New Source Formats and Source Package Verification
I had originally planned to make a proposal for modification to the
source packaging system on the 13th, to coincide with the release of
'bo', but the number of differing ideas in the current discussion has
convinced me that that may have been a bit premature.
Accordingly, in the rest of this message, I will make a number of
assertions regarding requirements and goals for the source packaging
system. I'd appreciate if people would comment to me directly
regarding opinions on the importance (or lack thereof) of any of these
goals, as well as other goals or requirements I may have missed. I'd
be happy to summarize and re-post any comments sent to me on any of
these points.
Note that I am not at this point concerning myself with the details of
the implementation of any of these requirements. I believe to have
developed a proposal which substantially meets the requirements
presented here, but before I post that proposal for debate, I'd like
to make sure we all agree on the requirements.
Please accept my apologies for the length of this message. If you
just want to see my proposed list of requirements, just skip to
"Security Concerns", "Other Concerns", and "Pragmatic Concerns",
below.
Overview:
---------
I believe that the Debian packaging format needs to be changed to
support cryptographic verification of package sources. As the person
likely to implement most of these changes, as well as the maintainer
of over fifty Debian source packages, I understand the importance of
minimizing disruption to the source package format. Nonetheless I
believe that any changes necessary for providing for package
verification need to be made as quickly as practical, as they are
critical to the security of Debian distributions. Other changes to
the packaging system may be considered as well, provided they do not
require any expensive conversions of packages or overly increase the
complexity of the source packaging system.
Why Security Changes are Necessary:
-----------------------------------
Currently, the Debian project has no way to ensure the security of its
packages other than trust of the individual maintainer. As the
current verifier of new-maintainer requests, I make a good-faith
effort to verify the real-life identity of each new maintainer and
associate him or her with a PGP key. We then accept all packages
submitted under this PGP key without examination, with the assumption
that the accountability provided by the single PGP key will serve as
sufficient verification.
Although this has worked reasonably well so far, I believe it to be
problematic both pragmatically and philosophically.
>From a philosophical standpoint, I find the focus on verifying the
identity of contributors rather than the correctness of packages to be
troubling. I believe we should be doing everything in our power to
attract new developers and make contributing to the project as easy as
possible --- not erect additional barriers in the name of security.
>From a practical standpoint, it would be easy for a serious attacker
to bypass our security, either by forging identification documents
(not all that hard, given that I currently accept scanned images as
"good enough"), or by compromising the key of a current developer
(with over 200 developers, it's not all that impractical).
I therefore propose to change the Debian source package management
system to provide a mechanism for independent (non-maintainer)
verification of each of the different components of a source package.
Such a change would allow us to accept and verify packages submitted
from completely untrusted sources, as well as allow independent
testing groups to provide independent verification of the integrity of
a source package. It also preserves the essentially decentralized
nature of the Debian project, and allows end-users to judge packages
based on a web-of-trust model (of the signers of the packaging and of
the signers of the original sources) rather than on a centralized
all-or-nothing basis.
Since this is a significant change to the source packaging system, I
believe it is useful to start by outlining a proposed set of
requirements for the Debian source packaging system.
Source Package Requirements:
----------------------------
I believe the following characteristics are important for any source
package format to be used by Debian (here I have tried to use "must"
to indicate an absolute requirement, and "should" to indicate a strong
requirement, except where noted otherwise).
Security concerns:
------------------
* [1.1] It must be possible to reconstruct exactly the construction
of a Debian-format source package directly from upstream sources,
possibly with the addition of Debian-specific patches or source
files. Where bit-for-bit archive equivalence of upstream sources is
not practical (because of troublesome upstream source formats),
file-for-file equivalence must be provided. It must be possible for
Debian developers to use multiple upstream source files and multiple
patch files where necessary to reflect the actual usage of upstream
sources (as a matter of policy this may or may not be encouraged,
but it must at least be possible).
* [1.2] The end-user must be able to cryptographically verify the
contents of Debian source packages.
* [1.3] Upstream source providers, Debian developers, and package
testers should each be able to provide verification of the integrity
of upstream sources, in the form of signed and possibly notarized
certificates to be included with each source package. Developers
should be able to finely control the level of verification they
provide to a given package.
[ For example, as the dpkg maintainer, I am willing vouch for the
integrity of the entire dpkg source distribution, and to certify that
the source distribution is free from malicious code (though not from
bugs).
As the e2fsprogs maintainer, however, I am willing to certify
that the upstream sources I am distributing are the same ones that
were released by Ted Ts'o, and that I have not made any malicious
patches, but I am not willing to vouch for the integrity of the
upstream sources. Ted Ts'o is willing to vouch for the integrity
of the upstream sources, but not the integrity of my patches. ]
* [1.4] The end-user of a Debian system must be able to unpack and
examine a Debian source package without executing any code other
than the Debian source unpacking tool.
* [1.5] Users of arbitrary UNIX distributions should be able to
unpack and examine a Debian source package with a minimum of
complexity, and must be able to unpack it without any non-standard
tools, and without executing any arbitrary code.
Other Concerns:
---------------
* [2.1] Changing the Debian-specific portions of a source package
should not require the re-transmission of the upstream source
portions, either by the package developer, or by the end-user
downloading the package.
* [2.2] Keeping in mind [2.1], the source package format should
provide a way for the end-user to download the entire contents of
a Debian-format source package easily and without error --- either
because all of the components are in a single file, or because
they are grouped together in some other way.
* [2.3] The Debian source packaging tools should provide a
mechanism to download the upstream portions of a Debian source
package automatically, possibly allowing Debian developers to upload
only the locally-generated parts of a source archive to the master
FTP site.
* [2.4] The end-user should be able to unpack, verify, and build a
source package in any directory of his choosing (see [1.4] and [1.5],
above).
* [2.5] All of the following operations should be made as simple as
possible for the developer:
* upgrading the upstream portion of a Debian source package, either
by adding upstream patches, or by replacing the upstream part
itself.
* maintaining Debian-modified source trees in the same directory as
upstream source trees without conflict
* maintaining and releasing Debian-only source trees or upstream
source trees that already have Debian modifications.
* [2.6] Developers should be able to add or remove text files, binary
files, and directories to and from upstream sources without undue
effort.
* [2.7] It should be possible to build a Debian-format source package
in a controlled build environment, without the need for root privileges.
Source packages should provide a mechanism to specify the tools (and
versions thereof) necessary to build that package, so that automated
building tools can construct a minimal and stable environment for
building each package.
Pragmatic Concerns For a New Source Format:
-------------------------------------------
* [3.1] It should be completely backwards-compatible with the current
source format, or at the very worst require simple mechanical
transformations to be performed on the current source packages.
* [3.2] It should not require a significant conceptual shift on the
part of the developers.
* [3.3] It should be independent of dpkg and the binary packaging
system --- those are complex enough already.
* [3.4] It should require only moderate changes to dpkg-dev and to
the FTP installation tools. I don't like to make work for myself,
and I especially don't like to make work for Guy Maor. Any proposed
changes should be able to be implemented by a single person by
July first.
Future Concerns:
----------------
The following are good ideas, but I don't plan to consider them as
part of the current set of changes:
* [4.1] It should be possible for the package builder to set options
for package building in a standard manner (for debugging symbols,
alternate root directory, etc).
* [4.2] It should be possible for the same Debian-format source
package to be used to build binary packages in multiple non-Debian
package formats (such as RPM, .tar.gz, and POSIX package format).
* [4.3] The Debian source package format should be generalized as a
universal source package format for use by upstream maintainers on
all distributions and all architectures, allowing packages to be
maintained directly by upstream maintainers, and reducing the burden
on Debian maintainers.
* [4.3.1] It should be possible for GNU-format source archives to be
used directly as debian source packages, with at most a mechanical
conversion process.
Issues not Considered Here:
---------------------------
These are important, but I think they can be separated from the
discussion of the source package system:
* [5.1] Binary package verification (the issues here are substantially
similar to those of source package verification).
* [5.2] Debian key management policies (multiple/split master keys,
notarization services, key revocation, etc.).
* [5.3] Issues of developer/distributor liability for bad/malicious
packages (This is a giant can of worms, and I'd rather just avoid
it completely for now).
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: