Date: Fri, 1 Oct 2021 05:03:00 +0200 (CEST)
From: Prayank <prayank@tutanota.de>
To: Ruben Somsen <rsomsen@gmail.com>
Message-ID: <MktnWM7--3-2@tutanota.de>
In-Reply-To: <CAPv7TjbvRE-b33MeYucUfr6CTooCRSH42hwSn5dMiJ4LODATRQ@mail.gmail.com>
References: <MkZx3Hv--3-2@tutanota.de>
 <yp9mJ2Poc_Ce91RkrhjnTA3UPvdh0wUyw2QhRPZEyO3gPHZPhmnhqER_4b7ChvmRh8GcYVPEkoud6vamJ9lGlQPi-POF-kyimBWNHz2RH3A=@protonmail.com>
 <MkdYcV9--3-2@tutanota.de>
 <CAPv7TjbvRE-b33MeYucUfr6CTooCRSH42hwSn5dMiJ4LODATRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_782139_198759108.1633057380830"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Mock introducing vulnerability in important
 Bitcoin projects
Precedence: list

------=_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 <http://2.One>>>  Lightning implementation
>> 3.Bisq
>> 4.Two Bitcoin libraries
>> 5.Two Bitcoin wallets
>> 6.One <http://6.One>>>  open source block explorer
>> 7.One <http://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

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>Hi Ruben,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; =
encouraging an environment of increased mistrust<br></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">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.<br></div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">&gt; For this reason, it would be appropriate to check first =
whether your plan is actually appreciated<br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">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.<br></div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><div dir=3D"auto">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:<br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">"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."<br></div></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Few questions for everyone reading this email:<br></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">1.What is better for Security? Trusting author=
s and their claims in PRs or a good review process?<br></div><div dir=3D"au=
to">2.Few people use commits from unmerged PRs in production. Is it a good =
practice?<br></div><div dir=3D"auto">3.Does this exercise help us in being =
prepared for worst?<br></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, 02:06 by rsomsen=
@gmail.com:<br></div><blockquote class=3D"tutanota_quote" style=3D"border-l=
eft: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div dir=3D"=
ltr"><div>Hi Prayank,<br></div><div><br></div><div>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 <a href=3D"https://lkml.org/lkml/2021/5/5/1244" rel=3D"noopener noref=
errer" target=3D"_blank">https://lkml.org/lkml/2021/5/5/1244</a> and <a hre=
f=3D"https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/" rel=
=3D"noopener noreferrer" target=3D"_blank">https://lore.kernel.org/linux-nf=
s/YH%2FfM%2FTsbmcZzwnX@kroah.com/</a> .<br></div><div><div><div><br></div><=
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.<br></div><div><br></div><div>Speaking on=
 behalf of the bitcoin-dev moderators, please ensure your plan is welcomed =
by the contributors, prior to proceeding.<br></div><div><br></div><div>Best=
 regards,<br></div><div>Ruben Somsen<br></div></div></div></div><div><br></=
div><div class=3D""><div class=3D"" dir=3D"ltr">On Tue, Sep 28, 2021 at 10:=
05 AM Prayank via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" rel=3D"noopener noreferrer" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
" class=3D""><div><div>Hi ZmnSCPxj,<br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Thanks for suggestion about sha256sum. I will share 10 in n=
ext few weeks. This exercise will be done for below projects:<br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">1.Two Bitcoin full node implement=
ations (one will be Core)<br></div><div dir=3D"auto"><a target=3D"_blank" h=
ref=3D"http://2.One" rel=3D"noopener noreferrer">2.One</a> Lightning implem=
entation<br></div><div dir=3D"auto">3.Bisq<br></div><div dir=3D"auto">4.Two=
 Bitcoin libraries<br></div><div dir=3D"auto">5.Two Bitcoin wallets<br></di=
v><div dir=3D"auto"><a target=3D"_blank" href=3D"http://6.One" rel=3D"noope=
ner noreferrer">6.One</a> open source block explorer<br></div><div dir=3D"a=
uto"><a target=3D"_blank" href=3D"http://7.One" rel=3D"noopener noreferrer"=
>7.One</a> coinjoin implementation<br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">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.<br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">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: <a target=3D"_blank" href=3D"https://t=
witter.com/1337in" rel=3D"noopener noreferrer">https://twitter.com/1337in</=
a><br></div><div><br></div><div dir=3D"auto"><br></div><div>-- <br></div><d=
iv>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>Sep 27, 2021, 15:4=
3 by <a target=3D"_blank" href=3D"mailto:ZmnSCPxj@protonmail.com" rel=3D"no=
opener noreferrer">ZmnSCPxj@protonmail.com</a>:<br></div><blockquote style=
=3D"border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5p=
x"><div>Good morning Prayank,<br></div><blockquote><div>Good morning Bitcoi=
n devs,<br></div><div><br></div><div>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: <a target=3D"_blank" href=3D"https://bitcoin.stacke=
xchange.com/a/108016/" rel=3D"noopener noreferrer">https://bitcoin.stackexc=
hange.com/a/108016/</a><br></div><div><br></div><div>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: <a target=3D"_blank" href=3D"https://news.ycomb=
inator.com/item?id=3D26887670" rel=3D"noopener noreferrer">https://news.yco=
mbinator.com/item?id=3D26887670</a><br></div><div><br></div><div>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:<br></div><=
div><br></div><div>1.Create new GitHub accounts for this exercise<br></div>=
<div>2.Study issues in different important Bitcoin projects including Bitco=
in Core, LND, Libraries, Bisq, Wallets etc.<br></div><div>3.Prepare pull re=
quests to introduce some vulnerability by fixing one of these issues<br></d=
iv><div>4.See how maintainers and reviewers respond to this and document it=
<br></div><div>5.Share results here after few days<br></div><div><br></div>=
<div>Let me know if this looks okay or there are better ways to do this.<br=
></div></blockquote><div><br></div><div><br></div><div>This seems like a go=
od exercise.<br></div><div><br></div><div>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).<br></div><div>e.g.<br=
></div><div><br></div><div>printf 'MyBitcoinHackingName 2c3e911b3ff1f04083c=
5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' | sha256sum<br></div><div>f0=
abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef<br></div><di=
v><br></div><div>Obviously do not share the actual name, just the sha256sum=
 output, and store how you got the sha256sum elsewhere in triplicate.<br></=
div><div><br></div><div>(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).)<br></div><div><br></div><div>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).<br></div><div><b=
r></div><div>You could argue that the commitment is a "show of good faith" =
that you will reveal later.<br></div><div><br></div><div>Regards,<br></div>=
<div>ZmnSCPxj<br></div></blockquote><div dir=3D"auto"><br></div></div><div>=
_______________________________________________<br></div><div> bitcoin-dev =
mailing list<br></div><div> <a target=3D"_blank" href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" rel=3D"noopener noreferrer">bitcoin-dev@lists.l=
inuxfoundation.org</a><br></div><div> <a target=3D"_blank" rel=3D"noopener =
noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>=
<br></div></blockquote></div></blockquote><div dir=3D"auto"><br></div>  </b=
ody>
</html>

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