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