Kevin Fenzi said the following on 10/26/2010 12:36 PM Pacific Time: We have some Fedora 15 features too. https://fedoraproject.org/wiki/Category:FeatureReadyForFesco John

=================================== #fedora-meeting: FESCO (2010-10-27) =================================== Meeting started by nirik at 18:30:00 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-10-27/fesco.2010-10-... Meeting summary --------------- * init process (nirik, 18:30:01) * Updates policy / Vision implementation status (nirik, 18:36:20) * LINK: https://fedoraproject.org/wiki/Updates_Policy (nirik, 18:46:00) * LINK: https://fedoraproject.org/wiki/User:Kparal/Package_update_approaches (cwickert, 18:46:52) * LINK: https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_policy (cwickert, 18:46:52) * LINK: https://fedoraproject.org/wiki/User:Adamwill/Proposal:Package_update_policy (cwickert, 18:46:52) * LINK: https://fedoraproject.org/wiki/Stable_release_updates_vision_implementati... (cwickert, 18:46:59) * LINK: https://fedoraproject.org/wiki/Package_update_acceptance_criteria (cwickert, 18:46:59) * LINK: https://fedoraproject.org/wiki/Stable_release_updates_vision (cwickert, 18:47:05) * LINK: https://fedoraproject.org/wiki/Package_update_acceptance_criteria#All_oth... is different from https://fedoraproject.org/wiki/Updates_Policy#All_other_updates (cwickert, 18:51:02) * ACTION: cwickert will work on new features repo ideas (nirik, 19:00:51) * ACTION: SMParrish will work on metrics (nirik, 19:00:59) * #416 Set EOL Date For Fedora 12 (nirik, 19:01:03) * AGREED: F12 eol will be 2010-12-02, moving forward eol dates will be the nearest weekday to 1 month from release (nirik, 19:07:33) * Elections coming up. (nirik, 19:08:21) * LINK: http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations (nirik, 19:10:16) * Kudos for F14 release (nirik, 19:10:39) * #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik, 19:15:16) * AGREED: the feature is approved. (nirik, 19:26:46) * Open Floor (nirik, 19:26:50) * LINK: https://fedorahosted.org/rel-eng/ticket/4224 (abadger1999, 19:27:32) * break build inheritance between F14 and F15 and update deltarpm files (nirik, 19:27:56) * AGREED: Fesco is fine with the indicated plan of mass tagging, breaking inherit, and scrubbing old deltarpms for rawhide. (nirik, 19:35:31) * Open Floor (nirik, 19:36:53) Meeting ended at 19:39:44 UTC. Action Items ------------ * cwickert will work on new features repo ideas * SMParrish will work on metrics Action Items, by person ----------------------- * cwickert * cwickert will work on new features repo ideas * SMParrish * SMParrish will work on metrics * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (115) * cwickert (51) * pjones (29) * ajax (24) * abadger1999 (17) * notting (16) * mclasen (14) * mjg59 (14) * zodbot (9) * kylem (9) * SMParrish (6) * wwoods (6) * Southern_Gentlem (3) * adamw (1) * rbergeron (1) -- 18:30:00 <nirik> #startmeeting FESCO (2010-10-27) 18:30:00 <zodbot> Meeting started Wed Oct 27 18:30:00 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:30:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:30:01 <nirik> #meetingname fesco 18:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 18:30:01 <nirik> #topic init process 18:30:01 <zodbot> The meeting name has been set to 'fesco' 18:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 18:30:37 <pjones> yo. 18:30:39 <nirik> who all is around for meeting? 18:32:04 <pjones> just me and you I guess. 18:32:06 * notting is here 18:32:06 * nirik wonders if we have quorum today. 18:32:08 <pjones> ;) 18:32:10 <kylem> yo. 18:32:31 <pjones> mjg59 was around a few minutes ago. 18:34:11 * nirik waits a few to see if we get one more person for quorum 18:35:28 <mjg59> pjones: Hi 18:35:35 <mjg59> Sorry, briefly distracted 18:35:50 <nirik> cool. I think we can go ahead and get started. 18:36:01 <cwickert> am I late? 18:36:06 <nirik> cwickert: nope, just in time. ;) 18:36:09 <cwickert> ;) 18:36:13 <mjg59> cwickert: Fashionably so 18:36:20 <nirik> #topic Updates policy / Vision implementation status 18:36:20 <nirik> .fesco 351 18:36:20 <nirik> .fesco 382 18:36:22 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 18:36:26 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 18:36:31 <nirik> SMParrish was going to look at more stats stuff. 18:36:38 <nirik> Also, I talked with lmacken about bodhi stats. 18:37:08 <nirik> He was going to generate them for us so we could see what was in them, and also try and do a 'pre release' 'post release' split for f14 18:37:32 <nirik> the next bodhi version will allow (I think) running them from cron/regularly. 18:38:21 <nirik> It seems like we are not making much progress to finishing this up. Anyone have ideas on how we could finish things before next elections? 18:38:32 * SMParrish sorry I'm late. 18:39:01 <SMParrish> nirik: was travelling last week. just got home yesterday and have not had time to work on the metrics issue 18:39:14 <nirik> ok. 18:39:18 <cwickert> I think we still suffer from unclear board statements 18:39:33 <pjones> cwickert: I think we're always going to suffer from that 18:39:52 <pjones> we should just interpret them as best we can and if that's really something they didn't want then we do it again :/ 18:39:55 <cwickert> I was talking to some board members and they were not happy with the "only security and bugfixes" thing ether 18:40:42 <notting> and...? internal board politics are a matter for the board. 18:41:19 <mjg59> The board's statement explicitly says " Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues. " 18:41:22 <nirik> I'd really like to see us try the current policy for a bit. It may be too conservative, but we can adjust it if so down the road. 18:41:42 <nirik> we also were going to look into a 'new features' repo. 18:42:46 <nirik> perhaps we could set action items and people on the remaining tasks? 18:42:58 <nirik> SMParrish: work with lmacken on metrics ? 18:43:08 <cwickert> speaking of that, I was supposed to write a propsal on the new-features repo 18:43:19 <nirik> cwickert: yeah. 18:43:24 <kylem> i think this is mostly just a reflection fo the project as a whole, looking at #fedora-dveel you'd be hard pressed to find unilateral agreement on the interpretation of our vision. 18:43:58 <SMParrish> nirik: yes i will get with lmacken on the metrics issue 18:44:02 <pjones> nirik: yeah, I'm with you in that we need more observation to see what we've done. 18:44:03 <cwickert> i have two problems: it is hard to find the status quo as there are a lot of outdated update-something pages in the wiki now 18:44:25 <nirik> we should nuke or redirect the old ones to the current one. 18:44:30 <pjones> yep 18:44:40 <cwickert> the second problem is: two weeks ago a lot of questions were raised in the meeting 18:44:48 <cwickert> but they have not made it into the wiki 18:45:13 <nirik> questions on the new feature repo? or ? 18:45:19 <cwickert> ys 18:45:21 <cwickert> yes 18:45:33 <cwickert> how things work in bodhi and all that 18:45:46 <cwickert> but they are not on https://fedoraproject.org/wiki/Talk:Stable_release_updates_vision_impleme... 18:46:00 <cwickert> I guess I'll have to dig in the meeting logs 18:46:00 <nirik> https://fedoraproject.org/wiki/Updates_Policy 18:46:25 <nirik> that should be the page maintainers look at/follow. 18:46:51 <cwickert> there is a few more 18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Kparal/Package_update_approaches 18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_policy 18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Adamwill/Proposal:Package_update_policy 18:46:59 <cwickert> https://fedoraproject.org/wiki/Stable_release_updates_vision_implementati... 18:46:59 <cwickert> https://fedoraproject.org/wiki/Package_update_acceptance_criteria 18:47:05 <cwickert> https://fedoraproject.org/wiki/Stable_release_updates_vision 18:47:15 <nirik> the last one is the vision from the board. 18:47:34 <notting> anything in the User: namespace should obviously not be policy 18:47:37 <pjones> seems like we should make a category template for the various User: Proposal: ones and tag them so it says something at the top of the page or something. 18:47:37 <nirik> the rest should be removed probibly. (Although we do still have things to implement from the implementation_ideas page) 18:47:52 <pjones> (not that I've got any idea how to do that on the wiki) 18:48:21 <cwickert> the problem is there are conflictins statements 18:48:22 <abadger1999> pjones: Could just use {{draft}} 18:48:35 <pjones> nirik: I'm not sure I'm okay with us deciding to remove stuff under User: (unless it violates various codes of behavior of course) 18:48:38 <pjones> abadger1999: yeah 18:48:48 <abadger1999> pjones: Although you might want something that also says "rejected" or "alternative was implemented" 18:48:51 <pjones> abadger1999: I was thinking something a little stronger than that, but that's certainly the right idea. 18:48:52 <nirik> pjones: true. Althought we could add a 'note: this is NOT policy' or something. 18:49:22 <cwickert> e.g. the last paragraph of https://fedoraproject.org/wiki/Package_update_acceptance_criteria is not exactly what https://fedoraproject.org/wiki/Updates_Policy says 18:49:37 <pjones> nirik: yeah, something like {draft} but maybe a little more "don't use this as reference" since lots of people are used to reading draft documents as the canonical source for data ;) 18:50:03 <nirik> cwickert: about exceptions? 18:50:15 <cwickert> nirik, about criteria 18:50:33 * nirik is not following. 18:50:56 <nirik> The critical path / other updates sections? 18:51:02 <cwickert> https://fedoraproject.org/wiki/Package_update_acceptance_criteria#All_oth... is different from https://fedoraproject.org/wiki/Updates_Policy#All_other_updates 18:51:12 <cwickert> at least slightly 18:51:47 <cwickert> the information should be one one single page to make sure we have no contradictions and no redundancy 18:51:48 <nirik> well, I thought I copied it from the one page to the new one. 18:52:12 <nirik> yes, I copied Package_update_acceptance_criteria data into Updates_Policy 18:52:17 <nirik> where I messed up we should fix it. 18:52:38 <cwickert> ok, what else is left to do except a clean-up? 18:53:10 <cwickert> i guess https://fedoraproject.org/wiki/Stable_release_updates_vision_implementati... 18:53:21 <nirik> if you see issues that are obviously me messing up the copy, just fix them. If it's something that should be changed, bring it up here and we can vote on it. 18:53:28 <nirik> right, we need: 18:53:31 <cwickert> i hope I can come up with a proposal for the next meeting, I'm just too busy in my dayjob 18:53:33 <nirik> metrics: how well is this working 18:53:44 <nirik> new feature repo: if it's fesable 18:53:47 <cwickert> what kind of metrics would that be? 18:54:26 <cwickert> i mean, how to judge if something is working? can we count how many people are cheating in bodhi? 18:54:37 <nirik> anything we could gather that would apply to: "Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements" 18:55:23 <nirik> we can count numbers of updates, numbers of bodhi comments/tests, number of karma submitters, number of bugs, etc. 18:55:49 <cwickert> so? what do we gain when counting the number of comments in bodhi? 18:56:05 <nirik> an increase in testing? 18:56:07 <cwickert> if even rel-eng gives "proxy karma" without testing 18:56:23 * nirik is happy to listen to any other metrics you think we should gather. 18:56:50 <cwickert> I'm sorry, I don't have any 18:57:07 <cwickert> but what I see at https://admin.fedoraproject.org/updates/openbox-3.4.11.2-5.fc14 makes me think we are not doing more testing than before 18:57:17 <wwoods> you're wrong. 18:57:20 <wwoods> provably so. 18:57:21 <cwickert> just an example, I'm sure there are plenty of this 18:57:33 <wwoods> that is an anecdote; the data say otherwise. 18:57:35 <nirik> the plural of anecdote is not data. 18:57:52 <nirik> anyhow, lets see what SMParrish comes up with and go from there? 18:58:05 <cwickert> wwoods, if two out of three testers are faking results, what have we gained? 18:58:17 <mjg59> One tester 18:58:25 <wwoods> furthermore, if that were actually correct - what would be the correct solution? Do *less* testing? 18:58:28 <cwickert> well... 18:58:34 * nirik notes we are over 15min on this topic. 18:59:11 <cwickert> wwoods, not have technical limitations that make people abuse the guidelines. 18:59:29 <wwoods> finding problems with a process should probably cause you to look for ways to improve the process 18:59:32 <cwickert> anyway, I'm happy for all numbers we can gather, but I doubt they are meaningful 19:00:00 <nirik> ok, anything further on updates? or shall we move on? 19:00:01 <wwoods> so - constructive suggestions on that topic would be excellent! probably not here and now, though. 19:00:09 <cwickert> +1 19:00:51 <nirik> #action cwickert will work on new features repo ideas 19:00:59 <nirik> #action SMParrish will work on metrics 19:01:03 <nirik> #topic #416 Set EOL Date For Fedora 12 19:01:03 <nirik> .fesco 416 19:01:08 <zodbot> nirik: #416 (Set EOL Date For Fedora 12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/416 19:01:11 <cwickert> can we also have somebody to clean up the wiki? 19:01:15 <nirik> Since F14 was pushed out a week, should we move EOL for F12 as well? 19:01:27 <nirik> cwickert: I can try, but I also have been very busy. 19:01:38 <pjones> nirik: yeah, we should keep them in lock-step I guess. 19:01:45 <cwickert> +1 19:02:12 <ajax> sure, why not 19:02:14 <mjg59> nirik: +1 19:02:29 <nirik> ok, +1 from me too. 19:02:36 <Southern_Gentlem> suggest 12/1/2010 19:02:44 <nirik> Further on this topic, instead of us voting on it, do we want to just setup a general rule? 19:02:50 <pjones> nirik: yes 19:02:57 <nirik> ie, nearest weekday to 1 month from release. 19:03:00 <notting> ACK 19:03:04 <pjones> +1 19:03:07 <mjg59> +1 19:03:12 * mclasen is all for auto-EOL 19:03:13 <mclasen> +1 19:03:17 <ajax> +1 19:03:25 <nirik> that would make it 2010-12-02 for this case tho (2010-12-03 was suggested) 19:03:58 * notting is +1 to lockstep, +1 to auto-lockstep 19:04:20 <pjones> nirik: nearest to or first after? 19:04:31 <kylem> +1. 19:04:32 <nirik> pjones: we could do that I suppose. 19:04:41 <pjones> not that I really care. 19:04:41 * nirik doesn't feel too strongly either way. 19:05:22 <nirik> anyone object to 'nearest weekday 1 month from release +1 day' ? 19:05:37 <ajax> fine with me 19:05:50 <cwickert> same here 19:05:56 <Southern_Gentlem> why the +1 day? 19:06:11 <kylem> latency. 19:06:12 <kylem> :P 19:06:24 <nirik> I guess that just makes it more complex. 19:06:42 <nirik> so, lets just do nearest weekday to 1 month after release. 19:07:07 <pjones> I'm thinking "first weekday after" just because that means we prefer mondays to fridays. 19:07:18 <pjones> (well, on or after. gah.) 19:07:27 <ajax> also fine with me. 19:07:33 <nirik> #agreed F12 eol will be 2010-12-02, moving forward eol dates will be the nearest weekday to 1 month from release 19:07:42 <nirik> pjones: I don't know that it matters... 19:07:59 <pjones> fair enough. 19:08:19 <nirik> Some topics that are just announcements/notices: 19:08:21 <nirik> #topic Elections coming up. 19:08:31 <nirik> elections are starting up for board, fesco, famsco 19:09:18 <nirik> Everyone should vote. ;) 19:09:25 <kylem> lol 19:09:27 <pjones> +1 19:09:31 <ajax> early and often. 19:09:33 * nirik looks to see who is up from fesco... 19:09:44 <notting> ajax, cwickert, pjones, mjg59 19:09:45 <mjg59> Me, ajax, pjones, cwickert? 19:09:47 <mjg59> Yeah 19:09:52 <rbergeron> ...or nominate themselves for open positions :) 19:09:57 <nirik> Adam Jackson (ajax), Christoph Wickert (cwickert), Peter Jones (pjones), and Matthew Garrett (mjg59) 19:10:10 * nirik thanks notting for updating the page. 19:10:16 <nirik> http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations 19:10:32 <nirik> moving on... 19:10:39 <cwickert> I haven't seen an announcement on devel list 19:10:39 <nirik> #topic Kudos for F14 release 19:10:42 * Southern_Gentlem crosses fingers that they all reapply for the job 19:10:58 <nirik> cwickert: yeah, not sure who is coordinating this time. ;( will find out tho. 19:11:11 <notting> nirik: i think everyone's coordinating their own? 19:11:24 <notting> do we want to designate someone to post to the devel list? 19:11:31 <nirik> I'd like to thank all the maintainers, qa folks, users and rel-eng for making F14 such a smooth release. :) 19:11:37 <cwickert> +1 19:11:39 <nirik> notting: oh, usually there's a coordinator. 19:11:51 <cwickert> especially for QA, adamw does a great job 19:12:10 <nirik> seconded. ;) 19:12:27 * adamw would like to thank all the people who did all the work 19:12:57 <nirik> I can find out if there is a coordinator this time, and if not, at least mail the devel-announce list about nominations being open. 19:13:14 <SMParrish> +1 kudos to all 19:13:20 <notting> nirik: wfm 19:13:22 <cwickert> nirik, there was something in the board list about coordination 19:13:24 <notting> nirik: thanks! 19:13:53 <nirik> ok, I had one f15 feature that I didn't note in time for the agenda. We could do it now, or wait until next week? 19:14:51 <cwickert> how about now? 19:14:54 <mjg59> Sure 19:14:55 <abadger1999> pjones, cwickert: Re: a template like {{draft}} I just made this for ya'll: https://fedoraproject.org/wiki/Template:Draft/declined Go ahead and change it if you want something slightly different. 19:15:12 <nirik> abadger1999: thanks! 19:15:15 * abadger1999 sorry for jumping in with that but has to leave soon 19:15:16 <nirik> #topic #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID ) 19:15:16 <nirik> .fesco 480 19:15:17 <zodbot> nirik: #480 (F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/480 19:15:36 <pjones> abadger1999: excellent. 19:15:57 * cwickert looks 19:16:15 <nirik> I'm +1 on this. I don't know how hard it's going to be, but if anyone can get it to happen dwalsh can. ;) 19:16:39 <ajax> i'm only barely +1 to this since i still think capabilities are far too coarse-grained to be of much use 19:16:46 <mjg59> I'm also +1, though concerned about the degree to which things may end up breaking 19:17:01 <pjones> I'm +0 to this for the sam reason ajax is barely +1 to it. 19:17:02 <mjg59> I can't see it /reducing/ security, but I don't think it's as big a win as it could be 19:17:22 <ajax> but f15's xserver is already shipping non-setuid, so, whatever. 19:17:50 <notting> ajax: sys_admin or raw_io? 19:18:01 <ajax> notting: both those and also dac_override 19:18:07 <mclasen> is the dependency list on the tracker bug complete ? 19:18:11 <mclasen> 24 sounds low... 19:18:29 <nirik> it does seem low yeah. 19:19:14 <notting> ajax: that doesn't remove much. if anything. 19:19:17 <ajax> notting: if that sounds like zero effective reduction in privileges, that's because it's no effective reduction in privs. 19:19:22 <ajax> so, like i said. 19:19:38 <ajax> hey cool we can use capabilities! if only that were meaningful! 19:19:50 <mclasen> would be good if the feature page had some advice on how to find out the 'correct caps' to use 19:19:56 <notting> i'm moderately for the idea, but it remains to see if we'll come up with anything useful 19:20:17 <ajax> xserver might be a special case, but really anything that needs dac_override or sys_admin is trivially equivalent to root 19:20:27 <pjones> mclasen: the problem is that the capabilities are so poorly thought out that that's a non-trivial (and possibly non-meaningful) exercise. 19:20:41 <mclasen> and one that breaks at runtime if you get it wrong ? 19:20:48 <ajax> mclasen: indeed. 19:20:49 <pjones> yep. 19:21:41 <ajax> i would say i get the feeling the caps were designed by someone who had never tried to root a machine, but that would imply that i thought they were designed period. 19:21:54 <mclasen> so we need individual testing attention for each binary that gets that treatment, I guess 19:22:42 <ajax> yeah. again, if dan wants to drive that, great. 19:22:58 <notting> ajax: 'designed by someone who only wanted to remove setuid from ping, other things are an afterthought'? 19:23:34 <ajax> notting: that's a bit closer, yeah. 19:24:27 <ajax> anyway. +1 to the feature even though it's of the most marginal utility. 19:25:04 <nirik> so where are we here... 19:25:11 <nirik> +3 I see 19:25:19 <cwickert> +1, see what it brings 19:25:31 <SMParrish> +1 19:26:13 <pjones> I guess I could be +1 despite limited utility. It's not a bad thing to do per se. 19:26:46 <nirik> #agreed the feature is approved. 19:26:50 <nirik> #topic Open Floor 19:26:55 <nirik> Anything for open floor? 19:26:57 * mclasen adds comments to the feature page and gives a +1 19:27:00 <ajax> hah! the bugs even cite Xorg as the example. 19:27:09 * ajax ahead of the curve 19:27:32 <abadger1999> https://fedorahosted.org/rel-eng/ticket/4224 19:27:39 <nirik> ah yes, 19:27:56 <nirik> #topic break build inheritance between F14 and F15 and update deltarpm files 19:28:07 <nirik> .rel-eng 4224 19:28:09 <zodbot> nirik: Ticket #4230 (task created): build tag override request for eclipse-3.6.1-2.fc14 || Ticket #4229 (task closed): Retire OpenOffice.org from F15 || Ticket #4229 (task created): Retire OpenOffice.org from F15 || Ticket #4228 (task created): Buildroot override request for libtorrent || Ticket #4227 (task created): tag request: dist-f14-override for libgda-4.2.0-1.fc14 || Ticket #4226 (defect closed): (11 more messages) 19:28:15 <abadger1999> Oxf13: You around for this? 19:28:16 <nirik> oops. thats not right. ;) 19:28:34 <ajax> eesh, this looks vile. 19:29:15 <nirik> yes, yes it does. 19:29:36 <abadger1999> This comment is probably the best summary of the problem: https://fedorahosted.org/rel-eng/ticket/4224#comment:6 19:29:51 <abadger1999> The initial report has the proposed solution. 19:30:31 <nirik> given that it falls back to the full rpm ok and that deltas are only somewhat usefull in rawhide anyhow... 19:30:32 <abadger1999> I think Oxf13 would like fesco input because we normally don't break build inheritance by itself... although we do in practice if we do a mass rebuild 9but once again, that would normally be later in the cycle) 19:30:42 <nirik> this is just f15 right? 19:30:48 <abadger1999> Correct. 19:30:55 * nirik whews 19:31:11 <abadger1999> It won't affect f14 as jnovy isn't going to push the new xz back. 19:31:19 <nirik> thank goodness. 19:31:32 <mclasen> whats the consequence of broken build inheritance ? people have to build their stuff for rawhide ? 19:31:40 <mclasen> doesn't sound too onerous to me 19:31:55 <ajax> mclasen: yeah, f14 builds won't automatically bubble to f15. 19:31:56 <abadger1999> mclasen: Correct. A build for F14 won't automatically go to F15. 19:32:11 <nirik> if we nuke existing deltas does that mean we would need a compose to rebuild them all? (ie, a long ass one) 19:32:35 <abadger1999> nirik: No, the idea is that we'll only have deltas for packages built after that time. 19:32:41 <nirik> ok, good. 19:32:45 <notting> rawhide deltas are just against the prior tree 19:32:55 <abadger1999> nirik: The reason is that the final package on the user's system will have been built with the xz on the user's system. 19:33:07 <nirik> I'm fine with the plan then... tag, break inhert, nuke deltas, move on. 19:33:09 <abadger1999> nirik: And when the update package was old, that's what's causing the breakage. 19:34:02 <pjones> yeah, I'm fine with this plan. 19:34:14 <ajax> works for me 19:34:22 <SMParrish> based on that I'm good with it 19:34:40 <nirik> that's +4 I think. 19:34:43 <mclasen> +1 19:35:01 <kylem> hrm. 19:35:04 <mjg59> +1, I think 19:35:05 <kylem> +1. 19:35:12 <mjg59> I can't see anything obviouly better 19:35:16 <kylem> i'd like t think about it more though. 19:35:31 <nirik> #agreed Fesco is fine with the indicated plan of mass tagging, breaking inherit, and scrubbing old deltarpms for rawhide. 19:35:34 <ajax> well, besides turning off deltas 19:35:52 <nirik> well, deltas are not usually that usefull in rawhide, unless you make sure to update every single day. 19:36:27 <nirik> and even then, if you had an day out of date mirror, etc. 19:36:40 <abadger1999> Cool. 19:36:48 * abadger1999 has to vamoose now. 19:36:52 <ajax> yeah, i really don't see much benefit in drpms for rawhide 19:36:53 <nirik> #topic Open Floor 19:37:05 <nirik> any further open floor items? or shall we wrap up? 19:37:06 <mclasen> do we have a date for that event ? 19:37:33 <nirik> mclasen: I guess when rel-eng is ready... it should be announced, etc. 19:37:46 <mclasen> sure, sounds fine 19:37:54 * mclasen was just making sure its not happening tomorrow 19:38:40 <nirik> I think the new xz has landed, but the only harm right now is that deltarpms don't work. 19:39:10 * nirik will close out the meeting in a few here if nothing comes up. 19:39:13 <notting> right, and since they fallback, i wasn't thinking it was OMG critical 19:39:34 <nirik> yeah. 19:39:39 <nirik> ok, thanks for coming everyone! 19:39:44 <nirik> #endmeeting

On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote: Probably: remove setuid bit, run, see what breaks. strace may be useful [pp@the ~]$ strace ./rsh localhost 2>&1|grep EACCES bind(3, {sa_family=AF_INET6, sin6_port=htons(1023), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EACCES (Permission denied) -> needs CAP_NET_BIND_SERVICE. It didn't seem to output any error to the user, so the lacking permissions may be well-hidden. https://wiki.archlinux.org/index.php/Using_File_Capabilities_Instead_Of_S... seems to have a list btw., which may or may not be correct. Do note that removing suid from some programs is a bad idea: "Warning: Do not use it, because mount and umount can not do some checks, then users can mount/umount filesystems that do not have permission." (probably those checks could/should be implemented upstream, if they're not already there) So it's a feature that could introduce new vulnerabilities if done wrong, but it's certainly worth doing, carefully. If uncertain, ask.

On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: JN> getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. - J<

On Thu, Oct 28, 2010 at 11:08:00PM +0100, Richard W.M. Jones wrote: You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. See also http://people.redhat.com/sgrubb/libcap-ng/index.html Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote: In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc is even tricker than with SELinux -Z because of the length of capabilities to display. eg, pscap for dhclient which has just 5 capabilities is showing 'dac_override, net_bind_service, net_admin, net_raw, sys_admin' There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to < 5 characters each, but it isn't going to be so readable, nor very short for lots of caps Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Fri, Oct 29, 2010 at 04:55:44PM +0530, Rahul Sundaram wrote: You only have 3 letters to remember the name of and you encounter them on a daily basis, so its easily rememberable. Give every capability even a 5 letter long code and few will ever be able to remember what they mean. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote: I don't think you need to display them, just display something that says "this is more than it seems" ... like ACLs. Something as simple as "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/2010 08:32 AM, James Antill wrote: https://bugzilla.redhat.com/show_bug.cgi?id=647786

On Fri, Oct 29, 2010 at 12:41:07PM +0100, Daniel P. Berrange wrote: Perhaps we can use obscure unicode glyphs. :) -- Matthew Miller <mattdm(a)mattdm.org&gt; Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences

