From FedoraProject

Jump to: navigation, search

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 2.7 by Marius Gedminas - find it at!