Packages
I publish a signed package repository, and here's how it works.
The system administrator configures repositories by adding a configuration file such as /usr/local/etc/pkg/repos/JdeBP.conf
. As part of doing so, xe tells the package manager the public key that is to be used to check the signatures on the repository. Xe obtains this key from me in some suitably trusted fashion, and saves it in a file somewhere like /usr/local/etc/pkg/keys/JdeBP.pub
. Xe then names that as the public key file in /usr/local/etc/pkg/repos/JdeBP.conf
.
I sign the package repository with the private key that only I have using the command pkg repo . /elsewhere/package_signing_key
. This creates signed information about the repository and the packages in three files, meta.txz
, digests.txz
, and packagesite.txz
. Each of those archives has two files, one being a signature
file for the other. The digests and packagesite archives contain hashes of each of the package archive files. The meta archive just contains the names of the other two and some versioning of the pkg-ng tool information.
So this is very much like Secure APT. There are some differences:
- Instead of
Release
giving the checksums for Packages
and Packages
then giving the hashes for the actual package archives, pkg-ng has just one level. packagesite.yaml
gives the hashes of the actual package archives directly.
- Instead of things being split into separately downloadable
Release
and Release.gpg
files, and then further Packages
and Sources
files, the packagesite.yaml
file (covering the entire repository) and its signature
are downloaded as a unit in one fetch
operation (and one HTTP/FTP transaction) as the packagesite.txz
file.
But the idea is much the same. A system administrator trusts that the packagesite.yaml
file came from me because its accompanying signature
can be checked against the locally stored, trusted, copy of my public key. A system administrator trusts that the redo-1.3.txz
file came from me because its hash matches the hashes from the (now) trusted packagesite.yaml
.
Ports
Ports are a very different kettle of fish. Debian's Secure APT treats source packages as just more packages. FreeBSD/TrueOS ports are not source packages in the Debian sense, but are rather automated ways of obtaining and building source packages that are published by someone else. A port is in essence a makefile with some instructions on where to fetch
source from. It has a list of the hash(es) of whatever is to be fetched.
The port itself comes from the FreeBSD or TrueOS repository, using either Subversion (if FreeBSD) or git (if TrueOS or FreeNAS). The standard ideas for trusting Subversion or git thus apply. On TrueOS, for example, the "remote" URL used when fetching the ports (themselves) with git is an HTTPS url for a GitHub repository that iXsystems vouches (in the TrueOS Handbook) is one that it owns.
So a system administrator trusts a port because xe has obtained it using a Subversion or git fetch that xe trusts. Xe trusts the source archive fetched by the port because it matches the hash listed in the (now) trusted port.
Notes
Debian's Release.gz
and Packages.gz
are pretty much in effect just ways to compress the HTTP transport. I've glossed over some other things that aren't to do with security, such as differences in how one is expected to handle multiple operating system releases.
Debian has moved towards how FreeBSD works over the years, and doesn't work like that wiki page says any more. Nowadays one has the hashes and the signature all in one, more like a FreeBSD repository, in an InRelease
file. This prevents a "tearing" problem that occurs when one downloads Release
and then Release.gpg
and the repository owner has updated the repository in between the two downloads, causing a signature mis-match.
(Debian only did things this way originally because it grew these things in stages over the years, each built upon the preceding mechanisms without changing them: first the Package
system, then the Release
mechanism on top of that, then the Release.gpg
mechanism on top of that.)
Also: FreeBSD has another, different, way of doing this which involves "fingerprints" and a signed digests
file (in the digests.txz
archive).
I've also glossed over the security considerations for the signing key, as that isn't really relevant to an answer that is discussing how this is like/unlike Secure APT. The requirements of private key security are general to the whole notion of signing things with public/private keys, and are independent of repository structures.
Further reading