17:59:59 <nirik> #startmeeting FESCO (2013-05-22)
17:59:59 <zodbot> Meeting started Wed May 22 17:59:59 2013 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:59:59 <nirik> #meetingname fesco
17:59:59 <nirik> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh
17:59:59 <nirik> #topic init process
17:59:59 <zodbot> The meeting name has been set to 'fesco'
17:59:59 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m
18:00:02 <t8m> hello
18:00:09 <abadger1999> greetings
18:00:14 * notting is here
18:00:15 <mmaslano> hi
18:00:28 <sgallagh> Hello
18:00:30 <mitr> Hello
18:01:52 <nirik> ok, lets go ahead and dive in then...
18:02:00 <nirik> #topic #1098 F19 Features - Progress on Features 100% Complete
18:02:00 <nirik> .fesco 1098
18:02:00 <nirik> https://fedorahosted.org/fesco/ticket/1098
18:02:01 <zodbot> nirik: #1098 (F19 Features - Progress on Features 100% Complete) – FESCo - https://fedorahosted.org/fesco/ticket/1098
18:02:35 <nirik> so, the only one thats not is anaconda, and it sounds like thats really 100% anyhow...
18:03:45 <nirik> so, close and move on? or some other action?
18:03:54 <jreznik> for what we care about from anaconda - I'd say we can deal with it as done
18:04:00 <t8m> nirik, +1
18:04:05 <abadger1999> +1
18:04:06 <t8m> to close and move on
18:04:19 <mitr> +1
18:04:34 <mmaslano> +1
18:05:24 <nirik> #agreed This is done, close now.
18:05:33 <nirik> #topic #1114 Would like to become a provenpackager
18:05:33 <sgallagh> +1
18:05:34 <nirik> .fesco 1114
18:05:34 <nirik> https://fedorahosted.org/fesco/ticket/1114
18:05:34 <notting> that works. +1
18:05:34 <zodbot> nirik: #1114 (Would like to become a provenpackager) – FESCo - https://fedorahosted.org/fesco/ticket/1114
18:06:08 <notting> this didn't get any +1 or -1 specifically, so moved to the meeting.
18:06:31 <nirik> yeah.
18:06:31 <sgallagh> I have no problems granting provenpackager in order to facilitate dealing with large numbers of packages
18:06:42 <abadger1999> would've been nice if sochotni or akuratov had +1'd the request...
18:06:48 <nirik> I guess it would be nice if at least some other folks in the java sig... yeah.
18:07:04 <notting> but i could assume an implicit +1 from them if they asked him to do it
18:07:26 <abadger1999> <nod>
18:07:37 <nirik> yeah, I guess +1 based on that.
18:07:51 <t8m> mmaslano, do you know any details?
18:07:55 <mmaslano> no
18:09:11 <t8m> If we had package groups it would be a perfect case for allowing access to such java group, but we really don't so +1
18:09:28 <mmaslano> yes +1
18:09:41 <notting> yeah, +1
18:09:44 <sgallagh> +1
18:10:10 <nirik> more votes?
18:10:42 <nirik> #agreed request is approved (+5,0)
18:10:46 <abadger1999> +1
18:10:52 <nirik> #undo
18:10:52 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x1d8cde10>
18:10:55 <nirik> #agreed request is approved (+6,0)
18:11:01 <nirik> #topic #1113 Using PIE by default on AMD64
18:11:01 <abadger1999> if someone in java sig objects we can always revisit.
18:11:01 <nirik> .fesco 1113
18:11:01 <nirik> https://fedorahosted.org/fesco/ticket/1113
18:11:02 <zodbot> nirik: #1113 (Using PIE by default on AMD64) – FESCo - https://fedorahosted.org/fesco/ticket/1113
18:11:22 <mitr> In case you haven't seen it - I have just pasted Jakub's reply into the tiket
18:11:45 <sgallagh> Based on Jakub's response, I'm -1 here
18:12:05 * abadger1999 wishes someone would propose a test case
18:12:18 <mmaslano> me to -1
18:12:34 <t8m> I'd really like to see some serious numbers before voting for that, so for now +0
18:12:52 <t8m> Although I'd like to see prelink removed :)
18:12:57 <sgallagh> I'm unwilling to change the policy globally at this point
18:13:00 <nirik> I know jakub knows whats what, but the numbers really seem to be not supporting his contention.
18:13:08 <t8m> but again that would need some numbers
18:13:09 <abadger1999> the person asking for this seems willing to do the work to test... none of the test cases people have asked him to perform have shown a large performance degredation.
18:13:32 <mitr> I can sort of see a case for flipping the default and making it very easy to opt out - what isn't processing untrusted data these days?
18:13:33 <nirik> yeah.
18:14:00 <t8m> mitr, yeah that would be something I could support too
18:14:36 <nirik> it would also mean more differences between 32/64bit, which could be confusing to people.
18:14:51 * nirik is personally not a fan of prelink.
18:15:09 <mitr> PIE and prelink are almost completely unrelated
18:15:14 <nirik> true.
18:15:26 <nirik> well, aside from if you use PIE you can't prelink
18:15:49 <t8m> sure
18:15:54 <mitr> I'd expect that to be fixable.
18:16:08 <nirik> proposal: ask jakub/the list again for cases where "the cost is serious", revisit next week?
18:16:09 <notting> 3.6% overall is certainly significant in terms of overall performance. (compiler people would kill for a 3.6% improvement )
18:16:17 <mitr> notting: yeah
18:16:39 <mitr> notting: OTOH many users willingly sacrifice more than that for a safer language
18:16:50 <t8m> notting, but what does it mean in the reality when most of the code is already PIC in shared libraries?
18:16:59 <notting> was it chromeos that does pie for everything? or was that just full relro + full stack protector?
18:17:57 <notting> t8m: perhaps not as much. but the code in binary vs lib breakdown should be pretty easy to generalize across a system
18:18:33 <mitr> t8m: So, the change would make a difference for 1) CPU-performance-sensitive code 2) in the main binary 3) that isn't a server.  What categories of code are we actually talking about?  Numerical simulations?
18:18:57 <mitr> games?  (non-multiplayer ones)
18:19:08 <t8m> mitr, perhaps - which means an easy opt-out would be probably the best way
18:19:25 <notting> hm. there's an implication in that that we would want one default for fedora code, and another for customer/user code
18:20:24 <mitr> notting: We've always had that with redhat-rpm-config.  It's schizophrenic and we might want to unify that... but I'm not willing to invest too much into this aspect.
18:21:06 <nirik> are there other tools folks we should ask to weigh in?
18:21:29 * nirik imagines a %__turbo macro for non PIE. :)
18:22:13 <t8m> LOL
18:22:16 <mitr> %_funroll_loops
18:22:38 <abadger1999> nirik: maybe the security team?
18:22:56 <nirik> I think the reporter is part of the security team... but sure. ;)
18:23:32 <mitr> mitr and t8m are a part of another security team FWIW.  We haven't had direct input from the third security team yet :)
18:24:24 <notting> if you'd like, we can get the facilities security team involved too
18:24:37 <t8m> maybe if we created another security team we could get more input :)
18:24:48 <abadger1999> heh.  so many teams concerned with security ;-)
18:24:49 <mitr> So... where are we?
18:25:04 <nirik> "A quick evaluation for x64 reports an average overhead of 3.61% and a geometric mean of 2.34% for an -O3 opti-mization level on the same system using the “test” dataset"
18:25:20 <notting> ... note that -O3 isn't the default
18:25:22 <nirik> of SPEC CPU 2006
18:25:32 <nirik> so thats one older spec benchmark.
18:25:34 <jwb> that seems irrelevant
18:26:13 <dan408_> prime95!
18:26:32 <nirik> anyhow, I'd be in favor of another week for more feedback.
18:26:38 <abadger1999> ahh halfie == dhiru.  got it.
18:26:53 <nirik> Or if we wanted to vote now, I'd probibly be +0.5 for the proposal
18:27:11 <mitr> Proposal: FESCo is fine with using PIE by default on amd64, and would like to ask the submitter to prepare the required redhat-rpm-config changes and perhaps new macros, and get it ratified by the FPC.
18:27:18 <dan408_> not my place: but i have a feeling if you enable PIE by default a lot of things will start failing to compile
18:27:21 <mitr> I'm personally +0.5 currently
18:27:35 <nirik> mitr: does this need to go to FPC?
18:27:36 <notting> +0 as of now
18:27:52 <nirik> mitr: also, we should ask them to provide a way to easily opt out? or no?
18:27:55 <mitr> nirik: I'd expect some new macros to be introduced ("is PIE enabled in this build") that would benefit from a wider review.
18:27:59 <mitr> nirik: right
18:28:09 <sgallagh> I'd rather we document it as "recommended" and leave it up to the maintainers, personally.
18:28:17 <dan408_> +1 sgallagh
18:28:22 <abadger1999> mitr: new macro to opt out?
18:28:34 <mitr> mitr:  Proposal: FESCo is fine with using PIE by default on amd64 if packagers are given an easy way to opt out, and would like to ask the submitter to prepare the required redhat-rpm-config changes and policies, and get it ratified by the FPC.
18:28:35 <abadger1999> +0.5 to mitr's proposal
18:28:36 <dan408_> i find if code supports -PIE it will use it OOTB
18:29:05 <mitr> dan408_: Writing code that can't be complied as PIE requires writing assembler AFAIK.
18:29:59 <nirik> so, what does this mean for prelink? still shipped by default, but just exits uselessly on 64bit? (or I guess does the small number of opt out things?)
18:30:00 <dan408_> mitr: well seeing how much trouble it gave me when I tried to enable it with lightdm as well as Rex im just imagining a lot of things starting to fail to compile if you do it distro wide for amd64
18:30:06 <notting> i guess i'm more -1 to mitr's proposal *today*. if it is better, we should be able to (with the security team, if necessary/possible) be able to convince the toolchain team why
18:30:32 <jwb> notting, right.  i'm -1 on the same grounds
18:30:41 <abadger1999> I guess right now I have reservations due to jakub being against it but the data so far inclines me to vote for it.... really would like more data to be more solidly +/-
18:30:59 * nirik is with abadger1999, which is why I wanted another week.
18:31:07 <t8m> I agree we need more solid data
18:31:14 <mitr> abadger1999, nirik, t8m: Can you specify what kind of data precisely?
18:31:27 <sgallagh> If we're voting today, I'd be -1. If we want to ask for more information, that may change in a week
18:31:38 <mmaslano> still -1
18:31:39 <nirik> mitr: I want more data from jakub? some case(s) where "the cost is serious"
18:31:46 <mitr> I'm fine with waiting another week in any case if it helps; just saying "we want more data" isn't too likely to make us decide next time.
18:31:58 <dan408_> i think sgallagh made a sane proposal, if you guys +1 this today or 7 days from now the instructions provided to enable it were not sufficient
18:32:08 <abadger1999> Proposal : defer, ask Jakub/tools team for a test case that we can get numbers of where performance degrades and to what extent.
18:32:33 <nirik> abadger1999: +1
18:32:46 <sgallagh> Aside: I have a hard stop in 28 minutes and I know we have another involved topic to discuss...
18:32:54 <t8m> abadger1999, I suppose you can create artificial example where the performance degrades seriously
18:33:22 <nirik> sure, I'd want some cases of fedora packages...
18:33:29 <abadger1999> t8m: how about: "where real world performance degrades[...]" ?
18:33:32 <t8m> nirik, OK then
18:33:33 <notting> abadger1999: +1
18:33:36 <t8m> abadger1999, OK
18:33:39 <jwb> i'd like to see numbers based on the current rpm macro settings too.  not -O3
18:33:39 <abadger1999> +1
18:33:50 <t8m> jwb, +1
18:34:07 <nirik> so thats +4 for abadger1999's proposal?
18:34:11 <abadger1999> jwb: +1  So for halfie, could we have numbers based on current rpm macro settings, not -O3
18:34:12 <sgallagh> +1
18:34:20 <mitr> I guess I'd like to see what cases of packages are harmed by the proposal; the list we have so far (numeric simulations incl. games) isn't too convicing but we may have missed something.
18:34:24 <sgallagh> Clarity: that's +1 to getting more information from the tools team
18:34:27 <mitr> abadger1999: +1
18:34:58 <dan408_> a display manager..
18:35:03 <nirik> #agreed defer, ask Jakub/tools team for a test case that we can get numbers of where performance degrades and to what extent. (+6,0)
18:35:22 <nirik> #topic #1115 guidance from FESCO on packagekit upstream policykit change
18:35:22 <nirik> .fesco 1115
18:35:22 <nirik> https://fedorahosted.org/fesco/ticket/1115
18:35:24 <zodbot> nirik: #1115 (guidance from FESCO on packagekit upstream policykit change) – FESCo - https://fedorahosted.org/fesco/ticket/1115
18:35:31 <halfie> hi, just got in.
18:36:12 <t8m> halfie, too late :)
18:36:33 <sgallagh> So this ticket has seen a lot of discussion on Trac
18:36:45 <halfie> no worries, I am very happy with the resolution. I am willing to work on getting those numbers.
18:37:31 <sgallagh> So as Mirek pointed out, the upstream change here to allow all users the ability to install signed packages without a password is in direct violation of published policy.
18:37:31 <mitr> Let me try to simplify this a little...
18:38:02 <sgallagh> However, since that policy was written (last updated Feb 2010) we have added a new Administrator concept around membership in the wheel group
18:38:21 <t8m> I'd be fine with letting wheel group members install such packages without password
18:38:21 <mclasen> the packages that this is all about contain nothing but videos...
18:38:25 <mitr> sgallagh: No, the administrator concept is explicitly included by the policy; it was one of the results of that discussion.
18:38:25 <sgallagh> I'd argue that this change would probably be acceptable if limited to those users.
18:38:44 * nirik waits for mitr's simplication.
18:38:58 <jwb> mclasen, videos?
18:39:12 <mitr> proposal: The privilege escalation policy stands (for the default configuration, not necessarily for all spins - explicitly the desktop spin can have a different configuration) and the change should be reverted.  Now we'll talk about the users in "wheel" group.
18:39:22 <mclasen> yes, the original motivation for the upstream change is to support lang-pack installation of the gnome-welcome-tour videos
18:40:51 * mclasen has stunned fesco into silence
18:40:52 * nirik isn't sure he's for that until he sees the further proposals.
18:40:54 <mitr> (that's end of the proposal, not "next part of the proposal will talk about wheel")
18:41:28 <notting> mclasen: that may be , but the ability can't be constrained to that in the current implementation
18:41:41 <t8m> mitr, +1
18:41:42 <abadger1999> mclasen: according to the ticket, the pakcagekit code isn't able to limit to a specific package or type of package, though... is that correct or incorrect?
18:42:14 <sgallagh> abadger1999: There's no inherent metadata in a package that PackageKit could base that on as far as I'm aware.
18:42:20 <mclasen> thats correct - yum can't either...
18:42:24 <mitr> abadger1999: That's fixable in various ways (not for f19 beta of course)
18:42:28 <abadger1999> <nod>
18:43:06 <mitr> mclasen: That doesn't make sense to me - do we want the very first thing the user sees on login a progress dialog (... to download a vide that the user will never see again)?  The videos (or something equivalent that isn't that large, perhaps) should just be installed by default
18:43:09 <abadger1999> yep.  Just wanting to be clear that the ticket is expressing what we'd be okaying or not okaying... not just installing videos or not.
18:43:12 <sgallagh> For the record, I'm +1 to mitr's first proposal, though I expect we'll have much to discuss with 'wheel'
18:43:51 <nirik> mitr: so, your proposal would mean thats the default policy, but any spin or group could write their own from scratch? or ?
18:43:53 <mitr> This also btw. my general objection to installation on demand - we're better off just installing most of those things by default anyway, like we did with fonts for all the world's languages IIRC
18:44:04 <sgallagh> mclasen: In addition to mitr's comment: how does that work in the case of a disconnected install (which is probably the default in today's WiFI world)
18:44:06 <abadger1999> sgallagh: there are numerous knobs here... what's teh proposal?
18:44:06 <mitr> nirik: They already can do that
18:44:35 <sgallagh> abadger1999: The one mitr proposed starting with "proposal: the privilege escalation policy stands..."
18:44:37 <abadger1999> oh I see...
18:44:53 <abadger1999> +1 mitr's proposal for status quo for default configuration.
18:45:06 <mmaslano> me too +1
18:45:16 <nirik> mitr: not according to the policy?
18:45:17 <notting> that would be s/yes/auth_admin/, essentially?
18:46:04 <mitr> nirik: " In the case of an approved Fedora spin which automatically grants administrative privileges to the first created user account, authentication as that user can be considered administrative authentication;" etc.
18:46:19 <mitr> nirik: Perhaps it doesn't cover some case you are thinking of?
18:46:21 <nirik> ok, I couldn't find that in there.
18:46:49 <mitr> notting: Yes (the old version had auth_admin_keep in there IIRC)
18:46:50 <nirik> sure, I am fine with starting from the existing policy and modifying it as we feel or not for this case...
18:48:14 <notting> i can agree with changing the hardcoded 'yes' due to the policy (unless we change the policy...)
18:48:49 <abadger1999> I think if nirik and notting are +1 then we're at +6
18:48:57 <notting> but i don't think we should stop there
18:49:06 <abadger1999> <nod>
18:49:07 <nirik> sure, lets actually look at this case now?
18:50:03 <abadger1999> sgallagh: So... what do you believe has changed with wheel/what does the wheel group allow a user account to do now?
18:50:34 <nirik> so, the request is to remove upgrading or installing system wide packages from the list of things normal users should not be allowed to directly do right?
18:50:46 <sgallagh> Well, compared to Fedora 12, we now have at least an accepted way to identify a user who is known to be "privileged"
18:50:48 <nirik> or some variant on allowing that
18:50:55 <pjones> (er, sorry I'm late.  Stuff came up.)
18:51:00 <sgallagh> Whereas that would previously have been ambiguous (as of F12 when this last came up)
18:52:02 <abadger1999> sgallagh: so.... wheel group has become the official method of marking an account as being more special than general user?
18:52:34 <sgallagh> Well, the use of "wheel" is a fedora-ism, but in general desktop-land, there's an "Administrator" concept that we just translate into that group
18:52:50 <sgallagh> It's therefore presumably acceptable for users in this group to be granted more leeway with decision-making
18:53:04 <abadger1999> sgallagh: k.  And what is that "Administrator" concept allowed to do right now without retyping in their password?
18:53:40 <sgallagh> abadger1999: Now we're getting to the part of the policy that I think may be malleable.
18:53:42 * abadger1999 asks because he's only used wheel in conjunction with PASSWD-sudo... so the usage there would imply retyping the password is still the expectation
18:53:49 <sgallagh> The answer there is "little", but I think that may be wrong
18:54:15 <sgallagh> For a non-privileged user, prompting for a privileged user's password makes sense. I think we'll all agree on that.
18:54:36 <sgallagh> But for a privileged user, re-prompting for the password serves only to address the walk-by-attacker problem
18:54:54 <sgallagh> And let's be honest: if physical security has been compromised, one password dialog does not a secure system make.
18:55:10 * nirik nods.
18:55:15 <mitr> abadger1999: Right now polkit would ask for the user's password instead of root's password; gnome-control-center has a weird rule that allows "wheel" to set hostname without any password; and that's mostly it.
18:55:56 <nirik> we also grant prvis to "local" users.
18:56:07 <nirik> ie, acls for sound devices, usb ownership, etc.
18:56:08 <notting> mitr: locale, keyboard, and hostname, to be precise
18:56:25 <abadger1999> wouldn't it include other local compromises, not just physical compromises?  For instance if I get your unencrypted ssh private key?
18:56:29 <mitr> notting: I suppose that's changed since f18 then
18:56:42 <sgallagh> Right, so I'm suggesting that the active console user who is a member of the wheel group should probably be eligible to install software without reauthenticating
18:56:42 <notting> mitr: (by reading the rule file)
18:56:51 <notting> abadger1999: that's not local
18:57:03 <sgallagh> abadger1999: I'm talking about active user (which policykit can differentiate)
18:57:08 <sgallagh> An SSH session would not qualify
18:57:28 <nirik> I'm not sure requiring wheel there is needed... what does it gain us?
18:57:28 <mclasen> mitr: that control-center rule was more of a workaround for a ui deficiency, we should get rid of it
18:57:55 <abadger1999> sgallagh: okay -- so you're proposing both 1) wheel group/Administrator group and 2) physical session on the box.
18:57:58 * sgallagh has to run in three minutes
18:58:02 <nirik> it's still someone who has been granted access... and is local to the machine and can probibly break in pretty easily.
18:58:02 <sgallagh> Yes, exactly.
18:58:25 <pjones> nirik: as much as that's somewhat true, let's pretend it isn't for these purposes?
18:58:26 <sgallagh> So the auth has already been validated by *DM or *-screensaver at this point
18:58:33 <pjones> nirik: I mean, there *could* be physical security.
18:58:39 <nirik> sure, I suppose.
18:58:53 <mitr> sgallagh: 1) There's also the "signaling" benefit - "I want your password because this is a serious decision"... which is kind of ridiculous but also kind of true, 2) Not prompting for a password makes reasonable sense only when a screensaver locks after a timeout
18:58:57 <nirik> I just suspect if we require that, everyone will just add everyone to the wheel group
18:59:29 <mitr> pjones: When there is physical security, the users are typically not in "wheel".
18:59:30 <sgallagh> nirik: What are you responding to?
18:59:50 <sgallagh> mitr: Sure, but I'm hoping that we can at least ask for a "yes-or-no" prompt instead of a full password prompt.
18:59:52 <nirik> the above proposal?
19:00:03 <sgallagh> Then we're also avoiding the "train the user to enter their password everywhere" problem
19:00:24 <mitr> sgallagh: I'm willing to bet the "yes/no" prompt isn't going to happen in GNOME upstream.
19:01:04 <mitr> Technically it might be doable in polkit, but...
19:01:06 <nirik> counterproposal: local users are allowed to use PK to install/update signed/trusted packages from their active local session.
19:01:08 <mclasen> its already happening in most of these cases - eg you get the 'gnome-terminal wants to install a font' - yes/no ? dialog
19:01:09 <sgallagh> I unfortunately have to go and collect my daughter from daycare now. Sorry, but you may assume a +1 vote to my own proposal if it comes to that.
19:01:12 <otaylor> sgallagh:  "yes-or-no" prompt can't *securely* be provided at the PolicyKit level, so there's no benefit of doing it there compared to just doing it in the triggering application (an UI expectation on software that uses PackageKit to install packages)
19:01:15 <nirik> (without password) sorry
19:01:31 <abadger1999> nirik: -1
19:01:32 <mitr> nirik: -1
19:01:34 <sgallagh> nirik: -1
19:01:37 <nirik> ok.
19:01:48 <notting> nirik: *any* local user? i  could be +1. but that's contrary to the priv escalation policy
19:01:56 <sgallagh> If everyone opts to use the wheel group, that's their own decision
19:01:59 <nirik> active, logged in at console.
19:02:02 <sgallagh> I don't want to make that the expected behavior
19:02:13 <nirik> wheel also grants them sudo remotely.
19:02:39 <mitr> sgallagh: I have just found https://bugzilla.redhat.com/show_bug.cgi?id=852393 on that note :/
19:02:39 <nirik> notting: yeah, we would need to modify it, but sounds like folks don't like the idea. ;(
19:02:42 <sgallagh> and now really gone (will read scrollback, or send me an email with the proposals being voted on and I'll reply by phone
19:03:01 <mmaslano> nirik: -1
19:03:10 <notting> proposal: local, active, admin user can update/remove/etc. signed software w/o password?
19:03:10 <abadger1999> sgallagh: let us know when you get back if the meeting hasn't ended ;-)
19:03:23 <nirik> could the -1 folks say what their concern is with that?
19:03:36 <sgallagh> notting: +1 (since that's effectively the same as what I've been saying)
19:03:40 <nirik> notting: +1, but I'm for even non admin I think... barring more info. ;)
19:03:43 <mitr> nirik: The problem with auto-installation is especially for codecs, where codecs are the worst ever thing to auto-install (I send the user an email with a link to a website, that website serves a video in an obscure format, the system happily installs the vulnerable code and runs the exploit)
19:03:49 <abadger1999> notting: where admin user == marked as admin via wheel or polkit?
19:04:02 <nirik> mitr: this codec is signed and in our repos?
19:04:12 <mitr> nirik: yes, but "obscure"
19:04:16 <abadger1999> I don't like packages being installed without the admin user's knowledge, though..
19:04:24 <notting> abadger1999: wheel. users marked as admin via other mechanisms in polkit aren't exposed to the polkit rules engine that way. (yes, i find this weird)
19:04:27 <mitr> Codecs and image formats are fairly high-risk software.
19:04:40 <t8m> notting, +1
19:04:41 <abadger1999> notting: huh.  Okay :-)
19:04:45 <nirik> so a 'admin' user would be more clued on this somehow?
19:04:46 <mitr> notting: I don't like the idea of making package installation that much of a special case.
19:04:52 <pjones> nirik: might be signed and in rpmfusion?
19:05:16 <mclasen> mitr: but fonts, videos, docs etc are comparatively low risk
19:05:23 <abadger1999> Okay--  still want some way to make sure the user is notified that the package is being installed.
19:05:25 <notting> mitr: but we allow the users the ability to compromise themselves like that already (fonts, codecs, etc. can all be installed local to the user)
19:05:37 <nirik> pjones: sure
19:05:38 <abadger1999> if the only way to do that now is via a password dialog... :-(
19:05:48 <mclasen> now, one could argue that those should not be in rpms to begin with, but i'm in the wrong channel for that :-)
19:05:57 <EvilBob> Or in "The Repo That Shall Not Be Named" that was set up and enabled by a "admin" with little experience
19:05:58 <otaylor> abadger1999: Do you know of any auto-installation on the desktop that doesn't prompt the user first?
19:06:01 <notting> abadger1999: that notification would be via the requesting app
19:06:01 <mitr> notting: If the user can be social-engineered to do _that_ i'm not feeling guilty
19:06:30 <abadger1999> notting: <nod>  So could we put that into the proposal?
19:06:35 <nirik> you can social enginneer people to do lots of things. ;) But we can't protect them from all possible social engineering.
19:06:47 <notting> mitr: users can be socially engineered for a lot. "hi, onion? plz to give us your password. thanks, syria"
19:06:49 <mitr> notting: Still, the required signature does make it a little of a special case.
19:07:05 <abadger1999> the proposal right now doesn't specify which part of the stack is enforcing things... just that those things have to happen or not happen.
19:07:37 <abadger1999> so I'd like it to say that asking the user to confirm the installation is mandatory.
19:08:17 <abadger1999> with that addition I think I'm +1
19:08:49 <notting> proposal: (amended) local, active, admin user can update/remove/etc. signed software w/o password. apps using this should not operate without confirmation from the user.
19:09:11 <nirik> sure, +1
19:09:13 <abadger1999> notting: +1
19:10:25 <nirik> more votes?
19:10:35 <t8m> notting, +1
19:10:37 <pjones> notting: +1
19:10:39 <mitr> Will we be voting about the same thing for the firewall or udisks within a month?
19:10:53 <t8m> mitr, heh, good question
19:11:08 <notting> ... heh. likely?
19:11:14 <nirik> so, shall we generalize? or ?
19:11:36 <mitr> I'm kind of thinking that "local active admin user with a screensaver set" should perhaps not require a password prompt.
19:11:52 <abadger1999> mitr: If there's nothing on the agenda for next week, maybe we want to stew on how to generalize and propose something next week?
19:12:05 <mitr> However 1) I'm not sure how this interacts with not-so-trusted applications, which seems to be the future, and 2) we don't need to decide today
19:12:25 <notting> mitr: maybe generalize for the future
19:12:46 <nirik> ok, so defer to next week for concrete proposals?
19:13:07 <notting> well, i think mine passed? unless people want to detract and defer
19:13:15 <notting> er, *re*tract
19:13:17 <nirik> so it did.
19:13:24 <nirik> Do we want to block beta on this?
19:13:28 <abadger1999> notting: assuming you're +1 on your own proposal :-)
19:13:37 <nirik> #agreed local, active, admin user can update/remove/etc. signed software w/o password. apps using this should not operate without confirmation from the user.
19:13:40 <notting> abadger1999: i am, and sgallagh says he was on the unamended version
19:13:45 <abadger1999> <nod>
19:13:58 <notting> nirik: -1 to blocking beta. but would take the fix if we had it and happened to be respinning
19:14:14 * abadger1999 agrees with notting
19:14:28 <mitr> nirik: Per comment #10 it's too late, and a release note is good enough for beta.  We do want to block GA though.
19:14:30 <nirik> adamw suggested we note the current behavior so no one is surprised in beta.
19:14:32 <abadger1999> adamw mentioned wanting to put a big disclaimer in the beta release notes as well.
19:14:35 <nirik> right
19:14:36 <abadger1999> jinx
19:14:50 <notting> adamw: you ok handling that for beta relnotes?
19:14:56 <adamw> we are doing an rc4 today so we could try and ram a reversion in, but it kinda gives me the screaming heebie jeebies
19:15:12 <t8m> mitr, +1
19:15:23 <adamw> notting: um, probably? i think that just goes through rbergeron, right?
19:15:39 <notting> you have seen through my plan of delegating it b/c i didn't remember the procedure.
19:15:44 <notting> curse you!
19:15:51 <nirik> so, do we close this since we agreed on something? or also leave it open for the more general proposals next week?
19:16:15 <adamw> notting: :)
19:16:44 * nirik would like to see a more general one
19:16:47 <notting> nirik: i'd have mitr (or anyone who has a proposal) open a new ticket?
19:16:48 <abadger1999> nirik: I'd like a new ticket.  if people are agreed that we'll discuss it next week, I'll take care of opening the ticket.
19:16:55 <nirik> ok.
19:16:56 <mitr> I'm personally not likely to invest too much time into implementing the general version soonish
19:17:02 <nirik> anything else on this?
19:17:03 <abadger1999> I just might not be the one to make a proposal :-)
19:17:21 <nirik> #topic next week's chair
19:17:32 <t8m> nirik, I can do it
19:17:49 <nirik> thanks
19:17:55 <nirik> #info t8m to chair next week.
19:18:00 <nirik> #topic Elections
19:18:12 <nirik> elections are coming up, please put in your name if you want to run.
19:18:47 <nirik> 2013-05-26 is the deadline.
19:19:00 <nirik> https://apps.fedoraproject.org/calendar/list/Elections/
19:19:27 <nirik> we only have 2 fesco nominations so far.
19:19:30 <mitr> nirik: Please add the first resolution (reverting etc.) to #1115 as well.
19:20:05 <nirik> hum?
19:21:00 <nirik> what are we reverting?
19:21:04 * nirik might need more coffee.
19:21:06 <abadger1999> nirik: for f19
19:21:27 <abadger1999> although I'm not sure if that's what we agreed to or not.
19:21:32 <mitr> nirik: "proposal: The privilege escalation policy stands (for the default configuration, not necessarily for all spins - explicitly the desktop spin can have a different configuration) and the change should be reverted.  Now we'll talk about the users in "wheel" group." (or didn't it pass?)
19:22:06 <nirik> ok. I'm not sure it makes sense to say "Our policy is still our policy", but feel free to add that to the ticket?
19:22:31 <mitr> will do
19:22:47 <nirik> #topic Open Floor
19:22:53 <nirik> any items for open floor?
19:23:20 <abadger1999> #topic flock talk submission deadline
19:23:35 <abadger1999> May 31, 2013 at 11:59 p.m. ET
19:23:56 <abadger1999> (Note: timezone is not UTC)
19:23:58 * nirik nods.
19:24:06 <abadger1999> #topic Open Floor
19:24:35 <mitr> Has anyone proposed a talk to discuss the FUDCon Lawrence-originated "revamp" yet?
19:25:34 <abadger1999> Current proposals: http://flock-lmacken.rhcloud.com/proposals
19:25:42 <pjones> mitr: kind of assuming you would ;)
19:25:58 <nirik> there's one on there I thought.
19:26:09 <nirik> I thought sgallagh_afk submitted one
19:27:36 <nirik> "The totally new Fedora Changes Process: A tutorial"
19:27:41 <nirik> similar I guess
19:27:50 * mitr makes a note to make sure, later
19:28:17 <abadger1999> I see another one as well: "The old new planning process"
19:28:36 * nirik will close out in a min if nothing else.
19:29:07 <abadger1999> maybe people who are okay with having their names on talks should add their names to their talk summaries... /me asks on the flock planning list.
19:29:42 <nirik> the question was already asked there about the names. ;) but sure.
19:29:50 <nirik> thanks for coming everyone!
19:29:54 <nirik> #endmeeting