I see that base64.b64encode and base64.standard_b64encode no longer
introduce line breaks into the output strings, as base64.encodestring
does. Shouldn't there be an option on one of them to do this?
On Fri, 14 Sep 2007 17:43:39 -0400, James Y Knight <foom(a)fuhm.net> wrote:
>On Sep 14, 2007, at 3:30 PM, Jean-Paul Calderone wrote:
>>On Fri, 14 Sep 2007 14:13:47 -0500, Justin Tulloss <tulloss2(a)uiuc.edu>
>>>Your idea can be combined with the maxint/2 initial refcount for
>>>>non-disposable objects, which should about eliminate thread-count
>>>I don't really like the maxint/2 idea because it requires us to
>>>differentiate between globals and everything else. Plus, it's a hack. I'd
>>>like a more elegant solution if possible.
>>It's not really a solution either. If your program runs for a couple
>>minutes and then exits, maybe it won't trigger some catastrophic behavior
>>from this hack, but if you have a long running process then you're almost
>>certain to be screwed over by this (it wouldn't even have to be *very*
>>long running - a month or two could do it on a 32bit platform).
>Not true: the refcount becoming 0 only calls a dealloc function.. For
>objects which are not deletable, the dealloc function should simply set the
>refcount back to maxint/2. Done.
So, eg, replace the Py_FatalError in none_dealloc with an assignment to
ob_refcnt? Good point, sounds like it could work (I'm pretty sure you
know more about deallocation in CPython than I :).
a quick question: i'm working on a pythonic build system, where the
scripts are plain python files. but i want to differentiate them from
python files (.py) by a different suffix (say .pyy), but then i can't
so i'm wondering, is there a quick way to just add another extension
import mechanism? or do i have to write a fully fledged import hook?
I've now got an HTTPS server (more importantly, one built on asyncore
and SocketServer and BaseHTTPServer), running in the test suite.
Also, I think that, for the moment, I'm going to take
ssl.ssl_shutdown() out of the library. The state machine implemented
at the GoogleSprint really only does the client side of
SSL_shutdown(); it will take a bit more work for the server side.
I'll check this in this weekend, and update the 2.3-compatible package.
On 13/09/2007, Bill Janssen <janssen(a)parc.com> wrote:
> > I could build some Windows installers if you want, but I'd need to
> > download and install some extra versions of Python, so you'd have to
> > tell me which you want doing (and I can't offer to commit to doing
> > this on a regular basis...)
> Thanks, but let's wait till this settles down a bit (say, a week
> passes without me saying anything about it :-). Then I'll definitely
> want both VS and mingw versions to upload to the Cheeseshop. But
> it's not quite ready yet.
OK, ignore my other message then (except as an indication that I can
build them when you're ready :-)).
You don't need VS and mingw binary installers, though - the mingw ones
will work for any Python (ignoring specialised custom builds, and
anyone doing one of them is probably capable of building the ssl
On 13/09/2007, Bill Janssen <janssen(a)parc.com> wrote:
> > Anyway, philosophy aside, I'll try to make some time in the next few
> > days to get a working setup.py for the SSL package using mingw.
> > Hopefully, Bill will then integrate this and we'll have mingw as a
> > supported option.
> I'll be happy to do that!
OK, the following patch to setup.py works for mingw32. You need to set
2 variables -
1. The location where you installed gnuwin32
2. Whether you want a static or dynamic build
I've checked both versions on Python 2.5.1 and they pass all tests.
Static build is 670k, dynamic is 26k (but depends on the openssl DLLs
libssl32.dll and libeay32.dll).
Ideally, these should be settable via command line options or
something. Also, it would be nice to detect the use of MSVC and do
something equivalent (but presumably somewhat different), but I don't
know how to detect the type of compiler the user has selected :-(
Anyway, I hope it's useful. If nothing else, it offers a way for
people to build the module with free software on Windows.
I could build some Windows installers if you want, but I'd need to
download and install some extra versions of Python, so you'd have to
tell me which you want doing (and I can't offer to commit to doing
this on a regular basis...)
On 9/5/07, Bill Janssen <janssen(a)parc.com> wrote:
> > It's actually easier to do all or nothing. I'm tempted to just report
> > 'critical' extensions.
> Simpler to provide them all, though I should note that the purpose of
> the information provided here is mainly for authorization/accounting
> purposes, not for "other" use of the certificate. If that's desired,
> they should pull the binary form of the certificate (there's an
> interface for that), and use M2Crypto or PyOpenSSL to decode it in
> general. This certificate has already been validated; the issue is
> how to get critical information to the app so it can make
> authorization decisions (like subjectAltName when the subject field is
> empty). Reporting non-critical extensions like "extended key usage"
> is nifty, but seems pointless.
"""If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
This is from an explanation of how to do hostname verification when
doing HTTPS requests. HTTPS clients MUST do this in order to be
compliant. Is an HTTPS client not in your list of use cases?
"""In general, HTTP/TLS requests are generated by dereferencing a URI.
As a consequence, the hostname for the server is known to the client.
If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message, in
order to prevent man-in-the-middle attacks."""
I really don't understand why you would not expose all data in the
certificate. It seems totally obvious. The data is there for a reason.
I want the subjectAltName. Probably other people want other stuff. Why
cripple it? Please include it all.
International Man of Twistery
I can't figure out how to build a Windows package for ssl-1.1.tar.gz,
and probably don't have the tools to do it anyway. I presume that
both a Windows machine and Visual Studio (because there's a C
extension) is required?
Anyone out there who's interested in the challenge?
It's at http://www.parc.com/janssen/transient/ssl-1.1.tar.gz.
Incidentally, there's no documentation in the package; instead, just
use the development documentation at
The local patch I have for PEP 366 is somewhat stale, and before I bring
it up to date with SVN head, I'd like to close out the issue raised a
while back regarding making zip files executable .
The original proposal was for a new command line switch, but PJE came up
with a patch (attached to the roundup tracker item) that uses the
existing import machinery to avoid the need for the extra command line
switch (by checking if the argument is a valid sys.path entry before
checking to see if it is an executable script).
I personally like the idea (and PJE's approach), and the performance
impact on script startup time appears to be negligible (although I
haven't performed any high precision measurements - I'm just using the
Linux time utility on a short test script with and without the patch).
Are there any objections to my committing this?
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia