From Fedora Project Wiki
Fedora Release Engineering Meeting :: Monday 2008-11-11
Fedora 10
- still frozen, and still accepting bugfix builds.
- November 16 is the last day to tag packages
- November 17 to 21 to create a final release
- Fedora 10 blocker list is needs to some work
- team of people is meeting on #fedora-blocker to work through list
- discussion of signed repo data
IRC Transcript
| f13 | ping: notting jeremy lmacken warren rdieter wwoods poelcat spot | 10:01 |
|---|---|---|
| jeremy | hi hi | 10:01 |
| * poelcat here | 10:01 | |
| * warren here | 10:01 | |
| * spot is here | 10:01 | |
| rdieter | hi | 10:01 |
| f13 | alright, lets get rolling | 10:02 |
| -!- f13 changed the topic of #fedora-meeting to: Fedora releng - F10 Final | 10:03 | |
| f13 | the 800lb gorilla that is Fedora 10 is upon us | 10:03 |
| f13 | We're still frozen, and still accepting bugfix builds. | 10:03 |
| f13 | as of tomorrow's rawhide, the version at install time will be 10, release name is set to Cambridge, and the fedora, fedora-updates repos are enabled, rawhide is disabled. | 10:04 |
| f13 | mirrormanager is taking care of the redirects on the repo front. | 10:04 |
| f13 | from our prospective things are shaping up, the last vestiges of a 'development' tree is the betanag in anaconda | 10:05 |
| warren | f13: does this mean everything in rawhide is signed? | 10:06 |
| f13 | warren: yes, it's been signed since before the Preview release. | 10:06 |
| warren | including new tagged things today? | 10:06 |
| f13 | yes. | 10:06 |
| * wwoods here | 10:06 | |
| jeremy | when is our drop dead date for meeting the release date? | 10:06 |
| f13 | in fact I just punched in the passphrase to sign everything I tagged this morning. | 10:07 |
| f13 | jeremy: we're giving people the 16th as the last day that we'll tag packages. | 10:07 |
| jeremy | k | 10:07 |
| f13 | that gives us from Monday the 17th to get the final tree prepared, staged, verified and synced. | 10:07 |
| f13 | for release on the 25th | 10:07 |
| * jeremy hasn't looked to see how much doom the blocker list is recently | 10:08 | |
| f13 | it's not great :/ | 10:08 |
| wwoods | it's pretty nasty | 10:08 |
| wwoods | I hear reports of lingering badness on i855, i9xx, assorted radeon bogosity | 10:08 |
| warren | notting: was the anaconda bug with /dev/mapper/something names in fstab causing upgrade failure filed? | 10:08 |
| wwoods | but I can't test any of it :/ | 10:08 |
| notting | warren: notabug | 10:08 |
| warren | notting: notabug? | 10:08 |
| warren | notting: anaconda of F9 wrote that into my fstab | 10:09 |
| notting | warren: anaconda migrates fstab/crypttab on upgrade. yum upgrades will read the old name fine | 10:09 |
| warren | notting: you mean the bug was fixed? | 10:10 |
| warren | [root@newcaprica i386]# cat /etc/fstab | 10:10 |
| warren | /dev/mapper/luks-vg0-system9 / ext3 defaults 1 1 | 10:10 |
| warren | /dev/mapper/luks-vg0-system9 anaconda doesn't like | 10:10 |
| warren | upgrades work fine if the vg was encrypted, but not if the individual lv was | 10:11 |
| notting | i can't parse what you just said | 10:11 |
| warren | I thought we were talking about this bug in #fedora-devel last week | 10:12 |
| warren | notting: if you had installed F9 onto an encrypted vg, anaconda can upgrade it just fine | 10:12 |
| wwoods | let's talk a bit about the emergency plan | 10:12 |
| notting | the bug was a phantom | 10:12 |
| warren | but if only your / partition was encrypted, /dev/mapper/luks-something was written in /etc/fstab, causing anaconda to fail upgrades | 10:12 |
| warren | notting: you're saying this isn't a bug? | 10:13 |
| notting | warren: install f9, attempt an upgrade, file a bug if it actually fails. i'm not convinced it does | 10:14 |
| f13 | yeah, this sounds like NEEDSRETESTING | 10:14 |
| warren | fine, will retest | 10:14 |
| f13 | wwoods: emergency plan, as in if we have to slip? | 10:14 |
| wwoods | yeah. consider how much doom we have on the blocker list right now | 10:15 |
| wwoods | let's assume it's actually worse than that | 10:15 |
| f13 | if we slip, it's going to be for at a minimum 2 weeks | 10:15 |
| f13 | that gets us around thanksgiving and I don't get knifed in my sleep for working while family is here | 10:15 |
| wwoods | thanksgiving is especially dangerous, what with the turkey carving knives and all | 10:16 |
| wwoods | suffocated in pumpkin pie | 10:16 |
| wwoods | etc. | 10:16 |
| f13 | what a way to go | 10:17 |
| f13 | (side note, i think it's worth yet another "would we actually slip the release for this" triage event on the blockers, live, on IRC with buggbot) | 10:17 |
| wwoods | yeah, definitely agree | 10:18 |
| wwoods | preferably with ajax/airlied assisting | 10:18 |
| poelcat | #fedora-blocker is still alive :) | 10:18 |
| wwoods | since I really can't get a sense for how bad the graphics problems really are | 10:18 |
| wwoods | beyond user complaints. which are, as always, loud and shrill | 10:18 |
| f13 | who's up for blocker bingo this afternoon? | 10:20 |
| rdieter | my personal experience here with lappy x86_64/intel-945 is regressed a bit from F-9. stability and compositing-performance has dropped dramatically. I can get by with xrender effects. but this is just me. | 10:20 |
| f13 | (well crap it's already afternoon for many of you) | 10:20 |
| wwoods | rdieter: yes, we know | 10:21 |
| f13 | rdieter: you're lucky, I can't get compiz to work, at all, on i965 | 10:21 |
| wwoods | it's slow, suspend/resume doesn't work, it crashes sometimes, this all used to work, etc. etc. | 10:21 |
| notting | f13: odd, my 965 box worked fine the last time i tried (last week-ish)( | 10:21 |
| rdieter | yay. ok. For what it's worth, my radeon box at home is worse. :( | 10:22 |
| f13 | lets say start the blocker party in 2.5~ hours, 1600 Eastern, 1300 pacific? | 10:22 |
| wwoods | so yeah, let's do blocker-bingo sometime after f13 gets some lunch | 10:22 |
| notting | f13: i have to leave ~1700, but sure | 10:22 |
| * spot will be there | 10:22 | |
| * f13 just realized something. | 10:22 | |
| f13 | nope, n/m. | 10:23 |
| f13 | twas just indigestion. | 10:23 |
| * nirik 's intel 945 is working fine, but then I don't use compiz/etc... | 10:23 | |
| f13 | ok, I'll try to ping some folks to show up at that time/place. | 10:23 |
| wwoods | I don't consider compiz failures a blocker per se | 10:24 |
| notting | which place? | 10:24 |
| wwoods | but goddamn are we going to get a lot of static over that | 10:24 |
| wwoods | if it doesn't work in F10 | 10:24 |
| spot | #fedora-blocker | 10:25 |
| wwoods | "this worked fine in F9, F10 sux, fedora sux now" | 10:25 |
| f13 | in other news... | 10:28 |
| f13 | I'd like to think about enabling signed repodata for F10 final and F10 updates(-testing) | 10:28 |
| f13 | at this time it'll require a post-repo creation by hand action, but it should be quick and relatively painless ( about as much pain as the by hand signing of packages in the first place ) | 10:29 |
| f13 | it would require a tiny bit of additional logic to the sync-fedora-updates script that takes care of rsyncing bodhi's output to the master mirror. eg checking for the existance of signed repodata and if not found, don't do the sync. | 10:30 |
| f13 | for the final release bits it'll just be one more thing to do to the tree, like gpg signing the SHA1SUM files | 10:30 |
| notting | will there be some sort of notifier that shows the updates push as not finished if we forget to sign? | 10:30 |
| warren | is signed repodata really necessary? what does it gain us? | 10:30 |
| warren | f13: what is the signed repodata filename? if the filename doesn't change, then we're back to the original proxy problem | 10:31 |
| f13 | warren: the signature is detached | 10:31 |
| warren | does yum check it automatically? | 10:31 |
| f13 | warren: I do believe so, seth will have more details there. | 10:31 |
| warren | also, was packagekit tested to handle this and key import? =) | 10:32 |
| f13 | warren: what it gains is is this. repomd.xml lists out the other repodata files and checksums. | 10:32 |
| f13 | we don't have a central place for this file, so we have to trust that the file the mirrors hand us is valid | 10:32 |
| warren | btw, what happened with presto? | 10:32 |
| f13 | by gpg signing it, clients can verify that what they got from a mirror, was intended for Fedora audiences and originated within Fedora, wasn't manufactured on the side. | 10:33 |
| f13 | warren: -EMANPOWER | 10:33 |
| warren | ok | 10:33 |
| f13 | casey worked some on it, but the upstream kept disappearing for long periods of time | 10:33 |
| f13 | warren: there is a good point about packagekit, however I do believe that seth and friends had been testing gpg signed repos for a bit, with various tools. | 10:34 |
| f13 | it's not very difficult to setup such a repo so we can do the testing. | 10:34 |
| warren | ok, as long as packagekit is tested | 10:34 |
| f13 | if it proves not working, we quite simply punt for this release and try again for F11 | 10:34 |
| f13 | but Fedora does get dinged often for not having signed repodata | 10:34 |
| warren | what attack vector is there? | 10:35 |
| warren | the packages themselves are signed | 10:35 |
| f13 | warren: I'll need the yum folks to answer that. | 10:38 |
| poelcat | f13: is F11 schedule discussion on today's agenda? | 10:39 |
| f13 | poelcat: I don't think so. | 10:40 |
| mitr | warren: A mirror can hold back specific packages that fix known vulnerabilities. | 10:42 |
| f13 | mitr: signed repodata doesn't help with that. | 10:43 |
| f13 | mitr: they could just as easily hold back the signed repodata that references the broken packages. | 10:43 |
| mitr | f13: Right - but in that case the user might notice no updates coming at all. | 10:43 |
| f13 | ... which is no different from today | 10:44 |
| f13 | the presence of a gpg signature adds nothign in this regard. | 10:44 |
| f13 | sadly the yum folks are not answering the phone | 10:44 |
| f13 | anyway, I'll start a thread maybe on fedora-devel-list (or ask seth to) regarding signed repodata for F10 | 10:50 |
| f13 | I've agreed to do the extra work it would take from the repo-pushing point of view, but I'd like to see what kind of testing they have, what problem it's solving, etc... | 10:50 |
| -!- f13 changed the topic of #fedora-meeting to: Fedora releng - open floor | 10:50 | |
| f13 | any thing from anybody else? | 10:50 |
| wwoods | f13: seen mdomsch around? any idea how to update releases.txt for preupgrade? | 10:51 |
| wwoods | that's another step that needs to be added to the release SOP | 10:51 |
| wwoods | but I don't know how/where to make the changes | 10:51 |
| f13 | hrm. | 10:52 |
| f13 | wwoods: I'll try to keep an eye out for that. | 10:52 |
| f13 | wwoods: for now, is there a ticket filed in rel-eng track for it on the F10-final milestone? | 10:52 |
| wwoods | f13: dunno, I'll check and file one if not | 10:53 |
| f13 | thanks | 10:53 |
| mitr | re: signing server: It can implement a dual control policy - requests from two separate users would be required to return any signature. This protects against compromising the client of a single signer. Is it practical for you, or is the added security not worth it? | 10:54 |
| f13 | mitr: I think that might be overkill, and lead to resource starving . | 10:54 |
| mitr | f13: Thought so, thanks. | 10:54 |
| f13 | having it be there and be able to turn it on at some point would be worthwhile though | 10:55 |
| geppetto | so ... signed repo repomd.xml ... what problem does it solve: | 10:56 |
| geppetto | The problem is: attacker takes over mirror for victim ... creates new repodata which has fake requires for a new glibc on an older vulnerable-package | 10:57 |
| geppetto | We have metalink ... but that isn't SSL, so an attacker can (even more theoretically) still modify that | 10:58 |
| geppetto | So with signed repomd.xml, the only attack they can do (if they can get past metalink) is serving old snapshots | 10:58 |
| geppetto | Anyone questions? | 11:00 |
| f13 | geppetto: do you know what clients have been tested with being presented a gpg signed repo? | 11:00 |
| f13 | both before and after a key import? | 11:00 |
| geppetto | only yum, that I know of | 11:01 |
| geppetto | You'd have to ask hughsie about PK ... in theory it should work if he has package keys importing working, and the codes been in yum for a few months ... but I wouldn't guarantee it's tested | 11:02 |
| f13 | yeah, we'd need extensive testing to enable this for F10 | 11:03 |
| geppetto | yum-updatesd probably does the right thing (ie. nothing), when it doesn't have the key ... but I'm not sure that's been explicitly tested either | 11:03 |
| geppetto | f13: Oh, yeh ... my understanding was that it was going to be metalink only for F10, and signed repos. for F11 and maybe F10 later when it's tested | 11:04 |
| f13 | ah ok. | 11:05 |
| geppetto | Well, generating the signatures for F10 later ... the config. wouldn't/couldn't be changed | 11:05 |
| f13 | skvidal was pushing to see it happen in F10 (it == gpg signed repodata) | 11:05 |
| geppetto | You sure that isn't just "generating the signatures server side" ... but not actually enabling the config. by default for F10? | 11:05 |
| f13 | geppetto: not 100% | 11:07 |
| f13 | ok, if there is nothing else, I'll close the meeting. | 11:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!