19:58:27 <waldi> #startmeeting
19:58:27 <MeetBot> Meeting started Fri Jan 11 19:58:27 2019 UTC.  The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:58:27 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:58:44 <waldi> ScottK: i heard you
19:58:46 <waldi> someone else?
20:00:28 <ScottK> \o
20:21:37 <waldi> #topic weboob
20:22:31 <waldi> #info https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914179
20:26:46 <waldi> we discussed the package and one of the FTP Masters will process the bug
20:28:03 <lfaraone> #topic secure boot
20:28:13 <waldi> #chair lfaraone
20:28:13 <MeetBot> Current chairs: lfaraone waldi
20:28:25 <waldi> #topic secure boot
20:28:40 <lfaraone> ansgar: I've lost state on this, mind summarising current blockers?
20:30:51 <ansgar> lfaraone: I think some people (Sledge) wanted to test it.
20:31:22 <ansgar> Then we can switch to the production keys; running the cron service automated is some more work (but not a blocker for enabling secure boot for Stretch)
20:31:36 * Sledge is testing right now, in fact
20:31:52 <lfaraone> Perfect! Yeah, just caught up in -efi :)
20:32:01 <Sledge> I have d-i and debian-cd patches ready so we have working installation media and netboot stuff
20:32:06 <Sledge> I'll get live media next
20:32:08 <waldi> ansgar: do we have a decision on how to signal trusted keys?
20:32:26 <ansgar> waldi: What do you mean?
20:33:21 <waldi> ansgar: the kernel package trusts a built-in key, currently the test-key. do we have an agreement how to signal this to the signer to not provide a trust-chain from production to test key?
20:33:58 <ansgar> waldi: Ah, I wanted to implement bwh's suggestion.  linux was the only package that embeds a key though AFAIU
20:34:07 <waldi> okay
20:34:21 <ansgar> (And it could technically not do that; Ubuntu's solution doesn't require a key embedded in linux)
20:34:28 <ansgar> (But we can change that later.)
20:34:56 <waldi> ubuntu's solution is disgraced by almost everyone. they just don't check any signature downstream
20:35:08 <ansgar> They do check signatures.
20:35:35 <ansgar> They just trust the same set of keys for signing kernel modules as for signing UEFI binaries (by asking UEFI for the set of trusted roots)
20:39:56 <waldi> and i found this: "Build time autogenerated kernel key"
20:41:06 <waldi> #agreed ansgar will implement trusted key vectors as suggested by bwh
20:43:22 <waldi> i wonder how canonical handles their certificates, if you find "OpenSSL Generated Certificate" from the config template in them
20:44:12 <waldi> #topic Any other business
20:44:23 <ansgar> We need to generate new keys :>
20:44:54 <ansgar> And look at key sharding (how many shares, who gets them, ...)
20:45:49 <waldi> do we generate a desaster recovery key at the same time?
20:47:02 <ansgar> waldi: An extra set of keys that are not used in production and stored encrypted somewhere?
20:47:16 <waldi> yes
20:47:26 <ansgar> I guess we could look at doing that too.
20:48:47 <ansgar> We can discuss on the BTS; there is a bug asking for the new keys, let me look for it.
20:50:24 <ansgar> Ah, there is https://bugs.debian.org/917535 against debian-archive-keyring.
20:51:12 <waldi> #info https://bugs.debian.org/917535
20:51:34 <waldi> okay. anything else?
20:52:15 <ScottK> Are there any thoughts about moving non-release archs to ports?
20:52:38 <ansgar> We wanted kfreebsd-* and hurd-i386 to move there; I'm not sure what the status is.
20:52:45 <Ganneff> humm
20:52:55 <waldi> Es hummt!
20:52:58 <ScottK> Any reason powerpc shouldn't go too?
20:53:00 <Ganneff> guess i got it an hour wrong in my calendar
20:53:17 <ansgar> ScottK: powerpc is already there.
20:53:24 <waldi> Ganneff: me too. i just fixed that today. timezones are a bitch
20:53:25 <ScottK> That'd be a great reason.
20:53:47 <Ganneff> waldi: no, only that people use ones different to mine
20:54:25 <ScottK> That would also explain why I haven't seen any powerpc stuff in the cruft report for awhile (not that I noticed)
20:54:50 <ansgar> Oh, I had a new idea:
20:55:02 <ansgar> Remove out-of-date binaries automatically.
20:55:49 <waldi> after a week? a month?
20:55:52 <ScottK> After the testing freeze, I think it'd make sense to do that until release.
20:56:09 <ansgar> More a month or so probably.
20:56:19 <waldi> that makes sense
20:56:22 <ansgar> firefox    | 47.0.1-1      | unstable       | source, kfreebsd-amd64
20:56:33 <ansgar> But really: such ancient things should not stay there...
20:57:11 <ScottK> That would probably clean up 90% of the cruft report.
20:57:48 <waldi> and regardless of breakages?
20:58:00 <ansgar> Maybe start with only removing leaf packages.
20:58:30 <ScottK> If you remove the leaf packages, the current auto removals should pick up the rest.
21:00:07 <ScottK> For example, there's an old libevent being kept around by firefox (and some other leaf packages)
21:03:31 <waldi> #action ansgar want's to explore automatic removal of out-of-date packages
21:03:57 <waldi> anything else?
21:05:56 <ansgar> Nothing more for ftp stuff from me :>
21:06:18 <waldi> okay. thank you for your time
21:06:22 <waldi> #endmeeting