path: root/9e/c9e7c322a54ddf1964e599fe0d3f511ede891e

Return-Path: <prayank@tutanota.de>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3C7CFC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  1 Oct 2021 15:55:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 10DF3407DA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  1 Oct 2021 15:55:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (2048-bit key) header.d=tutanota.de
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 OSZra7vKnc5y
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  1 Oct 2021 15:55:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
 by smtp2.osuosl.org (Postfix) with ESMTPS id B5B6D407DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  1 Oct 2021 15:55:17 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
 by w1.tutanota.de (Postfix) with ESMTP id 20DB6FBF520;
 Fri,  1 Oct 2021 15:55:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1633103715; 
 s=s1; d=tutanota.de;
 h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;
 bh=s1oDZhzEt9x9aFGF+AuQC+S5b7w5G3MVrt8MPhJSEGc=;
 b=cx1pJC2g/S82+cArYUhZ559gboVxm6UQaoyNUcUgaB9svbDSqNZ0QkL1QJkozvi/
 qQSeGhO9nzaMEJUk40q8u1dstTJFYnKpNCJWRDWWYHW4pNP0AbVHgGDMbYLH3xcHs25
 ptdvzXKQ3kDZ4F9c0kw/qYlarpTQr2IWUbp+2ee83OentbJPRlFsrKcrJPzQWwXWAR7
 IXQCVW1rzbMArhac1kE2NqtG7nJlOmPRNaSRnzm9O05US3xHfXMXVDtjIP5KqyVpXR4
 2+kWo+7FwXjbcR5QKRdSZ/qmoiMeY00Y1g1NFwkzeEtSeX4bMyYDPkA6H1kfoA+QDme
 ajSykwCioQ==
Date: Fri, 1 Oct 2021 17:55:15 +0200 (CEST)
From: Prayank <prayank@tutanota.de>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <MkwZGYl--7-2@tutanota.de>
In-Reply-To: <qNjz-H23x07OJjnf5Try4Qp8l5s23SQxhEE8yAfNbrniN34u2vM72FVFSDJxHg4HNTL8tdcm-KKT8h6XVRwOwN0ZmckxzWiMlNFmLbMNuHc=@protonmail.com>
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>
 <qNjz-H23x07OJjnf5Try4Qp8l5s23SQxhEE8yAfNbrniN34u2vM72FVFSDJxHg4HNTL8tdcm-KKT8h6XVRwOwN0ZmckxzWiMlNFmLbMNuHc=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_819211_1050375125.1633103715119"
X-Mailman-Approved-At: Fri, 01 Oct 2021 16:50:14 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Fri, 01 Oct 2021 15:55:20 -0000

------=_Part_819211_1050375125.1633103715119
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Good morning ZmnSCPxj,

Although its evening here and time zones feel irrelevant since I got involved in Bitcoin few years back. Initially I tried everything a tech enthusiast does after finding such thing online. Had a startup in 2017 which was a website that can be used to buy flight tickets using bitcoin. It didn't work. Trading became a part of life, worked for few exchanges, did meetups, spent hours on different platforms discussing issues in which I was called "maximalist" most of the times because focused only on Bitcoin and had so much positive to talk about it whole day. In last 2 years started contributing to development in different projects. But someone told me today all this is nothing and I am negative about Bitcoin development because I don't agree with all of their opinions.

Anyway this wasn't related to thread and your email. Sorry I just had to express myself which some people even call "rage quit" and allow only once.

I completely agree with all the points you mentioned. Thanks for your understanding of the issue and my approach towards Bitcoin security.

-- 
Prayank

A3B1 E430 2298 178F



Oct 1, 2021, 17:57 by ZmnSCPxj@protonmail.com:

> 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
>


------=_Part_819211_1050375125.1633103715119
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>Good morning ZmnSCPxj,<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Although its evening here and time zones feel irrelevant since I =
got involved in Bitcoin few years back. Initially I tried everything a tech=
 enthusiast does after finding such thing online. Had a startup in 2017 whi=
