Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Wed, May 10, 2017, at 00:07 CDT, Jason Zaman wrote: > I just want to make sure im understanding this right, only .a files that > were compiled without -pie will cause issues if you compile the later > thing that uses the .a with -pie? > So: > 1) people on hardened profiles are going to be fine no matter what? Yes. > 2) only packages that have .a files need to be rebuild? (not -e @world)? Essentially yes. (There might be one or two additional catches for languages with special linkage/libraries. For example, haskell packages have to force -no-pie - which they already do :-]) > 3) .a are static libs for compiling static binaries right, so nothing > will break at runtime from the change? only build failures? Yes. > I definitley think everyone on gentoo should have PIE and SSP by default > nowadays. Whats the status of -zrelro -znow on non-hardened? The essential difference between non-hardened and hardened is additional -fstack-protector-all -fstrict_overflow -znow on hardened. > This might be the kind of thing where a new set of profiles is a good > idea > 1) hardened would force the flags on, > 2) 13.0 non-hardened would force them off > 3) 17.0 non-hardened would force them on and people have to rebuild when > they change profiles *mhm* A profile update would also be an idea. > Im not sure how the timing of the new profile would work? only make them > once gcc-6 is stable so everyone does it at once? Best, Matthias
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Wed, May 10, 2017 at 01:44:06AM +0200, Andreas K. Huettel wrote: > Am Dienstag, 9. Mai 2017, 22:10:21 CEST schrieb Alexis Ballier: > > > > Do you realize that this breaks linking against about any static lib > > ever built before upgrading ? And I'm not even considering people > > toggling the flag. > > Toggling the flag is definitely bad. So it should be either on or off. > > > > > While I believe it might be a bit too early to default-enable pie, why > > not, but the news item *must* contain instructions that people should > > 'emerge -e world' in order for it to work. > > > > Also, I don't believe default-pie should even be a useflag. It's always > > been forced-on for hardened and forced-off for non-hardened I think. > > Switching between the two types of profiles has always been difficult > > because of that kind of differences. I strongly believe this should stay > > that way (that is: this cant be toggled by a simple useflag). > > > > Well... Hanno and Matthias said Gentoo is about the only place where it isn't > on by default. So why are we "early", and why not just force it on for > everybody? I just want to make sure im understanding this right, only .a files that were compiled without -pie will cause issues if you compile the later thing that uses the .a with -pie? So: 1) people on hardened profiles are going to be fine no matter what? 2) only packages that have .a files need to be rebuild? (not -e @world)? 3) .a are static libs for compiling static binaries right, so nothing will break at runtime from the change? only build failures? I definitley think everyone on gentoo should have PIE and SSP by default nowadays. Whats the status of -zrelro -znow on non-hardened? This might be the kind of thing where a new set of profiles is a good idea 1) hardened would force the flags on, 2) 13.0 non-hardened would force them off 3) 17.0 non-hardened would force them on and people have to rebuild when they change profiles Im not sure how the timing of the new profile would work? only make them once gcc-6 is stable so everyone does it at once? -- Jason
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2
This is a reworded news item (assuming we proceed with the plan to default-enable USE=pie). Suggestions for improving the emerge command to fix static archives is highly welcomed. Matthias Title: GCC 6 defaults to USE="pie ssp" Author: Matthias Maier Content-Type: text/plain Posted: 2017-05-09 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: >=sys-devel/gcc-6.3.0 In Gentoo, several GCC features can be default disabled or enabled via use-flags of sys-devel/gcc. Starting with gcc-4.8.3 we have already enabled default SSP [1]. Since the PIE patchset for default position independent executable support was integrated upstream [2,3], starting with gcc-6.3 we are also enabling PIE by default (via a default-enabled use-flag pie) in regular (non-hardened) profiles. [Additionally, following Gentoo policies, the default-off use-flags nopie (only present in Hardened) and nossp are replaced starting with gcc-6 by default-on use-flags pie and ssp.] Be advised that switching from an older version to GCC 6 will enable the PIE feature by default. This should not cause many problems for packages involving shared libraries. However, static archives need to be rebuilt (otherwise final linkage will fail [4]. You can rebuild affected packages containing static archives via # emerge --exclude 'dev-haskell/*' -1 $(find /lib* /usr/lib* -type f -name "*.a") [1] https://www.gentoo.org/support/news-items/2014-06-15-gcc48_ssp.html [2] https://gcc.gnu.org/gcc-6/changes.html [3] A big thanks to all developers and members of the Gentoo community that made upstreaming the pie patchset and other hardening options possible! [4] A typical link error reads relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
Am Dienstag, 9. Mai 2017, 22:10:21 CEST schrieb Alexis Ballier: > > Do you realize that this breaks linking against about any static lib > ever built before upgrading ? And I'm not even considering people > toggling the flag. Toggling the flag is definitely bad. So it should be either on or off. > > While I believe it might be a bit too early to default-enable pie, why > not, but the news item *must* contain instructions that people should > 'emerge -e world' in order for it to work. > > Also, I don't believe default-pie should even be a useflag. It's always > been forced-on for hardened and forced-off for non-hardened I think. > Switching between the two types of profiles has always been difficult > because of that kind of differences. I strongly believe this should stay > that way (that is: this cant be toggled by a simple useflag). > Well... Hanno and Matthias said Gentoo is about the only place where it isn't on by default. So why are we "early", and why not just force it on for everybody? -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
Am Mittwoch, 10. Mai 2017, 00:47:30 CEST schrieb Alexis Ballier: > On Tue, 9 May 2017 23:18:20 +0200 Hanno Böck wrote: > > I really think it's about time that pie becomes the default in Gentoo. > > For a transition we can probably build everything with -fPIE but not > link with -pie. If we want that to happen fast, gcc-6 might do that and > gcc-7 add the -pie option. What do we gain by that? Wouldn't we need to rebuild all the static archives afterwards again anyway, just to make sure they have been rebuilt? -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
> For a transition we can probably build everything with -fPIE but not > link with -pie. If we want that to happen fast, gcc-6 might do that and > gcc-7 add the -pie option. I am not entirely convinced that a transition period of one gcc version is enough for a smooth transition [1]. It might be better to go through a quick transition process that requires a world rebuild. - In particular we already forced everyone on ~amd64 to play beta tester in this regard [2,3]. Anyway the current use flag situation is a mess and has to be cleaned up asap. So, dos anyone recall why USE=pie was masked for >gcc-6.2 for everyone except amd64? Related to that - for which architectures shall we unmask the use flag? - shall we use.force a certain behavior per profile, or keep the flag unpinned? After having thought about the issue for a bit I still want to propose what we have already accidentally done - switch to USE=pie per default for gcc-6. Best, Matthias [1] Indeed *every* major linux distribution for which I have an lxc container has -pie enabled. If we decide on some slow transition we risk to be late to the party by quite a bit. [2] Which is extremely unfortunate. [3] The fallout I currently see due to enabled USE=pie is noticeably but by no stretch crazy bad. After all, static linkage is rarely used (with the exception of some languages). signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Tue, 9 May 2017 23:18:20 +0200 Hanno Böck wrote: > Hi, > > On Tue, 09 May 2017 15:55:36 -0500 > Matthias Maier wrote: > > > Well, Alexis certainly makes a strong point. Breaking installed > > static archives by changing a use flag shouldn't be as easy as > > changing a useflag. So we might simply use.force the pie use flag > > depending on hardened/non-hardened profiles. > > While I understand that enabling pie requires some more planning to > avoid breakage, I hope this is not the final solution we aim for. I > really think it's about time that pie becomes the default in Gentoo. For a transition we can probably build everything with -fPIE but not link with -pie. If we want that to happen fast, gcc-6 might do that and gcc-7 add the -pie option. Alexis.
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
Hi, On Tue, 09 May 2017 15:55:36 -0500 Matthias Maier wrote: > Well, Alexis certainly makes a strong point. Breaking installed static > archives by changing a use flag shouldn't be as easy as changing a > useflag. So we might simply use.force the pie use flag depending on > hardened/non-hardened profiles. While I understand that enabling pie requires some more planning to avoid breakage, I hope this is not the final solution we aim for. I really think it's about time that pie becomes the default in Gentoo. pie is required for working ASLR, which almost every other OS out there has these days. In recent years also Fedora, Ubuntu and lately Debian switched it on by default. I really think this should be a default security setting, not something that only lives in hardened. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
[gentoo-dev] [PATCH] profiles: Mask pie useflag for >=sys-devel/gcc-6
- Mask sys-devel/gcc pie useflag globally in /base - Selectively unmask pie useflag for hardened/linux hardened/linux/musl profiles - Ensure pie useflag is forced for hardened profiles --- profiles/arch/amd64/package.use.mask| 4 profiles/arch/base/package.use.mask | 4 profiles/base/package.use.mask | 4 profiles/hardened/linux/musl/amd64/package.use.mask | 6 -- profiles/hardened/linux/musl/package.use.mask | 4 profiles/hardened/linux/musl/use.force | 4 profiles/hardened/linux/package.use.mask| 4 profiles/hardened/linux/use.force | 2 +- 8 files changed, 17 insertions(+), 15 deletions(-) delete mode 100644 profiles/hardened/linux/musl/amd64/package.use.mask diff --git a/profiles/arch/amd64/package.use.mask b/profiles/arch/amd64/package.use.mask index 4548392..2fe5376 100644 --- a/profiles/arch/amd64/package.use.mask +++ b/profiles/arch/amd64/package.use.mask @@ -30,10 +30,6 @@ dev-lang/ocaml -spacetime # nvidia drivers are unmasked here media-video/ffmpeg -nvenc -# Magnus Granberg (18 Jan 2017) -# masked in base, unmask for amd64 ->=sys-devel/gcc-6.3.0 -pie - # Luke Dashjr (04 Jan 2017) # Assembly optimisations are supported on amd64 for all versions dev-libs/libsecp256k1 -asm diff --git a/profiles/arch/base/package.use.mask b/profiles/arch/base/package.use.mask index f2d3a9b..8442d97 100644 --- a/profiles/arch/base/package.use.mask +++ b/profiles/arch/base/package.use.mask @@ -18,10 +18,6 @@ media-video/ffmpeg nvenc # media-libs/raspberrypi-userland not keyworded media-video/motion mmal -# Magnus Granberg (18 Jan 2017) -# Mask it globally, unmask it on supported arch ->=sys-devel/gcc-6.2.0 pie - # Luke Dashjr (04 Jan 2017) # Mask assembly optimisations that are platform-specific dev-libs/libsecp256k1 asm diff --git a/profiles/base/package.use.mask b/profiles/base/package.use.mask index 9f55b27..c8faec7 100644 --- a/profiles/base/package.use.mask +++ b/profiles/base/package.use.mask @@ -7,6 +7,10 @@ # This file is only for generic masks. For arch-specific masks (i.e. # mask everywhere, unmask on arch/*) use arch/base. +# Matthias Maier (09 May 2017) +# Mask pie useflag globally and unmask + use.force on hardened profiles. +sys-devel/gcc pie + # Mike Gilbert (28 Apr 2017) # Needs sandbox-2.11 (masked) >=www-client/chromium-59 tcmalloc diff --git a/profiles/hardened/linux/musl/amd64/package.use.mask b/profiles/hardened/linux/musl/amd64/package.use.mask deleted file mode 100644 index e2d77b0.. --- a/profiles/hardened/linux/musl/amd64/package.use.mask +++ /dev/null @@ -1,6 +0,0 @@ -# Copyright 1999-2017 Gentoo Foundation. -# Distributed under the terms of the GNU General Public License v2 - -# Matthias Maier (07 May 2017) -# masked in arch/base, unmask for hardened/musl/amd64 ->=sys-devel/gcc-6.3.0 -pie diff --git a/profiles/hardened/linux/musl/package.use.mask b/profiles/hardened/linux/musl/package.use.mask index 9078b7c..46857dc 100644 --- a/profiles/hardened/linux/musl/package.use.mask +++ b/profiles/hardened/linux/musl/package.use.mask @@ -1,6 +1,10 @@ # Copyright 1999-2015 Gentoo Foundation. # Distributed under the terms of the GNU General Public License v2 +# Matthias Maier (09 May 2017) +# Unmask the pie useflag on hardened/linux/musl profiles. +sys-devel/gcc -pie + # See bug #504200 sys-devel/gcc sanitize diff --git a/profiles/hardened/linux/musl/use.force b/profiles/hardened/linux/musl/use.force index 79e5575..debacff 100644 --- a/profiles/hardened/linux/musl/use.force +++ b/profiles/hardened/linux/musl/use.force @@ -2,3 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 elibc_musl + +# Make sure people don't accidentally turn off ssp/pie in important packages. +pie +ssp diff --git a/profiles/hardened/linux/package.use.mask b/profiles/hardened/linux/package.use.mask index 4178151..aa2adc5 100644 --- a/profiles/hardened/linux/package.use.mask +++ b/profiles/hardened/linux/package.use.mask @@ -1,6 +1,10 @@ # Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 +# Matthias Maier (09 May 2017) +# Unmask the pie useflag on hardened profiles. +sys-devel/gcc -pie + # Ilya Tumaykin (19 Jan 2017) # Requires x11-drivers/nvidia-drivers. Needs testing first. media-video/mpv cuda diff --git a/profiles/hardened/linux/use.force b/profiles/hardened/linux/use.force index 35e5653..ec5509c 100644 --- a/profiles/hardened/linux/use.force +++ b/profiles/hardened/linux/use.force @@ -1,6 +1,6 @@ # Copyright 1999-2015 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# Make sure people don't accidentally turn of ssp/pie in important packages. +# Make sure people don't accidentally turn off ssp/pie in important packages. pie ssp -- 2.10.2
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Tue, May 9, 2017, at 15:10 CDT, Alexis Ballier wrote: > There is a *huge* difference between: > Disable PIE support (NOT FOR GENERAL USE) > and the negation of: > pie - Build programs as Position Independent Executables (a security > hardening technique) > > Enabling the latter builds *everything* as PIE. Yes. > Do you realize that this breaks linking against about any static lib > ever built before upgrading ? And I'm not even considering people > toggling the flag. Yes, I am aware of this. On Tue, May 9, 2017, at 15:27 CDT, Mike Gilbert wrote: > I disagree. We might want to default the "pie" USE flag differently > depending on the profile, but there's no need to force it. Well, Alexis certainly makes a strong point. Breaking installed static archives by changing a use flag shouldn't be as easy as changing a useflag. So we might simply use.force the pie use flag depending on hardened/non-hardened profiles. I'll follow up with a proposed profile change forcing -pie for non hardened and pie for hardened profiles (instead of this news item). I have one question, though: For what arches do we have to disable pie? (The current patchset simply enables all.) Best, Matthias
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Tue, May 9, 2017 at 4:10 PM, Alexis Ballier wrote: > Also, I don't believe default-pie should even be a useflag. It's always > been forced-on for hardened and forced-off for non-hardened I think. > Switching between the two types of profiles has always been difficult > because of that kind of differences. I strongly believe this should stay > that way (that is: this cant be toggled by a simple useflag). I disagree. We might want to default the "pie" USE flag differently depending on the profile, but there's no need to force it.
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Tue, 09 May 2017 12:26:48 -0500 Matthias Maier wrote: > Title: GCC 6 defaults to USE="pie ssp" > Author: Matthias Maier > Content-Type: text/plain > Posted: 2017-05-07 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: >=sys-devel/gcc-6.3.0 > Display-If-Keyword: amd64 > > In Gentoo, several GCC features can be default disabled or enabled > via use-flags of sys-devel/gcc. Starting with gcc-4.8.3 we have > already enabled default SSP [1]. Since the PIE patchset for default > position independent executable support was integrated upstream > [2,3], starting with gcc-6.3 we are also enabling PIE by default (via > a default-enabled use-flag pie) in regular (non-hardened) profiles. > > [Additionally, following Gentoo policies, the default-off use-flags > nopie (only present in Hardened) and nossp are replaced starting with > gcc-6 by default-on use-flags pie and ssp.] There is a *huge* difference between: Disable PIE support (NOT FOR GENERAL USE) and the negation of: pie - Build programs as Position Independent Executables (a security hardening technique) Enabling the latter builds *everything* as PIE. > Be advised that switching from an older version to GCC 6 will enable > the PIE feature by default. This should not cause many problems, but > it may be necessary to recompile parts of your userland. An indicator > are linker errors of the form [4] Do you realize that this breaks linking against about any static lib ever built before upgrading ? And I'm not even considering people toggling the flag. While I believe it might be a bit too early to default-enable pie, why not, but the news item *must* contain instructions that people should 'emerge -e world' in order for it to work. Also, I don't believe default-pie should even be a useflag. It's always been forced-on for hardened and forced-off for non-hardened I think. Switching between the two types of profiles has always been difficult because of that kind of differences. I strongly believe this should stay that way (that is: this cant be toggled by a simple useflag). Bests, Alexis.
[gentoo-dev] Re: [PATCH] toolchain.eclass: add DEPEND to dev-libs/boehm-gc, bug #617788
On 5/9/17 7:15 PM, Matthias Maier wrote: > sys-devel/gcc-7.1.0 requires external dev-libs/boehm-gc, the internal > copy got removed [1]. > > [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242985 > --- > eclass/toolchain.eclass | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass > index acdd401..db6e643 100644 > --- a/eclass/toolchain.eclass > +++ b/eclass/toolchain.eclass > @@ -178,6 +178,12 @@ fi > > tc_version_is_at_least 4.5 && RDEPEND+=" >=dev-libs/mpc-0.8.1:0" > > +if in_iuse objc-gc ; then > + if tc_version_is_at_least 7 ; then > + RDEPEND+=" objc-gc? ( >=dev-libs/boehm-gc-7.4.2 )" > + fi > +fi > + > if in_iuse graphite ; then > if tc_version_is_at_least 5.0 ; then > RDEPEND+=" graphite? ( >=dev-libs/isl-0.14 )" > looks fine.
[gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"
Title: GCC 6 defaults to USE="pie ssp" Author: Matthias Maier Content-Type: text/plain Posted: 2017-05-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: >=sys-devel/gcc-6.3.0 Display-If-Keyword: amd64 In Gentoo, several GCC features can be default disabled or enabled via use-flags of sys-devel/gcc. Starting with gcc-4.8.3 we have already enabled default SSP [1]. Since the PIE patchset for default position independent executable support was integrated upstream [2,3], starting with gcc-6.3 we are also enabling PIE by default (via a default-enabled use-flag pie) in regular (non-hardened) profiles. [Additionally, following Gentoo policies, the default-off use-flags nopie (only present in Hardened) and nossp are replaced starting with gcc-6 by default-on use-flags pie and ssp.] Be advised that switching from an older version to GCC 6 will enable the PIE feature by default. This should not cause many problems, but it may be necessary to recompile parts of your userland. An indicator are linker errors of the form [4] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC [1] https://www.gentoo.org/support/news-items/2014-06-15-gcc48_ssp.html [2] https://gcc.gnu.org/gcc-6/changes.html [3] A big thanks to all developers and members of the Gentoo community that made upstreaming the pie patchset and other hardening options possible! [4] https://bugs.gentoo.org/617698 signature.asc Description: PGP signature
[gentoo-dev] [PATCH] toolchain.eclass: add DEPEND to dev-libs/boehm-gc, bug #617788
sys-devel/gcc-7.1.0 requires external dev-libs/boehm-gc, the internal copy got removed [1]. [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242985 --- eclass/toolchain.eclass | 6 ++ 1 file changed, 6 insertions(+) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index acdd401..db6e643 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -178,6 +178,12 @@ fi tc_version_is_at_least 4.5 && RDEPEND+=" >=dev-libs/mpc-0.8.1:0" +if in_iuse objc-gc ; then + if tc_version_is_at_least 7 ; then + RDEPEND+=" objc-gc? ( >=dev-libs/boehm-gc-7.4.2 )" + fi +fi + if in_iuse graphite ; then if tc_version_is_at_least 5.0 ; then RDEPEND+=" graphite? ( >=dev-libs/isl-0.14 )" -- 2.10.2
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 05/09/2017 09:36 AM, Anthony G. Basile wrote: > > Perhaps I'm missing the issue, but can you just follow the dependencies > and drop keywords accordingly so the tree remains consistent. > If we can make it policy that I'm allowed to edit a bunch of other peoples' packages and de-keyword stable versions, then yeah; but I don't think it's allowed currently and I'd probably get some angry emails.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/05/2017 15:49, Michał Górny wrote: > Dnia 8 maja 2017 15:27:18 CEST, Dirkjan Ochtman > napisał(a): >> On Mon, May 8, 2017 at 12:49 PM, Mikle Kolyada >> wrote: >>> Against. Do not touch things you are not working on, council >>> has >> already >>> dropped m68k s390 and sh to exp few years ago. Now we have a >>> big mess there and only, while ia64 sparc and co have slow but >>> progress and mature enough stable profiles. >> >> Obviously we should prevent big messes from happening. But it's >> a mistake that things I don't work on don't affect me -- work >> left over by lagging arch teams can affect me in many ways, in >> terms of having to keep older versions of my packages working and >> in the tree, and having to keep track of many more KEYWORDREQs >> and STABLEREQs. >> >> To me it's likely that the pace of stabilization for everyone is >> affected by the slower arches, in the sense that maintainers are >> less likely to stabilize newer versions if they see that arches >> can't keep up with previous requests. This means that even stable >> amd64 users are affected to some extent by ppc being slow to >> stabilize. > > Plus the usual mess of having to keep up with multiple large > stablereqs for stuff where we need to stabilize newer while some > arches are still two stabilizations behind. > > Not to mention when we want to stabilize a new version but the > arches still haven't even keyworded it... That ! We can all face that our latency is not good for our traction on a wider user base. Freeing ourselves from this kind of latency is energy saving and thus a positive move imho. > >> >> Cheers, >> >> Dirkjan > > -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQSqwxDKv5211qJQBiIqJBJLtlj6EwUCWRHIfQAKCRAqJBJLtlj6 EwmzAPwP2a6MgG3aE6EdSuPLjsabytT+qRskanNMJtiVsQqWpwD+NsGzWk9ff1RS 2mZYazWC5U9HBD3MzPG65jhX8Dl43jA= =h+5a -END PGP SIGNATURE-
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 5/9/17 8:33 AM, Michael Orlitzky wrote: > On 05/09/2017 04:12 AM, Rich Freeman wrote: >> On Tue, May 9, 2017 at 12:23 AM, Yury German wrote: >>> >>> we can not call for cleanup or release the GLSA, >>> waiting for a stabilization of a non-core package, while the actual >>> package has been in a tree in ~arch status for weeks or months. >> >> Why not? If an arch is considered a non-security-supported arch then >> you would just ignore it in a security bug. >> > > For example, I can't remove the ancient and vulnerable nagios-3.5.1 > because an alternative is missing keywords: > > https://bugs.gentoo.org/show_bug.cgi?id=605724 > > If I drop nagios-3.5.1 without the keywords, pnp4nagios breaks. > > Perhaps I'm missing the issue, but can you just follow the dependencies and drop keywords accordingly so the tree remains consistent. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 05/09/2017 04:12 AM, Rich Freeman wrote: > On Tue, May 9, 2017 at 12:23 AM, Yury German wrote: >> >> we can not call for cleanup or release the GLSA, >> waiting for a stabilization of a non-core package, while the actual >> package has been in a tree in ~arch status for weeks or months. > > Why not? If an arch is considered a non-security-supported arch then > you would just ignore it in a security bug. > For example, I can't remove the ancient and vulnerable nagios-3.5.1 because an alternative is missing keywords: https://bugs.gentoo.org/show_bug.cgi?id=605724 If I drop nagios-3.5.1 without the keywords, pnp4nagios breaks.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 5/9/17 8:01 AM, Thomas Deutschmann wrote: > On 2017-05-09 10:12, Rich Freeman wrote: >> Why not? If an arch is considered a non-security-supported arch >> then you would just ignore it in a security bug. > > We dropped security coverage already for ia64 and are in the process to > drop it for sparc as well. > > So how do you want to cleanup a package which is the last ebuild of the > package and still marked stabled for ia64/sparc? You cannot. If you are > lucky you would only remove a package without any rdeps. But in most > cases you are breaking the tree. > > >> Otherwise a revbump could break stage3 on those arches. > > Is this really a problem? What could happen: > > Worst case: Existing stage3 for this specific dev/exp architecture will > be very old because any attempt to refresh the stage3 image will fail > with a build error. However, the last working stage3 image won't go away > until it was replaced by a newer working one... > I maintain quite a few ppc stage3's for uclibc and musl. I would appreciate keeping ppc as is. It is still a useful arch for many devices today, eg. some high end Mikrotik routers. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 2017-05-09 10:12, Rich Freeman wrote: > Why not? If an arch is considered a non-security-supported arch > then you would just ignore it in a security bug. We dropped security coverage already for ia64 and are in the process to drop it for sparc as well. So how do you want to cleanup a package which is the last ebuild of the package and still marked stabled for ia64/sparc? You cannot. If you are lucky you would only remove a package without any rdeps. But in most cases you are breaking the tree. > Otherwise a revbump could break stage3 on those arches. Is this really a problem? What could happen: Worst case: Existing stage3 for this specific dev/exp architecture will be very old because any attempt to refresh the stage3 image will fail with a build error. However, the last working stage3 image won't go away until it was replaced by a newer working one... Also, is this different from current status? Not really: If this architecture would be capable to keep up with all the other major architectures the stage3 image would be in a current working state. Build errors would be solved in time. We wouldn't discuss dropping them. So we are only talking about architectures which have shown that they are not able to keep up. And those architectures are already lacking behind, i.e. they don't have a current stage3... -- Regards, Thomas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On Tue, May 9, 2017 at 12:23 AM, Yury German wrote: > > we can not call for cleanup or release the GLSA, > waiting for a stabilization of a non-core package, while the actual > package has been in a tree in ~arch status for weeks or months. Why not? If an arch is considered a non-security-supported arch then you would just ignore it in a security bug. -- Rich
