Simon Josefsson <[email protected]> writes: > 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. Correct, the intention is not to say that everyone must do this, which is why it's a should, not a must. My intention is to make it a should with an exception: *if* your package is particularly sensitive to compiler flags for some reason, *then* you can ignore dpkg-buildflags (or selectively override it), but you are now responsible for keeping your compilation flags up-to-date. I think this is one of those cases where the goal is to get the 95% of the packages that probably shouldn't have strong opinions about compiler flags onto the standard machinery (or, to be more accurate, to document that we have largely already done this and give the stragglers a bit of a push), without ruling out the remaining 5% of exceptions that have good reasons to control their flags. It's also secondarily to try to say that it is worth the effort to plug dpkg-buildflags into the build system of packages that aren't easily supported with dh. It's possible that my proposed wording is too strong, but I'm hoping we can build a consensus that something *like* this is the right idea and then find the right wording for the exception. Being able to add new flags via dpkg-buildflags is immensely powerful makes transitions much easier, so I think it's a good idea to ask maintainers to not break this without a good reason. > 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. Also, hopefully some of these cases can be handled via dpkg-buildflags feature areas rather than abandoning the tool entirely. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
