[tor-dev] Why not use The Update Framework? (TUF)
Nick Mathewson
nickm at alum.mit.edu
Wed Aug 7 05:59:28 UTC 2013
On Mon, Aug 5, 2013 at 3:05 PM, adrelanos <adrelanos at riseup.net> wrote:
>> For TBB 3.0, we should use the Firefox updater. We should audit the
> Firefox updater for issues, and triage which of Thandy's features we
> should merge to it. (For example, we might want to sign the metadata
> file if it isn't signed; timestamp it if it isn't timestamped, add
> multiple-signature support, and so on.) [1]
>
> That sounds like reinventing the wheel.
>
>> Thandy was a good research platform, not a long-term piece of software
> we want to support. [1]
>
> Why not use its predecessor, TUF? [2] [3]
TUF was a successor/fork of Thandy, not the predecessor: check out the
license file. (https://github.com/theupdateframework/tuf/blob/master/LICENSE.txt)
(Thandy was based on research originally from Justin Samuel and Justin
Cappos, though, who were the original TUF people and I believe are
still involved.)
> TUF is written in python, and after all those years, TUF developers are
> still maintaining it and actively developing it. I think in future TUF
> will become a mature and widespread solution. Also work is being done to
> let pip (the python library installer) internally use TUF. So it can't
> be so bad after all?
>
> If you have discussed this and reasons for rejecting, fine. Just wanted
> to throw it in, because I think basing this feature on another active
> project (TUF) works better than reinventing the wheel.
Well, it's not like the Firefox updater isn't an active project
either. The advantage of using the FF updater are:
* Actually proven to update Firefox. (That's a big one; updating a
running application in a cross-platform, user-friendly way is much
harder than the "replace files with the latest version" problem.)
* Smaller marginal increase in Windows bundle size, since it
doesn't require a Python interpreter or py2exe runtime for TBBs that
don't ship that.
* Used in production by orders of magnitude more people.
* Has even more maintainers and developers.
* Is even more mature and widespread.
* Likelier to be doable fast by the people working on TBB today, we think.
In the Munich meeting, we weren't sure what the exact disadvantages
are yet; perhaps once we've reviewed the state of the art with FF's
updater, we'll run screaming for the hills. Likely disadvantages
include the kind of stuff that most non-Thandy, non-TUF systems suffer
from.
That said, who knows? If the distance from where FF is to where it
needs to be is too big, we might be wrong. The answer might be to end
up with porting the important parts of TUF/Thandy (metadata
management) to Javascript, and leaving the stuff that Firefox does
especially well (download updates and apply them in a robust and
user-friendly way) as-is.
(BTW, a thought I had: one subtle flaw of the meeting summary format
[and of most of the online stuff I write, I guess] is that it doesn't
do a good job of distinguishing between "I'm sure about this! It's
decided forever"; "I'm pretty sure about this, but let's talk more as
we go forward"; and "I dunno, seems like a good idea, let's try it."
So when you write stuff like that, there's always a risk that you'll
sound like you're dropping ukazes when you're really just trying to
make the best decision you can today, subject to revision tomorrow. So
thanks for asking!)
yrs & best wishes,
--
Nick
More information about the tor-dev
mailing list