Re: [Python-Dev] Segfault
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.
The way I see it, when the GIL is held, we're in the clear because
f->f_fp can only disappear with the GIL held. The troublesome cases are
those ones where f_fp is accessed inside an "allow threads" section.
To fix this, it shouldn't be necessary to change every individual place
that accesses f_fp. It is sufficient to protect the sections that
specifically allow threads, changing the semantics from "allow threads"
to "allow threads, locking out the ones operating on the same
fileobject".
For example, instead of Py_BEGIN_ALLOW_THREADS, the fileobject code
could use a macro such as:
#define PyFile_BEGIN_PROTECT(f) \
PyThread_acquire_lock(f->f_lock, 1); \
if (!f->f_fp) \
;\
else {
#define PyFile_END_PROTECT(f)\
} \
PyThread_release_lock(f->f_lock);
That change might be somewhat easier than changing each individual line
that accesses f->f_fp.
> I would be fine with the much simpler approach in the patch I sent
> (assuming the patch is finished). It doesn't completely address the
> problem, but does make the race condition much, much smaller. Part of
> the reason I'm ok with this is that in 3.0, all this code has already
> been removed.
That is a good point. Does your patch make the race crash go away
entirely in the tests like the one the OP posted?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segfault
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
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 <[EMAIL PROTECTED]> wrote: > > > 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 > and Debian, I checked the packaging, and they both put the "openssl" > binary > 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_socket_ssl > test does. That way we wouldn't have to futz with trying to run openssl. > > Bill > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
> 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 and Debian, I checked the packaging, and they both put the "openssl" binary 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_socket_ssl test does. That way we wouldn't have to futz with trying to run openssl. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
> 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
===
--- Lib/test/keycert.pem(revision 0)
+++ Lib/test/keycert.pem(revision 0)
@@ -0,0 +1,32 @@
+-BEGIN RSA PRIVATE KEY-
+MIICXwIBAAKBgQC8ddrhm+LutBvjYcQlnH21PPIseJ1JVG2HMmN2CmZk2YukO+9L
+opdJhTvbGfEj0DQs1IE8M+kTUyOmuKfVrFMKwtVeCJphrAnhoz7TYOuLBSqt7lVH
+fhi/VwovESJlaBOp+WMnfhcduPEYHYx/6cnVapIkZnLt30zu2um+DzA9jQIDAQAB
+AoGBAK0FZpaKj6WnJZN0RqhhK+ggtBWwBnc0U/ozgKz2j1s3fsShYeiGtW6CK5nU
+D1dZ5wzhbGThI7LiOXDvRucc9n7vUgi0alqPQ/PFodPxAN/eEYkmXQ7W2k7zwsDA
+IUK0KUhktQbLu8qF/m8qM86ba9y9/9YkXuQbZ3COl5ahTZrhAkEA301P08RKv3KM
+oXnGU2UHTuJ1MAD2hOrPxjD4/wxA/39EWG9bZczbJyggB4RHu0I3NOSFjAm3HQm0
+ANOu5QK9owJBANgOeLfNNcF4pp+UikRFqxk5hULqRAWzVxVrWe85FlPm0VVmHbb/
+loif7mqjU8o1jTd/LM7RD9f2usZyE2psaw8CQQCNLhkpX3KO5kKJmS9N7JMZSc4j
+oog58yeYO8BBqKKzpug0LXuQultYv2K4veaIO04iL9VLe5z9S/Q1jaCHBBuXAkEA
+z8gjGoi1AOp6PBBLZNsncCvcV/0aC+1se4HxTNo2+duKSDnbq+ljqOM+E7odU+Nq
+ewvIWOG//e8fssd0mq3HywJBAJ8l/c8GVmrpFTx8r/nZ2Pyyjt3dH1widooDXYSV
+q6Gbf41Llo5sYAtmxdndTLASuHKecacTgZVhy0FryZpLKrU=
+-END RSA PRIVATE KEY-
+-BEGIN CERTIFICATE-
+MIICpzCCAhCgAwIBAgIJAP+qStv1cIGNMA0GCSqGSIb3DQEBBQUAMIGJMQswCQYD
+VQQGEwJVUzERMA8GA1UECBMIRGVsYXdhcmUxEzARBgNVBAcTCldpbG1pbmd0b24x
+IzAhBgNVBAoTGlB5dGhvbiBTb2Z0d2FyZSBGb3VuZGF0aW9uMQwwCgYDVQQLEwNT
+U0wxHzAdBgNVBAMTFnNvbWVtYWNoaW5lLnB5dGhvbi5vcmcwHhcNMDcwODI3MTY1
+NDUwWhcNMTMwMjE2MTY1NDUwWjCBiTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCERl
+bGF3YXJlMRMwEQYDVQQHEwpXaWxtaW5ndG9uMSMwIQYDVQQKExpQeXRob24gU29m
+dHdhcmUgRm91bmRhdGlvbjEMMAoGA1UECxMDU1NMMR8wHQYDVQQDExZzb21lbWFj
+aGluZS5weXRob24ub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ddrh
+m+LutBvjYcQlnH21PPIseJ1JVG2HMmN2CmZk2YukO+9LopdJhTvbGfEj0DQs1IE8
+M+kTUyOmuKfVrFMKwtVeCJphrAnhoz7TYOuLBSqt7lVHfhi/VwovESJlaBOp+WMn
+fhcduPEYHYx/6cnVapIkZnLt30zu2um+DzA9jQIDAQABoxUwEzARBglghkgBhvhC
+AQEEBAMCBkAwDQYJKoZIhvcNAQEFBQADgYEAF4Q5BVqmCOLv1n8je/Jw9K669VXb
+08hyGzQhkemEBYQd6fzQ9A/1ZzHkJKb1P6yreOLSEh4KcxYPyrLRC1ll8nr5OlCx
+CMhKkTnR6qBsdNV0XtdU2+N25hqW+Ma4ZeqsN/iiJVCGNOZGnvQuvCAGWF8+J/f/
+iHkC6gGdBJhogs4=
+-END CERTIFICATE-
Index: Lib/test/test_ssl.py
===
--- Lib/test/test_ssl.py(revision 57559)
+++ Lib/test/test_ssl.py(working copy)
@@ -22,7 +22,6 @@
skip_expected = True
CERTFILE = None
-GMAIL_POP_CERTFILE = None
def handle_error(prefix):
@@ -298,12 +297,15 @@
nsCertType = server
"""
-def create_cert_files():
+def create_cert_files(hostname=None):
+"""This is the routine that was run to create the certificate
+and private key contained in keycert.pem."""
+
import tempfile, socket, os
d = tempfile.mkdtemp()
# now create a configuration file for the CA signing cert
-fqdn = socket.getfqdn()
+fqdn = hostname or socket.getfqdn()
crtfile = os.path.join(d, "cert.pem")
conffile = os.path.join(d, "ca.conf")
fp = open(conffile, "w")
@@ -316,7 +318,7 @@
})
fp.close()
error = os.system(
-"openssl req -batch -new -x509 -days 10 -nodes -config %s "
+"openssl req -batch -new -x509 -days 2000 -nodes -config %s "
"-keyout \"%s\" -out \"%s\" > /dev/null < /dev/null 2>&1" %
(conffile, crtfile, crtfile))
# now we have a self-signed server cert in crtfile
@@ -324,7 +326,8 @@
if (os.WEXITSTATUS(error) or
not os.path.exists(crtfile) or os.path.getsize(crtfile) == 0):
if test_support.verbose:
-sys.stdout.write("Unable to create certificate for test %d\n" %
error)
+sys.stdout.write("Unable to create certificate for test, "
+ + "error status %d\n" % (error >> 8))
crtfile = None
elif test_support.verbose:
sys.stdout.write(open(crtfile, 'r').read() + '\n')
@@ -336,7 +339,8 @@
raise test_support.TestSkipped("socket module has no ssl support")
global CERTFILE
-tdir, CERTFILE = create_cert_files()
+CERTFILE = os.path.join(os.path.dirname(__file__) or os.curdir,
+"keycert.pem")
if not CERTFILE:
sys.__stdout__.write("Skipping test_ssl ConnectedTests; "
"couldn't create a certificate.\n")
@@ -362,8 +366,6 @@
# wait for it to stop
server.join()
-if tdir and os.path.isdir(tdir):
-shutil.rmtree(tdir)
test_support.threading_cleanup(*thread_info)
if __name__ == "__main__":
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archiv
Re: [Python-Dev] Other SSL issues in the tracker have been marked
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.
>
> Here's a patch that does that.
>
> Bill
>
> Index: Lib/test/keycert.pem
> ===
> --- Lib/test/keycert.pem(revision 0)
> +++ Lib/test/keycert.pem(revision 0)
> @@ -0,0 +1,32 @@
> +-BEGIN RSA PRIVATE KEY-
> +MIICXwIBAAKBgQC8ddrhm+LutBvjYcQlnH21PPIseJ1JVG2HMmN2CmZk2YukO+9L
> +opdJhTvbGfEj0DQs1IE8M+kTUyOmuKfVrFMKwtVeCJphrAnhoz7TYOuLBSqt7lVH
> +fhi/VwovESJlaBOp+WMnfhcduPEYHYx/6cnVapIkZnLt30zu2um+DzA9jQIDAQAB
> +AoGBAK0FZpaKj6WnJZN0RqhhK+ggtBWwBnc0U/ozgKz2j1s3fsShYeiGtW6CK5nU
> +D1dZ5wzhbGThI7LiOXDvRucc9n7vUgi0alqPQ/PFodPxAN/eEYkmXQ7W2k7zwsDA
> +IUK0KUhktQbLu8qF/m8qM86ba9y9/9YkXuQbZ3COl5ahTZrhAkEA301P08RKv3KM
> +oXnGU2UHTuJ1MAD2hOrPxjD4/wxA/39EWG9bZczbJyggB4RHu0I3NOSFjAm3HQm0
> +ANOu5QK9owJBANgOeLfNNcF4pp+UikRFqxk5hULqRAWzVxVrWe85FlPm0VVmHbb/
> +loif7mqjU8o1jTd/LM7RD9f2usZyE2psaw8CQQCNLhkpX3KO5kKJmS9N7JMZSc4j
> +oog58yeYO8BBqKKzpug0LXuQultYv2K4veaIO04iL9VLe5z9S/Q1jaCHBBuXAkEA
> +z8gjGoi1AOp6PBBLZNsncCvcV/0aC+1se4HxTNo2+duKSDnbq+ljqOM+E7odU+Nq
> +ewvIWOG//e8fssd0mq3HywJBAJ8l/c8GVmrpFTx8r/nZ2Pyyjt3dH1widooDXYSV
> +q6Gbf41Llo5sYAtmxdndTLASuHKecacTgZVhy0FryZpLKrU=
> +-END RSA PRIVATE KEY-
> +-BEGIN CERTIFICATE-
> +MIICpzCCAhCgAwIBAgIJAP+qStv1cIGNMA0GCSqGSIb3DQEBBQUAMIGJMQswCQYD
> +VQQGEwJVUzERMA8GA1UECBMIRGVsYXdhcmUxEzARBgNVBAcTCldpbG1pbmd0b24x
> +IzAhBgNVBAoTGlB5dGhvbiBTb2Z0d2FyZSBGb3VuZGF0aW9uMQwwCgYDVQQLEwNT
> +U0wxHzAdBgNVBAMTFnNvbWVtYWNoaW5lLnB5dGhvbi5vcmcwHhcNMDcwODI3MTY1
> +NDUwWhcNMTMwMjE2MTY1NDUwWjCBiTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCERl
> +bGF3YXJlMRMwEQYDVQQHEwpXaWxtaW5ndG9uMSMwIQYDVQQKExpQeXRob24gU29m
> +dHdhcmUgRm91bmRhdGlvbjEMMAoGA1UECxMDU1NMMR8wHQYDVQQDExZzb21lbWFj
> +aGluZS5weXRob24ub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ddrh
> +m+LutBvjYcQlnH21PPIseJ1JVG2HMmN2CmZk2YukO+9LopdJhTvbGfEj0DQs1IE8
> +M+kTUyOmuKfVrFMKwtVeCJphrAnhoz7TYOuLBSqt7lVHfhi/VwovESJlaBOp+WMn
> +fhcduPEYHYx/6cnVapIkZnLt30zu2um+DzA9jQIDAQABoxUwEzARBglghkgBhvhC
> +AQEEBAMCBkAwDQYJKoZIhvcNAQEFBQADgYEAF4Q5BVqmCOLv1n8je/Jw9K669VXb
> +08hyGzQhkemEBYQd6fzQ9A/1ZzHkJKb1P6yreOLSEh4KcxYPyrLRC1ll8nr5OlCx
> +CMhKkTnR6qBsdNV0XtdU2+N25hqW+Ma4ZeqsN/iiJVCGNOZGnvQuvCAGWF8+J/f/
> +iHkC6gGdBJhogs4=
> +-END CERTIFICATE-
> Index: Lib/test/test_ssl.py
> ===
> --- Lib/test/test_ssl.py(revision 57559)
> +++ Lib/test/test_ssl.py(working copy)
> @@ -22,7 +22,6 @@
> skip_expected = True
>
> CERTFILE = None
> -GMAIL_POP_CERTFILE = None
>
>
> def handle_error(prefix):
> @@ -298,12 +297,15 @@
> nsCertType = server
> """
>
> -def create_cert_files():
> +def create_cert_files(hostname=None):
>
> +"""This is the routine that was run to create the certificate
> +and private key contained in keycert.pem."""
> +
> import tempfile, socket, os
> d = tempfile.mkdtemp()
> # now create a configuration file for the CA signing cert
> -fqdn = socket.getfqdn()
> +fqdn = hostname or socket.getfqdn()
> crtfile = os.path.join(d, "cert.pem")
> conffile = os.path.join(d, "ca.conf")
> fp = open(conffile, "w")
> @@ -316,7 +318,7 @@
>})
> fp.close()
> error = os.system(
> -"openssl req -batch -new -x509 -days 10 -nodes -config %s "
> +"openssl req -batch -new -x509 -days 2000 -nodes -config %s "
> "-keyout \"%s\" -out \"%s\" > /dev/null < /dev/null 2>&1" %
> (conffile, crtfile, crtfile))
> # now we have a self-signed server cert in crtfile
> @@ -324,7 +326,8 @@
> if (os.WEXITSTATUS(error) or
> not os.path.exists(crtfile) or os.path.getsize(crtfile) == 0):
> if test_support.verbose:
> -sys.stdout.write("Unable to create certificate for test %d\n" %
> error)
> +sys.stdout.write("Unable to create certificate for test, "
> + + "error status %d\n" % (error >> 8))
> crtfile = None
> elif test_support.verbose:
> sys.stdout.write(open(crtfile, 'r').read() + '\n')
> @@ -336,7 +339,8 @@
> raise test_support.TestSkipped("socket module has no ssl support")
>
> global CERTFILE
> -tdir, CERTFILE = create_cert_files()
> +CERTFILE = os.path.join(os.path.dirname(__file__) or os.curdir,
> +"keycert.pem")
> if not CERTFILE:
> sys.__stdout__.write("Skipping test_ssl ConnectedTests; "
> "couldn't create a certificate.\n")
> @@ -362,8 +366,6 @@
> # wait for it to stop
> server.join()
>
> -if tdir and os.path.isdir(tdir):
> -shutil.rmtree(tdir)
> test_support.threa
Re: [Python-Dev] tarfile and directory traversal vulnerability
-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 files?
GNU tar is not supposed to place files outside its working directory,
unless explicitly specified otherwise. So this is considered a security
vulnerability.
AFAIK there is no specified behavior and other tars might act
differently. But i think GNU tar behaves correctly in this regard.
Furthermore, extract() and extractall() documentation says "Extract
(...) from the archive to the *current working directory* or directory
[path]."
So current behavior is actually inconsistent with the documentation.
>> if tarinfo.name.startswith('../'):
>> self.extract(tarinfo, path)
>> else:
>> warnings.warn("non-local file skipped: %s" % tarinfo.name,
>> RuntimeWarning, stacklevel=1)
>
> Ok. You seem to be claiming that the tarfile is incorrect in some
> sense. Can you please point to some spec that says this is an incorrect
> tarfile?
No, the tar file itself is correct, according to POSIX. You can put
anything into a tar. Point is, you should be able to untar any file
'safely'.
> In any case, if you fix what you consider broken, you should do
> it exactly the same way as GNU tar does it (assuming you consider
> GNU tar fixed).
I can do that.
I would propose an optional parameter for extract() and extractall(),
absolutePaths, defaulting to False. When encountering a non-local file,
it would strip the leading slash or the path up to the last '../'
sequence (that is what GNU tar does) and extract the file locally.
Setting absolutePaths to True would restore current behavior (no checks).
regards,
jan matejek
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFG0wtkjBrWA+AvBr8RAmmnAKCtpYYoFZYaNwba2WW11NtRuCyqhwCePkFw
9M2pKHtu0O62fAYfb8NTm3A=
=yfVK
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tarfile and directory traversal vulnerability
-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 because foo > already exists. The best way would be to completely ignore > members and link targets that are absolute or outside the > archive's scope. GNU tar doesn't descend into symlinked directories when extracting, such archive fails anyway: # tar xvf foo.tar foo foo/passwd tar: foo/passwd: Cannot open: Not a directory tar: Error exit delayed from previous errors I think that is the simplest solution, but i'm not sure how to best implement that in extractall(). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG0wyUjBrWA+AvBr8RAjkJAKCJS+hkV1HYL9egOsyeTE5vj44r5ACeNmt7 HquYw+ON+5qVNoC778OtQRE= =9Kx/ -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Other SSL issues in the tracker have been marked
> 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 the error name directly from the err code.
> However, PySSL_SetError only works after the construction of an ssl
> object, which means it can't be used there... I'll take a longer look
> at it and see if there's a reasonable fix.
Here's a patch which addresses this. It also fixes the indentation in
PySSL_SetError, bringing it into line with PEP 7, fixes a compile warning
about one of the OpenSSL macros, and makes the namespace a bit more
consistent. I've tested it on FC 7 and OS X 10.4.
% ./python ./Lib/test/regrtest.py -R :1: -u all test_ssl
test_ssl
beginning 6 repetitions
123456
..
1 test OK.
[29244 refs]
%
Bill
Index: Modules/_ssl.c
===
--- Modules/_ssl.c (revision 57564)
+++ Modules/_ssl.c (working copy)
@@ -122,71 +122,74 @@
char buf[2048];
char *errstr;
int err;
- enum py_ssl_error p;
+ enum py_ssl_error p = PY_SSL_ERROR_NONE;
assert(ret <= 0);
- err = SSL_get_error(obj->ssl, ret);
+ if ((obj != NULL) && (obj->ssl != NULL)) {
+ err = SSL_get_error(obj->ssl, ret);
- switch (err) {
- case SSL_ERROR_ZERO_RETURN:
- errstr = "TLS/SSL connection has been closed";
- p = PY_SSL_ERROR_ZERO_RETURN;
- break;
- case SSL_ERROR_WANT_READ:
- errstr = "The operation did not complete (read)";
- p = PY_SSL_ERROR_WANT_READ;
- break;
- case SSL_ERROR_WANT_WRITE:
- p = PY_SSL_ERROR_WANT_WRITE;
- errstr = "The operation did not complete (write)";
- break;
- case SSL_ERROR_WANT_X509_LOOKUP:
- p = PY_SSL_ERROR_WANT_X509_LOOKUP;
- errstr = "The operation did not complete (X509 lookup)";
- break;
- case SSL_ERROR_WANT_CONNECT:
- p = PY_SSL_ERROR_WANT_CONNECT;
- errstr = "The operation did not complete (connect)";
- break;
- case SSL_ERROR_SYSCALL:
- {
- unsigned long e = ERR_get_error();
- if (e == 0) {
- if (ret == 0 || !obj->Socket) {
- p = PY_SSL_ERROR_EOF;
- errstr = "EOF occurred in violation of
protocol";
- } else if (ret == -1) {
- /* the underlying BIO reported an I/O error */
- return obj->Socket->errorhandler();
- } else { /* possible? */
+ switch (err) {
+ case SSL_ERROR_ZERO_RETURN:
+ errstr = "TLS/SSL connection has been closed";
+ p = PY_SSL_ERROR_ZERO_RETURN;
+ break;
+ case SSL_ERROR_WANT_READ:
+ errstr = "The operation did not complete (read)";
+ p = PY_SSL_ERROR_WANT_READ;
+ break;
+ case SSL_ERROR_WANT_WRITE:
+ p = PY_SSL_ERROR_WANT_WRITE;
+ errstr = "The operation did not complete (write)";
+ break;
+ case SSL_ERROR_WANT_X509_LOOKUP:
+ p = PY_SSL_ERROR_WANT_X509_LOOKUP;
+ errstr = "The operation did not complete (X509 lookup)";
+ break;
+ case SSL_ERROR_WANT_CONNECT:
+ p = PY_SSL_ERROR_WANT_CONNECT;
+ errstr = "The operation did not complete (connect)";
+ break;
+ case SSL_ERROR_SYSCALL:
+ {
+ unsigned long e = ERR_get_error();
+ if (e == 0) {
+ if (ret == 0 || !obj->Socket) {
+ p = PY_SSL_ERROR_EOF;
+ errstr = "EOF occurred in violation of
protocol";
+ } else if (ret == -1) {
+ /* the underlying BIO reported an I/O
error */
+ return obj->Socket->errorhandler();
+ } else { /* possible? */
+ p = PY_SSL_ERROR_SYSCALL;
+ errstr = "Some I/O error occurred";
+ }
+ } else {
p = PY_SSL_ERROR_SYSCALL;
- errstr = "Some I/O error occurred";
+ /* XXX Protected by gl
Re: [Python-Dev] Other SSL issues in the tracker have been marked
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 places which set
> > the string directly probably shouldn't; instead, they should call
> > PySSL_SetError to cons up the error name directly from the err code.
> > However, PySSL_SetError only works after the construction of an ssl
> > object, which means it can't be used there... I'll take a longer look
> > at it and see if there's a reasonable fix.
>
> Here's a patch which addresses this. It also fixes the indentation in
> PySSL_SetError, bringing it into line with PEP 7, fixes a compile warning
> about one of the OpenSSL macros, and makes the namespace a bit more
> consistent. I've tested it on FC 7 and OS X 10.4.
>
> % ./python ./Lib/test/regrtest.py -R :1: -u all test_ssl
> test_ssl
> beginning 6 repetitions
> 123456
> ..
> 1 test OK.
> [29244 refs]
> %
>
> Bill
>
>
> Index: Modules/_ssl.c
> ===
> --- Modules/_ssl.c (revision 57564)
> +++ Modules/_ssl.c (working copy)
> @@ -122,71 +122,74 @@
> char buf[2048];
> char *errstr;
> int err;
> - enum py_ssl_error p;
> + enum py_ssl_error p = PY_SSL_ERROR_NONE;
>
> assert(ret <= 0);
>
> - err = SSL_get_error(obj->ssl, ret);
> + if ((obj != NULL) && (obj->ssl != NULL)) {
> + err = SSL_get_error(obj->ssl, ret);
>
> - switch (err) {
> - case SSL_ERROR_ZERO_RETURN:
> - errstr = "TLS/SSL connection has been closed";
> - p = PY_SSL_ERROR_ZERO_RETURN;
> - break;
> - case SSL_ERROR_WANT_READ:
> - errstr = "The operation did not complete (read)";
> - p = PY_SSL_ERROR_WANT_READ;
> - break;
> - case SSL_ERROR_WANT_WRITE:
> - p = PY_SSL_ERROR_WANT_WRITE;
> - errstr = "The operation did not complete (write)";
> - break;
> - case SSL_ERROR_WANT_X509_LOOKUP:
> - p = PY_SSL_ERROR_WANT_X509_LOOKUP;
> - errstr = "The operation did not complete (X509 lookup)";
> - break;
> - case SSL_ERROR_WANT_CONNECT:
> - p = PY_SSL_ERROR_WANT_CONNECT;
> - errstr = "The operation did not complete (connect)";
> - break;
> - case SSL_ERROR_SYSCALL:
> - {
> - unsigned long e = ERR_get_error();
> - if (e == 0) {
> - if (ret == 0 || !obj->Socket) {
> - p = PY_SSL_ERROR_EOF;
> - errstr = "EOF occurred in violation of
> protocol";
> - } else if (ret == -1) {
> - /* the underlying BIO reported an I/O error */
> - return obj->Socket->errorhandler();
> - } else { /* possible? */
> + switch (err) {
> + case SSL_ERROR_ZERO_RETURN:
> + errstr = "TLS/SSL connection has been closed";
> + p = PY_SSL_ERROR_ZERO_RETURN;
> + break;
> + case SSL_ERROR_WANT_READ:
> + errstr = "The operation did not complete (read)";
> + p = PY_SSL_ERROR_WANT_READ;
> + break;
> + case SSL_ERROR_WANT_WRITE:
> + p = PY_SSL_ERROR_WANT_WRITE;
> + errstr = "The operation did not complete (write)";
> + break;
> + case SSL_ERROR_WANT_X509_LOOKUP:
> + p = PY_SSL_ERROR_WANT_X509_LOOKUP;
> + errstr = "The operation did not complete (X509
> lookup)";
> + break;
> + case SSL_ERROR_WANT_CONNECT:
> + p = PY_SSL_ERROR_WANT_CONNECT;
> + errstr = "The operation did not complete (connect)";
> + break;
> + case SSL_ERROR_SYSCALL:
> + {
> + unsigned long e = ERR_get_error();
> + if (e == 0) {
> + if (ret == 0 || !obj->Socket) {
> + p = PY_SSL_ERROR_EOF;
> + errstr = "EOF occurred in violation
> of protocol";
> + } else if (ret == -1) {
> + /* the underlying BIO reported an I/O
> error */
> + return obj->Socket->errorhandler();
> + } else { /* possible? */
> + p = PY_SSL_ERROR_
Re: [Python-Dev] Other SSL issues in the tracker have been marked
> 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 expand the test_ssl suite to cover more edge cases, particularly failure modes. Maybe I'll do that first. Actually... if you're in a check-in mood, there is the documentation patch (issue 1024), which explains about certificates... Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tarfile and directory traversal vulnerability
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 afterwards it will fail because foo > > already exists. The best way would be to completely ignore > > members and link targets that are absolute or outside the > > archive's scope. > > GNU tar doesn't descend into symlinked directories when extracting, such > archive fails anyway: > > # tar xvf foo.tar > foo > foo/passwd > tar: foo/passwd: Cannot open: Not a directory > tar: Error exit delayed from previous errors > > I think that is the simplest solution, but i'm not sure how to best > implement that in extractall(). GNU tar creates a placeholder file for every hard or symbolic link during the extract process and in a second step replaces them with links. I don't think that this is a good choice for a library. The problem is that it leads to delayed and (from the user's POV) unrelated errors. I prefer the solution that archive members with pathnames that either start with a "/" or a "../" raise an exception by default and can be extracted only by direct request. I am currently working on a patch. Should we move this discussion over to the bugtracker? -- Lars Gustäbel [EMAIL PROTECTED] Linux is like a wigwam - no Gates, no Windows, Apache inside. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] next steps in SSL work
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, and xmlrpclib. 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, etc. 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. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
