Debian Bug report logs - #340306
dpkg-sig'd .deb's rejected: please support it

version graph

Package: dpkg-sig; Maintainer for dpkg-sig is Marc 'HE' Brockschmidt <he@debian.org>; Source for dpkg-sig is src:dpkg-sig.

Reported by: rhonda@debian.at

Date: Tue, 22 Nov 2005 16:03:02 UTC

Severity: important

Merged with 493644

Found in version dpkg-sig/0.13.1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, James Troup and others <ftpmaster@ftp-master.debian.org>:
Bug#340306; Package ftp.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Gerfried Fuchs <alfie@debian.org>:
New Bug report received and forwarded. Copy sent to James Troup and others <ftpmaster@ftp-master.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Gerfried Fuchs <alfie@debian.org>
To: Debian Installer <installer@ftp-master.debian.org>
Cc: control@bugs.debian.org
Subject: Re: ldapvi_1.4-1_i386.changes REJECTED
Date: Tue, 22 Nov 2005 16:35:37 +0100
Package: ftp.debian.org
Severity: serious
thanks

* Debian Installer <installer@ftp-master.debian.org> [2005-11-22 07:02]:
> Rejected: ldapvi_1.4-1_i386.deb: found 4 chunks, expected 3.
> 
> ===
> 
> If you don't understand why your files were rejected, or if the
> override file requires editing, reply to this email.

 Citing man 5 deb (which is referenced by policy):

   These members must occur in this exact order.  Current implementations
   should  ignore  any additional members after data.tar.gz.

 The ftp tools doesn't ignore these members, in fact they check
explicitly for them and reject them. This is a sever change to the
toolchain because it breaks the status quo and undermines the usability
of binary package signatures. One doesn't always have the posibility to
check the md5 sum in the aptcache against the Release file signature and
Package files, because those are moving targets. So it is important to
quite some people to use binary package signatures, especially for long
time usage.

 Thanks for returning to the old functionality in advance and removing
this limitation that has technical background, and is against the
policy.

 So long,
Alfie
-- 
Wenn alles, was "Text durch die Gegend schicken" ist 'E-Mail' heisst, dann
koenntest du eine Klowand in einem Lokal als Mailserver bezeichnen.
              -- Rudolf E. Steiner in <3b42da6a.6058655@news.kpnqwest.at>



Information forwarded to debian-bugs-dist@lists.debian.org, James Troup and others <ftpmaster@ftp-master.debian.org>:
Bug#340306; Package ftp.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to James Troup and others <ftpmaster@ftp-master.debian.org>. Full text and rfc822 format available.

Message #10 received at 340306@bugs.debian.org (full text, mbox):

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: Gerfried Fuchs <alfie@debian.org>, 340306@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#340306: ldapvi_1.4-1_i386.changes REJECTED
Date: Tue, 22 Nov 2005 21:06:09 +0100
severity 340306 wishlist
retitle 340306 dpkg-sig'd .deb's rejected: please support it
reassign 340306 dak
thanks

On Tue, Nov 22, 2005 at 04:35:37PM +0100, Gerfried Fuchs wrote:
> * Debian Installer <installer@ftp-master.debian.org> [2005-11-22 07:02]:
> > Rejected: ldapvi_1.4-1_i386.deb: found 4 chunks, expected 3.
> > 
> > ===
> > 
> > If you don't understand why your files were rejected, or if the
> > override file requires editing, reply to this email.
> 
>  Citing man 5 deb (which is referenced by policy):
> 
>    These members must occur in this exact order.  Current implementations
>    should  ignore  any additional members after data.tar.gz.

Should != must.

Besides, Policy deals with packages' behaviour not with how the archive
should behave. In any case, I do not follow your reading of policy that
would mandate debian.org's archive to allow extra members of .deb's.
Anyway, it seems work is underway to allow specifically dpkg-sig'd
.deb's in the archive proper (rather than not checking extra members at
all, with the potentional to contain any random sort of data that's not
normally visible by usage of dpkg), once the code is there, this issue
will be revisited. For now though, the check will remain in place.

--Jeroen

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Severity set to `wishlist'. Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `ftp.debian.org' to `dak'. Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Joerg Jaspert <joerg@debian.org>:
Bug#340306; Package dak. Full text and rfc822 format available.

Acknowledgement sent to Gerfried Fuchs <alfie@ist.org>:
Extra info received and forwarded to list. Copy sent to Joerg Jaspert <joerg@debian.org>. Full text and rfc822 format available.

