I have updated <a href="http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2#Design_goals">http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2#Design_goals</a><br><br><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;">
<div class="Ih2E3d"><br>
<br>
</div>Like the theoretical future attacks on MD5. This isn't really worth<br>
discussion. If RSA suggests that new applications don't use v1.5,<br>
you're not going to convince me I should use it.</blockquote><div><br>Sorry, my point was not that 1.5 was good, just that you went overboard in criticizing OpenSSL for using it. Your original critique mentioned a specific attack, remember.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
>> > I did look at JAR files, and decided that their format lacked some<br>
>> > desirable<br>
>> > features. They are based on md5 hashes, which are close to broken; they<br>
>> > do<br>
>><br>
>> You are wrong.<br>
>> <a href="http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures" target="_blank">http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures</a><br>
><br>
> My reading of this is that there are three stages to a signature.<br>
> 1. manifest file: each subfile is signed by an arbitrary set of hashes<br>
> including md5<br>
> 2. .sf file: an arbitrary subset of the files in manifest. Each entry in the<br>
> manifest, including hashes, is signed by md5 alone.<br>
> 3. digital signature: an RSA (+md5), DSA, or PGP signature on the .sf file.<br>
><br>
> Thus md5 appears 2 or 3 times in this chain, and in step 2 there are no<br>
> options or redundancy. While a naive view would say that the constraints on<br>
> the manifest entry format are tight enough to make it more difficult to<br>
> forge a signature by breaking step 2, a meet-in-the-middle attack could<br>
> theoretically break it in as little as twice the time needed to break md5.<br>
> Also, step 3 does not allow for a simple rsa+shaxxx signature without using<br>
> pgp.<br>
<br>
<br>
</div>I gave you the wrong URL. Let's reboot with<br>
<a href="http://java.sun.com/javase/6/docs/technotes/guides/jar/index.html" target="_blank">http://java.sun.com/javase/6/docs/technotes/guides/jar/index.html</a><br>
<br>
which correctly deprecates the MD5-ish-ness of earlier specs.</blockquote><div><br><br>
I get the same error on reboot. Reading that file, I see no relevant
change to the section in question. It still looks as if it has at least
one, and up to 3, MD5-only steps to me. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(And don't you find it ironic that you're arguing for SHA against MD5<br>
here, but for v1.5 RSA signatures against v2.0 above?)<br>
<div class="Ih2E3d"></div></blockquote><div><br>Not for v1.5, just against being too dismissive. I agree, v2.0 is the way to go.<br><br></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>
> (Sorry, I realize that I am not fully explaining my thoughts here, because<br>
> it is beside the point. I assert that there is a way, but there is no good<br>
> way, within this format, for a master key to say "Signatures from key xxx<br>
> are valid, as long as their signed metadata states that they were requested<br>
> by activity yyy". Explaining the details of the bad way I can imagine is<br>
> unimportant; if you have a good way, let's talk about that instead.)<br>
<br>
</div>Why does this have to be part of the JAR file format? Isn't this a<br>
function of rainbow?<br>
The JAR file has a collection of signatures. Determining whether this<br>
is a *sufficient* collection of signatures is not something that JAR<br>
should be doing. That is application-level semantics. I content that<br>
there is nothing OLPC-specific about a collection of files and<br>
signatures.</blockquote><div><br>If all or most signatures have a special, one-to-one relationship with some associated metadata, and in some cases cannot even be created by an activity without Glucose adding that metadata, it seems to me there are several reasons to prefer including such metadata in the same file or at least the same directory. This is not possible with jar files, so any solution is more or less a hack.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
>> > user; they interact poorly with differential versioning storage; and<br>
>> > they do<br>
>><br>
>> They in fact interact quite well. See<br>
>> <a href="http://wiki.laptop.org/go/XO_updater#Application_updater" target="_blank">http://wiki.laptop.org/go/XO_updater#Application_updater</a><br>
><br>
> Ouch. This is somewhat of a monster of a year-old unimplemented<br>
> specification. It definitely has its attractions, but does not address the<br>
> problem I was attempting to refer to: compressed files will have much<br>
> noisier diffs from version to version. On a compressing, versioning file<br>
> system like jffs + olpcfs, storage should be in an uncompressed archive<br>
> format like tar IMO. Note that, with Develop, there may be dozens of<br>
> versions of one activity on the same machine; the redundancy between<br>
> versions dominates the redundancy within a given version (and the latter is<br>
> taken care of by jffs2 at the lowest level anyway.)<br>
<br>
</div>Zip files can, of course, be stored with uncompressed entries. On<br>
disk format does not need to match distribution format. Delta storage<br>
on the file system (or journal) makes most of what you seem to be<br>
claiming irrelevant. Perhaps you need to study the internal structure<br>
of ZIP more closely? (While you are at it, studying how rsync works<br>
will help you understand how compression and delta storage interact;<br>
in particular look at the --rsyncable option to gzip.)</blockquote><div><br>I am specifically talking about delta storage. A naive tgz causes an obnoxiously large delta. A tarfile can have tiny deltas. I am not sure where zip and --rsyncable lie on this continuum, and whether they are good enough. (--rsyncable is interesting, and I was not aware of it.) I do not even know which of those two options is better. This is a question that should be answered empirically, with some real bundles as examples.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> Obviously, I need to state my design goals more clearly and explicitly; it<br>
> is my fault you are puzzled. I will begin to compose an email to do that<br>
> now, meanwhile I will send this off.<br>
<br>
</div>Yes. Rebooting to<br>
<a href="http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2" target="_blank">http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2</a>, there is no<br>
use case or rationale, just a long list of required files. And the<br>
second sentence on that page is false. I'd recommend *starting* with<br>
the rationale, getting it discussed properly, and *then* working out<br>
the on-disk structure. [Again, I claim that there are no requirements<br>
on the on-disk structure which JAR can not provide.] </blockquote><div><br>Can, yes. However, when is it worth using an established format? I would argue that when it would be excruciating to use existing tools for that format by hand; when most such tools are written in a language that does not even run on your target platform; and when your special needs are large enough and against the grain of the format enough that using that format makes the job harder, both in terms of initial programming effort and upkeep; then the gain is not worth it.<br>
<br>Jameson<br></div></div><br>