4 ms·

If you are implementing a software updater, you should use The Update Framework[0]. In this case, the compromise happened because a file server was hacked. A si

If you are implementing a software updater, you should use The Update Framework[0]. In this case, the compromise happened because a file server was hacked. A simple offline cryptographic signature (with proper verification) would have prevented this incident, but it would not allow key rotation and revocation or prevent rollback, freeze, mix-and-match, etc. attacks.[1] [0] http://theupdateframework.com http://theupdateframework.com [1] https://github.com/theupdateframework/tuf/blob/620fa6e95375ca120e1b0a9965d28637b7204093/docs/tuf-spec.txt#L133-L158 https://github.com/theupdateframework/tuf/blob/620fa6e95375c...

Eridrus 11y ago
My first reaction to this was: great, I'm looking at developing some desktop software, I'll just drop it right in. Sadly, it seems like it's implemented in python, and it doesn't really handle anything besides downloading the files. I do wish someone actually built a good update system for desktop software, though it probably won't be relevant for long once enough users migrate to win10, since at that point every dev ecosystem will have some kind of store that handles updates for developers.
- Titanous 11y ago
  Yeah, I realize that depending on your toolchain it's not easily accessible. Ideally there would be a first-class implementation for each platform, but it looks like app stores are where we are headed. Though, that still leaves *nix package distribution, container images, language/framework and packaging as areas that can be helped by TUF. We (Flynn) actually have a Go[0] implementation that you could use to either make a separate updater binary or even compile it into your app using the new alternative build modes coming in Go 1.5[1]. Our implementation also includes some tools to manage the metadata and signing so that you don't have to manually build it. [0] https://github.com/flynn/go-tuf https://github.com/flynn/go-tuf [1] https://tip.golang.org/doc/go1.5#link https://tip.golang.org/doc/go1.5#link
  - Eridrus 11y ago
    Thanks for the link, Go seems reasonably deployable. It's probably not the ideal long term solution, but it seems like it is a good temporary one.

Eridrus 11y ago

My first reaction to this was: great, I'm looking at developing some desktop software, I'll just drop it right in. Sadly, it seems like it's implemented in python, and it doesn't really handle anything besides downloading the files. I do wish someone actually built a good update system for desktop software, though it probably won't be relevant for long once enough users migrate to win10, since at that point every dev ecosystem will have some kind of store that handles updates for developers.

Titanous 11y ago
Yeah, I realize that depending on your toolchain it's not easily accessible. Ideally there would be a first-class implementation for each platform, but it looks like app stores are where we are headed. Though, that still leaves *nix package distribution, container images, language/framework and packaging as areas that can be helped by TUF. We (Flynn) actually have a Go[0] implementation that you could use to either make a separate updater binary or even compile it into your app using the new alternative build modes coming in Go 1.5[1]. Our implementation also includes some tools to manage the metadata and signing so that you don't have to manually build it. [0] https://github.com/flynn/go-tuf https://github.com/flynn/go-tuf [1] https://tip.golang.org/doc/go1.5#link https://tip.golang.org/doc/go1.5#link
- Eridrus 11y ago
  Thanks for the link, Go seems reasonably deployable. It's probably not the ideal long term solution, but it seems like it is a good temporary one.