Menu
▾
▴
pyopenssl-list — General discussion list for users and developers of pyOpenSSL
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(9) |
Sep
(2) |
Oct
(15) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(17) |
Feb
(2) |
Mar
(3) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(9) |
Aug
(4) |
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
| 2004 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
(6) |
Sep
(13) |
Oct
(5) |
Nov
(1) |
Dec
(4) |
| 2005 |
Jan
(1) |
Feb
(7) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(7) |
Aug
(5) |
Sep
(3) |
Oct
(4) |
Nov
|
Dec
(1) |
| 2006 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
(1) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(2) |
| 2007 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(5) |
Jun
(6) |
Jul
|
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
| 2008 |
Jan
(2) |
Feb
|
Mar
(10) |
Apr
(4) |
May
(3) |
Jun
(3) |
Jul
(5) |
Aug
(2) |
Sep
(30) |
Oct
(12) |
Nov
(5) |
Dec
(2) |
| 2009 |
Jan
(7) |
Feb
(1) |
Mar
(26) |
Apr
(20) |
May
(4) |
Jun
(1) |
Jul
(7) |
Aug
(21) |
Sep
(2) |
Oct
(9) |
Nov
(8) |
Dec
|
| 2010 |
Jan
(4) |
Feb
(5) |
Mar
(3) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
(13) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(6) |
Nov
(11) |
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
(13) |
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
|
From: M.-A. L. <ma...@eg...> - 2011-04-11 18:31:41
|
ex...@tw... wrote: > Also, as a reminder, there is now a pyOpenSSL list hosted on Launchpad. > At some point I will stop sending announcements to this sourceforge > list. :) Please keep using this list for pyOpenSSL announcements and user discussions. I find it strange to have a user mailing list that's closed to "team members". If you don't like SF mailing lists, I'd suggest to move the list over to python.org. This is easy, given that SF mailing lists use Mailman. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 11 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ |
|
From: <ex...@tw...> - 2011-04-08 01:07:35
|
On 12:03 am, gl...@tw... wrote: >On Apr 7, 2011, at 7:22 PM, ex...@tw... wrote: >>Also, as a reminder, there is now a pyOpenSSL list hosted on >>Launchpad. >>At some point I will stop sending announcements to this sourceforge >>list. :) > >Since Launchpad's UI makes this basically impossible to discover, here >are the steps for getting on to that list: > >Make sure you have a launchpad.net account and are logged in. (Start >here if you don't have one: ><https://login.launchpad.net/+new_account>.) >If you already did have one, make sure your email address is correct. >(See <https://launchpad.net/~your-username/+editemails> to double >check.) >Go here: <https://launchpad.net/~pyopenssl-users>. (By the way, JP, >this isn't linked anywhere from <https://launchpad.net/pyopenssl>.) >Click "join the team". >Make sure "Subscribe me to this team's mailing list" is checked. >Click "join". Thanks for spelling that out. Jean-Paul |
|
From: Glyph L. <gl...@tw...> - 2011-04-08 00:04:02
|
On Apr 7, 2011, at 7:22 PM, ex...@tw... wrote: > Also, as a reminder, there is now a pyOpenSSL list hosted on Launchpad. > At some point I will stop sending announcements to this sourceforge > list. :) Since Launchpad's UI makes this basically impossible to discover, here are the steps for getting on to that list: Make sure you have a launchpad.net account and are logged in. (Start here if you don't have one: <https://login.launchpad.net/+new_account>.) If you already did have one, make sure your email address is correct. (See <https://launchpad.net/~your-username/+editemails> to double check.) Go here: <https://launchpad.net/~pyopenssl-users>. (By the way, JP, this isn't linked anywhere from <https://launchpad.net/pyopenssl>.) Click "join the team". Make sure "Subscribe me to this team's mailing list" is checked. Click "join". |
|
From: <ex...@tw...> - 2011-04-07 23:23:06
|
Hello all, I'm working on a new pyOpenSSL release. There are various sorts of pyOpenSSL 0.12a1 packages at <http://twistedmatrix.com/~exarkun/pyopenssl/>, and it would be great to get some testing of these before I make a final release of 0.12. This is a small bugfix and feature release. The near complete changelog is: 2011-04-06 Jean-Paul Calderone <ex...@tw...> * OpenSSL/crypto/x509.c: Add get_extension_count and get_extension to the X509 type, allowing read access to certificate extensions. * OpenSSL/crypto/x509ext.c: Add get_short_name and get_data to the X509Extension type, allowing read access to the contents of an extension. 2011-03-21 Olivier Hervieu <lp:~ohe> * OpenSSL/ssl/ssl.c: Expose a number of symbolic constants for values passed to the connection "info" callback. 2011-01-22 Jean-Paul Calderone <ex...@tw...> * OpenSSL/ssl/connection.py: Add support for new-style buffers (primarily memoryviews) to Connection.send and Connection.sendall. Also, as a reminder, there is now a pyOpenSSL list hosted on Launchpad. At some point I will stop sending announcements to this sourceforge list. :) Thanks, Jean-Paul |
|
From: <lo...@co...> - 2011-01-19 01:23:57
|
I've been trying with no success to get my pyOpenSSL client to use SSL session resume when making several connections sucessively (http requests) to a Tomcat application server. I'm pretty sure everything is fine on the server end since I have several other clients making the same requests and they are all able to do session resume. For the first connection I create the ssl context. Then I just reuse it for subsequent requests # Just do this for the first and then reuse the context for subsequent connections. ssl_context = SSL.Context(SSL.SSLv23_METHOD) ssl_context.set_options(SSL.OP_NO_SSLv2) # Do this for every connection sock = socket.create_connection((self.host, self.port), self.timeout) sslconn = SSL.Connection(ssl_context, sock) sslconn.set_connect_state() sslconn.do_handshake() Thanks in advance, Dan |
|
From: Sandro T. <mo...@de...> - 2010-11-04 22:10:24
|
Hi Jean-Paul,
On Mon, Nov 1, 2010 at 23:43, <ex...@tw...> wrote:
> Hello all,
>
> I'm happy to announce the release of pyOpenSSL 0.11. The primary change
> from the last release is that Python 3.2 is now supported. Python 2.4
> through Python 2.7 are still supported as well. This release also fixes
> a handful of bugs in error handling code. It also adds APIs for
> generating and verifying cryptographic signatures and it improves the
> test suite to cover nearly 80% of the implementation.
when upgrading the Debian package, I see this test failure:
running OpenSSL/test/test_ssl.py for python2.5 ...
...................................................E.............................
======================================================================
ERROR: test_set_default_verify_paths (__main__.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "OpenSSL/test/test_ssl.py", line 565, in test_set_default_verify_paths
clientSSL.do_handshake()
Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate
verify failed')]
----------------------------------------------------------------------
Ran 81 tests in 5.687s
FAILED (errors=1)
same error in 2.6 . The build and test were done in a clean chroot.
Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
|
|
From: Glyph L. <gl...@tw...> - 2010-11-02 01:15:38
|
On Nov 1, 2010, at 6:43 PM, ex...@tw... wrote: > I'm happy to announce the release of pyOpenSSL 0.11. Congratulations, JP! It's great to see this effort coming together. |
|
From: <ex...@tw...> - 2010-11-01 22:43:41
|
Hello all,
I'm happy to announce the release of pyOpenSSL 0.11. The primary change
from the last release is that Python 3.2 is now supported. Python 2.4
through Python 2.7 are still supported as well. This release also fixes
a handful of bugs in error handling code. It also adds APIs for
generating and verifying cryptographic signatures and it improves the
test suite to cover nearly 80% of the implementation.
Downloads and more details about the release can be found on the release
page:
https://launchpad.net/pyopenssl/main/0.11
Enjoy,
Jean-Paul
|
|
From: Sandro T. <mo...@de...> - 2010-10-25 21:25:56
|
Hi, On Sat, Oct 23, 2010 at 22:12, <ex...@tw...> wrote: > Please give it a spin and let me know how it goes. I've updated the Debian package (for python 2.5 and 2.6, no 3.x yet, sorry) and it works fine (I've uploaded to our experimental branch). Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: Glyph L. <gl...@tw...> - 2010-10-23 23:26:22
|
On Oct 23, 2010, at 4:12 PM, ex...@tw... wrote: > Please give it a spin and let me know how it goes. Looking good on Snow Leopard. (with the system python and Twisted trunk). |
|
From: <ex...@tw...> - 2010-10-23 20:12:30
|
Hello all, I've just uploaded a number of 0.11a2 release files. You can find them on <http://launchpad.net/pyopenssl>. 0.11a2 differs from 0.11a1 in that it fixes a distutils bug which prevented most of the C source files from being included in the source distribution. It also changes certain code which sets dlopen() flags to try to use platform-defined constants if they are available, which may affect proper functioning on OS X. These are two issues are the only that have come up since the 0.11a1 release, so if nothing more is reported, 0.11 final will be the same as 0.11a2 except for the version number. The focus of 0.11 is Python 3.x support. The entire code base has been updated to be compatible with Python 3.x. As this has been a somewhat significant undertaking (made possible thanks to support from the Python Software Foundation), testing of this alpha release will be particularly helpful in ensuring that no problems have crept in. Even if you're not interested in Python 3.x support yourself, testing on your preferred version of Python 2.x (0.11 will support Python 2.4 through Python 2.7) is useful too - to make sure the 3.x support hasn't caused any problems on 2.x! Aside from 3.x support, this release also brings basic signature and signature verification support, contributed by James Yonan, based on Dave Cridland's code. Several bugs, mainly in code for the error handling cases, in X509, X509Req, NetscapeSPKI, and Context have also been fixed. In the quest for full test coverage, this release also raises the percent of lines executed by the test suite to 79.8% from about 62.5% for the last release. Please give it a spin and let me know how it goes. Jean-Paul |
|
From: Glyph L. <gl...@tw...> - 2010-10-08 23:51:58
|
On Oct 7, 2010, at 11:27 PM, ex...@tw... wrote: > I've just uploaded a number of 0.11a1 release files. You can find them > on <http://launchpad.net/pyopenssl>. Congrats, this sounds like it's shaping up to be a great release. > Please give it a spin and let me know how it goes. Well, checking out from 'lp:~exarkun/pyopenssl/release-0.11', everything works great. But, if I actually download the release tarball from <http://launchpad.net/pyopenssl/main/0.11a1/+download/pyOpenSSL-0.11a1.tar.gz>, 'python.setup.py build' yields this: gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c OpenSSL/crypto/crypto.c -o build/temp.macosx-10.6-universal-2.6/OpenSSL/crypto/crypto.o OpenSSL/crypto/crypto.c:15:20: error: crypto.h: No such file or directory OpenSSL/crypto/crypto.c:16:20: error: pkcs12.h: No such file or directory and the predictable follow-on cascade or errors. I got this on both OS X Snow Leopard and Ubuntu Lucid. |
|
From: <ex...@tw...> - 2010-10-08 03:48:12
|
Hello all, I've just uploaded a number of 0.11a1 release files. You can find them on <http://launchpad.net/pyopenssl>. The focus of 0.11 is Python 3.x support. The entire code base has been updated to be compatible with Python 3.x. As this has been a somewhat significant undertaking (made possible thanks to support from the Python Software Foundation), testing of this alpha release will be particularly helpful in ensuring that no problems have crept in. Even if you're not interested in Python 3.x support yourself, testing on your preferred version of Python 2.x (0.11 will support Python 2.4 through Python 2.7) is useful too - to make sure the 3.x support hasn't caused any problems on 2.x! Aside from 3.x support, this release also brings basic signature and signature verification support, contributed by James Yonan, based on Dave Cridland's code. Several bugs, mainly in code for the error handling cases, in X509, X509Req, NetscapeSPKI, and Context have also been fixed. In the quest for full test coverage, this release also raises the percent of lines executed by the test suite to 79.8% from about 62.5% for the last release. Please give it a spin and let me know how it goes. Jean-Paul |
|
From: eGenix T. M.-A. L. <in...@eg...> - 2010-06-10 08:29:29
|
________________________________________________________________________
ANNOUNCING
eGenix.com pyOpenSSL Distribution
Version 0.10.0-1.0.0a
An easy-to-install and easy-to-use distribution
of the pyOpenSSL Python interface for OpenSSL -
available for Windows, Mac OS X and Unix platforms
This announcement is also available on our web-site for online reading:
http://www.egenix.com/company/news/eGenix-pyOpenSSL-Distribution-0.10.0-1.0.0a-1.html
________________________________________________________________________
INTRODUCTION
The eGenix.com pyOpenSSL Distribution includes everything you need to
get started with SSL in Python.
It comes with an easy-to-use installer that includes the most recent
OpenSSL library versions in pre-compiled form, making your application
independent of OS provided OpenSSL libraries:
http://www.egenix.com/products/python/pyOpenSSL/
pyOpenSSL is an open-source Python add-on that allows writing SSL/TLS-
aware network applications as well as certificate management tools:
https://launchpad.net/pyopenssl/
OpenSSL is an open-source implementation of the SSL/TLS protocol:
http://www.openssl.org/
________________________________________________________________________
NEWS
This new release of the eGenix.com pyOpenSSL Distribution updates the
included pyOpenSSL version to 0.10.0 and the included OpenSSL version
to 1.0.0a.
Main new features in pyOpenSSL 0.10.0 (from the announcement)
-------------------------------------------------------------
* pyOpenSSL 0.10 exposes several more OpenSSL APIs, including
support for running TLS connections over in-memory BIOs, access
to the OpenSSL random number generator, the ability to pass
subject and issuer parameters when creating an X509Extension
instance, more control over PKCS12 creation and an API for
exporting PKCS12 objects, and APIs for controlling the client CA
list servers send to clients.
* Several bugs have also been fixed, including a crash when
certain X509Extension instances are deallocated, a mis-handling
of the OpenSSL error queue in the X509Name implementation,
Windows build issues, and a possible double free when using a
debug build.
See Jean-Paul Calderone's full announcement for all details:
https://launchpad.net/pyopenssl/+announcement/4318
New features in OpenSSL 1.0.0a since our last release
-----------------------------------------------------
The main new features in OpenSSL 0.9.8m is the new support for RFC
5746, which addresses the SSL renegotiation problem found in earlier
OpenSSL versions.
* RFC 5746 - Transport Layer Security (TLS) Renegotiation
Indication Extension: http://tools.ietf.org/html/rfc5746
* For a complete list of changes see:
http://www.openssl.org/news/news.html
Version 0.9.8n fixes this vulnerability (see
http://www.openssl.org/news/secadv_20100324.txt):
* "Record of death" vulnerability in OpenSSL 0.9.8f through
0.9.8m
Version 1.0.0 adds many new features, including (see
http://www.openssl.org/news/news.html):
* Support for Whirlpool hash algorithm
* Support for GOST cipher
Version 1.0.0a fixes two security issues (see
http://www.openssl.org/news/secadv_20100601.txt):
* Invalid ASN1 module definition for CMS.
* Invalid Return value check in pkey_rsa_verifyrecover
New features in the eGenix pyOpenSSL Distribution
-------------------------------------------------
* The embedded OpenSSL libs will now look for certificates in
/etc/ssl on Unix platforms and /System/Library/OpenSSL on
Mac OS X
Note that it's usually better to explicitly tell OpenSSL where
to look for trusted certificates via
.load_verify_locations(None, certs_dir) than to rely on the
above defaults using context.set_default_verify_paths()
* Added support for Win64 and precompiled Python 2.6 compatible
binaries for that platform (you can find the OpenSSL libs in
openssl-win64/vc9)
* Added support for Mac OS X 10.6 on Intel x64.
* Added .egg Distributions for Python 2.4 as well (in order to
support Plone 3).
As always, we provide binaries that include both pyOpenSSL and the
necessary OpenSSL libraries for all supported platforms: Windows x86
and x64, Linux x86 and x64, Mac OS X PPC, x86 and x64.
Due to popular demand, we've also added .egg-file format versions of
our eGenix.com pyOpenSSL Distribution for Windows, Linux and Mac OS X
to the available download options.
These makes setups using e.g. zc.buildout and other egg-file based
installers a lot easier.
________________________________________________________________________
DOWNLOADS
The download archives and instructions for installing the package can
be found at:
http://www.egenix.com/products/python/pyOpenSSL/
________________________________________________________________________
UPGRADING
Before installing this version of pyOpenSSL, please make sure that
you uninstall any previously installed pyOpenSSL version. Otherwise,
you could end up not using the included OpenSSL libs.
_______________________________________________________________________
SUPPORT
Commercial support for these packages is available from eGenix.com.
Please see
http://www.egenix.com/services/support/
for details about our support offerings.
_______________________________________________________________________
INFORMATION
About Python (http://www.python.org/):
Python is an object-oriented Open Source programming language
which runs on all modern platforms. By integrating ease-of-use,
clarity in coding, enterprise application connectivity and rapid
application design, Python establishes an ideal programming
platform for today's IT challenges.
About eGenix (http://www.egenix.com/):
eGenix is a software project, consulting and product company
focusing on expert services and professional quality products for
companies, Python users and developers.
Enjoy,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 10 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK 38 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
|
|
From: Joe O. <jo...@re...> - 2010-04-20 15:42:53
|
Hi. I've created a branch here: https://code.launchpad.net/~jorton/pyopenssl/trust which adds basic support for handling of trusted certificates in pyOpenSSL. The patch is attached for review. Regards, Joe |
|
From: M.-A. L. <ma...@eg...> - 2010-03-16 11:56:19
|
ex...@tw... wrote: > On 08:55 pm, ma...@eg... wrote: >> >> Thanks for the hint. Here's the full background: >> >> http://www.madboa.com/geek/openssl/#verify-system > > Awesome link, thanks for finding it. > >> Different OSes place the trusted certificate database files in >> different places and non of them uses the OpenSSL default which >> is /usr/local/ssl and a subdir certs/. > > The version of OpenSSL distributed by Ubuntu and Debian and by Apple in > OS X 10.6 don't use the default, but the build configuration is > correctly specified so that OpenSSL can find the certificates in the > non-default location. > > In a perfect world, this is how it would be on all platforms. :) And it probably is on most platforms... I was testing with our embedded OpenSSL solution which uses the OpenSSL build defaults. Since most OSes appear to use non-standard certificate database locations, there's little hope of relying on the default verify path compiled into OpenSSL in such a case. >> The only way to work around this appears to be to call >> ctx.load_verify_locations() to point the context to the >> right set of trusted certificates. >> >> I believe that the test should apply such a setup for >> the verisign.com certificate authority instead of >> relying on a platform provided default setup, ie. use >> its own certs/ subdir with the root CA certificates that >> are used by verisign.com. > > The test in question is for ctx.set_default_verify_paths. It does seem > very likely that calling ctx.load_verify_locations with a path known to > contain the necessary CA certificate would make the test pass, but then > it would be testing something else. :) True. I missed that point :-) > I'll definitely agree that this is not a very good unit test, for a > number of reasons. I guess using that API with our pyOpenSSL distribution is not really all that useful. OTOH, explicit is better than implicit and IMHO it's better to explicitly have the user or application define which root CAs to trust or not. We'll add a note to the web page. >> In any case, the above test failure is a problem with the test >> setup more than anything else. > > I agree. I think it might make sense to try to determine if the libssl > being used was built in a way that could allow the necessary CA cert to > be found, and skip the test if it was not. Running "openssl version -d" > and checking what's in that directory might be a good heuristic. That won't work with our embedded version, since we don't ship the openssl executable, only the libs. Too bad, that there's not SSL_CTX_get_default_verify_paths(). >> Here's a version of the test which works on OpenSUSE: >> >> [snip] > > Any chance you could agitate to have the OpenSUSE build fixed so that > ctx.set_default_verify_paths can actually work? :) > > If all the major platforms had a properly built version of OpenSSL, I > think it'd be a lot easier for people to write well-behaved SSL > applications. OpenSUSE's OpenSSL libs do have the paths correclty defined. It's just that those OS libs often tend to be rather outdated and, in some cases, also have (had) serious bugs. That's the reason why we've created the eGenix pyOpenSSL distribution - it includes the OpenSSL libs embedded in the OpenSSL package and does not rely on the system provided ones. A side effect of this, is that the default OPENSSLDIR is (currently) set to /usr/local/ssl for those libs, so it's rather unlikely that the libs find the OS provided default collection of trusted root CA certs. Perhaps we should change the default to either /dev/null to make this even more secure in the "explicit is better than implicit" sense or add a function which tries to determine the OS default location for the root CA certs in order to help the developer in adding support for trusting these. Our own use case, the mxODBC Connect product, doesn't need all this, since you have to explicitly define the trusted certificates anyway. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 16 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ |
|
From: <ex...@tw...> - 2010-03-15 21:54:08
|
On 08:55 pm, ma...@eg... wrote: > >Thanks for the hint. Here's the full background: > >http://www.madboa.com/geek/openssl/#verify-system Awesome link, thanks for finding it. >Different OSes place the trusted certificate database files in >different places and non of them uses the OpenSSL default which >is /usr/local/ssl and a subdir certs/. The version of OpenSSL distributed by Ubuntu and Debian and by Apple in OS X 10.6 don't use the default, but the build configuration is correctly specified so that OpenSSL can find the certificates in the non-default location. In a perfect world, this is how it would be on all platforms. :) > >The only way to work around this appears to be to call >ctx.load_verify_locations() to point the context to the >right set of trusted certificates. > >I believe that the test should apply such a setup for >the verisign.com certificate authority instead of >relying on a platform provided default setup, ie. use >its own certs/ subdir with the root CA certificates that >are used by verisign.com. The test in question is for ctx.set_default_verify_paths. It does seem very likely that calling ctx.load_verify_locations with a path known to contain the necessary CA certificate would make the test pass, but then it would be testing something else. :) I'll definitely agree that this is not a very good unit test, for a number of reasons. > >In any case, the above test failure is a problem with the test >setup more than anything else. I agree. I think it might make sense to try to determine if the libssl being used was built in a way that could allow the necessary CA cert to be found, and skip the test if it was not. Running "openssl version -d" and checking what's in that directory might be a good heuristic. > >Here's a version of the test which works on OpenSUSE: > >[snip] Any chance you could agitate to have the OpenSUSE build fixed so that ctx.set_default_verify_paths can actually work? :) If all the major platforms had a properly built version of OpenSSL, I think it'd be a lot easier for people to write well-behaved SSL applications. Jean-Paul |
|
From: M.-A. L. <ma...@eg...> - 2010-03-15 21:28:57
|
ex...@tw... wrote: > On 12:04 pm, ma...@eg... wrote: >> M.-A. Lemburg wrote: >>> OpenSSL just released version 0.9.8m where they changed the >>> SSL renegotiation scheme to now follow RFC 5746 instead of >>> just disabling it completely: >>> >>> http://tools.ietf.org/html/rfc5746 >>> >>> pyOpenSSL compiles against the new version without problems, >>> but one of the unit tests fails on Linux x64 (and perhaps >>> other platforms as well): >>>> python OpenSSL/test/test_ssl.py >>> .......E.... >>> ====================================================================== >>> ERROR: test_set_default_verify_paths (__main__.ContextTests) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "OpenSSL/test/test_ssl.py", line 253, in >>> test_set_default_verify_paths >>> clientSSL.do_handshake() >>> Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate >>> verify failed')] >>> >>> ---------------------------------------------------------------------- >>> Ran 12 tests in 0.660s >>> >>> FAILED (errors=1) >>> >>> The test connects to https://verisign.com/ >>> I've tried a few other sites as well, but always get the same >>> error. >> >> I tried the same on Linux x86 with the same results. >> >> I then also checked pyOpenSSL 0.9.0 with OpenSSL 0.9.8l >> and again get the same results. >> >> Perhaps there's something wrong with my test setup ? I've >> done the tests on two different machines. > > This test depends on OpenSSL having been built so that it has access to > the platform-provided CA certificate database. It sounds like your > builds weren't done this way. > > I've never actually built OpenSSL this way myself, and I have very > little idea what is involved in doing so. I know that Ubuntu's OpenSSL > builds have this enabled, but as far as I know none of the other widely > used builds for other platforms do (I've looked at OS X and Windows and > they don't, I'm not sure about other Linux distros). > > Unfortunately I don't have much more info than that about the feature, > so I can't make any suggestions about how to check to see if this is > really the problem, or how to change the build in order to fix it. Thanks for the hint. Here's the full background: http://www.madboa.com/geek/openssl/#verify-system Different OSes place the trusted certificate database files in different places and non of them uses the OpenSSL default which is /usr/local/ssl and a subdir certs/. The only way to work around this appears to be to call ctx.load_verify_locations() to point the context to the right set of trusted certificates. I believe that the test should apply such a setup for the verisign.com certificate authority instead of relying on a platform provided default setup, ie. use its own certs/ subdir with the root CA certificates that are used by verisign.com. In any case, the above test failure is a problem with the test setup more than anything else. Here's a version of the test which works on OpenSUSE: # Arg, verisign.com doesn't speak TLSv1 context = Context(SSLv3_METHOD) #context.set_default_verify_paths() context.load_verify_locations(None, '/etc/ssl/certs') context.set_verify( VERIFY_PEER, lambda conn, cert, errno, depth, preverify_ok: preverify_ok) client = socket() client.connect(('verisign.com', 443)) clientSSL = Connection(context, client) clientSSL.set_connect_state() clientSSL.do_handshake() clientSSL.send('GET / HTTP/1.0\r\n\r\n') self.assertTrue(clientSSL.recv(1024)) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ |
|
From: <ex...@tw...> - 2010-02-26 19:14:15
|
On 07:02 pm, gl...@tw... wrote: >On Feb 26, 2010, at 10:26 AM, ex...@tw... wrote: >>This test depends on OpenSSL having been built so that it has access >>to >>the platform-provided CA certificate database. It sounds like your >>builds weren't done this way. >> >>I've never actually built OpenSSL this way myself, and I have very >>little idea what is involved in doing so. I know that Ubuntu's >>OpenSSL >>builds have this enabled, but as far as I know none of the other >>widely >>used builds for other platforms do (I've looked at OS X and Windows >>and >>they don't, I'm not sure about other Linux distros). > >OS X does; at least, the test passes on Snow Leopard. > >I updated <https://bugs.launchpad.net/pyopenssl/+bug/404343> with the >results of our experiment at the sprint. Oh right. Thanks for the correction. I got confused about versions of things. Jean-Paul |
|
From: <ex...@tw...> - 2010-02-26 16:26:48
|
On 12:04 pm, ma...@eg... wrote: >M.-A. Lemburg wrote: >>OpenSSL just released version 0.9.8m where they changed the >>SSL renegotiation scheme to now follow RFC 5746 instead of >>just disabling it completely: >> >> http://tools.ietf.org/html/rfc5746 >> >>pyOpenSSL compiles against the new version without problems, >>but one of the unit tests fails on Linux x64 (and perhaps >>other platforms as well): >>>python OpenSSL/test/test_ssl.py >>.......E.... >>====================================================================== >>ERROR: test_set_default_verify_paths (__main__.ContextTests) >>---------------------------------------------------------------------- >>Traceback (most recent call last): >> File "OpenSSL/test/test_ssl.py", line 253, in >>test_set_default_verify_paths >> clientSSL.do_handshake() >>Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate >>verify failed')] >> >>---------------------------------------------------------------------- >>Ran 12 tests in 0.660s >> >>FAILED (errors=1) >> >>The test connects to https://verisign.com/ >>I've tried a few other sites as well, but always get the same >>error. > >I tried the same on Linux x86 with the same results. > >I then also checked pyOpenSSL 0.9.0 with OpenSSL 0.9.8l >and again get the same results. > >Perhaps there's something wrong with my test setup ? I've >done the tests on two different machines. This test depends on OpenSSL having been built so that it has access to the platform-provided CA certificate database. It sounds like your builds weren't done this way. I've never actually built OpenSSL this way myself, and I have very little idea what is involved in doing so. I know that Ubuntu's OpenSSL builds have this enabled, but as far as I know none of the other widely used builds for other platforms do (I've looked at OS X and Windows and they don't, I'm not sure about other Linux distros). Unfortunately I don't have much more info than that about the feature, so I can't make any suggestions about how to check to see if this is really the problem, or how to change the build in order to fix it. Jean-Paul |
|
From: M.-A. L. <ma...@eg...> - 2010-02-26 14:11:39
|
M.-A. Lemburg wrote: > OpenSSL just released version 0.9.8m where they changed the > SSL renegotiation scheme to now follow RFC 5746 instead of > just disabling it completely: > > http://tools.ietf.org/html/rfc5746 > > pyOpenSSL compiles against the new version without problems, > but one of the unit tests fails on Linux x64 (and perhaps > other platforms as well): > >> python OpenSSL/test/test_ssl.py > .......E.... > ====================================================================== > ERROR: test_set_default_verify_paths (__main__.ContextTests) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "OpenSSL/test/test_ssl.py", line 253, in test_set_default_verify_paths > clientSSL.do_handshake() > Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')] > > ---------------------------------------------------------------------- > Ran 12 tests in 0.660s > > FAILED (errors=1) > > The test connects to https://verisign.com/ > I've tried a few other sites as well, but always get the same > error. I tried the same on Linux x86 with the same results. I then also checked pyOpenSSL 0.9.0 with OpenSSL 0.9.8l and again get the same results. Perhaps there's something wrong with my test setup ? I've done the tests on two different machines. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 26 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ |
|
From: M.-A. L. <ma...@eg...> - 2010-02-26 13:01:55
|
OpenSSL just released version 0.9.8m where they changed the
SSL renegotiation scheme to now follow RFC 5746 instead of
just disabling it completely:
http://tools.ietf.org/html/rfc5746
pyOpenSSL compiles against the new version without problems,
but one of the unit tests fails on Linux x64 (and perhaps
other platforms as well):
> python OpenSSL/test/test_ssl.py
.......E....
======================================================================
ERROR: test_set_default_verify_paths (__main__.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "OpenSSL/test/test_ssl.py", line 253, in test_set_default_verify_paths
clientSSL.do_handshake()
Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]
----------------------------------------------------------------------
Ran 12 tests in 0.660s
FAILED (errors=1)
The test connects to https://verisign.com/
I've tried a few other sites as well, but always get the same
error.
Any suggestions ?
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 26 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
|
|
From: Erwan L. <erw...@cg...> - 2010-02-02 16:08:05
|
Hello,
I've spent many days in looking for a solution for my problem:
User have smartcard with certificate and private key. They need to
access SSL ressource using their personal certificate as client
certificate for SSL.
With "hard" certificate I have no problem using something like
httplib.HTTPSConnection('monsitessl',443,'mykey.key','mycert.crt')
How can I do it with python ? Is there a way a pyopenssl to do it ? Is
anyone can tell me a way ?
I'm using OpenSC for the PKCS11 lib. (which works pretty well with
Firefox...)
Regards,
--
Erwan
|
|
From: <ex...@tw...> - 2010-01-25 22:19:49
|
On 10:01 pm, ex...@tw... wrote: >On 09:36 pm, ex...@tw... wrote: >>On 22 Jan, 06:24 am, seb...@gm... wrote: >>>Okay, let's try it again ... >>> >>>Could Rick's patch please be included in main? It works great, has >>>test >>>units and applies cleanly. >> >>Can you remind me where this patch is? I think the PKCS12 changes >>this >>thread refers to did land in trunk (in August). I don't remember any >>CRL changes making it in, though. And looking at the open bugs on >>Launchpad, none of them seem to be related. > >Oops. No need for a reminder. This is ><https://bugs.launchpad.net/pyopenssl/+bug/385178> right? I forgot how >to use Launchpad for a minute. Blech. I meant <https://bugs.launchpad.net/pyopenssl/+bug/404436> of course. Jean-Paul |
|
From: <ex...@tw...> - 2010-01-25 22:01:44
|
On 09:36 pm, ex...@tw... wrote: >On 22 Jan, 06:24 am, seb...@gm... wrote: >>Okay, let's try it again ... >> >>Could Rick's patch please be included in main? It works great, has >>test >>units and applies cleanly. > >Can you remind me where this patch is? I think the PKCS12 changes this >thread refers to did land in trunk (in August). I don't remember any >CRL changes making it in, though. And looking at the open bugs on >Launchpad, none of them seem to be related. Oops. No need for a reminder. This is <https://bugs.launchpad.net/pyopenssl/+bug/385178> right? I forgot how to use Launchpad for a minute. Jean-Paul |
5 messages has been excluded from this view by a project administrator.