Message #21 received at 340306@bugs.debian.org (full text, mbox):

From: Gerfried Fuchs <alfie@ist.org>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Cc: 340306@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#340306: ldapvi_1.4-1_i386.changes REJECTED
Date: Wed, 23 Nov 2005 10:53:14 +0100
[Message part 1 (text/plain, inline)]
reassign 340306 ftp.debian.org
title 340306 archive rejects .deb packages with any additional member
severity important
thanks

* Jeroen van Wolffelaar <jeroen@wolffelaar.nl> [2005-11-22 21:06]:
> Should != must.

 But you have to have a good reason to ignore it. I haven't heard any
(real) reason at all for it during the former changes in that respect
which were reverted because there was no reason available, and it still
breaks existing functionality.

> Besides, Policy deals with packages' behaviour not with how the
> archive should behave.

 So you are saying that the archive is allowed to actively work against
the policy? That's a very interesting point of view, and I don't think
that very much developers share that point of view. We could of course
start a GR/strawpoll for this, if you need it to be convinced that the
archive doesn't have to work against the policy, especially not with any
reasoning.

 Besides, you reassigned the bugreport to a package, so you *do* believe
that it's a package's behaviour. Now what? Is is a package's behaviour or
is it not? You are inconsistent in your "reasoning", which sounds more
like looking for an excuse because there isn't any reason involved?

> In any case, I do not follow your reading of policy that would mandate
> debian.org's archive to allow extra members of .deb's.

 Very fine. So you are for handing the responsibility about any future
extension like they are explicitly noted in the policy[1] over from the
people more invovled with it like package tool maintainers to the
archive maintainers?

 You are actively hindering the inclusion for digital signatures here,
and in addition of any future extension that might come up, adding more
load to your work, and decision power of inclusion/not inclusion of
future features, which in my opinion shouldn't be yours (as in the
archive team, not you personally).

> Anyway, it seems work is underway to allow specifically dpkg-sig'd
> .deb's in the archive proper (rather than not checking extra members
> at all, with the potentional to contain any random sort of data that's
> not normally visible by usage of dpkg),

 It is a good thing to add checking of like the signature that are known
now (against a quite broad pool of keys, mind you, there might not only
be signatures on the .deb that are in our keyring) and checking for bad
signatures. But not ignoring (yet) unknown parts to you is a very strong
change in the functionality and hinder any future development in any
direction at all. Again, I really don't thank that decision power and
especially even if they agree dealying process has to be the ftp team's
responsibility.

> once the code is there, this issue will be revisited. For now though,
> the check will remain in place.

 So for now some people aren't able to upload their packages and fix
outstanding problems because they refuse to buy that regression. Very
convenient.

 Thanks in advance for pulling more power to the ftp team and thinking
about if that's the way it should go. Besides, this is no wishlist
because the change disables usability that had been there for quite a
while (well over a year) and was actively used.

 So long,
Alfie
[1] From Appendix B of policy:
     In the future binary packages may also contain other components, such
     as checksums and digital signatures.  The format for the archive is
     described in full in the `deb(5)' man page.
-- 
> Wozu ein Forum, wenn's Usenet gibt?
Keine Unterscheidung zwischen Multipost, Crosspost und vor allem kein
Followup-To mehr noetig - ist fuer professionelle Anwender eh zu komplex
         -- Alexander Talos in <3d18e47b$0$20382$3b214f66@news.univie.ac.at>
[signature.asc (application/pgp-signature, inline)]

Bug reassigned from package `dak' to `ftp.debian.org'. Request was from Gerfried Fuchs <alfie@ist.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, James Troup and others <ftpmaster@ftp-master.debian.org>:
Bug#340306; Package ftp.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Gerfried Fuchs <alfie@ist.org>:
Extra info received and forwarded to list. Copy sent to James Troup and others <ftpmaster@ftp-master.debian.org>. Full text and rfc822 format available.

Message #28 received at 340306@bugs.debian.org (full text, mbox):

From: Gerfried Fuchs <alfie@ist.org>
To: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
Cc: 340306@bugs.debian.org
Subject: Re: Bug#340306: ldapvi_1.4-1_i386.changes REJECTED
Date: Tue, 29 Nov 2005 01:25:00 +0100
[Message part 1 (text/plain, inline)]
        Hi!

* Gerfried Fuchs <alfie@ist.org> [2005-11-23 10:53]:
> * Jeroen van Wolffelaar <jeroen@wolffelaar.nl> [2005-11-22 21:06]:
>> Should != must.
> 
>  But you have to have a good reason to ignore it. I haven't heard any
> (real) reason at all for it during the former changes in that respect
> which were reverted because there was no reason available, and it still
> breaks existing functionality.

 And I found out the good reason for it myself, after some thinking.
Sorry for being picky, I'm going to outline the reasoning (at least as I
would see it and accept it) here, for others, like promised in private
discussion:

 The ftp team is responsible for the content of the archive, and as
features with new parts get added they should add a check for it. The
best example is the current situation: Signatures created with dpkg-sig
should be checked on upload to avoid BADSIG in the pool. If the check
will be added later, like the current situation is, it is quite an
effort to check the things already in the pool if they might not go with
the standard.

 Leaving the bugreport open until the fix gets added, though. :)
Alfie
-- 
To err is human, to moo bovine.
                -- unknown
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joerg Jaspert <joerg@ganneff.de>, Debian FTP Master <ftpmaster@ftp-master.debian.org>:
Bug#340306; Package ftp.debian.org. Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@ganneff.de>:
Extra info received and forwarded to list. Copy sent to Joerg Jaspert <joerg@ganneff.de>, Debian FTP Master <ftpmaster@ftp-master.debian.org>. Full text and rfc822 format available.

Message #33 received at 340306@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@ganneff.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Cc: 340306@bugs.debian.org, 340306-submitter@bugs.debian.org
Subject: dpkg-sig: Making it work in Debian
Date: Sun, 03 Aug 2008 21:52:47 +0200
[Message part 1 (text/plain, inline)]
Package: dpkg-sig
Version: 0.13.1
Severity: important
Hi

in order to get dpkg-sig support into the archive, please change it so
that it doesn't add random files to the .deb, but just one extra
tarball, named something like "signatures.tar.gz". That one should then
contain a flat directory (ie no sub-directories) of signature files,
named however you prefer. New dpkg-sig runs add files to that tarball.

If that is done the archive will start supporting dpkg-sig signed
packages.

Oh, and btw, your homepage for this package is broken.

-- 
bye, Joerg
You're in good shape for being a Debian, with a SAP background
... anything has to look good from there...
[Message part 2 (application/pgp-signature, inline)]

Message sent on to Gerfried Fuchs <alfie@debian.org>:
Bug#340306. Full text and rfc822 format available.

Bug reassigned from package `ftp.debian.org' to `dpkg-sig'. Request was from Joerg Jaspert <joerg@ganneff.de> to control@bugs.debian.org. (Sat, 29 Nov 2008 23:06:04 GMT) Full text and rfc822 format available.

Forcibly Merged 340306 493644. Request was from Joerg Jaspert <joerg@ganneff.de> to control@bugs.debian.org. (Sat, 29 Nov 2008 23:06:05 GMT) Full text and rfc822 format available.

Owner recorded as rhonda@debian.at. Request was from Gerfried Fuchs <rhonda@debian.at> to control@bugs.debian.org. (Mon, 20 Apr 2009 10:18:16 GMT) Full text and rfc822 format available.

Removed annotation that Bug was owned by rhonda@debian.at. Request was from Gerfried Fuchs <rhonda@debian.at> to control@bugs.debian.org. (Mon, 20 Apr 2009 10:18:32 GMT) Full text and rfc822 format available.

Changed Bug submitter from Gerfried Fuchs <alfie@debian.org> to rhonda@debian.at. Request was from Gerfried Fuchs <rhonda@debian.at> to control@bugs.debian.org. (Mon, 20 Apr 2009 10:21:11 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Mon, 11 Jun 2012 09:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to niels@thykier.net (Niels Thykier):
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Mon, 11 Jun 2012 09:30:34 GMT) Full text and rfc822 format available.

Message #51 received at 340306@bugs.debian.org (full text, mbox):

From: niels@thykier.net (Niels Thykier)
To: debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Cc: Niels Thykier <niels@thykier.net>
Subject: Bug #340306: Specification draft for signed debs
Date: Mon, 11 Jun 2012 11:26:19 +0200 (CEST)
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-----




Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Mon, 11 Jun 2012 10:24:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org>:
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Mon, 11 Jun 2012 10:24:15 GMT) Full text and rfc822 format available.

Message #56 received at 340306@bugs.debian.org (full text, mbox):

