Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Jason L Tibbitts III]

> "BC" == Ben Cotton  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Steve Grubb]

On Thursday, October 31, 2019 7:04:47 AM EDT Aleksandra Fedorova wrote:
> Following pingou's advice adding c...@fedoraproject.org
> 
> On Wed, Oct 30, 2019 at 10:03 PM Ben Cotton  wrote:
> 
> >
> >
> > (skipped)
> >
> >
> >
> > Note - I do not know *how* to add a run of the annocheck program to
> > the Bodhi process.  This change request is about asking that such a
> > thing be added.
> 
> 
> In this form I think it doesn't qualify as Fedora Change, so let's see
> how we can rework it.
> 
> 
> > * Proposal owners:
> > In theory there is very little that I can do personally.  I do not
> > have the knowledge to change the Bodhi process myself, so I will have
> > to rely upon someone else to do that.  I am familiar with the annobin
> > package however, so any changes that are needed to it I will be happy
> > to make.
> 
> 
> We have a similar check coming to Fedora Rawhide gating. It is called
> rpminspect [1]. Check also the talk from Flock 2019 [2].
> Tim Flink and David Cantrell are driving it, and afaik it is close to
> being done: the Jenkins job is already up and running and we are
> hooking it into the gating framework.
> 
> If I understand correctly, the setup for annocheck should be very
> similar, so we can reuse most of the work done for rpminspect, with
> only the content of the test being different.
> There are several work items related to that: setup of a Jenkins job,
> update of a Jenkins which is needed to migrate to a new Fedora
> messaging infrastructure.
> 
> We can coordinate of that via Fedora CI SIG [3], next meeting is on
> November 4th [4] by the way.
> 
> Maybe we can make it a joint effort and file one change for both
> rpminspect and annocheck?

And one tangential question...will rpmfusion and others be held to this new 
standard? Many of the multimedia parsers that round out the Fedora ecosystem 
come from that repository. They also tend to have a lot of CVE's. I've 
scanned a number of packages that handle untrusted content and the use of 
protection mechanisms are really not up to par with the rest of Fedora.

-Steve


> [1] https://github.com/rpminspect/rpminspect
> [2] https://www.youtube.com/watch?v=lPxC185PBeI
> [3] https://fedoraproject.org/wiki/SIGs/CI
> [4] https://apps.fedoraproject.org/calendar/SIGs/2019/11/4/#m9618
> 
> -- 
> Aleksandra Fedorova
> bookwar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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/de...@lists.fedoraproject.or
> g



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Aleksandra Fedorova]

Following pingou's advice adding c...@fedoraproject.org

On Wed, Oct 30, 2019 at 10:03 PM Ben Cotton  wrote:
>
> (skipped)
>
> Note - I do not know *how* to add a run of the annocheck program to
> the Bodhi process.  This change request is about asking that such a
> thing be added.

In this form I think it doesn't qualify as Fedora Change, so let's see
how we can rework it.

> * Proposal owners:
> In theory there is very little that I can do personally.  I do not
> have the knowledge to change the Bodhi process myself, so I will have
> to rely upon someone else to do that.  I am familiar with the annobin
> package however, so any changes that are needed to it I will be happy
> to make.

We have a similar check coming to Fedora Rawhide gating. It is called
rpminspect [1]. Check also the talk from Flock 2019 [2].
Tim Flink and David Cantrell are driving it, and afaik it is close to
being done: the Jenkins job is already up and running and we are
hooking it into the gating framework.

If I understand correctly, the setup for annocheck should be very
similar, so we can reuse most of the work done for rpminspect, with
only the content of the test being different.
There are several work items related to that: setup of a Jenkins job,
update of a Jenkins which is needed to migrate to a new Fedora
messaging infrastructure.

We can coordinate of that via Fedora CI SIG [3], next meeting is on
November 4th [4] by the way.

