===================================
#fedora-meeting: FESCO (2013-05-22)
===================================
Meeting started by nirik at 17:59:59 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2013-05-22/fesco.2013-05-...
.
Meeting summary
---------------
* init process (nirik, 17:59:59)
* #1098 F19 Features - Progress on Features 100% Complete (nirik,
18:02:00)
* LINK:
https://fedorahosted.org/fesco/ticket/1098 (nirik, 18:02:00)
* AGREED: This is done, close now. (nirik, 18:05:24)
* #1114 Would like to become a provenpackager (nirik, 18:05:33)
* LINK:
https://fedorahosted.org/fesco/ticket/1114 (nirik, 18:05:34)
* AGREED: request is approved (+6,0) (nirik, 18:10:55)
* #1113 Using PIE by default on AMD64 (nirik, 18:11:01)
* LINK:
https://fedorahosted.org/fesco/ticket/1113 (nirik, 18:11:01)
* 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)
(nirik, 18:35:03)
* #1115 guidance from FESCO on packagekit upstream policykit change
(nirik, 18:35:22)
* LINK:
https://fedorahosted.org/fesco/ticket/1115 (nirik, 18:35:22)
* 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. (nirik, 19:13:37)
* next week's chair (nirik, 19:17:21)
* t8m to chair next week. (nirik, 19:17:55)
* Elections (nirik, 19:18:00)
* LINK:
https://apps.fedoraproject.org/calendar/list/Elections/
(nirik, 19:19:00)
* Open Floor (nirik, 19:22:47)
* flock talk submission deadline (abadger1999, 19:23:20)
* Open Floor (abadger1999, 19:24:06)
Meeting ended at 19:29:54 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (116)
* abadger1999 (61)
* mitr (59)
* sgallagh (43)
* notting (38)
* t8m (27)
* zodbot (9)
* mmaslano (8)
* mclasen (8)
* dan408_ (7)
* pjones (6)
* jwb (4)
* adamw (3)
* halfie (2)
* otaylor (2)
* EvilBob (1)
* jreznik (1)
--
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