On Saturday, October 11th, 2025 at 2:54 PM, Marek Marczykowski-Górecki <[email protected]> wrote: > While I understand your concern, TBH I'd expect EOL keys to be destroyed > not long after they are not needed anymore. But also, I don't really see > a risk in keys handling that would apply to EOL keys but not the current > ones - build infrastructure is the same, they don't setup separate > instances for different versions. > > [...] > > As listed above, option 1 is not really possible. > While option 2 technically might be possible, it would put quite a bit > of load on our infrastructure (repository size for our server and all > mirrors). > Right now repository is already almost 1TB (in large part thanks to > templates, but firmware and kernel packages take also significant role). > Another several hundreds of GB per release is an issue. > > In the past we did something else - we frozen repository metadata (which > includes hashes of all packages): > https://github.com/QubesOS/qubes-builder-rpm/pull/97 > But we did it not because we were afraid about key compromise, but > because qubes-builder used package manager from inside chroot (so, for > dom0 packages - the one that is EOL) to download packages as build > dependencies. The issue doesn't apply to live qubes instance (thanks to > updatevm, and rpmcanon tool doing verification before feeding packages > to dom0's dnf), and also builderv2 doesn't do that anymore either.
The frozen repository metadata approach is a much more sane one than what I suggested. And the metalinks seem to be designed with "rogue mirrors" in mind, which is precisely the case. The only downsides I can think of are: 1. mirrors would be hard-coded into the file 2. This verification could only happen in the updateVM, given that the logic on dom0's side purposely deals only with packages verification and installation. If we wanted to make this a dom0 check, it would be further exposing its dnf call to further untrusted input, which is probably undesirable. 3. The pinning hashes of update files, adds another failure point to system updates, should there ever be an unforeseen need to distribute a new package version in the EOL repos. This would be beyond the Qubes team's control and there would need to be a way to recover from this situation and avoid manually editing the hashes to work around the issues. But overall it's a more elegant approach that what I had suggested. However, from your comments my understanding is that the key management expectations from EOL keys is viewed the same level of risks as non-EOL keys. Therefore that this is not a risk worth mitigating. Or would this be worth exploring further? Cheers, deeplow -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/85owDU8gfdfc8JE3McCIC3od0e6gFxUxMCZSE_E2eV5-ihoZZ7qIQZkEaMSQIjF9qtVlp0fiL4iwg2PCuh-wYYZrbxgvTiKUJO6qz2dCoaQ%3D%40protonmail.com.
