Module signatures sometimes off by one or a few bytes
forax at univ-mlv.fr
Thu Apr 7 07:59:07 PDT 2011
The temporary file is in my opinion a good option.
On 04/07/2011 03:43 PM, Sean Mullan wrote:
> On 4/6/11 8:29 PM, Weijun Wang wrote:
>> Do we still have time to change the file format?
>> say, put the signature in a
>> separate file?
> That would definitely solve this problem, but has other disadvantages
> because then you have 2 files to keep track of instead of 1.
> You could break up the signatures into two, and have one at the
> beginning covering the header and module-info, and one at the end
> covering the rest of the content, but that seems overly complex.
> Any type of streamable signature format when writing is going to
> conflict with the desire to have the signature near the front of the
> file so that the module-info and signer can be authenticated before
> downloading the entire file.
> I guess I would like to see if there any objections to my proposed
> solution below first. This seems like a fairly simple solution with a
> small bit of performance impact.
>> On 04/07/2011 04:03 AM, Sean Mullan wrote:
>>> Been stuck on a bug for a few days and finally figured it out.
>>> When jpkg is used to create signed modules, it first writes a dummy
>>> signature to the module file. After the rest of the contents of the
>>> module file is written and digested it then seeks back and replaces
>>> with the actual signature. This is because it cannot calculate the real
>>> signature until all of the hashes are calculated. This works as long as
>>> the size of the dummy signature is the same as the real signature.
>>> However, sometimes the length of the dummy signature is off by a couple
>>> of bytes from the real signature. This causes the real signature to
>>> overwrite into the first few bytes of the next section, and when the
>>> signed module is installed, it fails because it cannot identify the
>>> section following the signature. I don't know the exact reason the
>>> length varies, but I don't think it is a bug in the underlying
>>> cryptographic algorithms.
>>> I don't think we can assume the length of the signature will be the
>>> each time it is generated even over the same content. We could add some
>>> padding bytes to try to accomodate the length changing, but that seems
>>> messy. Also, with the addition of timestamps, creating the dummy
>>> signature is expensive because it remotely contacts the TSA.
>>> I think we need a different way of addressing this. One simple solution
>>> is to write the remaining contents of the file (and digest as we go) to
>>> a temporary file, calculate the signature and then write the rest of
>>> module file from the contents of the temporary file.
More information about the jigsaw-dev