Re: [Python-Dev] Word size inconsistencies in C extension modules
On Mon, Sep 10, 2007 at 07:37:02AM +0200, "Martin v. L?wis" wrote: | 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. Are there some good examples in the Python source where this technique has been used already? Or were you proposing a cleaner solution that could be experimented with? | I have a GCC patch which checks for correctness of ParseTuple | calls (in terms of data size) if you are interested. Sounds like a useful variation of the standard -Wformat stuff. This probably wouldn't have helped in the AIX situation I experienced (because the IBM compiler was used in that situation), but it could be useful on other BE LP64 platforms that are more gcc-friendly (e.g, NetBSD/sparc64). pgpIM35QGPfWH.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
Re: [Python-Dev] Word size inconsistencies in C extension modules
Luke Mewburn schrieb: > On Mon, Sep 10, 2007 at 07:37:02AM +0200, "Martin v. L?wis" wrote: > | 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. > > Are there some good examples in the Python source where > this technique has been used already? Not directly. A check for the size of a library type can be found for fpos_t, but there, no ParseTuple depends on it. An example for using variable formatters (though again not for ParseTuple) is PY_FORMAT_SIZE_T. > Or were you proposing a cleaner solution that could be > experimented with? More that, yes. > | I have a GCC patch which checks for correctness of ParseTuple > | calls (in terms of data size) if you are interested. > > Sounds like a useful variation of the standard -Wformat stuff. Indeed, it's an extension to it. Unfortunately, introducing new kinds of formats is only possible by editing GCC (and then, the existing framework is focussed on %-style patterns, so I had to bypass that framework as well - but there were hooks for doing so). 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] summaries not arriving
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 10, 2007, at 1:30 AM, Paul Dubois wrote: > 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. Nope, I didn't bounce them. I don't /think/ they'll bounce automatically. Can you forward a bounce message to me directly? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRuUnF3EjvBPtnXfVAQKDvwQAnNbVXwY1Fc00TLLFrOffFwU+jRJVxSyJ J0HV/+ssVuX85+LfM7kAsbwZSAWM0PkTVrhfldtbD5j6D0x0II/C5GX21fQ0V+pg fyf9HQ9i1LSUe7TvvCyXGSI7d8snNBqBpsyQ2EakQ3OGlcMjILPVVmyVSDFd2mLr Z2VbrlinB58= =HohF -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] summaries not arriving
On Monday 10 September 2007, Paul Dubois wrote: > As a small boy I once knew wrote, I must not use bad words. (:-> It's OK to use them about Barry, though, surely? *wave* Hi Barry. -- Anthony Baxter, ekit. [EMAIL PROTECTED] (03) 9674 7015 Level 3 The Teahouse, 28 Clarendon St, Sth Melbourne Australia 3205 ___ 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] summaries not arriving
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 10, 2007, at 1:43 AM, Anthony Baxter wrote: > On Monday 10 September 2007, Paul Dubois wrote: >> As a small boy I once knew wrote, I must not use bad words. (:-> > > It's OK to use them about Barry, though, surely? > > *wave* Hi Barry. It's okay from /you/ Anthony, because it's the only way I know you still care. baby-unicorn-hugs-ly y'rs, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRuUs7XEjvBPtnXfVAQJZSQP+JoApQY+tY4zkZDN2OlE+jFv8xdF0vqRW LCK+p8yIQjlrkMC58c2CChvOsWTcH6tZMFAd0jK8d9q8NxyyN3tM7mbh25Rnm9fo KC9uDt787fY8RpRC5YC+zEtM589Y6omL3S4XcqdkTS9UWg6S50e9EDkqrjKmE1gb 8/1LSynRnF8= =W6ef -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] BerkeleyDB 4.6.19 is buggy and causes test_bsddb3 to hang
> 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? That sounds like the right solution to me. We should review it when/if a patch is available. "No OS release ships" is a difficult-to-test-for condition, given things like Gentoo and Debian unstable that simultaneously ship in dozens of versions (i.e. with "releases" every two hours or more often). After a bug fix is available, and some time has passed, I'd rather reallow 4.6.x, and put something into README about this bug. Thanks for investigating it. 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] Design and direction of the SSL module (was Re: frozenset C API?)
> 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? Sorry about that. We kind of did this on the fly at the Python sprint. I was trying to fix two problems: One, that the current socket.ssl support didn't validate certificates, and two, that you couldn't do server-side SSL with it. I'm only interested in that aspect, and in the simplest possible solution to those problems. I don't want to provide user validation callbacks, or arbitrary certificate decoding, or general-purpose crypto, or support for building automatic CA systems, or wrapping most of that great grab-bag of useful stuff called OpenSSL. Just fix the core issues with socket.ssl. Along the way I've found a nasty little threading/malloc bug in the existing code, and fixed that. I've added real documentation for the existing functionality. I've gone around with you and Martin, mainly, on what information to expose from the validated certificate, to support authorization and accounting (the answer so far: "notAfter", "subject", and "subjectAltName", if it's there). > 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. Well, remember, it's just a socket-layer wrapper for TLS, it's not an "OpenSSL implementation", by which I suppose you mean a full wrapper for OpenSSL, much like PyOpenSSL is supposed to be. For that purpose, doesn't it make more sense to to extend/fix PyOpenSSL, rather than try to grow the deliberately limited-purpose socket.ssl support into another version of that? Can't it be revived, if it is in fact moribund? > * Would it be possible to distribute as a separate library? (I think > I remember Bill saying something about that already...) Just to be clear that what you seem to want to work on and what I'm working on seem to be two different things... I plan to build a back-port of the improved socket.ssl support as a standalone package for 2.3 (because I need to use it on OS X 10.4). > 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. It's that they are too big and complicated to easily see how to fix. But that seems to be a side-effect of trying to wrap all of OpenSSL, which is a big, evolving project. > Wouldn't it be nice to know *why* the cert didn't validate? To provide Yes, so I've put in a bit of work making sure the OpenSSL errors are properly relayed back to the Python application. > The entire idea of "extensions" is pretty direct about the fact that the > original implementor need not understand their profitable use :). Not really. Each extension is proposed, debated, and approved before it's added to the spec for extensions. My idea is that as support for various extensions appear in OpenSSL, we can evaluate them and see if they are worth supporting in Python. > Specifically, properties of the > issuer define what properties the subject may have, in the verification > scheme for Vertex ( http://divmod.org/trac/wiki/DivmodVertex ) I didn't see a write-up of your scheme at that URL; can you point me to a particular page in the Wiki which describes the use case? I should point out that we're (actually, Greg Smith) also wrapping another chunk of the OpenSSL library for hashing. And last week I suggested that we might wrap yet another chunk for doing cryptography. This chunk-by-chunk approach might be a good way to go. If a chunk that did general X509 certificate munging did appear, I'd be happy to change the SSL support to use it. 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] which SSL client protocols work with which server protocols?
> I've now built a framework in test_ssl to test all client protocols > (SSL2, SSL3, SSL23, TLS1) against all server protocols, and here's > what I've come up with. Servers are along the X axis, and clients are > on the Y axis. "Yes" means that that client protocol can talk to that > server protocol. > > SSL2SSL3SS23TLS1 > SSL2 yes no no no > SSL3 yes yes yes no > SSL23 no no yes no > TLS1 no no yes yes > > I'm a bit surprised by the facts that (1) an SSL2 client can't connect > to an SSL23 server, and (2) an SSL23 client can *only* connect to an > SSL23 server. Can anyone verify that these combos (the results of > testing with the Python framework) are indeed to be expected? Sure enough, in testing on my FC7 platform, which has a more modern version of OpenSSL (0.9.8e instead of the older 0.9.7l platform I was using), an SSL2 client *can* connect to an SSL23 server. And I got one of the above entries wrong: an SSL23 client can connect to an SSL2 server. I guess in the test harness, I'll just note the discrepancy, but not fail the test either way. And I'll add a note to the documentation. 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] which SSL client protocols work with which server protocols?
Here's the updated connection table: SSL2SSL3SS23TLS1 SSL2yes no yes no SSL3yes yes yes no SSL23 yes no yes no TLS1no no yes yes Given this, I think the client-side default should be changed from SSLv23 to SSLv3, and the server-side default should be SSLv23. 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] [PEPs] Email addresses in PEPs?
[EMAIL PROTECTED] wrote: > Trent> If some would find it useful, here is a snippet of code that > Trent> obfuscates email addresses for HTML as done by Markdown (a > Trent> text-to-html markup translator). It randomly encodes each > Trent> charater as a hex or decimal HTML entity (roughly 10% raw, 45% > Trent> hex, 45% dec). > > Aren't most spammers' scrapers going to be intelligent enough by now > (several years since they first arrived on the scene) to "see through" these > sorts of common obfuscations? Perhaps, yes. No way of really knowing. Trent -- Trent Mick trentm at activestate.com ___ 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] Python tickets summary
People: I modified my tool, whichs makes a summary of all the Python tickets (I moved the source where the info is taken from SF to our Roundup). In result, the summary is now, again, updated daily: http://www.taniquetil.com.ar/facundo/py_tickets.html Enjoy it. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Alpha/Tru64 buildbot and SSL compile
The Alpha/Tru64 buildbot seems to be having difficulty compiling the _ssl.c file. Looks like missing header files. Anyone know what the configuration of OpenSSL on that machine is like? 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] Solaris 10 buildbot test_ssl failures
The Solaris 10 buildbot is complaining about test_ssl, and I think it's because some of the functions in it use constants from the ssl module at the top level, i.e., def tryProtocolCombo (server_protocol, client_protocol, expectedToWork, certsreqs=ssl.CERT_NONE): Is this verboten? 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] Design and direction of the SSL module (was Re: frozenset C API?)
By the way, if you're offering to help with this, there are a couple of things I could use some help with. I scratched my head a bit about how to turn the "othername" possibility of a subjectAltName into a Python data structure, using the OpenSSL C code, and finally gave up. If you could provide a C function that does that, I'd be very grateful. And there's a similar issue with the "permanent identifier" defined in RFC 4043. I don't see how to iterate over an ASN1 sequence using the OpenSSL C code -- if you can figure out how to do that and provide a C function to translate that field in a certificate into a Python data structure, it would also be a great help. 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] Solaris 10 buildbot test_ssl failures
> The Solaris 10 buildbot is complaining about test_ssl, and I think > it's because some of the functions in it use constants from the ssl > module at the top level, i.e., > > def tryProtocolCombo (server_protocol, > client_protocol, > expectedToWork, > certsreqs=ssl.CERT_NONE): > > Is this verboten? Of course it is. Yep, that was it. Solaris 10 is green. 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] testing in a Python --without-threads build
On Sat, Sep 08, 2007, "Martin v. L?wis" wrote: > > No. IIUC, "expected skips" are a platform property. For your platform, > support for threads is expected (whatever your platform is as log as > it was built in this millenium). Really? I thought NetBSD was still iffy WRT threading. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Many customs in this life persist because they ease friction and promote productivity as a result of universal agreement, and whether they are precisely the optimal choices is much less important." --Henry Spencer http://www.lysator.liu.se/c/ten-commandments.html ___ 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] Alpha/Tru64 buildbot and SSL compile
> The Alpha/Tru64 buildbot seems to be having difficulty compiling > the _ssl.c file. Looks like missing header files. Anyone know what > the configuration of OpenSSL on that machine is like? Neal Norwitz and Ralf Grosse-Kunstleve have access to that machine. 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] Alpha/Tru64 buildbot and SSL compile
On Tuesday 11 September 2007, Martin v. Löwis wrote: > > The Alpha/Tru64 buildbot seems to be having difficulty > > compiling the _ssl.c file. Looks like missing header files. > > Anyone know what the configuration of OpenSSL on that machine > > is like? > > Neal Norwitz and Ralf Grosse-Kunstleve have access to that > machine. Neal's on leave all this month, I believe. -- Anthony Baxter, ekit. [EMAIL PROTECTED] (03) 9674 7015 Level 3 The Teahouse, 28 Clarendon St, Sth Melbourne Australia 3205 ___ 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] testing in a Python --without-threads build
>> No. IIUC, "expected skips" are a platform property. For your platform, >> support for threads is expected (whatever your platform is as log as >> it was built in this millenium). > > Really? I thought NetBSD was still iffy WRT threading. Ah, right. Still, it seems that people expect that thread support is available on NetBSD. The list of expected skips does not mention test_thread for 'netbsd3' (it only does so for 'sco_sv3' and 'riscos') 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] Alpha/Tru64 buildbot and SSL compile
> > Neal Norwitz and Ralf Grosse-Kunstleve have access to that > > machine. > > Neal's on leave all this month, I believe. Well, I'm not sure it's urgent. Are there lots of Alphas still running? And Tru64 is in end-of-life mode. 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] Compiling Python 2.5 and settinf UCS2 flag
Hi all, I have an unusual use case in which some software I work on compiles a version of Python for distribution. I'm not 100% across this as it's not at all my area of responsibility, but I have been having some issues lately. My hand-compiled version of Python 2.5 works just fine, and in turn uses a hand-compiled Tcl/Tk with threading disabled. The system then re-compiles Python2.5 for its own purposes. At this point, it appears to ignore some of the options originally set using configure for Python. I have enough knowledge/control over the system to pass in some additional compiler flags. I would like to try to force some behaviour normally set as a flag to the configure script. Is there a C compiler flag I can use to force the use of UCS2 unicode? Thanks, -Tennessee ___ 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
