How many of you check the code of open source software?

[Pmalek]

There is no doubt that open-source software is better compared to closed-source software. There is a lot of content on this topic, so there is no reason to discuss the advantages of open source.

There is another thing I would like to know. The crypto community preaches "Verify, Don't Trust!" How many of us actively check the code of the software, wallets, and everything else crypto-related that we use? Do you have the programming skills, time, and experience to inspect the codebase and deem it OK to be used? Or do you trust that others have done so and take their word for it? Do you find it odd that you are placing your trust in other individuals to have done the job for you in an industry where you are supposed to be your own bank, banker, and security department?

According to a study I found, it was discovered that 91% percent of open-sourced code contained certain parts that are either outdated or not actively developed.

The 2020 OSSRA report reaffirms the critical role that open source plays in today's software ecosystem, revealing that effectively all (99 percent) of the codebases audited over the past year contain at least one open source component, with open source comprising 70 percent of the code overall. More notable is the continued widespread use of aging or abandoned open source components, with 91 percent of the codebases containing components that either were more than four years out of date or had seen no development activity in the last two years.

That by itself is no reason for concern, but the following part could and should be:

The most concerning trend in this year's analysis is the mounting security risk posed by unmanaged open source, with 75 percent of audited codebases containing open source components with known security vulnerabilities, up from 60 percent the previous year. Similarly, nearly half (49 percent) of the codebases contained high-risk vulnerabilities, compared to 40 percent just 12 months prior.

You can read the whole report here:
https://www.securitymagazine.com/articles/92368-synopsys-study-shows-91-of-commercial-applications-contain-outdated-or-abandoned-open-source-components

[1715657933]

1715657933

[1715657933]

1715657933

[1715657933]

1715657933

[1715657933]

1715657933

[ranochigo]

There is another thing I would like to know. The crypto community preaches "Verify, Don't Trust!" How many of us actively check the code of the software, wallets, and everything else crypto-related that we use? Do you have the programming skills, time, and experience to inspect the codebase and deem it OK to be used? Or do you trust that others have done so and take their word for it? Do you find it odd that you are placing your trust in other individuals to have done the job for you in an industry where you are supposed to be your own bank, banker, and security department?

I personally have only read Electrum's source code fully, because it's written in Python and it's relatively less bulky than most other implementations. For that matter, I think it's a good practice to inspect what you're running on the computer. But the truth is, it's just too unrealistic. It's a time consuming process and most programs are a mix of languages and for which some are not proficient at. If you're reading the code but you don't know what's going on, the process is probably not going to be of any use and just a waste of time.

Beauty of open source lies primarily in the fact that people can have access to the source code and there are probably some that are honest and are quick to point out of any mistakes as well as transparent commits (in the case of projs on github). If you don't have the skills or the time to audit it (which can be rather time consuming for some bulky codes), then you'll be better off just validating the binaries. You'll probably not be able to identify anything wrong with the source code, it can be well obfuscated.

As for the study, isn't it geared towards softwares which integrate open source resources? Wouldn't the onus be on the corporations to be auditing their own software and/or update the modules appropriately?

I think auditing the code and compiling it yourself is good practice, if you can read it in the first place. **Given how well the Electrum phishing worked, I would think that most people wouldn't bother to even validate the binaries, let alone see the code.

[casperBGD]

~snip
There is another thing I would like to know. The crypto community preaches "Verify, Don't Trust!"
~snip

one need to have knowledge to check if the software is good or bad, and I could not say that I am able to check if the open-source software is good or bad

yeah, I do not use it blindly, try to check it on reserve machine before installation on main computer, do not use what I do not exactly need, but as far as checking and verifying the software is good or bad, it takes more knowledge that I have to check it, and only option is to trust that others have verified it, and to check when last commits and updates happened

do you check it before use, as far as I can see, most people answered Yes

[ABCbits]

Check whole code of open source software? No, but i take a peek at few Python software (e.g. Electrum and Bitcoin library).

On a side note,
1. When security is important, i avoid unpopular open source software, unless someone publish proper audit.
2. The question also applies to dependency of open source software you use & any cryptography used.

[HeRetiK]

For the most part I only look deeper into the source code of libraries I use for development, especially when I'm facing unexpected behaviour and need to troubleshoot. Concerning the source code of crypto projects or other utility software I only sneak the occasional peek, more out of interest rather than to verify though. For the latter I'd lack the expertise to properly audit anyway.

One thing I often check though is the amount of development activity and what dependencies are involved. IMHO the latter often are a greater liability than the code of the project itself. A house may look stable enough, but if it's built on sand...

[Coding Enthusiast]

It's not as easy as you'd think. I dare say that less than a handful of projects have "readable" code. Trying to read bad code is like trying to read a terrible handwriting, and going through the entire code is like reading an entire book in terrible handwriting.
Another common issue is lack of documentation. A single line of comment (on parts that need it) can reduce the time reader needs to understand the code drastically.

The less readable the code is the easier for a bug or even malicious code to hide in it even if reviewed by experts.

[vjudeu]

You don't have to inspect everything before using it. If you are going to do so, then you will never run any Open Source software, because checking absolutely everything takes more time than a lifetime of an average human. It is not about checking everything. It is rather about a possibility to do so when needed. If you have some closed source software, you don't know how it works and you have no way of getting that knowledge, unless you are an expert in Reverse Engineering binaries. If you have some Open Source software, you can inspect every part you need and only that part of code if it is well organized. You can also do some grepping and stop searching when you find enough information. Sooner or later you have to "trust" someone, because assuming that everyone is lying and everything is fake is very hard to do in practice.

So, to sum up: you don't have to verify everything. You just have to have any chance of doing it when needed, that's all about it.

[BrewMaster]

You just have to have any chance of doing it when needed, that's all about it.

this could work fine for something that is not as security critical as a bitcoin wallet that is to store all your money, something like a browser for example. but when the stakes are high you should also take all the precautions as you can. if everyone thinks they have the chance of verifying the code but never do projects end up never being reviewed by anyone.

[aliashraf]

Let's talk about the one open source project we are all interested in: bitcoin core client software
I mean, it is one of the ugliest open source codes ever, yet the community has put half a trillion USD trust in it as the single highly reliable code maintaining the protocol, yes? But how is it possible after all? I have a few suggestions:

1) Bitcoin core code is maintained by a group of very talented programmers who have their own reasons for not putting readability in the top of the requirements list.

2) Bitcoin has a very strong incentive mechanism for adversaries to exploit vulnerabilities and the very fact that they have not ever made it, ensures users that the code is safe and reliable.

3) Satoshi's original code enjoyed simple and straightforward programming style, old school, clean and most importantly very small code base that was easy to understand and evaluate, further developments and improvements didn't come from nowhere and overnight although they made the code base far more complicated and larger, they did it gradually and through extensive discussions.

4) On one hand, readability and future development potentials were not primary considerations for Satoshi and after a while it was impossible to re-engineer the code or build a new one from scratch, because of the financial risks involved, it was how the code base become so ugly and fat. It was not an engineering, deliberate fault, nobody was able to imagine how critical and sensitive would become the mission of this innocent piece of code, but it happened and what kept the trust of users in it was a simple fact: the whole process was transparent and supported by almost all the contributors and users.

Except for CVE-2018-17144 which has been addressed and caused no harm to the system bitcoin core has proved to be a successful project despite the fact that it is almost impossible for users to make a full review of it.

[20kevin20]

I don't really verify the codes and the only reason is that I do not know any coding language. If I did, I would personally verify the codes by myself (or at least take a peek over them). This makes me feel a bit insecure honestly about the software I own, but as long as nobody complains about a certain version (I usually wait 1-2 weeks after a new Core version is released, for example), I take that as a trusted version to run.

[LTU_btc]

I don't check codes of open source software simply because I don't have programming skills - it's dark forest for me. Though, even if I would have such skills, I'm not sure that I would check it every time before downloading something. I imagine it may be quite time consuming.
But obviously, I don't use random unknown software - risk is too big considering all these scams in crypto area. It should be verified by someone who is reliable. For example, trusted Bitcointalk user or member of other community.

[squatter]

I don't really verify the codes and the only reason is that I do not know any coding language. If I did, I would personally verify the codes by myself (or at least take a peek over them).

This describes most Bitcoin users, myself included. It wouldn't be reasonable to expect laypeople to inspect every open source code base they use. If that were a requirement, mass Bitcoin adoption would never happen.

Part of the reason this is acceptable is that open source software published by publicly known, well reputed, and verified developers reinforces strong incentives against malicious exploits. In the case of popular software like Bitcoin Core or Electrum, we can be reasonably confident that thousands of programmers are pouring over the code, looking for bugs. After a sufficient amount of time has passed, I consider an update to be relatively safe.

Regardless of the incentives involved, exploits are always possible however, so I wouldn't keep all my eggs in one basket. I've generated private keys using multiple implementations and setups I am reasonably confident in for long term storage, because I know no single method or software is foolproof.

[DireWolfM14]

I've been slowly learning how to screen the source code of python software.  I actually studied computer science in college, but I haven't done any coding since.  Fortran and Pascal aren't very useful anymore, not that I remember any of it anyway.

Getting into bitcoin has renewed my interest in coding, but I must admit, it's SLOW going.  I don't have the time to dedicate to learning python as quickly as I would like, and often I go months without having any time at all to study for hobby's sake.

Having said that; I don't use open source software unless the packages are digitally signed, and I can verify the signature.  Even if it's only MD5 encryption used to create the signatures, that's usually enough for me if the the software isn't something that could pose a security risk.  Of course I'm very careful what I install on my main PC which does have all my crypto clients installed on it.

[NotATether]

Another common issue is lack of documentation. A single line of comment (on parts that need it) can reduce the time reader needs to understand the code drastically.

Literally this. Sometimes even when I'm trying to compile packages like that, I have to resort to reading their source code because their documentation is not descriptive enough. I have a fairly thick skin and can tolerate reading/trying to understand badly written code to.

Writing correct documentation is just as important as making the code run correctly, whether it's a program or library (and ESPECIALLY for libraries, because you do not want end-developers to waste their time debugging your library for what they think is a problem). Unfortunately it is an art most people overlook - even though there is capable documentation software for C and C++ (Doxygen), not enough people are using them even though they introduce no additional library dependencies into your program.

[PrimeNumber7]

There is no doubt that open-source software is better compared to closed-source software.

I don't think this is an open and shut discussion as you describe.

For something such as bitcoin that is very widely used and involved in billions of dollars worth of transactions, the software will be scrutinized by many experts, and vulnerabilities/bugs will be found and corrected. For software that is less widely used, the code will be less scrutinized, and there is a greater chance that someone acting maliciously will find a vulnerability without disclosing it.

Say for example that an exchange creates their own software that their exchange runs on from scratch. Would making the software open source make it better? If the software is open source, if the devs employed by the exchange inadvertently leave open a vulnerability, an attacker could find the vulnerability by reviewing the code and/or pen testing the software on their own implementation. On the other hand, if the software is closed source, an attacker would need to find the vulnerability by attacking the implementation run by the exchange, and any pen-testing could be detected by reviewing logs.

To answer the OP's question:
If I am building something on top of open-sourced software, I will review the relevant parts of the documentation, and if necessary the code itself so I can understand how something works. If something is not working as expected, I will review the code, surrounding what I am trying to do, and either correct my mistake or change the code in the software.

[pooya87]

it is one of the ugliest open source codes ever,

I don't consider bitcoin core code as the best code ever but it definitely is not the ugliest one either. It is clean enough and most parts of it are easy to understand.

3) Satoshi's original code enjoyed simple and straightforward programming style, old school, clean and most importantly very small code base that was easy to understand and evaluate, further developments and improvements didn't come from nowhere and overnight although they made the code base far more complicated and larger, they did it gradually and through extensive discussions.

It was also slow, weak and full of attack vectors.
All the improvements that came later have been addressing these issues. If it looks complicated it is because some of these issues were complicated and some of them are optimization.

[Pmalek]

Beauty of open source lies primarily in the fact that people can have access to the source code and there are probably some that are honest and are quick to point out of any mistakes as well as transparent commits (in the case of projs on github).

