apparent serious integrity problem in build system - setuptools bug?

[Greg Troxel]

Zooko Wilcox-OHearn <zooko at leastauthority.com> writes:

> 2. pyOpenSSL just updated from 0.13 to 0.14, and newly depends on a
> new project named cryptography.io: https://cryptography.io . To deal
> with this is ticket #2193.
>
> My current plan for #2193 is to pin Tahoe-LAFS's dependency on
> pyOpenSSL ¹ to pyOpenSSL == 0.13.

My ticket comment failed spam filtering, with 98.5% probability.  And
then when I hit back it was gone from the input box.  So the new spam
solution seems ungood; I'd far prefer to have less filtering and require
accounts to be given permission, but I realize that's more manual work.
Or maybe be able to mark known accounts not to get filtered; I think I
have a pretty good non-spam track record :-)

Regarding pinnning the dependency to 0.13, I don't think that's a
resaonable approach.  First, I think that any software that is broadly
successful is used almost entirely from prebuilt packages in various
packaging systems (or for us odd pkgsrc types, automatically built from
source using the packaging system, which amounts to the same thing).

My impression is that python generally does not support installing
multiple versions of a package, e.g py-OpenSSL 0.13.1 and 0.14 both.
(While pkgsrc has made python27 and python33 parallel installable, and
most libraries can have both at once, I haven't seen this extend to
individual libraries.)  So a packaging system has to just pick a
version.  Given that upstreams do not do security maintenance on
obsolete versions, the only reasonable choice is the latest, except that
taking a few months to move to a new release is also reasonable.  So
packaging systems soon (within a year) will no longer offer py-OpenSSL
0.13.1.

Twisted also requires py-OpenSSL, so I think fighting this implies
pulling py-Twisted and py-OpenSSL into tahoe sources.  That seems crazy
in terms of maintenance burden.

Overall, my impresssion is that we're seeing a big hiccup because of a
poorly-documented unexpected rototill, and that once packaging systems
catch up with the new dependencies, things will be ok as far as building
tahoe in a packaging system context (or installing deps from packaging
system and then building tahoe itself from source).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20140322/fb601a28/attachment.pgp>