--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo 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.
warrenI just posted an updated New Key plan to rel-eng and fesco lists.  It handles both auto-migration and auto-revoke.  Please review!
warrenI don't mean to hijack this meeting, but I am asking for the following from FESCO.
* jds2001 here
warrenFESCO, 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.)
bpepplewarren: before we get to that, could we do two quick topics since the keys & schedule topics will probably take awhile to discuss.
j-rodbpepple: Kick__ is out for today, if you didn't already catch his email
warrenbpepple: if this above request is followed, it wouldn't be time consuming.
nottingbpepple: schedule before keys, at least. simpler that way
bpepplej-rod: yeah, I caught it.
warrenbpepple: I would be happy to answer any questions when the time comes.
* warren waits.
bpepplenotting: 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
bpeppleanyone have any objections to the FPC proposals?
* dgilmore is here
dgilmorewarren: wait your tuen
* bpepple note Kick gave +1 to them on the mailing list.
nirik+1 from me, they seem fine, as does the new guideline.
nottingseems ok, +1
dgilmorehttp://fedoraproject.org/wikiPackagingDrafts/Haskell  gives a 404
j-rodworksforme, +1
* dwmw2 looking for multilib fun
j-roddgilmore: malformed url
nirikdgilmore: missing a / there
j-rodput a / after wiki and before Packaging
bpeppleok, I don't hear any objections, so we can probably move on....
dgilmorej-rod, nirik: thats the url that FPC posted
bpepplewe 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-roddgilmore: yep, they screwed up. :)
nottingwhat's changed?
* dgilmore has concerns about user security with this feature
nirikdidn't we have some questions about this one? I don't see anything on discussion page tho.
jds2001is the data actually stored on online.gnome.org?
bpepplenotting: I'm not sure anything changed.  I didn't see any questions for the feature owner on the discussion page.
warrenpasswords stored in gnome-keyring it says
jds2001i thought it was on the local keyring
j-rodseemed to me like there was plenty of data also stored on online.gnome.org, if you opted to let it be
dgilmorejds2001: yes  but it exposes dbus in new ways.  and there has to be something remotely that they auth against
nirikalso, is this a real visible feature with only the online desktop sidebar using it, and for only 2 sites?
jds2001nirik: i think it can be built upon
nirikyeah, also I guess it's gnome specific...
bpepplejds2001: yeah, I believe their plan is to expand upon it.
j-rodsure 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
nirikyeah, thats what I was getting at... with a bunch more apps and such, it could be a nice f11 feature...
bpepplej-rod: yeah, I'm inclined to think the same thing.
jds2001is the feature owner around to comment?
bpepplejds2001: 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
bpepplejds2001: 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 :(
warrenI'm told that marina is online gimpnet
otaylorjds2001: we have twittux patches working right now
nirikI can ask them to come here... ? I am over there...
otaylorjds2001: have to get them by bpepple first, of course :-)
bpeppleotaylor: shouldn't be a problem. ;)
otaylornirik: 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
nirikok. ;)
bpeppledgilmore: what was your question about security?
nirikotaylor: 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?
dgilmorebpepple: how data is transported
dgilmorewhats done to make sure its not picked up over the wire
jds2001and *what* data is transported
dgilmorecan a break in on the server comprimise user machines
whats done to prevent that from happening
jds2001or user account data?
otaylornirik: well,it's going to be a fairly limited feature initially.
dgilmore: OK, first storing anything on the server is opt-in
j-rodfor 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...
otaylordgilmore: 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
otaylordgilmore: 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
dgilmoreotaylor: whats done to prevent me using dbus  to get back at a user machine?
otaylordgilmore: 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-rodotaylor: ok, but for f10, we *are* talking about storing the user to online accounts mapping at online.gnome.org?
otaylordgilmore: 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
otaylordgilmore: 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-rodwalters_: yeah, I got that, just wanting to confirm that there *is* the option for stuff to go there w/in the f10 scope
otaylorj-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... :)
otaylorj-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-rodso 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
f13am I too late for the meeting?
I just got my internet working.
walters_j-rod: the gnome keyring only stores passwords
bpepplef13: nope.
jds2001f13: no
j-rodwalters_: does it store the online account passwords?
walters_j-rod: it's not an account system really
dgilmoreotaylor: so i send malicous packets over xmpp
jds2001dgilmore: to what end?
jds2001dgilmore: corrupting other people's data?
j-rodwalters_: so the screenie on the feature page... that's a new app? and the password you enter there gets stored in the gnome keyring?
otaylordgilmore: 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-rodwalters_: ok, I think I finally have things straight in my head. :)
otaylordgilmore: 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
dgilmoreotaylor: 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)
dgilmoreim thinking it could possibly be used to open a backdoor to users boxes
jds2001but is mugshot not similarly high-visibility today>?
otaylordgilmore: I don't see how, unless our protocol handling code is exploitable.
j-rodwalters_: right, so instead of having to input account info in pidgin (or whatever that new gnome client is), it just ties into this
otaylordgilmore: it's not inconceivable, of course, but we're using the standard loudmouth library
walters_j-rod: yeah
dgilmoreotaylor: ok
bpeppleok, are there any more questions, or are we ready to vote on this?
j-rodok, now that (I think) I understand this much better, +1
dgilmoreotaylor: and you have a clear policy to show users what data you do and dont use and whats kept where.
bpepple+1 to online account feature.
jds2001+1 here
otaylordgilmore: for this service in particular, everything that is kept on line is shown to you on your online accounts page
dgilmoreotaylor: how does a user know that?
otaylor: you need a very clear easily accesable privacy policy
nirikotaylor: the privacy policy link on online.gnome.org redirects to mugshots...
otaylordgilmore: there are other services running on the server (like mugshot) that are slightly less transparent ... there we have a privacy policy with detailed information.
niriknot sure thats not going to confuse people. ;)
anyhow, +1 from me.
bpeppleok, 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-rodhey, I thought this *was* fun... :)
otaylornirik: 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.
nirikotaylor: yeah, at least it would need to mention online.gnome.org too... the mugshot one only lists mugshot.
bpepplej-rod: no, I think the keys topic will be a *lot* more fun. ;)
otaylornirik: 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-rodotaylor/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
otaylornirik: 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
nirikotaylor: 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.
bpeppleok, so thats five '+1', and one '-1' to this feature.
otaylornirik: I'll make sure we improve the situation before f10 release
j-rodbpepple: keys topic... certainly could be more "fun" for some definition of... :)
bpeppleotaylor, 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
otaylorbpepple: Your welcome. Thanks to all of you for reviewing the feature.
bpeppleotaylor: np.
f13oh hey, the schedule change.
nottinghttp://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.
f13I hope not.
wwoodswhat could possibly go wrong?
nirik+1 to the new schedule.
bpeppleas is we don't have much wiggle room with the new schedule.  We getting close to the holiday season.
jds2001f13: I assume that's because there's only one of you?
jds2001: no, more like there is only one of koji
I don't see why we couldn't do 2 sign guests for a short period of time to make things go faster.
dgilmoref13: we can bring up another hub  for doing releng stuff on
f13not sure if that will help too much
but interesting thought
nottingf13: is the # of guests really the bottleneck vs. bw to/from the data
f13notting: 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
bpepplef13: do you think it's realistic for us to get the beta out on sept. 9th?
f13anyway, was there any objections to the schedule change?
j-rod+1, worksforme
f13bpepple: I think it is, unless things go horribly wrong in the next week
jds2001  +1
bpepple+1 to schedule change.
dgilmore+1  to schedule change
bpeppleok, 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
poelcatbpepple: 2008-09-09 is the freeze not public availability
nirikthere's no good answers here, but I say +1 to the last plan warren sent out...
warrenyes, all possible options suck
f13what's the link to the last plan?
* drago01 likes the "users don't have to do it by hand" part
abadger1999warren: How do you get away with not touching the iso?
f13just want to make sure it's the same thing I was reading yesterday.
bpepplepoelcat: your right.  I was looking at the wrong date.
nottingf13: no, it's different
warrenabadger1999: 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
nottingabadger1999: isos are individually verifiable, and it's not like we can get rid of burned & pressed CDs in the wild
abadger1999notting: right... but if we're getting rid of the old repository, the iso is no longer update capable.
skvidaldoes #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)
wwoodsit still adds the new updates repo, as long as it has a new name
jds2001and what about space on the mirrors?
warrenabadger1999: no
drago01abadger1999: what about a redirect from old>new repo?
nottingskvidal: new(additional) not new(replace), iirc
skvidalnotting: I'm sorry, I misunderstood
warrenabadger1999: old repository can remain with only fedora-release, new PackageKit and whatever else is needed to auto-migrate to new key.
drago01: no
nirikabadger1999: right, so we should keep the old repo around.
f13ok, that's interesting.
drago01warren: ok, thats better (and works ;) )
warrenold repository will need an entire dep chain to do it to be safe
drago01warren: my idea won't work due to key conflict
abadger1999clever... although it still leaves people open to attacks on mirrors.
warrenbut that's much smaller than entire repo
drago01: nod
nottingabadger1999: not if we revoke the key eventually?
warrenabadger1999: redoing the ISO is a separate decision
f13yeah, we can worry about how much content to leave in teh old repo
abadger1999notting: But then the ISO won't update.
* nirik notes kudos to mbonnet for coming up with this idea. ;)
jds2001for the short term, mirrors are going to require twice the space, right?
one for old key, one for new?
or am I missing something?
nottingabadger1999: as long as the package referring to the new repo is there...
nirikabadger1999: 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.
abadger1999but the mirror is attacked and new packages are placed there signed with the old key....
f13won't we also have to have a new release/ location?
f13eg the Everything repo?
jds2001f13: yeah, I think so.
spoleebajds2001, 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
nottingabadger1999: that happens with a pressed CD no matter what we do... ever.
f13and... hrm.  Unless we put in a web redirect that's goign to run afoul of our export filings.
nottingabadger1999: unless i'm missing something
spoleebajds2001, err requests/requested... if they choose to keep the old packages...then that's their choice
niriknotting / abadger1999: yeah, unless we just totally break updates from pressed cd's entirely...
jds2001spoleeba: ok, so it's a one-shot deal, and not gradual migration as packages get signed?
abadger1999notting: true. pressed CDs are SOL.  But if we aren't respinning the ISOs, we're leaving even more things open.
mdomschf13, refile the export, no big deal
warrenCan we please agree to do everything about the ISO for now?
decide on the ISO later?
everything but*
spoleebajds2001, one shot? or do things expire in chunks?
jds2001spoleeba: right
nottingskvidal: opinions from yum-land?
f13one shot per release.
but we can do releases independantly
skvidalnot from yum
but from me
any of the above better have a massive FAQ with it
* nirik nods.
skvidalb/c we're going to confuse the hell out of our users
warrenskvidal: yes, that's one of the steps on the plan
spoleebajds2001, so one shot... mirrors cache as much of the old keyd packages as they want or not
nirikI can hear the tons of questions in #fedora already.
jds2001ok, that makes sense.
warrenthe FAQ goes out before the fedora-release hits
skvidalso I wonder
what does the automation buy us
if we're likely to need to fall back on manual, a lot
warrenare we?
jds2001hopefully non-confused users.
skvidalb/c it feels like we're making a rube goldberg device for this
warrenskvidal: I might be missing something, but it appears the revised plan has no manual steps for users.
skvidalthat's the problem
it's going to fall over
I'll put money on it
warrenIs it really?
nirikwell, they still have to say 'y' to import the key
skvidalit's fine for people who are in this room
who grok how the pieces fit together
warrenit would fail for people who substantially modified their .repo files so they no longer have the same names
drago01manual is a no go imho and a prompt for the new key won't really confuse users
nirikanything that requires manual steps is going to leave a ton of users out in the cold.
warrenbut I cna't think of any other case where this fails.
f13this is a new repo file right, not a modification to the existing repo file?
nirikf13: yes
drago01nirik: nod
f13warren: wait, what?  what do names have to do with it?
warrenf13: 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.
f13<warren> it would fail for people who substantially modified their .repo files so they no longer have the same names
^^ please explain that
warrenf13: 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.
jds2001warren: they would use mirrormanager anyway, right?
(in an ideal world)
warrenjds2001: this plan does not require that the original fedora.repo is unmodified.
nirikskvidal: can you see where this will fail? or you just dislike all the complexity?
f13jds2001: it's the non-ideal world we're thinking about.
warrenIt is complex yes.
skvidalnirik: I dislike complexity
abadger1999Ooh... Can we have mirrormanager redirect all old repo requests to Fedora servers only?
warrenBut 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
skvidalnirik: complexity always loses to simplicity
nirikskvidal: 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.
nottingactually, once the resigning is in place, why not do the repo removal in the old repo's fedora-release
warrenJust test this like heck with lots of peer review.
mbonnetnote 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
skvidalnotting: modifying someone's .repo file via scripts?
mdomschabadger1999, hmm, I probably _could_
warrennotting: can you do that all safely in one transaction?
notting: perhaps
notting: let's test it
drago01skvidal: simpler for us does not always mean simpler for users ;)
f13skvidal: no, just don't package the file.
warrenskvidal: no.  this does not modify anyone's .repo by scripts.
abadger1999mdomsch: It helps with the ISO-has-old-key-deal-with-compromise-on-mirror case.
nottingskvidal: what f13 said
skvidaldrago01: automation that falls over - is harder for users
f13drop the .repo file from the package itself.
wwoodscomplexity fails to simplicity, but requiring intelligent intervention by users fails even harder
nirikmbonnet: it just needs to be signed by the old key, right? not contain it anymore?
* mdomsch thinks we should respin the ISOs too
warrenskvidal: this does NOT modify any .repo file with scripts
f13mbonnet: no, it wouldn't.
mdomschand nuke the old ISOs
jds2001skvidal: if automation falls over, then we still have the manual method.
f13mbonnet: the new fedora-release would only point to the new repo, which would have the new key
warrenmdomsch: we can decide that after
mbonnetnirik: no, it need to contain it, yum imports it the first time you update
drago01skvidal: _if_ it fails over....
skvidaljds2001: and potentially mangled shit to untangle -what fun
f13mbonnet: the last package one would get with the old key is the migration fedora-release package.
mdomschthe more this looks like a "9.1" release, the better
skvidalanyway - I don't think yum will vomit at what y'all are planning
nirikmbonnet: yeah, I guess so.
mbonnetahh, f13 is right, ignore me
mdomschwe're prepared to handle upgrades from "9" to "9.1"
warrenmdomsch: we really don't need to discuss that aspect now
mdomsch: we can do the first 5 steps and decide on the ISO later.
nirikf13: if we have packagekit and other updates in the old repo, we do need the key in there...
wwoodsnothing you do with the isos will fix the thousands of Fedora 9 CDs and DVDs already in the wild
nirikor resign them with new key after everything else is over.
mdomschthe new fedora-release package will have to go in the old updates repo
mbonnetnirik: you would already have the old key on your disk, via the fedora-release on media
warrenDoes 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?
warrenI propose this for vote.
mdomsch: yes, that is written in the plan.
abadger1999mdomsch: 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)
dgilmorenotting: +1
bpepplenotting: ;)
warrenOtherwise, please come up with another plan.  Otherwise we remain stuck without update pushes.
mdomschabadger1999, I can do a MM repo redirect old -> new trivially
dgilmoremdomsch: what about 8 to 8.1
mdomschdgilmore, sure
f13nirik: 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.
warrenI'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.
abadger1999mdomsch: but the systems getting redirected will have the old key and not the new key.
mdomschabadger1999, right - new fedora-release must be in both old and new updates/ repos to get the new key
nottingwarren: you're asking the legislative body to give full executive power to someone else. i can't help but make the joke
warrennotting: yes, that part was funny
nirikf13: ok. :) easy to get confused here... but yeah.
spoleebamdomsch, there's old old  and then there's new old
* mdomsch feels old old
warrenWhat exactly does FESCO want here?
spoleebamdomsch, new old could just hold just enough to get the new key installed
nirikis rel-eng ready to run with this plan? qa thinks its ok? mirrors? infrastructure?
warrenI'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.
spoleebamdomsch, and MM would start directing people to new old... and old old sort of silently gets taken out back and shot
nirikwhat will mirrors say to 2x space? (temp at least tho)
warrennirik: QA came up with the auto-migrate plan 2.5 hours ago
nirik: it isn't 2x space
mdomschnirik, they'll be fine
warrenspoleeba: actually no, that isn't how it works.
bpepplewarren: 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.
warrenyes, please poke holes in it
nirikf13: you like this plan?
warrenmbonnet and wwoods thought of this plan, Jeremy and I like it.
I was resistant at first.
f13nirik: I think it's workable, and I don't know of any better way to do it right now.
j-rodI'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
mdomschwarren, you're putting only new updates into an updates/9.1/ tree, or a whole new releases/9.1/ tree which is just resigned?
f13nirik: I reserve the right to abort if we get part way down and find a spotw here it fails.
spoleebawarren, the new fedora-release signed with the old key is going to live side by side with existing updates?
j-rodanyone else may die in a fire
warrenj-rod: that happens at step #6
nottingmdomsch: i believe *all* resigned updates go into the new repo
f13j-rod: the only thing we should keep in the old repo location is the new fedora-release package
* skvidal will brb
warrenwell, there's reallly three new repos per release
drago01f13: and PK
nirikf13: and packagekit? or can that move too?
jds2001f13: and PK and things required to update to the new PK
jeremyf13: and arguably the packagekit that can do something nice with the new key
f13which I could care less about.
it is adding unnecessary complication
warrenmdomsch: all resigned packages go into newrepo after they are resigned, but at first only new updates are there.
jds2001the F9 GA PK was braindead
f13but I suppose if that's what people want...
mdomschwarren, right - so it does become 2x disk on the mirrors - but they'll take it
f13jds2001: yes, and that's too bad.
nottingf13: any chance we could get all f9 updates resigned in < 1 day? if so, we could push that repo full live soon
j-rodbe like Nike
Just Do It
warrenmdomsch: 2x disk for a moment during rsync before --delete-after engages...
j-rod(and/or Be Like Mike)
warrenmdomsch: but that doesn't happen for 2 or 3 weeks
f13notting: 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)
warrenThe 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-rodyou need something like ssh-agent for the keysigning passphrase... :)
dgilmoref13: we should be able to drop F-7 and prior now
warrenKeep in mind that we still have to do the 1100+ rawhide package rebuild
wwoodshonestly, the *way* the F9 PK was braindead is much less painful if you're only updating a small number of packages
f13warren: I have yet to see where that bug is a beta blocker
warrenf13: right.
f13warren: I have yet to see where that bug actually /breaks/ anything.
warrenf13: do we rebuild before RC?
f13: for that bug
warrenSo, FESCO, what do you want more?
nirikanother topic?
wwoods...on further reflection, that fact isn't really useful, so nevermind. we'd need a third, intermediate repo.
warrenAnd note, I'm not asking for authorization for ME to make unilateral decisions.  You have rel-eng with Jeremy, notting, f13, wwoods, poelstra, etc.
bpepplewarren: no, I'm fine.  Does anyone else have any questions?  Otherwise we can vote on warren's proposal.
warrenwwoods: what is a third intermediate for?
mdomschwarren, thank you for taking the lead on drafting these proposals
nirikI'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.
f13warren: yes, thank you, it allowed me to continue concentrating on getting rawhide going.
warrenThere were some good minor ideas in this meeting I'll update and post a v3 soon.
bpepple+1 to warren's plan.
wwoodswarren: 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
warrenLike the part about keeping a small oldrepo with minimal packages to upgrade an old ISO install.
wwoodsstage3: install a whole mess of packages with the new key and new PK
jds2001err +1
wwoodsor old PK - doesn't matter at that point
warrenwwoods: no, not needed
notting+1, in general
warrenwwoods: 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.
bpeppledgilmore, j-rod: ?
j-rod+1, seems generally pretty sane, will hopefully be reasonably painless for users
nirikalso great if we could do some testing of this before it went live... I'm happy to test from here...
wwoodswarren: right - I was trying to figure out a way to make the old repo *only* have the new key/repo files. nevermind.
jds2001oh, for sure :)
warrenwwoods: after Step #6 oldrepo is trimmed down to the minimal deps to get to that new PK and new fedora-release.
bpepplenirik: definitely.
warrenOK folks, beyond deciding on this plan:
* f13 still doesn't like having to deal with PK being there.
bpepplealright, I see five '+1' and more importantly no '-1' so we've approved warren's proposal.
nirikf13: yeah, but if we don't we leave some high % of installs out in the cold. ;(
dgilmorebpepple: +1  for the general idea
warren1) 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.
wwoodsf13: 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
warren2) Decide on the ISO question separately later.
dgilmorei think there will be issues to correct as we move forward
wwoodsjust to avoid it
and now we're faced with the same problem, again. ha ha!
hilarious. wait, no, the other thing. ass-scorchingly awful.
dgilmorewwoods: pk is an ugly mess
warrenf13: 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.
f13warren: that's an lmacken question.
warrenlmacken: ?
f13warren: we're not lacking in fresh installs.
lmackenf13: sign1 hasn't been touched since I installed/updated it
warren: ^
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.
warrenok good
I'll update and post v3
abadger1999warren: 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.
warrenabadger1999: secondary key is an incredibly simple idea.  Just need to adequately protect the private key.
f13first thing is first, get rpm to understand trust chains
wwoodsI keep thinking.. man, it'd be nice if we were using a signing cert system that supported trust chains and revocation
f13and pubkey revocation
warrenf13: did you read the secondary key idea?  it was really simple.  needs no rpm changes.
nirikI 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.
anyway that's a later discussion
I'll get on v3
and fedora-release
f13and really, why continue gpg?  ssl certs would work too
warrenwhy keys at all?  they would be violating the DMCA
nirikbpepple: ok, next topic?
nirikwarren: thanks for putting all the ideas together...
bpepplethanks, 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?
f13oh 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)
bpeppleI'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...
bpeppleok, 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!