From philipp.gesang at intra2net.com  Fri Jan 25 09:04:13 2019
From: philipp.gesang at intra2net.com (Philipp Gesang)
Date: Fri, 25 Jan 2019 15:04:13 +0100
Subject: [python-ldap] signed releases
Message-ID: <20190125140413.GC4274@drift.m.i2n>

Hey guys,

the official(?) repo doesn?t appear to have signed tags and the
tarballs [1] are not accompanied by signature files either.
Consequently it?s not easy to establish the provenance of
releases.

Would it be possible to provide signed release tarballs or at
least sign release tags?

Please Cc: me, as I?m not subscribed.

Thank you,
Philipp

[0] https://github.com/python-ldap/python-ldap/
[1] E. g. https://github.com/python-ldap/python-ldap/releases/tag/python-ldap-3.1.0

-------------- 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/20190125/8ce25e6d/attachment.sig>

From pviktori at redhat.com  Mon Jan 28 11:02:54 2019
From: pviktori at redhat.com (Petr Viktorin)
Date: Mon, 28 Jan 2019 17:02:54 +0100
Subject: [python-ldap] signed releases
In-Reply-To: <20190125140413.GC4274@drift.m.i2n>
References: <20190125140413.GC4274@drift.m.i2n>
Message-ID: <c43023a6-8aca-2f0c-9de6-e97320bfcfae@redhat.com>

On 1/25/19 3:04 PM, Philipp Gesang wrote:
> Hey guys,

Hello!
(I assume not only guys are included?)

> 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.
Could you explain the security model a signature would allow, and what 
kind of security practices you'd expect the signer to follow?

> Consequently it?s not easy to establish the provenance of
> releases.

Those tarballs are generated by GitHub from the corresponding Git commit.

> Would it be possible to provide signed release tarballs or at
> least sign release tags?
>
> Please Cc: me, as I?m not subscribed.

Please don't forget to reply to the list :)


> [0] https://github.com/python-ldap/python-ldap/
> [1] E. g. https://github.com/python-ldap/python-ldap/releases/tag/python-ldap-3.1.0

From philipp.gesang at intra2net.com  Tue Jan 29 03:01:52 2019
From: philipp.gesang at intra2net.com (Philipp Gesang)
Date: Tue, 29 Jan 2019 09:01:52 +0100
Subject: [python-ldap] signed releases
In-Reply-To: <c43023a6-8aca-2f0c-9de6-e97320bfcfae@redhat.com>
References: <20190125140413.GC4274@drift.m.i2n>
 <c43023a6-8aca-2f0c-9de6-e97320bfcfae@redhat.com>
Message-ID: <20190129080152.GA3963@drift.m.i2n>

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>

From pviktori at redhat.com  Wed Mar 13 10:26:46 2019
From: pviktori at redhat.com (Petr Viktorin)
Date: Wed, 13 Mar 2019 15:26:46 +0100
Subject: [python-ldap] ANN: python-ldap 3.2.0
Message-ID: <1adfc270-ab44-4426-0866-440e8c38dfab@redhat.com>


Find a new release of python-ldap here:

    https://pypi.python.org/pypi/python-ldap/3.2.0

Notable changes since 3.1.0 are:

- Add support for X-ORIGIN in ldap.schema's ObjectClass
* Make initialize() pass extra keyword arguments to LDAPObject
- Provide ldap._trace_* atributes in non-debug mode


If you find any issues, please report them either on this mailing list 
or on the GitHub tracker:

     https://github.com/python-ldap/python-ldap/issues


About the project:

     python-ldap provides an object-oriented API to access LDAP directory
     servers from Python programs. It mainly wraps the OpenLDAP 2.x libs
     for that purpose. Additionally it contains modules for other
     LDAP-related stuff (e.g. processing LDIF, LDAP URLs and LDAPv3
     schema).

Project's web site:

     https://www.python-ldap.org/



Git tag hash for the release:
     python-ldap-3.2.0  70e326210c25019b3df732c01ecee8caffec917e

The tag is signed by my GPG key with fingerprint:
AD4D FBDB 5D40 4CA8 0600  A5F4 0BA8 70E7 9E17 2F37

----------------------------------------------------------------
Released 3.2.0 2019-03-13

Lib/
* Add support for X-ORIGIN in ldap.schema's ObjectClass
* Make initialize() pass extra keyword arguments to LDAPObject
* ldap.controls.sss: use str instead of basestring on Python 3
* Provide ldap._trace_* atributes in non-debug mode

Doc/
* Fix ReST syntax for links to set_option and get_option

Tests/
* Use intersphinx to link to Python documentation
* Correct type of some attribute values to bytes
* Use system-specific ENOTCONN value

Infrastructure:
* Add testing and document support for Python 3.7
* Add Python 3.8-dev to Tox and CI configuration
* Add Doc/requirements.txt for building on Read the Docs