I do agree with you and somewhere along the line you have to trust someone or something. But if those who are probably honest (I like that you aren't claiming that they are since people can turn) go rogue, together with the developers, would there be many people left to discover their wrongdoings?

This describes most Bitcoin users, myself included. It wouldn't be reasonable to expect laypeople to inspect every open source code base they use. If that were a requirement, mass Bitcoin adoption would never happen.

That describes me as well. That is one of the reasons I made this poll. I assume that very few people actually check the codebase thoroughly. Either because they don't know how to, they know how to but its tiring and time consuming, or they are relying on the fact that a respected/honest developer has checked it and remains honest.

A switch has been made from not trusting closed-source software (rightly so), to trusting open-source software that the majority hasn't investigated thoroughly and don't know how to.
This is not my way of criticizing the current situation, and I certainly don't have the know-how to make it better, it's just an observation on trust.     

[NotATether]

All the improvements that came later have been addressing these issues. If it looks complicated it is because some of these issues were complicated and some of them are optimization.

As a rule of thumb the more developers working on a project, the cleaner the code becomes since they have to make a coding style at some point so that everyone can check Git diffs the same way without these styling changes being part of the diff.

When they'd one or two people involved it's just "get the code out there and make it work" because they are the only people who ever read the code so they don't feel as compelled to make it readable for others.

Even better is if there's a standards process for adding features into a program because it fixates the structure of that part of the code allowing everyone implementing a standard to become familiar with it. Auditing usually doesn't involve making codebases readable. They only check for security vulnerabilities. Unless people raise enough concerns about the readability of the code like the OpenSSL devs did then a specific task force is made specifically for refactoring it.

I'd argue that makefiles written by hand and ./configure scripts are harder to read then even the most hairy C/C++ codebases (looking at you, X11).

[HeRetiK]

Looking at the poll there's more people in our community verifying the code of open source software than I expected. Nice.

it is one of the ugliest open source codes ever,

I don't consider bitcoin core code as the best code ever but it definitely is not the ugliest one either. It is clean enough and most parts of it are easy to understand.

I was thinking the same thing. I don't write C++ so I don't know the in and outs of how C++ code should look like in a production environment, but I've definitely seen worse.

As a rule of thumb the more developers working on a project, the cleaner the code becomes since they have to make a coding style at some point so that everyone can check Git diffs the same way without these styling changes being part of the diff.

Interesting observation! I guess that's because any project that doesn't follow clear styleguides eventually becomes hell to work on, causing active development to be abandoned. Anyone who's ever inherited "legacy code" probably knows what I'm talking about.

[aliashraf]

it is one of the ugliest open source codes ever,

I don't consider bitcoin core code as the best code ever but it definitely is not the ugliest one either. It is clean enough and most parts of it are easy to understand.

To be more exact, I'm saying this in the context of major open source projects, otherwise it is not expected from prominent programmers such as core devs to write down some trashy code, actually their coding style is pretty well above standard. Unfortunately for a software project to fall above average class, coding style is not enough, you have architectural and strategic framework decisions in play as well. Bitcoin client software is somehow trapped in its original design principles and objectives and there is no way out of it because nobody is in charge and risks are too high.

If, and it is a big IF, bitcoin client was not such a mission critical software with so many considerations and requirements including and not limited to avoiding unintentional chain splits we'd have seen at least two or three major rewrites and at least 3 or 4 competing pieces of software.

3) Satoshi's original code enjoyed simple and straightforward programming style, old school, clean and most importantly very small code base that was easy to understand and evaluate, further developments and improvements didn't come from nowhere and overnight although they made the code base far more complicated and larger, they did it gradually and through extensive discussions.

It was also slow, weak and full of attack vectors.
All the improvements that came later have been addressing these issues. If it looks complicated it is because some of these issues were complicated and some of them are optimization.

Putting optimization on top of the requirements list may be a good decision, but it comes with costs as every software engineer knows. There is also another issue with soft forks as they enforce downward compatibility in a highly sophisticated manner due to the nature of the consensus principle in a p2p network.

Obviously, I'm not criticizing the path that bitcoin client code has gone through in the past decade, but we need to understand the implications and consequences of the totally new and different situation with an ungoverned distributed system like bitcoin when it is loaded and should be maintained and developed  under the  load.