Fwd: Changes to Debian Maintainer upload permissions

[Adrian Knoth]

Hi!


I'm currently travelling and cannot closely follow the discussion on
debian-devel, but this could turn out to be relevant for us, too.


Cheers

-------- Original Message --------
Subject: Changes to Debian Maintainer upload permissions
Resent-Date: Sat, 22 Sep 2012 08:07:06 +0000 (UTC)
Resent-From: debian-devel-announce at lists.debian.org
Date: Sat, 22 Sep 2012 10:06:35 +0200
From: Ansgar Burchardt <ansgar at debian.org>
To: debian-devel-announce at lists.debian.org

During the FTPMaster meeting last week we have implemented the new
interface for managing DM permissions[1].

This new interface replaces the old DMUA field. The old field will stop
working on the 24th of November 2012, from then on only packages
explicitly granted upload permission to their DMs using the interface
described here will pass the DM check.

We are using this opportunity to clean up the "DM database" and will not
convert any of the DMUA flags to the new format, but two months ought to
be enough for any active DM to ensure their sponsor DDs have set the new
permission.

This new interface has various advantages over the old DMUA-flag style:

  - No longer bound to whatever GnuPG thinks of as "primary UID" on a
    key, solely uses the key fingerprint now.
  - Granting (or revoking) a DM upload permission no longer needs changes
    to a package with a sourceful upload.
  - DM rights are bound to people, not to packages. (Imagine a package
    with ten DMs somewhere in the Uploader line, but only one should
    really have the upload rights. (think of bigger teams and so)).
  - DM can't give another DM upload rights for "his" package anymore.
  - DMs no longer need to be listed at all in
    Maintainers/Uploaders/Changed-By (again, good for teams)


Changing upload permissions is done by creating and uploading a signed
file named $login-EPOCH.dak-commands (say 'ansgar-1348293.dak-commands')
using the following format:

----
Archive: ftp.debian.org
Uploader: A Developer <adeveloper at example.com> (optional)

Action: dm
Fingerprint: 1234567890ABCDEF1234567890ABCDEF
Allow: one-package another-package
Deny: yet-another-package
----

This file has to be uploaded to ftp.upload.debian.org. Don't use any of
the queues we provide elsewhere for now, they are not (yet?) handling
them. You can include as many additional action sections as you want to
manage permissions for multiple DMs in one run. The Deny field has
precedence, so allowing and then denying a package in the same run will
forbid the DM to upload said package.

Both the DD and DM will get a mail notification about any changes
taken.

As we all are lazy and hate to construct such files by hand, Gergely
Nagy is working on integrating a new tool into devscripts to make
creating .dak-commands files easier[2].

To check the archives knowledge about DMs you can look at the export[3]
updated during dinstall. This file is machine-readable in the usual 822
format we here at Debian love so much, with stanzas like

----
Fingerprint: 1234567890ABCDEF1234567890ABCDEF
Uid: example
Allow: one-package another-package
----

We plan to use this interface in the future for other purposes, such as
copying packages from experimental to unstable or other PPA related
features we are having on our roadmap. Please DO NOT use it to
break-the-archive.

Ansgar, for the ftp team

   [1] <http://lists.debian.org/debian-devel/2012/06/msg00321.html>
   [2] <http://bugs.debian.org/688319>
   [3] <https://ftp-master.debian.org/dm.txt>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Attached Message Part
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20120923/afac5242/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attached Message Part
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20120923/afac5242/attachment-0001.pgp>