>>>> "BC" == Ben Cotton
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
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