ch was a website that can be used to buy flight tickets using bitcoin. It d=
idn't work. Trading became a part of life, worked for few exchanges, did me=
etups, spent hours on different platforms discussing issues in which I was =
called "maximalist" most of the times because focused only on Bitcoin and h=
ad so much positive to talk about it whole day. In last 2 years started con=
tributing to development in different projects. But someone told me today a=
ll this is nothing and I am negative about Bitcoin development because I do=
n't agree with all of their opinions.<br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Anyway this wasn't related to thread and your email. Sorr=
y I just had to express myself which some people even call "rage quit" and =
allow only once.<br></div><div dir=3D"auto"><div dir=3D"auto"><br></div><di=
v dir=3D"auto">I completely agree with all the points you mentioned. Thanks=
 for your understanding of the issue and my approach towards Bitcoin securi=
ty.<br></div></div><div><br></div><div>-- <br></div><div>Prayank<br></div><=
div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div><div><br></div=
><div><br></div><div><br></div><div>Oct 1, 2021, 17:57 by ZmnSCPxj@protonma=
il.com:<br></div><blockquote class=3D"tutanota_quote" style=3D"border-left:=
 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>Good mornin=
g Prayank,<br></div><div><br></div><div>I think this is still good to do, c=
ontroversial or no, but then I am permanently under a pseudonym anyway, for=
 what that is worth.<br></div><blockquote><div>Few questions for everyone r=
eading this email:<br></div><div><br></div><div>1.What is better for Securi=
ty? Trusting authors and their claims in PRs or a good review process?<br><=
/div></blockquote><div><br></div><div>Review, of course.<br></div><blockquo=
te>2.Few people use commits from unmerged PRs in production. Is it a good p=
ractice?<br></blockquote><div><br></div><div>Not unless they carefully revi=
ewed it and are familiar enough with the codebase to do so.<br></div><div>I=
n practice core maintainers of projects will **very** occassionally put unm=
erged PRs in experimental semi-production servers to get data on it, but th=
ey tend to be very familiar with the code, being core maintainers, and pres=
umably have a better-than-average probability of catching security issues b=
eforehand.<br></div><blockquote>3.Does this exercise help us in being prepa=
red for worst?<br></blockquote><div><br></div><div>I personally believe it =
does.<br></div><div><br></div><div>Do note that in practice, humans being l=
azy, will come to trust long-time contributors, and may reduce review for t=
hem just to keep their workload down, so that is not tested (since you will=
 be making throwaway accounts).<br></div><div>However, long-time contributo=
rs 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) in=
troducing vulnerabilities).<br></div><div><br></div><div>I think it would b=
e valuable to lay out exactly what you intend to do, e.g.<br></div><div><br=
></div><div>* Generate commitments of the pseudonyms you will use.<br></div=
><div>* Insert a few random 32-byte numbers among the commitments and shuff=
le them.<br></div><div>* Post the list with the commitments + random crap h=
ere.<br></div><div>* Insert avulnerability-adding PRs to targets.<br></div>=
<div>* If it gets caught during review, publicly announce here with praise =
that their project caught the PR and reveal the decommitment publicly.<br><=
/div><div>* If not caught during review, privately reveal both the inserted=
 vulnerability *and* the review failure via the normal private vulnerabilit=
y-reporting channels.<br></div><div><br></div><div>The extra random numbers=
 mixed with the commitments produce uncertainty about whether or not you ar=
e done, which is important to ensure that private vulnerabilities are harde=
r to sniff out.<br></div><div><br></div><div>I think public praise of revie=
w processes is important, and to privately correct review processes.<br></d=
iv><div>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.<br=
></div><div><br></div><div>Basically: treat review process failures the sam=
e as code vulnerabilities, pressure the maintainers to fix the review proce=
ss failure, then only reveal it later when the maintainers have cleaned up =
the review process.<br></div><div><br></div><div><br></div><div><br></div><=
div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote><div dir=3D"auto"=
><br></div>  </body>
</html>

------=_Part_819211_1050375125.1633103715119--