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
