| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod | |
|---|---|---|
| Hi everybody; who's around? | ||
| * notting is here. this is going to be a fun one | ||
| nirik is here. | ||
| dwmw2 | fish | |
| warren | I just posted an updated New Key plan to rel-eng and fesco lists. It handles both auto-migration and auto-revoke. Please review! | |
| j-rod | wasabi | |
| warren | I don't mean to hijack this meeting, but I am asking for the following from FESCO. | |
| * jds2001 here | ||
| warren | FESCO, please voice concerns about anything you see in v2 of the New Key plan. But vote to grant rel-eng autonomy to just do the RIGHT THING so we can get updates out quick without more back and forth. (We shouldn't need more votes later to unstuck us.) | |
| bpepple | warren: before we get to that, could we do two quick topics since the keys & schedule topics will probably take awhile to discuss. | |
| j-rod | bpepple: Kick__ is out for today, if you didn't already catch his email | |
| warren | bpepple: if this above request is followed, it wouldn't be time consuming. | |
| notting | bpepple: schedule before keys, at least. simpler that way | |
| bpepple | j-rod: yeah, I caught it. | |
| warren | bpepple: I would be happy to answer any questions when the time comes. | |
| * warren waits. | ||
| bpepple | notting: agreed. | |
| warren: I'm hoping the first couple of topics won't take more than 10 minutes. | ||
| --- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01206.html | ||
| warren | ok | |
| bpepple | anyone have any objections to the FPC proposals? | |
| * dgilmore is here | ||
| dgilmore | warren: wait your tuen | |
| turn | ||
| * bpepple note Kick gave +1 to them on the mailing list. | ||
| nirik | +1 from me, they seem fine, as does the new guideline. | |
| notting | seems ok, +1 | |
| dgilmore | http://fedoraproject.org/wikiPackagingDrafts/Haskell gives a 404 | |
| j-rod | worksforme, +1 | |
| * dwmw2 looking for multilib fun | ||
| j-rod | dgilmore: malformed url | |
| nirik | dgilmore: missing a / there | |
| j-rod | put a / after wiki and before Packaging | |
| jds2001 | +1 | |
| bpepple | ok, I don't hear any objections, so we can probably move on.... | |
| dgilmore | j-rod, nirik: thats the url that FPC posted | |
| bpepple | we pushed bumped one feature last week, and I'd like to get a quick vote on it before going to the F10 schedule. | |
| --- bpepple has changed the topic to: FESCo-Meeting -- Features -- https://fedoraproject.org/wiki/Features/OnlineAccountsService | ||
| j-rod | dgilmore: yep, they screwed up. :) | |
| notting | what's changed? | |
| * dgilmore has concerns about user security with this feature | ||
| nirik | didn't we have some questions about this one? I don't see anything on discussion page tho. | |
| jds2001 | is the data actually stored on online.gnome.org? | |
| bpepple | notting: I'm not sure anything changed. I didn't see any questions for the feature owner on the discussion page. | |
| warren | passwords stored in gnome-keyring it says | |
| jds2001 | i thought it was on the local keyring | |
| j-rod | seemed to me like there was plenty of data also stored on online.gnome.org, if you opted to let it be | |
| dgilmore | jds2001: yes but it exposes dbus in new ways. and there has to be something remotely that they auth against | |
| nirik | also, is this a real visible feature with only the online desktop sidebar using it, and for only 2 sites? | |
| jds2001 | nirik: i think it can be built upon | |
| nirik | yeah, also I guess it's gnome specific... | |
| bpepple | jds2001: yeah, I believe their plan is to expand upon it. | |
| j-rod | sure it can be built upon, but maybe it needs a bit more building upon before its really something to holler about? | |
| i.e., please come back when there's a bit more to it | ||
| nirik | yeah, thats what I was getting at... with a bunch more apps and such, it could be a nice f11 feature... | |
| bpepple | j-rod: yeah, I'm inclined to think the same thing. | |
| jds2001 | is the feature owner around to comment? | |
| bpepple | jds2001: I don't think so. I haven't seen Marina on irc. | |
| * jds2001 inclined to go with j-rod in that case, but it's not entirely clear to me that this only applies to the online desktop sidebar | ||
| bpepple | jds2001: they plan on integrating this into other applications as well like empathy & twitux. | |
| jds2001 | (it's also not clear that isn't the case) | |
| ok, plans != testable feature :( | ||
| warren | I'm told that marina is online gimpnet | |
| otaylor | jds2001: we have twittux patches working right now | |
| nirik | I can ask them to come here... ? I am over there... | |
| otaylor | jds2001: have to get them by bpepple first, of course :-) | |
| bpepple | otaylor: shouldn't be a problem. ;) | |
| otaylor | nirik: I've already asked marina ... not sure if she's at her computer right now. I'm pretty familiar with the feature, though | |
| nirik: So, I probably can answer most questions | ||
| nirik | ok. ;) | |
| bpepple | dgilmore: what was your question about security? | |
| nirik | otaylor: so is this ready to be touted as a feature with so few applications/sites supported? or would it be better to wait for f11 and get more apps/sites? | |
| dgilmore | bpepple: how data is transported | |
| dgilmore | whats done to make sure its not picked up over the wire | |
| jds2001 | and *what* data is transported | |
| dgilmore | can a break in on the server comprimise user machines | |
| whats done to prevent that from happening | ||
| jds2001 | or user account data? | |
| otaylor | nirik: well,it's going to be a fairly limited feature initially. | |
| dgilmore: OK, first storing anything on the server is opt-in | ||
| j-rod | for some reason, I was thinking this stored users passwords on online.gnome.org (if they wanted), but now that I re-re-re-read the feature page, the ref to online.gnome.org seems to be solely that its a place the user has an online account, a la gmail.com... | |
| otaylor | dgilmore: Second, what is stored there is just a mapping from you to your accounts ... passwords are currently not stored there at all | |
| j-rod | ...but I knew I heard something that said you could store stuff on the server | |
| otaylor | dgilmore: So, if the server was compromised, what people could learn is the name of your flickr, twittux account, etc. | |
| j-rod: Eventually, the plan is to store your keyring on a server (encrypted, with a client side passphrase not stored on the server). That's not part of the f10 feature | ||
| dgilmore | otaylor: whats done to prevent me using dbus to get back at a user machine? | |
| otaylor | dgilmore: Transport is unencrypted. So, yes, you could sniff it, but if someone is using flickr or twitter, you can get the same information by sniffing the plain text traffic there (and probably hijack their session as well, which is worse than revealing an account name) | |
| j-rod | otaylor: ok, but for f10, we *are* talking about storing the user to online accounts mapping at online.gnome.org? | |
| otaylor | dgilmore: D-Bus usage is completely local within the session and not exposed to the server | |
| walters_ | j-rod: the design is for the system to work without a server as well | |
| otaylor | dgilmore: Communication to the server, if you opt in, is done over XMPP. If you don't opt in, then information is just stored locally in GConf. | |
| In that case, you get consistent storage of your account list across the desktop but not synced to your other computers | ||
| j-rod | walters_: yeah, I got that, just wanting to confirm that there *is* the option for stuff to go there w/in the f10 scope | |
| otaylor | j-rod: Yes, the account list storage on online.gnome.org is there for F10 | |
| * j-rod is slow, needs things explained in small words sometimes... :) | ||
| otaylor | j-rod: What it will look like (if you aren't running the onine desktop), is that the account list dialog will have a checkbox [ ] Store my accounts list online and if you check it you'll have a link to create an account on online.gnome.org or sign in | |
| j-rod | so really, what we're talking about for f10 is expanding gnome-keyring to store online account info in addition to local account info, and store some of those online account mappings on online.gnome.org if you so choose | |
| f13 | am I too late for the meeting? | |
| I just got my internet working. | ||
| walters_ | j-rod: the gnome keyring only stores passwords | |
| bpepple | f13: nope. | |
| jds2001 | f13: no | |
| j-rod | walters_: does it store the online account passwords? | |
| walters_ | j-rod: it's not an account system really | |
| dgilmore | otaylor: so i send malicous packets over xmpp | |
| jds2001 | dgilmore: to what end? | |
| jds2001 | dgilmore: corrupting other people's data? | |
| j-rod | walters_: so the screenie on the feature page... that's a new app? and the password you enter there gets stored in the gnome keyring? | |
| otaylor | dgilmore: If you can fool me into getting the wrong accounts information, then I think the major damage is that I'll be confused, because I'll get prompted to log in to twitter and it will fail. You can't convince me to log in to some other web site... it's just a user name. | |
| walters_ | j-rod: right | |
| j-rod | walters_: ok, I think I finally have things straight in my head. :) | |
| otaylor | dgilmore: You could also change the mapping permanently on the server. | |
| walters_ | j-rod: what gnome-keyring does not do is have a mapping from a semi-standard string like "twitter.com" -> password | |
| dgilmore | otaylor: specifically im thinking that your service will be a high visible target | |
| walters_ | j-rod: so apps have tended to invent their own account schema, and we're trying to standardize it (think of gnome-keyring like a database, and the account system like a schema) | |
| dgilmore | im thinking it could possibly be used to open a backdoor to users boxes | |
| jds2001 | but is mugshot not similarly high-visibility today>? | |
| otaylor | dgilmore: I don't see how, unless our protocol handling code is exploitable. | |
| j-rod | walters_: right, so instead of having to input account info in pidgin (or whatever that new gnome client is), it just ties into this | |
| otaylor | dgilmore: it's not inconceivable, of course, but we're using the standard loudmouth library | |
| walters_ | j-rod: yeah | |
| dgilmore | otaylor: ok | |
| bpepple | ok, are there any more questions, or are we ready to vote on this? | |
| j-rod | ok, now that (I think) I understand this much better, +1 | |
| dgilmore | otaylor: and you have a clear policy to show users what data you do and dont use and whats kept where. | |
| j-rod | heh | |
| bpepple | +1 to online account feature. | |
| jds2001 | +1 here | |
| otaylor | dgilmore: for this service in particular, everything that is kept on line is shown to you on your online accounts page | |
| notting | +1 | |
| dgilmore | otaylor: how does a user know that? | |
| otaylor: you need a very clear easily accesable privacy policy | ||
| nirik | otaylor: the privacy policy link on online.gnome.org redirects to mugshots... | |
| otaylor | dgilmore: there are other services running on the server (like mugshot) that are slightly less transparent ... there we have a privacy policy with detailed information. | |
| nirik | not sure thats not going to confuse people. ;) | |
| anyhow, +1 from me. | ||
| bpepple | ok, I see five '+1' to this feature and zero '-1', so we've approved it. | |
| anything else to add to this before moving on to some fun topics? | ||
| j-rod | hey, I thought this *was* fun... :) | |
| otaylor | nirik: We may need to clean that up in the next month ... getting stuff run through legal is always a pain, so we've been a bit lazy there. | |
| nirik | otaylor: yeah, at least it would need to mention online.gnome.org too... the mugshot one only lists mugshot. | |
| bpepple | j-rod: no, I think the keys topic will be a *lot* more fun. ;) | |
| otaylor | nirik: The privacy policy link on the sign up page ... the big prominent one you are going to go to if you are worried "what are they going to do with my info" | |
| Says "See GNOME Online and Mugshot Privacy Policy" | ||
| j-rod | otaylor/walters_: fwiw, I think the feature page could use a bit more clarification as to what is actually being delivered, it wasn't until this discussion here I that I felt I actually had a clue what was being proposed | |
| otaylor | nirik: but that's a bit of a "hack" to make people less confuesd without having to revise the privacy policy | |
| dgilmore | -1 from me | |
| walters_ | j-rod: makes sense, will do | |
| nirik | otaylor: sure, but they will get confused the way it is now. ;) Just thought I would mention it as something that must be fixed by f10 release... might note it in the wiki feature page too. | |
| bpepple | ok, so thats five '+1', and one '-1' to this feature. | |
| otaylor | nirik: I'll make sure we improve the situation before f10 release | |
| j-rod | bpepple: keys topic... certainly could be more "fun" for some definition of... :) | |
| bpepple | otaylor, walters_: thanks, for taking the time to answer our questions. | |
| ok, we should probably move on. | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- F10 Schedule - all | ||
| otaylor | bpepple: Your welcome. Thanks to all of you for reviewing the feature. | |
| bpepple | otaylor: np. | |
| f13 | oh hey, the schedule change. | |
| notting | http://poelstra.fedorapeople.org/schedules/f-10/f-10-three-week-change.html is the proposed new schedule | |
| * f13 actually wonders if this re-signing stuff is going to interfere with schedule changes. | ||
| f13 | I hope not. | |
| wwoods | what could possibly go wrong? | |
| f13 | *cough* | |
| nirik | +1 to the new schedule. | |
| bpepple | as is we don't have much wiggle room with the new schedule. We getting close to the holiday season. | |
| jds2001 | f13: I assume that's because there's only one of you? | |
| f13 | right | |
| jds2001: no, more like there is only one of koji | ||
| f13 | although. | |
| I don't see why we couldn't do 2 sign guests for a short period of time to make things go faster. | ||
| dgilmore | f13: we can bring up another hub for doing releng stuff on | |
| f13 | not sure if that will help too much | |
| but interesting thought | ||
| notting | f13: is the # of guests really the bottleneck vs. bw to/from the data | |
| f13 | notting: well, if we have one guest working through say dist-f10, while another guest works through dist-f9(-updates(-testing)) we'll get done faster | |
| especially if those guests are on different xen servers | ||
| bpepple | f13: do you think it's realistic for us to get the beta out on sept. 9th? | |
| f13 | anyway, was there any objections to the schedule change? | |
| j-rod | +1, worksforme | |
| f13 | bpepple: I think it is, unless things go horribly wrong in the next week | |
| jds2001 | +1 | |
| bpepple | +1 to schedule change. | |
| notting | +1 | |
| dgilmore | +1 to schedule change | |
| bpepple | ok, that six '+1', so we've approved the schedule change. | |
| ok, onto the key problem.... | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- Signing and pushing a new key | ||
| poelcat | bpepple: 2008-09-09 is the freeze not public availability | |
| nirik | there's no good answers here, but I say +1 to the last plan warren sent out... | |
| warren | yes, all possible options suck | |
| f13 | what's the link to the last plan? | |
| * drago01 likes the "users don't have to do it by hand" part | ||
| warren | http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001622.html | |
| abadger1999 | warren: How do you get away with not touching the iso? | |
| f13 | just want to make sure it's the same thing I was reading yesterday. | |
| bpepple | poelcat: your right. I was looking at the wrong date. | |
| notting | f13: no, it's different | |
| f13 | hrm. | |
| warren | abadger1999: not touching the ISO is a different decision | |
| abadger1999: if people want to go through the pain of redoing the ISO they can decide that separately | ||
| notting | abadger1999: isos are individually verifiable, and it's not like we can get rid of burned & pressed CDs in the wild | |
| abadger1999 | notting: right... but if we're getting rid of the old repository, the iso is no longer update capable. | |
| skvidal | does #3 work if they've touched any .repo file? | |
| or if any application has touched it for them? | ||
| * skvidal thought .repo files were config(noreplace) | ||
| wwoods | it still adds the new updates repo, as long as it has a new name | |
| jds2001 | and what about space on the mirrors? | |
| warren | abadger1999: no | |
| drago01 | abadger1999: what about a redirect from old>new repo? | |
| notting | skvidal: new(additional) not new(replace), iirc | |
| skvidal | notting: I'm sorry, I misunderstood | |
| warren | abadger1999: old repository can remain with only fedora-release, new PackageKit and whatever else is needed to auto-migrate to new key. | |
| drago01: no | ||
| nirik | abadger1999: right, so we should keep the old repo around. | |
| f13 | ok, that's interesting. | |
| clever. | ||
| drago01 | warren: ok, thats better (and works ;) ) | |
| warren | old repository will need an entire dep chain to do it to be safe | |
| drago01 | warren: my idea won't work due to key conflict | |
| abadger1999 | clever... although it still leaves people open to attacks on mirrors. | |
| warren | but that's much smaller than entire repo | |
| drago01: nod | ||
| notting | abadger1999: not if we revoke the key eventually? | |
| warren | abadger1999: redoing the ISO is a separate decision | |
| f13 | yeah, we can worry about how much content to leave in teh old repo | |
| warren | later | |
| abadger1999 | notting: But then the ISO won't update. | |
| * nirik notes kudos to mbonnet for coming up with this idea. ;) | ||
| jds2001 | for the short term, mirrors are going to require twice the space, right? | |
| one for old key, one for new? | ||
| or am I missing something? | ||
| notting | abadger1999: as long as the package referring to the new repo is there... | |
| nirik | abadger1999: should work... update gets new key/repo, then next update gets all new key packages/revokes key | |
| abadger1999: so they have to do 2 updates, but then it should work. | ||
| f13 | wait. | |
| abadger1999 | but the mirror is attacked and new packages are placed there signed with the old key.... | |
| f13 | won't we also have to have a new release/ location? | |
| releases/9-really/ | ||
| f13 | eg the Everything repo? | |
| jds2001 | f13: yeah, I think so. | |
| spoleeba | jds2001, i dont think any mirror will be requests to keep the contents of the old repo..other than the packages necessary for the key migration | |
| notting | abadger1999: that happens with a pressed CD no matter what we do... ever. | |
| f13 | and... hrm. Unless we put in a web redirect that's goign to run afoul of our export filings. | |
| notting | abadger1999: unless i'm missing something | |
| spoleeba | jds2001, err requests/requested... if they choose to keep the old packages...then that's their choice | |
| nirik | notting / abadger1999: yeah, unless we just totally break updates from pressed cd's entirely... | |
| jds2001 | spoleeba: ok, so it's a one-shot deal, and not gradual migration as packages get signed? | |
| abadger1999 | notting: true. pressed CDs are SOL. But if we aren't respinning the ISOs, we're leaving even more things open. | |
| mdomsch | f13, refile the export, no big deal | |
| warren | Can we please agree to do everything about the ISO for now? | |
| decide on the ISO later? | ||
| everything but* | ||
| spoleeba | jds2001, one shot? or do things expire in chunks? | |
| jds2001 | spoleeba: right | |
| notting | skvidal: opinions from yum-land? | |
| f13 | one shot per release. | |
| but we can do releases independantly | ||
| skvidal | not from yum | |
| but from me | ||
| any of the above better have a massive FAQ with it | ||
| * nirik nods. | ||
| skvidal | b/c we're going to confuse the hell out of our users | |
| warren | skvidal: yes, that's one of the steps on the plan | |
| spoleeba | jds2001, so one shot... mirrors cache as much of the old keyd packages as they want or not | |
| nirik | I can hear the tons of questions in #fedora already. | |
| jds2001 | ok, that makes sense. | |
| warren | the FAQ goes out before the fedora-release hits | |
| skvidal | so I wonder | |
| what does the automation buy us | ||
| if we're likely to need to fall back on manual, a lot | ||
| warren | are we? | |
| jds2001 | hopefully non-confused users. | |
| skvidal | b/c it feels like we're making a rube goldberg device for this | |
| warren | skvidal: I might be missing something, but it appears the revised plan has no manual steps for users. | |
| skvidal | that's the problem | |
| it's going to fall over | ||
| I'll put money on it | ||
| warren | Is it really? | |
| nirik | well, they still have to say 'y' to import the key | |
| skvidal | it's fine for people who are in this room | |
| who grok how the pieces fit together | ||
| warren | it would fail for people who substantially modified their .repo files so they no longer have the same names | |
| drago01 | manual is a no go imho and a prompt for the new key won't really confuse users | |
| nirik | anything that requires manual steps is going to leave a ton of users out in the cold. | |
| warren | but I cna't think of any other case where this fails. | |
| f13 | this is a new repo file right, not a modification to the existing repo file? | |
| nirik | f13: yes | |
| drago01 | nirik: nod | |
| f13 | warren: wait, what? what do names have to do with it? | |
| warren | f13: existing repo file is left alone | |
| f13: existing repo file points at old repo, new repo file provided by fedora-release points at new repo. | ||
| mdomsch | [fedora-resigned] | |
| f13 | <warren> it would fail for people who substantially modified their .repo files so they no longer have the same names | |
| ^^ please explain that | ||
| warren | f13: actually, i'm wrong | |
| I was thinking /etc/yum.repos.d/fedora.repo -> /etc/yum.repos.d/myinstitution.repo | ||
| but an upgrade would have screwed them anyway | ||
| because a fresh fedora.repo would come back | ||
| so no, I see no case where this plan falls over. | ||
| jds2001 | warren: they would use mirrormanager anyway, right? | |
| (in an ideal world) | ||
| warren | jds2001: this plan does not require that the original fedora.repo is unmodified. | |
| nirik | skvidal: can you see where this will fail? or you just dislike all the complexity? | |
| f13 | jds2001: it's the non-ideal world we're thinking about. | |
| warren | It is complex yes. | |
| skvidal | nirik: I dislike complexity | |
| abadger1999 | Ooh... Can we have mirrormanager redirect all old repo requests to Fedora servers only? | |
| warren | But I don't see where this would fail. | |
| abadger1999: that is a reasonable idea. | ||
| abadger1999: and less crappy once the resigned content is in place and most packages are gone from old repo | ||
| abadger1999 | <nod> | |
| skvidal | nirik: complexity always loses to simplicity | |
| nirik | skvidal: yeah, I agree, but I think it's better than manual... which many users will: just stop getting updates, get confused and switch distros, etc. | |
| notting | actually, once the resigning is in place, why not do the repo removal in the old repo's fedora-release | |
| warren | Just test this like heck with lots of peer review. | |
| mbonnet | note that the new fedora-release package (pushed to the old repo) would need to contain the old key and new key, to support the upgrade path for fresh installs from media | |
| skvidal | notting: modifying someone's .repo file via scripts? | |
| mdomsch | abadger1999, hmm, I probably _could_ | |
| warren | notting: can you do that all safely in one transaction? | |
| notting: perhaps | ||
| notting: let's test it | ||
| drago01 | skvidal: simpler for us does not always mean simpler for users ;) | |
| f13 | skvidal: no, just don't package the file. | |
| warren | skvidal: no. this does not modify anyone's .repo by scripts. | |
| abadger1999 | mdomsch: It helps with the ISO-has-old-key-deal-with-compromise-on-mirror case. | |
| notting | skvidal: what f13 said | |
| skvidal | drago01: automation that falls over - is harder for users | |
| f13 | drop the .repo file from the package itself. | |
| wwoods | complexity fails to simplicity, but requiring intelligent intervention by users fails even harder | |
| nirik | mbonnet: it just needs to be signed by the old key, right? not contain it anymore? | |
| * mdomsch thinks we should respin the ISOs too | ||
| warren | skvidal: this does NOT modify any .repo file with scripts | |
| f13 | mbonnet: no, it wouldn't. | |
| mdomsch | and nuke the old ISOs | |
| jds2001 | skvidal: if automation falls over, then we still have the manual method. | |
| f13 | mbonnet: the new fedora-release would only point to the new repo, which would have the new key | |
| warren | mdomsch: we can decide that after | |
| mbonnet | nirik: no, it need to contain it, yum imports it the first time you update | |
| drago01 | skvidal: _if_ it fails over.... | |
| skvidal | jds2001: and potentially mangled shit to untangle -what fun | |
| f13 | mbonnet: the last package one would get with the old key is the migration fedora-release package. | |
| mdomsch | the more this looks like a "9.1" release, the better | |
| skvidal | anyway - I don't think yum will vomit at what y'all are planning | |
| nirik | mbonnet: yeah, I guess so. | |
| mbonnet | ahh, f13 is right, ignore me | |
| mdomsch | we're prepared to handle upgrades from "9" to "9.1" | |
| warren | mdomsch: we really don't need to discuss that aspect now | |
| mdomsch: we can do the first 5 steps and decide on the ISO later. | ||
| nirik | f13: if we have packagekit and other updates in the old repo, we do need the key in there... | |
| wwoods | nothing you do with the isos will fix the thousands of Fedora 9 CDs and DVDs already in the wild | |
| nirik | or resign them with new key after everything else is over. | |
| mdomsch | the new fedora-release package will have to go in the old updates repo | |
| mbonnet | nirik: you would already have the old key on your disk, via the fedora-release on media | |
| warren | Does FESCO give rel-eng the autonomy to JUST DO IT and make minor modifications to the plan as necessary so we don't need to wait on more votes to get updates out? | |
| warren | I propose this for vote. | |
| mdomsch: yes, that is written in the plan. | ||
| abadger1999 | mdomsch: already pressed ISOs will still need to hit the old repo to get to the new repo (and trust the packages signed with the old key, there) | |
| dgilmore | notting: +1 | |
| bpepple | notting: ;) | |
| warren | Otherwise, please come up with another plan. Otherwise we remain stuck without update pushes. | |
| mdomsch | abadger1999, I can do a MM repo redirect old -> new trivially | |
| dgilmore | mdomsch: what about 8 to 8.1 | |
| mdomsch | dgilmore, sure | |
| f13 | nirik: no, because you'd either get them in the same transaction you get the transition fedora-release, or you would get them from the new repo after the transaction that gets you fedora-release. | |
| warren | I'm a bit annoyed that nobody worked on this and I had to do it without support from others, and now you are insulting me. | |
| abadger1999 | mdomsch: but the systems getting redirected will have the old key and not the new key. | |
| mdomsch | abadger1999, right - new fedora-release must be in both old and new updates/ repos to get the new key | |
| notting | warren: you're asking the legislative body to give full executive power to someone else. i can't help but make the joke | |
| warren | notting: yes, that part was funny | |
| nirik | f13: ok. :) easy to get confused here... but yeah. | |
| spoleeba | mdomsch, there's old old and then there's new old | |
| * mdomsch feels old old | ||
| warren | What exactly does FESCO want here? | |
| spoleeba | mdomsch, new old could just hold just enough to get the new key installed | |
| nirik | is rel-eng ready to run with this plan? qa thinks its ok? mirrors? infrastructure? | |
| warren | I'm proposing a way to move forward with update pushes with fully automatic rekeying and automatic revoking. If someone else can think of a better idea I want to hear it. | |
| spoleeba | mdomsch, and MM would start directing people to new old... and old old sort of silently gets taken out back and shot | |
| nirik | what will mirrors say to 2x space? (temp at least tho) | |
| warren | nirik: QA came up with the auto-migrate plan 2.5 hours ago | |
| nirik: it isn't 2x space | ||
| mdomsch | nirik, they'll be fine | |
| warren | spoleeba: actually no, that isn't how it works. | |
| bpepple | warren: I think your plan sounds good, I'm just want to make sure we've thought this through since like you said the plan was created pretty recently. | |
| warren | yes, please poke holes in it | |
| nirik | f13: you like this plan? | |
| warren | mbonnet and wwoods thought of this plan, Jeremy and I like it. | |
| I was resistant at first. | ||
| f13 | nirik: I think it's workable, and I don't know of any better way to do it right now. | |
| j-rod | I'm all for trimming the current repo(s) down to the bare minimum to upgrade 1) a cd/dvd-based install with the new key 2) a currently-up-to-date F9 with the new key, and then populate the new repo | |
| mdomsch | warren, you're putting only new updates into an updates/9.1/ tree, or a whole new releases/9.1/ tree which is just resigned? | |
| f13 | nirik: I reserve the right to abort if we get part way down and find a spotw here it fails. | |
| spoleeba | warren, the new fedora-release signed with the old key is going to live side by side with existing updates? | |
| j-rod | anyone else may die in a fire | |
| warren | j-rod: that happens at step #6 | |
| notting | mdomsch: i believe *all* resigned updates go into the new repo | |
| f13 | j-rod: the only thing we should keep in the old repo location is the new fedora-release package | |
| * skvidal will brb | ||
| warren | well, there's reallly three new repos per release | |
| released-resigned | ||
| updates-resigned | ||
| drago01 | f13: and PK | |
| warren | updates-testing-resigned | |
| nirik | f13: and packagekit? or can that move too? | |
| jds2001 | f13: and PK and things required to update to the new PK | |
| jeremy | f13: and arguably the packagekit that can do something nice with the new key | |
| f13 | which I could care less about. | |
| it is adding unnecessary complication | ||
| warren | mdomsch: all resigned packages go into newrepo after they are resigned, but at first only new updates are there. | |
| jds2001 | the F9 GA PK was braindead | |
| f13 | but I suppose if that's what people want... | |
| mdomsch | warren, right - so it does become 2x disk on the mirrors - but they'll take it | |
| f13 | jds2001: yes, and that's too bad. | |
| notting | f13: any chance we could get all f9 updates resigned in < 1 day? if so, we could push that repo full live soon | |
| j-rod | be like Nike | |
| Just Do It | ||
| warren | mdomsch: 2x disk for a moment during rsync before --delete-after engages... | |
| j-rod | (and/or Be Like Mike) | |
| warren | mdomsch: but that doesn't happen for 2 or 3 weeks | |
| f13 | notting: depends on if I can somehow script the signing with expect, and not have the passphrase sitting somewhere in the process list or memory. | |
| mdomsch: if we trim all the old content first, they will actually be net negative on space 9: | ||
| (by old I mean F7 and older) | ||
| warren | The benefit of doing #6 later is we can unstuck rawhide now, and push #6 resigned packages a bit later without flooding mirrors all at once. | |
| j-rod | you need something like ssh-agent for the keysigning passphrase... :) | |
| dgilmore | f13: we should be able to drop F-7 and prior now | |
| warren | Keep in mind that we still have to do the 1100+ rawhide package rebuild | |
| wwoods | honestly, the *way* the F9 PK was braindead is much less painful if you're only updating a small number of packages | |
| f13 | warren: I have yet to see where that bug is a beta blocker | |
| warren | f13: right. | |
| f13 | warren: I have yet to see where that bug actually /breaks/ anything. | |
| warren | f13: do we rebuild before RC? | |
| f13: for that bug | ||
| f13 | -EASKMELATER | |
| warren | ok | |
| warren | So, FESCO, what do you want more? | |
| nirik | another topic? | |
| wwoods | ...on further reflection, that fact isn't really useful, so nevermind. we'd need a third, intermediate repo. | |
| warren | And note, I'm not asking for authorization for ME to make unilateral decisions. You have rel-eng with Jeremy, notting, f13, wwoods, poelstra, etc. | |
| bpepple | warren: no, I'm fine. Does anyone else have any questions? Otherwise we can vote on warren's proposal. | |
| warren | wwoods: what is a third intermediate for? | |
| mdomsch | warren, thank you for taking the lead on drafting these proposals | |
| nirik | I'm +1 on this plan. I think if abort or significant changes need to be made it would be good to drop fesco info on the fesco list and we can regroup. | |
| f13 | warren: yes, thank you, it allowed me to continue concentrating on getting rawhide going. | |
| warren | There were some good minor ideas in this meeting I'll update and post a v3 soon. | |
| bpepple | +1 to warren's plan. | |
| wwoods | warren: stage1: get new key installed. stage2: install one package (using the old messed-up PK dialog) that pulls in the new key. | |
| jds2001 | =1 on this plan too, anything significant changes and fesco can regroup in an emergency meeting | |
| warren | Like the part about keeping a small oldrepo with minimal packages to upgrade an old ISO install. | |
| wwoods | stage3: install a whole mess of packages with the new key and new PK | |
| jds2001 | err +1 | |
| wwoods | or old PK - doesn't matter at that point | |
| warren | wwoods: no, not needed | |
| notting | +1, in general | |
| warren | wwoods: new PK is already signed by old key in old repo, just let them upgrade into that before yum update again with the new fedora-release. | |
| bpepple | dgilmore, j-rod: ? | |
| j-rod | +1, seems generally pretty sane, will hopefully be reasonably painless for users | |
| nirik | also great if we could do some testing of this before it went live... I'm happy to test from here... | |
| wwoods | warren: right - I was trying to figure out a way to make the old repo *only* have the new key/repo files. nevermind. | |
| jds2001 | oh, for sure :) | |
| warren | wwoods: after Step #6 oldrepo is trimmed down to the minimal deps to get to that new PK and new fedora-release. | |
| bpepple | nirik: definitely. | |
| warren | OK folks, beyond deciding on this plan: | |
| * f13 still doesn't like having to deal with PK being there. | ||
| bpepple | alright, I see five '+1' and more importantly no '-1' so we've approved warren's proposal. | |
| nirik | f13: yeah, but if we don't we leave some high % of installs out in the cold. ;( | |
| dgilmore | bpepple: +1 for the general idea | |
| warren | 1) We need to decide if we want to include a better auto-migration thing in Fedora 10 JUST IN CASE. I liked (jwb's?) idea of a secondary key that is kept off the network entirely. | |
| wwoods | f13: yeah, it's weaksauce, but you remember the failure condition for PK was *SO BAD* that we added last-minute horrible hacks to anaconda over jeremy's (valid) objections | |
| warren | 2) Decide on the ISO question separately later. | |
| dgilmore | i think there will be issues to correct as we move forward | |
| wwoods | just to avoid it | |
| and now we're faced with the same problem, again. ha ha! | ||
| hilarious. wait, no, the other thing. ass-scorchingly awful. | ||
| dgilmore | wwoods: pk is an ugly mess | |
| warren | f13: how are we on the update signing infra? | |
| f13: I can work on the proposed new fedora-release today and some testing. | ||
| f13: I also have a fresh 5.2 install at home if we want to generate on a known clean box. | ||
| f13 | warren: that's an lmacken question. | |
| warren | lmacken: ? | |
| f13 | warren: we're not lacking in fresh installs. | |
| warren | ok | |
| lmacken | f13: sign1 hasn't been touched since I installed/updated it | |
| warren: ^ | ||
| f13 | k | |
| if I can pawn rawhide bugs off on skvidal today, I can work on the sign box | ||
| and getting keys and starting to sign stuff. | ||
| warren | ok good | |
| I'll update and post v3 | ||
| abadger1999 | warren: the secondary key was my idea. But I don't know if it's better or worse than coming up with some app to revoke and import new keys based on a master key. | |
| warren | abadger1999: secondary key is an incredibly simple idea. Just need to adequately protect the private key. | |
| f13 | first thing is first, get rpm to understand trust chains | |
| wwoods | I keep thinking.. man, it'd be nice if we were using a signing cert system that supported trust chains and revocation | |
| f13 | and pubkey revocation | |
| warren | f13: did you read the secondary key idea? it was really simple. needs no rpm changes. | |
| nirik | I think we will want to re-think and come up with a overall better plan moving forward that allows us to revoke and other fun things. | |
| warren | ok | |
| anyway that's a later discussion | ||
| I'll get on v3 | ||
| and fedora-release | ||
| f13 | and really, why continue gpg? ssl certs would work too | |
| warren | why keys at all? they would be violating the DMCA | |
| nirik | bpepple: ok, next topic? | |
| nirik | warren: thanks for putting all the ideas together... | |
| bpepple | thanks, warren. | |
| ok, do we want to wrap up the meeting or do we want to discuss the default groups topic that kanarip sent the e-mail about? | ||
| f13 | oh that. | |
| I'm still working on that some | ||
| at least making what happens during install less bothersome by default, without having to make any changes to comps meaning | ||
| (nor making it more complicated) | ||
| bpepple | I'm inclined to call it done for today since we've already been going for an hour and a half. | |
| * nirik is ok with that... | ||
| bpepple | ok, let's wrap it up then..... | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!