Bill Allombert <[email protected]> writes: > On Sat, Feb 07, 2026 at 10:31:20AM -0800, Russ Allbery wrote: >> Ansgar <[email protected]> writes: >> >> This seems correct to me. We can at least make it a should in Debian >> Policy, and I can see the argument that it might be a must given the >> issues with time_t on 32-bit architectures. >> >> I'm not sure the best place to start with this given that we currently >> don't talk about dpkg-buildflags at all, as you point out. Maybe it's as >> simple as adding a 4.9.3 section along the following lines? >> >> This is very rough wording; feedback welcome. In particular, I'm a bit >> worried this is too strong when it comes to flags from dpkg-buildflags >> that are fine to override, such as changing the optimization level. > > I am not in favor of requiring the use of dpkg-buildflags in its current form. > At least dpkg-buildflag should be versionned so that package maintainers have > the ability to validate any compiler flags change before it is applied to a > package. > > Using different compiler flags than upstream is not very different from > patching the source code and should be treated with the same care. > > The concept of building all packages with the same flags do not really make > sense anyway. Packages serve different purpose. dpkg-buildflag targets > 'security flags' which are not relevant or suitable for HPC software > whose users require performance instead.
While I do agree with you on everything here, when I went back to read the proposed text from Russ, I think it works since it allows maintainers to opt out when needed. Did you intend your e-mail as opposition to the proposal? If so, could you explain why the opt out isn't sufficient? My perception is that opt-out is necessary and useful (for the reasons you explain) for many more packages than glibc though. I'm thinking of crypto packages like libmceliece, lib25519, lib1305 and probably many others where GCC/CLANG compiler flags are really security sensitive decisions, and one removed or added flag may mean that a severe timing side-channel is introduced. I believe there is some protection in the libraries I managed (careful checking of generated assembler output) but I expect these to be excellent examples compared to many others which just assume the compiler did what the upstream author intended to tell it (which dpkg-buildflags can break). I agree many other packages will need it for performance reasons, or other matters rather than security. Further, I think this set of packages will grow over the coming years. Still, I suspect more use of dpkg-buildflags will be generally useful, so I find the proposal good [unless I'm missing something]. /Simon
signature.asc
Description: PGP signature
