Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 8587 bytes --]

On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote:
> Another example for something that was not thought to the end and which 
> was rushed and pushed to our users.

You start this mail with an insult to me.  Why do you keep doing this?
 Do you feel that there is some special need for you to try to diminish
me in order to reach your goal?

>  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.

It would be nice if you could lead your argument in another way than
'see, public, he must be wrong, he does not understand what he is
doing!'

> 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.

Thank you for coming back to the point.  I understand that an important
point in every argument is to include a lot of text but our (readers!)
time is limited.

> 
> 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.

This sounds like 'perfect is the enemy of good'.  If we can't get this
done perfectly good, we should just lie down and do not put any effort
into making things better.

> 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?

Is this question to me or to the public?  Because if it's to me, then
yes, I've noticed I couldn't use HTTPS there.  I'm sorry, I'm not
as incompetent as you'd repeatedly trying to prove, you won't win your
argument this way.

> 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?

What's the alternative?  Ignoring upstream signatures entirely unless we
can securely fetch the key?  Shoving the problem under the carpet
and assuming that the developer will have safely set up the key on his
devbox while being totally incompetent at putting it in an ebuild?

Yes, again, this is not perfect.  It was never supposed to be.  It's
better than what we had before (local solutions).  Keeping the key
relatively correct via ebuild is easier than keeping it on multiple
machines used for development.

> 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.

Theories are all nice but do you have any proof of that?  Preferably one
that involves developers who *actually carefully* checked distfiles.
 Because my theory says developers don't have infinite time to audit
everything.

> 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.

Are you arguing that we should remove commit signatures as well?  Or
does it happen that with roughly the same technology and the same
people, one layer is secure and another similar layer is totally
bonkers?

> The purpose of this email is to get this addition removed ASAP.

Why do you claim to have the power to removed somebody's work just
because it doesn't fit your view of the world?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]