Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Anthony Towns via bitcoin-dev]

On Thu, Nov 18, 2021 at 09:29:24PM +0100, Prayank via bitcoin-dev wrote:
> After reading all the emails, personally experiencing review process 
> especially on important issues like privacy and security, re-evaluating 
> everything and considering the time I can spend on this, I have decided to do 
> this exercise for 3 projects with just 1 account. I have created a salted 
> hash for the username as you had mentioned in the first email:
> f40bcb13dbcbf7b6245becb75586c22798ed7360cd9853572152ddf07a39
> 3 Bitcoin projects are Bitcoin Core (full node implementation), LND (LN 
> implementation) and Bisq (DEX).
> Pull requests will be created in next 6 months. If vulnerability gets caught 
> during review, will publicly announce here that the project caught the PR and 
> reveal the de-commitment publicly. If not caught during review, will 
> privately reveal both the inserted vulnerability and the review failure via 
> the normal private vulnerability-reporting channels. A summary with all the 
> details will be shared later.

It's now been nine months since this email, but I don't believe
there's been any public report on this exercise. Does this mean that a
vulnerability has been introduced in one or all of the named projects?

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank via bitcoin-dev]

Good morning ZmnSCPxj,

> Indeed, I believe we should take the position that "review process is as much 
> a part of the code as the code itself, and should be tested regularly".

Agree. Review process is an important part of open source Bitcoin projects. We 
should test and verify if everything is working as expected or there is any 
scope for improvement.

> as they cannot opt out of "the real thing" other than to stop developing 
> entirely

True and it won't be as obvious as this. Nobody will announce it on dev mailing 
list and will use proxies (not networks but humans)

After reading all the emails, personally experiencing review process especially 
on important issues like privacy and security, re-evaluating everything and 
considering the time I can spend on this, I have decided to do this exercise 
for 3 projects with just 1 account. I have created a salted hash for the 
username as you had mentioned in the first email:

f40bcb13dbcbf7b6245becb75586c22798ed7360cd9853572152ddf07a39

3 Bitcoin projects are Bitcoin Core (full node implementation), LND (LN 
implementation) and Bisq (DEX).

Pull requests will be created in next 6 months. If vulnerability gets caught 
during review, will publicly announce here that the project caught the PR and 
reveal the de-commitment publicly. If not caught during review, will privately 
reveal both the inserted vulnerability and the review failure via the normal 
private vulnerability-reporting channels. A summary with all the details will 
be shared later.

This exercise cannot be same as one of the active developers trying to do the 
same thing because of few reasons mentioned by Ryan Grant in one of the emails: 
uneven reputation factor of various devs, and uneven review attention for new 
pull requests. However, I am expecting few interesting results which will help 
improve the review process hence make Bitcoin more secure.

Will end the email by rephrasing one of the tweets from a respected cypherpunk 
recently: Independent thought is critical in aircraft crash investigations and 
in bitcoin development. Immunity from peer pressure can be very helpful during 
review process.


-- 
Prayank

A3B1 E430 2298 178F



Oct 4, 2021, 09:29 by zmnsc...@protonmail.com:

>
> Good morning Luke,
>
>> All attempts are harmful, no matter the intent, in that they waste
>> contributors' time that could be better spent on actual development.
>>
>> However, I do also see the value in studying and improving the review process
>> to harden it against such inevitable attacks. The fact that we know the NSA
>> engages in such things, and haven't caught one yet should be a red flag.
>>
>
> Indeed, I believe we should take the position that "review process is as much 
> a part of the code as the code itself, and should be tested regularly".
>
>> Therefore, I think any such a scheme needs to be at least opt-out, if not
>> opt-in. Please ensure there's a simple way for developers with limited time
>> (or other reasons) to be informed of which PRs to ignore to opt-out of this
>> study. (Ideally it would also prevent maintainers from merging - maybe
>> possible since we use a custom merging script, but what it really needs to
>> limit is the push, not the dry-run.)
>>
>
> Assuming developers are normal humans with typical human neurology (in 
> particular a laziness circuit), perhaps this would work?
>
> Every commit message is required to have a pair of 256-bit hex words.
>
> Public attempts at attack / testing of the review process will use the first 
> 256-bit as a salt, and when the salt is prepended to the string "THIS IS AN 
> ATTACK" and then hashed with e.g. SHA256, should result in the second 256-bit 
> word.
>
> Non-attacks / normal commits just use random 256-bit numbers.
>
> Those opting-out to this will run a script that checks commit messages for 
> whether the first 256-bit hexword concatenated with "THIS IS AN ATTACK", then 
> hashed, is the second 256-bit hexword.
>
> Those opting-in will not run that script and ignore the numbers.
>
> The script can be run as well at the maintainer.
>
> Hopefully, people who are not deliberately opting out will be too lazy to run 
> the script (as is neurotypical for humans) and getting "spoilered" on this.
>
> ***HOWEVER***
>
> We should note that a putative NSA attack would of course not use the above 
> protocol, and thus no developer can ever opt out of an NSA attempt at 
> inserting vulnerabilities; thus, I think it is better if all developers are 
> forced to opt in on the "practice rounds", as they cannot opt out of "the 
> real thing" other than to stop developing entirely.
>
> Regards,
> ZmnSCPxj
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[ZmnSCPxj via bitcoin-dev]

