Bug#222779: marked as done (debian-policy: [PROPOSAL] deb specifications and signed debs extension)
Your message dated Mon, 23 Aug 2004 16:51:33 -0500
with message-id <87u0utikuy.fsf@glaurung.internal.golden-gryphon.com>
and subject line Bug#222779: debian-policy: [PROPOSAL] deb specifications and signed debs extension
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 3 Dec 2003 05:16:31 +0000
>From brederlo@informatik.uni-tuebingen.de Tue Dec 02 23:16:29 2003
Return-path: <brederlo@informatik.uni-tuebingen.de>
Received: from mx5.informatik.uni-tuebingen.de [134.2.12.32]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1ARPNF-0008FS-00; Tue, 02 Dec 2003 23:16:29 -0600
Received: from localhost (loopback [127.0.0.1])
by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
id 37EBC10D; Wed, 3 Dec 2003 06:16:28 +0100 (NFT)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
id 18372-02; Wed, 3 Dec 2003 06:16:26 +0100 (NFT)
Received: from dual (semeai [134.2.15.66])
by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP
id 06028139; Wed, 3 Dec 2003 06:16:23 +0100 (NFT)
Received: from mrvn by dual with local (Exim 3.36 #1 (Debian))
id 1ARPMz-0006rw-00; Wed, 03 Dec 2003 06:16:14 +0100
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: debian-policy: [PROPOSAL] deb specifications and signed debs extension
X-Mailer: reportbug 2.26.1
Date: Wed, 03 Dec 2003 06:16:13 +0100
Message-Id: <E1ARPMz-0006rw-00@dual>
Sender: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Delivered-To: submit@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin
2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_11_20
(1.212-2003-09-23-exp) on master.debian.org
X-Spam-Status: No, hits=-4.0 required=4.0 tests=BAYES_99,HAS_PACKAGE
autolearn=no
version=2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_11_20
X-Spam-Level:
Package: debian-policy
Version: 3.6.1.0
Severity: normal
Hi,
there seems to be no conclusive specification on the format of a deb
package anywhere. The only information is in "man deb" and thats
rather unspecific just saying its an ar archive (ar archive can have a
number of slightly different formats).
I would like to add a section to the debian-policy and/or the
developers-reference detailing the format of a deb in details and lay
out a policy for debs signed with debsigs.
1. The existing .deb format
Most of the information is in man deb. What is missing is the
specifications of the actual ar format to be used and what other
formats are supported and deprecated.
The dpkg-deb tool will produce ar archives of the bsd flavour.
Filenames use a delimiter or ' '. All tools understand such debs.
On the other hand the GNU ar program included in debian produces ar
files of the sysv flavour. Filenames use a delimiter of '/'. Afaik all
tools but apt-utils (patch in BTS) and the debian archive scripts
(someone claimed) do accept such ar archives.
It should be clarified what flavour of ar must be accepted by all
tools handling debs and which one is recomeded for official use.
The byte-by-byte specifications of the recomended ar format should be
included in the developer reference and the policy could reference
that for in depth details. [.deb files are ar archives as specified in
the developers-reverence, section 53253.243: Format of .deb ar archives]
2. Extending the deb format with a policy on signed debs
Goals:
- Easy way to verify a deb originated from debian (Release.gpg only
provides this while the deb is in archive)
- Easy way to verify a deb was not compromised after being build
(finding the changes files in the mailinglists is not easy and they
are not all archived)
- Easy way to verify file integrity of local files
Changes:
>From "man deb" I conclude that new files can be added to the end of
a deb with any name or with a leading _ at any place (must be after
debian-binary). Any existing software must ignore those files and at
least the "_foo" has been tested to work (gets ignored by dpkg) since
potato.
I propose introducing optional files to be added at the end of the deb
for the purpose of signing a deb and increasing the version of debs to
2.1. Existing software, if it followed "man deb", has to accept those
debs and ignore the unknown extra files.
The files would contain a signature as produced by debsigs (increases
the deb by 132 bytes per signature). Currently all debsigs files start
with "_gpg" followed by up to 10 chars of the type of signature. The
'_' was indendet for files placed in the middle of the deb that can
savely be ignored. That should change when the names become
official. I suggest a prefix of sig or gpg.
Standard signatures:
The following signatures should be defined and additional signatures
allowed but not existing in official debian packages:
Required:
sig-origin - Automatic signature done by dinstall when accepting a
package into the archive (same as Release.gpg signature)
sig-security - Signatur by the security team for security updates
sig-m<key id> - Signature by the maintainer/builder of the package.
sig-a<key id> - Signature of the admin of a buildd
The origin signature from the dinstall key and a sig-m signature from
any DD (the DD signing the changes file?) would be required. For now
the sig-a signature has some technical difficulties (but solvable) and
should not be enforced until they are solved for all buildd
admins. I'm confident the problem can be solved in time to get all
packages rebuild for sarge+1 by just normal updates. For security.d.o
the security signature would be required too.
Optional/Reserved:
sig-release - Signature by the release manager made off line
sig-s<key id> - Signature of the sponsored person
sig-md5sums - Signature of the md5sums file included (or generated
on the fly of a package)
The sig-release signature would play hell on all ftp mirrors. rsync
mirrors on the other hand would just download the end of each deb
again. This would also cause debs that are shared between stable and
testing/unstable to get downloaded again for all testing/unstable
users. The sig-release signature would be realy nice but technically
to troublesome. The name should be reserved for the purpose of such a
signature though (Debian offsprings might want to sign their releases
that way).
Sponsored (binary-only) uploads would have a sig-s<key id> signature
from the builder and a sig-m<key id> from the sponsor. Sponsor and
sponsorie should have met in person and exchanged keys or have a
reliably trust chain (some DDs have signed the sponsories key). This
should be used only when there is enough trust between the sponsor and
sponsorie to not warant rebuilding the debs.
The sig-md5sums signature is a signature of the md5sums file included
in many debs now by the same key as the maintainer/builder. The
signature should be included in the Packages files in the archive
along with the key id of the sig-m<key id> or installed by dpkg along
with the md5sums file. This would allow users to reboot a compromised
system with a known clean medium, verify all md5sums files and then in
turn verify all files on the system. This would prevent tampering
with the md5sums files stored in /var/lib/dpkg/info/. The md5sums
files would then be usefull for more than verifying accidental
changes. Note that files would not need to actually contain a md5sums
file since that can be generated on the fly when signing the deb, when
installing the deb or by dpkg-repack.
Implementation:
User:
- apt-get install debsigs-verify
- edit /etc/dpkg/dpkg.cfg (remove no-debsig)
- add signing policy and keys for debsigs-verify
- enjoy all the missing signatures
The user can configure debsig-verify to verify the sig-origin and
sig-security signatures against the suposed keys and the sig-m/a
signature against the debian keyring. All its needs is installing
debsig-verify and providing the keys to compare against.
A more strict checking, e.g. does the id match the maintainer of the
package or one the buildds of the sig-a key, can be implemented too
but is left for later. There is enough time before enough debs have
a signature and the signature checking can be enabled to implement
further user parts of the system.
Master:
debsigs can be used by dinstall to sign each deb before its moved
into the archive. The same key used for the Release.gpg can be used
here.
Maintainer:
debsign could be patched to sign debs and adjust the changes file
before signing that too. Maintainers would get asked for the
passphrase more often and wouldn't need to change anything. Patching
dpkg-deb to include a signature would require some way to pass the
key-id to be used through the debian/rules file and I would rather
avoid that.
Buildd:
sbuild, pbuilder and umlbuild could be patched to add the buildd
signature to the debs and change the .changes file before appending
the same to the build log.
Build admin:
Buildd admins get the build log send by mail, extract the changes
file from it, sign it and send the chages file back to trigger the
upload.
If debsign is patched to sign debs automatically it needs an option
not to for buildd admins. Ways to sign the debs without downloading
them or uploading the key to the buildd system are being looked
into.
MfG
Goswin
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux dual 2.4.21-ac4 #1 SMP Sat Jul 5 17:53:13 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=de_DE
-- no debconf information
---------------------------------------
Received: (at 222779-done) by bugs.debian.org; 23 Aug 2004 21:57:51 +0000
>From srivasta@debian.org Mon Aug 23 14:57:51 2004
Return-path: <srivasta@debian.org>
Received: from host-12-107-230-171.dtccom.net (glaurung.internal.golden-gryphon.com) [12.107.230.171]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BzMp4-0008RK-00; Mon, 23 Aug 2004 14:57:51 -0700
Received: from glaurung.internal.golden-gryphon.com (srivasta@localhost [127.0.0.1])
by glaurung.internal.golden-gryphon.com (8.13.1/8.13.1/Debian-8) with ESMTP id i7NLps6p030878
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Mon, 23 Aug 2004 16:51:59 -0500
Received: (from srivasta@localhost)
by glaurung.internal.golden-gryphon.com (8.13.1/8.13.1/Debian-8) id i7NLpX4U030843;
Mon, 23 Aug 2004 16:51:33 -0500
X-Authentication-Warning: glaurung.internal.golden-gryphon.com: srivasta set sender to srivasta@debian.org using -f
To: Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: 222779-done@bugs.debian.org
Subject: Re: Bug#222779: debian-policy: [PROPOSAL] deb specifications and signed debs extension
References: <E1ARPMz-0006rw-00@dual>
From: Manoj Srivastava <srivasta@debian.org>
Organization: The Debian Project
X-URL: http://www.debian.org/%7Esrivasta/
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) (i686-pc-linux-gnu)
Mail-Copies-To: nobody
X-Face: #q.#]5@vq!Jz+E0t_/;Y^gTjR\T^"B'fbeuVGiyKrvbfKJl!^e|e:iu(kJ6c|QYB57LP*|t
&YlP~HF/=h:GA6o6W@I#deQL-%#.6]!z:6Cj0kd#4]>*D,|0djf'CVlXkI,>aV4\}?d_KEqsN{Nnt7
78"OsbQ["56/!nisvyB/uA5Q.{)gm6?q.j71ww.>b9b]-sG8zNt%KkIa>xWg&1VcjZk[hBQ>]j~`Wq
Xl,y1a!(>6`UM{~'X[Y_,Bv+}=L\SS*mA8=s;!=O`ja|@PEzb&i0}Qp,`Z\:6:OmRi*
Date: Mon, 23 Aug 2004 16:51:33 -0500
In-Reply-To: <E1ARPMz-0006rw-00@dual> (Goswin Brederlow's message of "Wed, 03
Dec 2003 06:16:13 +0100")
Message-ID: <87u0utikuy.fsf@glaurung.internal.golden-gryphon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Delivered-To: 222779-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
Hi,
The actual format of a .deb file are not relevant to the
Policy manual, since any interactions mandated by policy to the
packaging system are mediated by dpkg and friends (any change in
underlying format is largely irrelevant to most packages).
This is a matter of dpkg documentation, so perhaps this should
be filed as a wishlist bug against dpkg?
In any case, this is not a policy issue.
manoj
--
The world is no nursery. Sigmund Freud
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: