"ipfs update check" showing no updates on version 0.2.1

[headbite]

On version 0.2.1 "ipfs update check" responds with "Error: No update available". As of today 0.2.3 is the latest version. I've since manually updated using the go get method.

[jbenet]

Yeah sorry ipfs update broke. We need to fix it. I want to start using ipfs itself for updates. This along with prebuilt (signed) packages will make it way easier to install and stay up to date.

If anyone is interested in helping tackle this, reply here

—
Sent from Mailbox

On Fri, Feb 27, 2015 at 12:36 PM, headbite [email protected]
wrote:

On version 0.2.1 "ipfs update check" responds with "Error: No update available". As of today 0.2.3 is the latest version. I've since manually updated using the go get method.

Reply to this email directly or view it on GitHub:
#837

[Luzifer]

Please tell me more what you're talking about signed packages. What kind of package, what kind of signature?

[jbenet]

@Luzifer thinking of deploying the binaries, kind of what gets built with your cool tool, with ipfs itself to ipfs clients. Ideally the sig would be in a merkledag node itself (the signature datastructure isn't there yet), but mabe we could do with a sig file in the same dir for now?

[Luzifer]

Yeah, I made some modifications especially to the upload process which should allow to add IPFS upload with only a bit of work. This is on my list right after the implementation of build-indicators (for people to see when the build is started)… The zip files currently are in fact hashed so their integrity should be verifiable by now. (I only don't display the hash somewhere but that's a no-brainer)

[jbenet]

Yep. I'd love to get to the point where users could verify that the update matches a particular git hash (not trivial unless they compile themselves and compilation is deterministic), and that it was signed by a private key the core dev team controls. There's lots of work done in this area already. Let's just do whatever makes the most sense for us.

[Luzifer]

You can… The build process is done by an open source image so you can review the image is not changing anything. Also you could tag versions (my build system is using tags to keep older versions) with signed tags (git tag -s -m v1.4.0)… I'm doing this for example for my gobuilder itself…

luzifer@knut-workstation01 ~/g/s/g/L/gobuilder (master)> git show --show-signature v1.4.0
tag v1.4.0
Tagger: Knut Ahlers <[email protected]>
Date:   Sat Feb 28 20:23:16 2015 +0100

v1.4.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAABAgAGBQJU8hWkAAoJENwnKf3TS+mewGwIAIU8Nh2qkh6QgMhOyKeKzxgW
Bki3bjHcFocIJCH+ulmC7ZBqWUZLWyyOcLFS6yTSj2INqXSNiUmm9AjS1kAZG1IE
WGm3afJD5iCX2uHjOfjAzFUdgbNmRmS3boREe/mBZq5ZbySxgi5mEdmc21AhGzYn
1GZ5IlCtoxOIAQmMEs2r1JQkgEr3w5kLw7XMrkIMhhHmIsxRCYrXtIOIJalG30DU
Ohq1OMChN4DkoKT0ANMCGVXWQU3zurgE8RBkzszbWe66Z0OYL0TkD6CBr2d9UE9t
vHuvKr8LiiSENp9RmkFJDVfwa7/xjaCUnTtpDjDznNlWAAJy44xtKmWn+MsIe8Y=
=T/z/
-----END PGP SIGNATURE-----

commit 90c9251c8bb9ecc76549c27c8c36d87ce277134a
Author: Knut Ahlers <[email protected]>
Date:   Sat Feb 28 20:23:16 2015 +0100

    Prepared release 1.4.0

[...]

luzifer@knut-workstation01 ~/g/s/g/L/gobuilder (master)> git tag -v v1.4.0
object 90c9251c8bb9ecc76549c27c8c36d87ce277134a
type commit
tag v1.4.0
tagger Knut Ahlers <[email protected]> 1425151396 +0100

v1.4.0
gpg: Signature made Sat Feb 28 20:23:16 2015 CET using RSA key ID D34BE99E
gpg: Good signature from "Knut Ahlers <[email protected]>"
luzifer@knut-workstation01 ~/g/s/g/L/gobuilder (master)>

And http://gobuild.luzifer.io/github.com/Luzifer/gobuilder?branch=v1.4.0

Maybe I can build in verifying the tag into the gobuilder and display it as a verified build if it is signed by someone…

[jbenet]

Also you could tag versions (my build system is using tags to keep older versions) with signed tags…

Yep, signed git tags may be the easiest way to go for now.

Maybe I can build in verifying the tag into the gobuilder and display it as a verified build if it is signed by someone…

Sounds like a good plan. Still, we dont have a good way to verify this builder (or any other) hasn't been compromised (without running the compilation separately in a "trusted compiler"). (cue lamport)

[Luzifer]

Still, we dont have a good way to verify this builder (or any other) hasn't been compromised (without running the compilation separately in a "trusted compiler"). (cue lamport)

Hmm thats hard. The image is built by automatic build system of hub.docker.com from latest GitHub code… You could review that… But still there is no guarantee it hasn't been modified in between… I don't have any idea how to verify the build system… It's using the official golang:cross container but that also isn't verified…

[whyrusleeping]

ipfs update is much cooler now. i will close this issue