Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3245CC000D for ; Fri, 1 Oct 2021 03:03:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 04CB1843AF for ; Fri, 1 Oct 2021 03:03:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, TRACKER_ID=0.1] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de 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 7cHX2WgoNqMd for ; Fri, 1 Oct 2021 03:03:04 +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 smtp1.osuosl.org (Postfix) with ESMTPS id BAC3A8439B for ; Fri, 1 Oct 2021 03:03:03 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id CF505FBF6A1; Fri, 1 Oct 2021 03:03:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1633057380; 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=CarRx0v8ZAngmiFfEJu7mJezHMrS7zyJ7HpkkMMs9ug=; b=PpmM4cupAkmmcCWJd5TqKs29sSZyulVON9FLcHAhgOLSBff15aL15MRL6yXg5bPS EXd3wN6yHnWEP8jRCZ737v/OEaGQ0PDx3t0Bi1g/uAB+FaB5vVMTcoP2CJYWi2G/goB 9IOg3VrQjPfL0EvFn13mauVM8KdqLeNu5cUrmILfxmrtLgFS9e79ftdjaJ7vcr7h1bd 2CgD6CN6DqcMKRVD49UQHgQr0gELJ7Ejt2PqWNx58Abr+j6jtK1J+/2E8LBaodUCF84 FOpXYxoM9G77a/ujNCvDoT+NknFxzbcwF46XJXZkIfezMxPds/qAJNW1Y/HGMwRWuG8 Tlz2j9oWMQ== Date: Fri, 1 Oct 2021 05:03:00 +0200 (CEST) From: Prayank To: Ruben Somsen Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_782139_198759108.1633057380830" X-Mailman-Approved-At: Fri, 01 Oct 2021 07:45:03 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 03:03:06 -0000 ------=_Part_782139_198759108.1633057380830 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ruben, > encouraging an environment of increased mistrust I have always tried to review pull requests based on what PR does, code, my= tests etc. and it was never based on author of pull request or what author= is trying to claim. So there is no trust involved. I am assuming others fo= llow the same thing. Infact there was a PR recently in which I found it doe= sn't fix the issues it claims to fix. Its not same as introducing vulnerabi= lity but the point is anyone can create PR, write anything, as a reviewer w= e need to review everything apart from algos already helping us which inclu= de Github Dependabot alerts, CI used by respository, other automated tools = etc. > For this reason, it would be appropriate to check first whether your plan= is actually appreciated Right. I don't want to get in some controversy when I am not even doing any= thing with wrong intentions. If maintainers of important Bitcoin projects t= hink I am not qualified enough to do this, they can plan such exercise inte= rnally and do it in a better way. Although I am still interested in the res= ults because they will help us improve review process and security in diffe= rent Bitcoin projects. I would like to repeat what I wrote in another email responding to few othe= r devs for same thread but wasn't CCed to bitcoin-dev mailing list: "I can avoid doing this but it is impossible to stop government agencies an= d anyone else to do the same thing without informing. All I am doing is cre= ating pull requests and expect them to be reviewed properly before being me= rged." 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? 2.Few people use commits from unmerged PRs in production. Is it a good prac= tice? 3.Does this exercise help us in being prepared for worst? --=20 Prayank A3B1 E430 2298 178F Oct 1, 2021, 02:06 by rsomsen@gmail.com: > Hi Prayank, > > While I can see how this can come from a place of good intentions, I=E2= =80=99d strongly advise you to tread carefully because what you are suggest= ing is quite controversial. A related event occurred in the Linux community= and it did not go over well. See > https://lkml.org/lkml/2021/5/5/1244> a= nd > https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/> . > > The main point of contention is that your research comes at the expense o= f the existing open source contributors =E2=80=93 you=E2=80=99d be one-side= dly deceiving them, encouraging an environment of increased mistrust, and c= ausing them a lot of work in order to gather the data you=E2=80=99re intere= sted in. For this reason, it would be appropriate to check first whether yo= ur plan is actually appreciated. > > Speaking on behalf of the bitcoin-dev moderators, please ensure your plan= is welcomed by the contributors, prior to proceeding. > > Best regards, > Ruben Somsen > > On Tue, Sep 28, 2021 at 10:05 AM Prayank via bitcoin-dev <> bitcoin-dev@l= ists.linuxfoundation.org> > wrote: > >> Hi ZmnSCPxj, >> >> Thanks for suggestion about sha256sum. I will share 10 in next few weeks= . This exercise will be done for below projects: >> >> 1.Two Bitcoin full node implementations (one will be Core) >> 2.One >> Lightning implementation >> 3.Bisq >> 4.Two Bitcoin libraries >> 5.Two Bitcoin wallets >> 6.One >> open source block explorer >> 7.One >> coinjoin implementation >> >> Feel free to suggest more projects. There are no fixed dates for it howe= ver it will be done in next 6 months. All PRs will be created within a span= of few days. I will ensure nothing is merged that affects the security of = any Bitcoin project. Other details and results will be shared once everythi= ng is completed. >> >> x00 will help me in this exercise, he does penetration testing since few= years and working for a cryptocurrencies derivatives exchange to manage th= eir security. His twitter account: >> https://twitter.com/1337in >> >> >> --=20 >> Prayank >> >> A3B1 E430 2298 178F >> >> >> >> Sep 27, 2021, 15:43 by >> ZmnSCPxj@protonmail.com>> : >> >>> Good morning Prayank, >>> >>>> Good morning Bitcoin devs, >>>> >>>> In one of the answers on Bitcoin Stackexchange it was mentioned that s= ome companies may hire you to introduce backdoors in Bitcoin Core: >>>> htt= ps://bitcoin.stackexchange.com/a/108016/ >>>> >>>> While this looked crazy when I first read it, I think preparing for su= ch things should not be a bad idea. In the comments one link was shared in = which vulnerabilities were almost introduced in Linux: >>>> https://news.yc= ombinator.com/item?id=3D26887670 >>>> >>>> I was thinking about lot of things in last few days after reading the = comments in that thread. Also tried researching about secure practices in C= ++ etc. I was planning something which I can do alone but don't want to end= up being called "bad actor" later so wanted to get some feedback on this i= dea: >>>> >>>> 1.Create new GitHub accounts for this exercise >>>> 2.Study issues in different important Bitcoin projects including Bitco= in Core, LND, Libraries, Bisq, Wallets etc. >>>> 3.Prepare pull requests to introduce some vulnerability by fixing one = of these issues >>>> 4.See how maintainers and reviewers respond to this and document it >>>> 5.Share results here after few days >>>> >>>> Let me know if this looks okay or there are better ways to do this. >>>> >>> >>> >>> This seems like a good exercise. >>> >>> You may want to hash the name of the new Github account, plus some rand= omized salt, and post it here as well, then reveal it later (i.e. standard = precommitment). >>> e.g. >>> >>> printf 'MyBitcoinHackingName 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d178= 02b2aac4da622def29dbb0' | sha256sum >>> f0abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef >>> >>> Obviously do not share the actual name, just the sha256sum output, and = store how you got the sha256sum elsewhere in triplicate. >>> >>> (to easily get a random 256-bit hex salt like the `2c3e...` above: `hea= d -c32 /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum` prod= uces a single hex string you can easily double-click and copy-paste elsewhe= re, assuming you are human just like I am (note: I am definitely 100% human= and not some kind of AI with plans to take over the world).) >>> >>> Though you may need to be careful of timing (i.e. the creation date of = the Github account would be fairly close to, and probably before, when you = post the commitment here). >>> >>> You could argue that the commitment is a "show of good faith" that you = will reveal later. >>> >>> Regards, >>> ZmnSCPxj >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> ------=_Part_782139_198759108.1633057380830 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ruben,

