16:30:10 #startmeeting fedora_coreos_meeting 16:30:10 Meeting started Wed Jun 5 16:30:10 2019 UTC. 16:30:10 This meeting is logged and archived in a public location. 16:30:10 The chair is bgilbert. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:10 The meeting name has been set to 'fedora_coreos_meeting' 16:30:17 #topic roll call 16:30:18 .hello2 16:30:21 .hello2 16:30:23 bgilbert: bgilbert 'Benjamin Gilbert' 16:30:25 slowrie: slowrie 'Stephen Lowrie' 16:30:26 .hello redbeard 16:30:26 .hello2 16:30:28 red_beard: redbeard 'Brian 'redbeard' Harrington' 16:30:31 ajeddeloh: ajeddeloh 'Andrew Jeddeloh' 16:30:42 .hello2 16:30:43 jlebon: jlebon 'None' 16:30:46 .hello2 16:30:47 yzhang: yzhang 'Yu Qi Zhang' 16:30:52 .hello mnguyen 16:30:53 mnguyen_: mnguyen 'Michael Nguyen' 16:31:05 geoff-: Geoff Levand 16:31:42 .hello2 16:31:43 dustymabe: dustymabe 'Dusty Mabe' 16:32:23 .hello lucab 16:32:24 kaeso[m]: lucab 'Luca Bruno' 16:33:16 #chair slowrie red_beard ajeddeloh jlebon yzhang mnguyen_ geoff- dustymabe kaeso[m] 16:33:16 Current chairs: ajeddeloh bgilbert dustymabe geoff- jlebon kaeso[m] mnguyen_ red_beard slowrie yzhang 16:34:08 #info Reminder that we're switching the meeting format back to only meeting tickets + open floor 16:34:11 #link https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/thread/4YZSH5NFDPRIXAAL45RRMI56ZVNM4IVP/ 16:34:26 #topic Action items from last meeting 16:34:32 None! 16:34:52 #topic Signing for release artifacts 16:34:55 #link https://github.com/coreos/fedora-coreos-tracker/issues/187 16:35:26 #info will be discussing this with infra tomorrow during their weekly meeting 16:35:37 #link https://github.com/coreos/fedora-coreos-tracker/issues/187#issuecomment-499160212 16:36:13 dustymabe, did you want to discuss the details further here? 16:36:29 bgilbert: i'm happy to, yep 16:36:48 just wanted to throw that out there so that people who are interested can come to that discussion with infra team 16:37:13 summary: 16:37:37 we have a few options for signing FCOS artifacts detailed in https://github.com/coreos/fedora-coreos-tracker/issues/187#issuecomment-497090284 16:37:57 there has been some discussion in the ticket on preferences 16:38:02 .hello2 16:38:03 rfairley: rfairley 'None' 16:38:16 some votes for option `4.` and some for option `1.` 16:38:37 * red_beard goes to re-read the ticket 16:38:52 we're going to discuss with infra tomorrow to see if there are limitations that will cause us to not be able to do option `1.` 16:38:52 i'm curious how much that splits along the lines of experience with #4 16:38:55 #chair rfairley 16:38:55 Current chairs: ajeddeloh bgilbert dustymabe geoff- jlebon kaeso[m] mnguyen_ red_beard rfairley slowrie yzhang 16:39:44 * dustymabe waits for people to read ticket and bring forth any discussion 16:40:48 red_beard: I'm interested in your opinion on those options 16:41:33 I still prefer 1, but if we can't do that I think I prefer 2 to 4, since it doesn't need --ignore-missing 16:41:40 well, let's be clear about my bias. I had done multiple evaluations of sigil and said "nope" which is why i invested multiple years of political capital into building fero. 16:42:08 personally, my opinion is as follows 16:42:17 if a user is having a hard time, it's a bug. 16:42:35 so i'd rather bear the brunt of the pain, and feel the motivation to fix it 16:42:40 rather than just kicking the can down the road 16:43:12 16:43:29 for reference, the "size issue" from the ticket with fero is just due to the grpc implemenation (and grpc max message size) 16:43:42 red_beard: +1 16:43:46 red_beard: is that an endorsement for 1. then? given that it's the easiest for users 16:43:46 which, to that point, also exists with sigil. 16:44:28 and the point of the optimization with fero was to minimize the _duplicated_ transmitting of content 16:44:46 so that you could even participate in the signing quorum from a low bandwidth place 16:45:14 ...after downloading the artifact to devsign it :-) 16:45:34 sure, but at least you don't have to re-upload it 16:45:37 right 16:46:03 also, actually participating in proper M/N signing 16:47:38 for context here, and red_beard and I have discussed this offline, I don't think there's much point in signing FCOS releases with fero 16:48:06 since we're constructing FCOS from koji-built packages not signed with M/N 16:48:09 correct, it's more about prior art on a specific ideology 16:48:38 sure 16:48:49 making this more concrete, I'll second jlebon's question 16:49:06 what user-facing signature model do you think makes the most sense? 16:49:23 sorry, i missed jlebon. yes, consider me a +1 for option 1 (sign the artifact itself and deliver detached signature) 16:49:46 red_beard: +1 16:51:09 other thoughts from folks? geoff- maybe? 16:51:44 are there any concerns around performance for users? how much more expensive is verification vs e.g. sha256sum? 16:52:13 the thing being RSA-signed is also a hash 16:52:19 so it comes down to libgcrypt's implementation of hash functions 16:52:25 I think it'd be dwarfed by DL time unless it's truly abysmal 16:52:26 I haven't looked in a decade, but they used to be very slow 16:52:28 bgilbert +1 16:52:35 but also what ajeddeloh said 16:52:47 something like coreos-installer should be doing streaming verification 16:52:51 +1 16:53:08 maybe #1 16:54:26 dumb question.. does the public key need to be present to verify? 16:54:33 yes 16:54:40 i.e. would `gpg --verify` need net access? 16:54:48 it'd need the pubkey 16:54:54 but that's true anyway 16:55:06 if you want to do a content verification without checking the sig 16:55:18 then the hashes will be available in the stream metadata 16:55:21 yeah I could think of a disconnected env 16:55:22 or presumably on the website 16:55:35 ahh you mean sha256sum hashes / 16:55:37 ? 16:55:38 yeah 16:55:40 +1 16:55:52 that should be good then 16:58:19 I had the thought that the website could even present a CHECKSUMS file for download 16:58:28 which is synthesized client-side from the stream metadata 16:58:33 "download" 16:58:59 not sure if that's the right affordance from a security perspective 16:59:00 and the user is good with that because SSL ? 16:59:17 yeah, and the stream metadata could be centralized but artifacts could come from the mirror network 16:59:21 it's not as good as a full verification 16:59:25 but some folks won't do that anyway 16:59:36 "full verification" meaning signature check 17:00:08 not arguing for it especially 17:00:40 (sorry I need to drop offline a bit) 17:01:10 any other discussion on artifact signing? 17:02:17 #topic Open Floor 17:05:07 countdown? 17:05:18 60 seconds 17:05:30 * jlebon starts making sandwich 17:05:41 * ajeddeloh listens to "The Final Countdown" 17:06:04 * bgilbert closes fueling valves on the rkt 17:06:20 * red_beard drops a mic 17:06:22 #endmeeting