1 |
On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote: |
2 |
> Another example for something that was not thought to the end and which |
3 |
> was rushed and pushed to our users. |
4 |
|
5 |
You start this mail with an insult to me. Why do you keep doing this? |
6 |
Do you feel that there is some special need for you to try to diminish |
7 |
me in order to reach your goal? |
8 |
|
9 |
> Sorry for being late to this but any |
10 |
> addition should really add a benefit. What is the benefit verify-sig is |
11 |
> adding? |
12 |
> |
13 |
> When mgorny started to propose this in #-qa, he used the argument to |
14 |
> improve security of Gentoo because we cannot know if every Gentoo |
15 |
> developer is really verifying distfiles or just copying ebuild to new |
16 |
> version and let `repoman commit` fetch the distfile and be done with the |
17 |
> bump. While I agree with the idea in general, i.e. when you would be |
18 |
> able to provide an automatism for that, that would be a great addition. |
19 |
> |
20 |
> But there is a problem. |
21 |
> |
22 |
> You cannot automate trust. |
23 |
> |
24 |
> And anyone who is trying to do that shows that he/she does not |
25 |
> understand how signing works and because of the fact he/she will claim |
26 |
> security was improved, security was actually lowered due to that. |
27 |
|
28 |
It would be nice if you could lead your argument in another way than |
29 |
'see, public, he must be wrong, he does not understand what he is |
30 |
doing!' |
31 |
|
32 |
> How is that? |
33 |
> |
34 |
> Because the statement you can get from a signature depends on the trust |
35 |
> in the used key. I.e. you assume that the key used to create that |
36 |
> signature is only accessible by the designated owner and that nobody |
37 |
> else have access to it. In the moment you learn that somebody else |
38 |
> gained access to that key, i.e. can create signatures using the same |
39 |
> key, you can no longer trust that key. More important, you should start |
40 |
> questioning previously seen signatures (if you take it serious you will |
41 |
> distrust any files signed by that key and demand on a new signature with |
42 |
> a new key where you managed to establish a new trust). |
43 |
> |
44 |
> Short excerpt: |
45 |
> Code signing is nothing new. It is an important layer in Microsoft’s |
46 |
> security defense. Even Apple is relying on signatures for their sandbox |
47 |
> they introduced some years ago. But does a signature prevent anything? |
48 |
> Of course not. StuxNet was signed with a valid signature from Realtek |
49 |
> Semiconductor Corp. and switched later to a signature which belongs to |
50 |
> JMicron Technology Corp when Realtek’s signature got revoked. A |
51 |
> post-mortem analysis suggested that cybercriminals compromised both |
52 |
> organizations and have stolen their development certificates, including |
53 |
> the private keys used to sign the executables. In 2014, when Sony |
54 |
> Pictures got hacked, attackers had signed the malware with valid |
55 |
> certificates from *Sony*. But that is only the tip of the iceberg, see |
56 |
> https://attack.mitre.org/techniques/T1553/002/ for more examples. My |
57 |
> point here is, and I believe we all agree on this, that signatures alone |
58 |
> are meaningless. |
59 |
> |
60 |
> To add a meaning to signatures you must trust the signer that he/she |
61 |
> will immediately revoke the certificate once he/she gets aware that an |
62 |
> unauthorized third party gained access to the certificate. If we, for an |
63 |
> unknown reason, assume that this will happen, we will face another |
64 |
> problem: We must receive this information. If we do not know that |
65 |
> something has happened to the key, we will not take any actions. |
66 |
> I guess you all still remember how you created your GPG key for Gentoo, |
67 |
> don’t you? Do you still have access to the revocation certificate you |
68 |
> created during that process? I am sure you do. But do you know how this |
69 |
> process works? Right, you need to upload that certificate to a key |
70 |
> server. But then 2019 happened. Key servers are dead now. You can no |
71 |
> longer rely on key servers, especially not that once you have uploaded |
72 |
> your revocation certificate that it will spread and reach users. Just do |
73 |
> an easy exercise: Check who committed to Gentoo repository in past 6 |
74 |
> months. Now try to fetch the GPG key of all committers without using |
75 |
> *.gentoo.org. Good luck! And no, WKD cannot help you with that (revocation). |
76 |
> |
77 |
> Coming back to my initial statement that it is all about automatization. |
78 |
|
79 |
Thank you for coming back to the point. I understand that an important |
80 |
point in every argument is to include a lot of text but our (readers!) |
81 |
time is limited. |
82 |
|
83 |
> |
84 |
> The whole idea started with assumption that not every developer will |
85 |
> verify the distfile (an assumption I share). But why should we trust |
86 |
> these developers that they will keep an eye on upstream’s used |
87 |
> certificate instead? That does not make any sense for me. |
88 |
|
89 |
This sounds like 'perfect is the enemy of good'. If we can't get this |
90 |
done perfectly good, we should just lie down and do not put any effort |
91 |
into making things better. |
92 |
|
93 |
> Another point I just want to mention was patch 5 of 6 for |
94 |
> net-libs/miniupnpc. Did you notice that the ebuild will fetch public key |
95 |
> via HTTP instead of HTTPS? |
96 |
|
97 |
Is this question to me or to the public? Because if it's to me, then |
98 |
yes, I've noticed I couldn't use HTTPS there. I'm sorry, I'm not |
99 |
as incompetent as you'd repeatedly trying to prove, you won't win your |
100 |
argument this way. |
101 |
|
102 |
> This will create a chicken-egg problem here: |
103 |
> We will record key information metadata the same way we store |
104 |
> information about distfiles which is temper proofed. But because this is |
105 |
> happening in an automatic way there is not just a theoretical chance |
106 |
> that we will store an attacker’s key in our metadata because who is |
107 |
> going to verify they key? The same developer we distrust (or where we |
108 |
> just want to avoid to trust) that he/she verified the distfile? |
109 |
|
110 |
What's the alternative? Ignoring upstream signatures entirely unless we |
111 |
can securely fetch the key? Shoving the problem under the carpet |
112 |
and assuming that the developer will have safely set up the key on his |
113 |
devbox while being totally incompetent at putting it in an ebuild? |
114 |
|
115 |
Yes, again, this is not perfect. It was never supposed to be. It's |
116 |
better than what we had before (local solutions). Keeping the key |
117 |
relatively correct via ebuild is easier than keeping it on multiple |
118 |
machines used for development. |
119 |
|
120 |
> Please do not get me wrong. I like the idea. But I also understand that |
121 |
> you cannot implement it in a secure and really working way -- you will |
122 |
> always require a human paying attention. But now that we pretend, we |
123 |
> managed to implement that and even show a fancy green message that we |
124 |
> verified (any) signature, we actually lowered security because more |
125 |
> people will now stop paying attention: |
126 |
> |
127 |
> - Previous developers who carefully checked distfiles will stop |
128 |
> doing that. |
129 |
> |
130 |
> - Nobody will question anything because there is a new passed |
131 |
> check. |
132 |
|
133 |
Theories are all nice but do you have any proof of that? Preferably one |
134 |
that involves developers who *actually carefully* checked distfiles. |
135 |
Because my theory says developers don't have infinite time to audit |
136 |
everything. |
137 |
|
138 |
> In worst case scenario, we are now emerging a signed malicious package |
139 |
> we could be aware of if some human would have checked upstream and |
140 |
> noticed that release key was revoked. But this will not happen anymore |
141 |
> because we rely that once we have recorded a key in the metadata that |
142 |
> some system will tell us in case there is a problem. And what do you |
143 |
> expect what will happen when after the download something will tell us |
144 |
> “Oh, this file is not signed with currently known key”? Right, that |
145 |
> developer who we do not want to trust that he/she verified the distfile |
146 |
> will just add a reference to the new matching key which will silence any |
147 |
> warning. |
148 |
> |
149 |
> No, sorry. Security required education. You need to understand where |
150 |
> security is depending on so that you know when you need to take action. |
151 |
> Every attempt to move this away from the user will actually add needless |
152 |
> complexity, allow for new attack vectors and will not improve security. |
153 |
|
154 |
Are you arguing that we should remove commit signatures as well? Or |
155 |
does it happen that with roughly the same technology and the same |
156 |
people, one layer is secure and another similar layer is totally |
157 |
bonkers? |
158 |
|
159 |
> The purpose of this email is to get this addition removed ASAP. |
160 |
|
161 |
Why do you claim to have the power to removed somebody's work just |
162 |
because it doesn't fit your view of the world? |
163 |
|
164 |
-- |
165 |
Best regards, |
166 |
Michał Górny |