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,
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
> 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
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 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 u
-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 fa
-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
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 pregen
> 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
===
> 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
a
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
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
Unsubscr
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.
13 matches
Mail list logo
