Bug #340306: Specification draft for signed debs
Hi dpkg-sig, dpkg maintainers and FTP-masters,
I would like to help with reviving the idea of "signed deb". I
noticed dpkg-sig/debsig-verify is on the dpkg maintainer's "RoadMap"
[DRM], hench the CC. I also found [OSPEC], which may be of interest
or possible the "old spec".
I think that we should start with creating "signatures support
inside .deb"-spec. I have come up with an initial draft based on my
observations of dpkg-sig and debsig-verifiy below. Feel free to
review and suggest ammends to it.
Once we have created the specification, I suggest we use dpkg-sig (and
possibly debsig-verify) to create a prototype implementation of it and
get archive support for it.
State of the art
================
So far the only tools I am aware of in this area are dpkg-sig and
debsig-verify (currently orphaned). Both of these add a
"_gpg<role/name>" to the end of the existing deb:
* debsig-verify uses this file as a gpg signature of:
$ cat debian-binary control.tar.gz data.tar.gz
(source [DSV-EX] and [OSPEC]).
* dpkg-sig uses this this file as a signed dctrl file (e.g.
similar to a signed .changes file) [DS-EX]
Obviously these two approaches are not compatible. To me, it seems
the dpkg-sig signature is more flexible and easiest to extend.
Should new members be added to the deb format later, it can
trivially be signed emitting checksums for it in the signed dctrl
file. It is also contains a human readable description of what is
signed.
Archive support
---------------
The FTP masters have requested that all signatures are stored in a
single ar member of the deb. That "member should then contain a flat
directory (ie no sub-directories) of signature files, [...]"
(#340306#33).
They suggested that the member should be named "signatures.tar.gz"
(or so), but as it exceeds the name limits I will use "sigs.tar.gz"
for now.
Draft Specification
===================
deb format changes
------------------
deb files can optionally have a member called "sigs.tar.gz" used for
verifying the authenticity and integrity of contents of the deb file.
The member should be the last, but may appear anytime after the
data.tar member.
Implementations should (still) ignore any member after the data.tar
member except for the "sigs.tar.gz" if it is present.
The "sigs.tar.gz" may be used to sign any member preceeding it in the
deb file. Implementations are not required to check for signatures
for any member occuring after the "sigs.tar.gz".
Rationale: I believe it makes sense to allow members to appear after
the "sigs.tar.gz". We currently allow arbitrary members after the
data.tar member and if we require "sigs.tar.gz" to be last, then
implemenations would have to "move it to the back" when inserting a
"new member" - even if it isn't signed.
This allows any tool that relies on being able to "inject" members
in a deb to continue working without any changes (assuming it is not
using the "sigs.tar.gz" member).
Any tool "blindly" appending members in the back of a deb is
unlikely to be "aware" of the "sigs.tar.gz" and therefore will
probably not rely on its for signatures. So I believe it is a safe
assumption that members after the "sigs.tar.gz" will not be signed.
As far as I can tell, these semantics provides backwards compatability
with the current format with the exception of any tool using
"sigs.tar.gz" differently (if any such tools exists).
sigs.tar.gz
-----------
The sigs.tar.gz member is a gzipped tar archive containing signatures,
as a series of clearsigned GPG plain text files. The tarball may
optionally contain an entry for ".", the current directory.
The filename of the signature files must consists entirely of lower
letters and digits (i.e. "a-z" and "0-9") followed by ".asc".
Implementations should ignore files with a different file extension.
The contents of signature files are described below.
Rationale: I included the restriction on the file extension to allow
new files in the future (e.g. a "new kind" of signature file).
The choice of ".asc" was somewhat arbitrary, so if anyone has a better
suggestion, let me know. I originally thought of using ".sig".
However, GPG uses it for "binary signatures" and I was afraid it
might cause some potentional issues.
(The first paragraph is pretty much required per FTP masters,
but is there for the sake of completeness.)
signature files
---------------
As mentioned previously, this will be a clearsigned debian control
file (syntax as described in Policy §5.1). It contains the following
fields:
* Format (required, simple). The value of this field is "1.0"
- used for versioning the format (in case we want to extend
it).
* Date (required, simple). The date of the signature in RFC-2822
format.
- Technically redundant as the GPG signature already contains
the signing date.
* Signer (required, simple). The person/entity signing this
package.
- When using role keys, this can be used to document who
created the signature. Otherwise it should be the same
as the owner of the key.
* Signing-Policy (optional, simple). The URI to the "Signing
Policy" of the signer (if any).
* Checksums-<algorithm> (required, multiline). Contains the
checksums and sizes of files covered by this signature file.
- Implementations are required to know/use "Md5", "Sha1" and
"Sha256".
- The first line must be empty. Subsequent lines are:
<checksum> <file-size> <filename>
(Same as the fields of same name in .changes)
- The filename should be the "unpacked" name of the file.
(without the slash added by some ar implementations etc.)
* Role (required, simple). Defines the signers relation to the
package. It must be one of the following values:
- "builder": The signer built the package. At most one
signature file can use this role.
- "reviewer": The signer reviewed the package. This role can
be used in any number of signature files.
- "vendor": The signer is a vendor (re-)distributing the
package. The name of the vendor will be in the Vendor
field. This role can be used in any number of signature
files (assuming the vendors import the deb "as-is" and
simply resign it).
* Vendor (special, simple). Contains the name of the Vendor
- Field is mandatory if Role has the value "vendor", otherwise
it should be absent.
- Example value: Debian
* Vendor-URI (optional, simple). URI to the vendor's website or
documentation.
- Should be omitted if Vendor is not present.
- Example value: http://debian.org
The entire control file must be covered by the signature.
Implementations should reject any signature file with contents that
are not part of the signature or covered by the signature.
Unless verifiable by the signed contents of a signature, no unsigned
part of the signature file (such as its filename or its last
modification time) should be given any semantic value.
Rationale: Basic syntax/format was chosen, since it is widely
supported in Debian based tools and well documented.
I chose "Format" over "Version" because A) it is the same as in .dsc +
.changes and B) it prevents confusion with the "version of the
package".
The Date and Signer field were added because it gives a human readable
information about the signature (without having to use GPG to extract
it). Open question: Should we have an optional field to document the
"ID" of the key (for role keys)?
The choice of the "Checksums-*" seemed obvious to me. Any tool
checking .dsc or .changes files should already have code to verify
these fields, so it should allow implementations to reuse existing
code. Also it trivially allows adding new algorithms in the future.
The last paragraph (only trust the signed part) should be straight
forward, but I included it because I noticed a possible flaw in
[OSPEC].
In [OSPEC], the origin is determined only from its member name.
This would allow someone to rename the signature and thereby change
"what" you signed. As [OSPEC]'s policies relies on the member names
it could possibly be abused in some way.
Open question: should we allow implementation specific fields with the
usual "X-<field>" notation (or something similar)?
Remarks
-------
[OSPEC] also includes a section of how to create policies to verify
these deb signatures. I do believe a standardized "verfication policy
framework" is a commendable thing, but I also believe it written on
top of this specification later.
I also wonder if we should permit signatures to sign other signatures.
As an example, "When I signed this deb, there was also a signature
from Alice (who signed it as role X)".
This was my draft specification signing debs. As mentioned earlier -
feedback and changes are more than welcome. :)
~Niels
PS: I am not subscribed to the bug, so please CC me accordingly.
[DRM] https://wiki.debian.org/Teams/Dpkg/RoadMap
"""
Merge back functionality from dpkg-sig, debsigs-verify, etc:
* Draft a new spec for the signature support inside .deb.
* Write a dpkg-sig (or similarly named program) in C (Depends: #refactor-deb).
* The archive should allow signed packages. Tracked in 34030
"""
[OSPEC] http://quux.org:70/devel/debian/debsigs.txt
[DSV] http://purplefloyd.wordpress.com/2009/02/05/signing-deb-packages/
Admittedly, I have not actually tested it and merely assumed that blog
post and [OSPEC] were "up to date".
[DS-EX]
Example output on a locally tested package:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Version: 4
Signer: Niels Thykier <niels@thykier.net>
Date: Sat Jun 9 15:28:24 2012
Role: nt
Files:
3cf918272ffa5de195752d73f3da3e5e 7959c969e092f2a5a8604e2287807ac5b1b384ad 4 debian-binary
942b15255d6977315435aad5b17d900e 0d8d802b45df7032e8155c05d8cb9b2ead13987e 8911 control.tar.gz
ec796ed1f636278915db1aeec1eeecf6 ca84c27f130bab7ee287f055eeaae7f7da51c2bb 683401 data.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJP0094AAoJEAVLu599gGRC6YEQAJj5BKm/5abCWKcSM6SyIRop
tmaT02t9ddxJFTt4WyuzTtEaA6M5/N2AKaowDMqvI+rITtXg8exivqbZg1AdZxNn
UdemxwIARATOe0wVVybfL4LAbbwoa7MVurDHw+qAw5KNqSuB6M0jCAIuJW4ZnG/4
vsPcqn4hLaR6XfRShqVLd5roogueYYQJmqyT9pWioYvWqLaA5vF6rG1LTHOcSDQB
RWYDAfBlQCmIVgpxazN5mYtzUZuSD9+xMSSs+LBSdaQ+/I6l8q4GJ2tNUX0r+31X
0zvb+aLXxpSLY9JTcBjJM/HABEFlSpspbaies5N44DMXJhiOJBMp7zR9xIdMBQuc
EDrkpoNjBA/CE2i/Kpq2b5QvqSKY9Fi5d4pnwiNIR92vi8bebgvesBAigWKh0S+I
za++4xtkKT7SZURxSzYKI1SXsx8DNZc1WUzXWNSn1cMhQfEZzl9vCoBOTFq1bxDf
Sv8O30HrsLoHZkPIaFzlg0DfQ7iUZCXvlC9qKlZHgtCwjJdnj+JBgn23IVb+RaJg
+Z2fplDdxUxPJ+UOo9poIUc5vE9TOsxCVFQOF+XgAhP72r3BpSyixlg1YVwJCnOL
sbQ+c+FLl224qFcbGmhknfmG6zsesvShY2ljQ0kCQlQItpSu2PQC1b2wHLe54bQc
LjVGQ/xw6geSIw+/z22F
=jc3N
-----END PGP SIGNATURE-----
Reply to: