>>>>> "BC" == Ben Cotton <bcotton@xxxxxxxxxx> writes: BC> Use the annocheck program from the annobin package to BC> produce an analysis of the security hardening of a compiled package BC> when reviewing a Bodhi update. While I don't disagree with running annocheck at some point in the build process, _only_ doing things in bodhi can be problematic for packagers. The issue is that you can build and test and have others test and be ready to submit an update, only to be stopped by some additional testing that you had no idea you needed to take extra steps to duplicate locally. Personally I'd prefer to do this in a brp script. Those run near the end of the build process, can output things into the build log which can be checked easily (even by anything which can look at koji, which I suppose would include bodhi) and could, if it were desired, fail the build entirely, notifying packagers of policy violations as early as possible instead of after waiting for a real koji build and bodhi processing. All this would take is a shell wrapper, a small tweak in redhat-rpm-config, and getting annocheck into the buildroot. Things to note: 1. You need the annocheck (or rather the annobin-annocheck package) in the buildroot. It doesn't appear to have additional dependencies which aren't already in the buildroot and the package is minimal, so this probably isn't a huge issue. 2. It's easy to disable brp scripts, which can be good or bad depending on whether you want them to implement hard policy. But it is also easy to find packages which disable them by grepping specfiles, and if the script is written to always output something then you can just grep the build log for evidence that it ran. 3. People get rather annoyed if builds start failing because of additional policy checks. This is of course mitigated somewhat by #2 above. Generally what we've done in the past is add the checks in some advisory mode and then turn bad things into failures after a release. - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