From: Ansgar Burchardt <ansgar@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Subject: Re: Bug #340306: Specification draft for signed debs
Date: Mon, 11 Jun 2012 12:21:15 +0200
Hi,

On 06/11/2012 11:26 AM, Niels Thykier wrote:
> 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.

Do you want dak to eventually sign the packages? Note that this would
make them no longer match the hashes from the .changes.

Why is signatures.tar.gz too long? Is that a limitation of the ar format?

> 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".

Do you plan to support partially-signed packages where only some members
are signed? I would suggest to treat such packages as having an invalid
signature as it is likely you will have bugs otherwise (where tools
treat unsigned members after the sigs.tar.gz as signed).

Ansgar




Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Mon, 11 Jun 2012 11:29:58 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Niels Thykier" <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Mon, 11 Jun 2012 11:30:16 GMT) Full text and rfc822 format available.

Message #61 received at 340306@bugs.debian.org (full text, mbox):

From: "Niels Thykier" <niels@thykier.net>
To: debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Cc: "Niels Thykier" <niels@thykier.net>
Subject: Re: Bug #340306: Specification draft for signed debs
Date: Mon, 11 Jun 2012 13:24:12 +0200
On Jun 11, 2012 12:21 "Ansgar Burchardt" <ansgar@debian.org> wrote:
> Hi,
> 
> On 06/11/2012 11:26 AM, Niels Thykier wrote:
> > 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.
> 
> Do you want dak to eventually sign the packages? Note that this would
> make them no longer match the hashes from the .changes.
> 

I think it would be a nice feature to have, as people could then verify
that the deb has once been in the Debian archive (without having to look
it up on snapshot.d.o etc).

I would assume it would be signed by dak after the package has been
accepted into archive.  Are .changes files still used after that point?

> Why is signatures.tar.gz too long? Is that a limitation of the ar
> format?
> 

According to ar(1), it depends on the "implementation" of ar.

"""
GNU ar can maintain archives whose members have names of any length; [...]
If it exists, the limit is often 15 characters (typical of formats related to a.out) or 16 characters (typical of formats related to coff).
"""

To be honest, I am not sure if deb is subject to these limits, but I assumed
it was better to err on the side of backwards compatibility here  (deb(5) does
not seem to document a limit or lack thereof).
  In particular, debsig-verify currently assumes ar members to be at most 15
characters... though that may a flawed assumption in debsign-verify.

> > 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".
> 
> Do you plan to support partially-signed packages where only some
> members
> are signed? I would suggest to treat such packages as having an
> invalid
> signature as it is likely you will have bugs otherwise (where tools
> treat unsigned members after the sigs.tar.gz as signed).
> 
> Ansgar
> 
> 

The main reason for allowing unsigned members after the sigs.tar.gz was
that I read deb(5):

"""
Current implementations should ignore any additional members after
data.tar
"""

As a "you can always safely stuff a new member in the back"... I probably
misunderstood that and if so, I see no problem in considering members after
"sigs.tar.gz" as unsigned.
  However, I do believe that it should be allowed for a member to be signed
by a subset of the signers.  For example, if someone uploads a signed deb to
the archive, then it would still be possible for the archive software to
embed a new member (if it signs the new member).

~Niels





Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Mon, 11 Jun 2012 11:57:40 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Mon, 11 Jun 2012 11:57:45 GMT) Full text and rfc822 format available.

Message #66 received at 340306@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: niels@thykier.net (Niels Thykier)
Cc: debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Subject: Re: Bug #340306: Specification draft for signed debs
Date: Mon, 11 Jun 2012 12:52:26 +0100
[Message part 1 (text/plain, inline)]
On Mon, 11 Jun 2012 11:26:19 +0200 (CEST)
niels@thykier.net (Niels Thykier) wrote:

>  * 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

> Open question: should we allow implementation specific fields with the
> usual "X-<field>" notation (or something similar)?

That would be useful for Emdebian and other derivatives who need to
preserve the original builder information and then sign as itself as a
builder (effectively a rebuilder) because we modify the data.tar.gz and
control.tar.gz without changing the md5sums of the compiled files
within the data.tar.gz. (We simply remove files & compress
debian/copyright). Preserving the original builder metadata helps
demonstrate binary compatibility with the original Debian package as
the signature file for that builder would have to be removed - it's now
a broken sig.

If there is to be only one builder role, the additional fields can used
to store the details of the original builder role, effectively
"transferring" the builder role to Emdebian and storing the old value
as another field. Reviewer doesn't really fit.

X-DebianBuilder: the Signer details from the original Debian package
X-DebianDate: the date the Debian package was signed.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Tue, 12 Jun 2012 06:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@debian.org>:
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Tue, 12 Jun 2012 06:21:03 GMT) Full text and rfc822 format available.

Message #71 received at 340306@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@debian.org>
To: "Niels Thykier" <niels@thykier.net>
Cc: debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Subject: Re: Bug #340306: Specification draft for signed debs
Date: Tue, 12 Jun 2012 08:19:15 +0200
On 12874 March 1977, Niels Thykier wrote:

>> Do you want dak to eventually sign the packages? Note that this would
>> make them no longer match the hashes from the .changes.
> I think it would be a nice feature to have, as people could then verify
> that the deb has once been in the Debian archive (without having to look
> it up on snapshot.d.o etc).

> I would assume it would be signed by dak after the package has been
> accepted into archive.  Are .changes files still used after that point?

Not by us, or shouldn't. But for some suites, like the p-u one, we
publish the .changes too, so people CAN use them for importing
somewhere.

Not sure its a valid reason to let it go.

Actually, I would like to have them signed by dak too, yes.

> The main reason for allowing unsigned members after the sigs.tar.gz was
> that I read deb(5):

> """
> Current implementations should ignore any additional members after
> data.tar
> """

> As a "you can always safely stuff a new member in the back"... I probably
> misunderstood that and if so, I see no problem in considering members after
> "sigs.tar.gz" as unsigned.
>   However, I do believe that it should be allowed for a member to be signed
> by a subset of the signers.  For example, if someone uploads a signed deb to
> the archive, then it would still be possible for the archive software to
> embed a new member (if it signs the new member).

The sigs tarball wont be signed ever, so we can put new sigs in as much
as we want.

Question is - what happens if i put a data.tar.xz behind a sigs.tar.gz
(and data.tar.gz). Unsigned. Or trojan.tar.xz. Or whatever.
(Whats dpkg doing then, btw?)

We might allow in general to put anything behind, but for the archive
enable a "nothing allowed" mode, probably in dak. IE if dak sees more
than it should, reject. And an option in apt too, maybe.

-- 
bye, Joerg
[...] could be redistributed free (as in "free bear") [...]




Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Tue, 12 Jun 2012 06:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@debian.org>:
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Tue, 12 Jun 2012 06:30:02 GMT) Full text and rfc822 format available.

Message #76 received at 340306@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@debian.org>
To: niels@thykier.net (Niels Thykier)
Cc: debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Subject: Re: Bug #340306: Specification draft for signed debs
Date: Tue, 12 Jun 2012 08:27:33 +0200
On 12874 March 1977, Niels Thykier wrote:

> 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.

Yep. And I stand by this as I haven't seen a good reason against it. :)
Also, make it "sigs.tar" plus the compression that the rest of the .deb
members use? dpkg and tools have to deal with a number of them anyways,
so we can make this open too, no need to limit to just one.

>  * 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".

MD5? Seriously?
Also, make it not too hard to switch those in the future.

>     - "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).

So dak would be signing as a vendor, "Debian" or "Debian Archive" (and
probably "Debian Security" and "Debian Backports")?

> Open question: should we allow implementation specific fields with the
> usual "X-<field>" notation (or something similar)?

Yes.

> 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)".

Or a sponsor can say "Yeah, that maintainer signed too".
Might make sense.


-- 
bye, Joerg
Lisa, honey, if it’ll make you feel better I’ll destroy something Bart loves.




Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Tue, 12 Jun 2012 07:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Tue, 12 Jun 2012 07:57:04 GMT) Full text and rfc822 format available.

Message #81 received at 340306@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Subject: Re: Bug #340306: Specification draft for signed debs
Date: Tue, 12 Jun 2012 09:54:02 +0200
Hi!

On Mon, 2012-06-11 at 11:26:19 +0200, Niels Thykier wrote:
> 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.

Thanks for digging into this! I've skimmed over the draft, and will be
replying to some minor specific issues that have been brought up in the
thread, but I'll only be seriously participating and pondering about all
this once the freeze is started, so I guess in few weeks, because I'd
like to focus on finishing some other dpkg stuff first.

> 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.

JFYI (in case people don't remember / are not aware) dpkg supports
using the debsig-verify interface, but it's disabled by default in
dpkg.cfg.

> signature files
> ---------------

> Open question: should we allow implementation specific fields with the
> usual "X-<field>" notation (or something similar)?

Using X- to extend fields has been controversial in the past for
dpkg control files, we discussed this some time ago (IIRC in
debian-policy), and for 3rd parties I added Private- as a prefix that
would not trigger warnings from dpkg-deb. I've just noticed this is
not documented in the man page, will quickly fix that.

> 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.

Sure, I'd appreciate if that would not rely on stuff like an XML parser,
though. :)

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Tue, 12 Jun 2012 08:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Tue, 12 Jun 2012 08:21:04 GMT) Full text and rfc822 format available.

Message #86 received at 340306@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Niels Thykier <niels@thykier.net>
Cc: debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Subject: Re: Bug #340306: Specification draft for signed debs
Date: Tue, 12 Jun 2012 10:16:25 +0200
On Mon, 2012-06-11 at 13:24:12 +0200, Niels Thykier wrote:
> On Jun 11, 2012 12:21 "Ansgar Burchardt" <ansgar@debian.org> wrote:
> > Why is signatures.tar.gz too long? Is that a limitation of the ar
> > format?
> 
> According to ar(1), it depends on the "implementation" of ar.
> 
> """
> GNU ar can maintain archives whose members have names of any length; [...]
> If it exists, the limit is often 15 characters (typical of formats related to a.out) or 16 characters (typical of formats related to coff).
> """
> 
> To be honest, I am not sure if deb is subject to these limits, but I assumed
> it was better to err on the side of backwards compatibility here  (deb(5)
> does not seem to document a limit or lack thereof).

There are the BSD and GNU extensions to the common ar format to store
long names in ar archives. dpkg only supports the common format and
supports neither of those extensions, because there's really no need.
I'll add the filename limits in the deb(5) man page too.

> In particular, debsig-verify currently assumes ar members to be at most 15
> characters... though that may a flawed assumption in debsign-verify.

ar filenames in the common format can be up to 16 characters, but
depending on the variant used they might contain a trailing ‘/’,
dpkg supports both variants (w/ and w/o the ‘/’) so that limits the
filenames to 15 characters. Also some implementations might ignore the
16th character if it's no ‘/’ (GNU binutils appears to do that for
example).

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Marc 'HE' Brockschmidt <he@debian.org>:
Bug#340306; Package dpkg-sig. (Tue, 12 Jun 2012 08:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Marc 'HE' Brockschmidt <he@debian.org>. (Tue, 12 Jun 2012 08:33:03 GMT) Full text and rfc822 format available.

Message #91 received at 340306@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Niels Thykier <niels@thykier.net>, debian-dpkg@lists.debian.org, ftpmaster@debian.org, 340306@bugs.debian.org
Subject: Re: Bug #340306: Specification draft for signed debs
Date: Tue, 12 Jun 2012 10:29:34 +0200
On Tue, 2012-06-12 at 08:19:15 +0200, Joerg Jaspert wrote:
> On 12874 March 1977, Niels Thykier wrote:
> > The main reason for allowing unsigned members after the sigs.tar.gz was
> > that I read deb(5):
> 
> > """
> > Current implementations should ignore any additional members after
> > data.tar
> > """
> 
> > As a "you can always safely stuff a new member in the back"... I probably
> > misunderstood that and if so, I see no problem in considering members after
> > "sigs.tar.gz" as unsigned.
> >   However, I do believe that it should be allowed for a member to be signed
> > by a subset of the signers.  For example, if someone uploads a signed deb to
> > the archive, then it would still be possible for the archive software to
> > embed a new member (if it signs the new member).

> Question is - what happens if i put a data.tar.xz behind a sigs.tar.gz
> (and data.tar.gz). Unsigned. Or trojan.tar.xz. Or whatever.
> (Whats dpkg doing then, btw?)

For the current behaviour and accepter members layout this is documented
in deb(5). For optional members (like the possible sigs.tar.gz) this
would depend on either new checks in dpkg itself or in an external
verifier like debsig-verify. (Or I didn't understand your question :)

> We might allow in general to put anything behind, but for the archive
> enable a "nothing allowed" mode, probably in dak. IE if dak sees more
> than it should, reject. And an option in apt too, maybe.

Yes, when specifying this it should be clearly decoupled what conforms
a valid .deb format and what subset dak might want to allow. For
example currently dak only allows a subset of valid .deb packages,
which I can see how it makes sense for it being more strict, but
general purpose tools should deal with the standard format.

regards,
guillem




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 06:29:51 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.