Date: Fri, 01 Oct 2021 12:27:19 +0000
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
Precedence: list

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