Good morning Luke,

> All attempts are harmful, no matter the intent, in that they waste
> contributors' time that could be better spent on actual development.
>
> However, I do also see the value in studying and improving the review process
> to harden it against such inevitable attacks. The fact that we know the NSA
> engages in such things, and haven't caught one yet should be a red flag.

Indeed, I believe we should take the position that "review process is as much a 
part of the code as the code itself, and should be tested regularly".

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

Assuming developers are normal humans with typical human neurology (in 
particular a laziness circuit), perhaps this would work?

Every commit message is required to have a pair of 256-bit hex words.

Public attempts at attack / testing of the review process will use the first 
256-bit as a salt, and when the salt is prepended to the string "THIS IS AN 
ATTACK" and then hashed with e.g. SHA256, should result in the second 256-bit 
word.

Non-attacks / normal commits just use random 256-bit numbers.

Those opting-out to this will run a script that checks commit messages for 
whether the first 256-bit hexword concatenated with "THIS IS AN ATTACK", then 
hashed, is the second 256-bit hexword.

Those opting-in will not run that script and ignore the numbers.

The script can be run as well at the maintainer.

Hopefully, people who are not deliberately opting out will be too lazy to run 
the script (as is neurotypical for humans) and getting "spoilered" on this.

***HOWEVER***

We should note that a putative NSA attack would of course not use the above 
protocol, and thus no developer can ever opt out of an NSA attempt at inserting 
vulnerabilities; thus, I think it is better if all developers are forced to opt 
in on the "practice rounds", as they cannot opt out of "the real thing" other 
than to stop developing entirely.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Luke Dashjr via bitcoin-dev]

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

However, I do also see the value in studying and improving the review process 
to harden it against such inevitable attacks. The fact that we know the NSA 
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 
opt-in. Please ensure there's a simple way for developers with limited time 
(or other reasons) to be informed of which PRs to ignore to opt-out of this 
study. (Ideally it would also prevent maintainers from merging - maybe 
possible since we use a custom merging script, but what it really needs to 
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 reputation.
> 2) A more complex scheme as described by Ryan (from my very rough
> understanding) seems to imply a random selection of team for attempting the
> 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 information
> 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  escreveu no
>
> dia sábado, 2/10/2021 à(s) 10:20:
> > This looks interesting although I don't understand few things:
> > > The scheme should include public precommitments collected at ceremonial
> >
> > 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-...@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 */ = double-sha256(secret)
> > hash2 /* public precommitment */ = 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.linuxfou

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Manuel Costa via bitcoin-dev]

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 reputation.
2) A more complex scheme as described by Ryan (from my very rough
understanding) seems to imply a random selection of team for attempting the
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 information
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  escreveu no
dia sábado, 2/10/2021 à(s) 10:20:

> This looks interesting although I don't understand few things:
>
> > The scheme should include public precommitments collected at ceremonial
> 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-...@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 */ = double-sha256(secret)
> hash2 /* public precommitment */ = 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank via bitcoin-dev]

This looks interesting although I don't understand few things:

> The scheme should include public precommitments collected at ceremonial 
> 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-...@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 */ = double-sha256(secret)
>  hash2 /* public precommitment */ = 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

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Ryan Grant via bitcoin-dev]

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 */ = double-sha256(secret)
  hash2 /* public precommitment */ = 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

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank via bitcoin-dev]

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 zmnsc...@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
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[ZmnSCPxj via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank via bitcoin-dev]

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 follow the 
same thing. Infact there was a PR recently 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, write anything, as a reviewer we need to review 
everything apart from algos already helping us which include 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 
anything with wrong intentions. If maintainers of important Bitcoin projects 
think I am not qualified enough to do this, they can plan 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 wrote 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 government agencies and 
anyone else to do the same thing without informing. All I am doing 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 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 practice?
3.Does this exercise help us in being prepared for worst?

-- 
Prayank

A3B1 E430 2298 178F



Oct 1, 2021, 02:06 by rsom...@gmail.com:

> Hi Prayank,
>
> While I can see how this can come from a place of good intentions, I’d 
> 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-nfs/yh%2ffm%2ftsbmczz...@kroah.com/>  .
>
> The main point of contention is that your research comes at the expense of 
> the existing open source contributors – you’d be one-sidedly deceiving them, 
> encouraging an environment of increased mistrust, and causing them a lot of 
> work in order to gather the data you’re interested 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@lists.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 however 
>> 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 everything 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 
>> their security. His twitter account: >> https://twitter.com/1337in
>>
>>
>> -- 
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> Sep 27, 2021, 15:43 by >> zmnsc...@protonmail.com>> :
>>
>>> Good morning Prayank,
>>>
 Good morning Bitcoin devs,

 In one of the answers on Bitcoin Stackexchange it was mentioned that some 
 companies may hire you to introduce backdoors in Bitcoin Core:  
 https://bitcoin.stackexchange.com/a/108016/

 While this looked crazy when I first read it, I think preparing for such 
 things should not be a bad idea. In the comments one link was shared in 
 which vulnerabilities were almost introduced in Linux:  
 https://news.ycombinator.com/item?id=26887670

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

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Ruben Somsen via bitcoin-dev]

