[Python-Dev] python sphinx install?
I'm interested in trying out new style (python 2.6) documentation. I see we're using docutils + sphinx? I did: svn co http://svn.python.org/projects/doctools/trunk/ How can I install this to try it with python-2.5? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python sphinx install?
Neal Becker schrieb: > I'm interested in trying out new style (python 2.6) documentation. I see > we're using docutils + sphinx? > > I did: svn co http://svn.python.org/projects/doctools/trunk/ > > How can I install this to try it with python-2.5? What do you want to try with Python 2.5? If you want to build the Python 2.6/3.0 docs, it's easiest to check the Python sources out from http://svn.python.org/projects/python/trunk, go to the Doc directory and do "make html". This will checkout sphinx and all other needed libraries into Doc/tools and build the docs. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] x86 XP trunk failure
Hi all, My build slave (http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk) keeps failing because of a crash that appears to be in the bsddb module. I assume the master deems the slave to be lost because it's sitting there waiting on me to make a choice on the "debug/abort" dialog box. I can provide details if anybody needs them. I just figured somebody might want to know that this is actual build/test problem instead of some kind of issue with the internet connection here. Thanks, Alan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python sphinx install?
Georg Brandl wrote: > Neal Becker schrieb: >> I'm interested in trying out new style (python 2.6) documentation. I see >> we're using docutils + sphinx? >> >> I did: svn co http://svn.python.org/projects/doctools/trunk/ >> >> How can I install this to try it with python-2.5? > > What do you want to try with Python 2.5? > > If you want to build the Python 2.6/3.0 docs, it's easiest to check the > Python sources out from http://svn.python.org/projects/python/trunk, go to > the Doc directory and do "make html". This will checkout sphinx and all > other needed libraries into Doc/tools and build the docs. > > Georg > I want to document my own python code. I figured I might as well start using the new documentation system - but I'm using python-2.5. I intend to use epydoc. I thought maybe I could just add sphinx to my docutils, but maybe not? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python sphinx install?
Neal Becker schrieb: > Georg Brandl wrote: > >> Neal Becker schrieb: >>> I'm interested in trying out new style (python 2.6) documentation. I see >>> we're using docutils + sphinx? >>> >>> I did: svn co http://svn.python.org/projects/doctools/trunk/ >>> >>> How can I install this to try it with python-2.5? >> >> What do you want to try with Python 2.5? >> >> If you want to build the Python 2.6/3.0 docs, it's easiest to check the >> Python sources out from http://svn.python.org/projects/python/trunk, go to >> the Doc directory and do "make html". This will checkout sphinx and all >> other needed libraries into Doc/tools and build the docs. >> >> Georg >> > > I want to document my own python code. I figured I might as well start > using the new documentation system - but I'm using python-2.5. I intend to > use epydoc. I thought maybe I could just add sphinx to my docutils, but > maybe not? I see. Currently, sphinx is not ready to be used by other projects, at least not in conjunction with tools like epydoc. (You should, however, be able to create a rst document hierarchy like Python's and use sphinx for it.) As soon as all needs for the Python documentation are fulfilled, I'll think about how to make the toolset available for other projects. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x86 XP trunk failure
> My build slave (http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk) > keeps failing because of a crash that appears to be in the bsddb > module. I assume the master deems the slave to be lost because it's > sitting there waiting on me to make a choice on the "debug/abort" > dialog box. What branch, and for how long has this dialog been sitting around? For crashes in 3.0, there should not be any such dialogs anymore, but there may have been before I turned them off. > I can provide details if anybody needs them. I just figured somebody > might want to know that this is actual build/test problem instead of > some kind of issue with the internet connection here. Thanks. You can discard any such dialogs - most likely, they really were from the 3.0 branch, which is known to crash in bsddb. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x86 XP trunk failure
On 9/5/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > My build slave (http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk) > > keeps failing because of a crash that appears to be in the bsddb > > module. I assume the master deems the slave to be lost because it's > > sitting there waiting on me to make a choice on the "debug/abort" > > dialog box. > > What branch, and for how long has this dialog been sitting around? It's the trunk; at the moment the debugger is sitting there with python_d.exe at a breakpoint. The current instance of python_d being debugged is only a day or so old. I don't know when this problem started happening, but I think it's been a while (it was happening for all the visible builds on the dashboard when I first noticed it a day or two ago). > For crashes in 3.0, there should not be any such dialogs anymore, but > there may have been before I turned them off. > > > I can provide details if anybody needs them. I just figured somebody > > might want to know that this is actual build/test problem instead of > > some kind of issue with the internet connection here. > > Thanks. You can discard any such dialogs - most likely, they really were > from the 3.0 branch, which is known to crash in bsddb. Ok. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> > In any case, it certainly sounds to me as if there can be multiple > > instances of AttributeTypeAndValue with the same "type" field in a > > single Name. So I'll represent them as tuples, which will preserve > > the order in which they occur in the certificate, and make the value > > immutable. > > Ok. I think this will still not support multi-valued RDNs properly, but > those are uncommon in PKI. I'm not sure why not... Can you say more? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
>The DNs of these are structurally different, one being >/DC=org/DC=python/CN=foo/CN=bar and the other >/DC=org/DC=python/CN=foo2+CN=bar2 Ah, I see what you're driving at. You can inspect them yourself by looking at the certs with openssl: % openssl x509 -text -in attachment-0002.crt Certificate: Data: Version: 3 (0x2) Serial Number: a9:29:70:b4:3a:72:27:5a Signature Algorithm: sha1WithRSAEncryption Issuer: DC=org, DC=python, CN=foo, CN=bar Validity Not Before: Sep 5 05:38:20 2007 GMT Not After : Sep 4 05:38:20 2008 GMT Subject: DC=org, DC=python, CN=foo, CN=bar Subject Public Key Info ... % openssl x509 -text -in attachment-0003.crt Certificate: Data: Version: 3 (0x2) Serial Number: 82:0a:4f:36:0f:ab:1a:c3 Signature Algorithm: sha1WithRSAEncryption Issuer: DC=org, DC=python, CN=bar2, CN=foo2 Validity Not Before: Sep 5 05:43:26 2007 GMT Not After : Sep 4 05:43:26 2008 GMT Subject: DC=org, DC=python, CN=bar2, CN=foo2 Subject Public Key Info: The hierarchy information does not appear to be preserved. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
More succinctly: % openssl x509 -subject -noout -in attachment-0002.crt subject= /DC=org/DC=python/CN=foo/CN=bar % openssl x509 -subject -noout -in attachment-0003.crt subject= /DC=org/DC=python/CN=bar2/CN=foo2 % Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
>> Ok. I think this will still not support multi-valued RDNs properly, but
>> those are uncommon in PKI.
>
> I'm not sure why not... Can you say more?
See the example certificates. If you get (('cn','a'),('email','b')),
you can't tell whether that's two single-valued RDNs in a DN,
or one multi-valued RDN with two attribute/value pairs.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> The hierarchy information does not appear to be preserved.
But it only appears so. OpenSSL does not know how to render it
properly (hence I say it is not very common in PKI), but they
started supporting that when generating certificates, with the
-multivalue-rdn option for req, and if you do
openssl asn1parse -in ca1.crt
you see that they differ:
(ca1)
l= 17 cons: SEQUENCE
l= 10 prim: OBJECT:domainComponent
l= 3 prim: IA5STRING :org
l= 22 cons: SET
l= 20 cons: SEQUENCE
l= 10 prim: OBJECT:domainComponent
l= 6 prim: IA5STRING :python
l= 12 cons: SET
l= 10 cons: SEQUENCE
l= 3 prim: OBJECT:commonName
l= 3 prim: PRINTABLESTRING :foo
l= 12 cons: SET
l= 10 cons: SEQUENCE
l= 3 prim: OBJECT:commonName
l= 3 prim: PRINTABLESTRING :bar
(ca2)
l= 17 cons: SEQUENCE
l= 10 prim: OBJECT:domainComponent
l= 3 prim: IA5STRING :org
l= 22 cons: SET
l= 20 cons: SEQUENCE
l= 10 prim: OBJECT:domainComponent
l= 6 prim: IA5STRING :python
l= 26 cons: SET
l= 11 cons: SEQUENCE
l= 3 prim: OBJECT:commonName
l= 4 prim: PRINTABLESTRING :bar2
l= 11 cons: SEQUENCE
l= 3 prim: OBJECT:commonName
l= 4 prim: PRINTABLESTRING :foo2
In the first case, foo and bar are in different sets, in the
second case, they are in the same set.
For people concerned about security, that makes a difference.
If OpenSSL actually supports that in its APIs, my proposal
would be to make a multi-valued RDN a more-than-two-tuple,
e.g.
(('DC','org'),('DC','python'),('CN','bar2','CN','foo2'))
That would make it possible to distinguish the names (pun
intended), yet still don't produce structural overhead for
the normal case of single-valued RDNs.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> % openssl x509 -subject -noout -in attachment-0002.crt > subject= /DC=org/DC=python/CN=foo/CN=bar > % openssl x509 -subject -noout -in attachment-0003.crt > subject= /DC=org/DC=python/CN=bar2/CN=foo2 Well, that's the same bug that John Nagle complains about. This output is incorrect. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> See the example certificates. If you get (('cn','a'),('email','b')),
> you can't tell whether that's two single-valued RDNs in a DN,
> or one multi-valued RDN with two attribute/value pairs.
Yup, got it. I don't see a way in the OpenSSL library functions I'm
using (X509_NAME_ENTRY_get_object, X509_NAME_ENTRY_get_data) to
distinguish between different RDNs, but I'll take a look at the source
for X509_NAME_print_ex, which does seem to be able to do this.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> Yup, got it. I don't see a way in the OpenSSL library functions I'm > using (X509_NAME_ENTRY_get_object, X509_NAME_ENTRY_get_data) to > distinguish between different RDNs, but I'll take a look at the source > for X509_NAME_print_ex, which does seem to be able to do this. There's a field on the X509_NAME_ENTRY struct which gives the level. OK, I can make it a tuple (list of RDNs) of tuples (one for each RDN) of tuples (one for each attribute in the RDN). And maybe add a flatten function to the ssl.py module :-). Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> Well, that's the same bug that John Nagle complains about. Yes, I agree. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> There's a field on the X509_NAME_ENTRY struct which gives the level. > OK, I can make it a tuple (list of RDNs) of tuples (one for each RDN) > of tuples (one for each attribute in the RDN). And maybe add a > flatten function to the ssl.py module :-). > See my other proposal as well. As nobody actually uses multi-valued RDNs, an option would be to make single tuple for each RDN, containing all attributes, with alternatingly type and value. Then, a single-valued RDN would turn out as a key-value pair (two-tuple), a multi-valued RDN would have a length of 2*number-of-attributes. As for accessor functions, I'd then rather see a get_attr_by_type, returning a list of all values of attributes of that type, across all RDNs in the DN (empty if no attribute was found). People would then do x = get_attr_by_type(subj, ssl.commonName) if len(x) != 1: unsupported_certificate() CN = x[0] Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> OK, I can make it a tuple (list of RDNs) of tuples (one for each RDN)
> of tuples (one for each attribute in the RDN).
Which gets us to this:
{'issuer': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'SSL'),),
(('commonName', u'somemachine.python.org'),)),
'notAfter': 'Feb 16 16:54:50 2013 GMT',
'notBefore': 'Aug 27 16:54:50 2007 GMT',
'subject': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'SSL'),),
(('commonName', u'somemachine.python.org'),)),
'version': 2}
and
{'issuer': ((('countryName', u'US'),),
(('organizationName', u'VeriSign, Inc.'),),
(('organizationalUnitName', u'VeriSign Trust Network'),),
(('organizationalUnitName',
u'Terms of use at https://www.verisign.com/rpa (c)06'),),
(('commonName',
u'VeriSign Class 3 Extended Validation SSL SGC CA'),)),
'notAfter': 'May 8 23:59:59 2009 GMT',
'notBefore': 'May 9 00:00:00 2007 GMT',
'subject': ((('serialNumber', u'2497886'),),
(('1.3.6.1.4.1.311.60.2.1.3', u'US'),),
(('1.3.6.1.4.1.311.60.2.1.2', u'Delaware'),),
(('countryName', u'US'),),
(('postalCode', u'94043'),),
(('stateOrProvinceName', u'California'),),
(('localityName', u'Mountain View'),),
(('streetAddress', u'487 East Middlefield Road'),),
(('organizationName', u'VeriSign, Inc.'),),
(('organizationalUnitName', u'Production Security Services'),),
(('organizationalUnitName',
u'Terms of use at www.verisign.com/rpa (c)06'),),
(('commonName', u'www.verisign.com'),)),
'version': 2}
Ugly, but accurate. Or is it? Do you really think that
"serialNumber" is at the top of a naming tree somewhere?
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> 'subject': ((('serialNumber', u'2497886'),),
> (('1.3.6.1.4.1.311.60.2.1.3', u'US'),),
> (('1.3.6.1.4.1.311.60.2.1.2', u'Delaware'),),
> (('countryName', u'US'),),
> (('postalCode', u'94043'),),
> (('stateOrProvinceName', u'California'),),
> (('localityName', u'Mountain View'),),
> (('streetAddress', u'487 East Middlefield Road'),),
> (('organizationName', u'VeriSign, Inc.'),),
> (('organizationalUnitName', u'Production Security Services'),),
> (('organizationalUnitName',
>u'Terms of use at www.verisign.com/rpa (c)06'),),
> (('commonName', u'www.verisign.com'),)),
> 'version': 2}
>
> Ugly, but accurate. Or is it? Do you really think that
> "serialNumber" is at the top of a naming tree somewhere?
Firefox claims the same order. To bad Verisign hasn't grasped
the concept of distinguished names :-(
Had they done it right, incorporationStateId, incorporationLocalityId,
streetAddress, localityName, postalCode would all have been in the
RDN with organizationName - they are all attributes of that
organization (or the address attributes perhaps belong to the OU).
Also, I doubt they have an organizationalUnit "Terms of use at ...".
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Errors in the csv module reader/writer methods - new w/ change to rst?
I was just looking for some csv DictWriter examples for a colleague at work and was myself confused by the apparent transformation which took place in the Reader Objects and Writer Objects sections. Each of the methods is now prefixed by "csv.csvreader." or "csv.csvwriter." Neither expression was previously defined in that section. Those undefined expressions are not in the old versions of the documentation, e.g.: http://www.python.org/doc/2.4.4/lib/node634.html http://www.python.org/doc/2.4.4/lib/node635.html http://www.python.org/doc/2.5/lib/node265.html http://www.python.org/doc/2.5/lib/node266.html I don't think they add anything useful to the documentation. Were they added just for the csv module (and possibly a few others) or was this a change to the entire libref documentation? That is, was this some sort of policy change? Can they be removed? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
All of this makes me think that some folks may want to do more processing on certificates with more advanced tools, and for that they will need access to the full bits of the certificate. I'll add the ability to retrieve that as well. I'm wondering if I should try to pull some extension attributes out of the cert, and add them to the dict, as well. Like subjectAltName, for instance. Or should we just wait till someone wants it and files a bug report? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> I'm wondering if I should try to pull some extension attributes out of > the cert, and add them to the dict, as well. Like subjectAltName, for > instance. Or should we just wait till someone wants it and files a > bug report? If you have the time and inclination to do that, feel free to. Covering some of the most widely used extensions could be useful: subjectAltName, key usage, extended key usage. If you set up a framework for that, people will contribute others they like to see supported. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x86 XP trunk failure
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: >> My build slave (http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk) >> keeps failing because of a crash that appears to be in the bsddb >> module. I assume the master deems the slave to be lost because it's >> sitting there waiting on me to make a choice on the "debug/abort" >> dialog box. > > What branch, and for how long has this dialog been sitting around? > > For crashes in 3.0, there should not be any such dialogs anymore, but > there may have been before I turned them off. I think there may actually be an issue here, if only with the tests, even though 3.0 does suppress the dialog. I think I started noticing this in the first build after bringing my buildbot online, so I think on Sep 1. I had manually done on a build on Aug 28 (running the buildbot batch file interactively) without the problem, but I haven't been able to find any relevant source tree changes in that interval. Re-fetching from that date has the problem, and I had blown away my older tree when starting up the buildbot officially (of course :-(). At least for me, it's happening on 2.5 and trunk (hard to tell about 3.0, but that's dying without a dialog), so I thought it might have been something backported. But it also appears common to more platforms than just Windows - it's just Windows that pops up that dialog. In my case, the actual dialog doesn't pop up until the end of the tests, and it seems to be occurring only if test_bsddb3 has run during the tests. On other platforms, it just shows up as a warning message, which doesn't serve to mark the tests as failing (e.g., OS X and FreeBSD) - at the of the test you get a message of: warning: DBTxn aborted in destructor. No prior commit() or abort(). which I tracked back to an abort() call within the bsddb library as final destruction is happening at Python exit. (When clearing the test_bsddb module, and the bsddb wrapper tries to access a log file related to an open transaction). So perhaps there's an issue with how one or more of the tests are constructed, or cleanup or something. I haven't narrowed it down further yet though. As with Alan, more details are available as needed. While it seems to show up in the full test run on more platforms, I have a harder time forcing it by just running test_bsddb3 on FreeBSD, for example, while I get the dialog consistently on Windows. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x86 XP trunk failure
I previously wrote: > (...) > which I tracked back to an abort() call within the bsddb library as > final destruction is happening at Python exit. (When clearing the > test_bsddb module, and the bsddb wrapper tries to access a log file > related to an open transaction). (...) For those more familiar with bsddb, it's the test_1413192.py module in lib/bsddb/test that tickles the problem. It should have been more obvious, since I saw the 1413192 in the module name during exit cleanup, but mentally ignored it as an internal identifier of some sort. The test module clearly leaves an open transaction, but also purges its working directory, so maybe that's why the log file is missing. But since the test was specifically against object destruction, I'm not sure how best to restructure (maybe make env_name into a class that only prunes the directory in __del__? Although that would affect GC and thus destruction order too). This test has been around a bit, but the pruning of the directory was backported recently, which is probably the source of the problems. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Product function patch [issue 1093]
Guido van Rossum wrote: > By all means do write up a PEP -- it's hard to generalize from that one > example. I'll write a PEP as soon as I get a chance. But the generalisation is pretty straightforward -- just replicate that signature for each of the binary operations. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x86 XP trunk failure
> warning: DBTxn aborted in destructor. No prior commit() or abort(). I have seen these as well. bsddb isn't very forgiving when you have a Python exception inside a bsddb transaction, in the test suite. IIRC, the exception will abort the transaction, then the unittest fixture teardown will close the environment, and that will cause a bsddb crash because something is getting released that does not exist anymore. When I last looked at it, I did not see an easy way to fix it; contributions are welcome. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x86 XP trunk failure
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: >> warning: DBTxn aborted in destructor. No prior commit() or abort(). > > I have seen these as well. bsddb isn't very forgiving when you have > a Python exception inside a bsddb transaction, in the test suite. > IIRC, the exception will abort the transaction, then the unittest > fixture teardown will close the environment, and that will cause > a bsddb crash because something is getting released that does not > exist anymore. When I last looked at it, I did not see an easy way to > fix it; contributions are welcome. One thing I tried that seems to work fairly well for this case is to encapsulate much of the module-level code in the test into a class instance. That way the module-level code can instantiate and destroy the class instance rather than waiting for the interpreter exit for the latter. It definitely resolves this current issue, but when I reverted the changes to _bsddb.c that were originally made in conjunction with this test, it still seemed to pass the test. So I tried the reverted module with the original test code and it still passes. So I'm not entirely sure that the test is enforcing anything at this point, or at least I'm not sure how to be absolutely positive that the change will continue to enforce what the existing code used to test. But I can open a ticket with the proposed changes if that would help. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] x86 XP trunk failure
I wrote: > But I can open a ticket with the proposed changes if that would help. Figure it can't hurt - I've created issue 1112 with the proposed patch to the test_1413192.py module. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Google spreadsheet to collaborate on backporting Py3K stuff to 2.6
Neal, Anthony, Thomas W., and I have a spreadsheet that was started to keep track of what needs to be done in what needs to be done in 2.6 for Py3K transitioning: http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg . I am opening the spreadsheet up to everyone so that others can help maintain it. There is a sheet in the Python 3000 Tasks spreadsheet that should be merged into this spreadsheet and then deleted. If anyone wants to help with that it would be great (once something has been moved from "Python 3000 Tasks" to "Python 2 -> 3 transition" just delete it from "Python 3000 Tasks"). Because Neal created this spreadsheet he is the only one who can open editing to everyone. If you would like to have edit abilities to the spreadsheet just reply to this email saying you want an invite and I will add you manually (and if you want a different address added just say so). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> > I'm wondering if I should try to pull some extension attributes out of > > the cert, and add them to the dict, as well. Like subjectAltName, for > > instance. Or should we just wait till someone wants it and files a > > bug report? > > If you have the time and inclination to do that, feel free to. Covering > some of the most widely used extensions could be useful: subjectAltName, > key usage, extended key usage. If you set up a framework for that, > people will contribute others they like to see supported. It's actually easier to do all or nothing. I'm tempted to just report 'critical' extensions. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frozenset C API?
> > > I'm wondering if I should try to pull some extension attributes out of
> > > the cert, and add them to the dict, as well. Like subjectAltName, for
> > > instance. Or should we just wait till someone wants it and files a
> > > bug report?
> >
> > If you have the time and inclination to do that, feel free to. Covering
> > some of the most widely used extensions could be useful: subjectAltName,
> > key usage, extended key usage. If you set up a framework for that,
> > people will contribute others they like to see supported.
>
> 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.
Here's an example:
{'extensions': {'Netscape Cert Type': u'SSL Server'},
'issuer': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'SSL'),),
(('commonName', u'somemachine.python.org'),)),
'notAfter': 'Feb 16 16:54:50 2013 GMT',
'notBefore': 'Aug 27 16:54:50 2007 GMT',
'serialNumber': 'FFAA4ADBF570818D',
'subject': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'SSL'),),
(('commonName', u'somemachine.python.org'),)),
'version': 3}
and
{'extensions': {'1.3.6.1.5.5.7.1.12': u'',
'Authority Information Access': u'OCSP -
URI:http://EVIntl-ocsp.verisign.com\n',
'X509v3 Authority Key Identifier':
u'keyid:4E:43:C8:1D:76:EF:37:53:7A:4F:F2:58:6F:94:F3:38:E2:D5:BD:DF\n',
'X509v3 Basic Constraints': u'CA:FALSE',
'X509v3 CRL Distribution Points':
u'URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl\n',
'X509v3 Certificate Policies': u'Policy:
2.16.840.1.113733.1.7.23.6\n',
'X509v3 Extended Key Usage': u'TLS Web Server
Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto,
Microsoft Server Gated Crypto',
'X509v3 Key Usage': u'Digital Signature, Key
Encipherment',
'X509v3 Subject Key Identifier':
u'F1:5A:89:93:55:47:4B:BA:51:F5:4E:E0:CB:16:55:F4:D7:CC:38:67'},
'issuer': ((('countryName', u'US'),),
(('organizationName', u'VeriSign, Inc.'),),
(('organizationalUnitName', u'VeriSign Trust Network'),),
(('organizationalUnitName',
u'Terms of use at https://www.verisign.com/rpa (c)06'),),
(('commonName',
u'VeriSign Class 3 Extended Validation SSL SGC CA'),)),
'notAfter': 'May 8 23:59:59 2009 GMT',
'notBefore': 'May 9 00:00:00 2007 GMT',
'serialNumber': '6A4AC31B3110E6EB48F0FC51A39A171F',
'subject': ((('serialNumber', u'2497886'),),
(('1.3.6.1.4.1.311.60.2.1.3', u'US'),),
(('1.3.6.1.4.1.311.60.2.1.2', u'Delaware'),),
(('countryName', u'US'),),
(('postalCode', u'94043'),),
(('stateOrProvinceName', u'California'),),
(('localityName', u'Mountain View'),),
(('streetAddress', u'487 East Middlefield Road'),),
(('organizationName', u'VeriSign, Inc.'),),
(('organizationalUnitName', u'Production Security
Services'),),
(('organizationalUnitName',
u'Terms of use at www.verisign.com/rpa (c)06'),),
(('commonName', u'www.verisign.com'),)),
'version': 3}
Probably another thing that *should* be reported is the cipher used to
protect the information on the channel, so that the app can decide
whether it's strong enough for its taste. (If it's not, it can
presumably reconnect using a different variant of SSL to try for a
better result, or decide not to use the server (or talk to the client)
at all.)
Bill
___
Python-Dev mailing list
Python-Dev@python.or
Re: [Python-Dev] frozenset C API?
>> It's actually easier to do all or nothing. I'm tempted to just report
>> 'critical' extensions.
>
> Simpler to provide them all
I very much doubt that, at least if you want to report decoded
information. Conceptually, there is an infinite number of extensions,
and when you are done, I can show you lots of certificates that
have extensions that you don't support.
> 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)
> {'extensions': {'1.3.6.1.5.5.7.1.12': u'',
> 'Authority Information Access': u'OCSP -
> URI:http://EVIntl-ocsp.verisign.com\n',
> 'X509v3 Authority Key Identifier':
> u'keyid:4E:43:C8:1D:76:EF:37:53:7A:4F:F2:58:6F:94:F3:38:E2:D5:BD:DF\n',
> 'X509v3 Basic Constraints': u'CA:FALSE',
> 'X509v3 CRL Distribution Points':
> u'URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl\n',
> 'X509v3 Certificate Policies': u'Policy:
> 2.16.840.1.113733.1.7.23.6\n',
> 'X509v3 Extended Key Usage': u'TLS Web Server
> Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto,
> Microsoft Server Gated Crypto',
> 'X509v3 Key Usage': u'Digital Signature, Key
> Encipherment',
> 'X509v3 Subject Key Identifier':
> u'F1:5A:89:93:55:47:4B:BA:51:F5:4E:E0:CB:16:55:F4:D7:CC:38:67'},
Hmm. In this certificate, none of the extensions you report have been
marked critical; they are all non-critical.
Also, you are reporting the logotype (1.3.6.1.5.5.7.1.12) incorrectly;
it's defined in RFC 3709, and it's definitely not an empty string in
the certificate you've used.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
