Official bitcoin source code should be more secure #13403

Official version control system for bitcoin core is based on Github which is not an open-source tool. Moreover recently it was takeover by Microsoft #13387 This fact seriously violate the reproducible-builds efforts especially for windows platform, where the whole toolchain from source code (Github), compilers(Visual Studio) up to build and executable environments (Window OS) based on Microsoft solutions only.

SVN, Mercurial, Git, etc don't work like blockchain and it cannot be really trusted. Moreover not every commits are gpg signed, and there are many possible attacks to corrupt the official source code.

Gitian, which is not fully https://reproducible-builds.org/ only protects the stable builds. Users who want to compile different commits. cannot really validate if the source code they use are not corrupted. The commit zip versions offered by Github (without the history log) could possible contain any kind of malware.

Please don't ignore this issue and provide at least some official git mirrors as a reference to your Github code.

Please note that we use GitHub only as a convenient way to publish the content of the current git repo, have a list of issue and pull requests.

Please refer to https://github.com/bitcoin/bitcoin/blob/a589f536b5e15daf3ac6ffcc137a146514c81967/contrib/devtools/README.md#github-mergepy on how the merge commits are signed.

Moreover not every commits are gpg signed

It would be too much to ask every developer to sign every commit, imo.

Users who want to compile different commits. cannot really validate if the source code they use are not corrupted.

Please refer to https://github.com/bitcoin/bitcoin/blob/a589f536b5e15daf3ac6ffcc137a146514c81967/contrib/verify-commits/README.md#tooling-for-verification-of-pgp-signed-commits on how to verify the merge commits.

Please don't ignore this issue and provide at least some official git mirrors as a reference to your Github code.

Since merge commits are signed, anyone can mirror the current state of the git repo and an "official git mirror" is not required.

where the whole toolchain from source code (Github), compilers(Visual Studio) up to build and executable environments (Window OS) based on Microsoft solutions only.

We don't actually use any Microsoft compiler or platform. All release binaries are built on an Ubuntu platform (inside Gitian) using the MinGW compiler suite for Windows binaries.

Gitian, which is not fully https://reproducible-builds.org/ only protects the stable builds. Users who want to compile different commits. cannot really validate if the source code they use are not corrupted

This is untrue. You can build at any commit with gitian. Anything that is commit-ish (e.g. commit, tag) can be specified to be built by gitian. Releases are just git tags which are commit-ish.

There are even (unsigned) nightly builds that you can compare against: https://bitcoin.jonasschnelli.ch/#nighly

If you're concerned about not being able to get the code except through Microsoft infrastructure I started a mirror of certain important bitcoin-related repositories on a Tor hidden service: nxshomzlgqmwfwhcnyvbznyrybh3gotlfgis7wkv7iur2yj2rarlhiad.onion, this can be useful for other reasons too, the sale of GitHub was just my wake-up call to do it.

I'm a bit disappointed that it needs to be said, but to be clear, nothing in this space is official. It's all just services hosted by developers, or other volunteers. Like with bitcoin itself, the onus of validation lies entirely with you.

It would be too much to ask every developer to sign every commit, imo.

it's just a weak point of your Github code and it could be solved in many different ways, if you care about protecting your full source code.

Please refer to https://github.com/bitcoin/bitcoin/blob/a589f536b5e15daf3ac6ffcc137a146514c81967/contrib/verify-commits/README.md#tooling-for-verification-of-pgp-signed-commits on how to verify the merge commits.

if Github is doing so good job then what for we need bitcoin PoW? Lets verify our blockchain with Microsoft commit-ish instead ;)

Since merge commits are signed, anyone can mirror the current state of the git repo and an "official git mirror" is not required.

Github is full of surprises: https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57 and inspirations: https://www.cvedetails.com/vulnerability-list/vendor_id-4008/GIT.html

All release binaries are built on an Ubuntu platform (inside Gitian) using the MinGW compiler suite for Windows binaries.

good for you but neither Ubuntu, nor MinGW, VirtualBox, Gitian, etc guarantee fully reproducible builds yet and I'm afraid you will never make it for Windows applications in general.

I'm a bit disappointed that it needs to be said, but to be clear, nothing in this space is official. It's all just services hosted by developers, or other volunteers. Like with bitcoin itself, the onus of validation lies entirely with you.

I totally agree with you, however in my opinion the idea of big open-source projects like Bitcoin is to provide the transparency in the highest possible level, avoiding any kind of obfuscation. Otherwise the validation process doesn't really make sens to me.

It is useless and not practical to require all commits to be signed - the signed merge commits are enough.

No security would be added by requiring random contributors to sign their commits and, from the part of maintainers, signing merge commits are enough to cover all commits under the signed one; unless you have a PoC that suggests otherwise, of course. Even if maintainers would, somehow, sign each and every commit that would just show they are good with automation and their keys are not very well cared.

Redundant to say but don't take what I say as anything representing the project or any of its maintainers/contributors as I'm nobody here and do not represent anybody but me.

unless you have a PoC that suggests otherwise

Good point.

Closing for now. Unless there is a specific suggestion on how to make the "source code [...] more secure" having this issue open serves no purpose.