15:30:46 #startmeeting 15:30:46 Meeting started Mon Mar 31 15:30:46 2014 UTC. The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:30:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:30:54 #meetingname releng 15:30:54 The meeting name has been set to 'releng' 15:31:29 #chair dwa tyll_ masta nirik sharkcz 15:31:29 Current chairs: dgilmore dwa masta nirik sharkcz tyll_ 15:31:42 #topic roll call 15:31:47 who is here? 15:32:03 I am 15:32:16 hey bochecha 15:32:38 morning 15:33:17 * masta is here 15:33:50 not seen peep from dwa today 15:35:26 #topic tickets https://fedorahosted.org/rel-eng/report/10 15:35:51 https://fedorahosted.org/rel-eng/ticket/5854 15:35:56 masta: any update? 15:36:34 dgilmore: honestly I completely forgot about that ticket. I can just knock it out, it's very easy 15:36:57 sry for the bad but honest answer 15:37:05 masta: no problem 15:37:25 https://fedorahosted.org/rel-eng/ticket/5362 15:37:33 I have no update on this one either 15:37:42 it would be nice to get it done. ;) 15:37:59 yeah, need to sit down and sort it out this week 15:38:08 at least to see what it will give up 15:38:10 us 15:38:15 https://fedorahosted.org/rel-eng/ticket/5870 15:38:34 nirik: so this is likely a long time project 15:38:52 yeah. 15:39:01 I didn't think we would solve it in 5minutes. ;) 15:39:13 Hi all 15:39:18 hey tyll_ 15:40:06 ideally, we would get sigul to grow support for unattended signing (that it could lock down via ip at least and possibly some other means) 15:40:14 yeah 15:40:23 maybe a ssl key for auth 15:40:30 failing that we would run another thing that just does these types of signing. 15:40:42 for koji and copr 15:40:44 as I mentioned in the ticket, that's what we've done at $dayjob (a signing server simpler than sigul though, but ip-locked) 15:41:11 if we auto sign the rpms, we likely will need to sign manually repodata 15:41:17 I'd say let them be signed with an uncontrolled key... not to imply a lack of security.... but something we automate 15:41:21 I definitely don't want the private key or passphrase on the hub. 15:41:27 which will put a manual step at the end of compsoses and psuhes 15:42:05 nirik: maybe a fedmsg listener, that does it elsewhere 15:42:07 obs-signd may be an ok option. I can ask security folks to look at it... 15:42:20 i know nothing about it 15:42:30 dgilmore: yeah, thats an option too 15:42:45 i like the fedmsg idea 15:43:26 #topic ticket 5870 rawhide signing 15:43:32 nirik: that way we can at least do it on a locked down box that is not publicly available 15:43:37 #info don't want the private key or passphrase on the hub 15:43:40 dgilmore: true. 15:43:49 there would be a race then tho 15:43:56 indeed 15:44:02 build something right before rawhide compose, might not get signed in time 15:44:29 two ways to deal with it 15:44:46 we culd have buildrawhide make sure everything is signed 15:45:01 or we add a slight delay 15:45:10 and tag into a holding tag 15:45:13 so if we signed all rawhide builds with a rawhide key, what happens at branched? we resign with FN key and each package has 2 signatures/rpms written out? 15:45:17 then move when its signed 15:45:34 +! slight delay 15:45:48 we have talked about a pending tag before... would allow some place to gate. 15:46:11 nirik: well we could resign,or we just sign with the next fedora key 15:46:25 we will make a f22 key at f21 branching 15:46:51 rawhide going forward at that point could be signed with the f22 key 15:47:16 ok, then in that model there isn't a rawhide key, we just sign it with the key for the next fedora when it was built? 15:47:34 yep 15:47:38 that may not work on new installs, wouldn't import the older keys? 15:48:00 we would need to make sure that it can have both 15:48:20 well, there may be even older at some point... 15:48:28 other option is to sign everything in rawhide at branching with the next fedora key 15:48:35 for things that faill mass rebuild that we keep shipping 15:49:32 I guess I prefer that, but I'm not sure fully why. ;) 15:49:47 we could address the old rpms at branching by resigning them 15:49:58 it might make it more clear when/fromwhat you installed something. 15:50:06 at branching we will need to make sure everything is signed with the release key 15:50:26 #info at branching we will need to make sure everything is signed with the release key 15:50:42 making sure that rawhide has access to and can import 2 keys should be doable 15:51:02 for instance right now f20 and f21 keys 15:51:33 yeah, but once we go to f22 there may be stuff that fails mass rebuild and is still f20, so for f22 we still might need the f20 key, etc... 15:51:42 nirik: no 15:52:00 nirik: this would be fixed by re-signing everything when branching 15:52:03 nirik: we would need to make sure at branching everything is signed with the f21 key like we do today 15:52:07 ah I see. ok. 15:52:15 #info < dgilmore> making sure that rawhide has access to and can import 2 keys should be doable 15:52:32 so, at branch, f21 gets all f21 signed and rawhide gets all f21 signed from there, but f22 after that? 15:53:08 or rawhide always has a rawhide key? 15:53:32 right 15:53:48 I do not think we ever have a rawhide key 15:53:52 signing rawhide with the F22 key is less effort, because not every RPM needs to be re-signed 15:54:09 just have a key for the next release 15:55:01 so if we can automate signing rawhide with the next branch key, can we do the same for non-rawhide builds? 15:55:10 but then that requires sigul be used right? 15:55:24 #info at branch, f21 gets all f21 signed and rawhide gets all f21 signed from there, but f22 after that 15:55:53 ie, if sigul has the f21 key in it, it has to be used to sign you can't use signd or something else... 15:57:19 nirik: right 15:57:25 so, if we wanted to use another service (signd or whatever) we would need to have a seperate key 15:58:13 not necessarily 15:58:23 you can import keys into sigul 15:58:40 but that does kinda defeat part of its purpose 15:58:45 yeah. 15:59:35 so, let me do this: 15:59:55 I'll talk with threebean about fedmsg and triggering signing from it, see if there's concerns there. 16:00:10 okay 16:00:22 I'll also ping mitr and see if there's any chance for sigul work this year... and how hard it would be to add a way to allow non passphrase/unattended. 16:00:29 at the least I think doing that we can secure the signing process 16:00:32 #action nirik will talk with threebean about fedmsg and triggering signing from it, see if there's concerns there. 16:00:47 #action nirik will ping mitr and see if there's any chance for sigul work this year... and how hard it would be to add a way to allow non passphrase/unattended 16:00:56 * nirik nods. 16:01:00 may be some other way for us to get build notifications 16:01:24 at the least we can look into feasability 16:02:53 anything anyone else want to add here> 16:02:54 ? 16:03:30 Did you notice that I mentioned in the channel that there are GPG smart cards that can hold RSA 4096 bit keys? 16:03:48 This might be something cheap to get HSM like security 16:04:01 yeah, thats an option... we already use them for secure boot signing. 16:04:08 tyll_: we use some for signing the binaries for secure boot 16:04:53 ah, that's great 16:06:49 nirik: ill leave the meeting keyword on the ticket, we can follow up next week 16:06:54 sounds good. 16:07:01 talking to mitr in devel now too. ;) 16:07:10 #topic Secondary Arches: s390 16:07:19 no sharkcz 16:07:26 #topic Secondary Arches: ppc 16:07:36 dwa: ping, status update 16:07:52 he may not be here 16:09:02 #topic Secondary Arches: aarch64 16:09:10 aarch64 is getting there 16:09:15 its following rawhide 16:09:37 need to look at doing some nightly installer composes 16:09:38 the usual challenges, getting patched upstream 16:10:19 dgilmore: that would be nice, right now it wouldn't work but maybe a few more key builds it could 16:10:38 masta: would give us a list of things to fix 16:11:42 sure, I'll see what I can find out. 16:11:50 we are looking good to get a f21 release 16:11:55 okay 16:12:03 #topic mass rebuild 16:12:38 with the f21 schedule set and the gcc 4.9 change just proposed we need to look at when we will do a mass rebuild 16:13:15 there's still changes rolling in... 16:13:18 but yeah 16:13:39 https://fedoraproject.org/wiki/Releases/21/Schedule 16:14:07 https://fedoraproject.org/wiki/Changes/GCC49 16:14:19 there is already the extra security change in 16:15:02 dgilmore: do you want to create ticket to track potential mass rebuilds? 16:15:11 jreznik: we should 16:15:18 we have branching at no earlier than 2014-07-08 16:15:33 #info branching is no earlier than 2014-07-08 16:15:34 I was thinking about it when announcing that change... I'll do it 16:16:29 so we really want to make sure that the mass rebuild is done by June 9th at the latest 16:17:13 so we need to start in the next 7-8 weeks 16:17:34 #info we really want to make sure that the mass rebuild is done by June 9th at the latest 16:17:36 I want to get in on the mass rebuild action when it happens 16:17:50 gcc 49 release is the first half of april 16:17:53 maybe even fire it off, would be good trainning 16:18:00 masta: well the script that does it can only be run by one person 16:18:25 dgilmore: ah, ok then... as I expected =( 16:19:03 jreznik: im thinking that it would be good to get the mass rebuild done early may 16:19:09 nice and early 16:19:25 would give time to address the fall-out 16:20:09 aarch64 folks probably want to rush to get a few patches in prior to the mass rebuild 16:20:28 masta: well done my June 9th gives us 4 weeks for cleanup 16:20:28 seems like that new gcc should not be a big issue from what's written in change, so doable 16:21:55 right 16:22:13 need to make sure ppc64le and aarch64 are in good shape 16:22:49 and work out if there are any other changes needing a mass rebuild 16:22:56 then work out some scheduling 16:23:14 for the java change it was mentioned but not required 16:23:29 how much does sec mass rebuilds affects primary (except the stuff that has to be in?) 16:23:36 https://fedoraproject.org/wiki/Changes/Java8 16:24:18 mass rebuilds do not really accomodate specs needing changes other than nvr bumps 16:24:39 jreznik: just want to make sure that they have things they need in 16:26:02 anyway, we need a ticket and to track whats needed and when to do it 16:26:08 #topic open floor 16:26:18 does anyone have anything for open floorr? 16:26:19 dgilmore: https://fedorahosted.org/rel-eng/ticket/5877 16:26:29 jreznik: cheers 16:27:10 nada 16:27:21 dgilmore: obvious open floor question is next - today I was asked by Christian, how they can officially produce initial WS composes snapshots 16:27:44 jreznik: they cant 16:28:02 about the lookaside hashing, last meeting we decided to talk about it on the list, but there hasn't been much talk on it :-/ 16:28:06 jreznik: we do need to work out exactly how we will compose things 16:28:13 see my email... I think it's a bit premature, as I don't see much content being even set for products but would be nice to be at least somehow ready by that time 16:28:20 #info next meeting will be 2014-04-07 15:30 UTC 16:28:35 dgilmore: yeah, that's that "I don't see much content being even set for products" 16:28:53 jreznik: i have setup kickstarts for each product 16:29:44 I need to send the Workstation folks an email about their deliverables 16:30:38 its still not clear to me what all the deliverables will be 16:31:13 and I'll ping Christian to really reply to it 16:32:35 cheers 16:32:56 bochecha: we do need to make a plan for it 16:33:53 dgilmore, a plan for the migration? 16:33:59 bochecha: yes 16:34:11 the thing is, last week there wasn't even a consensus on which hash(es) to use, how many,... 16:34:31 bochecha: well sha256 or sha512 16:34:41 that seems like it would need to be discussed before a plan 16:35:09 weither we make hardlinks for other hashes I dont care to much, there is some but very minimal use cases for them 16:35:22 id prefer sha512 16:35:49 me too, as that's what I had sent patches for (i.e less work :P) 16:36:39 for the migration plan, would it help if I sent something to the list about how I saw it when I made the patches, and so the path that the patches allow? 16:37:36 bochecha: having a proposal helps getting it discussed 16:39:01 alright, I'll try and do that this week then :) 16:39:01 i agree with tyll_ here 16:40:25 #action bochecha to send in a proposal for lookaside cache migration 16:40:32 anything else? 16:41:00 nothing from me 16:41:11 nothing here 16:41:18 #endmeeting