> = encouraging an environment of increased mistrust

I have always tried to review pull requests ba= sed on what PR does, code, my tests etc. and it was never based on author o= f pull request or what author is trying to claim. So there is no trust invo= lved. I am assuming others follow the same thing. Infact there was a PR rec= ently in which I found it doesn't fix the issues it claims to fix. Its not = same as introducing vulnerability but the point is anyone can create PR, wr= ite anything, as a reviewer we need to review everything apart from algos a= lready helping us which include Github Dependabot alerts, CI used by respos= itory, other automated tools etc.

> For this reason, it would be appropriate to check first = whether your plan is actually appreciated

Right. I don't want to get in some controversy when I= am not even doing anything with wrong intentions. If maintainers of import= ant Bitcoin projects think I am not qualified enough to do this, they can p= lan such exercise internally and do it in a better way. Although I am still= interested in the results because they will help us improve review process= and security in different Bitcoin projects.
I would like to repeat what I wr= ote in another email responding to few other devs for same thread but wasn'= t CCed to bitcoin-dev mailing list:

"I can avoid doing this but it is impossible to stop govern= ment agencies=20 and anyone else to do the same thing without informing. All I am doing=20 is creating pull requests and expect them to be reviewed properly before being merged."

Few questions for everyone reading this email:

1.What is better for Security? Trusting author= s and their claims in PRs or a good review process?
2.Few people use commits from unmerged PRs in production. Is it a good = practice?
3.Does this exercise help us in being = prepared for worst?

