Summary/Minutes from today's FESCo Meeting (2015-03-25)

Parag Nemade panemade at
Wed Mar 25 19:29:28 UTC 2015

#fedora-meeting: FESCO (2015-03-25)

Meeting started by paragan at 18:00:02 UTC. The full logs are available

Meeting summary
* init process  (paragan, 18:00:02)

* #1312 F22 System Wide Change: Replace Yum With DNF -  (paragan,
  * AGREED: Replace Yum with DNF in F22+ with plan given in but complete
    it before beta freeze (+5, 0, -0)  (paragan, 18:08:23)
  * LINK:
    does include -z,now  (mitr, 18:23:50)
  * AGREED: Revisit Hardening change next week  (paragan, 18:29:46)

* #1412 anaconda password change is causing consternation among the user
  community please review this policy decision  (paragan, 18:30:02)
  * LINK:
    (mitr, 18:38:35)
  * AGREED: In f22 default back to f21 anaconda password behavior, ask
    anaconda developers, fedora-release and releng folks to make this
    change happen before Beta freeze. (+5, 0 ,-0)  (paragan, 19:13:08)
  * ACTION: nirik to work with anaconda developers for anaconda password
    policy  (paragan, 19:16:01)

* #1374 F22 Self Contained Change:  (paragan,
  * AGREED: FESCo approved the DisabledRepoSupport Change (+6, 0, -0)
    (paragan, 19:18:13)

* Next week's chair  (paragan, 19:18:42)

* Open Floor  (paragan, 19:20:56)

Meeting ended at 19:25:02 UTC.

Action Items
* nirik to work with anaconda developers for anaconda password policy

Action Items, by person
* nirik
  * nirik to work with anaconda developers for anaconda password policy
  * (none)

