Ditching OpenPGP, a new approach to signing APT repositories
I took a look at the design and think there are a few issues with the format as proposed.<p># The public key is stored with the signature.<p>This should be stored separately. A public key found here is too tempting to use, rendering the signature worthless. Authenticating it would be OK, but low value. This is unauthenticated. A &quot;key ID&quot; should be used instead if the intention is to support lookups among multiple keys.<p># The algorithm is stored with the signature.<p>This is slightly less bad than above, but still bad. Attacker-controlled algorithms have been used repeatedly in &quot;downgrade&quot; attacks. Agility is bad, but if you must support multiple algorithms, store this with the public key (somewhere else). Some info here: <a href="https:&#x2F;&#x2F;github.com&#x2F;secure-systems-lab&#x2F;dsse&#x2F;issues&#x2F;35" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;secure-systems-lab&#x2F;dsse&#x2F;issues&#x2F;35</a><p>I didn&#x27;t look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is &quot;offline&quot;. But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself.<p>Using minisign&#x2F;signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (<a href="https:&#x2F;&#x2F;theupdateframework.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;theupdateframework.io&#x2F;</a>) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for.