Create Signed Releases

[whoabuddy]

Is your feature request related to a problem? Please describe.

It would be nice if the stacks-blockchain releases were signed, similar to what is seen with Bitcoin Core.

Describe the solution you'd like

There are two things that would need to be established:

• the list of approved signers
• the workflow for release signatures

In the method described here by Debian, it would require someone to download the release, verify the release, sign it, then upload the detached signature to the GitHub release page.

This is less ideal as it relies on one approved signer, but the added security would allow for other websites to reliably host downloads and provide release information, leading to further decentralization.

Describe alternatives you've considered

I am sure there are other methods and may be some missing steps listed above, but at the very least, I wanted to put this idea out there and find the correct road to implementation.

Bitcoin uses Gitian as "a secure source-control oriented software distribution method," with a documented release process, a repository of signed releases, and documentation for their Gitian building process.

Additional context

CoinDesk released an article in January covering some of the challenges around decentralizing the core development of Bitcoin, and Stacks is in a great position to balance control between the Stacks Internet Open Foundation and other ecosystem entities involved in core development.

Since verifying the signature is not required, this would have no impact on existing miners.

There may be an interesting use case to host the releases using Gaia storage, either through a domain linked to Runkod as a service, or through a direct link to the release and/or signature on a Gaia hub.

There was a phishing attempt via blockstack[dot]live over Discord that appeared twice, cloning both the blockstack.org and stacks.org website in order to trick users into downloading a Windows executable with a possible remote access trojan.

[jcnelson]

Hey @whoabuddy,

We're kind of already doing this going forward by announcing new releases via announce@stacks.org (please subscribe by sending an email to announce+subscribe@stacks.org if you haven't already). The emails sent from this address will be signed by the Foundation, and will contain the cryptographic digests of all pre-built binaries as well as the git tag for the release's source code. I've already sent an email to this list that describes how to verify the signatures here.

I think it might be good for the blockchain team to sign at least the tag's digest whenever we do a release. Then, as long as the code matches the hash and the signatures are good, anyone can build the software from source and be confident that it's the right software (including downstream packagers).

Since verifying the signature is not required, this would have no impact on existing miners.

Oh, verifying the signature is very much required :) Otherwise there's no point to signing.

There was a phishing attempt via blockstack[dot]live over Discord that appeared twice, cloning both the blockstack.org and stacks.org website in order to trick users into downloading a Windows executable with a possible remote access trojan.

Yeah, I've seen these clowns years ago. Just a couple points of clarity:

• We need people to get in the habit of verifying signed code (or make it automatic somehow). Otherwise people will download and run trojan'ed binaries.
• Signatures won't help if the "trojan" is really a signed but out-dated version of the node with a known security vulnerability that the attacker can exploit.
• The idea of putting copies of the binaries into a Blockstack app is appealing because it automates signature verification, but then phishers will just make malicious copies of that Blockstack app that trick you into thinking that the signature is valid.

So, we'll still need to be vigilant for phishers even if everyone verifies the signatures.

[CharlieC3]

In the method described here by Debian, it would require someone to download the release, verify the release, sign it, then upload the detached signature to the GitHub release page.
This is less ideal as it relies on one approved signer, but the added security would allow for other websites to reliably host downloads and provide release information, leading to further decentralization.

@whoabuddy
The signing of the binaries can be automated in the GH workflow which performs the release, so we might be able to mirror the Debian method with some improvements there. If the signage was automated and performed by a central authority (i.e. the gh workflow), how much extra value would we get out of having signatures from other people in addition to the automated signature? Is it worth introducing manual steps and complicating the process for that extra value?

I don't think having only 1 signature would be reason enough to delay a release until additional signatures can be acquired, but I do recognize the potential faults in only having one signature. Perhaps a suitable compromise would be to require one automated signature via GH workflow upon a new release, and encourage repo maintainers to asynchronously add additional signatures afterwords at their discretion.

Oh, verifying the signature is very much required...
We need people to get in the habit of verifying signed code (or make it automatic somehow)

@jcnelson
I agree, though I don't think this will have very wide adoption without it being automated. Hypothetically, what would it look like if this were to be verified automatically? I'm guessing the stacks-node binary would have to be shipped with the public portion of the GPG key and verify itself upon bootup?

[zone117x]

FWIW, another respected blockchain project publishes deterministic / reproducible builds for supported platforms along with the sha256 hashes on gh releases and their website. At the same time during release, contributors and community members also build and verify the hashes locally, and then post their approvals (often signed) on various mediums (reddit, irc, mailing list, etc).

It looks like reproducible builds are supported in rust [1], [2]? If so, we already have the docker build scripts setup so that any community member or contributor could do the same thing described above.

[stale]

This issue 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.

[stale]

This issue 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.

[stale]

This issue has been automatically closed. Please reopen if needed.