Open nealmcb opened 8 years ago
Sure, TUF certainly can be used and is used in this way. There isn't any requirement to have an online connection. Updates could come by USB stick, CDROM, floppy drive, carrier pigeon, etc. You can give TUF a local file path to download_updater(...) and this works out of the box.
Thanks for the question! Vlad: please add an FAQ to address this and some of the other popular questions.
On Thu, Oct 27, 2016 at 4:46 PM, Neal McBurnett notifications@github.com wrote:
Many of the most important computing systems, such as systems that manage root keys, or tabulate votes in elections, or secure other highly sensitive data, are kept offline and never connected to the Internet. I'm hoping that TUF could be used for such computers, given some sort of sneakernet polling mechanism and reliable source of the time-of day (e.g. via GPS). But I don't see any discussion of that. Given that TUF itself relies on having secure systems to manage TUF root keys, it would be helpful to clarify this.
Has it been done? Are there any caveats to keep in mind?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/theupdateframework/tuf/issues/388, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XD09GeFMvrhtBq3u_W6bAWQPm-c0dks5q4Q24gaJpZM4Kiznn .
I suppose these offline systems can also retrieve updates from other systems (acting as software repositories) reachable on a connected network.
We need to add a note to the FAQ
There's two cases to consider:
Case 1 is strictly speaking not spec-compliant: Success in at least downloading a new timestamp seems to be required (this could be just a result of the specification not really mentioning locally cached metadata at all). I think ngclient currently implements this strictly and so did the legacy client.
Case 2 does not work quite out-of-the-box but it's close: instead of the default RequestsFetcher, one would have to write a fetcher implementation that uses a local directory as a repository: this should be about 10 lines of code.
I don't think I want to include that in the library (without seeing actual users) but we could add a examples/offline-client-example/
that implements this?
This may relate to an Uptane proposal for offline updates
This may relate to an Uptane proposal for offline updates
Interesting. The reasons for the added complexity (new top level roles) in their offline update seems to be their director-model: they want the repository to decide the update contents, except in this one case they have to override that. So likely this is not relevant to TUF/python-tuf since we have no need for that?
Actually there is another detail in the uptane design that is relevant: that a client might want to run "normal" updates and "offline" updates using the same metadata (think of a wireless device that also has a USB for attaching a drive with updates)... This scenario is indeed a little tricky with "standard TUF" (as the requirements for the timestamp/snapshot keys might be quite different when they are on a USB disk).
Many of the most important computing systems, such as systems that manage root keys, or tabulate votes in elections, or secure other highly sensitive data, are kept offline and never connected to the Internet. I'm hoping that TUF could be used for such computers, given some sort of sneakernet polling mechanism and reliable source of the time-of day (e.g. via GPS). But I don't see any discussion of that. Given that TUF itself relies on having secure systems to manage TUF root keys, it would be helpful to clarify this.
Has it been done? Are there any caveats to keep in mind?