https://bugzilla.redhat.com/show_bug.cgi?id=1834731
--- Comment #56 from Oleg Girko <ol+red...@infoserver.lv> --- (In reply to Warren Togami from comment #55) > Oleg wrote: > > So far this threat is purely theoretical, there were no incidents related > > to that. > > This is incorrect. Some alt coins like PPC suffered exactly a catastrophic > fork because they disregarded warnings in this regard. I was not talking about minor altcoins with very low adoption rate. They suffer from more serious problems, like being vulnerable to 51% attacks. Also, they suffer from lack of developer resources and accumulate technical debt much quicker as a result. Hence, I'm not surprised that among thousands of altcoins you can find one that suffered because of this problem. You can find even more altcoins that suffered much worse problems because of bugs in their code anyway. > The diversity argument is counter to the opinion of among Bitcoin Core > developers. Yes, I know. But this doesn't automatically mean that Bitcoin Core developers are right. Ethereum developers have radically different opinion, for example. > Debating the diversity of implementations issue is not > productive here. I'm not debating diversity of implementations. I'm just using this argument to point to the fact that insisting on using particular versions of libraries is not an acceptable way to build reliable software. Unfortunately, it's becoming quite common mindset among developers: "I've tested my program with these particular versions of libraries, hence everyone should use them". Yes, this makes life easier for developers, but complicates life for everyone else. There is a good reason Fedora has a strong attitude against bundling of libraries. Upstream developers are usually not proficient enough to update all libraries they use in a timely manner. Maintainers of library packages are more proficient in this. If a remotely exploitable vulnerability is found in one of many libraries Bitcoin Core uses, it will take much more time for new version of Bitcoin Core to be released and packaged than for new version of this particular library packaged in Fedora. Very often Fedora gets patched package even before upstream releases a new version. Hence, if my argument about beneficial diversity is not enough for you, I have a much stronger argument: vulnerability in a bundled library. Remotely exploitable vulnerability is a true nightmare scenario for a cryptocurrency software, because it can lead to massive theft of funds. Unintended forks are just a nuisance compared to that. Even large-scale fork can lead just to temporary outage and increased time to reach consensus. Some transactions may be remaining in the mempool for a long time or even lost, so they have to be repeated later, but it's very unlikely that funds will be lost or stolen as a result. Single cases of double spend that can happen during an outage like this (that will be resolved when the fork is over anyway) are nothing compared to mass theft of funds. Considering a very minor fraction of nodes that will run Fedora-packaged Bitcoin Core, a theoretical fork involving these nodes will not be even large-scale. In worst case scenario, small percentage of nodes will be temporarily banned from the network until the problem is fixed. And probability of this is still lower than an unpatched vulnerability in a library Bitcoin uses. And packaging procedures in Fedora are well suited exactly to mitigate risks like this. > I ask that folks please defer to upstream Bitcoin Core > developer opinions on the wisdom and safety of how to ship Bitcoin Core in > downstream distributions. As a former Dash Core developer, I strongly disagree. Bitcoin Core deveopers' "wisdom" prevented Bitcoin Core client from being shipped in downstream distributions at all for 12 years already. > Simone wrote: > > I'm fine with your proposal, but the original bug report for the review is > > open since 2013, and apart high level things that should be done or not > > done I've not seen much from you on the topic. > > Upstream did not have a feasible build method until recently. I am sorry > this took so long. I also recognize this is extremely weird compared to the > normal way software is built in Fedora. The upstream developers felt so > strong about this that it was preferable to have no Bitcoin in the leading > Linux distros all these years. Now however we are close to a satisfactory > solution. I ask for a bit more patience. I don't think that building with all libraries bundled is satisfactory solution. At least, not for me. So, let's package Bitcoin Core client according to Fedora guidelines for now. However, I'm not against providing a bundled version as another option when it's available. I'm just against having this as the only option (and no option at all for quite a long time before it's available). Let users decide which slightly increased risk they prefer to take: minor fork and temporary ban or remotely exploitable vulnerability. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@lists.fedoraproject.org
