Bitcoin in general, and Wasabi specifically is high risk software. We need the highest security standards in all regards, including the development and review process.
There is a huge issue of phising sites publishing wrong and malicious versions of Wasabi.
The released packages are signed with @nopara73 gpg key, that's a good start, but that is not yet enough. Signing packages does not secure individual commits, and is thus useless when building from source.
We need a secure way to verify the commits AND reviews of several developers.
@FrankBraun's brilliant code chain solves many [all?] of these issues. This ready to use protocol includes GPG signatures of the individual commits, as well as for the review and merges. A user can select to only install commits that have met a threshold of review signatures. The signatures are stored in a hash chain, thus it's temper evident. It also allows for key rotation.
Trust us, bro!
We are constantly adding more and more administration around what gets into the master (for example at the beginning I was just pushing code to the master, didn't have CI, nor regtest, etc...)
But this is overkill at this point.
Btw the usefulness in signing of individual commits is highly debated.
Not sure if anything can be "overkill" in regards to software review and verification of a Bitcoin wallet.
And afaik, this would only include a chain of signatures in a file in the repo. In this sense it's a protocol similar to git, and it runs alongside it.
The attack is not hypothetical, at all!! There are already phising sites with wrong builds. Not a big step to introduce malicious commits...
I am very much in favor of at least strongly considering the integration.
The attack is not hypothetical, at all!! There are already phising sites with wrong builds. Not a big step to introduce malicious commits...
I review every commit. PGP doesn't do any good for this.
But I don't know that you did!
Withe code chain, every user knows that every commit was verified by for example 2/3 @nopara73 @lontivero @molnard.
For the user this is one single verification, might even be done automatically before the start of wasabi or something.
Smuggler summarizes it well in this tweet thread
You need one root of trust establishment, which means knowing any previously valid head of the codechain and trusting it. Afterwards the codechain verifies that the repo contains a valid codechain that covers the repo. For root of trust there is the optional of manual or DNSSec. One should keep the scenario in mind for which codechain was built. The main objective is to prevent insider attacks on code development, and to manage secure updates of software. It is to prevent outside coercion from being effective against code&infrastructure we work on.
Just to clarify, Codechain doesn't have anything to do with PGP and you do not sign every commit. It is orthogonal to Git. What you sign is releases (however you define that) and it let's you review and sign the diff between the last release and the new one. It really makes sense if you have more than one person reviewing and signing code, in order to prevent forced (as in $5 wrench attack) code updates.
But your call, I have no stakes in you using it.
Yes, thanks for the correction Frank! Though I think it would be possible for the devs to sign every commit [as is done already], and then use code chain for the review and merge? This would combine verification of the commit developer with the verification of review.
Here is a detailed walk-through of the protocol.
I'm re-opening this issue because I really think that this is a smart choice to use for secure code signing. To summarize the main advantages I see:
This has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Although codechain is a lovely tool, it seems there's no consensus to implement it.
I'll review any effort to do so though.
Closing for now.
Most helpful comment
Just to clarify, Codechain doesn't have anything to do with PGP and you do not sign every commit. It is orthogonal to Git. What you sign is releases (however you define that) and it let's you review and sign the diff between the last release and the new one. It really makes sense if you have more than one person reviewing and signing code, in order to prevent forced (as in $5 wrench attack) code updates.
But your call, I have no stakes in you using it.