From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Prayank <prayank@tutanota•de>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects
Date: Fri, 01 Oct 2021 12:27:19 +0000 [thread overview]
Message-ID: <qNjz-H23x07OJjnf5Try4Qp8l5s23SQxhEE8yAfNbrniN34u2vM72FVFSDJxHg4HNTL8tdcm-KKT8h6XVRwOwN0ZmckxzWiMlNFmLbMNuHc=@protonmail.com> (raw)
In-Reply-To: <MktnWM7--3-2@tutanota.de>
Good morning Prayank,
I think this is still good to do, controversial or no, but then I am permanently 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 or a good review process?
Review, of course.
> 2.Few people use commits from unmerged PRs in production. Is it a good practice?
Not unless they carefully reviewed it and are familiar enough with the codebase to do so.
In practice core maintainers of projects will **very** occassionally put unmerged PRs in experimental semi-production servers to get data on it, but they tend to be very familiar with the code, being core maintainers, and presumably 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 contributors, and may reduce review for them just to keep their workload down, so that is not tested (since you will be making throwaway accounts).
However, long-time contributors introducing security vulnerabilities tend to be a good bit rarer anyway (reputations are valuable), so this somewhat matches expected problems (i.e. newer contributors deliberately or accidentally (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 them.
* 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 vulnerability *and* the review failure via the normal private vulnerability-reporting channels.
The extra random numbers mixed with the commitments produce uncertainty about whether or not you are done, which is important to ensure that private vulnerabilities are harder to sniff out.
I think public praise of review processes is important, and to privately correct 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 review processes (being just another kind of code, readable by much more complicated 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 reveal it later when the maintainers have cleaned up the review process.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-10-01 12:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-27 1:52 Prayank
2021-09-27 10:13 ` ZmnSCPxj
2021-09-27 23:19 ` Prayank
2021-09-30 20:36 ` Ruben Somsen
2021-10-01 3:03 ` Prayank
2021-10-01 12:27 ` ZmnSCPxj [this message]
2021-10-01 15:55 ` Prayank
2021-10-01 20:15 ` Ryan Grant
2021-10-02 9:19 ` Prayank
2021-10-03 9:11 ` Manuel Costa
2021-10-03 21:33 ` Luke Dashjr
2021-10-04 3:59 ` ZmnSCPxj
2021-11-18 20:29 ` Prayank
2022-08-19 3:09 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='qNjz-H23x07OJjnf5Try4Qp8l5s23SQxhEE8yAfNbrniN34u2vM72FVFSDJxHg4HNTL8tdcm-KKT8h6XVRwOwN0ZmckxzWiMlNFmLbMNuHc=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=prayank@tutanota$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox