Hi, Guillem Jover (2022-09-23): > On Mon, 2022-09-19 at 10:06:11 +0200, intrigeri wrote: >> 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>.
Unfortunately, I'm not knowledgeable enough in this area to provide this information. > 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> My proposal, at least at this stage, is to *not* update the default: >> I suppose we don't want to switch hardening=fortify fortification >> level 3, at least to start with. It may be that the cost (performance) / benefit (security) needs to be assessed on a per-package basis, which would prevent us from ever making this the default. Anyway, IMO that's a discussion for years from now: we'll see how it works for distros that enable this feature, and once it is available in an opt-in manner, it'll be easier to gather the data we need to decide. >> 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. :/ Ouch. Thanks, I did not think of this. That indeed makes it difficult to add any new hardening build flag in an iterative manner :/ > 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. Sounds good! Should we track this versioning as a separate bug report, that would block this one? Thanks for your constructive reply, cheers!
