Code signing is not equal to code signing. There are a lot of differences between different code-signing strategies, many of which are often overlooked.
Example: I. Typical Windows case 1. Third-party developer gets a key from a CA. 2. Third-party developer signs a program binary. 3. The user obtains the program. 4. The signature is checked at execution time. 5. The signature has to be secure for many years if not decades. 6. The user has to figure out whether he has the latest version. 7. Revocation is an unreliable mess. One could even say that this strategy of code signing is literally useless, because malware can always just exploit a signed binary of an outdated version with known vulnerabilities. II. Typical Debian case 1. Debian developer signs source tarballs and upload them 2. The signature only has to be secure until the code lands in the FTP 3. Debian builds the binary packages 4. Debian creates Release files with hashes of the packages 5. The Release file is signed by Debian APT keys 6. The signature has to be secure until the next Release file 7. Security updates have a separate Release file with expiration time This strategy effectively prevents attackers from injecting outdated programs with known vulnerabilities into the updates. Even mirrors cannot do that. TLS for mirrors is not required for integrity and authenticity. Secure Boot is a different issue. From the security vulnerabilities which are being published, it looks to me that it has the same problem with malware exploiting vulnerable binaries with valid signatures. Regards Stephan PS: Another related discussion is about very old package uploads and the corresponding (expired, inactive, weak, etc.) developer signatures. https://lists.debian.org/debian-devel/2023/12/msg00000.html
signature.asc
Description: This is a digitally signed message part