Maybe we can make it a joint effort and file one change for both
rpminspect and annocheck?

[1] https://github.com/rpminspect/rpminspect
[2] https://www.youtube.com/watch?v=lPxC185PBeI
[3] https://fedoraproject.org/wiki/SIGs/CI
[4] https://apps.fedoraproject.org/calendar/SIGs/2019/11/4/#m9618

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Florian Weimer]

* Omair Majid:

>> It is desirable that the packaging guidelines be updated to describe
>> the security hardening features examined by annocheck.  (If they are
>> not already mentioned in the guidelines).
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
> has some of this, but not all. It seems to me like annocheck is more
> strict than the current packaging guidelines.

annocheck verifies against the Fedora build flags defined in
redhat-rpm-config and documented here:



The part of the Packaging Guidelines you quote has largely been
obsoleted by the Harden All Packages change in Fedora 23, and subsequent
changes in the flags are not reflected there, either.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Pierre-Yves Chibon]

On Wed, Oct 30, 2019 at 10:19:42PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Oct 30, 2019 at 05:01:55PM -0400, Ben Cotton wrote:
> > Note - I do not know *how* to add a run of the annocheck program to
> > the Bodhi process.  This change request is about asking that such a
> > thing be added.
> 
> I think the best approach to this would be turn it into a test that
> can be run in the CI and used in the gating process. The result
> would be only indirectly visible in bodhi (as part of the test results).
> No special support would be added in bodhi.

That is correct. We will not make this kind of changes to bodhi.
Fedora has grown a mechanism to integrate test results from different sources
which can then be used to gate packages in bodhi and this would be the mechanism
to use in this situation.

I encourage you to reach out to the CI folks (cf the CI mailing list) to see
what is needed from you to implement your test.
Once you have your test running on pull-request and bodhi udpates, you can
invite anyone and everyone to use it to gate their packages via the gating.yaml
file in their git repo.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Omair Majid]

Hi,

Ben Cotton  writes:

> The annobin package provides two components, a plugin for gcc that
> records details about how a program was compiled and an analyser that
> uses this information to produce a report on the security hardening
> status of the compiled program.  Currently the plugin is being used as
> part of the build process for Fedora packages (when they are built
> using gcc), but the analysing program is not being run.  This proposal
> is to have the analyser (called annocheck) run when creating
> information for review by the Bodhi update process, possibly allowing
> an update to be delayed until the security issues are addressed.

I currently run annocheck manually on my builds, so I am a fan of this
change.

But I think it's worth calling out one limitation: this currently mostly
works with gcc. clang is a bit behind in implementing some of the
features that annocheck looks at. With Fedora 30, annocheck would
cleanly skip most of clang-produced binaries. With Fedora 31, clang
seems to insert some of the meta-data that annocheck looks for, but
doesn't quite implement to match the gcc standard. I have recently run
into failures flagged by annocheck that I need to dig into on Fedora 31.

> It is desirable that the packaging guidelines be updated to describe
> the security hardening features examined by annocheck.  (If they are
> not already mentioned in the guidelines).

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
has some of this, but not all. It seems to me like annocheck is more
strict than the current packaging guidelines.

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 30, 2019 at 05:01:55PM -0400, Ben Cotton wrote:
> Note - I do not know *how* to add a run of the annocheck program to
> the Bodhi process.  This change request is about asking that such a
> thing be added.

I think the best approach to this would be turn it into a test that
can be run in the CI and used in the gating process. The result
would be only indirectly visible in bodhi (as part of the test results).
No special support would be added in bodhi.

Essentially, you'd provide a standard test that various packages could
use. Then it would be easier to override in specific packages to weed
out false positives.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Igor Gnatenko]

Hey Nick,

Is this change about stopping any builds which do not pass annocheck
test from going to stable repository or just adding new check in
there? If latter, I don't think it qualifies as a system-wide change.

On Wed, Oct 30, 2019 at 10:05 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/ANNOBIN-used-by-bodhi
>
> = Annobin Used By Bodhi =
>
> == Summary ==
> Use the annocheck program from the annobin package to produce an
> analysis of the security hardening of a compiled package when
> reviewing a Bodhi update.
>
> == Owner ==
> * Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
> * Email: ni...@redhat.com
>
> == Detailed Description ==
> The annobin package provides two components, a plugin for gcc that
> records details about how a program was compiled and an analyser that
> uses this information to produce a report on the security hardening
> status of the compiled program.  Currently the plugin is being used as
> part of the build process for Fedora packages (when they are built
> using gcc), but the analysing program is not being run.  This proposal
> is to have the analyser (called annocheck) run when creating
> information for review by the Bodhi update process, possibly allowing
> an update to be delayed until the security issues are addressed.
>
> The analyser currently looks for the following items:
>
> *  Lazy binding must not have been enabled via the linker option "-z
> lazy".  Instead the @option{-z now} option must have been used.
>
> * The program must not have a stack in an executable region of memory.
>
> * The relocations for the GOT table must be read only.
>
> * No program segment should have all three of the read, write and
> execute permission bits set.
>
> * There should be no relocations against executable code.
>
> * The runpath information used to locate shared libraries at runtime
> must only include directories rooted at /usr.
>
> * The program must have been compiled with the
> -fstack-protector-strong option enabled, and with -D_FORTIFY_SOURCE=2
> specified.  It must also have been compiled at at least optimisation
> level 2.
>
> * Dynamic executables must have a dynamic segment.
>
> * Shared libraries must have been compiled with -fPIC or-fPIE but not -static.
>
> * Dynamic executables must have been compiled with -fPIE and linked with -pie.
>
> * Program which use exception handling must have been compiled with
> -fexceptions enabled and with -D_GLIBCXX_ASSERTIONS specified.
>
> * If available the -fstack-clash-protection must have been used.
>
> * If available the -fcf-protection=full must have been used.
>
> * For i686 binaries, the -mstackrealign option must have been specified.
>
> * The program must have been compiled with the -D_FORTIFY_SOURCE=2
> command line option specified.
>
> * The program must have been compiled with at least -O2 optimisation enabled.
>
> * The program must not have any relocations that are held in a writable 
> section.
>
> * For x86_64 binaries, check that -fcf-protection has been enabled.
>
>
> Note - I do not know *how* to add a run of the annocheck program to
> the Bodhi process.  This change request is about asking that such a
> thing be added.
>
> == Benefit to Fedora ==
>
> Establishing good security practices when building packages will help
> Fedora remain a front running Linux distribution.  By providing a way
> to review the security hardening status of packages, this update will
> help to ensure that these practices continue.
>
> Note - the intention is that if this change is successful, and useful,
> then a future change request would be made to include the security
> checking as part of the actual package build process, and to have
> packages fail to complete building if they do not pass the security
> checks.
>
> == Scope ==
> * Proposal owners:
> In theory there is very little that I can do personally.  I do not
> have the knowledge to change the Bodhi process myself, so I will have
> to rely upon someone else to do that.  I am familiar with the annobin
> package however, so any changes that are needed to it I will be happy
> to make.
>
>
> * Other developers:
> Add an invocation of the annocheck program to the Bodhi build approval
> process and make its output available to reviewers.
> Annocheck can be invoked simply as "annocheck " although
> there are a set of command line options to extend and modify its
> behaviour.  Annocheck understands the rpm file format, as well as
> shared and static libraries and executable binaries.  It can also be
> helpful to provide annocheck with access to the debug information for
> a binary or rpm, if that has been placed into a separate file.
>
>
> * Release engineering: https://pagure.io/fedora-ci/general/issue/78
>
> No mass rebuild is required.
>
> * Policies and guidelines:
> It is desirable that the packaging guidelines be updated to describe
> the security hardening features examined by annocheck.  (If they are
> not already mentioned in the 

Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/ANNOBIN-used-by-bodhi

= Annobin Used By Bodhi =

== Summary ==
Use the annocheck program from the annobin package to produce an
analysis of the security hardening of a compiled package when
reviewing a Bodhi update.

== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com

== Detailed Description ==
The annobin package provides two components, a plugin for gcc that
records details about how a program was compiled and an analyser that
uses this information to produce a report on the security hardening
status of the compiled program.  Currently the plugin is being used as
part of the build process for Fedora packages (when they are built
using gcc), but the analysing program is not being run.  This proposal
is to have the analyser (called annocheck) run when creating
information for review by the Bodhi update process, possibly allowing
an update to be delayed until the security issues are addressed.

The analyser currently looks for the following items:

*  Lazy binding must not have been enabled via the linker option "-z
lazy".  Instead the @option{-z now} option must have been used.

* The program must not have a stack in an executable region of memory.

* The relocations for the GOT table must be read only.

* No program segment should have all three of the read, write and
execute permission bits set.

* There should be no relocations against executable code.

* The runpath information used to locate shared libraries at runtime
must only include directories rooted at /usr.

* The program must have been compiled with the
-fstack-protector-strong option enabled, and with -D_FORTIFY_SOURCE=2
specified.  It must also have been compiled at at least optimisation
level 2.

* Dynamic executables must have a dynamic segment.

* Shared libraries must have been compiled with -fPIC or-fPIE but not -static.

* Dynamic executables must have been compiled with -fPIE and linked with -pie.

* Program which use exception handling must have been compiled with
-fexceptions enabled and with -D_GLIBCXX_ASSERTIONS specified.

* If available the -fstack-clash-protection must have been used.

* If available the -fcf-protection=full must have been used.

* For i686 binaries, the -mstackrealign option must have been specified.

* The program must have been compiled with the -D_FORTIFY_SOURCE=2
command line option specified.

* The program must have been compiled with at least -O2 optimisation enabled.

* The program must not have any relocations that are held in a writable section.

* For x86_64 binaries, check that -fcf-protection has been enabled.


Note - I do not know *how* to add a run of the annocheck program to
the Bodhi process.  This change request is about asking that such a
thing be added.

== Benefit to Fedora ==

Establishing good security practices when building packages will help
Fedora remain a front running Linux distribution.  By providing a way
to review the security hardening status of packages, this update will
help to ensure that these practices continue.

Note - the intention is that if this change is successful, and useful,
then a future change request would be made to include the security
checking as part of the actual package build process, and to have
packages fail to complete building if they do not pass the security
checks.

== Scope ==
* Proposal owners:
In theory there is very little that I can do personally.  I do not
have the knowledge to change the Bodhi process myself, so I will have
to rely upon someone else to do that.  I am familiar with the annobin
package however, so any changes that are needed to it I will be happy
to make.


* Other developers:
Add an invocation of the annocheck program to the Bodhi build approval
process and make its output available to reviewers.
Annocheck can be invoked simply as "annocheck " although
there are a set of command line options to extend and modify its
behaviour.  Annocheck understands the rpm file format, as well as
shared and static libraries and executable binaries.  It can also be
helpful to provide annocheck with access to the debug information for
a binary or rpm, if that has been placed into a separate file.


* Release engineering: https://pagure.io/fedora-ci/general/issue/78

No mass rebuild is required.

* Policies and guidelines:
It is desirable that the packaging guidelines be updated to describe
the security hardening features examined by annocheck.  (If they are
not already mentioned in the guidelines).

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
This change should have no effect on upgrading Fedora, nor should it
introduce any compatibility problems.

== How To Test ==
Submit a package for Bodhi review and see if the annocheck data is
added to the page.
No special hardware is needed for this test, but it might involve the
use of a dummy package or a dummy instance of Bodhi in order to test
the behaviour before 

Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/ANNOBIN-used-by-bodhi

= Annobin Used By Bodhi =

== Summary ==
Use the annocheck program from the annobin package to produce an
analysis of the security hardening of a compiled package when
reviewing a Bodhi update.

== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com

== Detailed Description ==
The annobin package provides two components, a plugin for gcc that
records details about how a program was compiled and an analyser that
uses this information to produce a report on the security hardening
status of the compiled program.  Currently the plugin is being used as
part of the build process for Fedora packages (when they are built
using gcc), but the analysing program is not being run.  This proposal
is to have the analyser (called annocheck) run when creating
information for review by the Bodhi update process, possibly allowing
an update to be delayed until the security issues are addressed.

The analyser currently looks for the following items:

*  Lazy binding must not have been enabled via the linker option "-z
lazy".  Instead the @option{-z now} option must have been used.

* The program must not have a stack in an executable region of memory.

* The relocations for the GOT table must be read only.

* No program segment should have all three of the read, write and
execute permission bits set.

* There should be no relocations against executable code.

* The runpath information used to locate shared libraries at runtime
must only include directories rooted at /usr.

* The program must have been compiled with the
-fstack-protector-strong option enabled, and with -D_FORTIFY_SOURCE=2
specified.  It must also have been compiled at at least optimisation
level 2.

* Dynamic executables must have a dynamic segment.

* Shared libraries must have been compiled with -fPIC or-fPIE but not -static.

* Dynamic executables must have been compiled with -fPIE and linked with -pie.

* Program which use exception handling must have been compiled with
-fexceptions enabled and with -D_GLIBCXX_ASSERTIONS specified.

* If available the -fstack-clash-protection must have been used.

* If available the -fcf-protection=full must have been used.

* For i686 binaries, the -mstackrealign option must have been specified.

* The program must have been compiled with the -D_FORTIFY_SOURCE=2
command line option specified.

* The program must have been compiled with at least -O2 optimisation enabled.

* The program must not have any relocations that are held in a writable section.

* For x86_64 binaries, check that -fcf-protection has been enabled.


Note - I do not know *how* to add a run of the annocheck program to
the Bodhi process.  This change request is about asking that such a
thing be added.

== Benefit to Fedora ==

Establishing good security practices when building packages will help
Fedora remain a front running Linux distribution.  By providing a way
to review the security hardening status of packages, this update will
help to ensure that these practices continue.

Note - the intention is that if this change is successful, and useful,
then a future change request would be made to include the security
checking as part of the actual package build process, and to have
packages fail to complete building if they do not pass the security
checks.

== Scope ==
* Proposal owners:
In theory there is very little that I can do personally.  I do not
have the knowledge to change the Bodhi process myself, so I will have
to rely upon someone else to do that.  I am familiar with the annobin
package however, so any changes that are needed to it I will be happy
to make.


* Other developers:
Add an invocation of the annocheck program to the Bodhi build approval
process and make its output available to reviewers.
Annocheck can be invoked simply as "annocheck " although
there are a set of command line options to extend and modify its
behaviour.  Annocheck understands the rpm file format, as well as
shared and static libraries and executable binaries.  It can also be
helpful to provide annocheck with access to the debug information for
a binary or rpm, if that has been placed into a separate file.


* Release engineering: https://pagure.io/fedora-ci/general/issue/78

No mass rebuild is required.

* Policies and guidelines:
It is desirable that the packaging guidelines be updated to describe
the security hardening features examined by annocheck.  (If they are
not already mentioned in the guidelines).

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
This change should have no effect on upgrading Fedora, nor should it
introduce any compatibility problems.

== How To Test ==
Submit a package for Bodhi review and see if the annocheck data is
added to the page.
No special hardware is needed for this test, but it might involve the
use of a dummy package or a dummy instance of Bodhi in order to test
the behaviour before