Bitcoin Forum

how does bitcoin secure the github?
I don't know much about github, but if the code is sitting at github,
what is to stop someone from changing it?

someone please explain this to me, I am interested.

In order to change the code or files on github you would have to have commit access to the bitcoin repository.
Any outsider altering the code would have to clone it under a new repository, essentially creating an alt coin that no one would use.

Check out the help section on github. https://help.github.com/

They would need to hack the github server to change to code.

Or they would need to set up a phishing site with modified code.

Or they would need to set up a malware on your PC that would show other code on the site , when you visit it, but only for you.

Only person who have login information
can acces to github repository.

...its same as any other website, yoo need password
to acces account

It can't be changed by anyone other than the original developers, unless they were to be hacked of course.

Just as a thought experiment...

If GitHub itself is coerced into serving a modified version of the code, none of the developers can prevent it.

The code is duplicated on every developer's computer.

If the github source changes, then every developer will notice when they attempt to synchronize their local code with the server code.

what if someone working with github has inside ability to get login information?
or do you think people who work at github cannot figure out what someones login or password is at github?
is it a security risk, seeing as how there is money involved with bitcoin?

You, buddy, clearly do not understand how Open Source repo works. Changing the code in Github wont have any immediate impact on bitcoin. You are still immersed in the paradox of a centrally controlled system.

You are forgetting that many nodes and vital parts of the ecosystem are configured to automatically sync and update/recompile using what's on GitHub.

Do you think Bitcoin ATMs get manually updated? Another issue is, what if the developers themselves are coerced to sneak something in?

In other words - shouldn't Bitcoin stakeholders be able to vote on who is the authorized developer?

Source?

Sounds like the wrong approach to me. We are dealing with something that has value to some. Remember "being your own bank" - as cool as it may sound - comes with responsibilities as well.

I remember an exchange was doing auto-updates, but I can't recall the details. Let's hope I'm wrong about that one.

That said, I'm very interested in the implementation of a completely decentralized version of GitHub. I know Git itself by nature is decentralized.

But would be nice if there is a platform that doesn't rely on DNS whatsoever. Perhaps it's still too early for that.

This is certainly a problem in bitcoin XT where only… one? two? individual(s) have commit access.

You can still download it and check it does it?

Also when a release comes out, it usually has a checksum and a signature, any alteration after the release is easily detactable..

So if wallet 2.0 comes out, and it has a hash, but if you sneak something shady in it after, it wont match the hash of the 2.0.

My concern is after people have switched to XT due do the 8 Mb max block size. In that scenario, and assuming they will be coerced to put some unwanted code (eg. CoinValidation—and Hearn was pretty much for that IIRC), how are we going to switch back to Bitcoin Core? We can pretty much assume we won't, with the result that TPTB will have successfully co-opted bitcoin.

I'd rather see the 8 Mb change in Core, or stay at 1 Mb until more people have governance over XT.

If we reach the point where Bitcoin XT forks the blockchains, and has enough support to matter, perhaps I'll put together a wallet that maintains both blockchains in the same wallet.  That would allow users to access either one, and would provide some competition to prevent Hearn and his associates from implementing unpopular features.  If it comes to that, I'll see about creating some sort of diverse group to handle decisions regarding the software.

The scenario being discussed of someone external (e.g. github staff) tampering with the source isn't valid since it would leave the repo inconsistent due to hashing of commits (which would be evident to anyone interacting with the repo when they have a local copy with some commits). Additionally, tags can be GPG-signed, which additionally prevents tampering since changes would break the signature.