On Thu, Jan 20, 2022 at 10:52 PM James Carter <jwcart2@xxxxxxxxx> wrote: > On Thu, Jan 13, 2022 at 6:36 PM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > > The main goal of this move is to have the SHA-256 implementation under > > libsemanage, since upcoming patches will make use of SHA-256 for a > > different (but similar) purpose in libsemanage. Having the hashing code > > in libsemanage will reduce code duplication and allow for easier hash > > algorithm upgrade in the future. > > > > Note that libselinux currently also contains a hash function > > implementation (for yet another different purpose). This patch doesn't > > make any effort to address that duplicity yet. > > > > The changes here are only refactoring, no functional change is done > > here. A new libsemanage API function semanage_module_compute_checksum() > > is provided and semodule is made to use it for implementing its > > hash_module_data() function. > > > > Note that the API function also returns a string representation of the > > hash algorithm used, which is currently unused by semodule. The intent > > is to avoid ambiguity and potential collisions when the algorithm is > > potentially changed in the future. I could add the hash algorithm to the > > semodule output, but doing so might break tools parsing the exisiting > > format. (RFC: Should I change it anyway?) > > > > So that it would be a part of the hash string returned by > hash_module_data() in semodule.c? Yes. I imagine something like "sha256:0123456789abcfdef0123456789abcfdef0123456789abcfdef0123456789abcfdef" as used in the checksum file for the module changes detection. > I would want to hear from people who use the hashes before I would > want to change anything. Yep, I guess this is mainly a question for Petr, who was in contact with the team requesting this feature. Petr? -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
