[Rpm-maint] [rpm-software-management/rpm] Use xcalloc() instead of open-coded arithmetic (PR #1900)

Demi Marie Obenour notifications at github.com
Wed Jan 26 15:41:14 UTC 2022


> calloc() is significantly more expensive than malloc(), and these happen for every single package for non-trivial quantities of memory. A far subtler and generally useful hammer would be introducing + using a malloc() variant that takes calloc()-style arguments (similar to glibc reallocarray()) and failure semantics. There are some 160 malloc call-sites in rpm, and large number of them are performing arithmetics for the allocation size...

That’s a good idea, though refactoring the whole codebase is obviously out of scope for this patch.

> Oh and BTW, this being a regression of sorts, the fact + case history should be mentioned in the commit message.

Will do, thanks!

> This smells like a missing sanity check (or a bunch) somewhere _much_ earlier.

Personally I would prefer to ignore these tags if they are in the signature header, and change rpmsign to add them to the main header.  Not sure if that is a viable option, though.

Where should these consistency checks be located?  I do have some ideas but they may require significant refactoring.

> One known (to me) flaw is that both IMA and fs-verity signature tags miss pretty much _all_ sanity checks because they're not listed in rpmvs structures.

If by “rpmvs structures” you mean that they are in the signature header instead of the main header, that is definitely a problem, inasmuch as it means they are not covered by the signature and do not get type-checked.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1900#issuecomment-1022322402
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/1900/c1022322402 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220126/08a9e543/attachment.html>


More information about the Rpm-maint mailing list