Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-wireless/gr-air-modes/
> Nice .. esp. coming from a QA dev ... This is an absolutely inappropriate response. Especially from a Mentee and prospective new Developer. Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] News item for Exim 4.88
On Wed, Mar 1, 2017, at 13:43 CST, Fabian Groffen wrote: > Hi, > > I'd like to push out attached news item ASAP. Please review. Looks good. Has a clear and precise structure. > Title: =mail-mta/exim-4.88 problem with chunking > Author: Fabian Groffen > Content-Type: text/plain > Posted: 2017-03-01 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: =mail-mta/exim-4.88 > > Exim maintainers discovered that version 4.88 has some serious problems > with its CHUNKING extension. To quote: > > There are various known problems which can result in messages stuck in > queues and remote servers dropping connections on larger mails. > > In Gentoo, Exim 4.88 is the only stable version available, hence all > Exim users are advised to either upgrade to an unstable 4.89 Release > Candidate, or patch the configuration as follows: Maybe not capitalizing "release candidate". > > 1) in the main configuration section, add: > > chunking_advertise_hosts = > > 2) for each SMTP transport, add: > > hosts_try_chunking = signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
On Tue, Mar 7, 2017, at 10:52 CST, Rich Freeman wrote: >> As a Bitcoin user I personally don't feel too happy with my experience >> changing without me changing USE-flags. I'm not against changing the name of >> the USE-flag, just against changing the default behavior and applying a >> bunch of patches that Core might or might not support. >> >> If you compare this to the kernel would it not make more sense to create >> something like bitcoin-knots (vanilla-sources vs gentoo-sources)? >> > > Wouldn't this mean having 2^n packages if there are multiple optional > patches like this available? No. The bitcoin client is a sercurity relevant packages where applying a gigantic, third-party patchset isn't exactly something that should be hidden behind a use flag. The comparison with the kernel sources makes a lot of sense (vanilla-sources versus gentoo-sources). I agree that a separate ebuild for the client with knots patches is a much better approach.
Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots
> The kernel doesn't give you a choice of multiple independent patch > sets. We have just a few options that bundle many patches. You can't > selectively turn them on and off. > > I'm not asking whether patching bitcoin is good or bad. > > I'm pointing out that if you want to do the same thing with separate > packages that we currently do with 3 different USE flags (that I can > see offhand), you need a total of 8 packages. If you want to make > knots an option and it isn't one already, then make that 16. We were only talking about the "ljr" use flag here, weren't we?
Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them
> manifest-hashes = SHA512 SHA3-512 WHIRLPOOL > > Your thoughts? I just want to point out that according to GLEP 63 we only require pgp signatures with at least sha-256 [1]. Further, our PGP signatures by the release team are as well either SHA-256/SHA-512. So using SHA3-512 (or whirlpool for that matter) is nice but it feels a bit like overdoing it a bit. What about simply SHA512 and calling it a day? Further, it might be a good time to finally resolve the issue with our rsync integrity for users. (What is the gain of using a secure hash algorithm in the manifests if you can simply replace the manifest with a MITM attack on the rsync update?) Best, Matthias [1] https://wiki.gentoo.org/wiki/GLEP:63#Specifications_for_GnuPG_keys signature.asc Description: PGP signature
Re: [gentoo-dev] Re: stable gcc 5.4.0 ??
On Thu, Apr 20, 2017, at 17:17 CDT, "Walter Dnes" wrote: > ...fun !NOT. If you're doing a fresh install, ***WITH A GCC5-BUILT > INSTALL CD AND STAGE 3***, then yes, go for it. But changing horses in > mid-stream can be painfull. Would it hurt to stay with 4.9.4 for the > time being, assuming that you're not using prebuilt stuff like > firefox-bin or libreoffice-bin? What would be the best way to go about > it? The technical discussion how to proceed with the new C++ abi happend two years ago. We decided to do the only sensible thing in switching to the new C++ abi. (And hopefully only see very minor issues in ABI incompatibilities later on.) It unfortunately involves rebuilding parts of your userland. > A) Would 5.4.0 be slotted separately, and 4.9.4 left as the default? > B) Add "-D_GLIBCXX_USE_CXX11_ABI=0" to CFLAGS and CXXFLAGS > C) Mask out ">sys-devel/gcc-4.99" > D) Allow "--with-default-libstdcxx-abi=gcc4-compatible" via a USE flag? (A-C) gcc-5.4.0 and gcc-4.9.4 are slotted separately. What is going to be the default is entirely up to you. If overriding the ABI via (B) is such a great idea is yours to decide. (D) will definitely not happen. > Maybe we should what many enterprises do with Windows; i.e. skip a > version and go straight to gcc-6. No. We already stabilized gcc-5. A future stabilization of gcc-6/7 won't be nearly as painful as this one. There is no reason to skip something. Best, Matthias
Re: [gentoo-dev] gcc-6.x status inquiry
> Just as a datapoint, my main dev system is ~80% stable and has been updating > with gcc-6 since beginning of february; no problems. [*] [**] Same here. The gcc-6 incompatibilities were resolved quite a while ago. Let's keyword gcc-6 and try to get gcc-7 into the tree on time. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] gcc-6.x status inquiry
> After the discussion on this thread (no one seemed to object), I went > ahead just now and added ~ keywords to sys-devel/gcc-6.3.0. Thanks a lot! Did you update any keywording bug (if one is open at all)? Best, Matthias 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
[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
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
[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"
> 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", 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"
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] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Wed, May 10, 2017, at 02:28 CDT, Martin Vaeth wrote: > I am using gcc-6 since ages and tried to run a desktop with default pie > for quite a while, but soon was forced to give up: > [...] I have pie enabled on a desktop for years. Almost all major linux distribution have pie enabled as well nowadays. https://wiki.debian.org/Hardening/PIEByDefaultTransition
[gentoo-dev] Re: New profiles for default-pie transition
> -> This would also give us some time to discuss what other changes we might > make with the transition to the new profiles. > > -> Also, this means the transition is independent of gcc release timing. > > (We just need to be careful since hardened also inherits 13.0, so the setting > must be overridden there. As far as I can see that's already done there > though.) +1 I like the idea as well.
[gentoo-dev] Re: New profiles for default-pie transition
On Wed, May 10, 2017, at 10:32 CDT, Hanno Böck wrote: > Can't we just provide a small script or bash oneliner that will rebuild > all affected packages? See mail e-mail with the updated news item. "[RFC] News item: GCC 6 defaults to USE="pie ssp", v2" Best, Matthias
Re: [gentoo-dev] Removal of rxvt
On Thu, May 11, 2017, at 10:57 CDT, "Jason A. Donenfeld" wrote: > Does anybody have any objections to me doing this? (I'll wait a week > from now before taking any actions.) There is a clear and easy upgrade path to rxvt-unicode, so please mask right away. Best, Matthias
[gentoo-dev] [PATCH] profiles: update pie use-flag masks for sys-devel/gcc
- mask pie for sys-devel/gcc unconditionally in base/ - selectively unmask pie use-flag for hardened/linux and hardened/linux/musl 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 | 4 profiles/hardened/linux/musl/package.use.mask | 4 profiles/hardened/linux/package.use.mask| 4 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/profiles/arch/amd64/package.use.mask b/profiles/arch/amd64/package.use.mask index 372ea9c..cb0fafd 100644 --- a/profiles/arch/amd64/package.use.mask +++ b/profiles/arch/amd64/package.use.mask @@ -34,10 +34,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 5adfb6a..a9d8a52 100644 --- a/profiles/arch/base/package.use.mask +++ b/profiles/arch/base/package.use.mask @@ -22,10 +22,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..68fe87a 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 (11 May 2017) +# Globally mask pie use flag. Selectively unmask on specific 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 index e2d77b0..49830f8 100644 --- a/profiles/hardened/linux/musl/amd64/package.use.mask +++ b/profiles/hardened/linux/musl/amd64/package.use.mask @@ -1,6 +1,2 @@ # 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..d66f247 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 (11 May 2017) +# masked in base, unmask for hardened/musl/ +sys-devel/gcc -pie + # See bug #504200 sys-devel/gcc sanitize diff --git a/profiles/hardened/linux/package.use.mask b/profiles/hardened/linux/package.use.mask index 4178151..4a80418 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 (11 May 2017) +# masked in base, unmask for hardened profiles +sys-devel/gcc -pie + # Ilya Tumaykin (19 Jan 2017) # Requires x11-drivers/nvidia-drivers. Needs testing first. media-video/mpv cuda -- 2.10.2
[gentoo-dev] [PATCH] profiles: update pie use-flag masks for sys-devel/gcc
Hello all, In light of the recent discussion, I will restore the status quo for the pie use-flag: masked on non-hardened profiles, unmasked and forced on hardened profiles. The next step will be to switch the pie use-flag on default profiles from masked to unmasked/forced with a profile update. Best, Matthias
Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2
> Has anyone checked 32-bit systems? "emerge -pv =sys-devel/gcc-6.3.0" > on a 2008 Core2duo 32-bit install (my GCC 6.3.0 testbed) shows "(-pie)". > I read that as the "pie" USE flag being hard-masked out. On my 64-bit > desktop, "pie" is the default. Yes, we are aware of this. Unfortunately, determining the course of action took a bit of time. Will be fixed with a small profile update within the next 24h. Best, Matthias
[gentoo-dev] [RFC] 17.0 profile update
Hi all, I will post an RFC for a profile update (and a news item) for 17.0 shortly with the following change: - unmask pie use flag for sys-devel/gcc - unconditionally force pie and ssp use flag for sys-devel/gcc Any additional profile changes for our default/linux/*/13.0 that shall be considered? Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] mingw-w64 crossdev prefix?
Hi there, On Wed, May 17, 2017, at 17:25 CDT, Marty Plummer wrote: > Greetings, > > So, I'm a relatively new gentoo user (as of 2016-12) coming from arch, > and one thing I've noticed is the relative difficulty of setting up a > mingw-w64 cross-compile toolchain and libraries. > > I'm considering the idea of setting up a sort of prefix specifically > with the intent of being used on a 'normal' gentoo system with the sole > purpose of creating 'normal' windows binaries; does anyone have > suggestions/objections about the idea? > > As it currently stands I have to use an archlinux chroot to do my > cross-compiling, and I'd really enjoy to be able to do this sort of > thing without depending on an auxiliary distro. You can find some information on the wiki [1] (warning: I might be a bit outdated). But anyway, just check it for you (I haven't set up a cross compilation toolchain for windows for the last ~7 years): From a plain amd64 stage-3 setting up a mingw-264 environment via: # emerge crossdev # crossdev [...] -t x86_64-w64-mingw32 still works with a minor complication [2]. Please verify that this works and open a bug report for the libsanitizer issue mentioning the workaround [2,3]. After that you end up with a cross-compiler toolchain x86_64-w64-mingw32-* and necessary runtime somewhere in /usr/x86_64-w64-mingw32. You can also use $ x86_64-w64-mingw32-emerge to cross compile libraries/packages for mingw. Keep in mind that a cross compilation toolchain is a bit of a rocky journey. You might have to pin certain versions of libraries/programs, and or manually patch some stuff. Best, Matthias [1] https://wiki.gentoo.org/wiki/Mingw [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the cross-x86_64-w64-mingw32/gcc package. [3] https://bugs.gentoo.org/buglist.cgi?quicksearch=mingw&list_id=3536150 signature.asc Description: PGP signature
Re: [gentoo-dev] mingw-w64 crossdev prefix?
On Wed, May 17, 2017, at 22:53 CDT, Alon Bar-Lev wrote: > On 18 May 2017 at 06:46, Matthias Maier wrote: >> [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set >> EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the >> cross-x86_64-w64-mingw32/gcc package. > > Hi, > You should use the USE flags and not apply such workarounds, for example: > USE="-sanitizer" crossdev ... Yes, correct. It should read USE="-sanitize" though. Best, Matthias
Re: [gentoo-dev] Fixing elasticsearch maintainer
> Were this an actual office, this would be better solved with a "ok, > we've clearly been working too hard this week, everyone stop, ITS PUB > O-CLOCK!" This is most definitely true for almost everything going on for the last days in Gentoo. signature.asc Description: PGP signature
Re: [gentoo-dev] toolchain meeting agenda for today 19:00 UTC #gentoo-toolchain
On Fri, May 26, 2017, at 13:07 CDT, Alexis Ballier wrote: > On Sat, 20 May 2017 19:38:01 +0200 > "Andreas K. Huettel" wrote: >> - Globally setting -std=c++14 in upcoming 17.0 profiles > > A bit late to the party, but what was the outcome of the meeting, esp. > this part ? > > I'm not sure if default CXXFLAGS would make such a difference since > most people would override them. Exactly. Setting this in CXXFLAGS is not a great idea. Forcing via SPEC file is equally hacky. > OTOH, masking default to gnu++14 in a better way than with profiles and since I > think one of the points of the new profiles is to force default-pie, > it'll also avoid people using gcc5- that would not build pie by > default and have issues when switching to a gcc6+ This is exactly what is planned :-) Best, Matthias
[gentoo-dev] Last rites: app-text/7plus
# Matthias Maier (06 Jun 2017) # Dead upstream, unmaintained, no homepage, no SRC_URI, x86-only, does not # compile, bug #620964. Removal in 30 days. app-text/7plus
Re: [gentoo-dev] New 17.0 release profiles
On Wed, Jun 7, 2017, at 15:44 CDT, "Andreas K. Huettel" wrote: > [...] > Obviously we're now in the test phase and the official switchover > recommendation > can only happen after gcc-6 is stable. This is also why I'm not touching > profiles.desc yet. > > Patches following for review (only amd64 for now). All patches ACKed. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] New 17.0 release profiles
On Sun, Jun 11, 2017, at 13:39 CDT, "Walter Dnes" wrote: > 1) Should I be doing bug reports on the Gentoo bugzilla or upstream? Please check [1] and if not already reported open a bug report blocking [1] on our bugzilla. Best, Matthias [1] https://bugs.gentoo.org/show_bug.cgi?id=gcc-6
[gentoo-dev] [PATCH 3/5] toolchain-glibc.eclass: Always enable stack guard randomization (bug #621742).
From: Arfrever Frehtes Taifersar Arahesis
Signed-off-by: Matthias Maier
---
eclass/toolchain-glibc.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass
index eba829cd2f..5be31eb193 100644
--- a/eclass/toolchain-glibc.eclass
+++ b/eclass/toolchain-glibc.eclass
@@ -780,7 +780,7 @@ glibc_do_configure() {
[[ -d ports ]] && addons+=",ports"
popd > /dev/null
- myconf+=( $(use_enable hardened stackguard-randomization) )
+ myconf+=( --enable-stackguard-randomization )
if has_version '
[gentoo-dev] [PATCH 4/5] eclass/toolchain-glibc.eclass: use tc-enables-pie instead of gcc-specs-pie
---
eclass/toolchain-glibc.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass
index 5be31eb193..270c9cdac7 100644
--- a/eclass/toolchain-glibc.eclass
+++ b/eclass/toolchain-glibc.eclass
@@ -266,7 +266,7 @@ setup_flags() {
tc-enables-ssp && append-flags $(test-flags
-fno-stack-protector)
fi
- if use hardened && gcc-specs-pie ; then
+ if use hardened && tc-enables-pie ; then
# Force PIC macro definition for all compilations since they're
all
# either -fPIC or -fPIE with the default-PIE compiler.
append-cppflags -DPIC
@@ -535,7 +535,7 @@ toolchain-glibc_pkg_pretend() {
ewarn "hypervisor, which is probably not what you want."
fi
- use hardened && ! gcc-specs-pie && \
+ use hardened && ! tc-enables-pie && \
ewarn "PIE hardening not applied, as your compiler doesn't
default to PIE"
# Make sure host system is up to date #394453
--
2.13.0
[gentoo-dev] [PATCH 1/5] toolchain-funcs.eclass: Add functions for detection of PIE / SSP in way compatible with GCC >=6.
From: Arfrever Frehtes Taifersar Arahesis
Newly added tc-enables-pie(), tc-enables-ssp(), tc-enables-ssp-strong()
and tc-enables-ssp-all() check macros instead of specs.
This solution also works with older GCC and with Clang.
Signed-off-by: Matthias Maier
---
eclass/toolchain-funcs.eclass | 71 +++
1 file changed, 71 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index a0c359a950..3658c40518 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -792,6 +792,77 @@ gcc-specs-stack-check() {
}
+# @FUNCTION: tc-enables-pie
+# @RETURN: Truth if the current compiler generates position-independent code
(PIC) which can be linked into executables
+# @DESCRIPTION:
+# Return truth if the current compiler generates position-independent code
(PIC)
+# which can be linked into executables.
+tc-enables-pie() {
+ $($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2> /dev/null
+ #if defined(__PIE__)
+ true
+ #else
+ false
+ #endif
+ EOF
+ )
+}
+
+# @FUNCTION: tc-enables-ssp
+# @RETURN: Truth if the current compiler enables stack smashing protection
(SSP) on at least minimal level
+# @DESCRIPTION:
+# Return truth if the current compiler enables stack smashing protection (SSP)
+# on level corresponding to any of the following options:
+# -fstack-protector
+# -fstack-protector-strong
+# -fstack-protector-all
+tc-enables-ssp() {
+ $($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2> /dev/null
+ #if defined(__SSP__) || defined(__SSP_STRONG__) ||
defined(__SSP_ALL__)
+ true
+ #else
+ false
+ #endif
+ EOF
+ )
+}
+
+# @FUNCTION: tc-enables-ssp-strong
+# @RETURN: Truth if the current compiler enables stack smashing protection
(SSP) on at least middle level
+# @DESCRIPTION:
+# Return truth if the current compiler enables stack smashing protection (SSP)
+# on level corresponding to any of the following options:
+# -fstack-protector-strong
+# -fstack-protector-all
+tc-enables-ssp-strong() {
+ $($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2> /dev/null
+ #if defined(__SSP_STRONG__) || defined(__SSP_ALL__)
+ true
+ #else
+ false
+ #endif
+ EOF
+ )
+}
+
+# @FUNCTION: tc-enables-ssp-all
+# @RETURN: Truth if the current compiler enables stack smashing protection
(SSP) on maximal level
+# @DESCRIPTION:
+# Return truth if the current compiler enables stack smashing protection (SSP)
+# on level corresponding to any of the following options:
+# -fstack-protector-all
+tc-enables-ssp-all() {
+ $($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2> /dev/null
+ #if defined(__SSP_ALL__)
+ true
+ #else
+ false
+ #endif
+ EOF
+ )
+}
+
+
# @FUNCTION: gen_usr_ldscript
# @USAGE: [-a]
# @DESCRIPTION:
--
2.13.0
[gentoo-dev] [PATCH 5/5] eclass/toolchain-glibc.eclass: skip pie check for gcc-6 or newer
For gcc-6 and newer the old logic in the toolchain-glibc eclass:
if use hardened && gcc-specs-pie ; then
append-cppflags -DPIC
else
filter-flags -fPIE
fi
is obsolete. Simply disable the check.
---
eclass/toolchain-glibc.eclass | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass
index 270c9cdac7..32c1307c3a 100644
--- a/eclass/toolchain-glibc.eclass
+++ b/eclass/toolchain-glibc.eclass
@@ -266,15 +266,21 @@ setup_flags() {
tc-enables-ssp && append-flags $(test-flags
-fno-stack-protector)
fi
- if use hardened && tc-enables-pie ; then
- # Force PIC macro definition for all compilations since they're
all
- # either -fPIC or -fPIE with the default-PIE compiler.
- append-cppflags -DPIC
- else
- # Don't build -fPIE without the default-PIE compiler and the
- # hardened-pie patch
- filter-flags -fPIE
- fi
+ if [[ $(gcc-major-version) -lt 6 ]]; then
+ # Starting with gcc-6 (and fully upstreamed pie patches) we
control
+ # default enabled/disabled pie via use flags. So nothing to do
+ # here. #618160
+
+ if use hardened && tc-enables-pie ; then
+ # Force PIC macro definition for all compilations since
they're all
+ # either -fPIC or -fPIE with the default-PIE compiler.
+ append-cppflags -DPIC
+ else
+ # Don't build -fPIE without the default-PIE compiler
and the
+ # hardened-pie patch
+ filter-flags -fPIE
+ fi
+ fi
}
want_nptl() {
--
2.13.0
[gentoo-dev] [PATCH 2/5] toolchain-glibc.eclass: Build most of >=sys-libs/glibc-2.25 with -fstack-protector-all (bug #609048).
From: Arfrever Frehtes Taifersar Arahesis
configure accepts --enable-stack-protector=... option which results
in build system passing appropriate -fstack-protector... option
when possible.
Signed-off-by: Matthias Maier
---
eclass/toolchain-glibc.eclass | 17 ++---
sys-libs/glibc/glibc-2.23-r3.ebuild | 5 -
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass
index ef9d91acae..eba829cd2f 100644
--- a/eclass/toolchain-glibc.eclass
+++ b/eclass/toolchain-glibc.eclass
@@ -254,7 +254,7 @@ setup_flags() {
# this flag for us, so no need to do it manually.
version_is_at_least 2.16 ${PV} || append-cppflags -U_FORTIFY_SOURCE
- # building glibc with SSP is fraught with difficulty, especially
+ # building glibc <2.25 with SSP is fraught with difficulty, especially
# due to __stack_chk_fail_local which would mean significant changes
# to the glibc build process. See bug #94325 #293721
# Note we have to handle both user-given CFLAGS and gcc defaults via
@@ -262,7 +262,9 @@ setup_flags() {
# added before user flags, and we can't just filter-flags because
# _filter_hardened doesn't support globs.
filter-flags -fstack-protector*
- gcc-specs-ssp && append-flags $(test-flags -fno-stack-protector)
+ if ! version_is_at_least 2.25 ; then
+ tc-enables-ssp && append-flags $(test-flags
-fno-stack-protector)
+ fi
if use hardened && gcc-specs-pie ; then
# Force PIC macro definition for all compilations since they're
all
@@ -783,6 +785,10 @@ glibc_do_configure() {
myconf+=( --enable-old-ssp-compat )
fi
+ if version_is_at_least 2.25 ; then
+ myconf+=( --enable-stack-protector=all )
+ fi
+
[[ $(tc-is-softfloat) == "yes" ]] && myconf+=( --without-fp )
if [[ $1 == "linuxthreads" ]] ; then
@@ -941,7 +947,7 @@ toolchain-glibc_headers_configure() {
libc_cv_mlong_double_128ibm=yes
libc_cv_ppc_machine=yes
libc_cv_ppc_rel16=yes
- libc_cv_predef_{fortify_source,stack_protector}=no
+ libc_cv_predef_fortify_source=no
libc_cv_visibility_attribute=yes
libc_cv_z_combreloc=yes
libc_cv_z_execstack=yes
@@ -955,6 +961,11 @@ toolchain-glibc_headers_configure() {
ac_cv_lib_audit_audit_log_user_avc_message=no
ac_cv_lib_cap_cap_init=no
)
+ if ! version_is_at_least 2.25 ; then
+ vars+=(
+ libc_cv_predef_stack_protector=no
+ )
+ fi
einfo "Forcing cached settings:"
for v in "${vars[@]}" ; do
einfo " ${v}"
diff --git a/sys-libs/glibc/glibc-2.23-r3.ebuild
b/sys-libs/glibc/glibc-2.23-r3.ebuild
index 410b3485c1..1109618f52 100644
--- a/sys-libs/glibc/glibc-2.23-r3.ebuild
+++ b/sys-libs/glibc/glibc-2.23-r3.ebuild
@@ -137,11 +137,6 @@ src_prepare() {
-e '/^CFLAGS-backtrace.c/ iCPPFLAGS-chk_fail.c
= -DSSP_SMASH_DUMPS_CORE' \
debug/Makefile || die
fi
-
- # Build various bits with ssp-all
- sed -i \
- -e 's:-fstack-protector$:-fstack-protector-all:' \
- */Makefile || die
fi
case $(gcc-fullversion) in
--
2.13.0
[gentoo-dev] [RFC] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates
Hello all, this is a series of patches against the toolchian-funcs and toolchain-glibc eclasses, most notably - introducing new tc-enables-pie(), tc-enables-ssp(), tc-enables-ssp-strong() and tc-enables-ssp-all() functions in toolchain-funcs compatible with gcc >=6 and clang as a replacement for the old gcc-specs-* functions (patch 1). After this patchset is merged, I will follow up with fixes to a (small) number of ebuilds and eclasses utilizing the old gcc-specs-* functions so that we can deprecate those relatively quickly. - updates toolchain-glibc to use said new variants and removing obsolete configuration logic for gcc >=6. [1] - enables a number of (upstreamed) security features for glibc-2.25 per default. [2,3] Best, Matthias [1] https://bugs.gentoo.org/show_bug.cgi?id=618160 [2] https://bugs.gentoo.org/show_bug.cgi?id=621742 [3] https://bugs.gentoo.org/show_bug.cgi?id=609048
[gentoo-dev] Re: [RFC] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates
On Wed, Jun 14, 2017, at 18:15 CDT, Matthias Maier wrote: > [...] and of course, many thanks to Arfrever for patches and his kind support! Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/5] toolchain-funcs.eclass: Add functions for detection of PIE / SSP in way compatible with GCC >=6.
>> +# @FUNCTION: tc-enables-pie
>> +# @RETURN: Truth if the current compiler generates position-independent
>> code (PIC) which can be linked into executables
>> +# @DESCRIPTION:
>> +# Return truth if the current compiler generates position-independent code
>> (PIC)
>> +# which can be linked into executables.
>> +tc-enables-pie() {
>> +$($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2> /dev/null
>> +#if defined(__PIE__)
>> +true
>> +#else
>> +false
>> +#endif
>> +EOF
>> +)
>
> Looks quite horrible. Why can't you just compare the output against
> a value instead of randomly executing it?
Because we have to execute the compiler anyway and this is the quickest
way of getting the answer we need. Further, piping an unfiltered output
(e.g. -E -dM -x c) through grep is by no means prettier.
Best,
Matthias
signature.asc
Description: PGP signature
[gentoo-dev] [RFC v2] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates
OK. This is a slightly modified version that uses string comparison to form the result. Best, Matthias
[gentoo-dev] [PATCH 01/05] toolchain-funcs.eclass: Add functions for detection of PIE / SSP in way compatible with GCC >=6.
From: Arfrever Frehtes Taifersar Arahesis
Newly added tc-enables-pie(), tc-enables-ssp(), tc-enables-ssp-strong()
and tc-enables-ssp-all() check macros instead of specs.
This solution also works with older GCC and with Clang.
Signed-off-by: Matthias Maier
---
eclass/toolchain-funcs.eclass | 67 +++
1 file changed, 67 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index a0c359a950..8cfe329a96 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -792,6 +792,73 @@ gcc-specs-stack-check() {
}
+# @FUNCTION: tc-enables-pie
+# @RETURN: Truth if the current compiler generates position-independent code
(PIC) which can be linked into executables
+# @DESCRIPTION:
+# Return truth if the current compiler generates position-independent code
(PIC)
+# which can be linked into executables.
+tc-enables-pie() {
+ local ret="$($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2>
/dev/null
+ #if defined(__PIE__)
+ true
+ #endif
+ EOF
+ )"
+ [ "${ret}" = "true" ]
+}
+
+# @FUNCTION: tc-enables-ssp
+# @RETURN: Truth if the current compiler enables stack smashing protection
(SSP) on at least minimal level
+# @DESCRIPTION:
+# Return truth if the current compiler enables stack smashing protection (SSP)
+# on level corresponding to any of the following options:
+# -fstack-protector
+# -fstack-protector-strong
+# -fstack-protector-all
+tc-enables-ssp() {
+ local ret="$($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2>
/dev/null
+ #if defined(__SSP__) || defined(__SSP_STRONG__) ||
defined(__SSP_ALL__)
+ true
+ #endif
+ EOF
+ )"
+ [ "${ret}" = "true" ]
+}
+
+# @FUNCTION: tc-enables-ssp-strong
+# @RETURN: Truth if the current compiler enables stack smashing protection
(SSP) on at least middle level
+# @DESCRIPTION:
+# Return truth if the current compiler enables stack smashing protection (SSP)
+# on level corresponding to any of the following options:
+# -fstack-protector-strong
+# -fstack-protector-all
+tc-enables-ssp-strong() {
+ local ret="$($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2>
/dev/null
+ #if defined(__SSP_STRONG__) || defined(__SSP_ALL__)
+ true
+ #endif
+ EOF
+ )"
+ [ "${ret}" = "true" ]
+}
+
+# @FUNCTION: tc-enables-ssp-all
+# @RETURN: Truth if the current compiler enables stack smashing protection
(SSP) on maximal level
+# @DESCRIPTION:
+# Return truth if the current compiler enables stack smashing protection (SSP)
+# on level corresponding to any of the following options:
+# -fstack-protector-all
+tc-enables-ssp-all() {
+ local ret="$($(tc-getCC) ${CPPFLAGS} ${CFLAGS} -E -P - <<-EOF 2>
/dev/null
+ #if defined(__SSP_ALL__)
+ true
+ #endif
+ EOF
+ )"
+ [ "${ret}" = "true" ]
+}
+
+
# @FUNCTION: gen_usr_ldscript
# @USAGE: [-a]
# @DESCRIPTION:
--
2.13.0
Re: [gentoo-dev] [PATCH 01/05] toolchain-funcs.eclass: Add functions for detection of PIE / SSP in way compatible with GCC >=6.
> [[ ${ret} == true ]]
>
> Would be the canonical bash way.
Updated.
Re: [gentoo-dev] Hardening a default profile
Hi Michael, On Sun, Jun 11, 2017, at 16:39 CDT, Michael Brinkman wrote: > So I was just wondering if ~arch is ready for more secure defaults on > the 17.0 profiles in the linker flags. There are several > distributions which ship RELRO by default and I am not aware of any > performance issues regarding this. We (i.e. toolchain) are in the process of enabling quite a number of security hardening features on default profiles. In particular - (force) +pie +ssp for gcc-6 onwards in 17.0 profiles - enable additional hardening features for glibc-2.25 and newer (will be merged soon). But, yes. Updated linker flags are a very good point. I have put updated linker flags on the toolchain meeting agenda for next week. The hardened profiles (even used without a hardened kernel) will serve an important difference in the future. While we try to enable as many security features on default profiles as possible, we have to compromise between security features and not introducing regressions. The hardened profiles will thus have more aggressive security features enabled for the foreseeable future (at the cost of more potential breakage). Best, Matthias
Re: [gentoo-dev] Hardening a default profile
> there should be a way of turning these off systematically. the > advantage of the current hardened gcc specs is that one can switch > between them using gcc-config. if these are forced on for the default > profile then there will be no easy way to systematically turn them off. No - there won't be an easy way for systematically turning off SSP and PIE in 17.0 profiles [1,2]. The hardened toolchain with its different gcc profiles came from a time where SSP and PIE were relatively new security features and a certain amount of fine-grained control was needed. Further, at that time we were talking about external patches against gcc. Nowadays everything is upstreamed and (almost) no patches to gcc for hardened profiles are applied any more. Given the fact that all major linux distributions are following the path of improved default hardening features (see for example [1]) and that we have been using ssp/pie in hardened profiles for years now the purpose of fine-grained control over ssp/pie is also highly questionable. The consensus at the moment is that PIE and SSP (as well as stricter linker flags) will soon be standard (or, actually *are* already standard) compilation options. A per-package override (if absoluetely needed) is fine - and, in fact, already in place everywhere where needed. Thus, we should go with the time and simply force these well tested hardening features on platforms that support it. Best, Matthias [1] for amd64/x86 and well supported profiles [2] there is always the possibility to override forced use flags [1] https://wiki.debian.org/Hardening/PIEByDefaultTransition signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates
On Wed, Jun 14, 2017, at 18:15 CDT, Matthias Maier wrote: > Hello all, > > this is a series of patches against the toolchian-funcs and toolchain-glibc > eclasses, most notably > > - introducing new tc-enables-pie(), tc-enables-ssp(), >tc-enables-ssp-strong() and tc-enables-ssp-all() functions in >toolchain-funcs compatible with gcc >=6 and clang as a replacement for >the old gcc-specs-* functions (patch 1). > >After this patchset is merged, I will follow up with fixes to a (small) >number of ebuilds and eclasses utilizing the old gcc-specs-* functions >so that we can deprecate those relatively quickly. > > - updates toolchain-glibc to use said new variants and removing obsolete >configuration logic for gcc >=6. [1] > > - enables a number of (upstreamed) security features for glibc-2.25 per >default. [2,3] Pushed. Best, Matthias
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: We only support little-endian Alpha
On Sat, Jul 1, 2017, at 03:55 CDT, James Le Cuirot wrote:
> Funny that no one noticed this for 10 years. :) Thanks to klausman for
> clearing this up.
> ---
> eclass/toolchain-funcs.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 121db46e62b5..777fce905f3e 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -572,7 +572,7 @@ tc-endian() {
> case ${host} in
> aarch64*be) echo big;;
> aarch64)echo little;;
> - alpha*) echo big;;
> + alpha*) echo little;;
> arm*b*) echo big;;
> arm*) echo little;;
> cris*) echo little;;
Acked.
Matthias
Re: [gentoo-dev] [PATCH] toolchain.eclass: Remove kludge that blocks gcc-6+ on sys-libs/uclibc-ng systems
++
On Sun, Jul 30, 2017, at 02:46 CDT, Sergei Trofimovich
wrote:
> On Sat, 29 Jul 2017 19:12:23 -0400
> Joshua Kinard wrote:
>
>> The following kludge is present in toolchain.eclass, in
>> toolchain_pkg_pretend():
>>
>> [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
>> die "Sorry, this version does not support uClibc"
>>
>> The below patch removes this. I've been running a gcc-6-built,
>> sys-libs/uclibc-ng in chroot for some time now, have completed several
>> catalyst runs, and am at the tail end of a fresh install of a
>> sys-libs/uclibc-ng userland on actual MIPS hardware.
>>
>> Signed-off-by: Joshua Kinard
Signed-off-by: Matthias Maier
>> ---
>> eclass/toolchain.eclass |3 ---
>> 1 file changed, 3 deletions(-)
>>
>> --- a/eclass/toolchain.eclass.orig 2017-07-29 19:06:30.894211203 -0400
>> +++ b/eclass/toolchain.eclass2017-07-29 19:06:40.514211133 -0400
>> @@ -375,9 +375,6 @@ toolchain_pkg_pretend() {
>> "in your make.conf if you want to use this version."
>> fi
>>
>> -[[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
>> -die "Sorry, this version does not support uClibc"
>> -
>> if ! use_if_iuse cxx ; then
>> use_if_iuse go && ewarn 'Go requires a C++ compiler, disabled
>> due to USE="-cxx"'
>> use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ compiler,
>> disabled due to USE="-cxx"'
Best,
Matthias
[gentoo-dev] Re: toolchain team lead election and team meeting
On Wed, Aug 9, 2017, at 15:43 CDT, "Andreas K. Huettel" wrote: > Hey there, > > it's time we do a proper lead election and have a toolchain meeting again. > > So, here's the plan: > > 1) team lead election: > * Nominations from now until August 18, by e-mailing to the toolchain alias > * Voting (Helios) August 19-25 > I'm volunteering as organizer, since I won't run myself. Sounds good. > 2) team meeting: > how about Saturday 26 August, 19:00 UTC ?! Works for me! Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB
On Sun, Dec 17, 2017, at 07:21 CST, Michał Górny wrote:
> Hello, everyone.
>
> It's my pleasure to announce that with a majority vote the QA team has
> accepted a new policy. The accepted wording is:
>
> Total size of 'files' subdirectory of a package should not be larger
> than 32 KiB. If the package needs more auxiliary files, they should
> be put into SRC_URI e.g. via tarballs.
> Rationale
> =
>
> At this moment, syncing the repository implies fetching 'files'
> directories of all packages, even though the relevant files are used
> only when a ebuild referencing them is being built. This means that our
> users fetch many files that they will never use -- either because they
> don't need the package in question, or because the file belongs
> to an old version.
>
> For example, 'du -h app-shells/bash/files' states 232K while only three
> of those files are used by the newest version, and everything else are
> patches for old versions. And in case of bash, we're keeping those
> versions pretty much 'forever'.
>
> The new policy mostly targets large patchsets and files relevant to old
> package versions. By removing them from the repository, we're hoping to
> reduce the growth of its size a bit and reduce the amount of data
> transferred via rsync.
Assuming that only the true byte size of files are relevant and summing
up via
du -sb */*/files | awk '{sum+=$1} END {print sum}'
Currently gives roughly 29MB of data in the files directory. (For
comparison, the complete portage tree is roughly 219MB.)
Removing all "32kb offenders" results in 26MB for all files
directories. More aggressively, removing all "20kb offenders" results in
22MB.
I hardly doubt that these (at most) 10MB of saving we're talking about
are really relevant for rsync or git (with clone-depths 1). I haven't
estimated the growth of the repository, though.
Best,
Matthias
Re: [gentoo-dev] Packages up for grabs
On Tue, Dec 12, 2017, at 15:46 CST, Daniel Campbell wrote: > The following packages are in need of a maintainer: > > dev-util/astyle I will take over this one. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On Thu, Jan 11, 2018, at 11:34 CST, Rich Freeman wrote: > It is kind of hard to get new people interested in fixing bugs when > half the traffic is complaining because the people doing the work > aren't doing it in a way that makes the people not doing the work feel > important. ++
Re: [gentoo-dev] Its time to mask sys-libs/uclibc
On Fri, Feb 23, 2018, at 10:01 CST, "Anthony G. Basile" wrote: > [...] > I'm not even sure a news item is needed here. What do people think? If > you think so, who do I even direct it at? If there is no action needed on user side and an upgrade and migration from uclibc to uclibc-ng happens automatically, I'd say no news item is necessary. Further, seeing "uclibc-ng" being emerged and "uclibc" unmerged should be pretty self explanatory. Best, Matthias
[gentoo-dev] Council meeting 2018-03-11
Hi all, the next Council meeting will be on Sunday 2018-03-11, 18:00 UTC in the #gentoo-council channel on Freenode. We have a fairly short agenda this time: 1. Roll call 2. Bugs with council involvement: - GLEP 68 [1] https://bugs.gentoo.org/649740 [2] https://archives.gentoo.org/gentoo-dev/message/ae4f89a9697f623df500b7d44d66c215 - GLEP 74 [3] https://bugs.gentoo.org/648638 [4] https://archives.gentoo.org/gentoo-dev/message/3deff3aec43f9e702dbc53838df32168 [5] https://gitweb.gentoo.org/data/glep.git/commit/?id=30fef42d2186d4742c80526a748c40adc5c8953c - Joint venture to deal with copyright issues [6] https://bugs.gentoo.org/642072 - GLEP 14 [7] https://bugs.gentoo.org/637328 3. Open floor Best, Matthias signature.asc Description: PGP signature
[gentoo-dev] Re: [PATCH] app-emulation/libvirt: Update live ebuild, ebuild maintenance
On Fri, Mar 23, 2018, at 08:48 CDT, Michal Privoznik wrote: > [...] Applied. Thanks! Matthias
[gentoo-dev] Re: [PATCH] app-emulation/virt-manager-9999: Drop python2 support
Applied. Thanks!
On Sat, Mar 24, 2018, at 05:02 CDT, Michal Privoznik
wrote:
> With upstream commit of bd891eb380cdf771f0296a39193614a10749088b
> virt-manager is strictly python3 only. Update the ebuild to
> follow this change.
>
> Signed-off-by: Michal Privoznik
>
> [...]
commit 0e6753f646fc079ae499aaef034d1a7bdeb94467 (HEAD -> master, origin/master,
origin/HEAD)
Author: Michal Privoznik
Date: Sat Mar 24 11:02:15 2018 +0100
app-emulation/virt-manager-: Drop python2 support
With upstream commit of bd891eb380cdf771f0296a39193614a10749088b
virt-manager is strictly python3 only. Update the ebuild to
follow this change.
Closes: https://bugs.gentoo.org/650790
Closes: https://bugs.gentoo.org/647376
Signed-off-by: Michal Privoznik
Signed-off-by: Matthias Maier
Re: [gentoo-dev] Trustless Infrastructure
On Mon, Jul 2, 2018, at 12:01 CDT, "Jason A. Donenfeld" wrote: > Aren't git signatures done over the full commit objects? Meaning you'd > need the entire tree of metadata and thus all commits in order to > verify? Or do you see some clever opportunity for extracting just > enough metadata that you could actually have a file-based, rather than > commit-based, verification? Git signatures are over the full commit object - and the commit contains a hash of the root of the full repository tree. Git internally only stores tree snapshots (and not differences). So all you need is exactly one signed commit to verify that - this is the full repository tree the developer saw at the time of the commit - this is the full history the developer saw at the time of the commit Meaning, our current tree signing practice already ensures that - history cannot be tampered with - allows for a complete audit log (in buzzspeak, we're doing blockchain verification *SCNR*) Best, Matthias
Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?
On Tue, Jul 3, 2018, at 11:22 CDT, Matt Turner wrote: > I'd be happy to switch if the space requirements were similar. $ git clone --depth=1 https://github.com/gentoo-mirror/gentoo occupies 662M on my machine (just tested). With full history (i.e. without --depth=1) I am at 1.1GB. Best, Matthias signature.asc Description: PGP signature
[gentoo-dev] Last rites: sci-calculators/qalculate-{bases|currency|units}
# Matthias Maier (3 Aug 2016) # Masked for removal in 30 days. Obsolete packages that are now part of # sci-libs/libqalculate and/or sci-calculators/qalculate-gtk sci-calculators/qalculate-bases sci-calculators/qalculate-currency sci-calculators/qalculate-units signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: /etc/init.d/modules loading modules defined in files
On Tue, Aug 16, 2016, at 18:20 CDT, William Hubbs wrote: > All, > > I have received a request to implement a feature in OpenRC to allow > multiple software packages to drop files in a directory, /etc/modules.d > for example, which would define modules the /etc/init.d/modules script > would load. What about /etc/modules-load.d containing various files that list one module to load per line? With this, OpenRC's behavior would be compatible with systemd-modules-load [1]. Best, Matthias [1] To quote systemd's manpage: NAME modules-load.d - Configure kernel modules to load at boot SYNOPSIS /etc/modules-load.d/*.conf /run/modules-load.d/*.conf /usr/lib/modules-load.d/*.conf DESCRIPTION systemd-modules-load.service(8) reads files from the above directories which contain kernel modules to load during boot in a static list. Each configuration file is named in the style of /etc/modules-load.d/program.conf. Note that it is usually a better idea to rely on the automatic module loading by PCI IDs, USB IDs, DMI IDs or similar triggers encoded in the kernel modules themselves instead of static configuration like this. In fact, most modern kernel modules are prepared for automatic loading already. CONFIGURATION FORMAT The configuration files should simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored. signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: /etc/init.d/modules loading modules defined in files
On Tue, Aug 16, 2016, at 18:49 CDT, Matthias Maier wrote: > On Tue, Aug 16, 2016, at 18:20 CDT, William Hubbs wrote: > >> All, >> >> I have received a request to implement a feature in OpenRC to allow >> multiple software packages to drop files in a directory, /etc/modules.d >> for example, which would define modules the /etc/init.d/modules script >> would load. One more point, /etc/modules.d was used back in the old update-modules times. So, maybe we should avoid the directory due to historic reasons [1]. Best, Matthias [1] I had /etc/modules.d and /etc/modules.conf lingering around now for more than 3 years... signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS
On Sun, Sep 25, 2016, at 16:08 CDT, Michał Górny wrote: > Hi, > > I'd like to introduce a new USE_EXPAND for LLVM & clang. It'd be named > LLVM_TARGETS, and it's going to replace the current solution based on > USE=multitarget & VIDEO_CARDS=radeon. > > In the old system, the following rules applied: > > - host (implicitly figured out by LLVM) and BPF targets were always > built, > > - VIDEO_CARDS=radeon enabled additional R600 target, > > - USE=multitarget enabled all targets. > > In the new system, LLVM_TARGETS explicitly controls *all* targets > built. To avoid dependency hell, the host target is package.use.forced > in specific arch profiles. Additionally, the BPF target is on by > default. +1 We also avoid a very subtle abuse of the VIDEO_CARDS use expand with it. So far, I had to explain a surprising amount of times that VIDEO_CARDS=radeon for llvm does *not* mean that llvm magically uses the GPU for compiling. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: the demise of grub:0
On Mon, Oct 3, 2016, at 16:59 CDT, William Hubbs wrote: > All, > > I want to look into removing grub:0 from the tree; here are my thoughts > on why it should go. > > - the handbook doesn't document grub:0; we officially only support > grub:2. > > - Removing grub:0 from the tree doesn't stop you from using it. If people > really want it I will place it in the graveyard overlay. > > - grub:0 is dead upstream. They have not done any work on it in years. +1 Yes, let's lastrite it and put it into ::graveyard as well. People that insist on using it can find it there then. > - The only real problem with grub:2 has to do with pperception. Yes, > their documentation has a strong preference toward using their > configuration script (grub-mkconfig) to generate your grub.cfg, but > this is not required. On modern systems with UEFI and efi payloads we have the following alternatives as well: sys-boot/refind sys-boot/systemd-boot (aka gummiboot) (alternatively sys-apps/systemd) - direct efi stub loading I don't see any compelling argument that grub:0 would be the only alternative if one tries to avoid grub:2. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?
> I think you could make an argument that voluntarily placing that > header on your work is an assignment of copyright. I very much doubt that. > Personally I'd rather move to an explicit system. Yes! And I see absolutely no harm in explicitly annotating the actual copyright in gentoo ebuilds. Best, Matthias
Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?
> Well, depending on how this is done the main harm is in administrative > overhead, unless this is automated, or we use a simplistic approach of > just continuing to append names. The pragmatic approach would be to remove the policy and associated repoman warning and allow contributors to use an alternative copyright line instead. We could provide a "I don't care" skeleton of the form: # Copyright 1999-2016 Gentoo developers and contributors # Distributed under the terms of the GNU General Public License v2 # Author(s): John Doe , ... (with, or without the Author(s) line) A modified repoman check could enforce a layout of the form # Copyright - [...] # Distributed under the terms of the GNU General Public License v2 [# Author(s): [...]] We don't have to modify all existing ebuilds to do that. Alternatively, we can simply change all headers to # Copyright 1999-2016 Gentoo developers and contributors (if the Gentoo Foundation is OK with the few ebuilds were it holds a copyright ^^). Best, Matthias
Re: [gentoo-dev] newsitem: important fstab update
> please make also clear that UUID=... syntax will still work, one for all I > don't like labels and will gladly continu to use this format: > UUID=debd07a3-fbbc-4433-89db-29e6f91d25e4 /boot ext2 noauto,noatime 1 2 +1 Slightly revising the example given later on by simply showing one example for LABELs and one for UUIDs should be enough. Best, Matthias
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
> Therefore, we may indeed consider taking the DCO from the Linux source > tree which is distributed under the GPL-2 I highly doubt that the DCO in the readme is licensed under GPL-2. There is no readme/header, or other indicator stating this. Not everything in the linux repository falls under GPL-2. Thus, we simply blatantly violate the distribution terms: »Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.« Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
On Thu, Oct 27, 2016, at 09:11 CDT, Rich Freeman wrote: > I'd think that the title of a legal document falls more under > trademark law than copyright law. That is why the FSF publishes the > "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC > LICENSE." The former has far more trademark protection than the > latter. What? No, this is *not* how it works. A license text is an original piece of work that falls under copyright protection. In this case the copyright holder is the »The Linux Foundation and its contributors«. The terms of distribution are »Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.« You cannot simply copy a substantial amount of text into your work (no matter what it is) if you do not have the right to do so. > The Linux Foundation published a version of their DCO under the GPL, > which we would of course abide by. I highly doubt that, see my previous e-mail. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
> So, it is probably simpler to avoid controversy by just incorporating > it by reference under their original name, which is certainly the > intention of the Linux Foundation in promoting it. +1 :-) signature.asc Description: PGP signature
Re: [gentoo-dev] newsitem: important fstab and localmount update, round 2
On Tue, Nov 1, 2016, at 11:52 CDT, William Hubbs wrote: > requirement for udev to "settle" before it's startup completes. The ^~~~ its Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish
On Tue, Dec 6, 2016, at 20:37 CST, james wrote: > So do I need to apply again, or an I on the list? I went (nomail) > cause at the time reading via gmane.org was working. Perhaps I should > just change the status to receive the mails? I can test post, if > that is helpful? No, the list is simply dead (was never used in any meaningful way anyway). You can read the whole 3 e-mails over the last 5 months here [1] Best, Matthias [1] https://archives.gentoo.org/gentoo-proxy-maint/ signature.asc Description: PGP signature
Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles
On Mon, Jan 23, 2017, at 13:30 CST, Alexis Ballier wrote: > still that doesn't account for a 'ihatelennart' mixin masking udev & > systemd and a 'ilovelennart' mixin masking udev & eudev and an user > enabling them both But that's exactly what is ruled out by the "blocks @group" mechanism in mgorny's proposal. Best, Matthias
Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles
> well then 'ihateudev' masking udev, 'ihateeudev' masking eudev and > 'ihatesystemd' masking systemd; what are the blockers here? You make three profiles, 'udev', 'eudev', 'systemd' and put them in one group and let them block said group.
[gentoo-dev] Last rites: app-crypt/cryptkeeper
# Matthias Maier (31 Jan 2017) # Dead upstream (no development since 2010) [1,2], outstanding security # issue with newer encfs versions [3], oustanding Gentoo bugs [4,5]. # Mask for removal in 30 days. # [1] https://github.com/tomm/cryptkeeper/commits/master # [2] https://github.com/tomm/cryptkeeper/issues/ # [3] https://bugs.gentoo.org/show_bug.cgi?id=607772 # [4] https://bugs.gentoo.org/show_bug.cgi?id=448360 # [5] https://bugs.gentoo.org/show_bug.cgi?id=596832 app-crypt/cryptkeeper
Re: [gentoo-dev] Deprecating repoman
Just a quick though: Looking at the man page of repoman it doesn't look to difficult to replicate the behavior with pkgcheck. Meaning, we could think of creating a drop-in replacement for "repoman [full]" (which would just call pkgcheck) and "repoman commit" which actually does much more than just prepending the git commit summary line: repoman commit does - update the manifest - bail out if files are not correctly "git add"ed - add the output of [pkgcheck] as a comment to the git commit description Best, Matthias
Re: [gentoo-dev] Deprecating repoman
On Wed, Mar 9, 2022, at 15:47 CST, Matt Turner wrote: > [...] > > I wouldn't block anyone from doing this, but it's not something I'm > personally interested in pursuing. I see very little value here. I did not intend to imply that you should do anything. I just want to point out that we had been educating developers for using "repoman" to commit for a long time and looking at the "git log" history shows that repoman is still used by a sizable number of developers (around 50%-ish). So, it would be very nice to have a somewhat official "blessed" alternative in place. For example, dev-util/pkgdev was suggested as an alternative, but I cannot assess whether this is indeed a viable alternative. Best, Matthias
Re: [gentoo-dev] Deprecating repoman
On Wed, Mar 9, 2022, at 17:32 CST, Matt Turner wrote: > I think you just made that number up :) Nah. My sample was just bad (ago just made a sizable number of commits. I would estimate the current usage of repoman to be about 20-25%, down from well over 80-90% back when we just switched to git: https://tamiko.43-1.org/temp/repoman-usage.pdf >> For example, dev-util/pkgdev was suggested as an alternative, but I >> cannot assess whether this is indeed a viable alternative. > > Why not? Because I haven't used it so far. > Give it a try. Absolutely, the faster I can ditch repoman, the better. Best, Matthias
Re: [gentoo-dev] Multiple packages up for grabs (incl. zsh, feh, zathura, qbittorrent)
On Sat, Aug 26, 2023, at 09:59 CDT, Ionen Wolkens wrote: > app-shells/zsh If no one else steps up then I will happily take over zsh (co)maintenance. But due to limited time lately, :-(, it would be best if I found a (co)maintainer :-) Best, Matthias
Re: [gentoo-dev] Introducing .mailmap?
On Tue, Feb 13, 2024, at 02:39 CST, Sam James wrote: > Hi, > > We should consider adding a .mailmap to gentoo.git. > > There's a few reasons: > [...] +1 You can add * allows to fix up accidental commits with wrong e-mails as well. *cough* Best, Matthias
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On Tue, Feb 27, 2024, at 08:45 CST, Michał Górny wrote: > Given the recent spread of the "AI" bubble, I think we really need to > look into formally addressing the related concerns. In my opinion, > at this point the only reasonable course of action would be to safely > ban "AI"-backed contribution entirely. In other words, explicitly > forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to > create ebuilds, code, documentation, messages, bug reports and so on for > use in Gentoo. +1 > 2. Quality concerns. LLMs are really great at generating plausibly > looking bullshit. I suppose they can provide good assistance if you are > careful enough, but we can't really rely on all our contributors being > aware of the risks. This is my main concern, but all of the other points are valid as well. Best, Matthias
[gentoo-dev] Pakackages up for grabs
Dear all, I have had little time to contribute to Gentoo over the last 24 months. Therefore, I need to downsize in actively maintained packages. I will drop myself as maintainer from the following packages in the next couple days. Please adopt them if you're interested: app-crypt/efitools app-crypt/sbsigntools app-misc/hello app-text/barcode app-vim/vim-multiple-cursors sys-fs/mp3fs dev-util/astyle dev-util/cloc dev-util/cppcheck games-board/stockfish media-sound/quodlibet app-crypt/jitterentropy-rngd dev-python/magic-wormhole-mailbox-server dev-python/magic-wormhole dev-python/magic-wormhole-transit-relay dev-python/noiseprotocol dev-python/spake2 dev-python/txtorcon I am also happy if someone wants to co-maintain one of the following packages: dev-util/debootstrap app-text/doxygen sci-visualization/paraview Best, Matthias
Re: [gentoo-dev] Are users forced to use PAM?
Am 05. Oct 2014, 15:20 schrieb Diego Elio Pettenò : > Simple as this: -pam is not by default tested and you keep the pieces if it > breaks. Upstream bug is at [1]. According to comment 1 also upstream does not seem to test non-pam use cases all that often. I have the impression that all this fuzz around bug 524074 could have been handled in a much more civilized manner... "Are users forced to use PAM?" - we might want to inform upstream (politely) that we still support non-pam use cases. Otherwise the dependency might become mandatory. Best, Matthias [1] http://www.sudo.ws/bugs/show_bug.cgi?id=667
Re: [gentoo-dev] status of bugs blocking gcc-4.8.3
> Not sure if the llvm C++ runtime might help here or it is any better > than the one provided by gnu, but might be a good time to gather > volunteers to provide a mean to use clang as main compiler out of box. libc++ makes stricter ABI guarantees [1]. But from personal experience I would not consider it a replacement for libstdc++ in the near future. I have set up some lxc containers with clang/libc++ with promising results (and I plan to keep up testing with it once in a while). Best, Matthias [1] http://clang-developers.42468.n3.nabble.com/libc-ABI-stability-td2976682.html
[gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
> > Could you please blog or add some notes to the wiki about it? > I've put up a preliminary version for the toolchain part: https://gist.github.com/tamiko/7e3a0be806fac11f2a35 Best, Matthias
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
Am 27. Oct 2014, 11:14 schrieb Alexis Ballier :
> By the way, any help for maintaining the libc++ stack is very welcome;
> as you can see from the age of the current snapshots, it's been some
> time I've not been playing with it.
>
>
> Some notes:
> - why not adding a clang subprofile ? there's one for amd64-fbsd; I had
> been able to build a complete stage 3 without too much trouble.
> There's probably nothing bsd specific there, so moving
> generic code from there to profiles/features should work.
Yes, it looks fairly generic. This is definitely worth a try.
> - it'd be worth fixing/improving libunwind support, esp. as you write
> here on the clang 'spec' parts; I don't remember if there were other
> issues, but it was a bit pointless if we can't get rid of libgcc_s
> because of clang (maybe there were even symbol collisions?)
> - libcxxabi is probably the new way to go instead of libcxxrt; last
> time I checked there was a chicken and egg problem: libcxxabi needed
> clang + libc++ to build, so bootstrapping the stack was a bit
> painful.
The Toolchain behavior on GNU/Linux is fairly tailored to using gcc at
the moment (just grep for gcc_ on
tools/clang/lib/Driver/{Tools|Toolchain}.cpp).
In order to really pull off a clang/libc++ toolchain independent of gcc
assistance would involve quite a bunch of (preferably upstream) work...
> - there are a few todos in libcxx ebuild (mainly libsupc++ support, but
> the same could apply to libcxxabi)
> - it'd be interesting to have stand-alone ebuilds for gcc's crt files;
> or better, find BSD-like alternatives
>
> Alexis.
Best,
Matthias
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
Am 27. Oct 2014, 12:07 schrieb "M. Ziebell" : > Does clang compile glibc already? > At the last GNU Cauldron the speaker said that clang fails because > of:[1] > - nested functions > - VLAIS > > How did you avoid that problem? Even without this issues there remains the fact that glibc is quite closely coupled to gcc's support libraries (e.g. $ grep "dlopen.*gcc_" **/*.c, or pthread's usage of support libraries...). And this is something that won't change anytime soon. After all, glibc is part of the GNU eco system and as such it is perfectly valid to depend on respective compiler.
Re: [gentoo-dev] Clang toolchain
> - libcxxabi is probably the new way to go instead of libcxxrt; last > time I checked there was a chicken and egg problem: libcxxabi needed > clang + libc++ to build, so bootstrapping the stack was a bit > painful. I give libcxxabi a try. Does anybody has a bit insight in the current status of the llvm's bundled libunwind in libcxxabi, i.e. is it trivially portable? If yes, this might clean up the dependency chain quite a bit. Best, Matthias
Re: [gentoo-dev] terminal spreadsheet - sc fork
Am 03. Nov 2014, 00:24 schrieb Andrés Martinelli : > I am working on a terminal spreadsheet based on "sc", but with some > adds like undo/redo.. > you can find it here: > > https://github.com/andmarti1424/scim > > Any new ideas and/or contribution is always welcome! Just out of curiosity. The original sc program is public domain [1]. You have chosen to relicense your fork of the codebase under a custom license that you labeled "SCIM license". A quick peek at the license [2] reveals quite a cumbersome number of issues (forced contact, contact possibility, redistribution in form of tarballs and patches). Such a license usually prevents any meaningful number of external contributions and packaging. Not to mention that layman's licenses are almost always fundamentally flawed. Why not using an FSF-approved, OSI-approved, and/or DFSG compatible license instead? I'm sure that there is something available that fits your taste. (You can e.g. license under "GPL 2 or later" and ask for a special (non binding) courtesy to inform you of changes/patches.) Best, Matthias [1] http://metadata.ftp-master.debian.org/changelogs//main/s/sc/sc_7.16-3_copyright [2] https://github.com/andmarti1424/scim/blob/master/LICENSE
[gentoo-dev] last-rites: app-emulation/virtinst
# Matthias Maier (4 Nov 2014) # Masked for removal in 30 days. The package has multiple open bugs # (bug #482472, bug #501818, bug #528190) and is superseded by # app-emulation/virt-manager[-gtk] app-emulation/virtinst
Re: [gentoo-dev] Portage dependency solving algorithm
Am 07. Nov 2014, 19:30 schrieb Ciaran McCreesh : > On Fri, 07 Nov 2014 19:11:04 +0100 > Jauhien Piatlicki wrote: >> Then the same question for you: where can one read about the algorithm >> Paludis uses? > > It's basically a two stage process: simple constraint solving using > value ordering heuristics to enforce "don't do unnecessary work", then > ordering (which is not quite a graph process, and which is not as > simple as a topological sort, because the tree is full of circular > dependencies). > > But the interesting question isn't "what's the algorithm?", it's > "what's the model?". That's where the complexity lies: figuring out how > to turn *DEPEND specifications into constraints is an utter pain, and > it isn't clean or easily understandable. The primary reason is || > dependencies: developers like to write not-really-correct and utterly > unobvious dependency strings rather than asking for new syntax so they > can just say what they mean... Currently, for portage just to decide that nothing has to be done on my machine takes around 1 minute. What is in your opinion the main reason for this? And how can we knock this down to reasonable speed? - Is our dependency model that more complex than the problem resolvers of other package managers for other distributions solve? - Is it the algorithm that is implemented for the dependency model? - Is it its implementation? >> And, again, I have herd (did not try myself) that Paludis is as slow >> as Portage. > > Well, you're not comparing like with like. Paludis with "everything > turned off" does more than Portage with "everything turned on". If all > you're looking for is the wrong answer as fast as possible, there are > easier ways of getting it... The last time I compared the resolver speed of portage and paludis both needed almost the same time. Do you have a speed comparison with a similar feature set of both? (Or, alternatively, the speedup one gains by tuning paludis to be as fast as possible). Best, Matthias
Re: [gentoo-dev] Portage dependency solving algorithm
Am 07. Nov 2014, 20:21 schrieb Ciaran McCreesh : > On Fri, 07 Nov 2014 19:54:08 +0100 > Matthias Maier wrote: >> Currently, for portage just to decide that nothing has to be done on >> my machine takes around 1 minute. > > Are you running with or without metadata cache? If you're running > without, it's going to be slow independently of the resolution > algorithm... Yes, I run with metadata cache. Without, ... well I never waited for it to finish. > [...] Thank you very much for the detailed explanation. This helped a lot :-] > > (For comparison, Paludis on Exherbo will run an order of magnitude > faster for the same set of installed packages, simply because on > Exherbo the input is correct.) > This might be a problem that we can tackle, though... Best, Matthias pgpGIY5YAKi8b.pgp Description: PGP signature
Re: [gentoo-dev] fixed my virt-manager issue; libvirt-python-9999.ebuild
I've commited a live ebuild for libvirt-python to CVS. Given the fact that we already have one for libvirt and one for virt-manager, this makes sense. Best, Matthias *libvirt-python- (08 Nov 2014) 08 Nov 2014; Matthias Maier +libvirt-python-.ebuild: provide live ebuild as suggested by Paige Thompson on the mailing list
Re: [gentoo-dev] Packages up for grabs
Am 11. Nov 2014, 15:59 schrieb Pavlos Ratis : > * dev-vcs/mr I can take care of this one - I use dev-vcs/mr quite heavily. Best, Matthias
Re: [gentoo-dev] Packages up for grabs
> * dev-vcs/mr > * dev-vcs/vcsh On second thought, I think, I'll adapt both of them. :-) Best, Matthias
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > That said, I'm open to using a different recommendation, e.g. 2 years > as in riseup [1]. I suppose having the same time for both primary key > and subkeys would make the spec simpler, and many developers are > mistaking expiration times (as specified now) anyway. > > [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years Make it at most 2, 3, (or as it has been so far 5) years for both primary and subkeys. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > I don't really know the original rationale for this. > > The NIST standard says 1-3 years. If I were to guess, I'd say 1 year > was chosen for subkey because subkey expiring is a 'smaller' issue than > the whole key expiring, i.e. other users see the primary key as being > still valid. Quoting the NIST standard in this regard is a bit silly. It recommends that the total "cryptoperiod" (this is the total timeinterval a single key should be actively used) of a private key for the purpose of signing shall be 1 - 3 years. (The publickey for verification is unspecified) If we would follow this to the letter, we would all have to rotate (not extend) our pgp keys after 3 years. Can we just do something sensible here? I.e. requiring a key expiry of 2 years on any key (primary and subkeys)? Two years is a reasonable timeframe. Everyone with an air-gapped primary key can afford the 30 minutes to update signatures *every other* year. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] Re: What means bup?
On Sun, Sep 23, 2018, at 21:26 CDT, Kent Fredric wrote: > I personally try to use something of the form: > > "Bump version to 12.234.1567" > > Mostly, because it gives some vaguely useful context when reading a > commit summary log, that doesn't necessitate you running "git log -p" > or "git diff" to find out what actually changed. ++ > [...] > All of this is "nice to have" stuff I'd try to gently nudge others into > the direction of, in effort to provide useful information to not only > our users, but to other developers, and our future selves looking back > in the history trying to ascertain the importance of a given version. ++ > [...] > But you can imagine how I get *just* a little bit frustrated when this > is the sort of direction I'm trying to aspire towards, but what I'm > seeing on the list is debates about "bup" vs "bump" :) ++ There is nothing more to add. Best, Matthias
[gentoo-dev] Re: [PATCH] app-emulation/qemu-9999: Sync softmmu targets
Pushed, thanks!
On Wed, Sep 26, 2018, at 09:38 CDT, Michal Privoznik
wrote:
> Qemu dropped ppcemb target in
> a69dc537cc1a6d3c3cb35d30197ed45914a150c3.
>
> Signed-off-by: Michal Privoznik
> ---
> app-emulation/qemu/qemu-.ebuild | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app-emulation/qemu/qemu-.ebuild
> b/app-emulation/qemu/qemu-.ebuild
> index 8f95e3f2a6e..833c2349a4c 100644
> --- a/app-emulation/qemu/qemu-.ebuild
> +++ b/app-emulation/qemu/qemu-.ebuild
> @@ -38,7 +38,7 @@ COMMON_TARGETS="aarch64 alpha arm cris hppa i386 m68k
> microblaze microblazeel
> mips mips64 mips64el mipsel nios2 or1k ppc ppc64 riscv32 riscv64 s390x
> sh4 sh4eb sparc sparc64 x86_64 xtensa xtensaeb"
> IUSE_SOFTMMU_TARGETS="${COMMON_TARGETS}
> - lm32 moxie ppcemb tricore unicore32"
> + lm32 moxie tricore unicore32"
> IUSE_USER_TARGETS="${COMMON_TARGETS}
> aarch64_be armeb mipsn32 mipsn32el ppc64abi32 ppc64le sparc32plus
> tilegx"
[gentoo-dev] Re: [PATCH] app-emulation/virt-manager: Don's pass --qemu-user to configure
Applied. Thanks!
On Mon, Oct 15, 2018, at 06:47 CDT, Michal Privoznik
wrote:
> virt-manager has dropped --qemu-user configure option in
> e6738d9827492d. Update live ebulid to not pass it.
>
> Signed-off-by: Michal Privoznik
> ---
> app-emulation/virt-manager/virt-manager-.ebuild | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/app-emulation/virt-manager/virt-manager-.ebuild
> b/app-emulation/virt-manager/virt-manager-.ebuild
> index 7e88178f48f..69c24ad9817 100644
> --- a/app-emulation/virt-manager/virt-manager-.ebuild
> +++ b/app-emulation/virt-manager/virt-manager-.ebuild
> @@ -61,7 +61,6 @@ distutils-r1_python_compile() {
> local defgraphics=
>
> esetup.py configure \
> - --qemu-user=qemu \
> --default-graphics=spice
> }
[gentoo-dev] Re: [PATCH 0/2] app-emulation/qemu-9999: Couple of sync patches
On Mon, Oct 22, 2018, at 08:21 CDT, Michal Privoznik wrote: > QEMU upstream has changed a bit and thus we must update our ebuild. > > Michal Privoznik (2): > app-emulation/qemu-: Drop gtk2 use flag > app-emulation/qemu-: Drop sdl-1.2 support > > app-emulation/qemu/qemu-.ebuild | 31 - > 1 file changed, 8 insertions(+), 23 deletions(-) Pushed to the tree. As always, thanks a lot for your contributions! Matthias
[gentoo-dev] Re: [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4
Applied, thanks! On Thu, Oct 25, 2018, at 10:31 CDT, Michal Privoznik wrote: > --- a/app-emulation/libvirt-snmp/Manifest > +++ b/app-emulation/libvirt-snmp/Manifest > @@ -1,2 +1,3 @@ > DIST libvirt-snmp-0.0.2.tar.gz 152790 BLAKE2B > b2e5eee2d67283112556c52921b14029a90d5cedf0c4575e056475191470a4b6bf5d837f1ca942b848f6509da4aa12daa508bbfc5272e1435e73fbfc290e1967 > SHA512 > 13a522c765d278d3b8f8ab9f32f97c8531f6d131afcb0ce62ae397631db92ed3b585ad221a1f2b3bc17907cc4d61adca4a2071b0458a05f2bff5ca06191e1478 > DIST libvirt-snmp-0.0.3.tar.gz 161186 BLAKE2B > 1b43e7e81a43d4e969e2e30d7d62776743b3c5fb19929fb1606850946c665ad1ca662bee88743f60f202cd92fc42be1cc2cc94e99bf1d137df61bec09850de93 > SHA512 > 6ffda3594ddc513e05e31e7d347a12e371dca3cc698ca790a70e2d01b2ceac6acb5dd6e3cd19723817b41aa62e0c0a49c01c47cb9ce379ac491856a7e88e5a08 > +DIST libvirt-snmp-0.0.4.tar.gz 157859 BLAKE2B > e2c8fcdd97ba9b55bd4d318c63f7738024c1360ee10aa4e685c2ea6ca02478206febff30f3e1a82eb1a2dadaa52a377cfbce538e12e33f4ea2fe10b1a089945d > SHA512 > dbf47e7983f9bd6fcff205fffd1f6006268cca774cf427d39dec84dc7de37b545c0dfcbb2c6f171f55d73487cdec13341097137e24de2dea58ce90494d281162 ^^^ Your diff contained superfluous line breaks (some rogue e-mail editor configuration option?) Best, Matthias
Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4
> could you please stop sending project related stuff to the -dev mailing > list? It is irrelevant place to provide bump patches Why? What's the purpose of a developer mailing list then?
