Could you also look into this problem:
Traceback (most recent call last):
line 486, in __bootstrap_inner
line 144, in run
line 98, in __init__
cert_reqs, ssl_version, ca_certs)
sslerror: _ssl.c:271: SSL_CTX_use_PrivateKey_file error
This occurs on at least 3 of the buildbots (ubuntu and debian on ia64,
ppc, and hppa). Here's one example:
This also looks like it's not working on windows, but there is no info
The system cannot find the path specified.
Which happens after it hangs for 1200 seconds.
On 8/25/07, Bill Janssen <janssen(a)parc.com> wrote:
> I've gone through the other open SSL issues. Looks like some can be
> closed with the adoption of 1018 and 1024:
> 1027394 4 months ago socket.ssl should explain that it is a 2/3 connection
> 889813 4 months ago making the version of SSL configurable when creating sockets
> 1583946 9 months ago SSL "issuer" and "server" names cannot be parsed
> 783188 46 months ago support for server side transactions in _ssl
> Others are about various standard libraries that interact with SSL
> in various ways. I'm working on another patch that converts all the
> standard library modules over to use the new ssl module, and I'll look
> at the rest of the SSL-related bugs as part of that work.
> Python-Dev mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
-----BEGIN PGP SIGNED MESSAGE-----
once upon a time there was a known vulnerability in tar (CVE-2001-1267,
), and while tar is now long fixed, python's tarfile module is
The vulnerability goes basically like this: If you tar a file named
"../../../../../etc/passwd" and then make the admin untar it,
/etc/passwd gets overwritten.
Another variety of this bug is a symlink one: if tar contains files like:
./aaaa-directory -> /etc
then the "aaaa-directory" symlink would be created first and /etc/passwd
will be overwritten once again.
I was wondering how to fix it.
The symlink problem obviously applies only to extractall() method and is
easily fixed by delaying external (or possibly all) symlink creation,
similar to how directory attributes are delayed now.
I've attached a draft of the patch, if you like it, i'll polish it.
The traversal problem is harder, and it applies to extract() method as well.
For extractall() alone, i would use something like:
warnings.warn("non-local file skipped: %s" % tarinfo.name,
For extract(), i am not sure. Maybe it should throw exception when it
encounters such file, and have a special option to extract such files
anyway. Or maybe it should be left alone altogether.
Any suggestions are welcome.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
I was wondering if an additional Windows buildbot would be helpful, in
particular for py3k? If so, I should be able to run one, and wanted to
request a buildbot account, as mentioned on the buildbot page on python.org.
I've got some idle hardware - nothing fancy (x86 P4, 2.8GHz) but it's up and
infrequently used, with a solid broadband connection.
I had some time to test, so set up a Windows XP SP2 virtual machine with all
the various pieces needed for a buildbot. The host machine happens to run
XP too, but using a virtual machine was a bit cleaner (including easy
relocation over time if needed). I've manually done full builds of Python
2.5.1 (from release25-maint), 2.6a0 (from trunk), and 3.0x (from py3k) using
the buildbot build and test batch files under tools, so I think the
environment is good. 2.5.1 tested clean, 2.6a0 had two errors in test_ssl
and test_winreg but they match some existing buildbots. The 3.0 tests are
ugly, including a NULL pointer debug assertion triggered in test_os that
kills the test run, but I'm assuming that's just the current state of 3.0.
I've lurked on 3000-devel, but am not intimately up to date on expected
behavior under Windows.
Anyway, if it would be useful, I figured I could use this virtual machine
for a buildbot for at least trunk and 3k, perhaps with 2.5 too. Not sure if
that requires multiple accounts, or if you configure each buildbot instance
with an SVN path (I didn't see anywhere obvious for the latter).
I think the next steps to take are as follows, in order:
1) Generate a patch to the trunk to remove all use of socket.ssl in
library modules (and elsewhere except for
test/test_socket_ssl.py), and switch them to use the ssl module.
This would affect httplib, imaplib, poplib, smtplib, urllib,
This patch should also deprecate the use of socket.ssl, and
particularly the "server" and "issuer" methods on it, which can
return bad data.
I don't know how to deprecate something... Pointers?
2) Expand the test suite to exhaustively test edge cases, particularly
things like invalid protocol ids, bad cert files, bad key files,
3) Take the threaded server example in test/test_ssl.py, clean it up,
and add it to the Demos directory (maybe it should be a HOWTO?).
4) Generate a patch for the Py3K branch. This patch would remove the
"ssl" function from the socket module, and would also remove the
"server" and "issuer" methods on the SSL context. The ssl.sslsocket
class would be renamed to SSLSocket (PEP 8), and would inherit
from socket.socket and io.RawIOBase. The current improvements to
the Modules/_ssl.c file would be folded in. The patch would
also fix all uses of socket.ssl in the other library modules.
5) Generate a package for older Pythons (2.3-2.5). This would
install the ssl module, plus the improved version of _ssl.c.
Needs more design.
nope, not on many package based distributions. libssl0.9.8, libssl-dev and
openssl are all separate packages (with appropriate dependencies).
/usr/bin/openssl comes from the openssl package.
Regardless, building a fixed test certificate and checking it in sounds like
the better option. Then the openssl command in the test code can be turned
into a comment describing how the test data was pregenerated.
On 8/27/07, Bill Janssen <janssen(a)parc.com> wrote:
> > apt-get install openssl will fix that on those systems. on windows
> > unlikely to ever have an openssl binary present and available to
> Well, if you have OpenSSL in the first place, you'll have the binary,
> won't you? But I agree it's unlikely to be on your path. As for Ubuntu
> and Debian, I checked the packaging, and they both put the "openssl"
> in /usr/bin, so it's unlikely to be a path problem.
> We could just build a fixed certificate and check it in, as the
> test does. That way we wouldn't have to futz with trying to run openssl.