Bug#222779: debian-policy: [PROPOSAL] deb specifications and signed debs extension
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
Reply to: