
The Update Framework - ashitlerferad
https://theupdateframework.github.io/
======
heavenlyhash
Everyone: Read this. At least the threat models.

Do not assume all software you currently use gets these things right.

------
wtbob
From the spec:

> Delegated trust can be revoked at any time by the delegating role signing
> new metadata that indicates the delegated role is no longer trusted.

This is a mistake, as it means that a client must receive the new metadata in
order to be made aware of the revocation. The correct approach is either to
delegate trust for a particular time period (determining how long is a risk-
based decision), or to specify an online trust check (this fails safe).

~~~
evancordell
Every metadata file, including those that specify delegations, have an
expiration. There are also higher-level expirations in the snapshot and
timestamp files (a delegation won't be trusted if it's referenced by an out-
of-date snapshot or timestamp)

I.e. there are multiple time-based controls in place

------
doublerebel
So obviously we have to wonder why TUF hasn't been applied to NodeJS's npm.
All I can find is a suggestion that maybe someone from TUF posted to a node
mailing list in 2014 [1]. Any more recent info?

[1]:
[https://groups.google.com/forum/m/?fromgroups#!topic/theupda...](https://groups.google.com/forum/m/?fromgroups#!topic/theupdateframework/GbWtUbnO8_I)

~~~
raesene10
AFAIK several language package managers have looked at implementing TUF for
their repositories, but the only live implementation that I know of is Docker
Content Trust.

I kind of think it's an important part of secure management of libraries. As
the Fosshub breach last week showed, software repo's are tempting targets for
attackers...

~~~
bennofs
Hackage/Cabal also has at least a partial implementation of TUF.

~~~
cm3
And opam (OCaml) is working on it too.

------
cookrn
The Github PR for merging this into Rubygems is ~3 years old:
[https://github.com/rubygems/rubygems/pull/719](https://github.com/rubygems/rubygems/pull/719)

------
amelius
Shouldn't this be part of the OS?

~~~
djsumdog
_sigh_. I know there are those in the Python/Pypy community that thing
everything should be done via pip; not the system manager. Others say we
should have system packages (and they make elaborate systems that check for
new python packages they use and build them with fpm).

I really prefer the system managers, but what if things don't get new packages
in a timely manager. When I was on openstack security, we used the Cannonical
repos since they updated faster than the Debian repos, but some major exploits
would be left out there for half a month (which lead down the path of; do we
want to run our own CI-builds so we can deploy CVE patches immediately).

This isn't even getting into the issues with Java/Scala/Groovy projects that
could have jars with exploits embedded within the project (most OS packages
let projects keep their own jars, instead of using a set of system jars.
Gentoo tries to use system jars, but oh boy is that it's own crazy mess).
There are lots of programs that embedded C/C++ libraries for stability/error
reporting (I'm looking at you Firefox/Libreoffice) and hence there are
scanning tools for finding these embedded libraries with security issues (some
guy did a talk on this at Ruxcon 2012 I believe).

TL;DR It's turtles all the way down.

------
breakingcups
Quite obligatory XKCD: [https://xkcd.com/927/](https://xkcd.com/927/)

~~~
adontz
While this link is the expected joke, it is not joke at all.

I'm writing software updater right now. Security is one of major concerns.
Target platform, both client and server side is Linux. I write most of the
code in Python. Looks like great opportunity to use TUF. But it is not. My
updater has so many specific requirements that TUF is not nearly what I need.
More than this, TUF is not subset of what I need and cannot be foundation for
what I need, even from security perspective.

~~~
bennofs
Can you share what your different requirements that are not supported by TUF
are?

~~~
adontz
Software is split into a few overlays. Each overlay is filesystem slice, some
overlays may have intersection. They are merged in specific order to get the
final filesystem. Some overlays may be version-related (v1, v2), some
environment-related (test, live), some may contain specific device
configuration. Ordered overlay set forms an update stream. (That's just
terminology we use, I do not want to teach somebody how to call things right)

Initially client knows only own hardware ID (which is just sha256 of part
serials, MAC, etc.), and registers itself on server, which is allowed only
from trusted networks. During registration client receives unique HTTP client
certificate. Later administrator approves registration and assigns client
specific stream. Stream may include sensitive information, like unique
credentials to access some other services. Some overlays, which are not
secret, like executables, 3rd party libraries, OSS stuff, are just rsynced to
save time and bandwidth, but others like configuration and credentials, are
downloaded over HTTP with client certificate authentication. Overlays are
merged on client side in memory and applied in semi-atomic way (series of file
moves within partition, not writes or other I/O in between).

There are a few other requirements, like log if devices tries to register
second time, log if device tries to register from non-trusted network, log
every update attempt, successful or failed, etc. And this is of course just
brief overview. For instance, administrator approving registration is not a
single person, but group of administrators, each with different permissions on
streams. Client cannot download stream of some other client, and cannot get
any information on overlays used by other clients, etc.

I do not see any way generic updater [framework] (not only TUF) to fulfill my
requirements not causing more problem, than solved.

~~~
evancordell
Most of what you describe is external to TUF (authenticating, logging, the
specifics of the data you're protecting and how you transfer it once it's
validated).

A couple things you pointed out are definitely hard with TUF right now:

> For instance, administrator approving registration is not a single person,
> but group of administrators, each with different permissions on streams

TUF is being actively developed and this type of approval pattern is planned:
[https://github.com/theupdateframework/tuf/issues/346](https://github.com/theupdateframework/tuf/issues/346)

> Client cannot download stream of some other client, and cannot get any
> information on overlays used by other clients, etc.

This is currently a limitation of TUF, but it is known and there are some
tentative plans to address it. If you have specific use cases you'd like to
contribute to the discussion, there are GitHub issues and the mailing list.

I think it's worth pointing out that even if you don't use TUF, you need to be
thinking about the vulnerabilities it's designed to protect against. Once you
start doing that you'll probably end up with something similar modulo formats
and transport.

------
fit2rule
We've got a great update framework already, if only everyone would use it:
git.

Seriously. I can't think why this wouldn't "just work".

~~~
tonyedgecombe
When your only tool is a hammer everything starts to look like a nail.

~~~
username3
When your only proverb is a hammer everything starts to look like a hammer.

