<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
As you can see, the present security difficulties stem from the lack of<br>
effort spent on recording user intentions about what permissions should<br>
be applied to what activities. Signatures do absolutely nothing to<br>
address this problem -- they only permit an as-yet undesigned system<br>
interpreter to check whether the authors W of claim X about blob Y knew<br>
secret Z. </blockquote><div><br>This is literally true, of course, but I think that it is a misunderstanding of what Benjamin said. The "signatures" stumbling block is actually the "hashes" stumbling block - that is, the ability to refer to blob Y in a way that is stable across installation/repacking, .pyc compilation, etc, but secure against changes.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">These assertions yield no new power because the Bitfrost<br>
security model asserts that trusting that author W wrote blob Y implies<br>
no trust in blob Y itself. It's a good reason to display hints about<br>
blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author<br>
W, but it is _NOT_ sufficient to grant Y permissions in the initial<br>
default-deny configuration proposed by Bitfrost.</blockquote><div><br>This is also close to true, but not entirely. In general, we will not trust code simply because it comes from a given author. However, Bitfrost is not quite as categorical as you imply. I think that the code/user distinction is primarily a <u>distinction</u> between trust in a user and trust in their code, not a firm declaration that the latter is impossible without explicit intervention. Here's the relevant paragraph:<br>
<br><i>"Unfortunately, software received through a friend or acquaintance is
completely untrusted code, because there's no trust mapping between
people and software: trusting a friend isn't, and cannot be, the same
as trusting code coming from that friend. The friend's machine might be
taken over, and may be attempting to send malicious code to all her
friends, or the friend might be trying to execute a prank, or he might
have written—either out of ignorance or malice -- software that is
sometimes malicious."</i></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
</div>No new bundle format is needed to track activities according to<br>
non-spoofable tokens. All that is needed is to teach the software making<br>
authorization decisions (Sugar) to use the correct token.<br>
</blockquote><div><br>I disagree - for stronger security, a new bundle format which includes hashes is, if not 100% necessary, at least clearly desirable. However, you are right that we can do much better without this, and I am currently working on a patch which does that - for 5657.<br>
<br>Jameson<br> </div></div><br></div>