On Fri, 2007-08-24 at 09:01 -0700, Neal Norwitz wrote:
Right. I looked at this with Jeffrey Yasskin and agree that a lock is
needed for f_fp. The fix is ugly because it's needed around all
accesses to f_fp and there are a ton of them. Some are with the GIL
held and others when it isn't.
Honestly, the argument that this code is already gone in 3.0 is not very
valid. 2.x version would be probably used for many years.
Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
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
apt-get install openssl will fix that on those systems. on windows you're
unlikely to ever have an openssl binary present and available to execute.
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
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.
Here's a patch that does that.
Bill
Index: Lib/test/keycert.pem
Committed revision 57561.
On 8/27/07, Bill Janssen [EMAIL PROTECTED] wrote:
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
I must admit I fail to see the bug. If root untars a file, and that tar
file contains an instruction to overwrite /etc/passwd, why is an error
to execute that instruction? Shouldn't root just be more careful when
untaring
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lars Gustäbel wrote:
Suppose we have:
foo - /etc
foo/passwd
If creation of the foo symlink is delayed, foo/passwd will be
extracted in a directory foo which will be created implicitly.
If we create the foo symlink afterwards it will fail
Some of the code sets the error string in this directly before
returning NULL, and other pieces of the code call PySSL_SetError,
which creates the error string. I think some of the places which set
the string directly probably shouldn't; instead, they should call
PySSL_SetError to cons up
Committed revision 57568.
Anything else I can check in for you?
On 8/27/07, Bill Janssen [EMAIL PROTECTED] wrote:
Some of the code sets the error string in this directly before
returning NULL, and other pieces of the code call PySSL_SetError,
which creates the error string. I think some
Anything else I can check in for you?
Ho, ho!
No, I'm done for now. I think everything is working; let's see what
the buildbots say. I've got to do some job work now, and I promised
Barry I'd help with the email work, but I'll get back to this with a
port to the Py3K branch. I'd also like to
On Mon, Aug 27, 2007 at 07:40:36PM +0200, Jan Matejek wrote:
Lars Gustäbel wrote:
Suppose we have:
foo - /etc
foo/passwd
If creation of the foo symlink is delayed, foo/passwd will be
extracted in a directory foo which will be created implicitly.
If we create the foo symlink
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,
13 matches
Mail list logo
