Go-ipfs: Signed releases

Created on 22 Mar 2015  路  20Comments  路  Source: ipfs/go-ipfs

Once Go 1.5 lands we can compile all archs in one place. We can then do signed releases.
It would be ideal to deploy these releases using ipfs itself, using the gateways.

help wanted kinenhancement topireleases

Most helpful comment

You could at least publish signed SHASUMS with each release for the prebuilt binaries. This is independent from Go.

sha256sum <BUILD-OUTPUT-DIR>/* | gpg2 --clearsign --armor --output SHA256SUMS.asc

This will create an SHA256SUMS.asc file (like Bitcoin Core ships with each release) containing all the hashsums of the various binaries and put it in the same directory as the release (e.g. https://ipfs.io/ipns/dist.ipfs.io/go-ipfs/v0.4.15).

All you have to do is publish the corresponding public-key on various locations/sources (Github, ipfs.io website, IRC, forums, ...)

All 20 comments

+1 to this. For now, go with something like SHA-256, not md5.

+1 for sure. I see ipfs going a long way; signed releases are an obvious step and would fit in pretty well with a distribution model that works via ipfs itself.

@gwillen absolutely. I was waiting on Go 1.5 so that I could cross compile locally. But actually, @okket just got it all working based on the syncthing build scripts. See https://gist.github.com/okket/60f2897227fe59dedf76 -- happy to start compiling in a local machine and start doing signed releases. Parts still needed:

  • [x] get cross compiling working (@okket)
  • [ ] code-signing script based on best practices
  • [ ] new build targets in a makefile
  • [ ] tool for users to check our code-signing
  • [ ] fix pinning bugs (#1051 #1008)
  • [ ] S3 pinning
  • @Luzifer, happy to incorporate gobuilder in any of this, though the compilation probably will have to happen locally on my machine, at least for official releases.
  • With deterministic builds, we could also have @whyrusleeping and other community members do their own builds to verify my machine/I haven't been compromised (and gobuilder)
  • would be nice to see how auto-updating can figure into this. @inconshreveable's equinox.io is a great solution in general, though it's not self-hosting (i.e. using ipfs) and i'd prefer it if we dog-fooded our own stuff for deployments. (maybe there's a way to do that?)

How to cross compile IPFS locally:

First, install goxc with go get github.com/laher/goxc. Then build and install the cross compile toolchain binaries with goxc -t. This takes a long time, but is needed only once, of course.

Now cross build:

goxc -q -bc='linux,!arm darwin' -d=~/downloads -pv=0.2.4-alpha1 -tasks-=validate -build-gcflags='-i -wd cmd/ipfs

Windows binaries need two small tweaks: Install a dependency IPFS needs in this case with go get github.com/olekukonko/ts and the cross compile command needs to disable FUSE:

goxc -q -v -bc='windows,386' -d=~/downloads -pv=0.2.4-alpha1-win -tasks-=validate -build-gcflags='-i' -wd cmd/ipfs -build-tags=nofuse

The resulting Windows binary seems to at least be able to print out the USAGE message: https://gist.github.com/okket/66d67f915a132c2a3f5c

Signing binaries on OS X is really easy:

codesign -s "<sign identity substring>" ipfs

Check:

$ codesign -v -d ipfs 
Executable=/Users/okketimm/Downloads/ipfs_0.2.4-alpha1_darwin_amd64/ipfs
Identifier=ipfs
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=98008 flags=0x0(none) hashes=4895+2 location=embedded
Signature size=4343
Signed Time=13.04.2015 08:37:03
Info.plist=not bound
TeamIdentifier=H72RJK679G
Sealed Resources=none
Internal requirements count=1 size=180

Support for this is included in goxc:

 -codesign=     identity to sign darwin binaries with (only applied when host OS is 'darwin')

with go 1.5, cross compilation is:

GOOS=windows go build
GOARCH=arm go build

+1 on this
+1 on that (md5)

+1, both signed and reproducible releases would be awesome.

+1

+1

+1

:+1: for signing.
:-1: :warning: for md5 hashes. Come on: MD5 is broken! Use at least SHA-256 to sign files in a secure way.

also
:+1: for signing
:-1: for md5

I'd recommend SHA512 to make it more futureproof

@dandart

  • https://github.com/jbenet/multihash
  • also, sha512 does not confer significant algorithmic advantage over sha256-- it's the same algorithm with different initial parameters + rounds, so an algorithmic break is liable to break them both.
  • we'll include several digests

yay to signing, I'd go with PGP (GnuPG)

Yes please!

+1

+1

You could at least publish signed SHASUMS with each release for the prebuilt binaries. This is independent from Go.

sha256sum <BUILD-OUTPUT-DIR>/* | gpg2 --clearsign --armor --output SHA256SUMS.asc

This will create an SHA256SUMS.asc file (like Bitcoin Core ships with each release) containing all the hashsums of the various binaries and put it in the same directory as the release (e.g. https://ipfs.io/ipns/dist.ipfs.io/go-ipfs/v0.4.15).

All you have to do is publish the corresponding public-key on various locations/sources (Github, ipfs.io website, IRC, forums, ...)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

0x6431346e picture 0x6431346e  路  3Comments

kallisti5 picture kallisti5  路  3Comments

funkyfuture picture funkyfuture  路  3Comments

slrslr picture slrslr  路  3Comments

JesseWeinstein picture JesseWeinstein  路  4Comments