> On 05/06/20 10:26 +0200, Igor Raits wrote: > ... > > Well, upstreams are not necessarily enabling many security features > > or > > optimizations. So you are effectively saying "upstream knows better" > > where I would have to disagree with you. > > Yes, this is a very good point. > > Many of Fedora's packages have upstreams that are not using the latest > compilers, libraries, security features etc. > > Just because upstream hasn't been updated to work with compiler > hardening features doesn't mean we should disable those features. Just > because upstream's code is not portable to more than one compiler > doesn't mean we shouldn't send them bugs (or better still, patches).<> Right. Though I think the security side of this largely belongs in redhat-rpm- config and moving annobin/annocheck into an enforcement role (like we've done with RHEL).
We did this for RHEL and while painful, getting the vast majority of packages to honor the flags injection and verification via annobin/annocheck before the resultant packages can be included in the distro has been a big win and enables us to do a lot of useful things knowing that the flags injection works well. Fedora is behind on this. While most packages honor flags injection, we don't actually know which do not (either by accident or design) and we don't have a way to easily find them. So things like CET in enforcing mode by default are going to be harder to achieve in Fedora than in RHEL. But like so many things, I don't have the time to push on something like this for Fedora. Jeff _______________________________________________ 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
