Re: [gentoo-dev] News item for eudev deprecation
On 8/24/21 6:24 AM, Jaco Kroon wrote: > Hi All, > > We run glibc based systems. No musl. But we don't use systemd. > > As little as a year back we still ran into issues with systemd-udev > variant breaking systems, the fix of course was to nuke it and install > eudev. Are we certain there is nothing (eg, LVM integration was our > biggest problem resulting in really crazy impossible to debug since we > can't log in due to lvn snapshot creation/removal deadlocking with > systemd-udev - no ask me not how, all I can tell you is that eudev never > exhibited this behaviour) will break? > > Whilst I fully appreciate the difficult of all the various e* packages > (elogind, eudev etc ..) and I most certainly do not have the capacity to > maintain, and therefore I'm in full support of the concept of > deprecating eudev, I'm very, very worried about us suddenly being back > into the reboot-a-server-a-week scenario. In the worst case we've lost > some large filesystems almost certainly due to systemd-udev (we've had a > number of filesystem crashes which was recovered with fsck, but after > ditching systemd-udev and moving to eudev about two years back on this > specific host we've had ZERO further problems other than a failed drive > or two, none of which required a hard-reset to get back to a sane state). > > Kind Regards, > Jaco I kept eudev as conservative as possible which probably explains its predictable behavior. Open bugs with the sys-fs/udev maintainers and mark it critical if it is damaging filesystems. > > On 2021/08/22 22:14, Anthony G. Basile wrote: >> Hi everyone, >> >> Yes! It is time to finally deprecate eudev! sys-fs/udev now builds >> under musl! My original purpose for maintaining eudev was because >> systemd + musl did not play well together when udev was absorbed into >> the sytemd repo. Now thanks to patches from openembedded, they do, and >> my original reason for maintaining eudev is no longer valid. So its >> time to retire eudev. It has served its purpose as a stop-gap. >> >> To me, this is a success for musl, and I would like to thank all the >> developers who have taken musl seriously enough to make this happen :) >> >> I am willing to transfer the eudev repo to another organization, but I >> will not maintain it anymore and Base System doesn't want to either. >> Let me warn people, to maintain it correctly you MUST become familiar >> with its internals and watch what systemd is doing upstream to keep up. >> This is not trivial. I learned a lot from eudev, and it did save musl >> on gentoo, but there was a period there when it was taking up almost all >> of my time. If you don't know what you're getting into, you don't want >> to take on its maintenance. >> >> >> >> Title: eudev retirement on 2022-01-01 >> Author: Anthony G. Basile >> Posted: 2021-08-xx >> Revision: 1 >> News-Item-Format: 2.0 >> Display-If-Installed: sys-fs/eudev >> >> sys-fs/udev is becoming the standard provider of udev on non-systemd >> (e.g. OpenRC) systems. Users of systemd will continue to use the udev >> services provided by the sys-apps/systemd package itself. >> >> The transition should be uneventful in most cases, but please read this >> item in full to understand some possible corner cases. >> >> eudev will be retired and removed from Gentoo on 2022-01-01. We will >> start masking eudev on 2021-10-01 and give people 3 months to prepare >> their transition. You should ensure that sys-fs/eudev is not in your >> world file by running >> >> emerge --deselect sys-fs/eudev >> >> in order for Portage to replace eudev with sys-fs/udev once the >> package.mask is in place. We fully support udev on musl, whereas uclibc >> will still have to rely on eudev before also being removed on 2022-01-01. >> >> **WARNING** >> >> If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob, >> you will inevitably break your system. sys-fs/udev contains "systemd" in >> some of its filenames, hence a blanket filter rule will likely lead to a >> non-functional udev installation. >> >> Rationale >> >> The integration of udev into the systemd git repo introduced numerous >> problems for none-glibc systems, such as musl and uclibc. Several >> options were considered, and the one chosen was to fork and maintain >> udev independant of the rest of systemd. This was meant as a stop-gap >> solution until such time as the problems with systemd on musl had been >> resolved. This is
Re: [gentoo-dev] News item for eudev deprecation
On 8/23/21 11:05 AM, Rich Freeman wrote: > On Mon, Aug 23, 2021 at 10:36 AM Ulrich Mueller wrote: >> >>>>>>> On Mon, 23 Aug 2021, Anthony G Basile wrote: >> >>>>> **WARNING** >>>>> >>>>> If you happen to have an INSTALL_MASK with a blanket "*systemd*" >>>>> glob, you will inevitably break your system. sys-fs/udev contains >>>>> "systemd" in some of its filenames, hence a blanket filter rule will >>>>> likely lead to a non-functional udev installation. >>>> >>>> Will an INSTALL_MASK of "/usr/lib/systemd /etc/systemd" cause any >>>> issues? >> >>> I have not tested, but I think so since "systemd-" is used as a prefix >>> for files installed by sys-fs/udev. >> >> So, we've abandoned the systemd USE flag, and I remember that one of >> the arguments was that users could use INSTALL_MASK for precisely the >> above mentioned directories. > > Well, the argument is that we don't use USE flags to prevent packages > from installing small text files. It is the same reason we don't have > an openrc USE flag to control installing init.d scripts. We're now > talking about pretty far back in history but I think this was a > general guideline before systemd even came along. > >> Now the message is that users' systems will be broken if they had >> followed our previous advice? Seriously? > > Did we ever officially advise people to use INSTALL_MASK at all? I > thought that was mostly a "you can keep the pieces if you break > things" option we provide. IMO the risks of people misusing it are > far greater than the possible harm of having a few hundred small text > files installed on their system, but it is there if people really want > to use it. I remember this discussion well. It was for those "stubborn" people who wanted a clean system. I added to the discussion by saying "what about embedded systems people where every file counts because of inode and block allocation constraints" and the answer was INSTALL_MASK, not a USE flag, for the reasons Rich stated. This was to create a openrc/systemd agnostic system. Having said that, I'm open to whatever solution/wording you might suggest. > > However, having used the option in the past shouldn't hurt anybody. > It only impacts people if they use it when they install udev, hence > the news item. > -- 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] News item for eudev deprecation
On 8/22/21 5:00 PM, Joshua Kinard wrote: > On 8/22/2021 16:14, Anthony G. Basile wrote: >> Hi everyone, >> >> Yes! It is time to finally deprecate eudev! sys-fs/udev now builds >> under musl! My original purpose for maintaining eudev was because >> systemd + musl did not play well together when udev was absorbed into >> the sytemd repo. Now thanks to patches from openembedded, they do, and >> my original reason for maintaining eudev is no longer valid. So its >> time to retire eudev. It has served its purpose as a stop-gap. >> >> To me, this is a success for musl, and I would like to thank all the >> developers who have taken musl seriously enough to make this happen :) >> >> I am willing to transfer the eudev repo to another organization, but I >> will not maintain it anymore and Base System doesn't want to either. >> Let me warn people, to maintain it correctly you MUST become familiar >> with its internals and watch what systemd is doing upstream to keep up. >> This is not trivial. I learned a lot from eudev, and it did save musl >> on gentoo, but there was a period there when it was taking up almost all >> of my time. If you don't know what you're getting into, you don't want >> to take on its maintenance. > > Which version of sys-fs/udev has the patches that allow it to replace eudev? > Do these patches have any chance of being accepted by upstream? > >From udev-249-r2 and forward. As far as upstream goes, I don't know. I tried in the early days talking to people, but the "fog of politics" was too thick. I can try again. Having said that, I have assurances from people within Gentoo that they will help maintain those patches. I can also reach out to the openembedded people to inform them of our interest in these patches. I think musl has reached a sufficient weight that people beyond Gentoo are interested in making sure it works with linux systems. I was an early adopter of it into Gentoo, like 10 years ago now. At that time, plugging it into a linux distro was squeezing a square peg into a round whole. This is no longer the case. > >> Title: eudev retirement on 2022-01-01 >> Author: Anthony G. Basile >> Posted: 2021-08-xx >> Revision: 1 >> News-Item-Format: 2.0 >> Display-If-Installed: sys-fs/eudev >> >> sys-fs/udev is becoming the standard provider of udev on non-systemd >> (e.g. OpenRC) systems. Users of systemd will continue to use the udev >> services provided by the sys-apps/systemd package itself. > > Are there any concerns about upstream one day making udev and systemd > inseparable again? I can't address this. There are two issues: 1) making sure there is a device manager for musl. 2) making sure there is a device manager which is independent of systemd. My concern was the former, hence eudev. If one day I have to use systemd on a musl system, so be it. If anyone is concerned about the second issue, they are welcome to maintain eudev :P My life circumstances have changed and I don't have the time or will. > > >> The transition should be uneventful in most cases, but please read this >> item in full to understand some possible corner cases. >> >> eudev will be retired and removed from Gentoo on 2022-01-01. We will >> start masking eudev on 2021-10-01 and give people 3 months to prepare >> their transition. You should ensure that sys-fs/eudev is not in your >> world file by running >> >> emerge --deselect sys-fs/eudev >> >> in order for Portage to replace eudev with sys-fs/udev once the >> package.mask is in place. We fully support udev on musl, whereas uclibc >> will still have to rely on eudev before also being removed on 2022-01-01. >> >> **WARNING** >> >> If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob, >> you will inevitably break your system. sys-fs/udev contains "systemd" in >> some of its filenames, hence a blanket filter rule will likely lead to a >> non-functional udev installation. > > Will an INSTALL_MASK of "/usr/lib/systemd /etc/systemd" cause any issues? I have not tested, but I think so since "systemd-" is used as a prefix for files installed by sys-fs/udev. > > > Couple of typos below: > >> Rationale >> >> The integration of udev into the systemd git repo introduced numerous >> problems for none-glibc systems, such as musl and uclibc. Several > > s/none-glibc/non-glibc/ > >> options were considered, and the one chosen was to fork and maintain >> udev independant of the rest of systemd. This was meant as a stop-gap > > s/indep
[gentoo-dev] News item for eudev deprecation
Hi everyone, Yes! It is time to finally deprecate eudev! sys-fs/udev now builds under musl! My original purpose for maintaining eudev was because systemd + musl did not play well together when udev was absorbed into the sytemd repo. Now thanks to patches from openembedded, they do, and my original reason for maintaining eudev is no longer valid. So its time to retire eudev. It has served its purpose as a stop-gap. To me, this is a success for musl, and I would like to thank all the developers who have taken musl seriously enough to make this happen :) I am willing to transfer the eudev repo to another organization, but I will not maintain it anymore and Base System doesn't want to either. Let me warn people, to maintain it correctly you MUST become familiar with its internals and watch what systemd is doing upstream to keep up. This is not trivial. I learned a lot from eudev, and it did save musl on gentoo, but there was a period there when it was taking up almost all of my time. If you don't know what you're getting into, you don't want to take on its maintenance. Title: eudev retirement on 2022-01-01 Author: Anthony G. Basile Posted: 2021-08-xx Revision: 1 News-Item-Format: 2.0 Display-If-Installed: sys-fs/eudev sys-fs/udev is becoming the standard provider of udev on non-systemd (e.g. OpenRC) systems. Users of systemd will continue to use the udev services provided by the sys-apps/systemd package itself. The transition should be uneventful in most cases, but please read this item in full to understand some possible corner cases. eudev will be retired and removed from Gentoo on 2022-01-01. We will start masking eudev on 2021-10-01 and give people 3 months to prepare their transition. You should ensure that sys-fs/eudev is not in your world file by running emerge --deselect sys-fs/eudev in order for Portage to replace eudev with sys-fs/udev once the package.mask is in place. We fully support udev on musl, whereas uclibc will still have to rely on eudev before also being removed on 2022-01-01. **WARNING** If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob, you will inevitably break your system. sys-fs/udev contains "systemd" in some of its filenames, hence a blanket filter rule will likely lead to a non-functional udev installation. Rationale The integration of udev into the systemd git repo introduced numerous problems for none-glibc systems, such as musl and uclibc. Several options were considered, and the one chosen was to fork and maintain udev independant of the rest of systemd. This was meant as a stop-gap solution until such time as the problems with systemd on musl had been resolved. This is now the case with patches provided by openembedded, and my original reason for maintaining eudev is no longer relevant. I am willing to transfer eudev to another umbrella organisation or Linux distribution that is willing to continue its maintenance, but maintaining eudev cannot be done purely through proxy-maintaining and requires an understanding of its internals. This is a steep learning curve and must be an earnest effort. For this reason, the Base System project has decided not to support euev as an option going forward. -- 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] News Item for uClibc-ng deprecation
On 8/17/21 2:24 PM, Aaron Bauman wrote: > On Tue, Aug 17, 2021 at 01:27:45PM -0400, Mike Gilbert wrote: >> On Tue, Aug 17, 2021 at 7:40 AM Anthony G. Basile >> wrote: >>> >>> Hi everyone, >>> >>> Can I get feedback on the following news item? (BTW, thanks soap) >>> >>> Title: uClibc-ng retirement on 2023/01/01 >>> Author: Anthony G. Basile >>> Posted: 2021-08-15 >>> Revision: 1 >>> News-Item-Format: 2.0 >>> Display-If-Profile: default/linux/uclibc/* >>> >>> uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021, >>> noone has volunteered to step up maintenance or expressed interest in >>> the uClibc-ng profiles. With this announcement we last-rite the "uclibc" >>> profiles, which will be removed on 2023/01/01. For parties interested in >>> an alternative libc, consider moving to musl, which is supported. >> >> 2023? That seems like a pretty long time to wait to remove something >> that isn't very well supported right now. > > +1 > > While I have no involvement with uClibc-ng, it does seem awfully long > before removal. > > -Aaron > How does 2022-08-01 sound? That's about 1 year. -- 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] News Item for uClibc-ng deprecation
On 8/17/21 2:08 PM, Joshua Kinard wrote: > On 8/17/2021 13:49, Sam James wrote: >> >> >>> On 17 Aug 2021, at 16:19, Joshua Kinard wrote: >>> [snip] >>> >>> According to the uClibc-ng website, 1.0.38 was released earlier this year >>> (March 27th). Was an announcement put out somewhere about the project not >>> being maintained any further beyond that release, or has it gone quiet after >>> that? >> >> Upstream supporting something doesn't mean that's the case in Gentoo. The >> last "proper" mention of deprecating uclibc in Gentoo was from blueness >> in January this year [0]. >> >> Funnily enough: while digging for the email, I did notice you replied [1] >> and couldn't >> build ncurses, which is pretty apt for illustrating the problems here. That >> is, no developers >> within Gentoo are supporting uclibc, none of us are really surprised when >> common/core packages >> break, and the tracker [2] at least is rotting (as are other uclibc-related >> bugs). >> >> The gist is, it's not really supported anymore now. This is just about >> formally dropping >> it. I'd be really surprised if anyone is able to use this day-to-day without >> a fair amount >> of patches. >> >> In terms of "alt libcs", musl has won that fight. Maybe if somebody wants to >> step in future, >> we can look at uclibc-ng again, but I don't think we've got the resources >> right now. >> >> [0] >> https://archives.gentoo.org/gentoo-dev/message/8b376050c51c7fa9a8a05246feb8c781 >> [1] >> https://archives.gentoo.org/gentoo-dev/message/258c08a43961269338e4c9238783f8fe >> [2] https://bugs.gentoo.org/570544 >> >>> >>> I haven't been able to base a MIPS environment on uclibc-ng since 2019 when >>> Python3 in my stage3's mysteriously all started failing for unexplained >>> reasons. Thought about trying to bootstrap a new environment from scratch >>> at some point, but just haven't gotten around to it. >>> >> >> That sounds like a good reason to dump it too ;) > > The thing is, the breakage I describe is *really* weird. Unpack my 2019 > uclibc-ng stage3 on a MIPS system, chroot in, everything works fine. But > the instant you recompile ncurses inside of it, using the *same* Portage > snapshot that it was built from, the Python interpreter falls over with a > NULL deref in its curses module. I've debugged it down to the exact line of > C code in Python, but cannot find an explanation why it fails. > > I've had my share of weird crap running these SGI systems, but this one > takes the cake. That's why I gave up on uclibc-ng for a time until I could > try kickstarting a new build from scratch using OpenADK (which still > supports older pre-mips32/64r* platforms). No other choice, really, because > once Python goes down, so too does emerge. > > Even bugged it on Python's bug tracker, but no surprise it's gone ignored: > https://bugs.python.org/issue39819 > > In any event, yeah, I don't have a real issue with dropping it. I've > noticed that some of the more recent commits to it are really just ingesting > chunks of glibc and stripping out some of the macro fluff. There's actually > a change in upstream glibc I've yet to test on one of my non-coherent cache > platforms that uclibc-ng pulled in that probably breaks them in fun fun ways > (not that that platform ever worked well from the beginning, though...). > Its broken on every arch. Its time for it to go. What little time I have I need to put into musl. -- 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
[gentoo-dev] News Item for uClibc-ng deprecation
Hi everyone, Can I get feedback on the following news item? (BTW, thanks soap) Title: uClibc-ng retirement on 2023/01/01 Author: Anthony G. Basile Posted: 2021-08-15 Revision: 1 News-Item-Format: 2.0 Display-If-Profile: default/linux/uclibc/* uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021, noone has volunteered to step up maintenance or expressed interest in the uClibc-ng profiles. With this announcement we last-rite the "uclibc" profiles, which will be removed on 2023/01/01. For parties interested in an alternative libc, consider moving to musl, which is supported. Gentoo continues to wholeheartedly support musl and is focusing its efforts in that area. Resources: - https://wiki.gentoo.org/wiki/Project:Hardened_musl - https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches) - #gentoo-hardened (IRC channel on irc.libera.chat) for support and discussion -- 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] RFC: dropping support for uclibc-ng
On 1/5/21 8:43 AM, Jaco Kroon wrote: > Hi Thomas, > > On 2021/01/05 13:08, Thomas Mueller wrote: >>> I'd like feedback from people about the possibility of dropping support >>> for uclibc-ng. If you are unfamiliar, its the successor to uclibc as a >>> C Standard Library for embedded systems, ie a replacement for glibc >>> bloat. However, it is inferior to musl which serves the same purpose >>> and which has now well supported in Gentoo. >>> I know people want musl support, but does anyone even care about >>> uclibc-ng? If not, I can work towards deprecating it and putting what >>> little time I have towards musl. >>> Anthony G. Basile, Ph.D. >>> Gentoo Linux Developer [Hardened] >> Are you the only Gentoo developer working on musl and uclibc-ng? I'm the only one working on uclibc-ng. There are some people helping with musl, especially the overlay. >> >> One thing I might try with a Gentoo uclibc-ng system is convert to musl or >> glibc using crossdev. >> >> From what I see on the internet, there is more support for musl than >> uclibc-ng, and more people working with musl than with uclibc-ng. It does seem that musl is winning the embedded libc race. >> >> There is a musl-cross-make cross-toolchain that can be built from non-musl >> or even non-Linux. >> >> https://github.com/richfelker/musl-cross-make > > I've used crossdev in the past. It was a nasty experience, but I > believe crossdev in Gentoo is getting better and better, and it supports > many more targets. Yes it is, which is why I'm preparing pre-build stage3's on several arches so you don't have to x-compile. I've done the nasty part for you. > >> From what I have seen, musl looks more promising than uclibc-ng, and more >> user- and developer-friendly. >> >> Unless somebody wants to take over uclibc-ng for Gentoo, I say better for >> you, with your limited time, to drop uclibc-ng in favor of musl. Correct, if I had the time, I'd continue to support both. But my time is limited, so I need to concentrate. I'm just looking for anyone to scream if I'm destroying their world by dropping uclibc-ng. If no one does, then I'll begin the process of removing it from the tree. > > Not doing embedded work at the moment, but just out of hand as of right > now if I had to make a choice I'd definitely look at MUSL as first > choice. So +1 for that suggestion. > > Kind Regards, > Jaco > -- 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
[gentoo-dev] RFC: dropping support for uclibc-ng
Hi everyone, I'd like feedback from people about the possibility of dropping support for uclibc-ng. If you are unfamiliar, its the successor to uclibc as a C Standard Library for embedded systems, ie a replacement for glibc bloat. However, it is inferior to musl which serves the same purpose and which has now well supported in Gentoo. I know people want musl support, but does anyone even care about uclibc-ng? If not, I can work towards deprecating it and putting what little time I have towards musl. -- 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] [RFC] Discontinuing LibreSSL support?
On 12/29/20 6:06 PM, David Seifert wrote: > > If you want to provide an alternative, you have to subsume the API, not > make it superficially compatible, only to find out that the you need to > mask out a ton of stuff with macros. Agreed. If libressl hadn't failed on this point, we would not be having this conversation. They promised it would be API compatible and it started that way, but not anymore. This became annoying even to me with my other packages like stunnel, where with every bump I had to create a new patch with macros based on versions. This is not something we want to saddle the rest of Gentoo with. Nor do we want to burden upstream teams to have to follow libressl's insanity. -- 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] [RFC] Discontinuing LibreSSL support?
On 12/29/20 5:41 PM, Peter Stuge wrote: > Michał Górny wrote: >>> I would be happier if some other developers were able and willing to >>> participate actively in the LibreSSL project. >> >> But why would they do that? What I'm really missing in all the replies >> is a single reason why LibreSSL would be better for anyone. > > Maybe because it is so well-known that monoculture is harmful per se, > which is why the commitment to choice in Gentoo is very valuable. > > Further, LibreSSL comes out of the OpenBSD project, which has a good > reputation on code quality. > I am sympathetic to not degrading into a monoculture. If I would characterize my contribution to Gentoo over the years it would be "alt-everything". The reason being that competition between alternatives is a good thing and time will tell which way is best. But <- here's the "but" At some point a particular path may have to be dropped because it just doesn't provide any clear advantages. There was nothing wrong with adding libressl as an alternative in 2014 since it had promise. And now, years later, I see nothing wrong with removing it. It hasn't delivered. -- 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] [RFC] Discontinuing LibreSSL support?
On 12/28/20 3:56 AM, Michał Górny wrote: > Hello, developers and Gentoo LibreSSL team. > > TL;DR: is there really a point in continuing the never-ending always- > regressing struggle towards supporting LibreSSL in Gentoo? > > > I would like to discuss the possibility of discontinuing LibreSSL > support in Gentoo in favor of sticking with OpenSSL. Similarly how we > ended up deciding that fighting for libav was unpractical and the vast > majority of users are using ffmpeg (because they didn't really have > a choice), today it seems that LibreSSL is suffering the same fate. > > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? > To be honest, I don't think so. In 2014, it might have represented > a new quality. But today, OpenSSL is alive and kicking, and LibreSSL > finds it hard to keep up. > > The vast majority of software is not tested against LibreSSL. While > patches are usually trivial and we have people that submit them, > I find many of them short-sighted. Just look at [1]. Sure, it fixes > the build today but it disabled the feature for all foreseeable future. > How likely is it that somebody will submit another patch reenabling it > with a future LibreSSL version? > > While normally I strongly prefer submitting such patches upstream, that > makes things even worse. I mean, I wouldn't be surprised if there were > dozens of packages today that are crippled with LibreSSL just because > somebody fixed the build in the past and never revisited the problem. > > This somewhat resembles running in circles. Packages kept being broken > with LibreSSL because rarely anyone is using it. And rarely anyone is > using LibreSSL because the apparent benefit (or lack thereof) does not > justify the constant breakage (plus invisible regressions). > > All this considered, provided that nobody is able to find a good reason > to use LibreSSL, I would like to propose that we stop patching > packages, discontinue support for it and last rite it. > > > [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892 > I'm the current project lead. I inherited it back in the day from hasufel. It originally had promise of being better than openssl with 100% compatibility. I hung on because I trusted that team but it has become more of a hassle than its worth. I am in favor of removing it. If we decide to do so, how should we proceed? -- 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] musl doesn't provide execinfo.h
On 3/27/20 3:17 PM, Alexis Ballier wrote: > On Fri, 2020-03-27 at 08:03 -0400, Anthony G. Basile wrote: >> On 3/26/20 9:25 PM, Joshua Kinard wrote: >>> On 3/23/2020 04:21, Jaco Kroon wrote: >>>> Hi, >>>> >>>> https://bugs.gentoo.org/713668 relates. >>>> >>>> * Searching for /usr/include/execinfo.h ... >>>> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) >>>> >>>> As I see I can either add an explicit depend on glibc which I'd >>>> prefer >>>> not to. Or someone from the musl team could possibly assist on >>>> how to >>>> get the backtrace() set of calls on musl please? >>>> >>>> Alternatively I need to add a test and simply path debug.c to >>>> only >>>> provide stub function for print_backtrace(FILE *fp) that just >>>> does >>>> fprintf(fp, "No backtrace() available to print a backtrace.\n"); >>>> >>>> Suggestions? >>>> >>>> Kind Regards, >>>> Jaco >>> >>> Some quick searching on google, it looks like the cleanest fix for >>> that bug >>> is dahdi-tools needs to be patched to only include execinfo.h or >>> only use >>> backtrace() on glibc-based systems, and that patch then sent to the >>> dahdi-tools upstream developers for inclusion in a future >>> release. That >>> way, we're not dragging that patch around forever in the tree or in >>> the musl >>> overlay. >>> >>> It also doesn't look like musl itself will ever implement >>> execinfo.h or >>> backtrace(), per this message in 2015 from the lead musl developer: >>> https://www.openwall.com/lists/musl/2015/04/09/3 >>> >> >> Correct. I've been adding -standalone packages to provide for >> features >> like fts, obstack, argp,etc. which are bundled into glibc but not >> really >> under the POSIX standard. >> >> So either we patch packages to turn off backtrace() or we add >> libunwind-standalone to the tree. >> > > > BTW, we had libexecinfo for fbsd, which seems also present in alpine: > https://pkgs.alpinelinux.org/package/edge/main/x86/libexecinfo > > Had? Is it in the tree now or should I look into adding it? -- 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] musl doesn't provide execinfo.h
On 3/26/20 9:25 PM, Joshua Kinard wrote: > On 3/23/2020 04:21, Jaco Kroon wrote: >> Hi, >> >> https://bugs.gentoo.org/713668 relates. >> >> * Searching for /usr/include/execinfo.h ... >> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h) >> >> As I see I can either add an explicit depend on glibc which I'd prefer >> not to. Or someone from the musl team could possibly assist on how to >> get the backtrace() set of calls on musl please? >> >> Alternatively I need to add a test and simply path debug.c to only >> provide stub function for print_backtrace(FILE *fp) that just does >> fprintf(fp, "No backtrace() available to print a backtrace.\n"); >> >> Suggestions? >> >> Kind Regards, >> Jaco > > Some quick searching on google, it looks like the cleanest fix for that bug > is dahdi-tools needs to be patched to only include execinfo.h or only use > backtrace() on glibc-based systems, and that patch then sent to the > dahdi-tools upstream developers for inclusion in a future release. That > way, we're not dragging that patch around forever in the tree or in the musl > overlay. > > It also doesn't look like musl itself will ever implement execinfo.h or > backtrace(), per this message in 2015 from the lead musl developer: > https://www.openwall.com/lists/musl/2015/04/09/3 > Correct. I've been adding -standalone packages to provide for features like fts, obstack, argp,etc. which are bundled into glibc but not really under the POSIX standard. So either we patch packages to turn off backtrace() or we add libunwind-standalone to the tree. -- 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] RFC: request uid/gid for net-misc/stunnel
On 12/8/19 2:59 PM, Ulrich Mueller wrote: >>>>>> On Sun, 08 Dec 2019, Anthony G Basile wrote: > >> Okay, I'm requesting UID/GID = 492/492. I'm committing in a sec. > > That's the ID used by arch for oprofile, so it's a bad choice. > > Ulrich > I give up! How am I supposed to know what to choose if it isn't requested in the uid-git.txt file? -- 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] RFC: request uid/gid for net-misc/stunnel
On 12/8/19 2:53 PM, Michał Górny wrote: > On Sun, 2019-12-08 at 14:48 -0500, Anthony G. Basile wrote: >> Hi everyone, >> >> I know that is my third time requesting a uid/gid for stunnel, but it >> seems that my previous request was already taken but not added to the >> uid-gid.txt file, so I didn't know about the collision. >> >> Speaking with mgorny on #gentoo-dev, he suggested that we start simply >> making a request, and he'll assign the highest free value(s) at the time. >> >> So @mgorny, can i please have a UID and GID pair for stunnel. >> > > You misunderstood me. > > I meant that if you don't care about the specific number, you just make > a request saying you'll take the highest free UID/GID pair at the time > (that said, please try to use matching UID/GID for convenience's sake). > That is, unless you want to take a specific lower number. > > Since there's no point in waiting again, just look at uid-gid.txt, find > highest free UID/GID, verify that nobody else used or requested it. > Then commit it, and make sure to update uid-gid.txt. > Okay so when you said "i'll take highest free at the time" you meant that's what the requester would say. Sorry for the misunderstanding. Okay, I'm requesting UID/GID = 492/492. I'm committing in a sec. -- 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
[gentoo-dev] RFC: request uid/gid for net-misc/stunnel
Hi everyone, I know that is my third time requesting a uid/gid for stunnel, but it seems that my previous request was already taken but not added to the uid-gid.txt file, so I didn't know about the collision. Speaking with mgorny on #gentoo-dev, he suggested that we start simply making a request, and he'll assign the highest free value(s) at the time. So @mgorny, can i please have a UID and GID pair for stunnel. Thanks! -- 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] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel
On 11/27/19 1:47 PM, Ulrich Mueller wrote: >>>>>> On Wed, 27 Nov 2019, Anthony G Basile wrote: > > > I'd suggest UID and GID 43 for tor (following Archlinux). > > Ulrich > Thanks Ulrich. Works for me. -- 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] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel
On 11/27/19 11:52 AM, Anthony G. Basile wrote: > Hi everyone, > > I'm requesting > > 1) uid/gid = 70/70 for net-dns/avahi > > 2) uid/gid = 997/995 for net-vpn/tor > > 3) uid/gid = 485/485 for net-misc/stunnel > > Both avahi and tor follow fedora. The values for stunnel were the > highest available values below 500. > Sorry but I didn't know about the list of already requested numbers at https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.txt So I need to revise the above request. Here's my new numbers: 1) For net-dns/avahi avahi uid = 61 avahi gid = 61 avahi-autoipd uid = 62 avahi-autoipd gid = 62 netdev gid = 64 2) For net-vpn/tor tor uid = 493 tor gid = 493 3) For net-misc/stunnel stunnel uid = 478 stunnel gid = 478 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] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel
On 11/27/19 1:04 PM, Joonas Niilola wrote: > Hey, > > > On 11/27/19 6:52 PM, Anthony G. Basile wrote: >> 3) uid/gid = 485/485 for net-misc/stunnel >> >> Both avahi and tor follow fedora. The values for stunnel were the >> highest available values below 500. >> > 485 has been requested for bedrock though. > > https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.txt > > > -- juippis > > Thanks. I didn't know about that list. I'm going to have to update my numbers. -- 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] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel
On 11/27/19 11:52 AM, Anthony G. Basile wrote: > > 1) uid/gid = 70/70 for net-dns/avahi > Actually I need to expand this for avahi. I need a netdev group and avahi-autoipd user/group. So, in addition to the above, I'm also requesting netdev gid = 479 avahi-autoipd uid/gid = 170/170 The avahi-autoipd values were obtained from fedora. The netdev was obtained from the highest available gid below 500. -- 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
[gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel
Hi everyone, I'm requesting 1) uid/gid = 70/70 for net-dns/avahi 2) uid/gid = 997/995 for net-vpn/tor 3) uid/gid = 485/485 for net-misc/stunnel Both avahi and tor follow fedora. The values for stunnel were the highest available values below 500. -- 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] PSA: 13.0 profiles will be removed in a week
On 6/21/19 2:54 AM, Sergei Trofimovich wrote: > On Wed, 19 Jun 2019 15:29:33 -0400 > "Anthony G. Basile" wrote: > >> On 6/19/19 3:19 AM, Sergei Trofimovich wrote: >>> >>> This is now tracked as https://bugs.gentoo.org/688342. I hope to get >>> at least some followup there. >>> >> >> When I try to look at that bug, it says I'm not authorized. I'm >> concerned about two remaining mips profiles (uclibc and musl) which I'm >> working to migrate to 17.0. I don't think that the removal of the 13.0 >> profiles will affect them, but I'd like to know. >> >> The reason this is taking so long is 1) mips is a ~arch profile so >> there's a lot of blockers and 2) my mips equipment is slow. > > Those don't seem to inherit releases/13.0. > > I've dropped releases/13.0 again: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d40fdcf1e4bdd370a13800e73a383537beef365a > > It it happens to break other profiles missing from profiles.desc please > shout and we'll reinstate those until they are sorted. > They don't. I'm hoping over the weekend to move the remaining mips uclibc and musl profiles over to the 17.0 and then I'll clean up after myself. -- 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] PSA: 13.0 profiles will be removed in a week
On 6/19/19 3:19 AM, Sergei Trofimovich wrote: > > This is now tracked as https://bugs.gentoo.org/688342. I hope to get > at least some followup there. > When I try to look at that bug, it says I'm not authorized. I'm concerned about two remaining mips profiles (uclibc and musl) which I'm working to migrate to 17.0. I don't think that the removal of the 13.0 profiles will affect them, but I'd like to know. The reason this is taking so long is 1) mips is a ~arch profile so there's a lot of blockers and 2) my mips equipment is slow. --Tony -- 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] Re: EAPI 2 must die
On 6/6/19 3:34 AM, Luca Barbato wrote: > On 06/06/2019 09:05, Matt Turner wrote: >> On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote: >>> >>> On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote: >>>> Anybody has hardware to test it? >>> >>> I can do it on timberdoodle. >> >> The issue is that the package is for "OldWorld" Macs (like 20+ years >> old). We recently dropped the bootloader, sys-boot/quik, so I think >> we'd be fine to drop sys-apps/powerpc-utils as well. >> > > Exactly :) > > I'm fine with treecleaning it. > > lu > Lol! I still have some OldWorld Macs, but I'm okay with tree cleaning it. Didn't we have some "archive" for old ebuilds? Maybe we can move it there. -- 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] Packages up for grabs from xmw@g.o
On 11/25/18 5:04 AM, Michał Górny wrote: > net-misc/arpd This is an important package. I can take care of it. -- 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] [PATCH 3/4] toolchain.eclass: Transition deps to x11-base/xorg-proto
On 4/27/18 2:31 AM, Matt Turner wrote:
> ---
> eclass/toolchain.eclass | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 2da455ad4e3b..df76dc4feb8c 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -206,11 +206,10 @@ DEPEND="${RDEPEND}
> if in_iuse gcj ; then
> GCJ_DEPS=">=media-libs/libart_lgpl-2.1"
> GCJ_GTK_DEPS="
> + x11-base/xorg-proto
> x11-libs/libXt
> x11-libs/libX11
> x11-libs/libXtst
> - x11-proto/xproto
> - x11-proto/xextproto
> =x11-libs/gtk+-2*
> virtual/pkgconfig
> "
>
These patches should be fine. It looks like you just finished
stabilizing x11-base/xorg-proto for all arches so the transition won't
cause any problems.
--
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] Regarding the State of PaX in the tree
On 4/16/18 5:14 AM, Hanno Böck wrote: > Hi, > > I honestly don't see how it would be feasible to maintain a feature > that the developers maintaining it have access to. I think you're missing a negation in there. Point well taken though. > > I get that this whole pax-thing embodies a huge part of Gentoo history > and it may feel hard for some to let it go. But things are how they are. I agree, and we'll have it in our history if hardened-sources ever comes back. The only machinery we should keep is install-xattrs which grew out of the integration of xattr PaX markings but is useful beyond just PaX. > > Regarding the fork states: I followed up on minipli's fork, which > tried to maintain newer patches of grsec for LTS kernels, but that > essentially stopped after KPTI/meltdown/retpoline. From what I know > there's no public grsec patch with kpti or any spectre fixes, thus I > would very much say you're safer these days with an upstream kernel. > Correct. I would not use the old hardened-sources or minipli's fork on any production server. > I think the only realistic way this support can be upheld would be if > some people who have access to the grsec sources commit to making sure > that it is maintained. Upstream has never responded to any email I sent them. I had a brief discussion with spender when the decision came down, and he gave me what I interpreted as an "I'm sorry this is going to adversely affect you but it has to be this way." > > > There's also another question related to this: What's the future for > Gentoo hardened? > From what I can tell hardened consists of: > * the things that try to make it compatible with grsec/pax > (more or less obsolete). > * things that are now in default profiles anyway (aslr, stack > protector). > * things that probably should be in default profiles (relro, now linker > flags) > * -fstack-check, which should eventually be replaced with > -fstack-clash-protection (only available in future gcc's) and that > should probably also go into default profiles. > * Furthermore hardened disables some useful features due to their > incompatibility with pax (e.g. sanitizers). > > So it's stuff that either is obsolete or probably should be a candidate > for main profiles. Maybe we should strive for "hardened-by-default". > You're forgetting selinux. Most of Zorry's work has made it into gcc and is now being enabled by our default toolchain. Some kernel features have also been improved upstream. With upstream carrying a lot of the work we did, I think 'hardened-by-default' minus selinux should be the goal of Gentoo. -- 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] Regarding the State of PaX in the tree
On 4/16/18 3:22 AM, Ulrich Mueller wrote: >>>>>> On Mon, 16 Apr 2018, Michał Górny wrote: > >> W dniu nie, 15.04.2018 o godzinie 20∶04 -0400, użytkownik >> Anthony G. Basile napisał: >>> The question then is, do we remove all this code? As thing stands, >>> its just lint that serves no current purpose, so removing it would >>> clean things up. The disadvantage is it would be a pita to ever >>> restore it if we ever wanted it back. While upstream doesn't >>> provide their patch for free, some users/companies can purchase the >>> grsecurity patches and still use a custom hardened-sources kernel >>> with Gentoo. But since we haven't been able to test the pax >>> markings/custom patches in about a year, its hard to say how useful >>> that code might still be. > > For Emacs, hardened support was quite a headache in the past, due to > its unexec mechanism; see bugs 285778, 411439, 426394, 456970, 497498, > 515122, 529172, their duplicates, and the upstream bugs linked from > them. We cannot safely assume that any new (hardened kernel, or Emacs) > version will work out of the box. Therefore, I am inclined to either > remove the pax_kernel flag from my ebuilds, or to package.use.mask it > at least, in order to make clear that this is no longer a supported > configuration. > I was thinking particularly of emacs when I wrote this. So now not only do we have those headaches, but no way to maintain them properly. For emacs, I would just remove the pax stuff entirely and if hardened-sources ever comes back, we would then deal accordingly. >> One thing Hardened project should do is make a clear statement to >> other developers -- i.e. indicate whether I should CC hardened@ when >> someone has PaX problems and doesn't provide a patch, or just close >> the bug saying that we can't solve it without a patch. > > I would even go one step further and tell people to sort things out > with upstream. First, because I cannot reasonably upstream patches for > an unsupported configuration that I cannot test. Second, since they > have purchased the grsecurity patches, they should also ask grsecurity > for support. Why should I as an unpaid volunteer spend my time on it? > This pretty much sums up my sentiment. I want to add here that I'm upset with upstream's decision. For years we fixed many userland programs that would otherwise have remained useless with their hardening. I also worked to move the PaX flags from the elf program headers (where it sometimes broke stuff) to the much safer xattrs. grsecurity.net benefited from all this work and then threw us under the bus in their fight with whoever was abusing the license. Most unfair. > Ulrich > -- 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] Regarding the State of PaX in the tree
On 4/16/18 4:05 AM, Marc Schiffbauer wrote: > * Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr: >> Hi everyone, > > Hi Anthony, > > I vote for keeping PaX Support as I am still using it and might be doing > so in the future. > > Thanks ;) > -Marc > How are you able to test? Do you have your hands on the latest grsec patches or are you using an old kernel. Old at this point means one year old. -- 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
[gentoo-dev] Regarding the State of PaX in the tree
Hi everyone, Magnus (aka Zorry) and I have been talking about what to do with PaX in the Gentoo tree. A year ago, grsecurity.net upstream stopped providing open versions of their patches to the community and this basically brought an end to sys-kernel/hardened-sources. I waited a while before masking the package in the hope that upstream might reconsider. There were also some forks but I didn't have much confidence in them. I'm not sure that any of these forks have been able to keep up past meltdown/specter. It may be time to remove sys-kernel/hardened-sources completely from the tree. Removing the package is easy, but the issue is there is a lot of machinery in the tree that revolves around supporting a PaX kernel. This involves things like setting PaX flags on some executables either by touching the ELF program headers or the file's extended attributes, or applying custom patches. The question then is, do we remove all this code? As thing stands, its just lint that serves no current purpose, so removing it would clean things up. The disadvantage is it would be a pita to ever restore it if we ever wanted it back. While upstream doesn't provide their patch for free, some users/companies can purchase the grsecurity patches and still use a custom hardened-sources kernel with Gentoo. But since we haven't been able to test the pax markings/custom patches in about a year, its hard to say how useful that code might still be. I'm just emailing everyone to get advice. -- 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] Re: [gentoo-mips] Monthly mips@ project status for April 2018
On 4/2/18 3:39 AM, Joshua Kinard wrote: > On 4/2/2018 3:37 AM, Joshua Kinard wrote: >> On 4/1/2018 11:40 PM, Matt Turner wrote: >>> I'd like to start giving ~monthly updates on the status of mips@ in >>> Gentoo. >>> >>> Recently I received a Loongson 3A system (quad-core 1.35GHz, 16GB RAM, >>> AMD graphics) which is significantly faster and more stable than any >>> other mips system I have. >> >> Big or little endian? If little, > > Helps to finish my sentences. Except I don't remember where I was going to go > with this bit. > Its little endian. -- 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] Its time to mask sys-libs/uclibc
On 2/23/18 11:22 AM, Matthias Maier wrote: > > 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 > I already sent a news item for migrating uclibc -> uclibc-ng some years ago. After 6 years, anyone still on uclibc has a seriously broken system. I doubt migration is even possible at this point. -- 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
[gentoo-dev] Its time to mask sys-libs/uclibc
Hi everyone, So if anyone has been following uclibc, you know that its development stalled with its last official release in 2012 (https://uclibc.org/). It was forked into uclibc-ng (https://uclibc-ng.org/) which has been actively maintained since. All my uclibc work has been done using sys-libs/uclibc-ng although the profile names still retain /uclibc/ in them. Its time to mask and remove sys-libs/uclibc in favor of sys-libs/uclibc-ng. This email is just an alert to the community that I'm going to do that soon. 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? -- 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] EAPI 7 in Portage needs YOU!
On 2/19/18 5:49 AM, Michał Górny wrote: > 1. Runtime-switchable USE flags, I need to understand this. Where are the specs? -- 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] Cleaning up the uclibc and musl profiles
On 1/20/18 2:35 PM, Anthony G. Basile wrote: > I'm working on a multi-step plan to clean up the uclibc and musl > profiles to make repoman (and arch testers) happy. It will take a while > because I have to make sure I don't seriously break things for people > using them. As a first step, I think its time to clear out the ancient > uclibc profiles found at `profiles/uclibc'. They have been unused for > years. I have a PR on github if anyone wants to review: > > https://github.com/gentoo/gentoo/pull/6918 > > I'll commit it after feedback. > Okay, no feedback so I'm going to assume people are okay with this. -- 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
[gentoo-dev] Cleaning up the uclibc and musl profiles
I'm working on a multi-step plan to clean up the uclibc and musl profiles to make repoman (and arch testers) happy. It will take a while because I have to make sure I don't seriously break things for people using them. As a first step, I think its time to clear out the ancient uclibc profiles found at `profiles/uclibc'. They have been unused for years. I have a PR on github if anyone wants to review: https://github.com/gentoo/gentoo/pull/6918 I'll commit it after feedback. -- 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] Re: Managing updates on many identical Gentoo systems
On 1/19/18 10:03 AM, Anthony G. Basile wrote: > On 1/19/18 9:45 AM, Alec Warner wrote: >> On Thu, Jan 18, 2018 at 5:13 PM, Bill Kenworthy wrote: >> >>> On 18/01/18 23:36, Duncan wrote: >>>> Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excerpted: >>>> >>>>> I'm trying to design an update system for many identical Gentoo systems. >>>>> Using a binhost is obvious, but there are still problems with this >>>>> approach. >>>>> >>> >>> I'd suggest go for a semi diskless OS - boot them from one central image >>> with an individual overlay filesystem with local customisations. NFS >>> mount the common directories. >>> >>> you just have a one central host to build for and don't need to worry >>> about portage everywhere. >>> >>> Worked ok with a small number of mythtv frontends. >>> >> >> It doesn't work if you have a WAN; NFS needs low latencies between the NFS >> server and the client or you will have a bad time. >> >> > > Zac pretty much nailed the requirements in bug #644990. You should not > need the portage tree at all, neither locally nor via any network > filesystem. He mentions there that it is currently possible via "a > dummy profile", but I'm not sure what he means by that yet or how to set > one up. I'll read his bug #640318 and try to figure it out. > > Thanks guys, I'm glad people at least recognized the usefulness of such > a possibility. > Okay, I have a workable solution to my question. I was able to get binhost working with a portage tree containing ONLY /profiles and /eclass. That's 12MB and 2.8MB in size, respectively, and I can probably dump a bunch of the unused profile directories slimming that down. With just those two directories in PORTDIR, emerge -K pulls down the update packages from BINHOST and installs them. @zac any comments about this approach? Is it likely to break? -- 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] Re: Managing updates on many identical Gentoo systems
On 1/19/18 9:45 AM, Alec Warner wrote: > On Thu, Jan 18, 2018 at 5:13 PM, Bill Kenworthy wrote: > >> On 18/01/18 23:36, Duncan wrote: >>> Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excerpted: >>> >>>> I'm trying to design an update system for many identical Gentoo systems. >>>> Using a binhost is obvious, but there are still problems with this >>>> approach. >>>> >> >> I'd suggest go for a semi diskless OS - boot them from one central image >> with an individual overlay filesystem with local customisations. NFS >> mount the common directories. >> >> you just have a one central host to build for and don't need to worry >> about portage everywhere. >> >> Worked ok with a small number of mythtv frontends. >> > > It doesn't work if you have a WAN; NFS needs low latencies between the NFS > server and the client or you will have a bad time. > > Zac pretty much nailed the requirements in bug #644990. You should not need the portage tree at all, neither locally nor via any network filesystem. He mentions there that it is currently possible via "a dummy profile", but I'm not sure what he means by that yet or how to set one up. I'll read his bug #640318 and try to figure it out. Thanks guys, I'm glad people at least recognized the usefulness of such a possibility. -- 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
[gentoo-dev] Managing updates on many identical Gentoo systems
Hi everyone, I'm trying to design an update system for many identical Gentoo systems. Using a binhost is obvious, but there are still problems with this approach. Unless there's some magic I don't know about (and this is why I'm sending this email) each machine still needs to have the portage tree installed locally (1.5 GB) or somehow mounted by a network filesystem (which is not practical if the machines are not on a local network). Furthermore, each machine would have to run emerge locally to do the calculation of what packages need updating. This procedure is redundant because each machine is housing the same data and doing the same dependence-tree calculation. It should be possible to do this calculation on a centralized binhost and simply communicate the update information to the remote machines. They would then only have to download the .tbz2's and install them, keeping a tidy /var/db/pkg. Thus they avoid having to house the portage tree and burning cpu cycles that just calculate redundant information. I'm inspired here by OpenBSD's pkg_add which doesn't require all of ports to be installed, and mender which is a Any ideas? -- 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] [PATCH v3] profiles.desc: Lower some profiles with broken depgraph from dev to exp
On 1/11/18 4:47 PM, Michał Górny wrote: > > I withdraw this since everyone obviously has his special workflow and we > can't touch anything. Now the CI report is 3.5M large and lists over 900 > broken packages. Please start looking into fixing your profiles. Thank > you. > Now that you explained the issue to me on IRC, I'm going to work towards restructuring the uclibc and musl profiles so that they inherit in a manner similar to hardened. I suspect this will clear out a lot of the issues reported at [1]. It should also give those profiles more longevity. Its a fair bit of work, so I'll ask for some patience. [1] https://qa-reports.gentoo.org/output/gentoo-ci/output.html -- 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] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp
/multilib/n64 exp > > # Nios II Profiles > @@ -240,22 +240,22 @@ x86 default/linux/x86/17.0/developer > stable > x86 default/linux/x86/17.0/systemd stable > > # Gentoo/FreeBSD Profiles > -amd64-fbsd default/bsd/fbsd/amd64/9.1 dev > -amd64-fbsd default/bsd/fbsd/amd64/11.1 dev > +amd64-fbsd default/bsd/fbsd/amd64/9.1 exp > +amd64-fbsd default/bsd/fbsd/amd64/11.1 exp > amd64-fbsd default/bsd/fbsd/amd64/9.1/clangexp > amd64-fbsd default/bsd/fbsd/amd64/11.1/clang exp > sparc-fbsd default/bsd/fbsd/sparc/8.2 exp > -x86-fbsd default/bsd/fbsd/x86/9.1dev > -x86-fbsd default/bsd/fbsd/x86/11.1 dev > +x86-fbsd default/bsd/fbsd/x86/9.1exp > +x86-fbsd default/bsd/fbsd/x86/11.1 exp > > > @@ -290,37 +290,37 @@ x86 default/linux/musl/x86 > exp > x86 hardened/linux/musl/x86 exp > > # Non-embedded uclibc profiles > -amd64default/linux/uclibc/amd64 > dev > -amd64hardened/linux/uclibc/amd64 > dev > -arm default/linux/uclibc/arm/armv7a dev > -arm hardened/linux/uclibc/arm/armv7adev > -mips default/linux/uclibc/mips dev > -mips hardened/linux/uclibc/mips dev > -mips default/linux/uclibc/mips/mipseldev > -mips hardened/linux/uclibc/mips/mipsel dev > -ppc default/linux/uclibc/ppcdev > -ppc hardened/linux/uclibc/ppc dev > -x86 default/linux/uclibc/x86dev > -x86 hardened/linux/uclibc/x86 dev > +amd64default/linux/uclibc/amd64 > exp > +amd64hardened/linux/uclibc/amd64 > exp > +arm default/linux/uclibc/arm/armv7a exp > +arm hardened/linux/uclibc/arm/armv7aexp > +mips default/linux/uclibc/mips exp > +mips hardened/linux/uclibc/mips exp > +mips default/linux/uclibc/mips/mipselexp > +mips hardened/linux/uclibc/mips/mipsel exp > +ppc default/linux/uclibc/ppcexp > +ppc hardened/linux/uclibc/ppc exp > +x86 default/linux/uclibc/x86exp > +x86 hardened/linux/uclibc/x86 exp > Dropping the uclibc and musl profiles to exp will seriously break things for me. I'm going to say no to this. -- 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] Patches to update toolchain.eclass to EAPI=5
On 12/30/17 12:18 PM, Andreas K. Huettel wrote: > Am Samstag, 30. Dezember 2017, 13:22:52 CET schrieb Anthony G. Basile: >> Hi everyone, >> >> We've been stuck on EAPI=4 with toolchain.eclass for a while. This is >> causing problems with subslotting libraries like mpfr, mpc, gmp and isl >> that gcc depend on (see bug #642316). I went through and made the >> changes necessary to get the eclass up to EAPI=5 and compile tested >> across the board (ie all dependent ebuilds) for amd64. Everything looks >> good, so please review and I'll commit if we're okay. > > - confgcc+=( $(use_enable altivec) ) > + in_iuse altivec && confgcc+=( $(use_enable altivec) ) > > ^ Just as an example, such a construct may change the "default setting" when > no altivec useflag exists... > > Imagine that upstream enables altivec by default (?). In earlier eapis, > use_enable with a non-existing useflag returned --disable-altivec (?). Now, > without the useflag, no setting is passed to configure, and it's enabled. > > So, while this all works in principle, it may need careful per-flag review. > Okay so I tested and found that there is no change in the default settings due to the above construct (and there are a few). The way I did it was I built >=gcc-4.9.4 with and without the toolchain.eclass patch and compared the config.log's (there's about 33 per version of gcc). There were no substantial differences. If there would have been a change in the default behavior, then lines like following would have shown a difference. $ /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include/g++-v7 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 7.2.0 p1.1 --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --disable-default-pie --enable-default-ssp I didn't test earlier gcc versions because they're masked. I tested only on amd64 but I think that's oaky. The only flag my tests don't cover is the altivec flag (which is for ppc/ppc64), but it defaults off on all gcc versions. I think this puts your concern to rest. -- 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] Patches to update toolchain.eclass to EAPI=5
On 12/30/17 9:13 AM, Anthony G. Basile wrote:
> On 12/30/17 9:08 AM, Michael Orlitzky wrote:
>> On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
>>> use_if_iuse !nopie && return 0
>>
>> Does this work? The "use" function supports negation (undocumented, but
>> it's in the PMS), but I don't think use_if_iuse does.
>>
>
> Okay I'll read the code and test. You're right that I just assumed it
> worked liked "use" wrt negation so the semantics need to be checked.
>
> Thanks for looking this over carefully.
>
It looks like it would not work as expected because eutils.eclass has
in_iuse() {
debug-print-function ${FUNCNAME} "${@}"
[[ ${#} -eq 1 ]] || die "Invalid args to ${FUNCNAME}()"
local flag=${1}
local liuse=( ${IUSE} )
has "${flag}" "${liuse[@]#[+-]}"
}
use_if_iuse() {
in_iuse $1 || return 1
use $1
}
So $1 in use_if_iuse binds to "!nopie" and then in in_iuse again to
"!nopie" which then messes up the has line, looking for a flag named
"!nopie" in IUSE which will always be true.
I'll change that line to
use_if_iuse nopie || return 0
Grepping the tree, I see only instances of
if ! use_if_iuse X ...
which is good.
--
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] Patches to update toolchain.eclass to EAPI=5
On 12/30/17 9:08 AM, Michael Orlitzky wrote: > On 12/30/2017 07:22 AM, Anthony G. Basile wrote: >> use_if_iuse !nopie && return 0 > > Does this work? The "use" function supports negation (undocumented, but > it's in the PMS), but I don't think use_if_iuse does. > Okay I'll read the code and test. You're right that I just assumed it worked liked "use" wrt negation so the semantics need to be checked. Thanks for looking this over carefully. -- 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
[gentoo-dev] Patches to update toolchain.eclass to EAPI=5
Hi everyone,
We've been stuck on EAPI=4 with toolchain.eclass for a while. This is
causing problems with subslotting libraries like mpfr, mpc, gmp and isl
that gcc depend on (see bug #642316). I went through and made the
changes necessary to get the eclass up to EAPI=5 and compile tested
across the board (ie all dependent ebuilds) for amd64. Everything looks
good, so please review and I'll commit if we're okay.
--
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
From b4a707673b7a3e36959a071292807945b07fd018 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile"
Date: Sat, 30 Dec 2017 06:56:29 -0500
Subject: [PATCH 1/2] toolchain.eclass: update to EAPI=5 standards
This eclass is inherited by ebuilds in sys-devel/{gcc,kgcc64,gcc-apple},
each which make use of different IUSE flags. This causes problems with
`use X` construcitons when X is not in the IUSE flags. At EAPI=4 this
simply emitted a warning, while at EAPI=5 this is an error. We update
the eclass to make use of use_if_iuse and similar constructions where
necessary to bring the eclass into compliance with EAPI=5.
Signed-off-by: Anthony G. Basile
---
eclass/toolchain.eclass | 69 ++---
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index a038303ec7f..bf6aa89e2fb 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -496,7 +496,7 @@ toolchain_src_prepare() {
do_gcc_PIE_patches
epatch_user
- if ( tc_version_is_at_least 4.8.2 || use hardened ) && ! use vanilla ;
then
+ if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use
vanilla ; then
make_gcc_hard
fi
@@ -538,7 +538,7 @@ toolchain_src_prepare() {
fi
# >= gcc-4.3 doesn't bundle ecj.jar, so copy it
- if tc_version_is_at_least 4.3 && use gcj ; then
+ if tc_version_is_at_least 4.3 && use_if_iuse gcj ; then
if tc_version_is_at_least 4.5 ; then
einfo "Copying ecj-4.5.jar"
cp -pPR "${DISTDIR}/ecj-4.5.jar" "${S}/ecj.jar" || die
@@ -648,20 +648,20 @@ make_gcc_hard() {
# Gcc >= 6.X we can use configurations options to turn pie/ssp on as
default
if tc_version_is_at_least 6.0 ; then
- if use pie ; then
+ if use_if_iuse pie ; then
einfo "Updating gcc to use automatic PIE building ..."
fi
- if use ssp ; then
+ if use_if_iuse ssp ; then
einfo "Updating gcc to use automatic SSP building ..."
fi
- if use hardened ; then
+ if use_if_iuse hardened ; then
# Will add some optimatizion as default.
gcc_hard_flags+=" -DEXTRA_OPTIONS"
# rebrand to make bug reports easier
BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
fi
else
- if use hardened ; then
+ if use_if_iuse hardened ; then
# rebrand to make bug reports easier
BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
if hardened_gcc_works ; then
@@ -909,7 +909,7 @@ toolchain_src_configure() {
# Use the default ("release") checking because upstream usually neglects
# to test "disabled" so it has a history of breaking. #317217
- if tc_version_is_at_least 3.4 ; then
+ if tc_version_is_at_least 3.4 && in_iuse debug ; then
# The "release" keyword is new to 4.0. #551636
local off=$(tc_version_is_at_least 4.0 && echo release || echo
no)
confgcc+=( --enable-checking="${GCC_CHECKS_LIST:-$(usex debug
yes ${off})}" )
@@ -922,7 +922,7 @@ toolchain_src_configure() {
)
# If we want hardened support with the newer piepatchset for >=gcc 4.4
- if tc_version_is_at_least 4.4 && want_minispecs ; then
+ if tc_version_is_at_least 4.4 && want_minispecs && in_iuse hardened ;
then
confgcc+=( $(use_enable hardened esp) )
fi
@@ -934,7 +934,7 @@ toolchain_src_configure() {
fi
# Support to disable pch when building libstdcxx
- if tc_version_is_at_least 6.0 && ! use pch ; then
+ if tc_version_is_at_least 6.0 && ! use_if_iuse pch ; then
confgcc+=( --disable-libstdcxx-pch )
fi
@@ -1058,12 +1058,12 @@ toolchain_src_configure()
Re: [gentoo-dev] Projects up for grabs: cron, m68k
On 12/21/17 12:19 AM, Jason Zaman wrote: > On Wed, Dec 20, 2017 at 06:29:57PM +0100, Hans de Graaff wrote: >> On Wed, 2017-12-20 at 18:02 +0100, Michał Górny wrote: >>> >>> sys-process/vixie-cron >> >> My understanding is that vixie-cron is no longer maintained and sys- >> process/cronie is the drop-in replacement that is now also suggested as >> the default cron in the handbook. >> >> https://archives.gentoo.org/gentoo-dev/message/d898f86f805909eb72aba61d >> 2dca8523 >> >> I seem to recall a more recent discussion about this as well, but can't >> find it at the moment. >> >> Perhaps it is time to mask vixie-cron for removal? > > I just updated the SELinux patch on vixie-cron and stabilized it a while > ago, it works fine and doesnt need all that much maintenance. I vote > keep it, i'll look after it. If it has some big architectural issues > later then we can last-rite it but its been reliable so far. > > I added myself to the Cron project with blueness. > > -- Jason > > Jason, much appreciated. Also thanks Michal for noticing that cron needed love. -- 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
[gentoo-dev] Package up for grab
Hi everyone, I was maintaining the following package net-p2p/tribler but I just dropped it to maintainer-needed. Someone asked me for it, but it needs work on bumping and its not that interesting/important to me. -- 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] Projects up for grabs: cron, m68k
On 12/20/17 12:07 PM, Anthony G. Basile wrote: > On 12/20/17 12:02 PM, Michał Górny wrote: >> Hello, everyone. >> >> Due to prolonged inactivity of Mike Frysinger (vapier), the following >> projects have had effectively no members for 6 months already: >> >> https://wiki.gentoo.org/wiki/Project:Cron >> >> sys-process/anacron [m] >> sys-process/at >> sys-process/bcron >> sys-process/cronbase >> sys-process/cronie [m] >> sys-process/dcron >> sys-process/fcron [m] >> sys-process/vixie-cron >> virtual/cron >> >> https://wiki.gentoo.org/wiki/Project:M68k >> >> sys-apps/zorroutils [m] >> sys-fs/atari-fdisk >> >> The packages listed with '[m]' have other maintainers. The remaining >> packages are solely maintained by the listed projects. >> >> If you are interested in helping out with some of those packages, please >> consider joining the appropriate project and/or co-maintaining the >> individual packages. >> >> If the projects see no activity within the next month, I will disband >> them and move the appropriate packages to maintainer-needed. >> > > Those are very important packages. I use fcron and at and I can help > take care of those. I should probably take a look a t cronbase and > virtual/cron too. > Okay a followup on my last email, I added myself to the project and will try to take care of all cron packages. -- 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] Projects up for grabs: cron, m68k
On 12/20/17 12:02 PM, Michał Górny wrote: > Hello, everyone. > > Due to prolonged inactivity of Mike Frysinger (vapier), the following > projects have had effectively no members for 6 months already: > > https://wiki.gentoo.org/wiki/Project:Cron > > sys-process/anacron [m] > sys-process/at > sys-process/bcron > sys-process/cronbase > sys-process/cronie [m] > sys-process/dcron > sys-process/fcron [m] > sys-process/vixie-cron > virtual/cron > > https://wiki.gentoo.org/wiki/Project:M68k > > sys-apps/zorroutils [m] > sys-fs/atari-fdisk > > The packages listed with '[m]' have other maintainers. The remaining > packages are solely maintained by the listed projects. > > If you are interested in helping out with some of those packages, please > consider joining the appropriate project and/or co-maintaining the > individual packages. > > If the projects see no activity within the next month, I will disband > them and move the appropriate packages to maintainer-needed. > Those are very important packages. I use fcron and at and I can help take care of those. I should probably take a look a t cronbase and virtual/cron too. -- 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] Patch for toolchain.eclass for uclibc-ng
On 11/26/17 10:50 AM, Andreas K. Huettel wrote:
> Am Samstag, 25. November 2017, 15:01:20 CET schrieb Anthony G. Basile:
>> Hi everyone,
>>
>> With the stabilization of gcc-6.4.0, the uclibc build broke because the
>> eclass requires UCLIBC_VER to be define on uclibc systems else it will
>> die(). Since uclibc specific patches are no longer needed in gcc-6 and
>> above, we don't want to error out in the eclass when the patchset is not
>> found.
>>
>
> I'd guard this so it only applies to gcc-6 and later... for the simple reason
> that
> otherwise people will try to emerge some historical gcc versions and fail..
I don't think that's necessary because the ebuild is supposed to provide
a value of UCLIBC_VER if and only if a patchset is needed, and writing
the ebuild is up to us toolchain folks. I can see the possibility of
upstream porting the fix to versions of gcc previous to 6 and then we'd
have to go back and hack away at the toolchain.eclass.
I'm planning to use the same logic for musl specific patches: if
MUSL_VER is provided in the gcc ebuild, then there is a musl patchset to
be applied, otherwise there isn't.
This seems to be the cleanest approach without littering the eclass with
tc_version_is_at_least.
Comment?
>
> Otherwise WFM
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 503f7dbe94f..58d859dfaf3 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -378,9 +378,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"'
>
--
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
[gentoo-dev] Patch for toolchain.eclass for uclibc-ng
Hi everyone,
With the stabilization of gcc-6.4.0, the uclibc build broke because the
eclass requires UCLIBC_VER to be define on uclibc systems else it will
die(). Since uclibc specific patches are no longer needed in gcc-6 and
above, we don't want to error out in the eclass when the patchset is not
found.
Note that there are some musl specific patches which I would like to
migrate out of the overlay and into the tree. In a future patch, I'd
like to duplicate the uclibc code for musl in toolchain.eclass.
Feedback welcome.
--
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
From 909298f47c98f698923c834f67e53bed3bc6ab25 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile"
Date: Sat, 25 Nov 2017 08:47:41 -0500
Subject: [PATCH] eclass/toolchain.eclass: do not die if uclibc patches are not
available
gcc-6 and above no longer needs uclibc specific patches, so we don't die if
the patchset is not available. We do, however, still apply it if UCLIBC_VER
is defined in the ebuild to future proof the code in case we need to reintroduce
the patchset in the future.
---
eclass/toolchain.eclass | 3 ---
1 file changed, 3 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 503f7dbe94f..58d859dfaf3 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -378,9 +378,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"'
--
2.13.6
[gentoo-dev] Patch for toolchain.eclass for uclibc-ng
--
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
From 909298f47c98f698923c834f67e53bed3bc6ab25 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile"
Date: Sat, 25 Nov 2017 08:47:41 -0500
Subject: [PATCH] eclass/toolchain.eclass: do not die if uclibc patches are not
available
gcc-6 and above no longer needs uclibc specific patches, so we don't die if
the patchset is not available. We do, however, still apply it if UCLIBC_VER
is defined in the ebuild to future proof the code in case we need to reintroduce
the patchset in the future.
---
eclass/toolchain.eclass | 3 ---
1 file changed, 3 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 503f7dbe94f..58d859dfaf3 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -378,9 +378,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"'
--
2.13.6
Re: [gentoo-dev] PowerPC Resources at OSU
On 9/12/17 4:30 PM, James Le Cuirot wrote: > On Mon, 11 Sep 2017 23:29:10 -0500 > R0b0t1 wrote: > >> 1) May I have access to a/the POWER server, or some other suitable >> POWER resource? If not, >> 2) is anyone available to verify that I am associated with the project >> or that I will use the resources for project related work? >> >> My intent is to experiment with the PowerPC architecture, specifically >> features found on newer POWER processors and servers. It is unlikely I >> will ever get to do this on my own as the machines run $10k-$30k. I >> requested services from OSU because GCC was not able to accommodate my >> request for hypervisor access on their system. >> >> However, having finally found the resources I've been looking for this >> whole time, it looks like OSU's nodes are virtualized and won't be >> able to do exactly what I want anyway (i.e. the GCC sysadmin was >> misinformed), so I may have accidentally wasted people's time and >> potentially tarnished Gentoo's reputation. I will make amends as best >> I can. > > As of a few months ago, we have two POWER8 guests, one big endian > (timberdoodle) and one little endian (bogsucker). We would just have > one but you can't mix big and little endian on the same system. > > After the old POWER7 timberdoodle died, I was responsible for creating > these new instances with some help from prometheanfire. Replacing > CentOS systems that had tied up all the storage from the other side of > the world with no direct raw access was an interesting challenge! > > I didn't intend to manage the systems long term though as I only use > them for building and testing Java stuff. I consider prometheanfire, > blueness, and vapier to be in charge though you may struggle getting > hold of the latter two. > > We generally only give access to devs but I am aware of one exception > we made for gnu_andrew, who works for Red Hat and provides our icedtea > ebuilds. Unfortunately I've only seen you on this list but hopefully > someone can vouch for you. I don't know whether these guests will be > suitable for your needs though. > I've been using timberdoodle, but not bogsucker. I haven't been following this thread, but if its a question of maintaining those machines, I can help out with that. -- 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] [RFC] Update toolchain.eclass to deal with .xz compressed tarball for gcc-6.4.0
On 8/2/17 5:00 PM, Mike Gilbert wrote: > On Wed, Aug 2, 2017 at 4:52 PM, Anthony G. Basile wrote: >> Hi everyone, >> >> Upstream gnu.org used to provide .gz and .bz2 compressed tarballs for >> gcc's source code. With gcc-6.4.0 however, they only provide .gz and >> .xz. Our toolchain.eclass is written only for .bz2. I'd like to commit >> the attached patch to deal with this change. A better fix would >> autodetect whether upstream has .bz2 or .xz but I'm not sure how to >> proceed with that. > > Another option would be to move the SRC_URI setting code into the > individual ebuilds, instead of setting it in the eclass. > I would still have problems with the unpack which I can't override. Also, [Arfrever] on IRC suggested that instead of if tc_version_is_between 6.4.0 7 ; then I use if tc_version_is_between 5.5 6 || tc_version_is_between 6.4 7 || tc_version_is_at_least 7.2 ; then to better future proof the code. The assumption here being that gnu.org will continue using .xz instead of .bz2 going forward which seems reasonable. -- 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
[gentoo-dev] [RFC] Update toolchain.eclass to deal with .xz compressed tarball for gcc-6.4.0
Hi everyone,
Upstream gnu.org used to provide .gz and .bz2 compressed tarballs for
gcc's source code. With gcc-6.4.0 however, they only provide .gz and
.xz. Our toolchain.eclass is written only for .bz2. I'd like to commit
the attached patch to deal with this change. A better fix would
autodetect whether upstream has .bz2 or .xz but I'm not sure how to
proceed with that.
--
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
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index db6e643148c..3114bd85832 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -320,7 +320,11 @@ get_gcc_src_uri() {
elif [[ -n ${SNAPSHOT} ]] ; then
GCC_SRC_URI="ftp://gcc.gnu.org/pub/gcc/snapshots/${SNAPSHOT}/gcc-${SNAPSHOT}.tar.bz2";
else
-
GCC_SRC_URI="mirror://gnu/gcc/gcc-${GCC_PV}/gcc-${GCC_RELEASE_VER}.tar.bz2"
+ if tc_version_is_between 6.4.0 7 ; then
+
GCC_SRC_URI="mirror://gnu/gcc/gcc-${GCC_PV}/gcc-${GCC_RELEASE_VER}.tar.xz"
+ else
+
GCC_SRC_URI="mirror://gnu/gcc/gcc-${GCC_PV}/gcc-${GCC_RELEASE_VER}.tar.bz2"
+ fi
# we want all branch updates to be against the main release
[[ -n ${BRANCH_UPDATE} ]] && \
GCC_SRC_URI+=" $(gentoo_urls
gcc-${GCC_RELEASE_VER}-branch-update-${BRANCH_UPDATE}.patch.bz2)"
@@ -424,7 +428,11 @@ gcc_quick_unpack() {
elif [[ -n ${SNAPSHOT} ]] ; then
unpack gcc-${SNAPSHOT}.tar.bz2
elif [[ ${PV} != ** ]] ; then
- unpack gcc-${GCC_RELEASE_VER}.tar.bz2
+ if tc_version_is_between 6.4.0 7 ; then
+ unpack gcc-${GCC_RELEASE_VER}.tar.xz
+ else
+ unpack gcc-${GCC_RELEASE_VER}.tar.bz2
+ fi
# We want branch updates to be against a release tarball
if [[ -n ${BRANCH_UPDATE} ]] ; then
pushd "${S}" > /dev/null
Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream
On 6/24/17 6:04 AM, Alexis Ballier wrote: > On Fri, 23 Jun 2017 12:28:27 -0400 > "Anthony G. Basile" wrote: > >> Hardened Gentoo has two sides to it, kernel hardening (done via >> hardened-sources) and toolchain/executable hardening. The two are >> interrelated but independent enough that toolchain hardening can >> continue on its own. The hardened kernel, however, provided PaX >> protection for executables and this will be lost. We did a lot of >> work to properly maintain PaX markings in our package management >> system and there was no part of Gentoo that wasn't touched by issues >> stemming from PaX support. > > > Good luck to them at providing a complete userland ecosystem for using > pax protection. Good luck at getting people accept and review their > often crashing asm patches at upstream projects that won't even be able > to test their benefits. > > Maybe we should start a business for this ? :) > http://static.sstic.org/videos2015/SSTIC_2015-06-03_P08_CLIP.mp4 > (This is for Patrice) Correct. Zorry, myself and others on the hardened team did a lot to make userland play nice with the hardened-kernel. It represents most of my effort in Gentoo. > > > > We'll need to decide what to do with things like USE=pic. For media > packages this is not something you usually want to enable as you can > bear the 10Mb relocations at startup to have 10% or more performance > improvement when reading your 2hours long movie. It will be a mess going forward. We will necessarily have to start dropping pax related stuff, if for no other reason than we can't support making a package work under pax if we have no pax enabled kernel to test on. Once this is gone, such bugs will float upstream to pipacs and spender. "Good luck" is right. > > > Alexis. > -- 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
[gentoo-dev] The status of grsecurity upstream and hardened-sources downstream
Hi everyone, Since late April, grsecurity upstream has stop making their patches available publicly. Without going into details, the reason for their decision revolves around disputes about how their patches were being (ab)used. Since the grsecurity patch formed the main core of our hardened-sources kernel, their decision has serious repercussions for the Hardened Gentoo project. I will no longer be able to support hardened-sources and will have to eventually mask and remove it from the tree. Hardened Gentoo has two sides to it, kernel hardening (done via hardened-sources) and toolchain/executable hardening. The two are interrelated but independent enough that toolchain hardening can continue on its own. The hardened kernel, however, provided PaX protection for executables and this will be lost. We did a lot of work to properly maintain PaX markings in our package management system and there was no part of Gentoo that wasn't touched by issues stemming from PaX support. I waited two months before saying anything because the reasons were more of a political nature than some technical issue. At this point, I think its time to let the community know about the state of affairs with hardened-sources. I can no longer get into the #grsecurity/OFTC channel (nothing personal, they kicked everyone), and so I have not spoken to spengler or pipacs. I don't know if they will ever release grsecurity patches again. My plan then is as follows. I'll wait one more month and then send out a news item and later mask hardened-sources for removal. I don't recommend we remove any of the machinery from Gentoo that deals with PaX markings. I welcome feedback. -- 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] Hardening a default profile
On 6/15/17 11:20 AM, Matthias Maier wrote: > 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 > 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. for those who don't used hardened, gcc-config -l on hardened profile gives: [1] x86_64-pc-linux-gnu-5.4.0 * [2] x86_64-pc-linux-gnu-5.4.0-hardenednopie [3] x86_64-pc-linux-gnu-5.4.0-hardenednopiessp [4] x86_64-pc-linux-gnu-5.4.0-hardenednossp [5] x86_64-pc-linux-gnu-5.4.0-vanilla while on the default profiles it gives: [1] x86_64-pc-linux-gnu-5.4.0 * [5] on the hardened profile is equivalent to [1] on the vanilla. maybe we should consider merging the hardened and default profiles? -- 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
[gentoo-dev] Update to news item 2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt
Hi everyone, Kensington suggested updating the news item on the new c++11 abi for gcc. Since this news item now appears for all new installations of gcc it can be annoying. I'm proposing to change it as below, but I have one concern. It is important for anyone upgrading from gcc-4 to gcc-5. But if an upgrade to gcc-5 removes gcc-4, then the message won't show up while it is still relevant. Any suggestions on how to proceed? index d074dbe..25f1712 100644 --- a/2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt +++ b/2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt @@ -2,9 +2,9 @@ Title: GCC 4.7 Introduced the New C++11 ABI Author: Anthony G. Basile Content-Type: text/plain Posted: 2014-10-26 -Revision: 1 +Revision: 2 News-Item-Format: 1.0 -Display-If-Installed: >=sys-devel/gcc-4.7.0 +Display-If-Installed: <=sys-devel/gcc-5 Display-If-Keyword: amd64 Display-If-Keyword: arm Display-If-Keyword: mips -- 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
[gentoo-dev] Items for Council Agenda, June 11
Hi everyone, The Gentoo Council will be meeting in two weeks. If anyone has any issues we need to discuss, please let me know and I'll put it on the agenda. Thanks. -- 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 5/14/17 6:38 AM, Michael Weber wrote: > On 05/08/2017 09:13 PM, David Seifert wrote: >> If all of this ends in one big bikeshedding fest again, I will start >> dekeywording packages. Fortunately for me, I won't get any complaints >> (because the arch teams are dead). > formal complaint, powerpc team is alive, and I'm lead. > I defer to the ppc lead's decision on this. While I am okay with dekeywording everything *but* @system for ppc, I prefer keeping ppc keywords. -- 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 5/11/17 3:17 AM, Yury German wrote: > David, > > I never said anything about stablizing. But that is fine, thank you for > the answers. > > Blueness, > > When are you proposing to making the changes. As we are about to drop > sparc from security supported arches, so we might as well add PPC to the > list. > > On 5/10/17 11:50 PM, David Seifert wrote: >> If there really is a dedicated team up >> to the task and demonstrably active in keywording/stablereq'ing, we can >> reconsider. > Soap is working on the dekeywording. I just jumped in because I wanted to make sure we didn't break the catalyst runs for stage3's and he came up with the dekeywording solution which I like. -- 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 5/10/17 3:29 PM, David Seifert wrote: > On Wed, 2017-05-10 at 22:24 +0300, Mart Raudsepp wrote: >> Ühel kenal päeval, K, 10.05.2017 kell 15:01, kirjutas Anthony G. >> Basile: >>> On 5/10/17 11:08 AM, William Hubbs wrote: >>>> On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote: >>>>> On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile >>>> to >>>>> o.org> wrote: >>>>>> 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. >>>>> >>>>> So are you willing to do the work? There are currently 68 open >>>>> keyword >>>>> requests (oldest one reported in 2011) and 48 open stable >>>>> requests >>>>> (oldest one reported in November). >>>> >>>> +1000 >>>> >>>> If we are going to keep ppc as a stable profile, someone needs to >>>> do the >>>> keywording and stabilization for it. >>>> >>>> William >>>> >>> >>> the current plan by Soap et al is to drop all keywords except for >>> @system and leave the profiles stable. this works for me and >>> addresses >>> your concern. >> >> Are we talking about dropping all keywords besides @system things >> from >> ppc to ~ppc or completely? >> I guess the latter as the former doesn't solve keywording lag? >> >> >> Mart >> > > The latter, as that is the only way to restore sanity. I will be > preparing a list. > So let's make sure we're on the same page -- here's my understanding. 1) For @system packages, we will have KEYWORDS="ppc" for the stable versions and KEYWORDS="~ppc" for the rest. 2) For non @system packages we will remove both ppc and ~ppc keywords. 3) If for some reason I need to add back a package to build/maintain stage3/4, I will rekeyword myself, but other than that, we will *not* balloon the keywords. 4) I will take on the responsibility of stabilizing ppc @system packages if need be. -- 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 5/10/17 11:08 AM, William Hubbs wrote: > On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote: >> On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile >> wrote: >>> 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. >> >> So are you willing to do the work? There are currently 68 open keyword >> requests (oldest one reported in 2011) and 48 open stable requests >> (oldest one reported in November). > > +1000 > > If we are going to keep ppc as a stable profile, someone needs to do the > keywording and stabilization for it. > > William > the current plan by Soap et al is to drop all keywords except for @system and leave the profiles stable. this works for me and addresses your concern. -- 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 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 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] Packages up for grabs
On 3/26/17 3:50 PM, aide...@gentoo.org wrote: > app-crypt/md5deep I'll take this. I use it in hashing stage3's and tar'ed systems I push out. -- 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] RFC: Update bitcoin eclass to default to knots
On 3/11/17 3:13 PM, Peter Stuge wrote: > > All lines containing +knots should say knots instead. > Done. I'm getting increasingly unsatisfied with where bitcoins* is going. I think I'd like to take full ownership of it and remove all unnecessary patches. If there's anyone that wants to co-maintain it with me, I'd welcome the help. I'm busy until summer at which time I revisit the issue and try to clean up the eclass and ebuilds. -- 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] RFC: Update bitcoin eclass to default to knots
On 3/7/17 12:18 PM, Peter Stuge wrote: > Anthony G. Basile wrote: >> I proxy maintain bitcoins for luke-jr. He wants to propose a patch >> against the bitcoin eclass. The following is his proposed change. >> I'll commit it after review. > > Please do not do that, Anthony. > I don't have time nor the familiarity to properly maintain bitcoins myself. Every time Luke wants to make a change, I get nothing but negative advice - what not to do, but not what to do. If there were an unpopular package I would just drop it to maintainer-needed. But do we really want a distro that doesn't provide bitcoins? I will ignore all negative advice regarding this package unless it is balanced with positive advice. Please point out what lines of the patch should be changed and what they should be changed to, else I will commit the patch as provided. -- 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
[gentoo-dev] RFC: Update bitcoin eclass to default to knots
Hi everyone,
I proxy maintain bitcoins for luke-jr. He wants to propose a patch
against the bitcoin eclass. The following is his proposed change. I'll
commit it after review.
--Tony
Bitcoin Knots includes a number of enhancements users may find useful. I
think it would be a good idea to make it the default for Bitcoin
ebuilds (net-p2p/bitcoin-qt, net-p2p/bitcoind, and dev-util/bitcoin-tx).
Note that:
- The USE flag is being renamed from the old "ljr" to "knots" to reflect
the current naming.
- This does NOT enable the historically-controversial spamfilte
BITCOIN_POLICY.
- Knots has since 0.12 (over a year old) included a clearly different
splash screen and branding, so even if the user somehow misses the USE
flag change and explicit src_prepare warning, it is clear upfront at
startup and runtime that they are running Knots rather than Core.
- Old ebuilds are not being updated to minimise impact.
A patch against the current Portage tree is attached.
A bug tracker for this has been open for 2 months with no objections:
https://bugs.gentoo.org/show_bug.cgi?id=604520
If there are no objections in the next week, we will move forward with
deploying this change to the main Portage tree.
Please CC me on any replies, as I am not presently subscribed to the
mailing list.
Thanks,
Luke
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bas...@freeharbor.net
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
diff --git a/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
b/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
index ea538a2..1d56874 100644
--- a/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
+++ b/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
@@ -5,7 +5,7 @@ EAPI=5
BITCOINCORE_COMMITHASH="0d719145b018e28d48d35c2646a5962b87c60436"
BITCOINCORE_LJR_DATE="20170102"
-BITCOINCORE_IUSE="ljr"
+BITCOINCORE_IUSE="+knots"
BITCOINCORE_NEED_LIBSECP256K1=1
BITCOINCORE_NO_DEPEND="libevent"
inherit bitcoincore
diff --git a/dev-util/bitcoin-tx/metadata.xml b/dev-util/bitcoin-tx/metadata.xml
index a686a21..16e544a 100644
--- a/dev-util/bitcoin-tx/metadata.xml
+++ b/dev-util/bitcoin-tx/metadata.xml
@@ -10,6 +10,7 @@
Luke Dashjr
+ Build enhanced Bitcoin Knots version, rather
than Bitcoin Core
Enable Luke Dashjr's patches
diff --git a/eclass/bitcoincore.eclass b/eclass/bitcoincore.eclass
index 74cb2a3..6144fb8 100644
--- a/eclass/bitcoincore.eclass
+++ b/eclass/bitcoincore.eclass
@@ -37,7 +37,7 @@ fi
EXPORT_FUNCTIONS src_prepare src_test src_install
-if in_bcc_iuse ljr || in_bcc_iuse 1stclassmsg || in_bcc_iuse zeromq || [ -n
"$BITCOINCORE_POLICY_PATCHES" ]; then
+if in_bcc_iuse ljr || in_bcc_iuse knots || in_bcc_iuse 1stclassmsg ||
in_bcc_iuse zeromq || [ -n "$BITCOINCORE_POLICY_PATCHES" ]; then
EXPORT_FUNCTIONS pkg_pretend
fi
@@ -53,7 +53,7 @@ if [[ ! ${_BITCOINCORE_ECLASS} ]]; then
# @ECLASS-VARIABLE: BITCOINCORE_LJR_DATE
# @DESCRIPTION:
-# Set this variable before the inherit line, to the datestamp of the ljr
+# Set this variable before the inherit line, to the datestamp of the Knots
# patchset.
# @ECLASS-VARIABLE: BITCOINCORE_POLICY_PATCHES
@@ -72,6 +72,7 @@ WALLET_DEPEND="sys-libs/db:$(db_ver_to_slot "${DB_VER}")[cxx]"
LIBEVENT_DEPEND=""
UNIVALUE_DEPEND=""
BITCOINCORE_LJR_NAME=ljr
+BITCOINCORE_KNOTS_USE=knots
[ -n "${BITCOINCORE_LJR_PV}" ] || BITCOINCORE_LJR_PV="${PV}"
case "${PV}" in
@@ -87,8 +88,11 @@ case "${PV}" in
LIBSECP256K1_DEPEND="=dev-libs/libsecp256k1-0.0.0_pre20151118[recovery]"
UNIVALUE_DEPEND="dev-libs/univalue"
BITCOINCORE_LJR_NAME=knots
+ if in_bcc_iuse ljr; then
+ BITCOINCORE_KNOTS_USE=ljr
+ fi
if in_bcc_policy spamfilter; then
- REQUIRED_USE="${REQUIRED_USE} bitcoin_policy_spamfilter? ( ljr
)"
+ REQUIRED_USE="${REQUIRED_USE} bitcoin_policy_spamfilter? (
${BITCOINCORE_KNOTS_USE} )"
fi
;;
*)
@@ -201,9 +205,9 @@ DEPEND="${DEPEND} ${BITCOINCORE_COMMON_DEPEND}
if [ "${BITCOINCORE_NEED_LEVELDB}" = "1" ]; then
RDEPEND="${RDEPEND} virtual/bitcoin-leveldb"
fi
-if in_bcc_iuse ljr; then
+if in_bcc_iuse ${BITCOINCORE_KNOTS_USE}; then
if [ "${BITCOINCORE_LJR_NAME}" = "knots" ]; then
- DEPEND="${DEPEND} ljr? ( dev-lang/perl )"
+ DEPEND="${DEPEND} ${BITCOINCORE_KNOTS_USE}? ( dev-lang/perl )"
fi
fi
@@ -220,7 +224,7 @@ bitcoincore_policymsg() {
bitcoincore_pkg_pretend() {
bitcoincore_policymsg_flag=false
- if use_if_iuse ljr || use_if_iuse 1stclassms
Re: [gentoo-dev] News item for uclibc-ng
On 2/8/17 3:23 PM, Andrey Utkin wrote: > On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote: >> Hi everyone, >> >> Attached you'll find a news item for uclibc-ng. I'd like to push it out >> in a few days. >> > >> This will make sure all executables link directly against libc.so.0 (as >> reported by `readelf -d`) rather than via sym links like libdl.so.0 -> >> libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without symlink-combat: >> >> USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20 > > First quote sign is non-ascii so command doesn't work when copy-pasted > to terminal. > Thanks, I wrote this on my mac which does things like that. Is there a good utility for catching non-ascii chars? -- 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
[gentoo-dev] News item for uclibc-ng
Hi everyone, Attached you'll find a news item for uclibc-ng. I'd like to push it out in a few days. -- 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 Title: Upgrade to =sys-libs/uclibc-ng-1.0.22 Author: Anthony G. Basile Content-Type: text/plain Posted: 2017-02-10 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-libs/uclibc-ng Display-If-Profile: default/linux/uclibc/amd64 Display-If-Profile: hardened/linux/uclibc/amd64 Display-If-Profile: default/linux/uclibc/arm/armv7a Display-If-Profile: hardened/linux/uclibc/arm/armv7a Display-If-Profile: default/linux/uclibc/mips Display-If-Profile: hardened/linux/uclibc/mips Display-If-Profile: default/linux/uclibc/mips/mipsel Display-If-Profile: hardened/linux/uclibc/mips/mipsel Display-If-Profile: default/linux/uclibc/ppc Display-If-Profile: hardened/linux/uclibc/ppc Display-If-Profile: default/linux/uclibc/x86 Display-If-Profile: hardened/linux/uclibc/x86 There have been two major changes in uclibc-ng which need special attention when upgrading. Version 1.0.19 restructured the breakout libraries, libcrypt.so.0, libdl.so.0, and friends. The functions in those libraries are now included in libuClibc-0.1.0.19.so. Version 1.0.21 and above removed libc support for obstack, expecting packages to use their bundled GNU lib code. Both changes require special upgrade procedures which we outline below: 0. Because of changes in the library structure in previous versions, make sure you are working with 1.0.19 and rebuild world using emerge -evq @world This will make sure all executables link directly against libc.so.0 (as reported by `readelf -d`) rather than via sym links like libdl.so.0 -> libc.so.0. Then upgrade from 1.0.19 to 1.0.20 without symlink-combat: USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20 1. Get rid of the obstack.h header since its used by configure scripts to look for function prototypes and macros. mv /usr/include/obstack.h ~ 2. We also need to force the use of any bundled gnu lib code. We can do this by removing the definition of _GNU_OBSTACK_INTERFACE_VERSION from gnu-version.h cp /usr/include/gnu-versions.h ~ sed -i -e '/#define _GNU_OBSTACK/d' /usr/include/gnu-versions.h 3. We need to tell stdio.h that __UCLIBC_HAS_OBSTACK__ is false. We do this via the uClibc_config.h file. cp /usr/include/bits/uClibc_config.h ~ sed -i -e '/__UCLIBC_HAS_OBSTACK__/ s/1/0/' \ /usr/include/bits/uClibc_config.h 4. To be safe, you may want to back up your entire /lib directory so you can fall back should something go wrong: cp -a /lib /lib.bak 5. Now when we rebuild @world, all packages will use their bundled obstack code rather than depending on libc to provide it. ac_cv_func_obstack_vprintf=no emerge --keep-going --exclude \ sys-libs/uclibc-ng -evq @world 6. Finally updated uclibc-ng to the latest emerge =sys-libs/uclibc-ng-1.0.22 7. For good measure, rebuild the entire system emerge —evq @world
Re: [gentoo-dev] Unused profiles
On 1/22/17 3:41 PM, Michał Górny wrote: > >>>> uclibc/amd64 >>>> uclibc/arm/2.4 >>>> uclibc/mips/hardened >>>> uclibc/ppc/2.4 >>>> uclibc/ppc/hardened/2.4 >>>> uclibc/sh/2.4 >>>> uclibc/x86/2.4 >>>> uclibc/x86/2005.1/2.4 >>>> uclibc/x86/hardened/2.4 >> I'm still not sure if anyone uses these. I'm thinking maybe its time >> for the whole lot of profiles/uclibc/* to go. > If you need me to, I can look into inlining them into > default/linux/uclibc. > I don't know what you mean by "inlining" them but I'd rather not mix them in. I'd rather they were just removed or whoever is using them take care of them. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bas...@freeharbor.net GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Unused profiles
On 1/19/17 8:25 PM, Anthony G. Basile wrote: > Michal, I had a chance to look over this carefully and here's what I got: >> default/linux/mips/13.0/desktop >> default/linux/mips/13.0/developer >> default/linux/mips/13.0/mipsel/desktop >> default/linux/mips/13.0/mipsel/developer >> default/linux/mips/13.0/mipsel/multilib >> default/linux/mips/13.0/mipsel/n32/desktop >> default/linux/mips/13.0/mipsel/n32/developer >> default/linux/mips/13.0/mipsel/n64/desktop >> default/linux/mips/13.0/mipsel/n64/developer >> default/linux/mips/13.0/mipsel/o32/desktop >> default/linux/mips/13.0/mipsel/o32/developer >> default/linux/mips/13.0/multilib >> default/linux/mips/13.0/n32/desktop >> default/linux/mips/13.0/n32/developer >> default/linux/mips/13.0/n64/desktop >> default/linux/mips/13.0/n64/developer >> default/linux/mips/13.0/o32/desktop >> default/linux/mips/13.0/o32/developer These can all go. Do you want to drop a deprecated notice in them? Or shall I? > >> default/linux/powerpc/ppc64/13.0/desktop/gnome/systemd >> default/linux/powerpc/ppc64/13.0/desktop/kde/systemd >> default/linux/powerpc/ppc64/13.0/developer > > I think these can go. The systemd folks added the */systemd. I don't care to keep them but they might. */developer can definitely go. >> hardened/linux/arm/armv4 >> hardened/linux/arm/armv4t >> hardened/linux/arm/armv5te >> hardened/linux/arm/armv7a/selinux These can go. >> hardened/linux/mips/mipsel/multilib/n32 >> hardened/linux/mips/mipsel/multilib/n64 >> hardened/linux/mips/mipsel/n32 >> hardened/linux/mips/mipsel/n64 >> hardened/linux/mips/multilib/n32 >> hardened/linux/mips/multilib/n64 >> hardened/linux/mips/n32 >> hardened/linux/mips/n64 These are the only ones I had to add to profiles.desc. I need them for the lemote support. >> hardened/linux/uclibc/arm/armv6j This can go. >> uclibc/amd64 >> uclibc/arm/2.4 >> uclibc/mips/hardened >> uclibc/ppc/2.4 >> uclibc/ppc/hardened/2.4 >> uclibc/sh/2.4 >> uclibc/x86/2.4 >> uclibc/x86/2005.1/2.4 >> uclibc/x86/hardened/2.4 I'm still not sure if anyone uses these. I'm thinking maybe its time for the whole lot of profiles/uclibc/* to go. -- 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] Unused profiles
Michal, I'll look at all of the following ones over the weekend and get back to you but here's my 2 cents: > default/linux/mips/13.0/desktop > default/linux/mips/13.0/developer > default/linux/mips/13.0/mipsel/desktop > default/linux/mips/13.0/mipsel/developer > default/linux/mips/13.0/mipsel/multilib > default/linux/mips/13.0/mipsel/n32/desktop > default/linux/mips/13.0/mipsel/n32/developer > default/linux/mips/13.0/mipsel/n64/desktop > default/linux/mips/13.0/mipsel/n64/developer > default/linux/mips/13.0/mipsel/o32/desktop > default/linux/mips/13.0/mipsel/o32/developer > default/linux/mips/13.0/multilib > default/linux/mips/13.0/n32/desktop > default/linux/mips/13.0/n32/developer > default/linux/mips/13.0/n64/desktop > default/linux/mips/13.0/n64/developer > default/linux/mips/13.0/o32/desktop > default/linux/mips/13.0/o32/developer I think all of these can go except the multilib ones which can go into profiles.desc. > default/linux/powerpc/ppc64/13.0/desktop/gnome/systemd > default/linux/powerpc/ppc64/13.0/desktop/kde/systemd > default/linux/powerpc/ppc64/13.0/developer I think these can go. > hardened/linux/arm/armv4 > hardened/linux/arm/armv4t > hardened/linux/arm/armv5te > hardened/linux/arm/armv7a/selinux > hardened/linux/mips/mipsel/multilib/n32 > hardened/linux/mips/mipsel/multilib/n64 > hardened/linux/mips/mipsel/n32 > hardened/linux/mips/mipsel/n64 > hardened/linux/mips/multilib/n32 > hardened/linux/mips/multilib/n64 > hardened/linux/mips/n32 > hardened/linux/mips/n64 > hardened/linux/uclibc/arm/armv6j I think the arm can go but not the mips. I'll verify and add those to profiles.desc. > uclibc/amd64 > uclibc/arm/2.4 > uclibc/mips/hardened > uclibc/ppc/2.4 > uclibc/ppc/hardened/2.4 > uclibc/sh/2.4 > uclibc/x86/2.4 > uclibc/x86/2005.1/2.4 > uclibc/x86/hardened/2.4 > These can go except maybe uclibc/amd64. FYI, I do not use profiles/uclibc for my stuff but profiles/default/linux/uclibc. However there may be some people still using these older profiles, else I'd say kill all of profiles/uclibc. Also, we should just drop a deprecated file into these profiles for now and wait a year before removing them from the tree. -- 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] RFC: global USE c++11
On 1/3/17 4:08 AM, Justin wrote: > On 03/01/2017 08:51, Kristian Fiskerstrand wrote: >> On 01/02/2017 10:34 PM, Justin wrote: >>> >>> Seems to be very consistent in usage. >> >> But I'm not convinced it is a correct approach to have use flag changing >> this. First thing that springs to mind is if introducing something like >> that it should be done consistently across Gentoo, so a GLEP. But >> presumably a lot of packages are already built using C++11 without a use >> flag given Qt5.7 requiring it etc. >> >> If using C++11 enables different features the feature should be the use >> flag rather than C++11. Couldn't this just be determined using Autotools >> etc? What is the gain of the use flag? Immediately it sounds like it >> adds complexity without much gain. >> > > I tried to find some example usages from upstream. Two things I found > > * Most upstreams dropped the flag in recent versions > * If present, it is used to append -std=c++11 > > Probably we should keep it local and wait until it is gone everywhere > upstream. > > Justin > Agreed. Keep it local. -- 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] RFC: global USE c++11
On 1/2/17 4:34 PM, Justin wrote: > Hi all > > How about making USE="c++11" a global USE? > > Description: Build using the C++11 standard. > > Current situation: > sci-libs/dealii: Compile the library with -std=c++11 > sci-physics/herwig++: Build Herwig++ using the C++11 standard. > sci-astronomy/casacore: Build casacore using the C++11 standard > sci-libs/ceres-solver: Build ceres-solver using the C++11 standard > sci-physics/herwig++: Build Herwig++ using the C++11 standard. > sci-physics/root: Build ROOT using the C++11 standard > sci-physics/thepeg: Build ThePEG using the C++11 standard. > sci-physics/yoda: Build using the C++11 standard > > > Seems to be very consistent in usage. > > Best, > Justin > You really shouldn't start mixing different c++ abis, that's just asking for trouble. Since I'm not sure why the flag is there in those pkgs, I feel uneasy about making it a global flag. See https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/ -- 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] Changes in toolchain.eclass to enable Ada
On 12/22/16 3:11 PM, Michał Górny wrote: > On Thu, 22 Dec 2016 14:55:05 +0100 > Alfredo Tupone wrote: > >>>> I would like to start including, in the gentoo tree, GNAT-GPL >>>> built in the same way as sys-devel-gcc and selectable with gcc-config >>> >>> 1. Does this mean that GNAT-GPL build will include building a C >>> compiler? If yes, will the C compiler be installed? >> Yes, a C and a C++ compiler, and they will be installed >>> >>> 2. Will it be possible to combine GNAT-GPL with a different version of >>> regular gcc C/C++ compilers? >> No, not easily > > To be honest, I don't like this at all. This sounds like doubling > the effort on maintaining gcc, and it sounds like people using GNAT-GPL > would end up being forced to use old versions of GCC (also possibly > missing patches). > > If the Ada compiler requires Ada to boostrap anyway, can't you just > make it build the Ada compiler alone? > Yeah, I agree. -- 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] For review: News item "Deprecation of sys-libs/uclibc and migration to sys-libs/uclibc-ng"
On 9/24/16 1:34 PM, waltd...@waltdnes.org wrote: > On Sat, Sep 24, 2016 at 10:42:27AM -0400, Anthony G. Basile wrote >> Hi everyone, >> >> I'd like to commit the following news item in a couple of days. >> I'm sending it as an attachment so hopefully it'll come across >> exactly as I will commit it. >> >> Please review. Thanks. > > Glad to hear. Which mailing list(s) should users subscribe to for > questions, etc? > gentoo-embed...@lists.gentoo.org -- 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] For review: News item "Deprecation of sys-libs/uclibc and migration to sys-libs/uclibc-ng"
On 9/24/16 11:45 AM, Mike Gilbert wrote: > On Sat, Sep 24, 2016 at 10:42 AM, Anthony G. Basile > wrote: >> Hi everyone, >> >> I'd like to commit the following news item in a couple of days. I'm >> sending it as an attachment so hopefully it'll come across exactly as I >> will commit it. >> >> Please review. Thanks. > > GLEP 42 says Title should be 50 characters or less, and the body > should be wrapped at 72 characters. > Thanks, I did title < 72 and body wrapping at 80. Let me get other critiques first and I'll post an updated version. -- 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
[gentoo-dev] For review: News item "Deprecation of sys-libs/uclibc and migration to sys-libs/uclibc-ng"
Hi everyone, I'd like to commit the following news item in a couple of days. I'm sending it as an attachment so hopefully it'll come across exactly as I will commit it. Please review. Thanks. -- 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 Title: Deprecation of sys-libs/uclibc and migration to sys-libs/uclibc-ng Author: Anthony G. Basile Content-Type: text/plain Posted: 2016-09-26 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-libs/uclibc Display-If-Profile: default/linux/uclibc/amd64 Display-If-Profile: hardened/linux/uclibc/amd64 Display-If-Profile: default/linux/uclibc/arm/armv7a Display-If-Profile: hardened/linux/uclibc/arm/armv7a Display-If-Profile: default/linux/uclibc/mips Display-If-Profile: hardened/linux/uclibc/mips Display-If-Profile: default/linux/uclibc/mips/mipsel Display-If-Profile: hardened/linux/uclibc/mips/mipsel Display-If-Profile: default/linux/uclibc/ppc Display-If-Profile: hardened/linux/uclibc/ppc Display-If-Profile: default/linux/uclibc/x86 Display-If-Profile: hardened/linux/uclibc/x86 Upstream development of uClibc has been stalled since July 2015 and there hasn't been a proper release since May 2012 [1]. New patches addressing important issues have been submitted but these have not been reviewed nor have they been committed to the master branch. Furthermore, backporting even those patches which have been committed to master is now impractical as too many intermediate layers of patches conflict. For all intents and purposes, upstream uClibc is dead. Fortunately, a fork called uClibc-ng [2] was begun by Waldemar Brodkorb in February 2015 and is actively being maintained. Accordingly, Gentoo's Hardened uClibc project will be migrating to uClibc-ng as its libc provider. Currently stage3 tarballs based on sys-libs/uclibc-ng are available for all supported arches at [3] and these will become the default after October 5, 2016. Older stage3s based on sys-libs/uclibc will be removed. Unfortunately, migrating a production system from uclibc to uclibc-ng is not straightforward owing to the central role played by libc. A migration guide is provided at [4]. This has been tested on live systems with success, but the user is cautioned to plan a backup and recovery plan should something go wrong. Refs. [1] https://git.uclibc.org/uClibc/log/ [2] http://uclibc-ng.org/ [3] http://distfiles.gentoo.org/experimental/ [4] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc#Migration_to_uClibc-ng
[gentoo-dev] Review for patch to pax-utils.eclass
I'd like to commit the following change to the pax-utils.eclass to
address bug #590422. I'm submitting it to the list for review.
--
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
commit 6dcad31d0a6558eb70f5c46689fe4d4246d80bb1
Author: Anthony G. Basile
Date: Fri Aug 26 20:02:44 2016 -0400
pax-utils.eclass: do not attempt to create/convert a PT_PAX_FLAGS program
header
Support for the creation of PT_PAX_FLAGS program headers in ELF objects is
being
dropped in >=sys-devel/binutils-2.26.1. Running paxctl -C or -c either to
create
a PT_PAX_FLAGS header or to convert a PT_GNU_STACK header on such ELF
objects
results in broken executables. For backwards compatibility we continue to
support
PT_PAX_FLAGS markings with paxctl but remove these unsafe methods from the
eclass.
Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=590422
diff --git a/eclass/pax-utils.eclass b/eclass/pax-utils.eclass
index 9ed1170..386a7f6 100644
--- a/eclass/pax-utils.eclass
+++ b/eclass/pax-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
@@ -6,8 +6,8 @@
# @MAINTAINER:
# The Gentoo Linux Hardened Team
# @AUTHOR:
-# Original Author: Kevin F. Quinn
-# Modifications for bugs #365825, #431092, #520198, @ ECLASS markup: Anthony
G. Basile
+# Author: Kevin F. Quinn
+# Author: Anthony G. Basile
# @BLURB: functions to provide PaX markings for hardened kernels
# @DESCRIPTION:
#
@@ -82,11 +82,9 @@ pax-mark() {
einfo "PT_PAX marking -${flags} ${f} with
paxctl"
# First, try modifying the existing PAX_FLAGS
header.
paxctl -q${flags} "${f}" >/dev/null 2>&1 &&
continue
- # Second, try creating a PT_PAX header (works
on ET_EXEC).
- # Even though this is less safe, most exes need
it. #463170
- paxctl -qC${flags} "${f}" >/dev/null 2>&1 &&
continue
- # Third, try stealing the (unused under PaX)
PT_GNU_STACK header
- paxctl -qc${flags} "${f}" >/dev/null 2>&1 &&
continue
+ # We no longer try to create or convert a
PT_PAX header, bug #590422
+ # paxctl -qC${flags} "${f}" >/dev/null 2>&1 &&
continue
+ # paxctl -qc${flags} "${f}" >/dev/null 2>&1 &&
continue
fi
# Next try paxctl-ng -> this will not create/convert
any program headers.
Re: [gentoo-dev] base-system needs developers who care
On 8/23/16 8:03 PM, Lars Wendler wrote: > I have some kind of interest for these packages: Lars, maybe once we get some names we should get a meeting of base-system together and coordinate our efforts. In particular, I mostly have interest in those packages that make up @system for the stages I build. -- 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] base-system needs developers who care
On 8/23/16 7:17 PM, Robin H. Johnson wrote: > Over the years, the base-system package herd has grown in size. Today I've been doing some base-system related stuff because of uclibc/-ng and musl on minor arches, building stage3's for those. My involvement has been marginal because my emphasis is not mainstream, but I can start giving some of those packages love. I'm spread a bit thin, but I'm going to give away some of my less important packages. -- 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] New Working Group established to evaluate the stable tree
On 8/14/16 5:45 PM, Ciaran McCreesh wrote: > On Sun, 14 Aug 2016 23:35:58 +0200 > Kristian Fiskerstrand wrote: >> During the latest Council meeting it was determined to set up a new >> Working Group to come up with recommendations for improving the state >> of the stable tree at a later Council meeting. > > What's a Working Group, and how is it related to a Project? Shouldn't > there be a GLEP to define what a Working Group is first? > Seriously?! You mean a group of devs can't just get together to brainstorm a problem across projects? Anyhow, Kristian, I'm in. Put me on the cc list. -- 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] Lastrites: www-client/midori
On 7/31/16 7:19 AM, Pacho Ramos wrote: > # Pacho Ramos (31 Jul 2016) > # Upstream looks completely dead for a long time, doesn't reply to any > bug > # we report to them. This relies on obsolete software like (#587448) > and > # other bugs are being accumulated without any fix/attention. Removal > in a > # month if nobody comes with the fixes. > www-client/midori > I like midori. Let me take a look and see if its worthy the effort and get back to you. -- 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
[gentoo-dev] RFC: migration from uclibc to uclibc-ng
Hi everyone, Most of you know that uclibc upstream is pretty much dead. There hasn't been a official release since 2012 and there hasn't been a commit to their master branch for over a year. The situation has become impossible since important fixes really can't be backported without layers of intermediated fixes being backported first. This has lead to a fork at http://uclibc-ng.org/ which is actively maintained and has all of the fixes we need in the latest release. Since I don't want to just give up on Gentoo + uclibc, I'm going to migrate to uclibc-ng. (Parenthetically let me add that I think the real future of embedded will be musl, but still I don't want to just give up on uclibc.) After migrating, I will pretty much abandon uclibc itself and continue exclusively with uclibc-ng. The supported arches are and will continue to be amd64, armv7a (hard/soft float), mips32r2 (big endian), mipsel3 (little endian), ppc and i686. The process will be as follows: 1. Build experimental stage3's with customize /etc/portage. This is just for testing since the final stage3's should not have anything in /etc/portage. This must be completed for all arches before the next step. 2. Migrate the customized /etc/portage to profiles/default/linux/uclibc for all arches, and switch the priority in virtual/libc/libc-0.ebuild. Currently it reads: elibc_uclibc? ( || ( sys-libs/uclibc sys-libs/uclibc-ng ) ) 3. Update https://wiki.gentoo.org/wiki/Project:Hardened_uClibc with instructions on how to upgrade. 4. Start pushing out uclibc-ng base stages https://www.gentoo.org/downloads/ for amd64 and i686. I'm at step 1 for amd64 and i686. I welcome comment on any of the above. -- 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] masking and removing *coin packages
On 7/8/16 10:42 AM, Rich Freeman wrote: > On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile > wrote: >> >> Also there's some debate in IRC about whether or not these packages >> should be lastrited or dropped to maintainer-needed. These forks are >> not in good shape upstream, so I think it makes better sense to >> p.mask/lastrite and then move them to the graveyard overlay when I >> remove them from the tree in 30 days. >> > > IMO the criteria should be whether they work or not. Not whether > upstream is more or less active. There is a QA against the current version of namecoin* and upstreams newest packages are no good. > > If they're blockers on other work, by all means cull them. However, > if the biggest problem with them is that they're using a few inodes in > the repo, then they should probably stay. > I have no strong feeling here, but I do want to get rid of them. So I'm okay with maintainer-needed@ I'll let the discussion continue for a bit and then do whatever the consensus is. -- 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
Fwd: Re: [gentoo-dev] masking and removing *coin packages
Okay, I'll set the metadata.xml for both net-p2p/litecoin* and sys-process/nmon to the following: http://www.gentoo.org/dtd/metadata.dtd";> marc.p...@sunny-computing.de Marc Popp Maintainer. Assign bugs to him proxy-ma...@gentoo.org Proxy Maintainers Also there's some debate in IRC about whether or not these packages should be lastrited or dropped to maintainer-needed. These forks are not in good shape upstream, so I think it makes better sense to p.mask/lastrite and then move them to the graveyard overlay when I remove them from the tree in 30 days. I haven't acted yet, so there's still time to bikeshed ;) On 7/8/16 4:32 AM, Marc Popp wrote: > Hi Anthony, > > I would take over the litecoin* packages, but my last (and first) request > to take over nmon was not even approved it answered yet. I guess, I wasn't > following the right process. > > Thanks > Marc > > > > On Friday, 8 July 2016, Anthony G. Basile wrote: > >> Hi everyone, >> >> I emailed the list some time ago about giving away a bunch of bitcoin >> forks to see if anyone was interested in taking them. I didn't get any >> feedback so as of tomorrow I'll be masking the following for removal in >> 30 days. >> >> net-dns/namecoind >> net-dns/namecoin-qt >> >> net-p2p/bitcoinxtd >> net-p2p/bitcoinxt-qt >> >> net-p2p/litecoind >> net-p2p/litecoin-qt >> >> net-p2p/ppcoind >> net-p2p/ppcoin-qt >> >> net-p2p/primecoind >> net-p2p/primecoin-qt >> >> -- >> 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 >> >> > -- 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
[gentoo-dev] masking and removing *coin packages
Hi everyone, I emailed the list some time ago about giving away a bunch of bitcoin forks to see if anyone was interested in taking them. I didn't get any feedback so as of tomorrow I'll be masking the following for removal in 30 days. net-dns/namecoind net-dns/namecoin-qt net-p2p/bitcoinxtd net-p2p/bitcoinxt-qt net-p2p/litecoind net-p2p/litecoin-qt net-p2p/ppcoind net-p2p/ppcoin-qt net-p2p/primecoind net-p2p/primecoin-qt -- 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] why is the security team running around p.masking packages
On 7/6/16 8:11 AM, Rich Freeman wrote: > Like I said, one mistake doesn't make a trend, and we shouldn't > over-react to a mistake. However, the way to handle a mistake is for > everybody to say "this was a mistake," not "you're the only person who > has a problem with this." Let's just fix whatever broke (if it isn't > already fixed) and move on. We don't need to defend mistakes. +1 So what we don't want happening again moving forward is where a developer (me in this case) thinks he's provided the information needed for security, then the bug goes dormant 3 years, and then out of the blue a p.mask with 30 days notice until removal. Especially if it the security issue is minor. The security@g.o list has 500+ open bugs going back years. We don't want this uncertainty to loom over all developers heads. A reasonable policy here would help create clear expectations for security and other developers. I don't think I need to add more to this since K_F appears to be working on something that will address this. -- 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] why is the security team running around p.masking packages
On 7/6/16 7:30 AM, Kristian Fiskerstrand wrote: > On 07/06/2016 01:15 PM, Anthony G. Basile wrote: >> I'm also disappointed that no one else in the security team has >> recommended any internal policing in response to this. I maintain that >> forced p.masking and version bumping should not be done by the security >> team but passed to QA for review. Only QA is mandated with such powers >> by GLEP 48. > > We're discussing this in another thread already (i.e possibly a GLEP for > Security project), I'm discussing that as a member of security. > > As for any internal policing outside of public policies it is done > within the team and not on a public mailing list. The relevant public > policies are: > https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide > https://www.gentoo.org/support/security/vulnerability-treatment-policy.html > > But I agree these needs reviewing and codification in the form of a > GLEP, but as said in the other thread, need to discuss that within the > project first (I'm not lead, but have requested a team meeting already) > I like this. So let's make sure we have clear expectations and an escalation process with review before we pull the p.mask with 30 days till poof. -- 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] why is the security team running around p.masking packages
On 7/6/16 7:23 AM, Aaron Bauman wrote: > On Wednesday, July 6, 2016 8:15:24 PM JST, Anthony G. Basile wrote: >> On 7/6/16 6:54 AM, Aaron Bauman wrote: >>> On Wednesday, July 6, 2016 5:10:25 PM JST, Anthony G. Basile wrote: ... >> >> Except that I state such facts BEFORE the p.mask and you ignored it. >> Referring to bug #473770: >> >> >> >> (In reply to Anthony Basile from comment #1) >>> The CVE for this has gone nowhere. See >>> >>> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2183 >>> >>> There are no references and I can't get at the upstream bug report >>> anymore >>> since they moved to github. >> >> Actually, I found it. Its fixed: >> >> https://github.com/monkey/monkey/issues/93 >> >> >> >> >> >> Aaron Bauman gentoo-dev Security 2016-07-01 01:39:40 UTC >> >> # Aaron Bauman (1 Jul 2016) >> # Unpatched security vulnerabilities and dead upstream >> # per bugs #459274 and #473770 Removal in 30 days >> www-servers/monkeyd >> >> >> >> >> People reading following this can clearly see the problem here. >> >> I'm also disappointed that no one else in the security team has >> recommended any internal policing in response to this. I maintain that >> forced p.masking and version bumping should not be done by the security >> team but passed to QA for review. Only QA is mandated with such powers >> by GLEP 48. >> > > What kind of policing would you like to see councilman? Policing also has the meaning of policy-ing. I'd like to see better policies within the security team for escalation of security bugs. I'm suggesting passing the review onto QA, but it looks like K_F (from his other email) has other ideas which may better for a workflow. > Would you like > to see me removed from the project, because your precious package was > p.masked? I never said anything to that effect. I'm arguing a point for better policy-ing and I'm not satisfied by your solution that developers need to just better document when a security issue is fixed. monkeyd is an important package. > You have ignored every thing I have said regarding your > inability to work with the security team. Even after an apology from me > and a request to work with us you continue on with the rhetoric of > powers. It displays a lot about your inability to work with others. The problem is not an apology which I appreciate. The problem is we need better expectations of when a package is going to get p.masked on you. p.masking a package which a notice of 30 days until removal sends a very bad message to users who depend on it. Proceeding as the security team has, there is no way for a developer to know what's about to happen. Consider, I thought I'd answered the issue with bug #473770 with comment #2. > > No other developer is complaining... it is *literally* only you. > NP-Hardass's case was not even a security bug nor handled by the > security team. One of the bugs for monkeyd led to additional discovery > of insecurities regarding log files, but it took a p.mask to get your > attention. Quit pushing an agenda and work with others to make Gentoo > more secure. Everyone else is. > >> It doesn't matter, there is a problem here which needs to be addressed. I'm complaining because we need to fix a problem in our workflow. It sounds like K_F is working on a glep for that, which I applaud. > > -- 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] why is the security team running around p.masking packages
On 7/6/16 6:54 AM, Aaron Bauman wrote: > On Wednesday, July 6, 2016 5:10:25 PM JST, Anthony G. Basile wrote: >> On 7/5/16 10:52 PM, NP-Hardass wrote: >>> I think it is a little bit of a stretch to say that he's the only one to >>> have an issue. Now, I've spoken with the parties involved, so my issue >>> is resolved, but I had a package of mine bumped in the name of security >>> without being pinged/consulted at all. I'm not attempting to point >>> blame at anyone, but merely show that there are others who have been ... >> >> I agree that a ping is the necessary first step, but I'm afraid of a >> dispute between the maintainer and the security team. Bug #459274, >> which I discussed in my previous email, should never have been file and >> should never have been acted on. If the security team feels they must >> touch a package, I'd like to have QA review it. The QA leadership is >> ratified by the council and has a long history of dealing with these >> sorts of issues which are tried and true. >> >> > > So just state such facts, as you did following the p.mask, and all would > be well. It really has been and continues to be that simple. > Except that I state such facts BEFORE the p.mask and you ignored it. Referring to bug #473770: (In reply to Anthony Basile from comment #1) > The CVE for this has gone nowhere. See > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2183 > > There are no references and I can't get at the upstream bug report anymore > since they moved to github. Actually, I found it. Its fixed: https://github.com/monkey/monkey/issues/93 Aaron Bauman gentoo-dev Security 2016-07-01 01:39:40 UTC # Aaron Bauman (1 Jul 2016) # Unpatched security vulnerabilities and dead upstream # per bugs #459274 and #473770 Removal in 30 days www-servers/monkeyd People reading following this can clearly see the problem here. I'm also disappointed that no one else in the security team has recommended any internal policing in response to this. I maintain that forced p.masking and version bumping should not be done by the security team but passed to QA for review. Only QA is mandated with such powers by GLEP 48. -- 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] why is the security team running around p.masking packages
On 7/6/16 4:25 AM, Kristian Fiskerstrand wrote: > > That said, the reason the mask is questionable in this case is the low > severity of the bug, but that isn't a general case. Bug #582240 - sys-devel/gcc: multiple vulnerabilities If the security team proceeded with gcc as it did with monkeyd, it would be masking it now. It doesn't have to be a general case. Looking through the security bugs there's so much link, its hard to tell what's good and what's not. > > If council approval of special projects as lead is an important factor, > maybe we should rather also approve security leads? > Approving a security lead is not sufficient. QA is governed by GLEP 48. The very procedure of producing a glep means scrutiny by the community as to its scope, mandate, procedure and powers. By the security team simply thinking it has the powers to p.mask and bump packages, its is essentially circumventing Gentoo governance. If it needs these powers, it should go through QA. -- 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] why is the security team running around p.masking packages
On 7/5/16 10:52 PM, NP-Hardass wrote: > > I think it is a little bit of a stretch to say that he's the only one to > have an issue. Now, I've spoken with the parties involved, so my issue > is resolved, but I had a package of mine bumped in the name of security > without being pinged/consulted at all. I'm not attempting to point > blame at anyone, but merely show that there are others who have been > affected by security workflow sometimes going around the maintainer. I > don't think there should be any harm in acknowledging that, and striving > to make sure it doesn't happen in the future, where possible. > I agree that a ping is the necessary first step, but I'm afraid of a dispute between the maintainer and the security team. Bug #459274, which I discussed in my previous email, should never have been file and should never have been acted on. If the security team feels they must touch a package, I'd like to have QA review it. The QA leadership is ratified by the council and has a long history of dealing with these sorts of issues which are tried and true. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: [gentoo-dev] why is the security team running around p.masking packages
On 7/5/16 10:43 PM, Aaron Bauman wrote: > > That CVE request was not from Ago. It was from the respective OSS ML > referenced in the URL field of the bug report. Not to mention, you as a > maintainer were able to discover another issue with that package and fix > it. > You never bothered to follow that OSS ML link. For others reading this email, here is the link: http://www.openwall.com/lists/oss-security/2013/02/24/5 Here's a copy of that entire email: Date: Sun, 24 Feb 2013 20:00:57 +0100 From: Agostino Sarubbo To: oss-secur...@...ts.openwall.com Subject: CVE request: monkeyd world-readable logdir Monkeyd, a small, fast, and scalable web server, produces, at least on gentoo a world-readable log. # ls /var/log/monkeyd/master.log -la -rw-r--r-- 1 root root 0 Feb 24 19:56 /var/log/monkeyd/master.log Upstream site: http://www.monkey-project.com/ -- Agostino Sarubbo Gentoo Linux Developer That is what you p.masked on. That's it. Neither you nor Ago really understood the issue with monkeyd's logging. There were no followup emails and no CVE was assigned. Its junk. By both initiating and following through on such low quality bugs, you are damaging the reputation of the security project. >> I personally would like to see only QA oversee any forced p.maskings and >> have the security team pass that task over to QA for review. By forced >> I mean without the cooperation of the maintainer. >> > > Again, no one else has had an issue with this except you. The one who > doesn't want to cooperate. Having people review your work is a good idea, no? So in cases where security wants to touch a packages, why not ping the maintainer first and in case of a dispute or no response, escalate the issue to QA who will review the problem and act. Are you okay with this change in procedure? -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: [gentoo-dev] why is the security team running around p.masking packages
On 7/4/16 11:26 PM, Aaron Bauman wrote: > > Finally, that does not dissolve the developer of providing usable, > substantiated, and verifiable information regarding the > vulnerabilities. The idea that a developer gets to choose whether or > not they do so should not be considered. Anthony's verbiage on Freenode > was very frank, in that if he chose to do so he would. We ask for all > developers to assist and work together with us to fix these issues. You > can see the fruits of such information from the developer following Alex > Legler's comments on the bug and my follow up actions. > > -Aaron > 1) In bug #473770 upstream gave sufficient information. I stated so in comments #1 and #2 with links. You ignored this fact and proceeded to p.mask in comment #3. This CVE should never have been filed. Its junk. 2) Bug #459274 is not a security bug. A CVE request was filed by Ago which, as far as I can tell, went no where. The log file in question does not disclose much more than one could obtain with just ps and netstat. I fixed a related issue with access.log in bug #459274. 3) My point on IRC is that you are acting on junk CVEs and I question your judgment. You can't produce "substantiated and verifiable information" on junk. Your above paragraph eclipses that side of my argument and strawmans me. I personally would like to see only QA oversee any forced p.maskings and have the security team pass that task over to QA for review. By forced I mean without the cooperation of the maintainer. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
[gentoo-dev] why is the security team running around p.masking packages
I'm going to ask the security team to please stop running around p.masking packages without acknowledgement from the maintainers. I'm referring in particular to commit 135b94c85950254f559f290f4865bce8b349a917 regarding monkeyd. Both of the cited "security bugs" were long fixed, and even if the were not, they do not merit masking because they were at best some information leakage with minor impact. I have reverted that commit and would ask that security stop this practice. -- 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
