Prayank [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-01 📝 Original message:Good morning ZmnSCPxj, ...
📅 Original date posted:2021-10-01
📝 Original message: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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211001/25e558c1/attachment-0001.html>;
📝 Original message: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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211001/25e558c1/attachment-0001.html>;