1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 31036C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Oct 2021 12:27:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 122E540278
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Oct 2021 12:27:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.297
X-Spam-Level:
X-Spam-Status: No, score=0.297 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Ek6RIZr_wPbF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Oct 2021 12:27:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by smtp2.osuosl.org (Postfix) with ESMTPS id B91EC401D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Oct 2021 12:27:24 +0000 (UTC)
Date: Fri, 01 Oct 2021 12:27:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1633091241;
bh=auaUzyqvqrhV8jWwLTwAazlJPsSQXa6IP6KYUt2MhHc=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=JdErgXpWmijYEW1u6rWP5iqsG9RoPzTLIqCl+FlymfiRhJRaHXEk9Zh3LSl6fHYxB
ZG6U1sneVHNat5LN9A6zrP8iBDN4XopbNkxbkomcUzgi21SKL4mD4Pr3kG9eMHotKR
dLvF6meVafrrxBCDSbfDT1Z+9GjbgWZf5woDs3/I=
To: Prayank <prayank@tutanota.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <qNjz-H23x07OJjnf5Try4Qp8l5s23SQxhEE8yAfNbrniN34u2vM72FVFSDJxHg4HNTL8tdcm-KKT8h6XVRwOwN0ZmckxzWiMlNFmLbMNuHc=@protonmail.com>
In-Reply-To: <MktnWM7--3-2@tutanota.de>
References: <MkZx3Hv--3-2@tutanota.de>
<yp9mJ2Poc_Ce91RkrhjnTA3UPvdh0wUyw2QhRPZEyO3gPHZPhmnhqER_4b7ChvmRh8GcYVPEkoud6vamJ9lGlQPi-POF-kyimBWNHz2RH3A=@protonmail.com>
<MkdYcV9--3-2@tutanota.de>
<CAPv7TjbvRE-b33MeYucUfr6CTooCRSH42hwSn5dMiJ4LODATRQ@mail.gmail.com>
<MktnWM7--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Mock introducing vulnerability in important
Bitcoin projects
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2021 12:27:26 -0000
Good morning Prayank,
I think this is still good to do, controversial or no, but then I am perman=
ently under a pseudonym anyway, for what that is worth.
> Few questions for everyone reading this email:
>
> 1.What is better for Security? Trusting authors and their claims in PRs o=
r a good review process?
Review, of course.
> 2.Few people use commits from unmerged PRs in production. Is it a good pr=
actice?
Not unless they carefully reviewed it and are familiar enough with the code=
base to do so.
In practice core maintainers of projects will **very** occassionally put un=
merged PRs in experimental semi-production servers to get data on it, but t=
hey tend to be very familiar with the code, being core maintainers, and pre=
sumably have a better-than-average probability of catching security issues =
beforehand.
> 3.Does this exercise help us in being prepared for worst?
I personally believe it does.
Do note that in practice, humans being lazy, will come to trust long-time c=
ontributors, and may reduce review for them just to keep their workload dow=
n, so that is not tested (since you will be making throwaway accounts).
However, long-time contributors introducing security vulnerabilities tend t=
o be a good bit rarer anyway (reputations are valuable), so this somewhat m=
atches expected problems (i.e. newer contributors deliberately or accidenta=
lly (due to unfamiliarity) introducing vulnerabilities).
I think it would be valuable to lay out exactly what you intend to do, e.g.
* Generate commitments of the pseudonyms you will use.
* Insert a few random 32-byte numbers among the commitments and shuffle the=
m.
* Post the list with the commitments + random crap here.
* Insert avulnerability-adding PRs to targets.
* If it gets caught during review, publicly announce here with praise that =
their project caught the PR and reveal the decommitment publicly.
* If not caught during review, privately reveal both the inserted vulnerabi=
lity *and* the review failure via the normal private vulnerability-reportin=
g channels.
The extra random numbers mixed with the commitments produce uncertainty abo=
ut whether or not you are done, which is important to ensure that private v=
ulnerabilities are harder to sniff out.
I think public praise of review processes is important, and to privately co=
rrect review processes.
Review processes **are** code, followed by sapient brains, and this kind of=
testing is still valuable, but just as vulnerabilities in machine-readable=
code require careful, initially-private handling, vulnerabilities in revie=
w processes (being just another kind of code, readable by much more complic=
ated machines) also require careful, initially-private handling.
Basically: treat review process failures the same as code vulnerabilities, =
pressure the maintainers to fix the review process failure, then only revea=
l it later when the maintainers have cleaned up the review process.
Regards,
ZmnSCPxj
|
