Gentoo Archives: gentoo-dev

From: William Hubbs <williamh@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.
Date: Wed, 27 Dec 2017 16:32:18
Message-Id: 20171227163202.GA14165@linux1.home
In Reply to: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults. by Mart Raudsepp
1 On Wed, Dec 27, 2017 at 05:42:04PM +0200, Mart Raudsepp wrote:
2 > On K, 2017-12-27 at 09:57 -0500, Michael Orlitzky wrote:
3 > > > 2) What you plan to do to have USE=cracklib enabled by default. Two
4 > > > people suggested you should keep this (one way or another) but
5 > > instead
6 > > > everyone is now without it enabled by default.
7 > >
8 > > I plan to do nothing, because I think it should be disabled by
9 > > default
10 > > like all other USE flags. I've CC'ed all of the maintainers who might
11 > > want to add the default to IUSE, and apparently none of them do. The
12 > > hardened project and base-system are also CCed/assigned in case one
13 > > of
14 > > them wanted to adopt the default.
15 > >
16 > > The base profile is the wrong place to enable USE=cracklib, but there
17 > > are better places. If none of the people in charge of those places
18 > > want
19 > > to enable the flag, then maybe it should remain disabled.
20 >
21 > If USE=cracklib is ever removed from base/make.defaults, then this IUSE
22 > default enabling should be done before it is removed for many of the
23 > places where it helps password safety, not afterwards when some
24 > maintainers happen to see you've done it some months later, after we
25
26 I would say that it is up to you to show where it was approved for
27 adding to base/make.defaults by showing where it was discussed on this
28 list, or showing where it was added in the profile revision history.
29
30 A bug and that has been open as long as he said it was earlier in this
31 thread, as well as notification here with a 72 hour delay as well as
32 contacting the maintainers directly as far in advance as he did seems
33 reasonable to me.
34
35 I will look at this more when I get back to my home system, but on the
36 face of it, I would support his change.
37
38 >
39 > If you need more opposing, then consider this one, as long as this
40 > preparation work isn't done. Just removing it because maintainers
41 > didn't get to it in your timeline isn't something I would see OK. If
42 > you want to make such a base profile change, then I believe you should
43 > contact the maintainers and see which one wants it default disabled,
44 > and which default enabled; do the default enabled changes and only
45 > afterwards you can touch a base default USE flag, otherwise you are
46 > making a change to all these maintainers packages without their
47 > consent. It IS an effective change to their package, and you are
48 > effectively doing non-maintainer changes to them.
49
50 As he said, he contactedd the maintainers in ample time, so I would say
51 that since they didn't respond he went ahead in good faith. I'll get the
52 link later, but as I recall, the dev manual recommends a 2-4 week wait
53 for maintainers not responding then we can assume that what we are doing
54 is ok.
55
56 I will look into this more when I get back to my home system, but as a
57 member of base-system, tentavely count me as supporting his change.
58
59 To respond to the comment about preparation work:
60 Again, I haven't checked the bug, but if it has been there a while and
61 received no input from base-system etc, there may not be any, so
62 removing it from base/make.defaults would be the way to go.
63
64 William

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies