pyopenssl-list — General discussion list for users and developers of pyOpenSSL

[pyOpenSSL] Does PKey.generate_key lock the GIL?

[Tobias O. <tob...@ta...>]

I am using PyOpenSSL from within Twisted and want to generate new keys without blocking the Twisted networking.

To do so, I use the deferToThread() Twisted feature, which runs functions on a thread from a background thread pool.

However,

PKey.generate_key

still seems to block everything.

Does above function lock the GIL?

Re: [pyOpenSSL] how to verify integrity of x509 cert

[<ex...@tw...>]

On 03:22 pm, ri...@kd... wrote:
>On Mon, Nov 14, 2011 at 4:00 PM,  <ex...@tw...> wrote:
>>Heya Rich,
>>
>>I wonder if you could file a bug report on Launchpad describing this 
>>new
>>feature. It might help out someone searching for the functionality in
>>the future.
>
>Sure, done. #892522

Thanks!

Jean-Paul

Re: [pyOpenSSL] how to verify integrity of x509 cert

[Richard M. <ri...@kd...>]

On Mon, Nov 14, 2011 at 4:00 PM,  <ex...@tw...> wrote:
> Heya Rich,
>
> I wonder if you could file a bug report on Launchpad describing this new
> feature.  It might help out someone searching for the functionality in
> the future.

Sure, done. #892522

Rich.

Re: [pyOpenSSL] how to verify integrity of x509 cert

[<ex...@tw...>]

On 09:46 am, ric...@gm... wrote:
>On Mon, Nov 14, 2011 at 2:44 AM, Kui Zhang <kui...@gm...> wrote:
>>any way I can do this in pyopenssl ?
>>
>>http://www.jensign.com/JavaScience/IsCertTrusted/index.html
>
>You can't right now. I'm hoping to add it since I know how to
>implement the openssl side of it, but I haven't had time yet.

Heya Rich,

I wonder if you could file a bug report on Launchpad describing this new 
feature.  It might help out someone searching for the functionality in 
the future.

Thanks,
Jean-Paul

Re: [pyOpenSSL] how to verify integrity of x509 cert

[Richard M. <ric...@gm...>]

On Mon, Nov 14, 2011 at 2:44 AM, Kui Zhang <kui...@gm...> wrote:
> any way I can do this in pyopenssl ?
>
> http://www.jensign.com/JavaScience/IsCertTrusted/index.html

You can't right now. I'm hoping to add it since I know how to
implement the openssl side of it, but I haven't had time yet.

Rich.

[pyOpenSSL] how to verify integrity of x509 cert

[Kui Z. <kui...@gm...>]

Hello

any way I can do this in pyopenssl ?

http://www.jensign.com/JavaScience/IsCertTrusted/index.html


thanks
KuiZ

Re: [pyOpenSSL] hit an error while passing python string with embedded NUL byte(s) to OpenSSL.crypto.sign method

[CarSun C <car...@ya...>]

I'm so sorry, you're absolutely right. 0.12 is built-in into my current environment, which I wasn't aware of until recently. You're correct about 0.13 too.

Should have caught that, and should have searched the Bug history more carefully. Anyhow, really appreciate your quick response.

Thanks.
-C


________________________________
From: "ex...@tw..." <ex...@tw...>
To: "pyo...@li..." <pyo...@li...>
Sent: Thursday, October 27, 2011 8:26 PM
Subject: Re: [pyOpenSSL] hit an error while passing python string with embedded NUL byte(s) to OpenSSL.crypto.sign method

On 27 Oct, 11:07 pm, car...@ya... wrote:
> With pyOpenSSL 0.13, passing a python string with embedded NUL byte(s) to crypto.sign method will generate an error saying "must be string without null bytes, not str".
> 
> Initially I thought the API is meant to support C-string (NUL- terminated) only, though it isn't explicitly mentioned in the documentation, above error seems to say so. However, looking into the crypto_sign function (within "crypto.c"), that doesn't seem to be the case, as the format string being used (enclosed below) put a "#" right after BYTESTRING_FMT...
> 
> "O!" BYTESTRING_FMT "#s:sign"
> 
> 
> Unsurprisingly, once I modify the format string to "O!s#s:sign", signing a python string with embedded NUL byte(s) works perfectly fine.
> 
> Am I over looking something? or is this a bug?

This sounds like a bug that was fixed in 0.13:

https://bugs.launchpad.net/pyopenssl/+bug/653830

Can you double check that you observed the problem with that version and not an earlier version?

BYTESTRING_FMT is defined as "s" on Python 2.x, so your change shouldn't have made any difference.  If you were using an older version of pyOpenSSL before, though, and then switched to a custom build based on 0.13, that would explain why it started working (it would have worked without the edit, too).

If this isn't the case, a minimal reproducing example would be nice, perhaps attached to a new bug report in Launchpad.

Thanks,
Jean-Paul


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
pyopenssl-list mailing list
pyo...@li...
https://lists.sourceforge.net/lists/listinfo/pyopenssl-list

Re: [pyOpenSSL] hit an error while passing python string with embedded NUL byte(s) to OpenSSL.crypto.sign method

[<ex...@tw...>]

On 27 Oct, 11:07 pm, car...@ya... wrote:
>With pyOpenSSL 0.13, passing a python string withembedded NUL byte(s) 
>to crypto.sign method will generate an error saying "must be string 
>without null bytes, not str".
>
>Initially I thought the API is meant to support C-string (NUL- 
>terminated) only, though it isn't explicitly mentioned in the 
>documentation, above error seems to say so. However, looking into the 
>crypto_sign function (within "crypto.c"), that doesn't seem to be the 
>case, as the format string being used(enclosed below) put a "#" right 
>afterBYTESTRING_FMT...
>
>"O!" BYTESTRING_FMT "#s:sign"
>
>
>Unsurprisingly, once I modify the format string to "O!s#s:sign", 
>signing a python string with embedded NUL byte(s) works perfectly fine.
>
>Am I over looking something? or is this a bug?

This sounds like a bug that was fixed in 0.13:

  https://bugs.launchpad.net/pyopenssl/+bug/653830

Can you double check that you observed the problem with that version and 
not an earlier version?

BYTESTRING_FMT is defined as "s" on Python 2.x, so your change shouldn't 
have made any difference.  If you were using an older version of 
pyOpenSSL before, though, and then switched to a custom build based on 
0.13, that would explain why it started working (it would have worked 
without the edit, too).

If this isn't the case, a minimal reproducing example would be nice, 
perhaps attached to a new bug report in Launchpad.

Thanks,
Jean-Paul

[pyOpenSSL] hit an error while passing python string with embedded NUL byte(s) to OpenSSL.crypto.sign method

[CarSun C <car...@ya...>]

With pyOpenSSL 0.13, passing a python string with embedded NUL byte(s) to crypto.sign method will generate an error saying "must be string without null bytes, not str".

Initially I thought the API is meant to support C-string (NUL-terminated) only, though it isn't explicitly mentioned in the documentation, above error seems to say so. However, looking into the crypto_sign function (within "crypto.c"), that doesn't seem to be the case, as the format string being used (enclosed below) put a "#" right after BYTESTRING_FMT... 

"O!" BYTESTRING_FMT "#s:sign"


Unsurprisingly, once I modify the format string to "O!s#s:sign", signing a python string with embedded NUL byte(s) works perfectly fine.

Am I over looking something? or is this a bug?

Would appreciate your feedback

- c

Below is the signature of the sign method
sign(key, data, digest)

Re: [pyOpenSSL] Tracking down a change in private key format

[Erinn Looney-T. <eri...@gm...>]

On 10/12/2011 04:59 AM, ex...@tw... wrote:
> On 11 Oct, 10:03 pm, eri...@gm... wrote:
>> I am trying to track down a change in private key format that exists
>> between RHEL 5 and RHEL 6 systems and I believe that pyOpenSSL may be
>> responsible, though I am not sure.
>>
>> RHEL 5 uses pyOpenSSL-0.6-2.el5
>> RHEL 6 uses pyOpenSSL-0.10-2.el6.x86_64
>>
>> It appears that in RHEL 5 private keys were stored in OpenSSL's default
>> PEM format, e.g. starting with:
>> ----BEGIN RSA PRIVATE KEY-----
>> -----END RSA PRIVATE KEY-----
>>
>> In RHEL 6 this seems to have changed (using the same code to call) and
>> the format now appears to use PKCS#8 (for the code call it is an
>> unencrypted key):
>>
>> -----BEGIN PRIVATE KEY-----
>> -----END PRIVATE KEY-----
>>> From OpenSSL's documentation it appears that PKCS#8 is still not the
>> default, so I am unsure as to why this is the format being output. The
>> code in question comes from certmaster: 
>> https://fedorahosted.org/certmaster/
>>
>> The code (identical on RHEL 5 and RHEL 6):
>> def make_keypair(dest=None):
>>    pkey = crypto.PKey()
>>    pkey.generate_key(crypto.TYPE_RSA, 2048)
>>    if dest:
>>        destfd = os.open(dest, os.O_RDWR|os.O_CREAT, 0600)
>>        os.write(destfd, (crypto.dump_privatekey(crypto.FILETYPE_PEM,
>> pkey)))
>>        os.close(destfd)
>>
>>    return pkey
>>
>> Was this formatting change intentional or did it just happen due to 
>> some
>> change in OpenSSL? Just trying to nail down how this change came about,
>> because it ultimately lead to the syslog daemon core dumping as it 
>> tried
>> to load the private key.
> Hiya Erinn,
>
> The formatting change was not intentional.  I think that I noticed it 
> when I was working on OpenSSL 1.0.0 compatibility.  Do you know if RHEL 
> 6 switched to OpenSSL 1.0.0 (or maybe they just back-ported the format 
> change to their version of 0.9.8, which is the sort of thing Debian 
> likes to do)?
>
> I didn't think much of the change when I noticed it, and I didn't expect 
> it to cause problems like the one you're describing, or I might have 
> tried to have pyOpenSSL force the result to be the old format.  Instead, 
> I just made the unit tests work with either format. :/
>
> Jean-Paul
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> pyopenssl-list mailing list
> pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopenssl-list

Yeah RHEL 6 uses openssl-1.0.0-10.el6_1.4.x86_64. So is OpenSSL setting
the default to PKCS#8 now? If so they probably need to update their
documentation.

-Erinn

Re: [pyOpenSSL] Tracking down a change in private key format

[<ex...@tw...>]

On 11 Oct, 10:03 pm, eri...@gm... wrote:
>I am trying to track down a change in private key format that exists
>between RHEL 5 and RHEL 6 systems and I believe that pyOpenSSL may be
>responsible, though I am not sure.
>
>RHEL 5 uses pyOpenSSL-0.6-2.el5
>RHEL 6 uses pyOpenSSL-0.10-2.el6.x86_64
>
>It appears that in RHEL 5 private keys were stored in OpenSSL's default
>PEM format, e.g. starting with:
>----BEGIN RSA PRIVATE KEY-----
>-----END RSA PRIVATE KEY-----
>
>In RHEL 6 this seems to have changed (using the same code to call) and
>the format now appears to use PKCS#8 (for the code call it is an
>unencrypted key):
>
>-----BEGIN PRIVATE KEY-----
>-----END PRIVATE KEY-----
>> From OpenSSL's documentation it appears that PKCS#8 is still not the
>default, so I am unsure as to why this is the format being output. The
>code in question comes from certmaster: 
>https://fedorahosted.org/certmaster/
>
>The code (identical on RHEL 5 and RHEL 6):
>def make_keypair(dest=None):
>    pkey = crypto.PKey()
>    pkey.generate_key(crypto.TYPE_RSA, 2048)
>    if dest:
>        destfd = os.open(dest, os.O_RDWR|os.O_CREAT, 0600)
>        os.write(destfd, (crypto.dump_privatekey(crypto.FILETYPE_PEM,
>pkey)))
>        os.close(destfd)
>
>    return pkey
>
>Was this formatting change intentional or did it just happen due to 
>some
>change in OpenSSL? Just trying to nail down how this change came about,
>because it ultimately lead to the syslog daemon core dumping as it 
>tried
>to load the private key.

Hiya Erinn,

The formatting change was not intentional.  I think that I noticed it 
when I was working on OpenSSL 1.0.0 compatibility.  Do you know if RHEL 
6 switched to OpenSSL 1.0.0 (or maybe they just back-ported the format 
change to their version of 0.9.8, which is the sort of thing Debian 
likes to do)?

I didn't think much of the change when I noticed it, and I didn't expect 
it to cause problems like the one you're describing, or I might have 
tried to have pyOpenSSL force the result to be the old format.  Instead, 
I just made the unit tests work with either format. :/

Jean-Paul

[pyOpenSSL] Tracking down a change in private key format

[Erinn Looney-T. <eri...@gm...>]

I am trying to track down a change in private key format that exists
between RHEL 5 and RHEL 6 systems and I believe that pyOpenSSL may be
responsible, though I am not sure.

RHEL 5 uses pyOpenSSL-0.6-2.el5
RHEL 6 uses pyOpenSSL-0.10-2.el6.x86_64

It appears that in RHEL 5 private keys were stored in OpenSSL's default
PEM format, e.g. starting with:
----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

In RHEL 6 this seems to have changed (using the same code to call) and
the format now appears to use PKCS#8 (for the code call it is an
unencrypted key):

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

>From OpenSSL's documentation it appears that PKCS#8 is still not the
default, so I am unsure as to why this is the format being output. The
code in question comes from certmaster: https://fedorahosted.org/certmaster/

The code (identical on RHEL 5 and RHEL 6):
def make_keypair(dest=None):
    pkey = crypto.PKey()
    pkey.generate_key(crypto.TYPE_RSA, 2048)
    if dest:
        destfd = os.open(dest, os.O_RDWR|os.O_CREAT, 0600)
        os.write(destfd, (crypto.dump_privatekey(crypto.FILETYPE_PEM,
pkey)))
        os.close(destfd)

    return pkey

Was this formatting change intentional or did it just happen due to some
change in OpenSSL? Just trying to nail down how this change came about,
because it ultimately lead to the syslog daemon core dumping as it tried
to load the private key.

Thanks,

-Erinn

[pyOpenSSL] pyOpenSSL 0.13 release

[<ex...@tw...>]

Hello all,

I'm happy to announce the release of pyOpenSSL 0.13.  With this release, 
pyOpenSSL now supports OpenSSL 1.0.  Additionally, pyOpenSSL now works 
with PyPy.

Apart from those two major developments, the following interesting 
changes have been made since the last release:

  * (S)erver (N)ame (I)ndication is now supported.
  * There are now APIs with which the underlying OpenSSL version can be 
queried.
  * The peer's certificate chain for a connection can now be inspected.
  * New methods have been added to PKey and X509 objects exposing more 
OpenSSL functionality.

Release files are available on PyPI.  The latest development version and 
the issue tracker can be found on Launchpad.

Jean-Paul

Re: [pyOpenSSL] [Pyopenssl-users] pyOpenSSL 0.13a1 is here

[Glyph L. <gl...@tw...>]

On Aug 14, 2011, at 7:17 PM, ex...@tw... wrote:

> Hello all,
> 
> Only somewhat behind schedule, I'm happy to announce the first alpha of the 0.13 release.  Highlights since 0.12:
> 
> - Support for OpenSSL 1.0
> - Support for PyPy (mostly)
> - Version information about the underlying libssl is now exposed
> - Several SNI-related APIs are now available
> - A handful of nice data-related bug fixes
> 
> Alpha packages are available at <http://twistedmatrix.com/~exarkun/pyopenssl/>.
> 
> Please give it a try and let me know how it goes!
> 
> Jean-Paul

Thanks Jean-Paul!  I'm especially glad to hear about the SNI features, I'll try them out as soon as I have an opportunity.

-glyph

Re: [pyOpenSSL] [Pyopenssl-users] pyOpenSSL 0.13a1 is here

[Sandro T. <mo...@de...>]

On Mon, Aug 15, 2011 at 01:17,  <ex...@tw...> wrote:
> Please give it a try and let me know how it goes!

I've just uploaded the package to Debian: let's see how the build
machines digest it :)

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

[pyOpenSSL] pyOpenSSL 0.13a1 is here

[<ex...@tw...>]

Hello all,

Only somewhat behind schedule, I'm happy to announce the first alpha of 
the 0.13 release.  Highlights since 0.12:

  - Support for OpenSSL 1.0
  - Support for PyPy (mostly)
  - Version information about the underlying libssl is now exposed
  - Several SNI-related APIs are now available
  - A handful of nice data-related bug fixes

Alpha packages are available at 
<http://twistedmatrix.com/~exarkun/pyopenssl/>.

Please give it a try and let me know how it goes!

Jean-Paul

Re: [pyOpenSSL] pyOpenSSL 0.12a1

[Glyph L. <gl...@tw...>]

On Apr 26, 2011, at 6:17 AM, M.-A. Lemburg wrote:

> Zooko O'Whielacronx wrote:
>> I took the liberty of anonymously quoting MAL and Glyph on
>> https://bugs.launchpad.net/launchpad/+bug/194126 .
> 
> Thanks.
> 
> Just to clarify: I personally don't have a problem
> with doing all the necessary steps to sign up to a Launchpad
> list - I just think that in order to get more people attracted
> to pyOpenSSL, the feedback channel needs to be easy to find,
> open and straight forward to subscribe to.
> 
> To wrap up: should I go ahead and get a python.org list setup
> for the project ?
> 
> Jean-Paul: if you have access to the SF mbox file of the list
> there, we could have that imported to the new python.org list's
> archive.

Personally I'd prefer it if we could use the Launchpad list, so that all the code-hosting facilities are in one place.  I presume that eventually Launchpad's UI will get better (perhaps even as a direct result of the bug linked above) and it will be more obvious how to get on the mailing list; for now, we could just have some clearer text and a link in the project's description.  But a python.org mailing list will forever be an extraneous link hanging off the side, rather than just a part of the facilities that the project offers where it's hosted.

But this is a very mild preference and I will not defend it further than this one message, so please feel free to ignore :).

Re: [pyOpenSSL] pyOpenSSL 0.12a1

[M.-A. L. <ma...@eg...>]

Zooko O'Whielacronx wrote:
> I took the liberty of anonymously quoting MAL and Glyph on
> https://bugs.launchpad.net/launchpad/+bug/194126 .

Thanks.

Just to clarify: I personally don't have a problem
with doing all the necessary steps to sign up to a Launchpad
list - I just think that in order to get more people attracted
to pyOpenSSL, the feedback channel needs to be easy to find,
open and straight forward to subscribe to.

To wrap up: should I go ahead and get a python.org list setup
for the project ?

Jean-Paul: if you have access to the SF mbox file of the list
there, we could have that imported to the new python.org list's
archive.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 26 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/
________________________________________________________________________
2011-06-20: EuroPython 2011, Florence, Italy               55 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/

Re: [pyOpenSSL] pyOpenSSL 0.12a1

[Zooko O'W. <zo...@zo...>]

I took the liberty of anonymously quoting MAL and Glyph on
https://bugs.launchpad.net/launchpad/+bug/194126 .

Regards,

Zooko

Re: [pyOpenSSL] pyOpenSSL 0.12 released

[M.-A. L. <ma...@eg...>]

ex...@tw... wrote:
> On 21 Apr, 10:42 am, ma...@eg... wrote:
>> Zooko O'Whielacronx wrote:
>>> Ugh, look: an advertisement appended to your announcement email. I
>>> hate advertisements. Even more than having to be a "team member" in
>>> order to subscribe to a mailing list.
>>
>> Jean-Paul, should I ask Barry (or one of the other list masters) to
>> create an open pyopenssl list on python.org ?
> 
> I don't really care where the list is.  I figured since the code and
> tickets are on Launchpad it would make sense to host the list there.  I
> don't see why being a "team member" is off-putting; it's not really any
> different from having to create an account with a mailman list.
> 
> If Launchpad is really objectionable, then I don't mind staying on
> sourceforge.  If people really can't stand sourceforge either, then a
> python.org list is fine with me too.

If Launchpad were more geared up for providing a better user
experience, I wouldn't mind having to sign up with them, but
as it stands, finding the mailing is really non-intuitive. Unless
you know that there is a list, you wouldn't even think there is one:
the link to the list only shows up under "Answers" as "Answer Contact"
and page there makes it look like the list is for pyOpenSSL developers
only:

https://launchpad.net/~pyopenssl-users

You'd get a lot more user attention with a list on python.org
which is announced on the python.org list page.

http://mail.python.org/mailman/listinfo

I'd also suggest adding links to the list from the SF page, the
launchpad description and your release emails.

pyOpenSSL certainly deserves more attention in Python land, IMHO.

>>> Also: congratulations on the release and thanks for the work on
>>> pyOpenSSL!
>>
>> Thanks from me as well !
> 
> Thanks. :)
> 
> Jean-Paul

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 23 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/
________________________________________________________________________
2011-06-20: EuroPython 2011, Florence, Italy               58 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/

Re: [pyOpenSSL] pyOpenSSL 0.12 released

[<ex...@tw...>]

On 21 Apr, 10:42 am, ma...@eg... wrote:
>Zooko O'Whielacronx wrote:
>>Ugh, look: an advertisement appended to your announcement email. I
>>hate advertisements. Even more than having to be a "team member" in
>>order to subscribe to a mailing list.
>
>Jean-Paul, should I ask Barry (or one of the other list masters) to
>create an open pyopenssl list on python.org ?

I don't really care where the list is.  I figured since the code and 
tickets are on Launchpad it would make sense to host the list there.  I 
don't see why being a "team member" is off-putting; it's not really any 
different from having to create an account with a mailman list.

If Launchpad is really objectionable, then I don't mind staying on 
sourceforge.  If people really can't stand sourceforge either, then a 
python.org list is fine with me too.
>>Also: congratulations on the release and thanks for the work on 
>>pyOpenSSL!
>
>Thanks from me as well !

Thanks. :)

Jean-Paul

Re: [pyOpenSSL] pyOpenSSL 0.12 released

[M.-A. L. <ma...@eg...>]

Zooko O'Whielacronx wrote:
> Ugh, look: an advertisement appended to your announcement email. I
> hate advertisements. Even more than having to be a "team member" in
> order to subscribe to a mailing list.

Jean-Paul, should I ask Barry (or one of the other list masters) to
create an open pyopenssl list on python.org ?

> Also: congratulations on the release and thanks for the work on pyOpenSSL!

Thanks from me as well !

Time to update our pyOpenSSL distribution again :-)

> Regards,
> 
> Zooko
> 
> On Mon, Apr 11, 2011 at 9:42 PM,  <ex...@tw...> wrote:
>> Exciting news everyone,
> ...
>> http://python.org/pypi/pyOpenSSL - check it out.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 21 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/

Re: [pyOpenSSL] pyOpenSSL 0.12 released

[Zooko O'W. <zo...@zo...>]

Ugh, look: an advertisement appended to your announcement email. I
hate advertisements. Even more than having to be a "team member" in
order to subscribe to a mailing list.

Also: congratulations on the release and thanks for the work on pyOpenSSL!

Regards,

Zooko

On Mon, Apr 11, 2011 at 9:42 PM,  <ex...@tw...> wrote:
> Exciting news everyone,
...
> http://python.org/pypi/pyOpenSSL - check it out.
>
> Jean-Paul
>
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> pyopenssl-list mailing list
> pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopenssl-list
>

[pyOpenSSL] pyOpenSSL 0.12 released

[<ex...@tw...>]

Exciting news everyone,

I have just released pyOpenSSL 0.12.  pyOpenSSL provides Python bindings
to a number of OpenSSL APIs, including certificates, public and private
keys, and of course running TLS (SSL) over sockets or arbitrary in-
memory buffiers.

This release fixes an incompatibility with Python 2.7 involving
memoryviews.  It also exposes the "info callback" constants used to
report progress of the TLS handshake and later steps of SSL connections.
Perhaps most interestingly, it also adds support for inspecting
arbitrary X509 extensions.

http://python.org/pypi/pyOpenSSL - check it out.

Jean-Paul

Re: [pyOpenSSL] pyOpenSSL 0.12a1

[Glyph L. <gl...@tw...>]

On Apr 11, 2011, at 2:31 PM, M.-A. Lemburg wrote:

> 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".

The "team" in this case is PyOpenSSL users, not developers.  Just think of it as Launchpad jargon for a "group".

(Also, file a bug against launchpad for having such confusing jargon.)

> 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.

I am completely neutral on this, I will just join whatever list the maintainer tells me discussion will happen on :).

-glyph