apparent serious integrity problem in build system - setuptools bug?

Zooko Wilcox-OHearn zooko at
Mon Mar 17 23:09:14 UTC 2014


Thanks for the issue report, gdt.

Here's what I know so far:

1. The Tahoe-LAFS build system (which is based on setuptools) will
download and execute any package which says is the
"foo" package, if any part of Tahoe-LAFS transitively depends on a
package named "foo". To change it so that it *doesn't* automatically
download packages over the Net is ticket #1220.

2. pyOpenSSL just updated from 0.13 to 0.14, and newly depends on a
new project named . 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.

I have a question for you: how did "cryptography" and "six" get into
the dependencies that setuptools is trying to satisfy (in your
transcript above)? I would guess that "cryptography" got in there
because of "pyOpenSSL", and that "six" got in there because of
"cryptography", but why didn't your build use the pyOpenSSL package
that was already installed!?

I have a suggestion for you: go ahead and patch Tahoe-LAFS's
src/allmydata/ to specify "pyOpenSSL == 0.13" instead of
just "pyOpenSSL" if it helps.

Please let us know what you learn.

See also relevant tickets #1582, #2055, and #2077.



¹ build/install
should be able to refrain from getting dependencies setuptools delenda est Building tahoe
safely is non-trivial pip packaging plan pyOpenSSL 0.14
pulls in a bunch of new dependencies

More information about the tahoe-dev mailing list