Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[William Hubbs]

On Thu, Dec 28, 2017 at 05:42:19PM -0500, Michael Orlitzky wrote:
> We now have IUSE="+cracklib" in sys-apps/shadow, sys-auth/pambase, and
> sys-libs/pam (thanks robbat2).
> 
> Does that address everyone's concerns?
> 
> Enough so that I can revert the revert without anyone reverting the
> revert revert?

I would say go ahead and revert the revert.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Michael Orlitzky]

We now have IUSE="+cracklib" in sys-apps/shadow, sys-auth/pambase, and
sys-libs/pam (thanks robbat2).

Does that address everyone's concerns?

Enough so that I can revert the revert without anyone reverting the
revert revert?

Re: OT: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[R0b0t1]

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.

[Nils Freydank]

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.

[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.

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] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[William Hubbs]

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.

[Michael Orlitzky]

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] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Mart Raudsepp]

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] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Michael Orlitzky]

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?

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Jeroen Roovers]

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

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Michael Orlitzky]

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.
> 
> Please close that bug report.

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.

If you disagree, please make your voice heard on the bug.

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Jeroen Roovers]

On Thu, 21 Dec 2017 10:10:30 -0500
Michael Orlitzky  wrote:

> The "cracklib" USE flag has long (since 2007ish) been enabled by
> default for all profiles. But, the features that it provides are not
> critical for any of the packages that use it: typically, the library
> is used to evaluate a candidate password and to prevent the user from
> choosing a weak one.
> 
> Since the flag is not critical, and because we now have per-package
> USE defaults, this commit removes it from base/make.defaults.
> 
> Closes: https://bugs.gentoo.org/635698

As there:

So as to recap that lengthy discussion of the pros and cons of having
cracklib protect people from using bad passwords by default, to you it
does "not look critical". I can't even tell what you mean by that. I
guess you were picking low hanging fruits and thought you might start
some spring cleaning? Because that's the only thing I can make of this
change: it's old so it's probably useless.

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.

Please close that bug report.



Kind regards,
 jer

[gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Michael Orlitzky]

The "cracklib" USE flag has long (since 2007ish) been enabled by
default for all profiles. But, the features that it provides are not
critical for any of the packages that use it: typically, the library
is used to evaluate a candidate password and to prevent the user from
choosing a weak one.

Since the flag is not critical, and because we now have per-package
USE defaults, this commit removes it from base/make.defaults.

Closes: https://bugs.gentoo.org/635698
---
 profiles/base/make.defaults | 10 --
 1 file changed, 10 deletions(-)

diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index db5f5389791..8139749349d 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -71,16 +71,6 @@ XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options 
ipset ipp2p iface ge
 # Some common lcd devices
 LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses 
text"
 
-# 2006/10/17 - Daniel Drake 
-# cracklib is becoming optional in shadow (and removed from system) as of
-# today. However, cracklib is very standard across the Linux world so we
-# enable it by default.
-#
-# Diego Pettenò  (14 Jul 2007)
-# Moved to base/ profile from default-linux/ so that it also applies to
-# embedded and hardened profiles.
-USE="cracklib"
-
 # Miroslav Šulc  (19 Nov 2008)
 # Netbeans modules/clusters
 NETBEANS="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb 
php profiler soa visualweb webcommon websvccommon xml"
-- 
2.13.6