Re: [Python-Dev] what platforms require RAND_add() before using SSL?
> There are some functions in _ssl.c for gathering randomness from a > daemon, and adding that randomness to the pseudo-random number > generator in SSL, before using SSL. There's a note there saying that > "on some platform" this is necessary. Anyone know which platforms? In general, anything that does not have /dev/[u]random; older Solaris releases and HP-UX in particular. Regards, Martin ___ 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] can't run test_tcl remotely logged in on an OS X machine
> "test_tcl" fails on me (OS X 10.4.10 on an Intel Mac, remotely logged > in via SSH and X Windows): > > % test_tcl > 2007-09-08 17:00:22.629 python.exe[4163] CFLog (0): CFMessagePort: > bootstrap_register(): failed 1100 (0x44c), port = 0x3a03, name = > 'Processes-0.58327041' > See /usr/include/servers/bootstrap_defs.h for the error codes. > 2007-09-08 17:00:22.630 python.exe[4163] CFLog (99): > CFMessagePortCreateLocal(): failed to name Mach port (Processes-0.58327041) > CFMessagePortCreateLocal failed (name = Processes-0.58327041 error = 0) > Abort > % > > This is on the trunk. That's no surprise, I would say: it seems you link against TkAqua (not X11 Tk); for that to work, you need a reference to WindowServer, which won't be available when logged in through SSL. Regards, Martin ___ 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] Porting python
Hi! I've tried to port Python (2.3.6 and 2.5.1) to my own OS. The compilation of the python library is done after a few hours of work. When i try to run the compiled executable i got an error shown on the following screenshot: http://giszo.lame.hu/jshot/screens/screen31.png After a little while of debugging i know that it fails bootstrapping the exceptions because the initializer function failes to get the "__builtin__" module. Adding debug printfs to the bltinmodule.c init code it looks like the builtin module is initialized properly. I'd like to ask some help where i should start checking the code to fix the error. Thanks! Message sent using UebiMiau 2.7.9 ___ 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] Porting python
> I'd like to ask some help where i should start checking the code to fix the > error. Python searches possible candidate locations of the standard library for a landmark, see getpath.c; currently, the landmark is os.py. If it doesn't find the landmark, it complains. Regards, Martin ___ 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] what platforms require RAND_add() before using SSL?
> > There are some functions in _ssl.c for gathering randomness from a > > daemon, and adding that randomness to the pseudo-random number > > generator in SSL, before using SSL. There's a note there saying that > > "on some platform" this is necessary. Anyone know which platforms? > > In general, anything that does not have /dev/[u]random; > older Solaris releases and HP-UX in particular. Thanks, I"ll add that to the documentation. Any ideas what the values of the "entropy" parameter to RAND_add() are like, or how they are derived? I did a rapid skim of RFC 1750, but didn't see it there. 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] can't run test_tcl remotely logged in on an OS X machine
> > "test_tcl" fails on me (OS X 10.4.10 on an Intel Mac, remotely logged > > in via SSH and X Windows): > > That's no surprise, I would say: it seems you link against TkAqua > (not X11 Tk); for that to work, you need a reference to WindowServer, > which won't be available when logged in through SSL. Actually, I think it literally *is* a surprise; if it were truly "no surprise", the testing harness would have caught it and moved on to the other tests. But if you mean, "no big deal", I agree. 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
[Python-Dev] Word size inconsistencies in C extension modules
Hi folks. While working on an in-house application that uses the curses module, we noticed that it didn't work as expected on an AIX system (powerpc 64-bit big-endian LP64), using python 2.3.5. On a hunch, I took a look through the _cursesmodule.c code and noticed the use of PyArg_ParseTuple()'s "l" decoding mode to retrieve a "long" from python into a C type (attr_t) that on AIX is an int. On 64-bit LP64 platforms, sizeof(long) > sizeof(int), so this doesn't quite work, especially on big-endian systems. Further research into curses shows that different platforms use a different underlying C type for the attr_t type (int, unsigned int, long, unsigned long), so changing the PyArg_ParseTuple() to using the "i" decoding mode probably wasn't portable. I documented this problem and provided a patch that fixes it against the head of the svn trunk in http://bugs.python.org/issue1114 (because the problem appears to still exist in the latest code.) My workaround was to use a separate explicit C "long" to decode the value from python into, and then just assign that to the final value and hope that the type promotion does the right thing on the native platfomr. My questions are: (a)What's the "preferred" style in python extension modules of parsing a number from python into a C type, where the C type size may change on different platforms? Is my method of guessing what the largest common size will be (long, unsigned long, ...), reading into that, and assigning to the final type, acceptable? (b)Is there a desire to see the standard python C extension modules cleaned up to use the answer to (a), especially where said modules may be susceptable to the word size problems I mentioned? (64bit big-endian platforms such as powerpc and sparc64 are good for detecting word-size lossage) cheers, Luke. pgpuVGvyDmpHK.pgp Description: 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
[Python-Dev] tests expanded for SSL module -- other suggestions?
I'm looking for suggestions for other SSL module tests.
Here's the result of running my (not yet checked-in) test_ssl.py
module in verbose mode. I'm pretty happy with the codebase right now,
and barring other tests, I'm ready to check it in and start on the 3.x
patch (or perhaps the 2.3 package).
In the client/server tests, a new server thread is created for
each test.
In the STARTTLS test, several messages are exchanged in the clear,
then the client sends a STARTTLS message and after the server replies
"OK", initiates the TLS handshake.
It would be nice to have an external HTTPS server on python.org
that could be used for an HTTPS connection test. Is there one?
Bill
% ./python.exe ./Lib/test/regrtest.py -u all -v test_ssl
test_ssl
testCrucialConstants (test.test_ssl.BasicTests) ... ok
testParseCert (test.test_ssl.BasicTests) ...
{'notAfter': 'Feb 16 16:54:50 2013 GMT',
'subject': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'SSL'),),
(('commonName', u'somemachine.python.org'),))}
ok
testRAND (test.test_ssl.BasicTests) ...
RAND_status is 1 (sufficient randomness)
ok
testSSLconnect (test.test_ssl.BasicTests) ... ok
testEcho (test.test_ssl.ConnectedTests) ...
server: new connection from ('127.0.0.1', 51840)
server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256)
client: sending 'FOO\n'...
server: read 'FOO\n', sending back 'foo\n'...
client: read 'foo\n'
client: closing connection.
server: client closed connection
ok
testMalformedCert (test.test_ssl.ConnectedTests) ... ok
testMalformedKey (test.test_ssl.ConnectedTests) ... ok
testNULLcert (test.test_ssl.ConnectedTests) ... ok
testReadCert (test.test_ssl.ConnectedTests) ...
{'notAfter': 'Feb 16 16:54:50 2013 GMT',
'subject': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'SSL'),),
(('commonName', u'somemachine.python.org'),))}
Connection cipher is ('AES256-SHA', 'TLSv1/SSLv3', 256).
ok
testRudeShutdown (test.test_ssl.ConnectedTests) ... ok
testSSL2 (test.test_ssl.ConnectedTests) ...
SSLv2->SSLv2 CERT_NONE
SSLv2->SSLv2 CERT_OPTIONAL
SSLv2->SSLv2 CERT_REQUIRED
SSLv23->SSLv2 CERT_NONE
{SSLv3->SSLv2} CERT_NONE
{TLSv1->SSLv2} CERT_NONE
ok
testSSL23 (test.test_ssl.ConnectedTests) ...
{SSLv2->SSLv23} CERT_NONE
SSLv3->SSLv23 CERT_NONE
SSLv23->SSLv23 CERT_NONE
TLSv1->SSLv23 CERT_NONE
{SSLv2->SSLv23} CERT_OPTIONAL
SSLv3->SSLv23 CERT_OPTIONAL
SSLv23->SSLv23 CERT_OPTIONAL
TLSv1->SSLv23 CERT_OPTIONAL
{SSLv2->SSLv23} CERT_REQUIRED
SSLv3->SSLv23 CERT_REQUIRED
SSLv23->SSLv23 CERT_REQUIRED
TLSv1->SSLv23 CERT_REQUIRED
ok
testSSL3 (test.test_ssl.ConnectedTests) ...
SSLv3->SSLv3 CERT_NONE
SSLv3->SSLv3 CERT_OPTIONAL
SSLv3->SSLv3 CERT_REQUIRED
{SSLv2->SSLv3} CERT_NONE
{SSLv23->SSLv3} CERT_NONE
{TLSv1->SSLv3} CERT_NONE
ok
testSTARTTLS (test.test_ssl.ConnectedTests) ...
client: sending 'msg 1'...
server: new connection from ('127.0.0.1', 51870)
server: read 'msg 1', sending back 'msg 1'...
client: read 'msg 1' from server
client: sending 'MSG 2'...
server: read 'MSG 2', sending back 'msg 2'...
client: read 'msg 2' from server
client: sending 'STARTTLS'...
server: read STARTTLS from client, sending OK...
client: read 'OK\n' from server, starting TLS...
server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256)
client: sending 'MSG 3'...
server: read 'MSG 3', sending back 'msg 3'...
client: read 'msg 3' from server
client: sending 'msg 4'...
server: read 'msg 4', sending back 'msg 4'...
client: read 'msg 4' from server
client: closing connection.
server: client closed connection
ok
testTLS1 (test.test_ssl.ConnectedTests) ...
TLSv1->TLSv1 CERT_NONE
TLSv1->TLSv1 CERT_OPTIONAL
TLSv1->TLSv1 CERT_REQUIRED
{SSLv2->TLSv1} CERT_NONE
{SSLv3->TLSv1} CERT_NONE
{SSLv23->TLSv1} CERT_NONE
ok
--
Ran 15 tests in 6.866s
OK
1 test OK.
CAUTION: stdout isn't compared in verbose mode:
a test that passes in verbose mode may fail without it.
[23679 refs]
___
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] summaries not arriving
The weekly summaries from the new bug tracker are disappearing somewhere between the tracker and python-dev. My attempt to post one by hand was rejected by python-dev-owner (Barry Warsaw?) without explanation. Perhaps he has bounced the others; emails to python-dev-owner result in an automated message suggesting that my mail may never be read so I don't know how to ask him. As a small boy I once knew wrote, I must not use bad words. (:-> Paul Dubois ___ 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] Word size inconsistencies in C extension modules
> (a)What's the "preferred" style in python extension modules > of parsing a number from python into a C type, where the > C type size may change on different platforms? > Is my method of guessing what the largest common size > will be (long, unsigned long, ...), reading into that, > and assigning to the final type, acceptable? Yes, that's the best thing we have come up with. You then have the issue on potential truncation on assignment: if the value passed fits into a long (say) but not an attr_t, it would be good if an error was raised. In the past, we have typically coded that ValueError explicitly after the ParseTuple call. In principle, it is possible to deal with these in ParseTuple. To do so: a) in configure.in, make a configure-time check to compute the size of the type, and possibly its signedness. b) in _cursesmodule.c, make a conditional define of ATTR_T_FMT, which would be either "i" or "l" (or #error if it's neither the size of int nor the size of long). Then rely on string concatenation in using that define. > (b)Is there a desire to see the standard python C extension > modules cleaned up to use the answer to (a), especially > where said modules may be susceptable to the word > size problems I mentioned? Most certainly. There shouldn't be that many places left, though; most have been fixed over the years already. I have a GCC patch which checks for correctness of ParseTuple calls (in terms of data size) if you are interested. Regards, Martin ___ 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] Design and direction of the SSL module (was Re: frozenset C API?)
Sorry for the late response. As always, I have a lot of other stuff going on at the moment, but I'm very interested in this subject. On 6 Sep, 06:15 pm, [EMAIL PROTECTED] wrote: >>PyOpenSSL, in particular, is both a popular de-facto >>standard *and* almost completely unmaintained; python's standard >>library >>could absorb/improve it with little fuss. > >Good idea, go for it! A full wrapper for OpenSSL is beyond the scope >of my ambition; I'm simply trying to add a simple fix to what's >already in the standard library. I guess I'd like to know two things. One, what *is* the scope of your amibition? I feel silly for asking, because I am pretty sure that somewhere in the beginning of this thread I missed either a proposal, a PEP reference, or a ticket number, but I've poked around a little and I can't seem to find it. Can you provide a reference, or describe what it is you're trying to do? Two, what's the scope of "the" plans for the SSL module in general for Python? I think I misinterpreted several things that you said as "the plan" rather than your own personal requirements: but if in reality, I can "go for it", I'd really like to help make the stdlib SSL module to be a really good, full-featured OpenSSL implementation for Python so we can have it elsewhere. (If I recall correctly you mentioned you'd like to use it with earlier Python versions as well...?) Many of the things that you recommend using another SSL library for, like pulling out arbitrary extensions, are incredibly unweildy or flat- out broken in these libraries. It's not that I mind going to a different source for this functionality; it's that in many cases, there *isn't* another source :). I think I might have said this already, but subjectAltName, for example, isn't exposed in any way by PyOpenSSL. I didn't particularly want to start my own brand-new SSL wrapper project, and contributing to the actively-maintained stdlib implementation is a lot more appealing than forking the moribund PyOpenSSL. However, even with lots of help on the maintenance, converting the current SSL module into a complete SSL library is a lot of work. Here are the questions that I'd like answers to before starting to think seriously about it: * Is this idea even congruent with the overall goals of other developers interested in SSL for Python? If not, I'm obviously barking up the wrong tree. * Would it be possible to distribute as a separate library? (I think I remember Bill saying something about that already...) * When would such work have to be completed by to fit into the 2.6 release? (I just want a rough estimate, here.) * Should someone - and I guess by someone I mean me - write up a PEP describing this? My own design for an SSL wrapper - although this simply a Python layer around PyOpenSSL - is here: http://twistedmatrix.com/trac/browser/trunk/twisted/internet/_sslverify.py This isn't really complete - in particular, the documentation is lacking, and it can't implement the stuff PyOpenSSL is missing - but I definitely like the idea of having objects for DNs, certificates, CRs, keys, key pairs, and the ubiquitous certificate-plus-matching-private- key-in-one-file that you need to run an HTTPS server :). If I am going to write a PEP, it will look a lot like that file. _sslverify was originally designed for a system that does lots of automatic signing, so I am particularly interested in it being easy to implement a method like PrivateCertificate.signCertificateRequest - it's always such a pain to get all the calls for signing a CR in any given library *just so*. >>This begs the question: M2Crypto and PyOpenSSL already do what you're >>proposing to do, as far as I can tell, and are, as you say, "more >>powerful". To clarify my point here, when I say that they "already do" what you're doing, what I mean is, they already wrap SSL, and you are trying to wrap SSL :). >I'm trying to give the application the ability to do some level of >authorization without requiring either of those packages. I'd say "why wouldn't you want to require either of those packages?" but actually, I know why you wouldn't want to, and it's that they're bad. So, given that we don't want to require them, wouldn't it be nice if we didn't need to require them at all? :). >Like being >able to tell who's on the other side of the connection :-). Right >now, I think the right fields to expose are I don't quite understand what you mean by "right" fields. Right fields for what use case? This definitely isn't "right" for what I want to use SSL for. > "subject" (I see little point to exposing "issuer"), This is a good example of what I mean. For HTTPS, the relationship between the subject and the issuer is moot, but in my own projects, the relationship is very interesting. Specifically, properties of the issuer define what properties the subject may have, in the verification scheme for Vertex ( http://divm
[Python-Dev] BerkeleyDB 4.6.19 is buggy and causes test_bsddb3 to hang
BerkeleyDB 4.6.19 is a buggy release, the DB_HASH access method databases can lockup the process. This is why several of the bleeding edge distro buildbots are timing out while running test_bsddb3. I've created a simple C test case and made sleepycat^Woracle aware of the problem. I have a change in my sandbox to explicitly avoid linking with 4.6.19 but it seems like committing it would just pollute setup.py with vague notions of what versions of a specific library are bad. I'd prefer to just disallow use of libdb 4.6 completely in setup.py until oracle fixes this and we're sure no OS release ships with 4.6.19. thoughts? -gps http://groups.google.com/group/comp.databases.berkeley-db/browse_thread/thread/abf12452613ca7ec ___ 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
