[releng] Issue #7069: Enable annotaions of binaries compiled by gcc
by Nicholas Clifton
nickc reported a new issue against the project: `releng` that you are following:
``
I would like to enable binary annotations for files compiled by gcc. This will allow extra information to be stored in these files, such as which hardening options were used, the stack size requirements, potential ABI conflicts and so on.
In order to do this I propose patching the redhat-rpm-config rpm to enable the use of the annobin plugin. This plugin will add the extra information to the binary files. Some example scripts in the annobin package demonstrate how this information might be used.
This change has several possible consequences for release engineering:
* It might break the building of any package that uses gcc.
[I have tried to test building various packages locally, and these have all succeeded,
but I do not have the equivalent of an entire Fedora build system].
* The size of gcc built binaries will increase. Not by a huge amount I hope, since
the annotation format is designed to be compact, but it could still be a factor. Note
the information is stored in an unallocated section in the binary, so it will not affect
the size of the executable in memory, only on disk.
* if the annotations work it should allow releng the opportunity to add extra checks
for ABI incompatibilities and hardening problems.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7069
6 years, 1 month
v2: moving around some ostree repos
by Dusty Mabe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I got some suggestions on the original proposal [1] so here is a v2.
We are moving to a unified ostree repo model where we compose/ship
content for different releases in a single repo.
- From this we'll basically have one "compose" repo where all the different
branches and rawhide write into it and we'll have a unified repo where the
content will be published to.
When we moved bodhi over to start using pungi we configured it to use a
unified compose repo located at https://kojipkgs.fedoraproject.org/compose/updates/atomic/.
The plan is to take this existing repo and mv it to /compose/atomic/repo and
use it for *all* composes.
The steps are:
1. archive /compose/atomic to /compose/atomic_archive_$date
2. move the /compose/updates/atomic/ unified repo to /compose/atomic/
3. update all configs to compose into /compose/atomic and publish to /atomic/repo/
4. sync ostree content from /atomic/workstation/ into /atomic/repo/
Summary:
- - rawhide now composes in /compose/atomic/
- - branched now composes in /compose/atomic/
- - bodhi now composes in /compose/atomic
- - FAH & FAW rawhide now publishes to /atomic/repo/
- - FAH & FAW branched now publishes to /atomic/repo/
- - FAH & FAW released updates now publishes to /atomic/repo/
- - FAH 27 will continue to publish to /atomic/27/, 28 will move to /atomic/repo/
How do we handle the transition?
[FAH rawhide clients]
- - currently pull from /atomic/rawhide/
- - can redirect *or* tell clients to update configs
[FAW rawhide clients]
- - currently pull from /compose/ostree/rawhide/
- - we need to have them update anyway as they should not be pulling from compose location
[FAH 27 clients]
- - currently pull from https://kojipkgs.fedoraproject.org/atomic/27/
- - continue to pull from /atomic/27, will move to unified repo when they rebase to 28
[FAW 27 clients]
- - currently pull from https://dl.fedoraproject.org/ostree/27/ which is redirect for /atomic/workstation
- - can change existing redirect to point to /atomic/repo
If no one objects patrick and I will perform these changes soon.
Thanks,
Dusty
[1] https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject...
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlqYtWEACgkQMwLb1zlS
5nFhmg//Q2K/HeDGwFQo44lk31tMOuDr9xvCNiHUsU88xd8BII9TbPbTGnYvgo1o
5F3E/T8SQ7AH/ZAQpym9ctmrC3R5DtPlJPRbNI0+EkEDviDMMAbAjwiUgafb+KhX
hJURXvP/SVjuasRFplhIgMrgD/ycTQPMJ4vdV2vUq9W7PTt6zmKtCNZrgkFu/CcF
m01B8uzqoJzYy9ojCjaQIZ1MYk8j5tIuuO+IBsNsbeTXgamQ10nRwo0lC9s+/UGp
pNewEagaAqJ/nmsb41Z2bx/DW5MkNRgr+KNuSZf1MPQDm9RDWzSFpC8VFchXHdDt
iS6fTQZTZtNx+aWzEqZlhbq8TCKsyED/xJjgn91iXvkmFdELf2PL87UKKBUx30L8
JAFnU9n/XvAHMF2eCxQ/VvPNivLuapwcSFem+6YE++VP60hDcCf8DKW4ck94zYhp
99Xapz+UHOLuf5TZ/2CRFZWuJoeQz3xnRgKQVyd5uWWoZwa91n5KXH4o2G1QBmIa
w3qVrsnZH1hxxiWZjCrBo0o6pPAjzzbujWzS6Q7RVBp5U0s0XNELg11H2v+0sbY/
dsV1Gh0WuRR4CoRuozxjtA2R3PLgJN+nut/fbZmIKyyxF/qp45m2qV0JGYPKyK2N
RcK2ZIvE9VBeteRvibMpGdxf2oBxUAF7oF5vOBnndl4FJOk9OaA=
=HGgG
-----END PGP SIGNATURE-----
6 years, 1 month