Hi Prayank,

While I can see how this can come from a place of good intentions, I’d
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-nfs/yh%2ffm%2ftsbmczz...@kroah.com/ .

The main point of contention is that your research comes at the expense of
the existing open source contributors – you’d be one-sidedly deceiving
them, encouraging an environment of increased mistrust, and causing them a
lot of work in order to gather the data you’re interested 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@lists.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
> however 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
> everything 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
> their security. His twitter account: https://twitter.com/1337in
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Sep 27, 2021, 15:43 by zmnsc...@protonmail.com:
>
> Good morning Prayank,
>
> Good morning Bitcoin devs,
>
> In one of the answers on Bitcoin Stackexchange it was mentioned that some
> companies may hire you to introduce backdoors in Bitcoin Core:
> https://bitcoin.stackexchange.com/a/108016/
>
> While this looked crazy when I first read it, I think preparing for such
> things should not be a bad idea. In the comments one link was shared in
> which vulnerabilities were almost introduced in Linux:
> https://news.ycombinator.com/item?id=26887670
>
> 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 idea:
>
> 1.Create new GitHub accounts for this exercise
> 2.Study issues in different important Bitcoin projects including Bitcoin
> 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
> randomized salt, and post it here as well, then reveal it later (i.e.
> standard precommitment).
> e.g.
>
> printf 'MyBitcoinHackingName
> 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' |
> 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: `head
> -c32 /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum`
> produces a single hex string you can easily double-click and copy-paste
> elsewhere, 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank via bitcoin-dev]

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 however 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 everything 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 their 
security. His twitter account: https://twitter.com/1337in


-- 
Prayank

A3B1 E430 2298 178F



Sep 27, 2021, 15:43 by zmnsc...@protonmail.com:

> Good morning Prayank,
>
>> Good morning Bitcoin devs,
>>
>> In one of the answers on Bitcoin Stackexchange it was mentioned that some 
>> companies may hire you to introduce backdoors in Bitcoin Core: 
>> https://bitcoin.stackexchange.com/a/108016/
>>
>> While this looked crazy when I first read it, I think preparing for such 
>> things should not be a bad idea. In the comments one link was shared in 
>> which vulnerabilities were almost introduced in Linux: 
>> https://news.ycombinator.com/item?id=26887670
>>
>> 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 
>> idea:
>>
>> 1.Create new GitHub accounts for this exercise
>> 2.Study issues in different important Bitcoin projects including Bitcoin 
>> 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 randomized 
> salt, and post it here as well, then reveal it later (i.e. standard 
> precommitment).
> e.g.
>
>  printf 'MyBitcoinHackingName 
> 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' | 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: `head -c32 
> /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum` produces a 
> single hex string you can easily double-click and copy-paste elsewhere, 
> 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

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[ZmnSCPxj via bitcoin-dev]

Good morning Prayank,

> Good morning Bitcoin devs,
>
> In one of the answers on Bitcoin Stackexchange it was mentioned that some 
> companies may hire you to introduce backdoors in Bitcoin Core: 
> https://bitcoin.stackexchange.com/a/108016/
>
> While this looked crazy when I first read it, I think preparing for such 
> things should not be a bad idea. In the comments one link was shared in which 
> vulnerabilities were almost introduced in Linux: 
> https://news.ycombinator.com/item?id=26887670
>
> 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 idea:
>
> 1.Create new GitHub accounts for this exercise
> 2.Study issues in different important Bitcoin projects including Bitcoin 
> 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 randomized 
salt, and post it here as well, then reveal it later (i.e. standard 
precommitment).
e.g.

printf 'MyBitcoinHackingName 
2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' | 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: `head -c32 
/dev/random | sha256sum`; you *could* use `xxd` but `sha256sum` produces a 
single hex string you can easily double-click and copy-paste elsewhere, 
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

[bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank via bitcoin-dev]

Good morning Bitcoin devs,

In one of the answers on Bitcoin Stackexchange it was mentioned that some 
companies may hire you to introduce backdoors in Bitcoin Core: 
https://bitcoin.stackexchange.com/a/108016/

While this looked crazy when I first read it, I think preparing for such things 
should not be a bad idea. In the comments one link was shared in which 
vulnerabilities were almost introduced in Linux: 
https://news.ycombinator.com/item?id=26887670

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

1.Create new GitHub accounts for this exercise
2.Study issues in different important Bitcoin projects including Bitcoin 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.

-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev