17:01:20 <notting> #startmeeting FESCO (2012-05-07)
17:01:20 <zodbot> Meeting started Mon May  7 17:01:20 2012 UTC.  The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:20 <notting> #meetingname fesco
17:01:20 <notting> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
17:01:20 <notting> #topic init process
17:01:20 <zodbot> The meeting name has been set to 'fesco'
17:01:20 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
17:01:33 <mitr> Hello
17:01:37 <sgallagh> Hello
17:01:43 <pjones> yo.
17:01:44 <notting> good morning/afternoon/evening all
17:02:02 <nirik> hello
17:02:04 <mmaslano> hi
17:02:06 <VICODAN> hello
17:02:31 <t8m> hello
17:03:14 <notting> ok. mjg59 and sgallagh both said they'd be out this week. limburgher?
17:03:24 <sgallagh> notting: I said "might" :)
17:03:27 * limburgher here
17:04:05 <notting> ok then
17:04:10 <notting> #topic #839     Proposal for revitalizing the packager sponsorship model
17:04:10 <notting> .fesco 839
17:04:13 <zodbot> notting: #839 (Proposal for revitalizing the packager sponsorship model) – FESCo - https://fedorahosted.org/fesco/ticket/839
17:04:44 <notting> this was tabled until this week pending more fesco + hopefully more discussion
17:04:52 <notting> we have the former, at least.
17:05:11 <limburgher> Not so much the latter, unless I'm missing something.  Should we use the former and have the latter now?
17:05:33 <nirik> I'm happy to try this out... at worse case there will not be enough interest from sponsors and we will need to punt back to the current model...
17:05:51 <t8m> I am fine with the proposal, so +1
17:06:02 <limburgher> I'm ok with that too.
17:06:11 <nirik> what are next steps here? approve and ask tibbs to move forward?
17:06:26 <mmaslano> probably, he came with the idea
17:06:32 <limburgher> Yup.
17:07:01 <sgallagh> I am also +1 to the proposal
17:07:09 <limburgher> +1
17:07:13 <mmaslano> +1
17:07:46 <notting> i'm +1.
17:07:55 * nirik nods. +1 here.
17:08:00 <pjones> I'm not against it, so may as well call that +1
17:08:04 <mitr> +1, I suppose
17:08:15 <notting> tibbs: from an initial reading of this, the only thing that needs done on the fesco side is redirecting sponsor requests to the new trac/mailing list/etc once that's up?
17:08:32 <tibbs> Pretty much.
17:09:23 <tibbs> Loads of wiki stuff to update but all of the changes are policy-based.
17:10:09 <notting> #agreed Proposal for revitalizing the packager sponsorship model is accepted (+:8, -:0 0:0)
17:10:27 <tibbs> Cool, unanimous.
17:10:37 <notting> now, onto feature fun
17:10:38 <tibbs> Thanks, folks; I'll get to work on that later today.
17:10:47 <nirik> tibbs: thanks for working on this!
17:10:51 <limburgher> tibbs:  Thank you!
17:11:24 <notting> #topic #841     F18 Feature: Xfce 4.10 - https://fedoraproject.org/wiki/Feature
17:11:24 <notting> .fesco 841
17:11:25 <zodbot> notting: #841 (F18 Feature: Xfce 4.10 - https://fedoraproject.org/wiki/Features/Xfce-4.10) – FESCo - https://fedorahosted.org/fesco/ticket/841
17:11:40 * nirik will refrain from voting since this is my feature.
17:11:40 <mmaslano> sounds good +1
17:11:44 <nirik> happy to answer questions
17:11:48 <notting> already done? then sign me up! +1
17:11:51 <mitr> +1
17:12:00 <sgallagh> +1
17:12:03 <notting> did this just miss the f17 feature freeze, or something?
17:12:14 <pjones> sure, +1
17:12:20 <nirik> notting: yes, it was too late for f17.
17:12:44 <nirik> upstream kicked things into high gear and released in about a month, but it was after feature freeze.
17:13:03 <nirik> I do have a side repo for f17/f16 builds.
17:13:07 <limburgher> +1
17:13:31 <t8m> +1
17:13:33 <notting> #agreed Xfce-4.10 feature accepted for Fedora 18 (+:7, -:0, 0:0)
17:13:38 <nirik> thanks!
17:13:48 <notting> #topic #842     F18 Feature: Usermode Migration - https://fedoraproject.org/wiki/Features/UsermodeMigration
17:13:48 <notting> .fesco 842
17:13:49 <zodbot> notting: #842 (F18 Feature: Usermode Migration - https://fedoraproject.org/wiki/Features/UsermodeMigration) – FESCo - https://fedorahosted.org/fesco/ticket/842
17:14:03 * mitr points at https://fedoraproject.org/wiki/Talk:Features/UsermodeMigration
17:14:46 <mitr> In particular, the idea of breaking user's workflow for unconverted packages is a total show-stopper for me, hopefully fixable easily enough
17:16:11 <t8m> I don't quite see the benefit in dropping usermode from the distribution altogether. Of course once everything is converted, why not. But making a dropping package a feature does not seem to me particularly interesting.
17:17:06 <notting> hm, in re-reading there is a disconnect between that statement and the contingency plan
17:17:15 <t8m> So I'd propose changing the scope to just convert the configuration utilities where the feature parity between the current configuration and the polkit based solution is there.
17:17:21 <sgallagh> I agree. By all means continue converting packages to PolicyKit, but I don't see value in requiring usermode/consolehelper removal.
17:17:28 <notting> mitr: t8m: would you be in favor with the feature as long as usermode itself wasn't removed?
17:17:38 <kay> the feature is not about dropping, it is about an official buy-in that we want to replace all that
17:17:40 <limburgher> sgallagh: +1
17:17:54 <notting> sgallagh: it's not "continue" as much as JFDI. this has been an option for ~4 or 5 releases, and we just haven't tried
17:18:04 <kay> "at console" is really not good enough today anymore
17:18:17 <kay> it breaks all sorts of things we rely on today
17:18:20 <mitr> notting: My blocking objection is the idea of removing the support from packages that are not converted, which is, pedantically speaking, something else
17:18:22 <kay> https://bugzilla.redhat.com/show_bug.cgi?id=804088
17:18:38 <t8m> kay, the usermode is not really connected to the "at console" concept
17:18:46 <mitr> kay: "console" should be fixable easily enough by writing one more PAM module
17:18:49 <VICODAN> how does usermode integration differ from selinux?
17:19:09 <kay> mitr: how? pam it authentication, not authorization
17:19:10 * nirik is ok with the feature, but can everything be converted in one release?
17:19:13 <mezcalero> this is really about getting the support from fesco, that polkit is the future and usermode is not, so that the people making the changes have some leverage
17:19:29 <sgallagh> kay: What exactly would you call pam_acct_mgmt(), if not authorization?
17:19:30 <kay> mezcalero: right
17:19:39 <mitr> notting: I'm also not really clear on the long-term plan; polkit is just too inflexible, liittle-featured etc.  That's something I can live with, but I would really like to see what the long-term idea is.
17:19:44 <mitr> "We like polkit" is not a vision
17:19:59 <t8m> kay, pam is both authentication and authorization
17:20:21 <mezcalero> mitr: you know, you can say the same about PAM. PAM does not include a database for allowing individual operations
17:20:22 <mitr> kay: PAM is authentication, authorization and more.  I can't see why multi-seat support shouldnt' be possible.
17:20:54 <mezcalero> mitr: you shouldn't try to turn PAM into a database for permissions, which it clearly is not
17:21:02 <kay> mitr: it's not about "possible" it about that it breaks the curent stuff by intercepting it
17:21:04 <t8m> mezcalero, ugh?
17:21:09 <mitr> mezcalero: It really does - just declare each one a different service (I know, ugly).  The real problem with PAM is that it can only be used in processes running as unconfined root.
17:21:18 <mezcalero> mitr: the same way as sudo uses PAM but includes the policy in /etc/sudoers, polkit uses PAM for authentication but has its own database
17:21:27 <mezcalero> mitr: you really are mixing apples and oranges here
17:21:28 <sgallagh> mitr: That's not really true anymore
17:21:33 <sgallagh> oddjob can work around that
17:21:38 <sgallagh> And SSSD in some instances
17:21:51 <kay> or policykit :)
17:22:05 <kay> and that's what we use everywhere
17:22:12 <mezcalero> mitr: sorry, but if you suggest we ship a gazillion service files pretending that PAM services where actually permissable actions, then you are really misusing PAM
17:22:17 <notting> i mean, usermode is a hammer for badly designed interfaces, in most cases
17:22:20 <sgallagh> kay: I'm not opposed to doing more with policykit
17:22:22 <mitr> policykit is not a good PAM client, everything has the same configuration => you have no flexibility
17:22:29 <mezcalero> mitr: PAM is for auhtenticating sessions, not for permissions management
17:22:36 <kay> mitr: nonsense
17:22:39 <sgallagh> I just haven't been convinced that we should be declaring the use of consolehelper deprecated
17:22:47 <mezcalero> mitr: and using PAM service stacks as a configuration lanaguage for policy is just completely broken
17:22:50 <kay> mitr: look at the pk files please
17:22:54 <mitr> mezcalero: I'm not at all saying that polkit should go away - but what _is_ the flexibility of polkit?
17:22:58 <pjones> sgallagh: oh, we really should.  just as soon as humanly possible.
17:23:30 <mitr> kay: OK, how do I require only a password for trivial things like picture changes, but a smartcard auth for accessing critical data?
17:23:33 <t8m> kay, well using XML as a configuration language is ugly as hell as well
17:23:41 <mezcalero> mitr: that question is not really specific, is it?
17:23:53 <sgallagh> pjones: Allow me to rephrase. I haven't heard any sufficient arguments for why polkit is sufficiently better as to make us declare it the One True Successor.
17:23:57 <mitr> mezcalero: which question?
17:24:08 <kay> sgallagh: intercepting binaries by $PATH overwrite should really not be part of future systems
17:24:24 <notting> the flexibility that using pam in usermode gives you, that i can see, is you could have one usermode-using tool only use fingerprint, one usermode-using tool only use kerberos, etc? that's *something*, but i don't know that it necessarily is a killer feature that must be preserved. what current cases use this?
17:24:33 <sgallagh> kay: That I can get behind
17:24:33 <t8m> kay, because what?
17:24:51 <mezcalero> mitr: you know, you are nmixing up the authentication technology with authorization of individual permissions
17:25:04 <t8m> kay, also usermode is not particularly attached to the binary interception by PATH
17:25:07 <mitr> kay: I'm not really arguing for keeping things on userhelper
17:25:26 <limburgher> We just have to keep usermode until conversion is complete.
17:25:39 <kay> limburgher: that we need to anyway
17:25:43 <mitr> mezcalero: No, I just expect that polkit will have to grow a real plugin interface sometime, and right now it's not at all clear what we are buying into
17:25:45 <mezcalero> usermode is just very badly designed due to the $PATH thingy, that alone should be reason enough to get rid of it
17:25:51 <sgallagh> Which, if systemd conversion is any indication, will be around F37
17:25:59 <mezcalero> also, polkit is technolgoy used by most distros, usermode is not
17:26:08 <mitr> mezcalero: That $path thing is trivial to fix if you really care that much.
17:26:11 <mmaslano> sgallagh: :)
17:26:13 <t8m> mezcalero, may I repeat that  usermode is not particularly attached to the binary interception by PATH
17:26:14 <pjones> The $PATH trick isn't all that offensive.  But at the same time, I don't see why you're choosing to focus on it here.
17:26:17 <notting> sgallagh: this is much more mechanical than systemd unit file conversion
17:26:22 <t8m> mezcalero, that can be easily changed
17:26:33 <sgallagh> notting: Sorry, can you define "mechanical" for me?
17:26:49 <pjones> sgallagh: not needing of people doing a lot of script conversions
17:26:52 <mitr> Let's please talk about polkit here, not about userhelper, OK?  I don't care if userhelper dies in 3 months, not really.
17:26:54 <sgallagh> ok
17:27:06 <VICODAN> mezcalero: when did that ever stop us? (being different)
17:27:20 <nirik> mitr: so, if userhelper dies, and you don't want polkit, what else replaces it? pam directly?
17:27:21 <notting> sgallagh: sysv scripts being essentially free-form, you need to figure out what it does, how it does it, and then do that in systemd language. userhelper -> polkit is a simple translation in 95-99% of cases
17:27:32 <pjones> VICODAN: can we stick to productive discussion, please?
17:27:54 <mezcalero> VICODAN: well, the stuff that i usually propose at least attempts to favour solutions that other distros can agree on too
17:27:58 <sgallagh> notting: Thanks, that makes sense
17:28:07 <limburgher> if the conversion process is just that list, and is that much simpler than systemd, I think f18 is attainable.
17:28:13 <mitr> nirik: "I don't know what polkit will look like when it will be feature complete".  That's not "I don't want it", but it's enough uncertainity that I don't want to commit to it.
17:28:22 <mezcalero> sgallagh: also the set of packages neediong conversion is much smaller here
17:28:35 <VICODAN> mezcalero: understood. and I think that's a good thing.
17:28:37 <pjones> mitr: I think that's just a rare case of being completely honest?
17:28:37 <notting> mitr: t8m:  trying to understand - the issue you have with polkit vs. pam is that ... all polkit authorization is run through the same pam stack?
17:28:41 <sgallagh> mezcalero: Sure, sorry if I made light of the systemd conversion.
17:28:48 <t8m> notting, yes
17:28:58 <t8m> notting, at least speaking for me
17:29:07 <mitr> notting: "polkit does too little and will have to be extended, and we don't know how ugly or not the result will be"
17:29:44 <notting> what usermode-using services are built around the idea of ... not authenticating a particular user for the action?
17:29:44 <mezcalero> mitr: have you tried asking davidz for allowing configuration of the PAM service string per action?
17:29:47 <mitr> Running a single PAM stack is one aspect of that - the promised centralized management does not exist at all
17:30:04 <mitr> mezcalero: I'm not pushing this idea, you know
17:30:16 <mezcalero> mitr: i mean, i really doubt that it was useful to allow that, since the used auth technology should be dependent on the equipment of the user, not of the action that needs permissions, but did you ask?
17:30:32 <t8m> mezcalero, note that mitr is not proposing the conversion - I'd expect that people who propose it would at least attempt the feature parity
17:30:44 <mezcalero> t8m: nah
17:30:47 <pjones> mezcalero: surely that depends on both of those things?
17:30:48 <mezcalero> t8m: they don't need to
17:30:55 <t8m> I know they don't care.
17:31:02 <mezcalero> t8m: they only need to cover the features that are deemed essential
17:31:07 <t8m> by them
17:31:14 <notting> i am fine with convert-all-the-cases-where-there-is-parity, and work to figure out the  other ones
17:31:21 <pjones> notting: yeah, likewise
17:31:28 <mitr> notting: right
17:31:28 <mezcalero> t8m: i don't think it is too useful to allow different stacks for different actions, but then again, davidz might just add that, if that's what it takes
17:31:29 <notting> but (reducto ad absurdum) hooking up a service to pam_rps is not the normal case
17:31:29 <t8m> notting, that would be fine with me
17:31:51 <mezcalero> t8m: but, i mean, i am sure davidz would be very thankful for a couple of really useful usecases for this
17:31:57 <notting> wait, we don't ship pam_rps any more?
17:32:13 <kay> polkit support specific user setting just fine
17:32:22 <mezcalero> t8m: and if you can point him to some real bug or so where this very feature was asked for or used I am sure he will listen more
17:32:27 <kay> it's easy to specify that
17:32:28 <mitr> mezcalero: Well, it took me about 10 minutes to find 3 packages that won't be possible to convert to current polkit/pkexec.  Why didn't the feature owners mention this?
17:32:33 <kay> i have no idea what should be missing
17:32:34 <notting> kay: pam supports authenticating as things that are not users
17:32:44 <notting> kay: (to speak in broad generalities)
17:33:21 <mezcalero> mitr: so, which packes require different PAM stacks for their actions in usermode?
17:33:24 <mezcalero> mitr: which 3 are those?
17:33:31 <t8m> kay, mezcalero, F. E. mock allows access to users that are part of the mock group in the PAM configuration
17:33:36 <mitr> mezcalero: mock, pure-ftpd, preupgrade
17:33:39 <t8m> is that something polkit allows?
17:33:42 <kay> easy in polkit
17:34:13 <kay> done with 'wheel' today already for mounting system disks
17:34:33 <mitr> kay: "KEEP_ENV_VARS=COLUMNS" has no equivalent in pkexec
17:34:38 <mezcalero> mitr: polkit can allow groups access, that should be enough for mock, no?
17:34:46 <mezcalero> mitr: what are you missing for pure-ftpd, preupgrade?
17:35:09 <mitr> preupgrade has KEEP_ENV_VARS as well, IIRC, and pure-ftpd uses pam_listfile
17:36:20 <mezcalero> are you sure pkexec doesn't leave COLUMNS in there anyway?
17:36:23 <mezcalero> i mean, it has a filter
17:36:43 <mitr> mezcalero: yes
17:36:54 <notting> stepping back
17:36:56 <pjones> man, we are way off in the weeds here.
17:36:58 <mitr> But really, there will be a dozen of such things as in a year or two, if polkit is the only game in town.  How will the config look?
17:37:01 <mezcalero> http://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c#n406
17:37:11 <mezcalero> would be trivial to add COLUMNS and LINES there
17:37:12 <notting> proposal: accept feature page with caveat: usermode will not be removed as long as packages depend on it
17:37:26 <kay> notting: that is surely the plan
17:37:34 <mitr> notting: "For the unconverted rest, drop the usermode part and recommend to use pkexec on the command line, similar to the usual usage of sudo." is the sentence I want dropped
17:37:39 <pjones> notting: +1
17:37:50 <notting> kay: last line of Scope: implies otherwise
17:37:56 <kay> notting: we just want the general buy-in so we can point people to it
17:38:10 <limburgher> +1 notting
17:38:23 <notting> mitr: maybe clarify that to read "as long as that works for the package's paradigm"
17:38:42 <nirik> +1
17:38:47 <mitr> notting: What does that mean?
17:38:58 <notting> mitr: the ones you mention wouldn't work with sudo either
17:39:53 <mitr> notting: There's nothing in there saying that only those will remain unconverted.
17:40:02 <mezcalero> mitr: https://bugzilla.redhat.com/show_bug.cgi?id=819609 ← i filed that one for you now
17:40:53 <mitr> Proposal: Change the last bullet of Scope to "If/after all packages are successfully converted, userhelper may be removed", and assume a corresponding update to How To Test
17:42:13 <mitr> mezcalero: that's misrepresenting me, but I'll fix that
17:43:08 * nirik is fine with that too provided feature owners are
17:43:58 <t8m> mitr, +1
17:44:04 <notting> sorry, only proposing, not voting since my name's on the feature
17:45:07 <notting> kay: mezcalero: ok with dropping or rewording the last sentence in scope?
17:45:11 <haraldh> mitr, changed scope
17:45:49 <notting> now says:
17:45:58 <notting> onvert all packages where it makes sense to use polkit to pkexec.
17:45:58 <notting> For the unconverted rest, recommend to use pkexec on the command line, similar to the usual usage of sudo.
17:45:58 <notting> If all packages are successfully converted, userhelper may be removed
17:46:05 <mitr> haraldh: Can you just drop the "recommend to use pkexec" part?  There's really zero reason to require users to change behavior AFAICT.
17:46:11 <haraldh> removed
17:46:33 <mitr> haraldh: thanks
17:46:43 * mitr still doesn't know what the deal with polkit is, but can be +1 now
17:46:57 * t8m is +1 now as well
17:47:37 <t8m> (expecting a how to test section update - at least testing whether the converted packages did not regress should be mentioned)
17:48:31 <sgallagh> I'm +1 now as well
17:48:38 <notting> that's 6 - mmaslano?
17:48:43 <mmaslano> +1
17:48:46 <notting> ok
17:48:53 <notting> #agreed F18 Feature: Usermode Migration is approved (+:7, -:0, 0:0)
17:49:01 <notting> #topic #843     F18 Feature: KRB5 Dir: Credential Caches - https://fedoraproject.org/wiki/Features/KRB5DirCache
17:49:01 <notting> .fesco 843
17:49:03 <zodbot> notting: #843 (F18 Feature: KRB5 Dir: Credential Caches - https://fedoraproject.org/wiki/Features/KRB5DirCache) – FESCo - https://fedorahosted.org/fesco/ticket/843
17:50:00 * mitr wonders at the silence...
17:50:01 <notting> sgallagh: the gnome/krb5-auth-dialog changes are stef's problem now, correct?
17:50:09 * mitr likes: +1
17:50:21 <t8m> +1
17:50:27 <sgallagh> notting: Yes and no
17:50:30 <nirik> +1 here, not sure many people will jump up for joy on this feature, but perhaps some will. ;)
17:50:35 <limburgher> +1
17:50:43 <sgallagh> It's a work in progress between Stef, Ray and myself
17:50:59 <notting> sgallagh: ok. second question - this is only tangentially related to moving the caches to /run/user, in that that's where this new directory might live?
17:51:16 <sgallagh> Yes, this feature basically depends on the other one
17:51:26 <sgallagh> In order for all components to have a well-known location for the caches to reside
17:51:52 <sgallagh> One side-effect of the DIR: style is that if an application doesn't update to handle DIR: natively, it can still treat individual caches within that dir as FILE:
17:52:02 <notting> are we going to need to munge krb5.conf on upgrade? or only have it for new installs and just tell people how to do it if they want the support on upgrade?
17:52:20 <mitr> sgallagh: How many places need to be modified to specify the location?
17:52:48 <sgallagh> mitr: In 99% of cases, it's read from the KRB5_CCNAME env var
17:53:00 <mitr> sgallagh: ... which is unset on my system
17:53:03 <sgallagh> notting: We'll try to do it only for new installs
17:53:17 <notting> sgallagh: ok
17:53:19 * notting is +1
17:53:23 <sgallagh> mitr: It would be auto-set by pam_krb5 or pam_sss if you logged in via Kerberos
17:53:42 <mitr> sgallagh: sounds good
17:53:49 <sgallagh> Otherwise it will be managed by Gnome in our vision of the future
17:53:52 <mmaslano> +1
17:54:53 <notting> #agreed F18 Feature: KRB5 Dir: Credential Caches is approved (+:6, -:0, 0:0)
17:55:08 <notting> whoops - missed 1. pjones - any objections?
17:55:15 <pjones> no
17:55:40 <pjones> definitely +1
17:55:43 <notting> #undo
17:55:43 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x18eecf50>
17:55:46 <notting> #agreed F18 Feature: KRB5 Dir: Credential Caches is approved (+:7, -:0, 0:0)
17:55:58 <notting> #topic Next week's chair
17:56:01 <notting> any volunteers?
17:56:06 <sgallagh> I haven't done it in a while
17:56:15 <sgallagh> And I'll be out the following week, so I may as well
17:56:22 <notting> #info sgallagh will chair next week's meeting
17:56:59 <notting> ok, i have a couple of items for...
17:57:01 <notting> #topic Open Floor
17:57:14 <notting> #topic Elections
17:57:50 <notting> the nomination period for FESCo elections is from: May 9-15 (closes promptly at 23:59:59 UTC on the 15th)
17:58:07 <notting> that is one week starting this Wednesday.
17:58:35 <notting> from the wiki: Open seats are currently held by: Kevin Fenzi, Bill Nottingham, Peter Jones, Stephen Gallagher, and Tomáš Mráz.
17:58:46 <notting> should probably info that
17:59:04 <notting> #info FESCo nominations open Wednesday, run until  23:59:59 UTC on the 15th. 5 seats open.
17:59:27 <notting> #topic Open Floor
17:59:40 <notting> adamw:  did you have anything that needs said re: F17 final freeze, etc?
18:00:58 <notting> guess not. (I probably should have asked before the meeting)
18:01:04 <notting> anyone have anything else for open floor?
18:01:10 <limburgher> Not currently.
18:02:10 * nirik has nothing
18:02:35 <notting> if nothing pops up , will close meeting in two minutes
18:04:37 <notting> #endmeeting