AU: Support signatures in new-style update images.

update_metadata.proto

 // Copyright (c) 2009 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Update file format: A delta update file contains all the deltas needed
 // to update a system from one specific version to another specific
 // version. The update format is represented by this struct pseudocode:
 // struct delta_update_file {
 //   char magic[4] = "CrAU";
 //   uint32 file_format_version = 1;
 //   uint64 manifest_size;  // Size of protobuf DeltaArchiveManifest
 //   // The Bzip2 compressed DeltaArchiveManifest
 //   char manifest[];
 //
 //   // Data blobs for files, no specific format. The specific offset
 //   // and length of each data blob is recorded in the DeltaArchiveManifest.
 //   struct {
 //     char data[];
 //   } blobs[];
 //
+//   // These two are not signed:
+//   uint64 signatures_message_size;
+//   char signatures_message[];
+//
 // };
 
 // The DeltaArchiveManifest protobuf is an ordered list of InstallOperation
 // objects. These objects are stored in a linear array in the
 // DeltaArchiveManifest. Each operation is applied in order by the client.
 
 // The DeltaArchiveManifest also contains the initial and final
 // checksums for the device.
 
 // The client will perform each InstallOperation in order, beginning even
@@ skipping 18 matching lines @@
 // physical partition. An ordered list of extents is another
 // representation of an ordered list of blocks. For example, a file stored
 // in blocks 9, 10, 11, 2, 18, 12 (in that order) would be stored in
 // extents { {9, 3}, {2, 1}, {18, 1}, {12, 1} } (in that order).
 // In general, files are stored sequentially on disk, so it's more efficient
 // to use extents to encode the block lists (this is effectively
 // run-length encoding).
 // A sentinel value (kuint64max) as the start block denotes a sparse-hole
 // in a file whose block-length is specified by num_blocks.
 
+// Signatures: Updates may be signed by the OS vendor. The client verifies
+// an update's signature by hashing the entire download. The section of the
+// download the contains the signature is at the end of the file, so when
+// signing a file, only the part up to the signature part is signed.
+// Then, the client looks inside the download's Signatures message for a
+// Signature message that it knows how to handle. Generally, a client will
+// only know how to handle one type of signature, but an update may contain
+// many signatures to support many different types of client. Then client
+// selects a Signature message and uses that, along with a known public key,
+// to verify the download. The public key is expected to be part of the
+// client.
+
 message Extent {
   optional uint64 start_block = 1;
   optional uint64 num_blocks = 2;
 }
 
+message Signatures {
+  message Signature {
+    optional uint32 version = 1;
+    optional string data = 2;
+  }
+  repeated Signature signatures = 1;
+}
+
 message DeltaArchiveManifest {
   message InstallOperation {
     enum Type {
       REPLACE = 0;  // Replace destination extents w/ attached data
       REPLACE_BZ = 1;  // Replace destination extents w/ attached bzipped data
       MOVE = 2;  // Move source extents to destination extents
       BSDIFF = 3;  // The data is a bsdiff binary diff
     }
     required Type type = 1;
     // The offset into the delta file (after the protobuf)
@@ skipping 13 matching lines @@
     // byte length of dst, not necessarily block aligned. It's only used for
     // BSDIFF, because we need to fill in the rest of the last block
     // that bsdiff writes with '\0' bytes.
     optional uint64 dst_length = 7;
   }
   repeated InstallOperation install_operations = 1;
   repeated InstallOperation kernel_install_operations = 2;
 
   // (At time of writing) usually 4096
   optional uint32 block_size = 3 [default = 4096];
+
+  // If signatures are present, the offset into the blobs, generally
+  // tacked onto the end of the file. We use an offset rather than
+  // a bool to allow for more flexibility in future file formats.
+  // If this is absent, it means signatures aren't supported in this
+  // file.
+  optional uint64 signatures_offset = 4;
 }