Hey all,
So, as per the GR, I've been adding a class of restricted uploaders to
dak; here's how that works.
(1) keyring changes
DMs have their own keyring, kept in:
ries:/srv/ftp.debian.org/keyrings/debian-maintainers.gpg
In order to verify uploads from three keyrings instead of just two
I've changed the Dinstall::PGPKeyring/GPGKeyring options to a single
Dinstall::GPGKeyring option that includes a list of keys.
Rather than implementing the upload restrictions based directly on
the keyring, each of those keyrings are treated exactly the same for
verifications. The restrictions are instead implemented by mapping
fingerprints to the uid table.
(2) dak import-keyring
This means that DM keys have to be associated with a uid entry as
soon as they're included in the keyring dak looks at, rather than
at some point after the first upload signed by that key is made as
occurs for DD keys.
This association is performed by "dak import-keyring --generate-users"
which reads a keyring for all its signing fingerprints (both primary and
secondary) and will create users which will have the id "dm:<email>"
and full name generated from the first uid entry in the keyring. The
"dm:" pattern distinguishes generated uids from DD uids, and is used for
the upload restrictions.
"dak import-keyring" without the --generate-users flag should be able
to be used for DD keyrings, but at this time there doesn't seem to be
any point to doing so.
(3) dak clean-suites
Having to track fingerprints for keys prior to that key being used to
upload a package means that dak clean-suites can't delete all fingerprints
that aren't related to packages in the archive. So I've limited it to
only delete fingerprints that don't have the keyring field set.
That means that DM fingerprints will be deleted only once they no longer
appear in the DM keyring _and_ none of the packages they've signed are in
the archive.
(4) src_uploaders table
To implement upload restrictions we need some sort of information on who
is allowed to upload what. As such I've created a src_uploaders table
that relates an existing source package (by source id) with one or more
entries in the maintainers table. This table is updated when a package
is accepted, with the entries being the values from the Maintainer: and
Uploaders: fields. If the Dm-Upload-Allowed: field isn't present with
the value "yes", no new entries are added. Entries are deleted when the
source package is removed from the archive with dak clean-suites.
(5) process_unchecked upload restrictions
I've changed check_signed_by_key() to first lookup a uid from the
fingerprint used to sign the changes file. This will always be present
for DM keys (as detailed above), but may not be for DD keys. So if
there is a uid and it begins with "dm:" upload restrictions are applied,
such that sponsored uploads are not allowed (may_sponsor), and nor are
NMUs/BYHAND/NEW uploads (may_nmu).
Sponsored uploads are determined by checking for the uid's name and email
address appearing in the Maintainer: or Changed-By: field of the changes
file.
"NMUs" are determined by:
- find the source_ids of all the source packages that are being
replaced by the upload, as well as version of the source
package in unstable
- if any of those source_ids don't have an entry in src_uploaders
that corresponds with the uploader's uid, it's considered an NMU
In addition, if may_nmu isn't set, checks are made for:
- replacing binaries from a different source package
- BYHAND files
- NEW files
The existing Binary-Upload-Restrictions checks follow at this point.
(6) Automatic BYHAND processing
(This was mostly implemented earlier for automatic Tags: override
processing)
Automatic byhand processing requires a stanza in dak.conf, eg:
AutomaticByHandPackages {
"debian-maintainers" {
Source "debian-maintainers";
Section "raw-keyring";
Extension "gpg";
Script "/srv/ftp.debian.org/dak/scripts/debian/byhand-dm";
};
};
The above stanza allows for the "debian-maintainers" source package to
include a byhand file in section raw-keyring, named after the stanza field
(in this case also "debian-maintainers"):
debian-maintainers_${VER}_${ARCH}.gpg
where $VER matches the source package version, and $ARCH is an
architecture-like string (i386, all, source, or similar).
When such a byhand package is found, the nominated script is invoked with
arguments:
$1 = name of the byhand file (cwd remains as queue/holding)
$2 = $VER
$3 = $ARCH
$4 = full path to the .changes file
If the script finishes successfully, the byhand file is unlinked;
if all byhand files from a source package succeed in being processed
automatically the package is ACCEPTed automatically, otherwise it's
passed back to the BYHAND queue (minus any byhand files that were
accepted automatically).
Note that this suffers from the bug that autobyhand files aren't
removed from q/unchecked. This is the same bug as when .orig.tgz
files aren't deleted from q/unchecked after being already found
in the pool or queue, and occurs because the only files deleted
from q/unchecked are the ones with entries in the files dict (see
process_unchecked.py:remove_from_unchecked).
raw-.* is accepted as an alias for byhand.
The DM keyring uploads are processed by:
finding the fingerprint used to sign the .changes file using
gpgv and the debian-keyring.gpg keyring (ie, not the DM keyring
and not the .pgp DD keyring).
finding the uid corresponding to that fingerprint via projectb
seeing if there's an entry in the src_uploaders table for
the debian-maintainers package corresponding to "$NAME
<$UID@debian.org>"
if there isn't; treat it as regular byhand
if there is, copy the uploaded keyring over the previous DM
keyring, and run dak import-keyring --generate-users on it
As such, control over the keyring should be able to be managed by regular
uploads with access limited using the Uploaders: field. This requires
the Dm-Upload-Allowed: yes field to be set in the DM keyring package in
order to get an entry in the src_uploaders table.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature