[python-ldap] signed releases

[Philipp Gesang]

Hi Petr,

thanks for your reply.

-<| Quoting Petr Viktorin <pviktori at redhat.com>, on Monday, 2019-01-28 05:02:54 PM |>-
> On 1/25/19 3:04 PM, Philipp Gesang wrote:
> > the official(?) repo doesn’t appear to have signed tags and the
> > tarballs [1] are not accompanied by signature files either.
> 
> I don't normally use a signature, and I'm not part of any webs of trust, so
> I'm not sure what a signed release would accomplish.

For me as the one in charge of packaging it would allow verifying
the origin of a source tarball.

Internally we perform the check at packaging time (during the
%prep phase of rpmbuild, to be exact) wherever possible against a
static key or keyring that is part of the SRPM. When the
verification fails after an update it can mean a) upstream’s
signing key changed or b) something is wrong with the tarball. A
little bit of research (or an email to some mailing list ;)) will
easily confirm / rule out a).

Web of trust style key distribution is optional btw. You can just
publish the public key or a dedicated keyring on the project
website.

> Could you explain the security model a signature would allow, and what kind
> of security practices you'd expect the signer to follow?

The Apache project did a good job documenting best practices and
the motivation: https://www.apache.org/dev/release-signing.html

> > Consequently it’s not easy to establish the provenance of
> > releases.
> 
> Those tarballs are generated by GitHub from the corresponding Git commit.

That’s why signed release tags would work as well: I would run
“git tag -v” on the tag and just package the tarball from the
sources.

Best regards,
Philipp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20190129/9551ecf7/attachment.sig>