[tahoe-dev] reproducible builds for Tahoe-LAFS: where do we start?

Guido Witmond guido at witmond.nl
Sat Aug 31 15:18:35 UTC 2013


On 08/31/13 16:12, Zooko O'Whielacronx wrote:

> 
> One thing that worries me about this issue is that it is one of those
> things were different open source projects can reasonably assume that
> it is Someone Else's Problem to fix this. I've often seen this: when
> there is an issue that spans multiple open source projects, that it is
> hard to make progress on that issue, since every open source project
> has a theory of how it ought to be fixed by some other open source
> project taking responsibility for it.
> 
> So what can we do to push on this issue now?
> 



All the things you mention are good to pursue, however, you miss one
important part.

The current design of operating systems is *allowing* any process that
gets to run access to the whole of the system. A single lapse of
judgment of the user could render a whole computer (and all it's data)
in the hands of an adversary. The result is the widespread malware and
spying problem.

The technical term for these designs is Ambient Authority. [1]

Many people are running into the problem and looking for solutions,
hence the popularity of virtual machines where one can control the
environment. (And with the environment, the permissions). I see virtual
machines as a very course grained attempt to reach the principal of
least authority.

Zooko, I know that you know all about it, it's part of the design of
Tahoe LAFS. It is this theoretic background that makes Tahoe so robust.

The reason I bring it up is that we need to shout it from the roofs what
the problem with current operating systems is. People need to know that
there are better designs [2,3.4...] for their computers.

Guido.

[1] Wikipedia: https://en.wikipedia.org/wiki/Ambient_authority
[2] genode.org
[3] http://www.linuxjournal.com/magazine/minorfs
[4] https://en.wikipedia.org/wiki/Principle_of_least_authority
[5] https://en.wikipedia.org/wiki/Capability-based_security
[6] https://en.wikipedia.org/wiki/KeyKOS
[7] https://en.wikipedia.org/wiki/CAP_computer



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130831/a2073db4/attachment.asc>


More information about the tahoe-dev mailing list