Tomorrow I will be doing a talk at #FrOSCon about a project that I have been working on for a while: #Signstar - a secure signing environment based on @nitrokey's #NetHSM
https://programm.froscon.org/2024/events/3139.html
#FrOSCon2024 #Rust #RustLang #DigitalSigning #ArchLinux #OpenPGP #SecureBoot #Packaging #Automation #HardwareSecurityModule #HSM
The recording of my talk about the #RustLang based #signing solution for #ArchLinux from last week at #FrOSCon is available:
https://media.ccc.de/v/froscon2024-3139-boring_infrastructure_building_a_secure_signing_environment
The slides are hosted at https://pkgbuild.com/~dvzrv/presentations/froscon2024/
#OpenPGP #DigitalSignature #Signing #Rust #FrOSCon2024 #NetHSM
@dvzrv Just watched it, was an interesting talk.
I do have 1 specific question: you mentioned that N out of M build machines need to repro identical artifacts for automatic deployment. Why not M out of M and when that isn't the case fall back to manual intervention?
Seems a bit weird to just kinda ignore the ones where the repro wasn't identical. (I do know that currently a decent chunk of packages aren't reporducible, but I am not talking about those)
@NekkoDroid thanks!
FWIW, the threshold signing is something we won't be able to do nearterm.
In that case n out of m refers to the number of future build machines. If we have m (let's assume e.g. four) in total, we would only need n (e.g. two out of four) to verify our reproducibility assumption.
Going for m out of m is somewhat an economical question (e.g. rebuilding QEMU is costly and takes time), but also one of usefulness (do we need more than one or two validations?).
@dvzrv makes sense, I thought M referred to the amount of systems where the build for package X was run on and only N of those needed to agree on the repro status.
Having 3 for smaller and 2 for larger ones make sense, as with the larger ones it's more likely that something is gonna differ
David Runge
Nekko
Nitrokey