#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 2.15
\textclass article
\language default
\inputencoding latin1
\fontscheme default
\graphics default
\paperfontsize default
\spacing single 
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default

\layout Title

Package Verification with dpkg: Implementation
\layout Author

John Goerzen <jgoerzen@progeny.com>
\layout Date

Version 5; January 4, 2001
\layout Section

Introduction
\layout Standard

As part of a continuing effort to improve the security of users of Debian
 and Debian-based systems, one step that is important to take is to allow
 the users to verify for themselves that .deb packages that they have are
 from an authentic source.
 This mechanism is intended to prevent various types of attacks.
 Some are:
\layout Itemize

Preventing people from setting up a fake Debian archive, containing potentially
 trojaned packages, and masquerading as a real Debian archive.
 This attack can be thwarted by checking an origin signature, checking archive
 signatures, or checking maintainer signatures.
\layout Itemize

Preventing altered .deb packages from being installed undetected.
 Since all signatures are applied to the contents, any signature that is
 checked will protect against this attack.
\layout Itemize

Preventing people from separating or inserting forged data or metadata into
 a package.
 Because all signatures are applied to both the control and the data chunks
 together, separating them will not be possible without causing a signature
 failure.
\layout Itemize

Helping to prevent old packages from being presented as new.
 By checking the signature date, policy files can be set to reject packages
 that contain old signatures.
 Sites might re-sign their packages periodically with an 
\begin_inset Quotes eld
\end_inset 

archive
\begin_inset Quotes erd
\end_inset 

 or a 
\begin_inset Quotes eld
\end_inset 

timeliness
\begin_inset Quotes erd
\end_inset 

 signature that could be used specifically for this purpose.
\layout Itemize

Allowing verification to ensure that a given package was part of a particular
 archive site, distribution, made by a particular developer, etc.
 Signatures could be applied for various stages of development -- approval
 by QA managers, release managers, etc.
 The multiple signature per .deb architecture outlined in this proposal allows
 this.
\layout Itemize

Allowing verification of an isolated .deb, even in the absence of an Internet
 connection or access to an archive.
 By including the signatures inside the .deb itself, it is not necessary
 to download signed index files to verify a signature.
\layout Subsection

Unaddressed Problems
\layout Standard

The approach set forth in this document leaves one hole that must be solved
 by other means.
 That problem is the task of insuring the integrity of the keys, policy
 files, and programs themselves used to carry out the verification.
 One potential solution is to modify apt-get to support https and use trusted
 third-party (e.g., Thawte) to shore up this problem.
\layout Standard

The mechanism used to ensure old packages are not presented as new might
 be resource-intensive on the server in some situations.
 One potential avenue to explore there might be to provide signed Packages
 files on the server.
\layout Subsection

Rationale
\layout Standard

Some thought has gone into the design of this particular solution.
 For benefit of future discussions, here is some information on how this
 mechanism was chosen and reasons for it.
 Here are the main alternatives that have been considered:
\layout Description

GPG\SpecialChar 
 apt, genchanges, and various other utilities.
 The additional complexity of doing so and the possibility of separating
 the signature from the .deb makes this approach undesirable.
\layout Description

GPG\SpecialChar 
 However, this would change the basic format of the .deb and render it
 unusable without a current dpkg and GPG installed on the system.
 Since it breaks backward compatibility in such a severe way, this approach
 is also undesirable.
\layout Description

Sig-per-chunk A sig-per-chunk system would place separate sigs in the ar
 file for the data and the control chunks.
 Unfortunately, this would allow someone to mix and match data and control
 data in making trojan .debs, which can also be a security threat.
\layout Description

Sig-per-repository A sig-per-repository system would place an md5sum of
 a .deb into the Packages files and sign those.
 However, this omits fine-grained control and prevents verification of a
 .deb in absence of the Packages file from the Internet.
 It also requires solutions to problems of determining which archive a package
 came from.
\layout Standard

The policy files (see section 
\begin_inset LatexCommand \ref{Policy Definitions}

\end_inset 

) are designed to be simple, straightforward, and easy to both write and
 parse.
 By keeping them as simple as possible, the potential for both human authoring
 errors and parsing errors in software can be minimized.
\layout Section

Modifications to .deb
\layout Standard

Currently, a .deb consists of an ar archive containing debian-binary, control.tar.g
z, and data.tar.gz files.
 These files represent package meta-data and package contents, respectively.
 Each signature will be applied to the debian-binary, control.tar.gz, and
 data.tar.gz files concatenated together in that order.
 The files should not be decompressed before applying the signature.
\layout Standard

Each signature file will be stored in the ar archive and have a name of
 this form:
\layout Standard

_gpg
\emph on 
type
\layout Standard

Therefore, an origin signature would be named _gpgorigin.
 The 
\begin_inset Quotes eld
\end_inset 

type
\begin_inset Quotes erd
\end_inset 

 string must not exceed 10 characters in length nor be less than 1 character.
\layout Standard

Therefore, an origin signature in GnuPG format would be named _sig-origin.gpg.
 At this time, all signatures must be in GnuPG format.
\layout Section

Signatures and Types
\layout Standard

Each .deb file that is signed must have at least an origin signature.
 This signature should be unique per entity.
 For instance, Debian, Helix, and Progeny would each provide an origin signature.
 The origin signature is used as a key into the policy database such that
 the proper policy description can be loaded to describe the file.
\layout Standard

Beyond the origin signature, the signature types that are present or required
 are defined by the site policy.
 Examples of other signatures might be a maintainer signature from the person
 that built the package, a signature from quality assurance certifying that
 the package has passed QA tests, a signature from a release manager certifying
 that a package was part of a given distribution release, and a signature
 from an archive maintainer certifying that the package went into an archive.
\layout Section

A Runthrough
\layout Standard

To make sure the entire process is entirely clear, here is what will occur
 when a package is processed:
\layout Enumerate

The Key ID of the origin signature will be obtained.
 This will be used to determine the directory in which to look for policy
 files and keyrings as specified in section 
\begin_inset LatexCommand \ref{locations}

\end_inset 

.
\layout Enumerate

The checker will iterate over each policy file in that directory in an arbitrary
 order, doing the following:
\begin_deeper 
\layout Enumerate

Compare the Origin: line in the policy file (see section 
\begin_inset LatexCommand \ref{Origin line}

\end_inset 

) with the Key ID of the origin signature.
 If there is a difference, immediately die because of suspected corrupted
 policy files.
\layout Enumerate

Evaluate the selection clauses, if any, in the policy file.
 If there are any that do not pass, skip to the next policy file.
 If all of them pass, or there are no selection clauses, adopt the current
 policy file as authoritative for the package.
\layout Enumerate

If no appropriate policy files are found, reject the package as having a
 bad (unverifyable) signature.
\end_deeper 
\layout Enumerate

Given the appropriate policy file, the checker will iterate over every verificat
ion clause in that file.
 If all of them pass, the package is considered to pass the test.
 If any of them fail, the package is considered to have failed the test
 and processing immediately exits.
 No other policy files will ever be tested after this point.
 If the policy file contains no verification clauses, it will be rejected
 as invalid.
\layout Standard

It is possible that other package verifiers that use the same .deb architecture
 but different verification procedures may be introduced in the future.
 This section is not intended to imply a prohibition against such.
\layout Section

File Locations
\layout Standard

The following locations are defined for files that comprise this system:
\begin_inset LatexCommand \label{locations}

\end_inset 


\layout Itemize

/etc/debsigs/policy/
\emph on 
Origin-ID
\emph default 
/* contains one or more policy files that are to be applied for .debs whose
 Origin key was signed by the Key ID as listed in the path.
 The policies are tried in a non-deterministic order until one matches the
 selection criteria.
 Once one matches the selection criteria, the success or failure of the
 entire check is entirely contingent upon the success or failure of the
 verification clauses.
 If no policy file matches the selection criteria, then the entire operation
 is determined to fail.
\layout Itemize

/usr/share/debsigs/keyrings/
\emph on 
Origin-ID
\emph default 
/* contains one or more keyrings that are used by the policy files for the
 given origin.
 They may be symlinks to keyrings located elsewhere if desired.
 This is used as the directory for the keyrings in the RequiredSig and OptionalS
ig lines unless an absolute path is specified there.
\layout Standard

The policy files are located in /etc because sites may opt to alter the
 criteria for installing files on their site.
 The keyrings are located in /usr/share because they should not be altered
 locally.
 Because of the multi-file and multi-directory nature, it is easy for organizati
ons to provide packages providing information for verification of certain
 things.
 For instance, Debian could provide a debian-debsigs-potato package which
 contains a policy file and a potato release file.
 It could depend on debian-debsigs-main package, which contains the keyring
 for the origin field, a symlink to the main Debian keyring for the maintainers
 field, and a dependency on debian-keyring.
\layout Section

Related Documents
\layout Bibliography
\bibitem {1}

de Winter, Brenno.
 
\emph on 
Gnu Privacy Guard Mini Howto
\emph default 
 at http://www.dewinter.com/gnupg_howto/english/.
\layout Bibliography
\bibitem {2}

Free Software Foundation.
 
\emph on 
The GNU Privacy Handbook
\emph default 
 at http://www.gnupg.org/gph/en/manual.html.
\layout Bibliography
\bibitem {3}

Free Software Foundation.
 
\emph on 
gpg manpage
\emph default 
 available on local systems with gpg or at http://www.gnupg.org/gpgman.html.
\layout Bibliography
\bibitem {4}

Braakman, Dorman, et al.
 
\emph on 
Debian Packaging Manual
\emph default 
 at http://www.debian.org/doc/packaging-manuals/packaging.html/.
\layout Bibliography
\bibitem {5}

Quinlan, Daniel.
 
\emph on 
Filesystem Hierarchy Standard
\emph default 
 at http://www.pathname.com/fhs/.
\layout LyX-Code

\the_end