17:01:20 #startmeeting FESCO (2012-05-07) 17:01:20 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:20 #meetingname fesco 17:01:20 #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher 17:01:20 #topic init process 17:01:20 The meeting name has been set to 'fesco' 17:01:20 Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 17:01:33 Hello 17:01:37 Hello 17:01:43 yo. 17:01:44 good morning/afternoon/evening all 17:02:02 hello 17:02:04 hi 17:02:06 hello 17:02:31 hello 17:03:14 ok. mjg59 and sgallagh both said they'd be out this week. limburgher? 17:03:24 notting: I said "might" :) 17:03:27 * limburgher here 17:04:05 ok then 17:04:10 #topic #839 Proposal for revitalizing the packager sponsorship model 17:04:10 .fesco 839 17:04:13 notting: #839 (Proposal for revitalizing the packager sponsorship model) – FESCo - https://fedorahosted.org/fesco/ticket/839 17:04:44 this was tabled until this week pending more fesco + hopefully more discussion 17:04:52 we have the former, at least. 17:05:11 Not so much the latter, unless I'm missing something. Should we use the former and have the latter now? 17:05:33 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 I am fine with the proposal, so +1 17:06:02 I'm ok with that too. 17:06:11 what are next steps here? approve and ask tibbs to move forward? 17:06:26 probably, he came with the idea 17:06:32 Yup. 17:07:01 I am also +1 to the proposal 17:07:09 +1 17:07:13 +1 17:07:46 i'm +1. 17:07:55 * nirik nods. +1 here. 17:08:00 I'm not against it, so may as well call that +1 17:08:04 +1, I suppose 17:08:15 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 Pretty much. 17:09:23 Loads of wiki stuff to update but all of the changes are policy-based. 17:10:09 #agreed Proposal for revitalizing the packager sponsorship model is accepted (+:8, -:0 0:0) 17:10:27 Cool, unanimous. 17:10:37 now, onto feature fun 17:10:38 Thanks, folks; I'll get to work on that later today. 17:10:47 tibbs: thanks for working on this! 17:10:51 tibbs: Thank you! 17:11:24 #topic #841 F18 Feature: Xfce 4.10 - https://fedoraproject.org/wiki/Feature 17:11:24 .fesco 841 17:11:25 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 sounds good +1 17:11:44 happy to answer questions 17:11:48 already done? then sign me up! +1 17:11:51 +1 17:12:00 +1 17:12:03 did this just miss the f17 feature freeze, or something? 17:12:14 sure, +1 17:12:20 notting: yes, it was too late for f17. 17:12:44 upstream kicked things into high gear and released in about a month, but it was after feature freeze. 17:13:03 I do have a side repo for f17/f16 builds. 17:13:07 +1 17:13:31 +1 17:13:33 #agreed Xfce-4.10 feature accepted for Fedora 18 (+:7, -:0, 0:0) 17:13:38 thanks! 17:13:48 #topic #842 F18 Feature: Usermode Migration - https://fedoraproject.org/wiki/Features/UsermodeMigration 17:13:48 .fesco 842 17:13:49 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 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 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 hm, in re-reading there is a disconnect between that statement and the contingency plan 17:17:15 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 I agree. By all means continue converting packages to PolicyKit, but I don't see value in requiring usermode/consolehelper removal. 17:17:28 mitr: t8m: would you be in favor with the feature as long as usermode itself wasn't removed? 17:17:38 the feature is not about dropping, it is about an official buy-in that we want to replace all that 17:17:40 sgallagh: +1 17:17:54 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 "at console" is really not good enough today anymore 17:18:17 it breaks all sorts of things we rely on today 17:18:20 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 https://bugzilla.redhat.com/show_bug.cgi?id=804088 17:18:38 kay, the usermode is not really connected to the "at console" concept 17:18:46 kay: "console" should be fixable easily enough by writing one more PAM module 17:18:49 how does usermode integration differ from selinux? 17:19:09 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 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 kay: What exactly would you call pam_acct_mgmt(), if not authorization? 17:19:30 mezcalero: right 17:19:39 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 "We like polkit" is not a vision 17:19:59 kay, pam is both authentication and authorization 17:20:21 mitr: you know, you can say the same about PAM. PAM does not include a database for allowing individual operations 17:20:22 kay: PAM is authentication, authorization and more. I can't see why multi-seat support shouldnt' be possible. 17:20:54 mitr: you shouldn't try to turn PAM into a database for permissions, which it clearly is not 17:21:02 mitr: it's not about "possible" it about that it breaks the curent stuff by intercepting it 17:21:04 mezcalero, ugh? 17:21:09 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 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 mitr: you really are mixing apples and oranges here 17:21:28 mitr: That's not really true anymore 17:21:33 oddjob can work around that 17:21:38 And SSSD in some instances 17:21:51 or policykit :) 17:22:05 and that's what we use everywhere 17:22:12 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 i mean, usermode is a hammer for badly designed interfaces, in most cases 17:22:20 kay: I'm not opposed to doing more with policykit 17:22:22 policykit is not a good PAM client, everything has the same configuration => you have no flexibility 17:22:29 mitr: PAM is for auhtenticating sessions, not for permissions management 17:22:36 mitr: nonsense 17:22:39 I just haven't been convinced that we should be declaring the use of consolehelper deprecated 17:22:47 mitr: and using PAM service stacks as a configuration lanaguage for policy is just completely broken 17:22:50 mitr: look at the pk files please 17:22:54 mezcalero: I'm not at all saying that polkit should go away - but what _is_ the flexibility of polkit? 17:22:58 sgallagh: oh, we really should. just as soon as humanly possible. 17:23:30 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 kay, well using XML as a configuration language is ugly as hell as well 17:23:41 mitr: that question is not really specific, is it? 17:23:53 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 mezcalero: which question? 17:24:08 sgallagh: intercepting binaries by $PATH overwrite should really not be part of future systems 17:24:24 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 kay: That I can get behind 17:24:33 kay, because what? 17:24:51 mitr: you know, you are nmixing up the authentication technology with authorization of individual permissions 17:25:04 kay, also usermode is not particularly attached to the binary interception by PATH 17:25:07 kay: I'm not really arguing for keeping things on userhelper 17:25:26 We just have to keep usermode until conversion is complete. 17:25:39 limburgher: that we need to anyway 17:25:43 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 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 Which, if systemd conversion is any indication, will be around F37 17:25:59 also, polkit is technolgoy used by most distros, usermode is not 17:26:08 mezcalero: That $path thing is trivial to fix if you really care that much. 17:26:11 sgallagh: :) 17:26:13 mezcalero, may I repeat that usermode is not particularly attached to the binary interception by PATH 17:26:14 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 sgallagh: this is much more mechanical than systemd unit file conversion 17:26:22 mezcalero, that can be easily changed 17:26:33 notting: Sorry, can you define "mechanical" for me? 17:26:49 sgallagh: not needing of people doing a lot of script conversions 17:26:52 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 ok 17:27:06 mezcalero: when did that ever stop us? (being different) 17:27:20 mitr: so, if userhelper dies, and you don't want polkit, what else replaces it? pam directly? 17:27:21 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 VICODAN: can we stick to productive discussion, please? 17:27:54 VICODAN: well, the stuff that i usually propose at least attempts to favour solutions that other distros can agree on too 17:27:58 notting: Thanks, that makes sense 17:28:07 if the conversion process is just that list, and is that much simpler than systemd, I think f18 is attainable. 17:28:13 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 sgallagh: also the set of packages neediong conversion is much smaller here 17:28:35 mezcalero: understood. and I think that's a good thing. 17:28:37 mitr: I think that's just a rare case of being completely honest? 17:28:37 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 mezcalero: Sure, sorry if I made light of the systemd conversion. 17:28:48 notting, yes 17:28:58 notting, at least speaking for me 17:29:07 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 what usermode-using services are built around the idea of ... not authenticating a particular user for the action? 17:29:44 mitr: have you tried asking davidz for allowing configuration of the PAM service string per action? 17:29:47 Running a single PAM stack is one aspect of that - the promised centralized management does not exist at all 17:30:04 mezcalero: I'm not pushing this idea, you know 17:30:16 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 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 t8m: nah 17:30:47 mezcalero: surely that depends on both of those things? 17:30:48 t8m: they don't need to 17:30:55 I know they don't care. 17:31:02 t8m: they only need to cover the features that are deemed essential 17:31:07 by them 17:31:14 i am fine with convert-all-the-cases-where-there-is-parity, and work to figure out the other ones 17:31:21 notting: yeah, likewise 17:31:28 notting: right 17:31:28 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 but (reducto ad absurdum) hooking up a service to pam_rps is not the normal case 17:31:29 notting, that would be fine with me 17:31:51 t8m: but, i mean, i am sure davidz would be very thankful for a couple of really useful usecases for this 17:31:57 wait, we don't ship pam_rps any more? 17:32:13 polkit support specific user setting just fine 17:32:22 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 it's easy to specify that 17:32:28 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 i have no idea what should be missing 17:32:34 kay: pam supports authenticating as things that are not users 17:32:44 kay: (to speak in broad generalities) 17:33:21 mitr: so, which packes require different PAM stacks for their actions in usermode? 17:33:24 mitr: which 3 are those? 17:33:31 kay, mezcalero, F. E. mock allows access to users that are part of the mock group in the PAM configuration 17:33:36 mezcalero: mock, pure-ftpd, preupgrade 17:33:39 is that something polkit allows? 17:33:42 easy in polkit 17:34:13 done with 'wheel' today already for mounting system disks 17:34:33 kay: "KEEP_ENV_VARS=COLUMNS" has no equivalent in pkexec 17:34:38 mitr: polkit can allow groups access, that should be enough for mock, no? 17:34:46 mitr: what are you missing for pure-ftpd, preupgrade? 17:35:09 preupgrade has KEEP_ENV_VARS as well, IIRC, and pure-ftpd uses pam_listfile 17:36:20 are you sure pkexec doesn't leave COLUMNS in there anyway? 17:36:23 i mean, it has a filter 17:36:43 mezcalero: yes 17:36:54 stepping back 17:36:56 man, we are way off in the weeds here. 17:36:58 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 http://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c#n406 17:37:11 would be trivial to add COLUMNS and LINES there 17:37:12 proposal: accept feature page with caveat: usermode will not be removed as long as packages depend on it 17:37:26 notting: that is surely the plan 17:37:34 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 notting: +1 17:37:50 kay: last line of Scope: implies otherwise 17:37:56 notting: we just want the general buy-in so we can point people to it 17:38:10 +1 notting 17:38:23 mitr: maybe clarify that to read "as long as that works for the package's paradigm" 17:38:42 +1 17:38:47 notting: What does that mean? 17:38:58 mitr: the ones you mention wouldn't work with sudo either 17:39:53 notting: There's nothing in there saying that only those will remain unconverted. 17:40:02 mitr: https://bugzilla.redhat.com/show_bug.cgi?id=819609 ← i filed that one for you now 17:40:53 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 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 mitr, +1 17:44:04 sorry, only proposing, not voting since my name's on the feature 17:45:07 kay: mezcalero: ok with dropping or rewording the last sentence in scope? 17:45:11 mitr, changed scope 17:45:49 now says: 17:45:58 onvert all packages where it makes sense to use polkit to pkexec. 17:45:58 For the unconverted rest, recommend to use pkexec on the command line, similar to the usual usage of sudo. 17:45:58 If all packages are successfully converted, userhelper may be removed 17:46:05 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 removed 17:46:33 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 (expecting a how to test section update - at least testing whether the converted packages did not regress should be mentioned) 17:48:31 I'm +1 now as well 17:48:38 that's 6 - mmaslano? 17:48:43 +1 17:48:46 ok 17:48:53 #agreed F18 Feature: Usermode Migration is approved (+:7, -:0, 0:0) 17:49:01 #topic #843 F18 Feature: KRB5 Dir: Credential Caches - https://fedoraproject.org/wiki/Features/KRB5DirCache 17:49:01 .fesco 843 17:49:03 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 sgallagh: the gnome/krb5-auth-dialog changes are stef's problem now, correct? 17:50:09 * mitr likes: +1 17:50:21 +1 17:50:27 notting: Yes and no 17:50:30 +1 here, not sure many people will jump up for joy on this feature, but perhaps some will. ;) 17:50:35 +1 17:50:43 It's a work in progress between Stef, Ray and myself 17:50:59 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 Yes, this feature basically depends on the other one 17:51:26 In order for all components to have a well-known location for the caches to reside 17:51:52 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 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 sgallagh: How many places need to be modified to specify the location? 17:52:48 mitr: In 99% of cases, it's read from the KRB5_CCNAME env var 17:53:00 sgallagh: ... which is unset on my system 17:53:03 notting: We'll try to do it only for new installs 17:53:17 sgallagh: ok 17:53:19 * notting is +1 17:53:23 mitr: It would be auto-set by pam_krb5 or pam_sss if you logged in via Kerberos 17:53:42 sgallagh: sounds good 17:53:49 Otherwise it will be managed by Gnome in our vision of the future 17:53:52 +1 17:54:53 #agreed F18 Feature: KRB5 Dir: Credential Caches is approved (+:6, -:0, 0:0) 17:55:08 whoops - missed 1. pjones - any objections? 17:55:15 no 17:55:40 definitely +1 17:55:43 #undo 17:55:43 Removing item from minutes: 17:55:46 #agreed F18 Feature: KRB5 Dir: Credential Caches is approved (+:7, -:0, 0:0) 17:55:58 #topic Next week's chair 17:56:01 any volunteers? 17:56:06 I haven't done it in a while 17:56:15 And I'll be out the following week, so I may as well 17:56:22 #info sgallagh will chair next week's meeting 17:56:59 ok, i have a couple of items for... 17:57:01 #topic Open Floor 17:57:14 #topic Elections 17:57:50 the nomination period for FESCo elections is from: May 9-15 (closes promptly at 23:59:59 UTC on the 15th) 17:58:07 that is one week starting this Wednesday. 17:58:35 from the wiki: Open seats are currently held by: Kevin Fenzi, Bill Nottingham, Peter Jones, Stephen Gallagher, and Tomáš Mráz. 17:58:46 should probably info that 17:59:04 #info FESCo nominations open Wednesday, run until 23:59:59 UTC on the 15th. 5 seats open. 17:59:27 #topic Open Floor 17:59:40 adamw: did you have anything that needs said re: F17 final freeze, etc? 18:00:58 guess not. (I probably should have asked before the meeting) 18:01:04 anyone have anything else for open floor? 18:01:10 Not currently. 18:02:10 * nirik has nothing 18:02:35 if nothing pops up , will close meeting in two minutes 18:04:37 #endmeeting