Re: [gentoo-dev] Changing policy about -Werror
On Sun, Sep 9, 2018 at 1:50 PM Michael Orlitzky wrote: > > So if you're using -Werror to prevent a > "vulnerable" package from being installed, it doesn't work, and can > actually be harmful if it prevents me from using a better compiler. > Whether or not the new compiler is better, it is clearly untested with the package-version in question (otherwise these warnings would have been addressed). For something critical like a filesystem (zfs) that could be useful to know. I'm not convinced that this rule ought to be absolute. That said, I do agree with your later comments that this creates a messy situation by painting a user into a corner. Other than sticking painful ranged version dependencies on the toolchain into the package I'm not sure if there is a cleaner solution that guarantees that the package won't be built with a version of gcc that is untested with that specific package without a user override. I guess we could just have sensitive ebuilds output that it might eat your data if you didn't add -Werror to your CFLAGS and then leave it to the users to decide how much they care about build errors vs unlikely sorry-I-lost-your-10PiB-array errors. -- Rich
Re: [gentoo-dev] Changing policy about -Werror
Andrew Savchenko schrieb: So my proposal is: 1) Deprecate QA policy with unconditional demand of -Werror removal. 2) Add to devmanual's chapter on -Werror an exception clause about security-oriented software and maintainer's right to make final decision. Likely this proposal will not fly. I understand that -Werror is a precautionary measure against installing broken code on user systems, and I am all for using it when upstream says so. But it is understandably unwelcome by many on Gentoo. If ebuilds started to use -Werror in greater numbers, perceived tree quality would go down as build failures increase. "But it's for your own good!" you would tell users who are angry again that package XY didn't compile. -Werror gets in the way of users getting things done, and if that happens too often, you might drive those users out. So while I would very much like to see -Werror allowed, this is just not going to happen. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-09-09 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2018-09-09 23:59 UTC. Removals: dev-python/Coffin 20180903-13:25 vdupras 672f79ed8c4 dev-python/django-compressor 20180903-13:27 vdupras b82b9c91890 dev-python/django-openstack-auth 20180903-13:27 vdupras fcd692152c6 dev-python/django-tastypie20180903-13:26 vdupras 10271e0994c dev-python/jingo 20180903-13:25 vdupras 630c0c57527 dev-python/jsonfield 20180903-13:22 vdupras 69d02f6e520 sys-apps/microcode-ctl20180909-11:24 zlogene 6915ad82555 Additions: dev-perl/Devel-CheckOS20180907-07:18 kentnl e17b5bec66a dev-perl/Dumbbench20180907-08:41 kentnl 5e02b4f4944 dev-perl/Number-WithError 20180907-08:29 kentnl 166bc76dbef dev-perl/Statistics-CaseResampling20180907-08:35 kentnl 47c1f77d9ba dev-perl/Test-LectroTest 20180907-08:10 kentnl e0a5c9be16e dev-perl/Test-TempDir-Tiny20180907-06:20 kentnl 38276e12295 dev-python/async_generator20180905-02:14 zmedico 1004e415a8d dev-python/jeepney20180903-22:29 sbraz 7e73ae48bc3 dev-python/osc-placement 20180904-17:28 prometheanfire 1f60c2f7618 dev-python/sphinx-aiohttp-theme 20180905-03:18 zmedico 54e68e1e090 kde-apps/kitinerary 20180908-08:53 asturm 44068399ad9 kde-apps/kpkpass 20180908-08:53 asturm 44068399ad9 kde-frameworks/syndication20180908-08:27 asturm 64aa333e558 media-libs/libheif20180908-23:40 whissi dd208d76029 net-libs/google-cloud-cpp 20180907-18:02 perfinion 7fc4eccc434 net-libs/libad9361-iio20180904-20:53 zerochaos 25a6def0fb2 net-libs/libiio 20180904-20:53 zerochaos 600fde3abe0 net-wireless/cubicsdr 20180905-16:37 zerochaos 9c5dd3f3488 net-wireless/gr-iio 20180905-01:13 zerochaos 3ff0de7c990 net-wireless/soapyplutosdr20180904-20:54 zerochaos c4aaf04edbf sci-electronics/kicad-footprints 20180826-06:57 vdupras 45883f57160 sci-electronics/kicad-i18n20180827-06:44 vdupras 1711185d517 sci-electronics/kicad-meta20180904-04:26 vdupras 45c8884cde5 sci-electronics/kicad-packages3d 20180826-21:59 vdupras 9a6e700e20d sci-electronics/kicad-symbols 20180826-21:22 vdupras 0133314b450 sci-electronics/kicad-templates 20180826-21:31 vdupras b77019e631f sci-libs/oce 20180801-05:22 vdupras 9ba46ea6663 sys-auth/google-authenticator-libpam-hardened 20180909-07:00 mgorny f3855f930fa -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: sys-apps/microcode-ctl,removed,zlogene,20180909-11:24,6915ad82555 dev-python/django-compressor,removed,vdupras,20180903-13:27,b82b9c91890 dev-python/django-openstack-auth,removed,vdupras,20180903-13:27,fcd692152c6 dev-python/django-tastypie,removed,vdupras,20180903-13:26,10271e0994c dev-python/jingo,removed,vdupras,20180903-13:25,630c0c57527 dev-python/Coffin,removed,vdupras,20180903-13:25,672f79ed8c4 dev-python/jsonfield,removed,vdupras,20180903-13:22,69d02f6e520 Added Packages: sys-auth/google-authenticator-libpam-hardened,added,mgorny,20180909-07:00,f3855f930fa media-libs/libheif,added,whissi,20180908-23:40,dd208d76029 kde-apps/kitinerary,added,asturm,20180908-08:53,44068399ad9 kde-apps/kpkpass,added,asturm,20180908-08:53,44068399ad9 kde-frameworks/syndication,added,asturm,20180908-08:27,64aa333e558 net-libs/google-cloud-cpp,added,perfinion,20180907-18:02,7fc4eccc434 dev-perl/Dumbbench,added,kentnl,20180907-08:41,5e02b4f4944 dev-perl/Statistics-CaseResampling,added,kentnl,20180907-08:35,47c1f77d9ba dev-perl/Number-WithError,added,kentnl,20180907-08:29,166bc76dbef dev-perl/Test-LectroTest,added,kentnl,20180907-08:10,e0a5c9be16e dev-perl/Devel-CheckOS,added,kentnl,20180907-07:18,e17b5bec66a dev-perl/Test-TempDir-Tiny,added,kentnl,20180907-06:20,38276e12295 sci-electronics/kicad-meta,added,vdupras,20180904-04:26,45c8884cde5 sci-electronics/kicad-i18n,added,vdupras,20180827-06:44,1711185d517 sci-electronics/kicad-templates,added,vdupras,20180826-21:31,b77019e631f sci-electronics/kicad-packages3d,added,vdupras,20180826-21:59,9a6e700e20d sci
Re: [gentoo-dev] Changing policy about -Werror
Michał Górny schrieb: Are you suggesting that upstream is going to detect all those situations and prevent them from occurring, or are you going to WONTFIX the resulting bugs? No. With -Werror, upstream indicates that if a warning occurs, the build should fail and the resulting code not be installed on user systems. Instead, someone knowledgeable should look at the situation *first* and determine whether it is a bogus warning, a trivial issue, or something which warrants further attention. I have long disagreed with QA policy on this, and think that ebuilds should respect upstream here. Of course giving users the ability to override. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Changing policy about -Werror
On Sun, Sep 9, 2018 at 4:32 AM Andrew Savchenko wrote: > > Hi! > > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed > > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. Bug 665464 supports the exact opposite conclusion. Werror turned a trivial warning into a build failure. > My point is that in *most* cases -Werror indeed should be removed, > because upstream rarely can keep up with all possible configure, > *FLAGS, compiler versions and arch combinations. But! In some cases > — especially for security oriented software — this flag may be > pertain and may be kept at maintainer's discretion. > > The rationale is that -Werror usually points to dangerous > situations like uninitialized variables, pointer type mismatch or > implicit function declaration (and much more) which may lead to > serious security implications. Warnings are often over unimportant details (like in this bug). It is certainly not the case that they "usually point to dangerous situations". > So, if maintainer has enough manpower to support this flag, we > should allow to keep it. Of course if it will cause long-standing > troubles (e.g. bugs opened for a long time) QA should have power to > remove it or demand its removal. In the bug that started this, it was the case that the maintainer himself had not built the package with this configuration. Nor had any arch team that recently stabilized the package (x86, amd64, ia64, ppc, ppc64, arm). So again, the bug supports the opposite conclusion. The policy is sound, and I don't think we could have found a worse bug as supporting evidence that we should revise the policy.
Re: [gentoo-dev] Changing policy about -Werror
On 09/09/2018 07:32 AM, Andrew Savchenko wrote: > Hi! > > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed > > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. > > ... I agree with the QA team on this. For the upstream maintainer, -Werror is useful and deserves to be enabled. For the end-user, on the other hand, it has no real benefit. And for users of a source-based distribution, it is actively harmful. Here are some random points: * A -Werror failure doesn't actually prevent me from installing a package, it only prevents me from installing a package with a newer compiler (that often provides other security improvements, like Spectre mitigation). So if you're using -Werror to prevent a "vulnerable" package from being installed, it doesn't work, and can actually be harmful if it prevents me from using a better compiler. * The build failures from -Werror don't occur only with new installs. They also occur during rebuilds for things like USE changes or library ABI updates, leaving you with a broken system. * Upstream maintainers can't retroactively fix Gentoo versions. If some old version foo-1.0 builds with gcc-8.x and is stable, but then breaks with gcc-9.x due to a new warning, how is upstream going to fix that? They aren't -- and you aren't either without patching a supposedly stable package in-place. * Breakage with -Werror prevents upgrades of an already-installed package. If there's a security vulnerability in an old version and if -Werror is preventing me from upgrading (thanks to a gcc upgrade in the meantime), then you've just made things much worse. And so on.
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 9, 2018, at 1:09 PM, Richard Yao wrote: > > > >> On Sep 9, 2018, at 12:11 PM, Michał Górny wrote: >> >> On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote: On Sep 9, 2018, at 7:32 AM, Andrew Savchenko wrote: Hi! Our current -Werror policy demands unconditional removal: https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed I think this is wrong, see bugs 665464, 665538 for a recent discussion why. My point is that in *most* cases -Werror indeed should be removed, because upstream rarely can keep up with all possible configure, *FLAGS, compiler versions and arch combinations. But! In some cases — especially for security oriented software — this flag may be pertain and may be kept at maintainer's discretion. The rationale is that -Werror usually points to dangerous situations like uninitialized variables, pointer type mismatch or implicit function declaration (and much more) which may lead to serious security implications. So, if maintainer has enough manpower to support this flag, we should allow to keep it. Of course if it will cause long-standing troubles (e.g. bugs opened for a long time) QA should have power to remove it or demand its removal. So my proposal is: 1) Deprecate QA policy with unconditional demand of -Werror removal. 2) Add to devmanual's chapter on -Werror an exception clause about security-oriented software and maintainer's right to make final decision. >>> >>> -Werror has caught bugs that could have resulted in data loss in ZFS in the >>> past thanks to it being built in userspace as part of zdb. So it is useful >>> for integrity too, not just security (although arguably, integrity is part >>> of security). >>> >>> Currently, sys-fs/zfs turns on -Werror when USE=debug is set. So far, >>> nobody has complained about USE=debug enforcing -Werror. USE=debug by >>> definition ought to be an exception. >> >> Now that you know that you're violating a policy, please kindly fix >> that. > I already knew about the policy. However, USE=debug is by definition meant > for debug purposes. -Werror is helpful for debugging. There is nothing wrong > with turning it on for debugging. The normal builds don’t have USE=debug set > and -Werror is not used there. By the way, if people insist on applying this policy to USE=debug, I am inclined to mask the USE flag. This would satisfy the policy, but I don’t think that is better than how things are now. Users already are warned not to set USE=debug globally and if they are setting it on a specific package, they are opting into the package’s definition of debug functionality. I don’t see a problem with having -Werror as part of USE=debug. USE=debug on that package is meant to be an aid to upstream development and upstream in this case wants to know about any warnings. >>> Perhaps we could have another USE flag for -Werror where it is a security >>> feature. e.g. USE=strict-compile-checks >> >> Perhaps people could learn that Gentoo lets them alter CFLAGS, and stop >> inventing USE flags for every flag the compiler supports. >> Best regards, Andrew Savchenko >>> >>> >> >> -- >> Best regards, >> Michał Górny > >
Re: [gentoo-dev] Changing policy about -Werror
On Sep 9, 2018, at 12:32 PM, Ulrich Mueller wrote: >> On Sun, 09 Sep 2018, Andrew Savchenko wrote: > >> What I'm trying to do is to allow maintainers to keep -Werror if >> they really want to do this, understand what they are doing and >> have enough manpower to support this. > > Bug 665464 has just proven that this doesn't work. That bug would not > have happened if the policy had been followed. Also its fix (removal of > an unused variable) should have been applied only upstream. I don't see > a good reason for adding downstream patches that will make no difference > for the resulting binary. At least not when the upstream package is > maintained, and the issue will likely go away with one of the next > releases. > >> As can be seen from aforementioned bugs right now developer and >> upstream support this to their best and yet QA team tries to >> enforce -Werror drop using the brute force and ignoring active best >> effort support. This should not happen. > > See flameeyes's old blog post for the rationale why the current policy > is in place: > https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/ For every pointless check that fails -Werror, there is likely one that actually does matter. An unused variable could go either way if upstream intended to use that variable, but used another one by mistake (it happens). Allowing users to opt into -Werror behavior on specific packages whose maintainers have a good reason to do it and are keeping up with things would be alright. > > Ulrich >
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 9, 2018, at 12:11 PM, Michał Górny wrote: > > On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote: >>> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko wrote: >>> >>> Hi! >>> >>> Our current -Werror policy demands unconditional removal: >>> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed >>> >>> I think this is wrong, see bugs 665464, 665538 for a recent >>> discussion why. >>> >>> My point is that in *most* cases -Werror indeed should be removed, >>> because upstream rarely can keep up with all possible configure, >>> *FLAGS, compiler versions and arch combinations. But! In some cases >>> — especially for security oriented software — this flag may be >>> pertain and may be kept at maintainer's discretion. >>> >>> The rationale is that -Werror usually points to dangerous >>> situations like uninitialized variables, pointer type mismatch or >>> implicit function declaration (and much more) which may lead to >>> serious security implications. >>> >>> So, if maintainer has enough manpower to support this flag, we >>> should allow to keep it. Of course if it will cause long-standing >>> troubles (e.g. bugs opened for a long time) QA should have power to >>> remove it or demand its removal. >>> >>> So my proposal is: >>> >>> 1) Deprecate QA policy with unconditional demand of -Werror removal. >>> 2) Add to devmanual's chapter on -Werror an exception clause about >>> security-oriented software and maintainer's right to make final >>> decision. >> >> -Werror has caught bugs that could have resulted in data loss in ZFS in the >> past thanks to it being built in userspace as part of zdb. So it is useful >> for integrity too, not just security (although arguably, integrity is part >> of security). >> >> Currently, sys-fs/zfs turns on -Werror when USE=debug is set. So far, nobody >> has complained about USE=debug enforcing -Werror. USE=debug by definition >> ought to be an exception. > > Now that you know that you're violating a policy, please kindly fix > that. > >> Perhaps we could have another USE flag for -Werror where it is a security >> feature. e.g. USE=strict-compile-checks > > Perhaps people could learn that Gentoo lets them alter CFLAGS, and stop > inventing USE flags for every flag the compiler supports. Do that and watch nearly everything break. If a package really ought to have -Werror due to a very good reason and is properly maintained to support it, then there is nothing wrong with inventing a USE flag to give users the option of enforcing that. It is better than letting users discover that via random trial and error. That just wastes people’s time. > >>> >>> Best regards, >>> Andrew Savchenko >> >> > > -- > Best regards, > Michał Górny
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 9, 2018, at 12:11 PM, Michał Górny wrote: > > On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote: >>> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko wrote: >>> >>> Hi! >>> >>> Our current -Werror policy demands unconditional removal: >>> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed >>> >>> I think this is wrong, see bugs 665464, 665538 for a recent >>> discussion why. >>> >>> My point is that in *most* cases -Werror indeed should be removed, >>> because upstream rarely can keep up with all possible configure, >>> *FLAGS, compiler versions and arch combinations. But! In some cases >>> — especially for security oriented software — this flag may be >>> pertain and may be kept at maintainer's discretion. >>> >>> The rationale is that -Werror usually points to dangerous >>> situations like uninitialized variables, pointer type mismatch or >>> implicit function declaration (and much more) which may lead to >>> serious security implications. >>> >>> So, if maintainer has enough manpower to support this flag, we >>> should allow to keep it. Of course if it will cause long-standing >>> troubles (e.g. bugs opened for a long time) QA should have power to >>> remove it or demand its removal. >>> >>> So my proposal is: >>> >>> 1) Deprecate QA policy with unconditional demand of -Werror removal. >>> 2) Add to devmanual's chapter on -Werror an exception clause about >>> security-oriented software and maintainer's right to make final >>> decision. >> >> -Werror has caught bugs that could have resulted in data loss in ZFS in the >> past thanks to it being built in userspace as part of zdb. So it is useful >> for integrity too, not just security (although arguably, integrity is part >> of security). >> >> Currently, sys-fs/zfs turns on -Werror when USE=debug is set. So far, nobody >> has complained about USE=debug enforcing -Werror. USE=debug by definition >> ought to be an exception. > > Now that you know that you're violating a policy, please kindly fix > that. I already knew about the policy. However, USE=debug is by definition meant for debug purposes. -Werror is helpful for debugging. There is nothing wrong with turning it on for debugging. The normal builds don’t have USE=debug set and -Werror is not used there. > >> Perhaps we could have another USE flag for -Werror where it is a security >> feature. e.g. USE=strict-compile-checks > > Perhaps people could learn that Gentoo lets them alter CFLAGS, and stop > inventing USE flags for every flag the compiler supports. > >>> >>> Best regards, >>> Andrew Savchenko >> >> > > -- > Best regards, > Michał Górny
Re: [gentoo-dev] Changing policy about -Werror
> On Sun, 09 Sep 2018, Andrew Savchenko wrote: > What I'm trying to do is to allow maintainers to keep -Werror if > they really want to do this, understand what they are doing and > have enough manpower to support this. Bug 665464 has just proven that this doesn't work. That bug would not have happened if the policy had been followed. Also its fix (removal of an unused variable) should have been applied only upstream. I don't see a good reason for adding downstream patches that will make no difference for the resulting binary. At least not when the upstream package is maintained, and the issue will likely go away with one of the next releases. > As can be seen from aforementioned bugs right now developer and > upstream support this to their best and yet QA team tries to > enforce -Werror drop using the brute force and ignoring active best > effort support. This should not happen. See flameeyes's old blog post for the rationale why the current policy is in place: https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/ Ulrich
Re: [gentoo-dev] Changing policy about -Werror
On Sun, 2018-09-09 at 14:32 +0300, Andrew Savchenko wrote: > Hi! > > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed > > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. > > My point is that in *most* cases -Werror indeed should be removed, > because upstream rarely can keep up with all possible configure, > *FLAGS, compiler versions and arch combinations. But! In some cases > — especially for security oriented software — this flag may be > pertain and may be kept at maintainer's discretion. > > The rationale is that -Werror usually points to dangerous > situations like uninitialized variables, pointer type mismatch or > implicit function declaration (and much more) which may lead to > serious security implications. It may also point to a different coding style, user's flags (like clang's 'argument unused during X' warnings. Are you suggesting that upstream is going to detect all those situations and prevent them from occurring, or are you going to WONTFIX the resulting bugs? > > So, if maintainer has enough manpower to support this flag, we > should allow to keep it. Of course if it will cause long-standing > troubles (e.g. bugs opened for a long time) QA should have power to > remove it or demand its removal. What you're saying basically boils down to 'it's fine that the package randomly fails to build if somebody will fix it'. However, some people actually use Gentoo on real systems and really prefer when things *build*. While resolving warnings etc. is usually a worthwhile goal, not at the cost of having users repeatedly hit failures, have to report bugs about them and wait for the maintainer to fix them. Not to mention that those fixes only work for new versions, and therefore this whole idea turns downgrading (however undesirable you might consider it) into a pointless effort of chasing old warnings. This is just another example of writing programs for a single toolchain, and adding more hacks every time someone tests with another one. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing policy about -Werror
On Sun, 2018-09-09 at 11:22 -0400, Richard Yao wrote: > > On Sep 9, 2018, at 7:32 AM, Andrew Savchenko wrote: > > > > Hi! > > > > Our current -Werror policy demands unconditional removal: > > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed > > > > I think this is wrong, see bugs 665464, 665538 for a recent > > discussion why. > > > > My point is that in *most* cases -Werror indeed should be removed, > > because upstream rarely can keep up with all possible configure, > > *FLAGS, compiler versions and arch combinations. But! In some cases > > — especially for security oriented software — this flag may be > > pertain and may be kept at maintainer's discretion. > > > > The rationale is that -Werror usually points to dangerous > > situations like uninitialized variables, pointer type mismatch or > > implicit function declaration (and much more) which may lead to > > serious security implications. > > > > So, if maintainer has enough manpower to support this flag, we > > should allow to keep it. Of course if it will cause long-standing > > troubles (e.g. bugs opened for a long time) QA should have power to > > remove it or demand its removal. > > > > So my proposal is: > > > > 1) Deprecate QA policy with unconditional demand of -Werror removal. > > 2) Add to devmanual's chapter on -Werror an exception clause about > > security-oriented software and maintainer's right to make final > > decision. > > -Werror has caught bugs that could have resulted in data loss in ZFS in the > past thanks to it being built in userspace as part of zdb. So it is useful > for integrity too, not just security (although arguably, integrity is part of > security). > > Currently, sys-fs/zfs turns on -Werror when USE=debug is set. So far, nobody > has complained about USE=debug enforcing -Werror. USE=debug by definition > ought to be an exception. Now that you know that you're violating a policy, please kindly fix that. > Perhaps we could have another USE flag for -Werror where it is a security > feature. e.g. USE=strict-compile-checks Perhaps people could learn that Gentoo lets them alter CFLAGS, and stop inventing USE flags for every flag the compiler supports. > > > > Best regards, > > Andrew Savchenko > > -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changing policy about -Werror
> On Sep 9, 2018, at 7:32 AM, Andrew Savchenko wrote: > > Hi! > > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed > > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. > > My point is that in *most* cases -Werror indeed should be removed, > because upstream rarely can keep up with all possible configure, > *FLAGS, compiler versions and arch combinations. But! In some cases > — especially for security oriented software — this flag may be > pertain and may be kept at maintainer's discretion. > > The rationale is that -Werror usually points to dangerous > situations like uninitialized variables, pointer type mismatch or > implicit function declaration (and much more) which may lead to > serious security implications. > > So, if maintainer has enough manpower to support this flag, we > should allow to keep it. Of course if it will cause long-standing > troubles (e.g. bugs opened for a long time) QA should have power to > remove it or demand its removal. > > So my proposal is: > > 1) Deprecate QA policy with unconditional demand of -Werror removal. > 2) Add to devmanual's chapter on -Werror an exception clause about > security-oriented software and maintainer's right to make final > decision. -Werror has caught bugs that could have resulted in data loss in ZFS in the past thanks to it being built in userspace as part of zdb. So it is useful for integrity too, not just security (although arguably, integrity is part of security). Currently, sys-fs/zfs turns on -Werror when USE=debug is set. So far, nobody has complained about USE=debug enforcing -Werror. USE=debug by definition ought to be an exception. Perhaps we could have another USE flag for -Werror where it is a security feature. e.g. USE=strict-compile-checks > > Best regards, > Andrew Savchenko
Re: [gentoo-dev] Changing policy about -Werror
On Sun, 9 Sep 2018 14:32:21 +0300 Andrew Savchenko wrote: > Hi! > > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed Which is great. > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. That's just QA failing to be human in one report and then again in another report. It happens all the time and cannot be fixed, so you seem to instead suggest banning -Werror wrong because some developers think they can sanely cat-herd -Werror's overreaching effects. > My point is that in *most* cases -Werror indeed should be removed, > because upstream rarely can keep up with all possible configure, > *FLAGS, compiler versions and arch combinations. But! In some cases > — especially for security oriented software — this flag may be > pertain and may be kept at maintainer's discretion. ^^^ Pertinent, you meant to say, I assume. If you really have to support this mistaken (upstream) sense of security, instead go for -Werror= (see gcc(1)) i.e. turn very specific warnings into errors instead of turning _all_ warnings into errors. > The rationale is that -Werror usually points to dangerous > situations like uninitialized variables, pointer type mismatch or > implicit function declaration (and much more) No it does not. It merely turns warnings (non-fatal) emitted by the actual checks into errors (fatal). It does not cause any checks to be performed or warnings to be issued by itself. Setting or allowing a blanket -Werror therefore causes innocuous warnings like this: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] (In other words: FIXME: I didn't check this format because it was not a string literal and I cannot yet resolve those into an actual format defined elsewhere.*) and this: # hppa2.0-unknown-linux-gnu-gcc -fstack-protector main.c cc1: warning: -fstack-protector not supported for this target into hilarious errors. To some those might look like succeeding security checks, but they're really failing sanity checks. > which may lead to serious security implications. > > So, if maintainer has enough manpower to support this flag, we > should allow to keep it. Of course if it will cause long-standing > troubles (e.g. bugs opened for a long time) QA should have power to > remove it or demand its removal. > > So my proposal is: > > 1) Deprecate QA policy with unconditional demand of -Werror removal. You have yet to give arguments for its removal. Like, proper and particular examples of where -Werror benefits everyone. So far I've seen only some hand-waving of the (in)security banner. Unless you meant to say that security is improved when you can't install the software when of -Werror prevents it from being built, because then you've already solved the entire problem of the software's purported vulnerabilities, indeed. > 2) Add to devmanual's chapter on -Werror an exception clause about > security-oriented software and maintainer's right to make final > decision. That clause will be the laughing stock of the security community. Regards, jer * We have plenty of bug reports already where one "security researcher" points out that the build fails when the former warning is triggered when -Werror is injected, and it might indeed look like a lurking security issue if it weren't for the fact that the format sanity check never took place.
Re: [gentoo-dev] Changing policy about -Werror
On Sun, 9 Sep 2018 15:03:11 +0200 Thomas Deutschmann wrote: > Hi, > > I disagree. Either discuss to drop the entire policy about "-Werror" or > don't but please do _not_ enter the game of differentiating between > "normal" and something you call "security-orientated" packages. You got me wrong. I'm not trying to build special rules for security packages (since there is no margin between them and other packages and you rightfully pointed out that any vulnerability may play a role in a chained attack); they were just an example. What I'm trying to do is to allow maintainers to keep -Werror if they really want to do this, understand what they are doing and have enough manpower to support this. As can be seen from aforementioned bugs right now developer and upstream support this to their best and yet QA team tries to enforce -Werror drop using the brute force and ignoring active best effort support. This should not happen. Best regards, Andrew Savchenko pgp0NX1LMpgNP.pgp Description: PGP signature
Re: [gentoo-dev] Changing policy about -Werror
Hi, I disagree. Either discuss to drop the entire policy about "-Werror" or don't but please do _not_ enter the game of differentiating between "normal" and something you call "security-orientated" packages. You will lose this game in the end. If there's really a reason to allow "-Werror" it applies to *any* package or there isn't a good reason. _Any_ package can be part of a chained attack. Saying "Uh, this is a security-orientated package, we must keep '-Werror' for..." -- for WHAT?! You are probably creating a false sense of security... Let me remind you of something like https://daniel.haxx.se/blog/2016/10/14/a-single-byte-write-opened-a-root-execution-exploit/ No, "-Werror" wouldn't have prevent this, that's not my point. My point is, that there's nothing like "security-orientated" packages. And in the end you deal with chained attacks involving vectors you haven't thought of before involving otherwise harmless packages. Regarding a general drop of that policy: No, I wouldn't change that policy at all. Gentoo is a rolling distribution and "-Werror" creates undesired problems in most cases. Given that we have another rule that any package must respect user's CFLAGS any user or dev who care can add "-Werror" back to his/her CFLAGS... but don't force every user of Gentoo to deal with that. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Changing policy about -Werror
Hi! Our current -Werror policy demands unconditional removal: https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed I think this is wrong, see bugs 665464, 665538 for a recent discussion why. My point is that in *most* cases -Werror indeed should be removed, because upstream rarely can keep up with all possible configure, *FLAGS, compiler versions and arch combinations. But! In some cases — especially for security oriented software — this flag may be pertain and may be kept at maintainer's discretion. The rationale is that -Werror usually points to dangerous situations like uninitialized variables, pointer type mismatch or implicit function declaration (and much more) which may lead to serious security implications. So, if maintainer has enough manpower to support this flag, we should allow to keep it. Of course if it will cause long-standing troubles (e.g. bugs opened for a long time) QA should have power to remove it or demand its removal. So my proposal is: 1) Deprecate QA policy with unconditional demand of -Werror removal. 2) Add to devmanual's chapter on -Werror an exception clause about security-oriented software and maintainer's right to make final decision. Best regards, Andrew Savchenko pgpjt0_Y4nNob.pgp Description: PGP signature
