Nicolas Williams wrote: > > One possible problem: streaming [real-time] content.
Brian Warner wrote: > Yeah, that's a very different problem space. You need > the low-alacrity stuff from Tahoe, but also you don't > generally know the full contents in advance. So you're > talking about a mutable stream rather than an > immutable file. Not mutable, just incomplete. Immutable streaming content needs a tiger hash or a patricia hash, which can handle the fact that some of the stream will be lost in transmission, and that one needs to validate the small part of the stream that one has already received rather than waiting for the end. > upgrade bundles are produced by a very strict process, > and are rigidly immutable [...] For software upgrades, > it would reduce the attack surface significantly. But how does one know which immutable file is the one that has been blessed by proper authority? Although Version 3.5.0 is immutable, what makes it Version 3.5.0, rather than haxx350, is that some authority says so - the same authority that said that your current version is 3.4.7 - and it should not even be possible to get a file named by some different authority as an upgrade. Of course, one would like a protocol that committed the authority to say the same thing for everyone, and the same thing for all time, saying new things in future, but never being able to retroactively adjust past things it has said. In other words, upgrades should be rooted in an append only capability. I suppose this could be implemented as a signed dag of hashes, in which whenever one upgraded, one checked that the signed dag that validates the upgrade is consistent with the signed dag that validated the current version. _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
