Module signatures sometimes off by one or a few bytes

[Rémi Forax]

The temporary file is in my opinion a good option.

cheers,
Rémi


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?
>
> Yes.
>
>> 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.
>
> --Sean
>
>>
>> Max
>>
>> 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 
>>> this
>>> 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 
>>> same
>>> 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 
>>> the
>>> module file from the contents of the temporary file.
>>>
>>> Comments?
>>>
>>> Thanks,
>>> Sean