[gentoo-dev] Last rites: app-doc/linux-gazette
profiles: Last rite app-doc/linux-gazette Upstream deleted all files more than 6 years ago and is inactive. Masked for removal on 2018-02-01 app-doc/linux-gazette-base app-doc/linux-gazette-all app-doc/linux-gazette Bug: https://bugs.gentoo.org/628960 -- Best regards, Jonas Stein signature.asc Description: OpenPGP digital signature
Re: OT: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
On Wed, Dec 27, 2017 at 4:16 PM, Nils Freydank wrote: > Am Mittwoch, 27. Dezember 2017, 22:33:03 CET schrieb R0b0t1: >> On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs wrote: >> > As he said, he contactedd the maintainers in ample time, so I would say >> > that since they didn't respond he went ahead in good faith. I'll get the >> > link later, but as I recall, the dev manual recommends a 2-4 week wait >> > for maintainers not responding then we can assume that what we are doing >> > is ok. >> >> This assumes there is some pressing need for the change to take place, >> which I am not sure there is. I can understand wanting to make the >> change for consistency's sake, but the feature is important enough >> that I think a suitable replacement should explicitly be found before >> continuing. E.g. affirmative feedback from all affected packages. > > Often a fix timeline is the only way to achieve any responses - or at least > get stuff done, even if the matter itself is not urgent at all. In this > specific case the points Michael had were quite clear, and the timespan of > two month was long enough to react somehow (at least in the context of typical > periods in Gentoo, e.g. last rite/removal period of 30 days). > Yes, but as per past comments it seems some people think the action taken was slightly inappropriate. It feels like you didn't read what I said: in some cases, a fix timeline may not be appropriate. I don't know when that is. > On topic: There are some users including myself that find cracklib mostly > annoying. I use strong passwords (or ssh keys only) where I can, and cracklib > annoys me with the request to set "secure passwords" for a container > playground, where I want root:test as login credentials. > Beside that the point that profiles in general should contain as least USE as > possible (see the bug report for that). > I must be confused, because this is the only part of your message that is offtopic. >> Enforcement of rules or Gentoo development guidelines does not happen >> consistently, and the times when rules are enforced "for consistency's >> sake" seem completely arbitrary. There seems to be no extant problems >> caused by the flag as set, so why focus on this specifically? > > To me these times look as they're based upon agreement between the involved > parties, and in itself consistently, e.g. at least 30 days masking before > removal out of the tree, or in this case at least two to four weeks to let > others respond. > But why male models^H^H^H^H^H^H^H^H^H^H^Hfocus on this issue in particular? If I understand the situation, nothing is actually *broken.* That is why I was questioning consistency. >> There is a lot of discussion of not burdening developers with >> pointless talk or changes. If that is a goal, then why is this posting >> receiving so many replies? > > With all due respect, your posting didn't bring any new relevant aspects into > this thread on this mailing list with the explicit focus and topic of Gentoo > development, and might be exactly part of the "pointless talk" you mention. > > My one isn't better; I just want to point that out to you, because you tend to > write messages with this kind of meta questions about the cause of things. > > If you want to discuss this, I'd prefer another place than this list. > As someone watching from the outside I see this type of discussion crop up from time to time. All I am suggesting is thinking about actions before they are acted out. This isn't to say what was undertaken was not thought out - but the patterns of behavior I see that that decision exists within are what I am suggesting needs more careful consideration. If you can not see the utility in thinking about thinking, I am not sure we would have much to talk about. Respectfully, R0b0t1
OT: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
Am Mittwoch, 27. Dezember 2017, 22:33:03 CET schrieb R0b0t1: > On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs wrote: > > As he said, he contactedd the maintainers in ample time, so I would say > > that since they didn't respond he went ahead in good faith. I'll get the > > link later, but as I recall, the dev manual recommends a 2-4 week wait > > for maintainers not responding then we can assume that what we are doing > > is ok. > > This assumes there is some pressing need for the change to take place, > which I am not sure there is. I can understand wanting to make the > change for consistency's sake, but the feature is important enough > that I think a suitable replacement should explicitly be found before > continuing. E.g. affirmative feedback from all affected packages. Often a fix timeline is the only way to achieve any responses - or at least get stuff done, even if the matter itself is not urgent at all. In this specific case the points Michael had were quite clear, and the timespan of two month was long enough to react somehow (at least in the context of typical periods in Gentoo, e.g. last rite/removal period of 30 days). On topic: There are some users including myself that find cracklib mostly annoying. I use strong passwords (or ssh keys only) where I can, and cracklib annoys me with the request to set "secure passwords" for a container playground, where I want root:test as login credentials. Beside that the point that profiles in general should contain as least USE as possible (see the bug report for that). > Enforcement of rules or Gentoo development guidelines does not happen > consistently, and the times when rules are enforced "for consistency's > sake" seem completely arbitrary. There seems to be no extant problems > caused by the flag as set, so why focus on this specifically? To me these times look as they're based upon agreement between the involved parties, and in itself consistently, e.g. at least 30 days masking before removal out of the tree, or in this case at least two to four weeks to let others respond. > There is a lot of discussion of not burdening developers with > pointless talk or changes. If that is a goal, then why is this posting > receiving so many replies? With all due respect, your posting didn't bring any new relevant aspects into this thread on this mailing list with the explicit focus and topic of Gentoo development, and might be exactly part of the "pointless talk" you mention. My one isn't better; I just want to point that out to you, because you tend to write messages with this kind of meta questions about the cause of things. If you want to discuss this, I'd prefer another place than this list. Regards, Nils -- GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B' Nils Freydank signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs wrote: > As he said, he contactedd the maintainers in ample time, so I would say > that since they didn't respond he went ahead in good faith. I'll get the > link later, but as I recall, the dev manual recommends a 2-4 week wait > for maintainers not responding then we can assume that what we are doing > is ok. This assumes there is some pressing need for the change to take place, which I am not sure there is. I can understand wanting to make the change for consistency's sake, but the feature is important enough that I think a suitable replacement should explicitly be found before continuing. E.g. affirmative feedback from all affected packages. Enforcement of rules or Gentoo development guidelines does not happen consistently, and the times when rules are enforced "for consistency's sake" seem completely arbitrary. There seems to be no extant problems caused by the flag as set, so why focus on this specifically? There is a lot of discussion of not burdening developers with pointless talk or changes. If that is a goal, then why is this posting receiving so many replies? Respectfully, R0b0t1
Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution
On Wed, Dec 27, 2017 at 05:18:11PM +0100, Francesco Riosa wrote: > > > On 12/27/17 16:47, Mike Gilbert wrote: > > On Tue, Dec 26, 2017 at 7:18 PM, Robin H. Johnson > > wrote: > >> On Tue, Dec 26, 2017 at 11:22:50PM +0100, Jason A. Donenfeld wrote: > >>> You might want to mention that alternatively, uninstalling > >>> openrc&sysvinit&netifrc on a systemd profile system is fine to do > >>> these days, despite the warning. > >> If you're using netifrc's systemd support, this would break your > >> networking ;-). > > I guess the winky face means you are not serious, but I'll respond anyway. > > :-) > > > > I suspect the number of people using systemd with netifrc is in the > > single digits. I would rather not clutter the news item to account for > > this scenario. It was a GSOC project, but since then I hadn't heard of any users of it, other than the GSOC student, and haven't had any bug reports of it being broken. I'm happy to hear it has at least one other user in Francesco. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
On Wed, Dec 27, 2017 at 05:42:04PM +0200, Mart Raudsepp wrote: > On K, 2017-12-27 at 09:57 -0500, Michael Orlitzky wrote: > > > 2) What you plan to do to have USE=cracklib enabled by default. Two > > > people suggested you should keep this (one way or another) but > > instead > > > everyone is now without it enabled by default. > > > > I plan to do nothing, because I think it should be disabled by > > default > > like all other USE flags. I've CC'ed all of the maintainers who might > > want to add the default to IUSE, and apparently none of them do. The > > hardened project and base-system are also CCed/assigned in case one > > of > > them wanted to adopt the default. > > > > The base profile is the wrong place to enable USE=cracklib, but there > > are better places. If none of the people in charge of those places > > want > > to enable the flag, then maybe it should remain disabled. > > If USE=cracklib is ever removed from base/make.defaults, then this IUSE > default enabling should be done before it is removed for many of the > places where it helps password safety, not afterwards when some > maintainers happen to see you've done it some months later, after we I would say that it is up to you to show where it was approved for adding to base/make.defaults by showing where it was discussed on this list, or showing where it was added in the profile revision history. A bug and that has been open as long as he said it was earlier in this thread, as well as notification here with a 72 hour delay as well as contacting the maintainers directly as far in advance as he did seems reasonable to me. I will look at this more when I get back to my home system, but on the face of it, I would support his change. > > If you need more opposing, then consider this one, as long as this > preparation work isn't done. Just removing it because maintainers > didn't get to it in your timeline isn't something I would see OK. If > you want to make such a base profile change, then I believe you should > contact the maintainers and see which one wants it default disabled, > and which default enabled; do the default enabled changes and only > afterwards you can touch a base default USE flag, otherwise you are > making a change to all these maintainers packages without their > consent. It IS an effective change to their package, and you are > effectively doing non-maintainer changes to them. As he said, he contactedd the maintainers in ample time, so I would say that since they didn't respond he went ahead in good faith. I'll get the link later, but as I recall, the dev manual recommends a 2-4 week wait for maintainers not responding then we can assume that what we are doing is ok. I will look into this more when I get back to my home system, but as a member of base-system, tentavely count me as supporting his change. To respond to the comment about preparation work: Again, I haven't checked the bug, but if it has been there a while and received no input from base-system etc, there may not be any, so removing it from base/make.defaults would be the way to go. William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
On 12/27/2017 10:42 AM, Mart Raudsepp wrote: > If you want to make such a base profile change, then I believe you > should contact the maintainers and see which one wants it default > disabled, and which default enabled; do the default enabled changes > and only afterwards you can touch a base default USE flag The bug is titled "base/make.defaults: unset USE=cracklib by default" and it says, I'm CCing the maintainers of all affected packages. If anyone would like us to wait until they've set "+cracklib" in their ebuilds, please just file a blocker bug against this. It's been two months, and all I asked for is a "hey, don't do it yet..."
Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution
On 12/27/17 16:47, Mike Gilbert wrote: > On Tue, Dec 26, 2017 at 7:18 PM, Robin H. Johnson wrote: >> On Tue, Dec 26, 2017 at 11:22:50PM +0100, Jason A. Donenfeld wrote: >>> You might want to mention that alternatively, uninstalling >>> openrc&sysvinit&netifrc on a systemd profile system is fine to do >>> these days, despite the warning. >> If you're using netifrc's systemd support, this would break your >> networking ;-). > I guess the winky face means you are not serious, but I'll respond anyway. :-) > > I suspect the number of people using systemd with netifrc is in the > single digits. I would rather not clutter the news item to account for > this scenario. Just for the record, I'm using it if using systemd (desktop systems), it's the only network manager that use iproute2 syntax, shortening it if context is available (no need to specify interface if it's mentioned in variable name f.ex.). Beside I don't like NetworkManager worse than that I'm actually using the same gentoo image with openrc and systemd in different scenarios. Basically my build box is using openrc inside a lxc container (no use of netifrc, since net is managed by lxc). The clients of the build box instead boot with systemd _and_ netifrc. Gentoo is used by people who like to change defaults and (ab)use the (autodocumented) flexibility offered by portage and ebuilds. Don't be light in assuming how strange people is using strange configuration, and population of strange people, that could be surprising.
Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution
On Tue, Dec 26, 2017 at 5:22 PM, Jason A. Donenfeld wrote: > You might want to mention that alternatively, uninstalling > openrc&sysvinit&netifrc on a systemd profile system is fine to do > these days, despite the warning. I have added the following text after the third paragraph. Let me know if this is insufficient. Enabling sysv-utils should cause Portage to un-merge sysvinit and OpenRC if they are currently installed. emerge may emit a warning message before doing so; if you are booting with systemd, this message is safe to ignore.
Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution
On Tue, Dec 26, 2017 at 7:18 PM, Robin H. Johnson wrote: > On Tue, Dec 26, 2017 at 11:22:50PM +0100, Jason A. Donenfeld wrote: >> You might want to mention that alternatively, uninstalling >> openrc&sysvinit&netifrc on a systemd profile system is fine to do >> these days, despite the warning. > If you're using netifrc's systemd support, this would break your > networking ;-). I guess the winky face means you are not serious, but I'll respond anyway. :-) I suspect the number of people using systemd with netifrc is in the single digits. I would rather not clutter the news item to account for this scenario.
Re: [gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...
On K, 2017-12-27 at 10:31 -0500, Brian Evans wrote: > > > > # Pacho Ramos (27 Dec 2017) > > # All Ekiga set is dead and broken for years, it relies on obsolete > > # dead/libs that are also old and broken and upstream looks to not > > release > > # newer ekiga ever. To keep this please go ahead and take care of > > it *and > > # all the dependencies it also needs*. See bugs #626176, #460458, > > #589276, > > # #638122, #641990, #633670, #624578, #600398, #627868. > > # Removal in a month. > > net-libs/ptlib > > net-libs/opal > > net-voip/openmcu > > net-voip/ekiga > > > > > > It seems you missed net-libs/h323plus which needs net-libs/ptlib. > > h323plus is needed for net-voip/openmcu (already masked above) and > net-voip/yate[h323] Note that h323plus is active with latest release from 2017-09-01. Also ptlib on h323plus website points at a version 2.12.8, while we only have 2.10.11 - possibly because ekiga doesn't work with that 2.12.x. Doesn't mean it can't be last rited due to maintainer-needed and getting in the way of something; just mentioning how the state upstream is, if someone wants to pick up h323plus or something. Perhaps radio@ as maintainers of yate? Mart
Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
On K, 2017-12-27 at 09:57 -0500, Michael Orlitzky wrote: > > 2) What you plan to do to have USE=cracklib enabled by default. Two > > people suggested you should keep this (one way or another) but > instead > > everyone is now without it enabled by default. > > I plan to do nothing, because I think it should be disabled by > default > like all other USE flags. I've CC'ed all of the maintainers who might > want to add the default to IUSE, and apparently none of them do. The > hardened project and base-system are also CCed/assigned in case one > of > them wanted to adopt the default. > > The base profile is the wrong place to enable USE=cracklib, but there > are better places. If none of the people in charge of those places > want > to enable the flag, then maybe it should remain disabled. If USE=cracklib is ever removed from base/make.defaults, then this IUSE default enabling should be done before it is removed for many of the places where it helps password safety, not afterwards when some maintainers happen to see you've done it some months later, after we have dozens of users with "12345" passwords or something. If you need more opposing, then consider this one, as long as this preparation work isn't done. Just removing it because maintainers didn't get to it in your timeline isn't something I would see OK. If you want to make such a base profile change, then I believe you should contact the maintainers and see which one wants it default disabled, and which default enabled; do the default enabled changes and only afterwards you can touch a base default USE flag, otherwise you are making a change to all these maintainers packages without their consent. It IS an effective change to their package, and you are effectively doing non-maintainer changes to them. Mart
Re: [gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...
> # Pacho Ramos (27 Dec 2017) > # All Ekiga set is dead and broken for years, it relies on obsolete > # dead/libs that are also old and broken and upstream looks to not release > # newer ekiga ever. To keep this please go ahead and take care of it *and > # all the dependencies it also needs*. See bugs #626176, #460458, #589276, > # #638122, #641990, #633670, #624578, #600398, #627868. > # Removal in a month. > net-libs/ptlib > net-libs/opal > net-voip/openmcu > net-voip/ekiga > > It seems you missed net-libs/h323plus which needs net-libs/ptlib. h323plus is needed for net-voip/openmcu (already masked above) and net-voip/yate[h323] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
On 12/27/2017 05:49 AM, Jeroen Roovers wrote: > OK, let me explain again. > > In #gentoo we give a lot of attention and support to people who want to > set up full disk encryption, tor, VPNs, and other security mechanisms, > and this tells me that they actually want security. By saying that "some > people [might] want it enabled" you ignore one of the main reasons why > people turn to Gentoo Linux in the first place. > > Having it enabled by default prompts new users and veteran users alike > to think about password safety, because this means that you get > reminded of possibly bad passwords *during* installation/while setting > up your services. Enable it if you want, but base/make.defaults is the wrong place. > People can always disable it easily when they feel they do not need it > (any longer). Not quite true due to the USE stacking order, as I mentioned on the bug. >> If you disagree, please make your voice heard on the bug. > > I already did that parallel to my response here. Note that *this* is > the proper venue for discussing sweeping changes like this, and that a > bug report that saw no input from anyone else for a couple of months > is not. That wasn't directed at you. It was directed at all of the other people on this list, to avoid exactly this discussion that we're having. If people voiced their opposition, I was happy to leave it alone. Even after two threads and a bug, yours was the only sure "no." I think I convinced floppym that base/make.defaults was the wrong place for it. And keep in mind that I only asked for responses from people who disagree. > You already went ahead and committed that change without proper > discussion and waving away the input you did get suggesting you should > drop it, so I have now reverted it. Next time, please discuss your > problems with sane defaults like these before doing anything rash. There have been two mailing list threads. The first was two months ago, https://archives.gentoo.org/gentoo-dev/message/8ddc678a05cb6d3b93adfc5a54d6312c and then there's this one, in which I tried to rally people to your cause (to no avail). Not to mention the bug itself, where I CC'ed every affected maintainer. > As quoted from the bug report, please address these: > 1) Why you think having USE=cracklib enabled by default is a *problem* > which needs to be addressed by way of its removal. My original response > questioned that, but you didn't actually answer it. I never said that having it enabled by default is a problem. I said that having it enabled in the base profile is a problem, and semantically incorrect, as evidenced by the fact that at least one profile has to unset it. Then there's the stacking issue again, which makes it awkward to disable if the base profile enables it. > 2) What you plan to do to have USE=cracklib enabled by default. Two > people suggested you should keep this (one way or another) but instead > everyone is now without it enabled by default. I plan to do nothing, because I think it should be disabled by default like all other USE flags. I've CC'ed all of the maintainers who might want to add the default to IUSE, and apparently none of them do. The hardened project and base-system are also CCed/assigned in case one of them wanted to adopt the default. The base profile is the wrong place to enable USE=cracklib, but there are better places. If none of the people in charge of those places want to enable the flag, then maybe it should remain disabled. > 3) This bug report sat there for two months without notice to > gentoo-dev@ (and largely immaterial, without even a response from the > teams you CC'd). There was no proper discussion about a change that > affects not just developers, but all users, and hardly anyone knew > about it until you posted your patch. Two separate threads and a bug CC'ed to everyone affected. What else did you want me to do?
[gentoo-dev] Lastrites: compiz and related packages
# Pacho Ramos (27 Dec 2017) # Remove all Compiz related packages: they all need major work/bumps to fix # lots of pending issues and they need a dedicated maintainer (bug #339622 # and many others). Removal in a month. x11-wm/compiz x11-apps/fusion-icon x11-libs/compizconfig-backend-gconf x11-libs/libcompizconfig dev-python/compizconfig-python x11-misc/ccsm x11-misc/simple-ccsm x11-plugins/compiz-plugins-extra x11-plugins/compiz-plugins-main x11-plugins/compiz-plugins-unsupported x11-wm/compiz-fusion x11-wm/emerald x11-themes/emerald-themes x11-libs/compiz-bcop
[gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...
# Pacho Ramos (27 Dec 2017) # Dead for ages, not needed, for java 1.5 (#638036). Removal in a month. dev-java/jikes # Pacho Ramos (27 Dec 2017) # Dead for ages, requires glibc with rpc (#371391). Removal in a month. net-misc/netkit-rusers # Pacho Ramos (27 Dec 2017) # Out ebuild is completely obsolete (#381073), download manually PPD is # preferred, current tarballs cannot be downloaded even (#635146). Removal # in a month. net-print/xerox-drivers # Pacho Ramos (27 Dec 2017) # Dead and broken for a long time (#427876), nothing requires this. Removal # in a month. dev-dotnet/gnome-sharp # Pacho Ramos (27 Dec 2017) # Dead and broken for a long time (#428354, #562772, #624956, #558120, # #585222, #585548, #605706, #612368), nothing requires this. Removal # in a month. # Mikhail Pukhlikov (20 Jul 2017) # Old mono/dotnet packages (used on GNOME2 stack) # also some deprecated forks used for monodevelop # awhile they are very unstable they will live in dotnet overlay gnome-extra/docky dev-dotnet/gnome-desktop-sharp dev-dotnet/gtksourceview-sharp dev-dotnet/rsvg-sharp dev-dotnet/vte-sharp dev-dotnet/wnck-sharp dev-dotnet/xdt-for-monodevelop dev-dotnet/nuget dev-dotnet/referenceassemblies-pcl # Pacho Ramos (27 Dec 2017) # Dead for ages, rely on deprecated/dead libs (#447466). Removal in a month. dev-vcs/bzr-gtk dev-vcs/bzr-explorer # Pacho Ramos (27 Dec 2017) # Completely broken for years (#514400, #596078, #598609, #640096, #641428). # Removal in a month. dev-cpp/pficommon # Pacho Ramos (27 Dec 2017) # Dead for a long time, failing tests (#526900), nothing requires it. # Removal in a month. net-misc/ytalk # Pacho Ramos (27 Dec 2017) # Upstream dead, SRC_URI dead, nothing requires it (#533812). Removal in a # month. media-video/replex # Pacho Ramos (27 Dec 2017) # Not compatible with mono-4 (#557588, #562546, #569252, #581920, #585860, #596652), # nothing requires them. Removal in a month. dev-dotnet/xsp dev-dotnet/nini dev-lang/mono-basic dev-util/jay # Pacho Ramos (27 Dec 2017) # python files installed in wrong path (#580328), relies on qt4 and cannot # be bumped (#585328), fails with gcc6 (#630332), fails to build (#641514). # Removal in a month. sci-visualization/qtiplot # Pacho Ramos (27 Dec 2017) # Dead upstream for a long time, relies on dead gnome-icon-theme and has # some crashes (#602144). Removal in a month. app-doc/podbrowser # Pacho Ramos (27 Dec 2017) # Dead upstream for a long time, relies on dead gnome-icon-theme and nothing # requires it (#602146). Removal in a month. games-emulation/gxmame # Pacho Ramos (27 Dec 2017) # All Ekiga set is dead and broken for years, it relies on obsolete # dead/libs that are also old and broken and upstream looks to not release # newer ekiga ever. To keep this please go ahead and take care of it *and # all the dependencies it also needs*. See bugs #626176, #460458, #589276, # #638122, #641990, #633670, #624578, #600398, #627868. # Removal in a month. net-libs/ptlib net-libs/opal net-voip/openmcu net-voip/ekiga
Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
On Fri, 22 Dec 2017 12:30:35 -0500 Michael Orlitzky wrote: > On 12/21/2017 02:27 PM, Jeroen Roovers wrote: > > On Thu, 21 Dec 2017 10:10:30 -0500 > > Michael Orlitzky wrote: > > > >> The "cracklib" USE flag ... this commit removes it from > >> base/make.defaults. > >> > >> Closes: https://bugs.gentoo.org/635698 > > > > As there: > >> ... > > > > Let me (easily) counter that by stating that having cracklib in > > place makes people pick better passwords. Especially the brand new > > Linux users we see so many of might benefit from a default > > mechanism that helps them make better security choices, but I am > > sure even advanced users and systems administrators might set a > > "temporary" POC password "quickly" and then later see their systems > > go into production without a second thought about using stronger > > passwords. > I don't think that "some people want it enabled" is enough > justification to keep this in the base profile that is the parent of > all others. OK, let me explain again. In #gentoo we give a lot of attention and support to people who want to set up full disk encryption, tor, VPNs, and other security mechanisms, and this tells me that they actually want security. By saying that "some people [might] want it enabled" you ignore one of the main reasons why people turn to Gentoo Linux in the first place. Having it enabled by default prompts new users and veteran users alike to think about password safety, because this means that you get reminded of possibly bad passwords *during* installation/while setting up your services. People can always disable it easily when they feel they do not need it (any longer). > If you disagree, please make your voice heard on the bug. I already did that parallel to my response here. Note that *this* is the proper venue for discussing sweeping changes like this, and that a bug report that saw no input from anyone else for a couple of months is not. You already went ahead and committed that change without proper discussion and waving away the input you did get suggesting you should drop it, so I have now reverted it. Next time, please discuss your problems with sane defaults like these before doing anything rash. As quoted from the bug report, please address these: 1) Why you think having USE=cracklib enabled by default is a *problem* which needs to be addressed by way of its removal. My original response questioned that, but you didn't actually answer it. 2) What you plan to do to have USE=cracklib enabled by default. Two people suggested you should keep this (one way or another) but instead everyone is now without it enabled by default. 3) This bug report sat there for two months without notice to gentoo-dev@ (and largely immaterial, without even a response from the teams you CC'd). There was no proper discussion about a change that affects not just developers, but all users, and hardly anyone knew about it until you posted your patch. Kind regards, jer