AU: Support signatures in new-style update images.

AU: Support signatures in new-style update images.

I'm sending this CL out as a first step to supporting signatures in
the images.

BUG=5673
TEST=None

[adlr, 2010-08-13 04:38:29]

[+cc: sumit]

[petkov, 2010-08-13 16:14:47]

LGTM

[adlr, 2010-08-16 21:20:14]

I've moved the length out of the signed protobuf. This is because we may not
know the length of the signatures message until after we've finalized the update
we wish to sign.

This format should be backwards compatible with old clients that don't expected
signed updates (they will discard extra data tacked onto the end of the update
file and unknown params in the protobuf)

PTAL

[petkov, 2010-08-16 21:42:54]

LGTM w/ a question.

http://codereview.chromium.org/3175010/diff/5001/6001
File update_metadata.proto (right):

http://codereview.chromium.org/3175010/diff/5001/6001#newcode122
update_metadata.proto:122: optional uint64 signatures_offset = 4;
Theoretically, this could be a boolean, right? Present/not present. Do you need
to document what value specifies that signatures are not present?

[adlr, 2010-08-16 21:57:00]

It's optional, so if the tag isn't present, it would mean no signature
possible. If it's there, it means a signature may be there.

The advantage of having a length over a boolean is we can choose where the
client looks for the signature, as opposed to hard-coding in that it always
looks at the end. This way we could potentially tack other things onto the
end later.

I'll add comments in to address these questions and submit.

Thanks,
-andrew

On Mon, Aug 16, 2010 at 2:42 PM, <petkov@chromium.org> wrote:

> LGTM w/ a question.
>
>
>
> http://codereview.chromium.org/3175010/diff/5001/6001
> File update_metadata.proto (right):
>
> http://codereview.chromium.org/3175010/diff/5001/6001#newcode122
> update_metadata.proto:122: optional uint64 signatures_offset = 4;
> Theoretically, this could be a boolean, right? Present/not present. Do
> you need to document what value specifies that signatures are not
> present?
>
>
> http://codereview.chromium.org/3175010/show
>