bitshares1-core
bitshares1-core copied to clipboard
bitshares
sign release tags
We should sign release sha256sums and Git commit hashes, and publish it as public_data from some official account. So anyone with access to the blockchain can verify a given source or binary. Also public_data allows us to easily handle revocation -- if we want to "unsign" a release we can just remove its hash.
Can we have this: https://ariejan.net/2014/06/04/gpg-sign-your-git-commits/
@theoreticalbts Why would you want to publish the signature on the chain by everyone? Isn't that just bloating the chain?
Can we have this: https://ariejan.net/2014/06/04/gpg-sign-your-git-commits/
Yes this issue is to remind me to begin signing the release tags and also checksums for the builds.
GPG is a major PITA to use. I understand how to use BitShares -- indeed it is trivial for anyone with a BitShares account to publish stuff in public_data -- but I'd have to wade through a ton of man pages to use GPG and I'd face the thorny problem of how to distribute the GPG signing pubkey securely. If you have the pubkey for download on the same server as the release, it offers exactly zero security -- anyone who can replace the release can also replace the pubkey.
Also, AFAIK there is no way to revoke a commit signature on a GPG commit.
Publishing a couple hashes a month in a single account's public_data is such a small amount of "bloat" that it doesn't matter. Anyone with a version of the client already will be able to easily verify the next version hash.
If @vikramrajkumar wants to go through the trouble to produce GPG signatures for tags, I'd be fine with that. But I think our own PKI since it can easily support this use case.
I see .. a single (known) account to hold the public_data .. makes sense to me .. thanks for the clarification!
Can't we also publish the individual GPG fingerprint in there and build a second ~~web~~ blockchain of trusted GPG fingerprints?
Also, AFAIK there is no way to revoke a commit signature on a GPG commit.
Can't we also publish the individual GPG fingerprint in there and build a second blockchain of trusted GPG fingerprints?
How about using a GPG key specifically for the policy of revocable code signatures and including that GPG fingerprint in the public_data of the signing accounts. Developers can then use the git --gpg-sign feature to use that GPG key to sign the release tags, and users of the source code will have to adopt the policy of checking if the key used to sign the tag is active in the respective dev's public_data on the blockchain at the time they wish to use the signed release.
Furthermore, since it appears a git tag can only be signed by one key (is this correct?), developers can adopt a policy of submitting a sequence of trivial commits that are each signed by their GPG key prior to the final release tag signed by the final dev. Cautious users can check the diff between each subsequent trivial commit (probably something as simple as a line added to some text file stating the developer has signed off for the release) to ensure there were in fact no code changes made between the start of this sign chain and the release tag. This effectively implements multisig on the codebase of a given release.
Although GPG is frustrating to use sometimes, I think it is important to support GPG since it is so widely used in addition to whatever BitShares specific validation system we end up using for validating upgrades. The first time a cautious and advanced user wants to install BitShares, they have no access to the blockchain to get the hashes of releases. However, they likely already have access to GPG tools and may be able to leverage web of trust to get access to the dev's code signing keys (even if they aren't as revocable as we would like them to be) to validate the initial build.
Finally, none of this is suitable for a regular user downloading a pre-compiled upgrade to the client. I agree with theoretical that the devs should put the sha256sum of the upgrade release binaries in their public_data (at least for the releases made within the last year if they are worried about blockchain bloat). But even that is not user friendly enough. Eventually, I would hope an upgrade tool could be built into the client which allows the user to point it to a downloaded compressed archive containing the relevant binaries of the new release along with some kind of authentication manifest file which includes important signatures of the binaries. The client would check the archive and list the BTS account names that have valid signatures on the given release and prompt the user to either cancel if not enough of the dev's BTS account names show up (and/or delegate account names) or to click the upgrade button which will automatically close the client and launch the upgrade installer.
The only remaining case will then be when regular users want to download a pre-compiled client release for the first time on their computer (meaning they don't already have a working client installed). We can't expect regular users to fiddle around with GPG and web of trust, so unfortunately I think the best that can be done here is to just rely on HTTPS and trusting the bitshares.org server.
