Hi Ava, Thanks for the additional thoughts. > Peter was not the only "senior" person on the security list. Obviously I > will not disclose non-public information, but certainly there are people > on the security list who are just as, if not more, senior than Peter. Apart of sipa (who is arelady public on the security.md), I think they are 2 more people with whom I had experience of interacting on the list that I think are as much "senior" than Peter, both of them from public notoriety and on their own declaration they are less active in bitcoin protocol development (while they keep my reasonable trust if I have to report security information). Apart of those 3 people, I don't see who is most senior than Peter in bitcoin protocol development, and who an equivalent track records in matters of adversarial exploitation, consensus changes and use-cases protocol design (as one needs a bit of understanding of the "userspace" when you're handling issues). I won't be a jerk to disclose in public people who I think are actually on the list, and that you might think off in saying "just as", and here I have practical experiences with a lot of people in the space who have been there since satoshi time or after. > Furthermore, the "old parts" still do get changed, and someone who no > longer actively contributes to the project is more likely to be unaware > of how the code actually works today, even if they are familiar with > components that change infrequently. This is not incorrect to say that "old parts" get changed, though the frequency is far from being exceptional and the substantial changes are pretty rare. If you take few iconic files and you run stats (all no merges): - net_processing.cpp, initial file creation 2016, number of commits 926, in average 115 changes yearly - validation.cpp, initial file creation 2016, number of commits 1075, in average 134 changes yearly - scheduler.cpp, initial file creation 2015, number of commits 47, in average 5 changes yearly - interpreter.cpp, initial file creation 2014, number of commits 145, in average 14 changes yearly One can certainly run more line code stats diff changes at each year point to get a granularity how much substantial changes they are and if they are any trend like subsystem being more stable than other. Validation and net processing are obviously beefy files ongoing regular changes (as there has never been a patchset landing successs of the many attempts from many authors to break them further like #13413, #16175 and #18963). And what of substantial abstraction have been introduced in the past years in validation ? Package support and a lot of block-relay mitigations and cleanup, not something like crazy. Consensus and its interfaces has by far has a rythm of upgrades more slow, for an ecosystem impact de-multiplied in case of issues (and it's harder to evaluate they might have "horizontal" effect on use-cases like timelocks). Like I was saying evaluating who is active on single-digit years timelines (and more probably 2 than 9) is short-sighted, and this does not match practical experiences in other top open-source codebases like linux kernel. There is not only a necessity to be aware of how the code actually works today, though also the undocumented or unforseen scope of things like past attacks vectors or plausible past misinteractions. I think this something that Peter full disclosure illustrates well as more "junior" security list recipients, whatever their competency and goodwill, have failed to point out a type of class of attack that have come again and again in discussions about mempool rebroadcast years ago (see the PR link I was pointing out in one my Dave answer above). > Not being on the list does not preclude him from being consulted if the > need arises. "If the need arises" supposes a lot, as first it assumes the report timeframes give you leeway to come as more or less group decision to share the sensitive information to someone like Peter, being a default recipient it's always faster (one might have to deal with situations where the security flaw is already half-mentioned in public and it's better to act fast). Secondly, "if the need arises" is a technical judgement in itself. One worst-case scenario could be for all the default recipients reading a no-spam report, though missing an angle of exposure or that actually it's a serious attack vector. It did happen to me on the lightning side in the past as I pointed out the general vulnerability and someone cc after comes up with novel observations that were worsening the issues, or any hardening fix of it. > With the two examples you provide, I am not aware of Peter being > actively involved in the resolution of both of those, whereas there are > current members of the list who were. They were given as examples of situations where you prefer to have too much competent and responsible security list recipient that far too less, as both have temporal contengencies far beyond the scope of bitcoin core list to deal with them (the first as the DB-switch provoked fork was already happenin, the second as the report was from a bitcoin core fork coin). On the list of people being actively involved in the resolution of them, or who got privileged access to information before disclosure, from my experience they're some names that I must say can be a bit sloppy in terms of reactiveness and implications in security issues resolution (whatever the independent fact they're very skilled bitcoin engineers and pretty good reviewers). > In general though, it is not clear to me how it was beneficial to have > Peter on the security list, nor how not having him is directly harmful. > In the 2 years that I have been on the security list, I was unaware that > Peter was a recipient until shortly before he was removed. My > understanding is that others who have been on the list longer than me > were also unaware. Personally, I think Peter has still one of the most furnished track records in bugs findings around the mempool (the segwit malleability PR #8312) and understanding of all timelocks issues with the authorship of bip65, which is critical for contract protocols. That one disagrees with another security list member on its public technical opinions for newer changes, I think it's something one has to abstract when all security issues handlers are coming together to bring a mitigation to the issue. That one can be too much "cowboy" in matters of timelines full disclosure, which I think have been a bit about the last 3 "free relay" disclosure, the best you can do is say so either publicly, or privately in all courtesy. No way to make progress on responsible disclosure standards, if no one never speaks up. I was aware that Peter was on the list from conversations years ago with him on a reported issue, far before all the present topics about V3 / TRUC / RBFR have been raised. In my understanding, the fact that you were unaware that Peter was on the list can only reinforce impression had a very slow pace in terms of security issues fixing, especially when it's coupled with the disclosure of all issues of past months with which you have been involved. My number one recommendation would be to make the list of default security list recipient public, as it would create more personal accountability (both internally among the list recipient and externally towards the security issues reporters / the wider community) and you can have a key fingerprint for each one which is good in terms of process. I certainly don't wish to pour the blame on anyone specifically, as I think the current "so-so" state of security issues handling by bitcoin core has been more a background result of all the ups and downs of blocksize wars time, where contributors didn't focus on it sufficiently. Yet, I think it's very beneficial to think more about this process, before we see either more funds at stake with contract protocols and other applications (as it was well pointed out by one of the optech newsletter and sadly too known by lightning protocol devs, what can be a medium severity on the base layer like transaction-relay censorship vector is very likely a high severity on upper layer). Best, Antoine ots hash: b8b4ce2cbed73ef7036bc7d7ebe67c325ff0b0f9336ac480c49d9036c2e40736 Le dimanche 21 juillet 2024 à 21:49:10 UTC+1, Ava Chow a écrit : > On 07/20/2024 10:06 PM, Antoine Riard wrote: > > "Naive", as saying this is the _Bitcoin Core_ project list only can only > > provoke blind > > spot among the list members if the security issues are either affecting > > old part of > > the codebases that younger members have less experiences with (some > > parts like consensus > > or block-relay are modified only every 5 years) or novel factors from > > upstream or downstream > > (e.g the internet networking stack or implications on deployed contract > > protocols like > > lightning). On both the former and latter criterias, I think Peter > > overly meets the bar. > > Peter was not the only "senior" person on the security list. Obviously I > will not disclose non-public information, but certainly there are people > on the security list who are just as, if not more, senior than Peter. > > Furthermore, the "old parts" still do get changed, and someone who no > longer actively contributes to the project is more likely to be unaware > of how the code actually works today, even if they are familiar with > components that change infrequently. > > > When you've big sh*t hitting the fan like inflation bugs or level DB > > 2013 unexpected fork you > > prefer have experts with a decade of experience to collaborate with, and > > sharing the same cultural > > and ethical norms of the active contributors evaluated by numbers on > > commits on the last single-digit > > years. > > Not being on the list does not preclude him from being consulted if the > need arises. > > With the two examples you provide, I am not aware of Peter being > actively involved in the resolution of both of those, whereas there are > current members of the list who were. > > > In general though, it is not clear to me how it was beneficial to have > Peter on the security list, nor how not having him is directly harmful. > In the 2 years that I have been on the security list, I was unaware that > Peter was a recipient until shortly before he was removed. My > understanding is that others who have been on the list longer than me > were also unaware. > > Ava > > > > > I'll repropose Peter admission on the security list mailing list in the > > coming weeks by opening an > > issue on the bitcoin-meta repository, once this current mailing list > > thread has slowed down a bit, > > or at least the technical analysis has been dissociated from the > > proceedings which have all been > > bundle in a big message. In my very personal opinion, I still trust more > > Peter competence and experience > > than some other people I know who are on the security mailing list. > > > > All that said I appreciate your answer and I'm satisfied from the > > personal role you've have played > > in the matter with, and be reassured I'll keep you among the recipient > > of future security issues with > > a potential impact on bitcoin core that I might find or be aware off. > > > > Best, > > Antoine > > ots hash: > db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54 > > > > Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit : > > > > On 07/19/2024 07:58 PM, Antoine Riard wrote: > > > As said in one my previous email, I'm still curious about achow101 > > > explaining publicly > > > why you have been kicked-out of the bitcoin-security mailing > > list, when > > > you were certainly > > > more senior than achow101 in matters of base-layer security > > issues or > > > even hard technical > > > issues like consensus interactions (e.g bip65). I'll re-iterate my > > > respect towards achow101 > > > as a maintainer from years of collaboration, though this is a topic > > > worthy of an answer. > > > > I am not the one that removed Peter from the mailing list, nor do I > > even > > have the login(s) to do so. > > > > There was a discussion amongst several members of the security list > > about who was on the list, and who should be on the list. Given that > > the > > security list is the _Bitcoin Core_ security list, we determined that > > the people who should be on the list are people who still actively > > contribute to the project. As Peter Todd no longer actively contribute > > code nor code review to the project, we decided that it didn't make > > sense to continue to have him on the list. > > > > My recollection is that multiple other people were removed from the > > list > > for the same reason at the same time. > > > > Ava > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to bitcoindev+...@googlegroups.com > > . > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com > < > https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer > >. > > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/f9d17558-4b74-401b-bb64-fed34bd46619n%40googlegroups.com.