[OLPC Security] [Techteam] Crypto export and python-crypto

[Jameson "Chema" Quinn]

>
> OK, I'm spending a lot of time writing replies to you, and you're not
> reading the links I'm sending you.  Please work harder if you want me
> to keep responding.  Please search for 'MD5' in the spec and tell me
> what it says in the last hit.  Thanks.


 Sorry, I missed that. I was misled by the use of the definite article in
the sentence fragment "The corresponding signature file would be:"

>
> > 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.
>
> Your reasoning is poor.  You are creating your own archive format
> because you don't want to create an extra file?  Geez.


I am creating my own archive format because the existing one solves
essentially none of the problems I am interested in, and in fact makes it
harder to solve them and less intuitive for others to understand the
solutions.


>
>
> >> Zip files can, of course, be stored with uncompressed entries.  On
> >> disk format does not need to match distribution format.  Delta storage
> >> on the file system (or journal) makes most of what you seem to be
> >> claiming irrelevant. Perhaps you need to study the internal structure
> >> of ZIP more closely?  (While you are at it, studying how rsync works
> >> will help you understand how compression and delta storage interact;
> >> in particular look at the --rsyncable option to gzip.)
> >
> > 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.
>
> AGAIN, PLEASE READ THE STUFF I ASK YOU TO READ BEFORE MAKING ME READ A
> RESPONSE!
>
> Thank you.


Please, let's treat each other with respect. I did respond to you. It is a
fact that both zip an gzip --rsyncable still have the potential to propagate
a small change, even though both of them do place limits on how far this
change can propagate. I acknowledged this in my response.

You may think it ridiculous that I want empirical data on the relative
sizes. You may be right that zip format can be assumed to be good enough,
given that the most dysfunctional case for zip deltas - a single large
subfile subject to frequent, small, sequentially-early changes - will be
uncommon in a bundle. But please do not yell at me and tell me to "read the
stuff" when you did not give me a link, I did do a google, and my response
reflected that. I have a similar impression that you are reading my
responses superficially, yet I know misunderstandings happen between
intelligent people.

>
>
> > 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.
>
> http://www.google.com/search?q=fastjar


A tool which does nothing in terms of signatures.


> <http://www.google.com/search?q=fastjar>
>
> It is worth using existing formats even if you have to rewrite all
> your tools from scratch, because the format has been used and tested
> and understood by more people than just you.  In fact, formats with
> multiple implementations are *preferred*, because that shows that they
> are well understood.


You are right, if those formats solve the problem you need to solve. If,
even after you rewrite the tools from scratch, they get you no closer to a
solution than you started out, it is at least debatable if that was worth
it.

Consider:
Jar defines only two signature formats (md5-rsa and dsa), both of which are
ready for deprecation. So I have to do that myself.

Jar gives no inherent way to decide what content does or does not need a
signature. So I have to do that myself. (And when I do, I must, for
compliance, uselessly duplicate the list of files which need a signature as
many times as I have signatures on those files.)

Jar gives me, as far as I can tell, no useful tools for building valid
bundles (using fastjar takes about the same number of lines of python as
doing it natively from python, though it is probably faster). So I might as
well do that myself.

Jar does not allow metadata to be included with a signature. So I have to
keep track of metadata in a separate file - not too hard, as you say. Worse,
I have to write the glucose signing service such that it puts this minor but
confusing job in the lap of any other activity which wants to use
signatures. So here, I'm worse off than I was without it.

Even when I do all that, Jar does not give me any help in defining what
chain of signatures is valid. Again, do it myself.

What does it give me? Some directory, file, and attribute names; some
definitions of whitespace, picky line length limits, and some more elements
of an underdefined manifest specification. That's great; I would be happy to
use the naming and other conventions from the jar spec, insofar as they
don't get in my way. But since any checker which validates jar spec
compliance will get me about 10% of the way to proving that a given bundle
is valid by my definition, the fact is in effect I am writing my own spec
anyway. I would say that is more helpful to make that fact clear by
deviating from the jar spec when it is convenient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/0d3c41f0/attachment-0001.htm