Hi, I am really unhappy with this addition.
Another example for something that was not thought to the end and which was rushed and pushed to our users. Sorry for being late to this but any addition should really add a benefit. What is the benefit verify-sig is adding?
When mgorny started to propose this in #-qa, he used the argument to improve security of Gentoo because we cannot know if every Gentoo developer is really verifying distfiles or just copying ebuild to new version and let `repoman commit` fetch the distfile and be done with the bump. While I agree with the idea in general, i.e. when you would be able to provide an automatism for that, that would be a great addition.
But there is a problem. You cannot automate trust.And anyone who is trying to do that shows that he/she does not understand how signing works and because of the fact he/she will claim security was improved, security was actually lowered due to that.
How is that?Because the statement you can get from a signature depends on the trust in the used key. I.e. you assume that the key used to create that signature is only accessible by the designated owner and that nobody else have access to it. In the moment you learn that somebody else gained access to that key, i.e. can create signatures using the same key, you can no longer trust that key. More important, you should start questioning previously seen signatures (if you take it serious you will distrust any files signed by that key and demand on a new signature with a new key where you managed to establish a new trust).
Short excerpt:Code signing is nothing new. It is an important layer in Microsoft’s security defense. Even Apple is relying on signatures for their sandbox they introduced some years ago. But does a signature prevent anything? Of course not. StuxNet was signed with a valid signature from Realtek Semiconductor Corp. and switched later to a signature which belongs to JMicron Technology Corp when Realtek’s signature got revoked. A post-mortem analysis suggested that cybercriminals compromised both organizations and have stolen their development certificates, including the private keys used to sign the executables. In 2014, when Sony Pictures got hacked, attackers had signed the malware with valid certificates from *Sony*. But that is only the tip of the iceberg, see https://attack.mitre.org/techniques/T1553/002/ for more examples. My point here is, and I believe we all agree on this, that signatures alone are meaningless.
To add a meaning to signatures you must trust the signer that he/she will immediately revoke the certificate once he/she gets aware that an unauthorized third party gained access to the certificate. If we, for an unknown reason, assume that this will happen, we will face another problem: We must receive this information. If we do not know that something has happened to the key, we will not take any actions. I guess you all still remember how you created your GPG key for Gentoo, don’t you? Do you still have access to the revocation certificate you created during that process? I am sure you do. But do you know how this process works? Right, you need to upload that certificate to a key server. But then 2019 happened. Key servers are dead now. You can no longer rely on key servers, especially not that once you have uploaded your revocation certificate that it will spread and reach users. Just do an easy exercise: Check who committed to Gentoo repository in past 6 months. Now try to fetch the GPG key of all committers without using *.gentoo.org. Good luck! And no, WKD cannot help you with that (revocation).
Coming back to my initial statement that it is all about automatization.The whole idea started with assumption that not every developer will verify the distfile (an assumption I share). But why should we trust these developers that they will keep an eye on upstream’s used certificate instead? That does not make any sense for me.
Another point I just want to mention was patch 5 of 6 for net-libs/miniupnpc. Did you notice that the ebuild will fetch public key via HTTP instead of HTTPS? This will create a chicken-egg problem here: We will record key information metadata the same way we store information about distfiles which is temper proofed. But because this is happening in an automatic way there is not just a theoretical chance that we will store an attacker’s key in our metadata because who is going to verify they key? The same developer we distrust (or where we just want to avoid to trust) that he/she verified the distfile?
Do you see the contradiction?Please do not get me wrong. I like the idea. But I also understand that you cannot implement it in a secure and really working way -- you will always require a human paying attention. But now that we pretend, we managed to implement that and even show a fancy green message that we verified (any) signature, we actually lowered security because more people will now stop paying attention:
- Previous developers who carefully checked distfiles will stop
doing that.
- Nobody will question anything because there is a new passed
check.
In worst case scenario, we are now emerging a signed malicious package
we could be aware of if some human would have checked upstream and
noticed that release key was revoked. But this will not happen anymore
because we rely that once we have recorded a key in the metadata that
some system will tell us in case there is a problem. And what do you
expect what will happen when after the download something will tell us
“Oh, this file is not signed with currently known key”? Right, that
developer who we do not want to trust that he/she verified the distfile
will just add a reference to the new matching key which will silence any
warning.
No, sorry. Security required education. You need to understand where security is depending on so that you know when you need to take action. Every attempt to move this away from the user will actually add needless complexity, allow for new attack vectors and will not improve security.
The purpose of this email is to get this addition removed ASAP.PS: I assume that the "Arch Linux is using something similar" argument will appear. I am not going to make an in depth statement about what Arch Linux is doing here. But they have a total different security model which you have to take into account. And please don't forget that we already have that working Manifest mechanism which isn't promising anything it cannot do.
-- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
OpenPGP_signature
Description: OpenPGP digital signature