People Present (lines said)
* nirik (85)
* mitr (71)
* paragan (67)
* ajax (60)
* rishi (51)
* thozza (29)
* jwb (23)
* zodbot (9)
* drago01 (8)
* jreznik (5)
* Corey84 (3)
* dgilmore (2)
* sgallagh (0)
18:00:02 <paragan> #startmeeting FESCO (2015-03-25)
18:00:02 <zodbot> Meeting started Wed Mar 25 18:00:02 2015 UTC.  The
chair is paragan. Information about MeetBot at
18:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea
#link #topic.
18:00:02 <paragan> #meetingname fesco
18:00:02 <zodbot> The meeting name has been set to 'fesco'
18:00:02 <paragan> #chair ajax dgilmore jwb mitr nirik paragan rishi
thozza sgallagh
18:00:02 <paragan> #topic init process
18:00:02 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan
rishi sgallagh thozza
18:00:16 <nirik> morning.
18:00:16 <jwb> hi
18:00:20 <paragan> Hi all
18:00:22 <dgilmore> hi
18:00:26 <mitr> Hello
18:00:30 <dgilmore> I have to run in an hour
18:00:35 <thozza> hi
18:00:58 <paragan> we are missing sgallagh_afk  and rishi
18:01:26 <paragan> Okay let's start
18:01:37 <paragan> #topic #1312 F22 System Wide Change: Replace Yum
With DNF -
18:01:37 <paragan> .fesco 1312
18:01:40 <zodbot> paragan: #1312 (F22 System Wide Change: Replace Yum
With DNF - –
18:02:00 <paragan> dnf developer has given the proposal in
18:02:30 <mitr> +1
18:02:32 * ajax waves
18:02:50 <paragan> anyone have any issues with his proposal?
18:03:03 <thozza> paragan: I'm +1 on it.
18:03:11 <nirik> If the yum/dnf folks agree with that plan of action,
I don't think fesco should stop them... it's a bit worrying that it is
happening now instead of before alpha tho.
18:03:31 <ajax> looks fine to me, +1
18:03:33 <paragan> right this should have happened before alpha
18:04:06 <ajax> i've had fewer issues with dnf in f22 than i've had
with yum, tbh
18:04:42 <drago01> actually yum (as in the tool) should go away the
libary / apis should be there to give users some porting time
18:04:48 <nirik> well, dnf has it's quirks, but it's the future! and
we are just more used to yum's really...
18:04:53 <ajax> i don't think the timing should block the proposal,
given how long its taken to get even to this point.
18:05:00 <drago01> I don't see a reason for a "yum-decprecated"
command but well ...
18:05:02 <ajax> (talk talk talk)
18:05:13 <nirik> right, unless it doesn't land before beta freeze.
18:06:07 <paragan> Proposal: FESCo approves the plan given by dnf
developer for Yum With DNF Change in
18:06:13 <ajax> +1
18:06:16 <ajax> (again)
18:06:18 <nirik> sure, +1
18:06:20 <mitr> +1 again
18:06:21 <paragan> I am +1
18:06:50 <mitr> (And please make sure this is done by beta freeze)
18:07:22 <nirik> asap
18:07:29 <paragan> I see +4 votes
18:07:38 <paragan> any more votes?
18:08:03 <thozza> +1
18:08:23 <paragan> #agreed Replace Yum with DNF in F22+ with plan
given in but
complete it before beta freeze (+5, 0, -0)
18:08:44 <paragan> #topic #1384 F23 System Wide Change: Harden all
packages -
18:08:45 <paragan> .fesco 1384
18:08:46 <zodbot> paragan: #1384 (F23 System Wide Change: Harden All
Packages -
– FESCo -
18:08:56 <ajax> ah, this again
18:09:03 <nirik> fun times.
18:09:10 * nirik reads mitr's comment he just added.
18:09:16 <mitr> Sorry about being so late
18:10:11 <mitr> tl;dr is that I would prefer -z,now on by default (for
non-memory-safe languages at least), but it is not a life-or-death
issue ☺
18:10:56 <ajax> from a security perspective i'd probably agree
18:11:17 <ajax> from a performance perspective i think we really need
to measure the impact and set about mitigation
18:11:32 <ajax> because it's going to be non-zero
18:11:44 <ajax> and at least on (admittedly dumb) workloads, appreciable
18:11:58 <ajax> what i _don't_ see is the feature owners doing that measurement
18:12:29 <ajax> the 'binary compatibility' thing is maybe not the best
way i could have phrased it
18:12:43 <ajax> but basically every other elf system in the world
defaults to -z lazy semantics
18:12:51 <ajax> so... kind of a big change
18:13:13 <mitr> So do we, for anything not compiled within Fedora or
with redhat-rpm-config installed.  Sure, that is fuzzy
18:13:44 <mitr> IIRC there were measurements of PIE impact, but not relro.
18:13:55 <ajax> relro is pretty much free at runtime
18:14:10 <ajax> there's one additional mprotect() before you hit main()
18:14:12 <mitr> isn’t relro what requires -z,now
18:14:18 <ajax> nggh
18:14:19 <ajax> so
18:14:22 <ajax> imprecise terms
18:14:51 <ajax> relro on its own just says "here's a section full of
relocations that are const at runtime"
18:15:02 <ajax> in C terms, imagine taking the address of a function
in an external DSO
18:15:13 <ajax> that _could_ be const
18:15:49 <mitr> Sure, I was talking about making the GOT/PLT read only.  Sorry.
18:15:56 <mitr> (FWIW the older ticket with the measurements was )
18:16:06 <ajax> once you make an executable PIE you create a lot more
18:16:12 <ajax> and you'd like them to be read-only
18:17:06 <ajax> so that's where -z now comes in, because it moves
those relocations to be approximately as read-only as they'd be were
it not PIE
18:18:26 <paragan> ajax, what I get from the comments is following
proposal, hope that looks okay
18:18:30 <paragan> Proposal: FESCo approves update to Hardening Change
as: default to _hardened_build 0, link executables as -z now and PIE.
The _hardened_build now only affects -z for shared libraries.
18:18:59 <ajax> paragan: "default _hardened_build to undefined" actually
18:19:12 <paragan> #undo
18:19:12 <zodbot> Removing item from minutes: <MeetBot.items.Topic
object at 0x450b8d0>
18:19:16 <nirik> will that require updating all those specs?
18:19:34 <paragan> Proposal: FESCo approves update to Hardening Change
as: default to _hardened_build undefined, link executables as -z now
and PIE. The _hardened_build now only affects -z for shared libraries.
18:20:01 <ajax> nirik: enh, "require" is a funny word there
18:20:15 <ajax> presumably everything that's been "fixed" so far for
this is already doing %undefined _hardened_build
18:20:24 <ajax> so... they'd still be doing that?
18:20:38 <ajax> we can make that mean whatever we want
18:20:43 <mitr> As a packaging matter, I would prefer that if we have
a _hardened_build toggle at all (as opposed to manual overrides), it
should control most or all of the functionality; having a
_hardend_build toggle that controls the comparatively minor relro
aspect but not the major ASLR one would be confusing.
18:20:52 <ajax> the patch i posted makes it mean what paragan proposed there
18:21:02 <mitr> OTOH with the -specs usage we probably do need a toggle
18:21:12 <ajax> the relro thing is effectively already the default anyway
18:21:23 <ajax> like, binutils defaults to it for us, before specs are involved
18:21:26 * nirik was thinking the case where someone did a %if
_hardened_build or whatever, but not sure anyone does that
18:22:29 <jwb> i'm distracted and the proposal reads to me like FESCo
is saying we aren't defaulting to hardened builds, which is what the
feature was requesting.  i'll just defer to people paying more
attention than me
18:22:42 * rishi is here
18:22:53 <ajax> jwb: it's hair-splitting
18:22:58 <nirik> the problem is that "hardened_build" is covering
several different things affecting differnt types of builds. ;)
18:23:14 <ajax> the feature was "harden all builds with
position-independent code"
18:23:21 <jwb> originally i thought we approved PIE and PIE only.
nothing to do with -znow
18:23:24 <ajax> is that what they actually meant or not?  well, who knows.
18:23:46 <ajax> -znow is orthogonal to pic, so.
18:23:50 <mitr>
does include -z,now
18:24:15 <ajax> mitr: it says that now, yes.  was that because they
intended it to say that, or because they copied in what the macros
_would_ do.
18:24:33 <ajax> (the latter i'm pretty sure)
18:25:09 <ajax> huh, i should give jakub's testcase there a try
18:25:30 <mitr> ajax: You’re right, that table was added later.
18:26:14 <ajax> anyway
18:26:20 <paragan> we are discussing this since last 15 minutes now
18:26:21 <nirik> I'm ok waiting for more test data or just +1ing ajaxs
proposal .
18:26:22 <mitr> ajax: That test case is IIRC a completely artifical
stress test.  It doesn’t hurt to know but I wouldn’t consider this a
decisive data point.
18:26:34 <ajax> i've not really had as much time to devote to this as
i'd like due to rhel
18:26:40 <nirik> we just need to make sure we do our changes before
any gcc mass rebuild.
18:26:57 <jwb> are we even going to have time for a mass rebuild before beta?
18:27:04 <nirik> jwb: no no, rawhide.
18:27:06 <mitr> I guess I’ll sum this up and be -1 at this point; the
components that can’t live with -z,now have a workaround, and
optimizing the system for running configure scripts seems dubious.
18:27:06 <ajax> jwb: f23
18:27:09 <jwb> oh, right
18:27:14 <jwb> sorry, as i said, distracted
18:27:43 <ajax> but yeah i'd like to come back to this over the next
week, and i don't think there's any urgency in the f23 schedule yet
18:27:47 <mitr> But I haven’t had any time to actually help with the
workarounds or anything else either
18:28:14 * nirik hasn't noticed any slowness on his rawhide system,
but thats a poor measure. :)
18:28:27 <ajax> there's at least the other buglet mentioned there regarding gnat
18:28:27 <nirik> so, yeah, lets let it cook another week?
18:28:39 <ajax> nirik: +1 defer
18:29:21 <mitr> OK, defer
18:29:26 <ajax> i'm happy to get some more representative data once
i'm out of rhel rebase stress
18:29:28 <paragan> okay let check this next week
18:29:46 <paragan> #agreed Revisit Hardening change next week
18:30:02 <paragan> #topic #1412 anaconda password change is causing
consternation among the user community please review this policy
18:30:02 <paragan> .fesco 1412
18:30:04 <zodbot> paragan: #1412 (anaconda password change is causing
consternation among the user community please review this policy
decision) – FESCo -
18:30:28 <drago01> mitr: "configure scripts" ? wouldn't this affect
anything that execs multiple binaries in a short time like "make" ?
18:30:29 <nirik> so, anaconda can now adjust it's policy...
18:30:34 <paragan> Anaconda developers have added default password
policy in anaconda ->
18:30:46 <paragan> Products can implement their own policy by
including a modified copy of
in their product.img -- drop it into /usr/share/anaconda/ and it will
overwrite the default.
18:30:48 <mitr> drago01: configure scripts have a much larger
overhead-to-useful-code ratio than compiling
18:31:18 <rishi> mitr: Don't configure scripts also compile random
code to test the compiler?
18:31:18 <mitr> Looking at that interactive-defaults.ks, with the
--strict, it _doesn’t_ actually implement what FESCo has asked for, or
am I mistaken?
18:31:29 <nirik> so, on this one I'd say we should also defer and see
if we can get all the products to agree to as few different policies
as possible?
18:31:29 <drago01> mitr: I can't parse that
18:32:03 <ajax> i kinda don't care what the defaults do if the product
kickstart can override it
18:32:03 <nirik> mitr: we can set whatever policy we want and/or let
products set their own
18:32:11 <drago01> mitr: its not about "configure scripts are
important" but "configure scripts are slow because $foo" ... "other
uses cases do $foo and will be affected to"
18:32:12 <paragan> I am not sure if all product groups should be
following the same password policy.
18:32:12 <drago01> o
18:32:13 <mitr> drago01: Things like (sed 's/^ //') are essentially
millions of instructions to edit a few bytes of memory
18:32:16 <ajax> and there's --nostrict so
18:32:33 <rishi> We are having overlapping discussions. :/
18:32:53 <drago01> rishi: oh sorry didn't notice that the topic changed
18:32:57 <nirik> on configure: benchmarking welcome, we don't need to
discuss that here.
18:32:58 <mitr> nirik: Well, except for non-product?
18:33:29 <drago01> nirik: (you missed the point as well)
18:33:34 <mitr> And fundamentally I very much agree with some people
in that thread, that there should be only one policy.  If pwpolicy is
a thing,  it should affect the installed system.
18:33:43 <paragan> I see adamw have emailed to all product groups
about this password policy rules.
18:33:59 <rishi> nirik: I spoke with Kalev about the Anaconda change.
It appears that we (as in Workstation) have what we need to relax the
password policy.
18:34:04 <nirik> drago01: sorry...
18:34:05 <rishi> So in that sense the change is OK.
18:34:11 <thozza> I think that what FESCo asked can be implemented in
the products using the change made in anaconda
18:34:16 <mitr> I would say Defer, but the beta freeze is next Tuesday.
18:34:21 <nirik> rishi: sure, but if we can get everyone to agree to
ONE POLICY thats better. ;)
18:35:04 <jwb> i don't think that's realistic
18:35:09 <rishi> nirik: Agreed. But strictly speaking that is outside
the scope of what we asked from Anaconda.
18:35:15 <jwb> cloud wants to use ssh keys and not passwords at all
18:35:15 <nirik> sure.
18:35:35 <nirik> cloud doesn't run the installer...
18:35:47 <thozza> can we use the same policy as for F21 for all products in F22?
18:36:03 <jwb> by default?
18:36:07 <jwb> maybe
18:36:10 <nirik> if we can get them all to agree.
18:36:16 <rishi> Now the ball is in the WGs' court, not Anaconda's.
18:36:33 <jwb> but getting it coordinated and approved by Server and
Workstation before then seems a stretch
18:36:35 <thozza> I thought we want to fall back to the F21 state for F22
18:36:43 <thozza> until some policy is prepared
18:36:49 <nirik> jwb: adamw has sent out an email to try and do
this... it might well be possible
18:37:00 <jwb> what was asked them to do was allow the 'double done
click' functionality
18:37:00 <nirik> thozza: all we agreed to was to readd the 'double done'
18:37:06 <mitr> Proposal: go back to anaconda and ask them to
implement exactly what has asked for;
AFAICS that hasn’t happened and _we don’t have time_.
18:37:07 <jwb> afaik, they didn't do that and did this instead?
18:37:13 <thozza> nirik: sure
18:37:42 <paragan> afaik they don't want to change upstream code
18:37:44 <mitr> We can continue to have the pwpolicy discussion for
F23 of course.
18:37:53 <nirik> mitr: ?
18:37:54 <thozza> mitr: I think it is possible also with the change they made
18:38:04 <mitr> paragan: so IIRC the plan was to patch it in f22,
which, looing at git log, didn't happen.
18:38:22 <nirik> They said that they would re-add it, but in a local
to fedora way.
18:38:30 <nirik> that upstream defaults would not change
18:38:35 <jwb> perhaps there's a subtle language issue here
18:38:35 <mitr>
18:38:35 <nirik> thats what this is?
18:38:36 <paragan> right instead they given choices to implement
password policies
18:38:58 <jwb> they said it would have to be carried as a patch.
nobody ever said who was creating said patch
18:39:14 <ajax> childish.
18:39:25 <ajax> like the world's stupidest game of "i'm not touching you!"
18:40:05 <jwb> could be they just forgot too
18:40:13 <thozza> can we just use what anaconda is using except
--strict (use --nostrict) instead which would bring back the double
18:40:16 <thozza> ?
18:40:18 <nirik> anyhow...
18:40:49 <mitr> Sorry, the git log above is not really representative
because anaconda is just rebasing tarballs
18:40:50 <paragan> so what we want to propose here, fallback to old
double click password acceptance or implement password policies
18:41:19 <thozza> paragan: the double click can be implemented using --nostrict
18:41:24 <nirik> I'm not sure of the details (we need sgallagh_afk who
has actually tested stuff for server), but I would say:
18:41:50 <nirik> set a default policy back to the f21 one, working
groups can override
18:42:14 <thozza> nirik: that's what I said basically... so I agree
18:42:28 <nirik> but the ramp is short.
18:42:31 <rishi> Ok, so pwpolicy has --nostrict flag.
18:42:34 <mitr> Proposal: anaconda to switch the default as requested
previously for F22, for all products and non-products, using whatever
mechanism they find appropriate, in whatever package they find
appropriate, by F22 beta freeze.
18:42:46 <paragan> I am not sure if the rules they have given in that
commit, can be used to created f21 policy by product groups
18:42:46 <nirik> mitr: -1
18:43:05 <mitr> I'm not excited to go looking for new ways to package
that kickstart in $something now, and someone to do it.
18:43:25 <nirik> mitr: that ordering people to do work for us where we
know they will not be thrilled to do so. Setting up for failure.
18:43:37 <nirik> sgallagh was testing this yesterday for server.
18:43:51 <rishi> nirik: Agreed.
18:44:04 <nirik> but the f22 build doesn't have this yet.
18:44:08 <mitr> nirik: We have already done that three weeks ago; if
we do it at all, then we need to follow up or enforce.  Or we can just
plain stop doing that and make these meetings shorter :)
18:44:10 <rishi> mitr: I am reading
18:44:10 <nirik> and rawhide was crashing on him
18:44:27 <rishi> mitr: It seems we have the necessary framework to
restore the F21 behaviour.
18:44:35 <nirik> right.
18:44:47 <mitr> rishi: Framework, perhaps.  Actual packaging desiign,
people to impelment such design, and _time_, not.  The freeze is on
18:44:48 <jreznik> yep
18:45:11 <jreznik> but still doable
18:45:29 <jreznik> and everything is better than double click from UX
18:45:39 <nirik> we are not getting rid of double done.
18:46:17 <rishi> mitr: We can just ask the WGs to use a policy that is
exactly the same as the F21 behaviour.
18:46:22 <paragan> hm so defer this ticket again?
18:46:31 <mitr> paragan: No time
18:46:32 <jwb> nirik, uh...
18:46:37 <jwb> it's already gone
18:46:48 <jreznik> it's gone for good
18:46:51 <paragan> right beta freeze is coming
18:46:53 <jwb> we asked for it to be added back.  it isn't added back
18:46:56 <jwb> so?
18:46:57 <rishi> jwb: Gone? Double done is gone?
18:46:58 * nirik sighs.
18:47:00 <nirik> no.
18:47:12 <rishi> So what is this --nostrict thing then?
18:47:14 <nirik> It is not added back currently.
18:47:18 <mitr> rishi: Yes it is gone in the configuration that is
being used at this very moment.
18:47:22 <nirik> however, they have given us a way to do so
18:47:35 <rishi> mitr: nirik: Right.
18:47:36 <nirik> it's up to us to do so by adding a small %anaconda
section to the kickstarts we use
18:47:52 <nirik> or I suppose yell at them and ask them to scrap all
this and just re-add double done
18:47:55 <rishi> So we can just use a config that mimics F21.
18:48:18 <nirik> rishi: yes...
18:48:51 <rishi> Basically, I don't want to antagonize the Anaconda
folks too much.
18:48:51 <nirik> --nostrict --minlen=6 --minquality=1 --nochanges --emptyok
18:49:40 <paragan> I still not sure what are we concluding here
18:49:51 <rishi> As long as we can reasonably do whatever we want,
which at this point is getting the F21  behaviour back.
18:49:58 <rishi> nirik: Right.
18:50:33 <thozza> can we ask them to carry the patch for the default
configuration of options they introduced for F22?
18:50:42 <thozza> to mimic the F21 behavior...
18:50:46 <thozza> I mean anaconda
18:51:17 <thozza> why should we ship it in a separate package?
18:51:19 <rishi> And on top of that, ask the WGs to not change the
behaviour because now they can do that in their kickstart.
18:51:25 <thozza> sure
18:51:31 <nirik> rishi: why?
18:51:52 <nirik> thozza: we could ask, but they didn't want to change
the defaults... so not sure they would be receptive.
18:51:57 <mitr> rishi: That seems unnecessary.
18:52:02 <rishi> Umm... don't we want F22 to retain the F21 behaviour?
18:52:33 <rishi> Atleast that is what says.
18:52:38 <jwb> nirik, i see.  i was confused because the UI work was
done in a commit before the one bcl linked to
18:52:40 <nirik> all we wanted was the double done back. ;)
18:52:51 <mitr> nirik: Well #1191842 is a beta blocker
18:52:57 <thozza> nirik: they can keep the defaults in rawhide and upstream
18:53:05 <nirik> mitr: good point.
18:53:45 <mitr> nirik: As a matter of principle, “upstream disagrees”
is no way to make a consistent distribution.  I just don’t buy that at
18:53:46 <nirik> thozza: well, we could ask.
18:53:49 <rishi> nirik: Yeah, but now we have the possibility that a
product change the policy to something else.
18:54:05 <rishi> At the end of the day, the question is: "what does
the user see".
18:54:31 <mitr> rishi: If a product thinks they have a good basis for
a different policy, and enough time and interest to implement this, I
don’t currently see a good reason to stop them.
18:54:52 <nirik> mitr: well, this is a bigger conversation really... I
mean when we have a upstream that doesn't do what we want, normally we
have a set of maintainers that adjusts upstream for us, but we really
don't have that in some cases.
18:54:55 <rishi> mitr: Ok., so in that case, everything is perfect now. No?
18:55:21 <mitr> rishi: No becaususe if a product doesn't think so or
doesn’t have time and interest we are in a broken situation.
18:56:00 <rishi> mitr: Can't the product just use:
18:56:01 <rishi> --nostrict --minlen=6 --minquality=1 --nochanges --emptyok
18:56:06 <rishi> as nirik said ?
18:56:20 <nirik> sure, but then all the nonproduct things will still
have the anaconda defaults.
18:56:22 <mitr> So…?  Do we have a volunteer to figure out what
kickstarts, where and how need adjusting, and do so, so that I can +1
them and we can move on?  If not, please let
18:56:28 <mitr> ’s kick this back to anaconda.
18:56:35 <mitr> Or are there any other options we could be pursuing?
18:56:37 <rishi> nirik: You mean the spins?
18:57:00 <nirik> spins, atomic images, arm appliances, the other
billion things we are making now.
18:57:05 <nirik> netinstall isos
18:57:22 <rishi> nirik: Ok. I see the point now.
18:57:30 <thozza> is there any common package/place to include the
defaults? I mean common for all spins, etc...
18:57:37 <nirik> mitr: what exactly do you want to ask anaconda folks?
can you form a proposal?
18:57:38 <rishi> In that case, I think it is reasonable to ask
Anaconda to change the default to mimic F21.
18:57:42 <ajax> spin-kickstarts.git, yes
18:57:59 <nirik> many of the items in the spin-kickstarts use common
stuff and include...
18:58:01 <mitr> nirik: I have formed two above; I suppose the second
one, perhaps toned down by someone who is not as annoyed as I am.
18:58:20 <rishi> Unless we can osomehow verride it for the spins,
atomic images, etc..
18:58:34 <nirik> I don't know enough about the setup to say.
18:58:44 <nirik> as I noted sgallagh was looking into it.
18:58:45 <mitr> thozza: IMHO libpwquality would be appropriate but
that is again getting into design discussions we don’t have time for.
18:59:00 <paragan> Should we wait to see what product WG's are
concluding on how to use this new password policy or we want to decide
on this today?
18:59:18 <mitr> paragan: Wait till when?
18:59:30 <nirik> I am ok waiting a week to see if we can come up with
something based on this anaconda framework.
18:59:34 <paragan> not sure say next week
18:59:34 <mitr> nirik: for the record:
18:59:36 <mitr> Proposal: anaconda to switch the default as requested
previously for F22, for all products and non-products, using whatever
mechanism they find appropriate, in whatever package they find
appropriate, by F22 beta freeze.
18:59:44 <mitr> paragan: The freeze is Tuesday next week, again.
18:59:54 <nirik> yes, but as you noted this is a blocker bug.
18:59:54 <ajax> mitr: +1
19:00:00 <thozza> mitr: +1
19:00:09 <mitr> +1 for the record
19:00:10 <rishi> paragan: As far as I can see this isn't about the WGs.
19:00:17 <thozza> they now have the mechanism they implemented, so
they can use it :)
19:00:29 <rishi> It seems to be about what the non-product things that
we have are going to use.
19:00:46 <rishi> mitr: +1
19:00:53 <paragan> rishi, I just thought we are not finding common
proposal so hear what WG will say
19:01:40 <paragan> mitr, defaults to f21 password policy in your proposal?
19:02:16 <mitr> paragan: To be more precise, s/as requested previously
for F22/& in
19:02:22 <rishi> paragan: Well, right now, all the WGs can either
decide to use the F21 policy, or use their own (mitr and nirik sounded
happy about that). The problem seems to be that the non-products don't
have a way to override the Anaconda default, which is not what the F21
policy was.
19:02:45 * nirik is again hobbled by not having played with this stuff.
19:02:54 <nirik> it could well be that they can override too in their
kickstarts, etc.
19:02:57 <mitr> rishi: For the record I am _not_ happy about what the
pwpolicy thing does, but that can be easily enough adjusted for F23
19:04:06 <mitr> (to be specific, the kickstart directives should IMHO
affect the installed system)
19:04:07 <rishi> mitr: Out of curiosity, what part of the pwpolicy
thing do you not like?
19:04:12 <mitr> ^^
19:04:18 <nirik> so, that means we want --nostrict to be default in
f22 anaconda... right?
19:04:45 <paragan> I am not sure if anaconda developers will be agree
to provide double done as they have given way to implement own
19:04:45 <thozza> nirik: right
19:04:49 <jreznik> and it does not have to be implemented by anaconda
but other teams
19:04:52 <mitr> nirik: As far as my proposal above, I wanted to leave
the implementation details up to implementers.
19:04:59 <mitr> nirik: But yes, it seems so.
19:05:02 <jwb> paragan, they provided double done via --nostrict
19:05:34 <mitr> (We are going in this circle for the 3rd or 4th time,
aren’t we?)
19:05:35 <rishi> mitr: The kickstart directives don't affect the
installed system? Are you talking about things like
gnome-initial-setup or gnome-control-center which have their own
password UI?
19:05:36 * nirik also notes it could be implemented by
fedora-release-nonproduct for nonproducts perhaps. But again, I have
not had time to look at implementation details
19:05:52 <thozza> mitr: it seems so :-(
19:06:12 <ajax> i'm trying very hard not to.
19:06:15 <mitr> rishi: AFAICS they affect _nothing_; and they should
affect _everything_ the same way the auth directive does.
19:06:19 <rishi> I guess we should first figure out if the
non-products can override the default.
19:06:24 <nirik> +0 on the proposal from me, as I don't know that
anaconda would be the best place to make this change.
19:06:26 <rishi> That should break the circle. :)
19:06:40 <thozza> we have +4 on mitr's proposal
19:06:53 * rishi re-reads the proposal
19:07:02 <mitr> nirik: The proposal is not claiming that anaconda is
the best _place_, only the best _people_ to make it.
19:07:06 * Corey84 joins rishi
19:07:08 <thozza> nirik: it does not say it has to be anaconda
19:07:09 <thozza> ;)
19:07:20 <nirik> mitr: well, I am not sure thats even the case.
19:07:31 <mitr> nirik: That’s fair.
19:07:34 <nirik> if we can make this in fedora-release* the
maintainers there would be
19:07:37 <rishi> "whatever package" and "whatever mechanism" seems
like the operative words. :)
19:07:53 <Corey84> given the issues anaconda has been facing as of
late   I say its not but willing to help change that
19:08:28 <nirik> mitr: ok, so 'anaconda' in your proposal was the
software, not the anaconda developers specifically?
19:08:53 <mitr> nirik: Sorry, it should have been the developers.
19:08:57 <paragan> Proposal: Ask anaconda developers to provide patch
that will give F21 password double done policy in F22 for all products
19:09:05 <Corey84> i'd go +1 if that interpration is correct
19:09:07 <paragan> does above looks similar to mitr proposal
19:09:14 <rishi> nirik: We can add a "whoever" in there for all I care.
19:09:16 <mitr> paragan: s/provide and apply/
19:09:24 <jwb> Corey84, please don't vote if you are not a FESCo member
19:09:40 <rishi> paragan: Your proposal doesn't cover the non-products.
19:10:26 <mitr> Rewording for clarity:
19:10:28 <mitr> Proposal: Ask anaconda developers to switch the
default as requested previously for F22 in , for all
products and non-products, using whatever mechanism they find
appropriate, in whatever package they find appropriate, by F22 beta
19:10:29 <nirik> proposal: In f22 default back to f21 anaconda
password behavior, ask anaconda developers, fedora-release and releng
folks to make this change happen before Beta freeze.
19:10:34 <paragan> Okay +1 to mitr proposal then
19:11:03 <rishi> I like nirik 's more.
19:11:07 <paragan> actually I was looking for simple text
19:11:17 <mitr> nirik: +1 I guess, it’s a collective body/collective
responsibility either way.
19:11:20 <paragan> I like nirik's proposal
19:11:25 <rishi> Because it includes more people than just "anaconda
19:11:31 <ajax> +1 to whatever makes this a thing we're not talking
about anymore tbh
19:11:38 <rishi> ajax: Yeah.
19:11:38 <nirik> ajax: :)
19:11:54 * rishi hands out a few +1s to both nirik and mitr
19:12:02 <paragan> I see we are about to get nirik proposal approved
but who is going to work on this?
19:12:09 <thozza> mitr: +1
19:12:21 <nirik> I can try and shepard it...
19:12:36 <nirik> hopefully sgallagh has already done the heavy lifting.
19:12:42 <nirik> do we want to allow products to override tho?
19:13:08 <paragan> #agreed  In f22 default back to f21 anaconda
password behavior, ask anaconda developers, fedora-release and releng
folks to make this change happen before Beta freeze. (+5, 0 ,-0)
19:13:34 <mitr> nirik: In principle, I think so; at this moment, I’d
say preferably only if it is done by Beta freeze.
19:13:35 <nirik> proposal: products may override password policies
from the default.
19:13:48 <nirik> mitr: good point...
19:14:21 <rishi> nirik: I am leaning towards "no" to that since it is
quite late, but if some WG really wants something else, then it should
be b y Beta freeze.
19:14:31 <mitr> nirik: +1 if that needs to be voted on; IIRC
configuration divergences have always been fair game, though I am not
sure whether we have an explicit decision to that effect
19:14:42 <nirik> ok, like I said sgallagh was working on it, so he may
have something for server by tuesday
19:14:59 <nirik> mitr: also good point. so, lets just say they can and move on.
19:16:01 <paragan> #action nirik to work with anaconda developers for
anaconda password policy
19:16:09 <rishi> nirik: mitr: FWIW when I tried to relax the policy in
gnome-control-center, I was hampered by pam. So not sure how easily a
product can use its own policy in practice.
19:16:18 <paragan> #topic #1374 F22 Self Contained Change:
19:16:19 <paragan> .fesco 1374
19:16:20 <zodbot> paragan: #1374 (F22 Self Contained Changes) – FESCo
19:16:25 <mitr> rishi: g-c-c should not have its own policy at all, it
should be in pwquality.
19:16:27 <nirik> rishi: well, for install... but yes, there's still
nothing unified. ;(
19:16:46 <nirik> +1 this self contained change.
19:16:55 <paragan> +1
19:16:56 <mitr> +1 to the disabled-repo support (and annoyed about the
packaging tools split)
19:17:24 <thozza> +1
19:17:24 <ajax> +1 to this change
19:17:54 <paragan> cool
19:17:58 <rishi> +1
19:18:13 <paragan> #agreed FESCo approved the DisabledRepoSupport
Change (+6, 0, -0)
19:18:39 <paragan> I think we are done with tickets :)
19:18:42 <paragan> #topic Next week's chair
19:18:42 <paragan> any volunteer? :)
19:18:55 <ajax> have we rotated everyone through yet?
19:20:17 <mitr> I can do it next week.
19:20:38 <paragan> mitr, thanks
19:20:45 <paragan> #note mitr to chair next week
19:20:56 <paragan> #topic Open Floor
19:20:56 <paragan> anything for open floor?
19:21:20 <ajax> nothing from me.
19:21:26 * nirik has nothing
19:23:18 <paragan> If there is nothing to discuss then I'll end the
meeting in a minute
19:25:02 <paragan> thanks everyone for having this meeting.
19:25:02 <paragan> #endmeeting

More information about the devel mailing list