--
Prayank<= br>

A3B1 E430 2298 178F



Oct 1, 2021, 02:06 by rsomsen= @gmail.com:
Hi Prayank,

While I can see how this= can come from a place of good intentions, I=E2=80=99d strongly advise you = to tread carefully because what you are suggesting is quite controversial. = A related event occurred in the Linux community and it did not go over well= . See https://lkml.org/lkml/2021/5/5/1244 and https://lore.kernel.org/linux-nf= s/YH%2FfM%2FTsbmcZzwnX@kroah.com/ .

<= div>The main point of contention is that your research comes at the expense= of the existing open source contributors =E2=80=93 you=E2=80=99d be one-si= dedly deceiving them, encouraging an environment of increased mistrust, and= causing them a lot of work in order to gather the data you=E2=80=99re inte= rested in. For this reason, it would be appropriate to check first whether = your plan is actually appreciated.

Speaking on= behalf of the bitcoin-dev moderators, please ensure your plan is welcomed = by the contributors, prior to proceeding.

Best= regards,
Ruben Somsen

On Tue, Sep 28, 2021 at 10:= 05 AM Prayank via bitcoin-dev <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
Hi ZmnSCPxj,

Thanks for suggestion about sha256sum. I will share 10 in n= ext few weeks. This exercise will be done for below projects:

1.Two Bitcoin full node implement= ations (one will be Core)
2.One Lightning implem= entation
3.Bisq
4.Two= Bitcoin libraries
5.Two Bitcoin wallets
6.One open source block explorer
7.One coinjoin implementation

Feel free to suggest more projects. There are no fixed dates for it however=20 it will be done in next 6 months. All PRs will be created within a span=20 of few days. I will ensure nothing is merged that affects the security=20 of any Bitcoin project. Other details and results will be shared once=20 everything is completed.

x00 will help me in this exercise, he does penetration testing since few=20 years and working for a cryptocurrencies derivatives exchange to manage=20 their security. His twitter account: https://twitter.com/1337in


Prayank




Good morning Prayank,
Good morning Bitcoi= n devs,

In one of the answers on Bitcoin Stack= exchange it was mentioned that some companies may hire you to introduce bac= kdoors in Bitcoin Core: https://bitcoin.stackexc= hange.com/a/108016/

While this looked craz= y when I first read it, I think preparing for such things should not be a b= ad idea. In the comments one link was shared in which vulnerabilities were = almost introduced in Linux: https://news.yco= mbinator.com/item?id=3D26887670

I was thin= king about lot of things in last few days after reading the comments in tha= t thread. Also tried researching about secure practices in C++ etc. I was p= lanning something which I can do alone but don't want to end up being calle= d "bad actor" later so wanted to get some feedback on this idea:
<= div>
1.Create new GitHub accounts for this exercise
=
2.Study issues in different important Bitcoin projects including Bitco= in Core, LND, Libraries, Bisq, Wallets etc.
3.Prepare pull re= quests to introduce some vulnerability by fixing one of these issues
4.See how maintainers and reviewers respond to this and document it=
5.Share results here after few days

=
Let me know if this looks okay or there are better ways to do this.


This seems like a go= od exercise.

You may want to hash the name of = the new Github account, plus some randomized salt, and post it here as well= , then reveal it later (i.e. standard precommitment).
e.g.

printf 'MyBitcoinHackingName 2c3e911b3ff1f04083c= 5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' | sha256sum
f0= abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef

Obviously do not share the actual name, just the sha256sum= output, and store how you got the sha256sum elsewhere in triplicate.

(to easily get a random 256-bit hex salt like the `= 2c3e...` above: `head -c32 /dev/random | sha256sum`; you *could* use `xxd` = but `sha256sum` produces a single hex string you can easily double-click an= d copy-paste elsewhere, assuming you are human just like I am (note: I am d= efinitely 100% human and not some kind of AI with plans to take over the wo= rld).)

Though you may need to be careful of ti= ming (i.e. the creation date of the Github account would be fairly close to= , and probably before, when you post the commitment here).
You could argue that the commitment is a "show of good faith" = that you will reveal later.

Regards,
=
ZmnSCPxj

= _______________________________________________
bitcoin-dev = mailing list

------=_Part_782139_198759108.1633057380830--