Ben Finney <> writes:

> Debian's UScan has the ability to find, download, and verify the GnuPG
> signature for a package source release. Lintian will remind the
> maintainer if a Debian source package is not taking advantage of this.

A related issue is:

Should we be using PyPI as our source of packages? Or github?

You mention a very good reason why PyPI should be the preferred form,
packages *can* be signed by the author.

However, often packages in PyPI are not the complete source package you
would get from github. They may be sufficient for installations, but
often not for Debian packaging - which really should have the complete
source package. e.g. they can be missing tests, license files,
documentation that doesn't get installed, etc.

Sure, you could argue that PyPI source packages should contain
everything the github package does. In fact there is a PyPI tool to help
get the correct for such purposes -; however a counter argument
could also be made that upstrems generally don't care about such issues
- probably won't notice any regressions - if it installs from PyPI that
is all that really matters - and the only way we can be sure we are
getting the complete source iis from github.

Unfortunately, github releases cannot (AFAIK) easily be signed, unless
you retrieve signed git tags directly from git (which is not supported
by uscan AFAIK). Would be good if gbp buildpackage supported signing git
tags, I don't think it does either.

I started off thinking github was the best source, then slowly swayed
towards PyPI, now I am thinking maybe github again.


Some related issues:

* Do we consider signed git tags / commits secure, considering they are
  based on SHA1?

* Is there any point having signed PyPI releases when (very likely) the
  underlying upstream git repository has no signatures?

* Is there any point having signed PyPI releases when (very likely) the
  public key is stored in an insecure DPMT respository on
Brian May <>

Reply via email to