Differences between revisions 1 and 2
Revision 1 as of 2021-03-02 02:03:47
Size: 2472
Editor: GuillemJover
Comment: Add initial spec
Revision 2 as of 2021-03-02 23:21:56
Size: 2848
Editor: GuillemJover
Comment: List implementations that might need to reject weak algos, add upstream contacting
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
  * Warn on deprecated algorithms. DebianBug:983069, DebianBug:983070   * Warn on deprecated algorithms.
    * lintian DebianBug:983069
    * devscripts (uscan, debsign) DebianBug:983070
    * dpkg (dpkg-buildpackage, dpkg-source): Fixed locally
    * debsig-verify: Fixed locally
    * dupload: Fixed locally
    * dput:
    * dput-ng:
Line 20: Line 27:
  * Should we standardize a new pathname to ship encryption-capable certificates to contact upstream, say, for security reporting? (f.ex. debian/upstream/security-contact.asc)
Line 21: Line 29:
  * Improve tooling to ease managing debian/upstream/signing-key.asc.
   
Sequoia can help here as it can work directly with ASCII Armored keyrings.
  * Improve tooling to ease managing debian/upstream/signing-key.asc. Sequoia can help here as it can work directly with ASCII Armored keyrings.

Upstream Tarball Signatures

This is now already supported by the packaging tooling, but there are still several things that could be improved or polished, in the tooling, infrastructure or workflow, practices and policies, and perhaps documentation.

Here's a list of problems brought up by Daniel Kahn Gillmor:

Problems/Proposals:

  • Warn on deprecated algorithms.
    • lintian 983069

    • devscripts (uscan, debsign) 983070

    • dpkg (dpkg-buildpackage, dpkg-source): Fixed locally
    • debsig-verify: Fixed locally
    • dupload: Fixed locally
    • dput:
    • dput-ng:
  • How to handle upstream key transitions and deprecation of upstream keys?
    • Document the process for maintainers?
      • Check new signing certificate is signed by old signing certificate.
      • Check uid in both certificates match. If they don't? Poke upstream?
      • Replace old signing certificate with new one in debian/upstream/signing-key.asc, making sure the new signing certificate is minimized (stripping encryption-capable subkeys, expired subkeys, revoked User IDs, irrelevant user IDs, and most (all?) third-party certifications).
    • Document in the UpstreamGuide page what's expected from upstream.

    • Perhaps this could be automated by a service checking for upstream releases:
      • When it detects a new sig with an unknown signing certificate, doing the chain verification if possible, and if any subtle changes in uid are found, prompt the maintainer to send a mail to upstream?
      • Otherwise if successful, committing directly the changes to git, or sending an MR, or filing an automatic bug report or similar?
    • Perhaps a service emits a warning whenever the upstream signing certificate is close to expiry?
  • Should we standardize a new pathname to ship encryption-capable certificates to contact upstream, say, for security reporting? (f.ex. debian/upstream/security-contact.asc)
  • Dashboard or overview of current percentage of upstream packages with signed orig tarballs, deprecated algo usage, etc. Probably lintian could serve as a starting point, perhaps the Package tracker or DDPO could gain some of this.
  • Improve tooling to ease managing debian/upstream/signing-key.asc. Sequoia can help here as it can work directly with ASCII Armored keyrings.
  • How to verify the git tree mapping to a tarball release:
    • Ship the signed git tag object perhaps?
  • How to handle releases cut out of signed git tags with no signed tarball releases?
    • The "3.0 (git)" format could be used, one issue in the past has been the inclusion of history, dpkg-source could default to --git-depth=1 (queue that for 1.21.x).
  • How to handle releases cut out of git snapshots, or repackaged. There are currently probably out of scope.


CategorySpec