On Fri, Oct 29, 2010 at 06:16:32PM +0200, Andreas Schwab wrote: I think that's something we can live with. Colorizing is already significant overhead, and if performance is important, don't do it: /usr$ time ls --color=yes -R > /dev/null real 0m23.871s user 0m1.315s sys 0m22.513s /usr$ time ls --color=no -R > /dev/null real 0m3.707s user 0m0.636s sys 0m3.060s (Actually average of three runs, after discarding one.) -- Matthew Miller <mattdm(a)mattdm.org&gt; Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences

On Fri, Oct 29, 2010 at 07:00:54PM +0200, Patrick MONNERAT wrote: It absolutely cannot be the only indication. I did not mean to suggest that. However, it is a very valuable indicator for those able to take advantage of it. -- Matthew Miller <mattdm(a)mattdm.org&gt; Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences

On 29/10/10 04:15, Jason L Tibbitts III wrote: I've just come across another issue with this. I use the "tmpfs" plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot: DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance. Paul.

On Mon, 01 Nov 2010 11:04:09 -0400 Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote: The tmpfs is set up by mock and I can't see anywhere in the mock code that it sets nosuid. I can't tell from outside mock what options it's using as it also uses a namespace. If I just run "mount" from within a package build I don't get any output. Any suggestions? Paul.

Yeah, it looks like the capabilities thing has broken my buildsystem: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported I don't use the mock tmpfs plugin; I just have a big tmpfs mounted on /mock that everything is built in. tmpfs /mock tmpfs rw,rootcontext=unconfined_u:object_r:default_t:s0,seclabel,relatime,size=10485760k,nr_inodes=1048576,mode=2775,gid=219 0 0 I'm thinking that tmpfs simply doesn't support capabilities, which would be... unfortunate. - J<

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2010 04:31 PM, Jason L Tibbitts III wrote: Opened a bug on this. https://bugzilla.redhat.com/show_bug.cgi?id=648653

On Thu, Oct 28, 2010 at 11:14:08AM +0300, Pekka Pietikainen wrote: Don't do that. You have to *always* read the application source code to verify that the change is safe. You have to verify all relevant shared libraries too. That's completely wrong and dangerous point of view... Karel -- Karel Zak <kzak(a)redhat.com&gt; http://karelzak.blogspot.com

Pardon the thread necromancy, So recently I had cause to look at http://fedoraproject.org/wiki/Features/RemoveSETUID again (I was investigating the X server permissions for an unrelated reason). Now, that page links to http://people.redhat.com/sgrubb/libcap-ng/index.html which attempts to explain the value of capabilities, etc. I was following along on all of this, and I understand that capabilities have some (non-negligible) value if you don't have e.g. cap_sys_admin. But then I got to the point where it says: "But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root?" So...right, "we can do these small changes, and then if we do this BIG CHANGE, it all works!". But this feature doesn't include BIG CHANGE, and there are no plans to, right? Or is chmod u-rwx g-rwx on the root filesystem really in the cards? Now, https://fedoraproject.org/wiki/Features/LowerProcessCapabilities appears to claim 100% completion on this for Fedora 12, but none (?) of it happened?

On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote: I understand the goal of getting fewer capabilities (however, I think switching setuid to cap_sys_admin is at best pointless, at worst an obfuscation). But you didn't answer my question - does the scope of this plan include a Unix mode 005 /bin, etc. or not?

Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500: No. The original plans didn't count with the fact that changing permissions by owner does not require any capabilities either. If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless. Mirek

On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav Trmač wrote devel: Ok, so who says that the files must be owned by root? Make them owned by some other user -- say, bin? (or does that have another use that my google search isn't coming up with?)

2010/12/21 Miloslav Trmač: You don't even need to change permissions for root to be able to delete or change the contents of the directory. Dick

tis 2010-12-21 klockan 11:47 -0500 skrev Colin Walters: Eh? A process given capabilities via file capablities do not need to run with uid 0. It can run as the calling user (no setuid bit), and is what RemoveSETUID is about. For things started as root, a capabilities aware system service started as root can drop to a non-root user while keeping the capabilities it needs. But this is not using file capabilities. But practicaly nothing accessed bu users should be running as root. Regards Henrik

ons 2010-12-22 klockan 00:59 +0100 skrev Miloslav Trmač: Imho in that specific case it should be protected by two group acls. One group for writing/modifying, another for reading. No need for capabilities at all, just setgroupid and file acls. shadow have no special significance to kernel functions. Regards Henrik