On 05.06.23 09:06, 'Earl Chew' via EFI Boot Guard wrote: > As explained in configure.ac: > >> AC_CHECK_LIB([z], [crc32], [], [AC_MSG_ERROR([need crc32 > implementation from libz])]) > > The CRC32 implementation comprises a lookup table, and a short loop to > process the data. > > The main purpose of zlib is to support compression, and I wonder if it > is worth taking this dependency for a relatively straightforward > checksum implementation. > > I also notice that there is an implementation of precisely the same > CRC32 algorithm in gnu-efi, and EFI Boot Guard already depends on gnu-efi. > > Today, the dependency on crc32 in zlib means that users of libebgenv.a > need to link -lz (as named in libebgenv.pc). Changing that to a > dependency on gnu-efi (for CalculateCrc) would mean that users of > libebgenv.a would instead need to link -lefi. Though there is a zlib.pc > for the current use case, there is no matching gnuefi.pc available as > far as I know. > > With that in mind, I think the most appropriate simplification is to > provide a crc32() implementation in EFI Boot Guard itself (eg env/crc32.c). > > Is there any appetite to remove this dependency on zlib? > > Are there other features planned which potentially depend on zlib?
Valid points, and I don't think that we will need compression in EBG in the foreseeable future. Happy to see any patch suggestions for moving to dedicated crc32 implementation. Maybe the one from gnuefi is statically linked anyway when using it? Jan -- Siemens AG, Technology Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/19c3ff16-e3ae-8d66-424a-a00f9fa0b0fc%40siemens.com.
