path: root/8f/0b42d5e6a24ea3ae00c27cfeddb837953a0b3e

Return-Path: <luke@dashjr.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4246AC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Oct 2021 21:34:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 132C1801DA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Oct 2021 21:34:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.517
X-Spam-Level: 
X-Spam-Status: No, score=-4.517 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.117,
 RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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=dashjr.org
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 6AnJFv3OybqV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Oct 2021 21:34:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1])
 by smtp1.osuosl.org (Postfix) with ESMTP id AA7E5849AF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Oct 2021 21:34:01 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.215])
 (Authenticated sender: luke-jr)
 by zinan.dashjr.org (Postfix) with ESMTPSA id 15E1038A009D;
 Sun,  3 Oct 2021 21:33:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
 t=1633296840; bh=42DbXDlIJoWG+D4XHgmlc3gF/iwCBtq8dgCzPwm4BpE=;
 h=From:To:Subject:Date:References:In-Reply-To;
 b=0poshgLQ9KTmxSB0QJiuVRckFD9mM2uy6mEcWJXFRvVJlEbnDqHtluR2tqUIIHf+o
 A8F+xtx0GBXXgqOhIgqvtRRam4x7/F/ADFYwhrc3JBcMhFUG6sPGoQwCmlzM86NdSF
 7V6K/i3Tm1izx5BAU1aJ+h37ghR9FHDMk5STwySc=
X-Hashcash: 1:25:211003:bitcoin-dev@lists.linuxfoundation.org::4Jdqyx=2HkCdYRHB:USL/
X-Hashcash: 1:25:211003:manecosta@gmail.com::dyzebcQwz3TQpCIA:OaDP
X-Hashcash: 1:25:211003:prayank@tutanota.de::nk93vcZeaWDXDDIs:N1Sn
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Manuel Costa <manecosta@gmail.com>,
 Prayank <prayank@tutanota.de>
Date: Sun, 3 Oct 2021 21:33:43 +0000
User-Agent: KMail/1.9.10
References: <MkZx3Hv--3-2@tutanota.de> <Ml-IIuL--3-2@tutanota.de>
 <CAAxiurb1_-p2yO8183MvB2x_i9H+WAo9t0RH85faRrrKz9YxGg@mail.gmail.com>
In-Reply-To: <CAAxiurb1_-p2yO8183MvB2x_i9H+WAo9t0RH85faRrrKz9YxGg@mail.gmail.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <202110032133.44726.luke@dashjr.org>
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: Sun, 03 Oct 2021 21:34:03 -0000

All attempts are harmful, no matter the intent, in that they waste=20
contributors' time that could be better spent on actual development.

However, I do also see the value in studying and improving the review proce=
ss=20
to harden it against such inevitable attacks. The fact that we know the NSA=
=20
engages in such things, and haven't caught one yet should be a red flag.

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

Luke


On Sunday 03 October 2021 09:11:53 Manuel Costa via bitcoin-dev wrote:
> Good morning everyone,
>
> Just wanted to point out a few things for discussion which may or may not
> be obvious:
>
> 1) A simple scheme as described by ZmnSCPxj first can lead way for a
> standardized process where people can excuse their legitimate attempts to
> actually introduce vulnerabilities, where they create the precommit and
> then attempt to introduce the vulnerability. If it goes wrong they have
> plausible deniability by revealing it and possibly saving their reputatio=
n.
> 2) A more complex scheme as described by Ryan (from my very rough
> understanding) seems to imply a random selection of team for attempting t=
he
> attack, which might be limiting, since someone willing to do it and with
> enough knowledge to attempt it properly might not be picked.
>
> It seems to me that an ideal process would start from the will to attempt
> it from one person (or group), which then by some process similar to what
> Ryan described will pick at random a team of people to back up his claim =
to
> be doing it in good faith. With that selection done, the initial person
> would warn and gather from the randomly chosen participants a set of
> signatures for a similar message as described by ZmnSCPxj and only then go
> ahead with the attempt. This way you achieve:
>
> - One person can initiate it at will.
> - Other people (provably chosen at random) are insiders to that informati=
on
> and have a shared precommit.
> - You can't not reveal your intent in case it isn't caught, since other
> randomly chosen people are in on it.
> - You can't pick a specific group of people which might be willing to
> collude with you to achieve a similar situation to 1).
>
> Another important consideration is that depending on the size of the team
> to be insiders, we might by chance deplete the relevant pool of outsiders
> which would be adequate for reviewing the specific details of the
> vulnerability being introduced.
>
> Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> escreveu =
no
>
> dia s=C3=A1bado, 2/10/2021 =C3=A0(s) 10:20:
> > This looks interesting although I don't understand few things:
> > > The scheme should include public precommitments collected at ceremoni=
al
> >
> > intervals.
> >
> > How would this work? Can you explain with an example please.
> >
> > > Upon assignment, the dev would have community approval to
> >
> > opportunistically insert a security flaw
> >
> > Who is doing the assignment?
> >
> > --
> > Prayank
> >
> > A3B1 E430 2298 178F
> >
> >
> >
> > Oct 2, 2021, 01:45 by bitcoin-dev@rgrant.org:
> >
> > Due to the uneven reputation factor of various devs, and uneven review
> > attention for new pull requests, this exercise would work best as a
> > secret sortition.
> >
> > Sortition would encourage everyone to always be on their toes rather
> > than only when dealing with new github accounts or declared Red Team
> > devs. The ceremonial aspects would encourage more devs to participate
> > without harming their reputation.
> >
> > https://en.wikipedia.org/wiki/Sortition
> > https://en.wikipedia.org/wiki/Red_team
> >
> > The scheme should include public precommitments collected at
> > ceremonial intervals.
> >
> > where:
> > hash1 /* sortition ticket */ =3D double-sha256(secret)
> > hash2 /* public precommitment */ =3D double-sha256(hash1)
> >
> > The random oracle could be block hashes. They could be matched to
> > hash1, the sortition ticket. A red-team-concurrency difficulty
> > parameter could control how many least-significant bits must match to
> > be secretly selected. The difficulty parameter could be a matter of
> > group consensus at the ceremonial intervals, based on a group decision
> > on how much positive effect the Red Team exercise is providing.
> >
> > Upon assignment, the dev would have community approval to
> > opportunistically insert a security flaw; which, when either caught,
> > merged, or on timeout, they would reveal along with the sortition
> > ticket that hashes to their public precommitment.
> >
> > Sortition Precommitment Day might be once or twice a year.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev