Control: tags -1 moreinfo On Mon, 2022-09-19 at 10:06:11 +0200, intrigeri wrote: > Package: dpkg-dev > Version: 1.21.9 > Severity: wishlist
> According to > https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level, > _FORTIFY_SOURCE=3 improves memory management protections. It requires > glibc 2.34. It's been supported in Clang "for some time" and support > was added to GCC 12. I understand it has some performance impact. It would be nice to understand what's the impact here. Paul Wise also mentioned a thread on <https://news.ycombinator.com/item?id=32888516>. If the intention is to update the default, then that would require a discussion on d-d: <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F> > I suppose we don't want to switch hardening=fortify fortification > level 3, at least to start with. > > So perhaps a new hardening=XYZ flag could allow package maintainers to > opt-in? The main problem is that any new feature added to an area such as hardening will be automatically picked up by anything that is currently specifying hardening=all. :/ I've been pondering about managing this kind of thing via <https://wiki.debian.org/Teams/Dpkg/Spec/DpkgDevCompatLevel>, but I don't think that would even help with the =all problem. So I was thinking a potential solution would be to version the =all request somehow. We'd have =all meaning level 0, then say =all-v1 for the new defaults, that would also mean we can safely add new features that will not be part of the current =all. Thanks, Guillem
