summaryrefslogtreecommitdiff
path: root/1e/a285924fe1cb7ad684443b2f618d6550a81581
blob: d15a6de67c83dd0fe4a71311877dc9d7d1463512 (plain)
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
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4975AC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  4 Oct 2021 03:59:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 383328412B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  4 Oct 2021 03:59:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level: 
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5
 tests=[BAYES_20=-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_H4=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id UFe_Itk02GD1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  4 Oct 2021 03:59:39 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 67DD984102
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  4 Oct 2021 03:59:39 +0000 (UTC)
Date: Mon, 04 Oct 2021 03:59:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1633319976;
 bh=ao4CSbapt76oiwOfpzvUjfXCtj1v5oqdyq/smauHbRU=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=VZVPh5YUJXyg9oyjZ3Xb59G4izKHgEGC1XkwKUiQh5EanxqA1FeJuX9QEz82/cdyq
 J/ixTG37rmuhqXI9tYk9WoEgHAi86Xhq1cx7VmTlC0YfKxQZTx7HQzUdBc0snMu2E9
 3R7YkZds8dRx+heiweRoUkxeo2J++2i57eZfffxQ=
To: Luke Dashjr <luke@dashjr.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <sez9AuvBEnKKkLkJ4aivnaLJz5M5VFz3yTOdreTGmFb6RzwMv7h0dRFbEiB1_aup4Daw7t9YwlZKp2YvbgCu1fzym28cHhlzRVC3efmfBpE=@protonmail.com>
In-Reply-To: <202110032133.44726.luke@dashjr.org>
References: <MkZx3Hv--3-2@tutanota.de> <Ml-IIuL--3-2@tutanota.de>
 <CAAxiurb1_-p2yO8183MvB2x_i9H+WAo9t0RH85faRrrKz9YxGg@mail.gmail.com>
 <202110032133.44726.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Prayank <prayank@tutanota.de>
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: Mon, 04 Oct 2021 03:59:40 -0000


Good morning Luke,

> All attempts are harmful, no matter the intent, in that they waste
> contributors' time that could be better spent on actual development.
>
> However, I do also see the value in studying and improving the review pro=
cess
> to harden it against such inevitable attacks. The fact that we know the N=
SA
> engages in such things, and haven't caught one yet should be a red flag.

Indeed, I believe we should take the position that "review process is as mu=
ch a part of the code as the code itself, and should be tested regularly".

> Therefore, I think any such a scheme needs to be at least opt-out, if not
> opt-in. Please ensure there's a simple way for developers with limited ti=
me
> (or other reasons) to be informed of which PRs to ignore to opt-out of th=
is
> study. (Ideally it would also prevent maintainers from merging - maybe
> possible since we use a custom merging script, but what it really needs t=
o
> limit is the push, not the dry-run.)

Assuming developers are normal humans with typical human neurology (in part=
icular a laziness circuit), perhaps this would work?

Every commit message is required to have a pair of 256-bit hex words.

Public attempts at attack / testing of the review process will use the firs=
t 256-bit as a salt, and when the salt is prepended to the string "THIS IS =
AN ATTACK" and then hashed with e.g. SHA256, should result in the second 25=
6-bit word.

Non-attacks / normal commits just use random 256-bit numbers.

Those opting-out to this will run a script that checks commit messages for =
whether the first 256-bit hexword concatenated with "THIS IS AN ATTACK", th=
en hashed, is the second 256-bit hexword.

Those opting-in will not run that script and ignore the numbers.

The script can be run as well at the maintainer.

Hopefully, people who are not deliberately opting out will be too lazy to r=
un the script (as is neurotypical for humans) and getting "spoilered" on th=
is.

***HOWEVER***

We should note that a putative NSA attack would of course not use the above=
 protocol, and thus no developer can ever opt out of an NSA attempt at inse=
rting vulnerabilities; thus, I think it is better if all developers are for=
ced to opt in on the "practice rounds", as they cannot opt out of "the real=
 thing" other than to stop developing entirely.

Regards,
ZmnSCPxj