[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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

  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],

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

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