17:01:19 #startmeeting fpc 17:01:20 Meeting started Thu Nov 13 17:01:19 2014 UTC. The chair is geppetto. 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 fpc 17:01:20 The meeting name has been set to 'fpc' 17:01:20 #topic Roll Call 17:01:24 Howdy. 17:01:28 geppetto limburgher mbooth orionp racor Rathann SmootherFr0gZ spot tibbs|w tomspur: FPC ping 17:01:35 #chair tibbs 17:01:35 Current chairs: geppetto tibbs 17:01:37 Hey 17:01:38 * limburgher here 17:01:39 morning 17:01:44 #chair limburgher 17:01:44 Current chairs: geppetto limburgher tibbs 17:01:47 #chair orionp 17:01:47 Current chairs: geppetto limburgher orionp tibbs 17:01:50 * tomspur is here 17:01:52 * Rathann gere 17:01:55 #chair tomspur 17:01:55 Current chairs: geppetto limburgher orionp tibbs tomspur 17:01:56 *here 17:01:58 #chair Rathann 17:01:58 Current chairs: Rathann geppetto limburgher orionp tibbs tomspur 17:02:37 Sorry about last week. 17:02:42 no problem 17:02:49 #chair mbooth 17:02:49 Current chairs: Rathann geppetto limburgher mbooth orionp tibbs tomspur 17:02:49 Sorry I'm late 17:03:27 mbooth: 6 demerits. This is going on your permanent record. 17:03:37 mbooth - that doesn't qualify as late by FPC standards :) 17:03:59 Nah. I think up to 45 is "on time". ;) 17:04:05 minutes-----------^ 17:04:14 :-) 17:04:43 SmootherFrOgZ: FPC ping 17:05:52 ok, going to start anyway … we have 7 17:06:06 #topic #467 Consider requiring all files in /usr to be world-readable 17:06:15 https://fedorahosted.org/fpc/ticket/467 17:06:39 * SmootherFrOgZ here 17:06:44 tibbs: You seem to have looked at this during the week … and thoughts 17:06:45 * racor is here 17:06:48 #chair SmootherFrOgZ 17:06:48 Current chairs: Rathann SmootherFrOgZ geppetto limburgher mbooth orionp tibbs tomspur 17:06:50 #chair racor 17:06:51 Current chairs: Rathann SmootherFrOgZ geppetto limburgher mbooth orionp racor tibbs tomspur 17:06:55 Well, my input is all in there. 17:07:10 The current guidelines do seem to cover this, but the language is kind of iffy. 17:07:17 We were less precise way back when. 17:08:20 In summary... 17:08:47 I think cleaning up the language is good, but requiring some committee vote for exceptions is overkill. 17:09:46 I also can't say much about the security implications of this. There's more info in https://fedorahosted.org/fpc/ticket/286 about security stuff. 17:09:49 I'm inclinde to agree. 17:10:08 Do we want to allow people to have non world readable exes in /usr/sbin and/or /usr/bin ? 17:10:24 I guess the best example would be sudo. Why is it mode 4111? What happens if it isn't? 17:11:10 IIRC (it's been at least a couple of years) the security group that dealt with govt. stds. wanted a bunch of exes to not be readable 17:11:18 We already don't allow it, technically. 17:12:00 Yeh, but do we want to say all those apps. are violating it and anyone is free to file bugs and say it's against policy? 17:12:36 That's a fight in which we generally don't involve ourselves.... 17:12:37 I don't really mind that … but then I also don't see the need to have everything be world readable … apps. should handle it better 17:13:01 So there are a couple of arguments, I guess. 17:13:26 One is the security by obscurity thing, which I really don't buy since our binaries are the same all over the planet. 17:13:34 And esp. in the ticket the whole thing about files should be readable but dirs. don't have to be … seemed like insanity, just fix your apps. to treat files like dirs. then 17:14:01 tibbs: To be fair I think this happened when prelink was a thing … so the apps. did technically change. 17:14:33 Well sudo, for example, has been mode 4111 since it was imported into public CVS in 2004. 17:14:51 So I'm guessing it's always been that way. 17:14:54 "tradition"? 17:14:58 yeh 17:16:46 ok, I think there are enough use cases to go ahead with this 17:16:51 Well, as I said … I kind of feel like everyone is wrong here. So I don't really mind who we annoy. 17:16:57 +1 to making everything world readable 17:16:58 sudo doesn't seem to care; it works just fine mode 4555 and mode 4755. 17:17:00 in /usr 17:18:26 So, I'd propose to strike "in the majority of situations" and change should to must in the first paragraph of http://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions 17:19:58 Should we explicitly mention /usr there? 17:20:21 I guess yes 17:20:42 non-config and non-state == /usr ? 17:21:27 I'm somewhat worried about anyone using /usr/etc 17:21:29 but meh. 17:21:31 +1 17:22:11 So anything in /usr is a must and the rest a should? 17:22:21 $ ls -l /usr/etc 17:22:21 ls: cannot access /usr/etc: No such file or directory 17:22:30 Nothing in the distro provides it, either. 17:22:31 not in default Fedora install 17:22:33 just looked at util-linux for chfn/chsh … and they both have "always" been non-readable 17:22:56 Ok, cool 17:22:58 But yeah, this guideline does apply to more than just /usr, so I guess special casing /usr for "must"ing would be good. 17:23:02 I thought some weird stuff did 17:23:06 ssh-agent is non-readable too, but works if it is 17:26:31 So we have +3 for tibbs proposal, so far? 17:27:01 I'm +1 too, all the reasons against doing this sound like "security theatre" to me 17:27:08 I agree with the latest one with special casing /usr for "must"ing 17:27:11 I'm trying to figure out how to clarify /usr versus other stuff. 17:27:36 * geppetto nods … ok, I'll give tibbs a couple of minutes to do a new proposal and then we can all vote again :) 17:27:53 Can't figure out how to say "unless there is some reason not to do so" in a guidelines-y fashion. 17:28:22 "without prior approval from FPC"? 17:28:30 I sure hope not. 17:28:37 "except under extenuating circumstances" ? 17:28:49 +1 17:28:56 And wouldn't those circumstances need to be vetted by FPC/FESCo? 17:29:04 We don't want to get into the business of having to approve every group-specific permission thing in /etc, for example. 17:30:28 http://fpaste.org/150547/89981314/ 17:30:54 Smells like sanity. 17:31:08 I'm pretty sure root:root ownership can't be a must 17:31:42 there are setgid bins at least 17:31:47 right 17:31:53 yeh 17:32:11 That's kind of the problem we ran into at the beginning. 17:32:32 It's basically "must do this unless you have one of a huge number of reasons not to do this". 17:33:01 let's focus on "must be universally readable " ? 17:33:10 which is the question at hand 17:33:23 Drop group ownership entirely? 17:33:39 Or "files should be group root unless setgid" ? 17:33:51 How about: Inside of /usr files should be owned by root:root, unless a more specific user/group is needed for security. They should be writable only by the owner and universally readable (and executable if appropriate). 17:34:44 Sounds good for me. 17:34:50 But, should or must? 17:35:10 It's not like we have precise definitions of either. 17:35:12 The second should is a must, right? 17:35:31 Yeah, I think that's the whole point of this. 17:35:45 Well, though, I thought root ownership was a good security practice for things that run as other users? 17:35:49 change user/group to group 17:36:11 How about: Inside of /usr files should be owned by root:root, unless a more specific user/group is needed for security. They must be universally readable (and executable if appropriate). 17:36:59 orionp: I can imagine some packages have myowner:root 17:37:08 orionp: So it seems weird to just say group 17:37:58 +1 17:38:37 geppetto - true I guess I was focusing on binaries only 17:39:31 So we're at http://fpaste.org/150551/41590035/ 17:39:36 ? 17:39:39 If so, +1 17:39:45 Ok, +1 17:40:33 +1 17:40:38 +1, fixing secirity typo :) 17:40:42 Yeah. 17:40:51 Oh, go on then :) 17:41:01 hm 17:41:40 I dropped the writable bit, as it seemed hard to get correct with all the possabilities 17:41:56 this is a bit contradictory: if a file is not owned by root then current wording will require that it's not writable by that user 17:42:11 yeh 17:48:45 Ok, so: http://fpaste.org/150552/90090314/ 17:49:01 +1 17:49:31 +1 17:49:36 +1 17:50:23 +1 17:51:54 we are retaining the current "shoulds" about default modes (0755/0644 and 2775), right? 17:52:37 0 ... I am uncertain and am not sure what to think about this. 17:53:41 Rathann: I understood that we are only re-writing the first paragraph -- the note about group writable dirs should be retained, I think 17:53:46 Rathann: yeh 17:53:50 ok, then 17:53:51 +1 17:54:32 limburgher: vote? 17:55:18 I'd also add a requirement to justify and document non-standard (root:root 644/755) ownership in the specfile 17:58:27 Ok, one last time … now have the whole section: 17:58:30 http://fpaste.org/150558/01488141/ 17:59:31 +1 17:59:38 ehhh, now it looks like the default modes apply only outside /usr 17:59:40 +1 18:00:04 Human languages.... so imprecise. 18:02:12 how about this? http://fpaste.org/150562/41590171/ 18:02:17 Rathann: I didn't want to repeat that bit :( 18:02:23 * geppetto looks 18:03:15 Yeh, that looks fine to me 18:03:15 +1 18:03:16 I am turning my vote into a -1 18:03:16 +1 18:03:24 Sorry, called away, reading. . . 18:03:39 or s/Default file mode/Files should be mode/ 18:03:42 racor: Want to change anything? 18:03:42 +1 18:03:44 I don't think we haven't yet fully understood the breadth of the problems 18:03:48 I'm basically +1 to all of these. 18:04:37 e.g. did you consider the files under /usr/sbin which intentionally are o-r to keep them out of an ordinary user's PATH 18:04:47 racor: all the packaged files are available publicly anyway in Fedora repositories, so what's the point of making them unreadable? 18:05:14 To keep them out of an ordinary user's PATH 18:05:21 any user can download the package, unpack it and put the same binary in her own $HOME/bin 18:05:27 This has nothing to do with obsurity 18:05:40 wait wait 18:05:45 this is about run-time accessabitity 18:05:54 the files can still be non-executable 18:06:04 i.e. 754 or 744 18:06:28 we're not adding MUST be world executable 18:06:33 only world readable 18:06:46 The weirdest example I can think of is apache suexec. 18:07:07 -r-x--x---. 1 root apache 19456 Jul 23 05:31 suexec* 18:07:29 I think that one hits all of the weird spots. What would break if it changed? 18:07:42 Run "which audispd" as root and as normal user and you'll see the difference 18:07:53 Also, isn't "must be kept out of the user path" something you'd simply document in the spec file as the guideline indicates and move on? 18:08:02 I mean, the guideline doesn't break anything. 18:08:05 -rwxr-x---. 1 root root 49120 Oct 28 18:13 audispd 18:08:11 tibbs: Hmm, I wonder why suexec is not in libexec? 18:08:27 mbooth: Probably reasons. 18:08:40 racor: And so why should that not be documented in the spec? 18:08:58 racor: which package is that? I can't find it 18:09:13 I mean, this guideline comes down to "unless you have a reason, do this. If you have a reason, document it" 18:09:23 racor: Try adding just readability for the user and try it again … it should act the same way 18:09:29 Not sure how you can really poke holes in that. 18:10:06 racor: We aren't saying all programs should be executable by the user 18:11:04 * Rathann will be away for about 10 minutes 18:12:19 geppetto: We don't say this, but we force packager to make them act this way. 18:12:19 orionp: mbooth: You want to vote again on http://fpaste.org/150562/41590171/ ? 18:12:30 sure, +1 18:12:30 racor: I don't see how 18:12:53 "They must be universally readable" 18:13:07 racor: Yes, but 754 satisfies that and isn't executable 18:13:08 +1, LGTM 18:14:11 Anyway, moving on 18:14:12 #topic #468 Temporary modernizr packing exception for kimchi 18:14:18 https://fedorahosted.org/fpc/ticket/468 18:15:29 Ok, I am running out-a-time and have to quit for today. 18:15:31 I guess … why can't you just package modernizr? 18:15:40 * geppetto nods, ok 18:15:42 Is kimchi in the distro? Doesn't appear to be in F20 at least. 18:16:01 geppetto: I had the same thought, I don't see any review open for modernizr 18:16:01 I assume baude is trying to package it now? 18:16:24 https://bugzilla.redhat.com/show_bug.cgi?id=1126990 is the review for kimchi 18:16:34 * geppetto nods... was just checking that :) 18:17:33 #action Just package modernizr, instead of bundling it. 18:17:38 I'm definitely in the just package modernizr camp 18:17:41 +1 18:17:51 +1, at least show willing 18:17:56 +1 18:18:02 #action If still desire to bundle it, please answer the std. bundling questions. 18:18:08 Ok, cool 18:18:16 #topic Open Floor 18:18:31 geppetto: Got time to look at #471? 18:19:28 damn, hadn't seen 469+ 18:19:34 +1 for the gradle thing. 18:19:39 +1 18:19:45 for 468 18:19:56 sorry, keep getting busy. 18:20:12 I don't see 471 … just 470 18:20:39 Oh, nevermind … didn't refresh 18:21:13 #topic #471 Bootstrap exception for Gradle 18:21:34 I think we sitll have 5 … so can vote on this 18:22:14 +1 18:22:23 I am +1 to this 18:22:37 +1 18:23:17 +1 for the record 18:23:35 limburgher: vote for 471? 18:23:38 +1 18:27:30 #action Bootstrap exception for Gradle (+1:5, 0:0, -1:0) 18:27:36 #topic Open Floor 18:27:46 Ok, anything else? 18:28:37 * tomspur thought, that it is forbidden to build several versions of a package out of one spec file, but couldn't find it. 18:28:54 Does maybe someone know if that is forbidden and where it is written? 18:29:18 subpackages are allowed and used a lot … so you mean like N different versions of the main package? 18:29:26 i.e.: the package with a correct version and a compat package within the same package 18:29:26 Yeah, sorry, +1 on 471. Attention span of a goldfish. . . . 18:29:32 geppetto, yes 18:29:35 I'm not even sure that's possible … without calling rpmbuild N times. 18:30:11 You have an example? 18:30:15 It is, but I don't like to blame the package at hand right now ... :/ 18:31:18 http://pkgs.fedoraproject.org/cgit/activemq-cpp.git/tree/activemq-cpp.spec?h=el6 :/ 18:32:33 I couldn't find anything that forbids this, but I hope it is... 18:32:35 yeh, those are just subpackages 18:32:49 They have different names etc. 18:33:28 tomspur: I'd allow that, usually the maintainer of the main package is unwilling to maintain additional compat packages so other who want them have to step up and submit a separate package review 18:33:46 So props to this guy willing to support many versions of his package 18:33:52 yeh, plus they might only live for a short time 18:34:17 So don't want to go through a package review for something you'll kill in a few months or whatever 18:34:24 Exactly 18:34:44 hmm, then I could have save also one of mine review requests :( 18:35:11 Now you know the secret ;) 18:35:22 It still doesn't look "right"... 18:35:58 I confess I did the same thing in one of my packages many years ago: http://pkgs.fedoraproject.org/cgit/lpg.git/tree/lpg.spec 18:37:55 tomspur: Yeh, it's not super awesome … it's just often better than the alternatives 18:38:08 Anyone have anything else? 18:38:16 If not I'll close in a couple of minutes 18:40:18 #endmeeting