From mcepl at redhat.com  Tue Oct 13 19:11:04 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Tue, 13 Oct 2009 19:11:04 +0200
Subject: [pyOpenSSL] cannot connect to XMPP server with gajim (using
	pyOpenSSL)
Message-ID: <4AD4B4A8.2010902@redhat.com>

Not sure much what more information is required and how to get it. My 
verbose gajim log is on
http://mcepl.fedorapeople.org/tmp/gajim-log-pyOpenSSL.txt

Unfortunately the server is behind VPN, so you have to tell me whatever 
tests or debugging you need to be done.

Mat?j
-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Besides, the determined Real Programmer can write Fortran
programs in any language.
       -- Ed Post, Real Programmers Don't Use Pascal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3284 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/pyopenssl-users/attachments/20091013/04e4f653/attachment.bin>

From exarkun at twistedmatrix.com  Tue Oct 13 19:21:16 2009
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Tue, 13 Oct 2009 17:21:16 -0000
Subject: [pyOpenSSL] cannot connect to XMPP server with gajim
	(using	pyOpenSSL)
In-Reply-To: <4AD4B4A8.2010902@redhat.com>
References: <4AD4B4A8.2010902@redhat.com>
Message-ID: <20091013172116.11350.820957483.divmod.xquotient.6@localhost.localdomain>

On 05:11 pm, mcepl at redhat.com wrote:
>Not sure much what more information is required and how to get it. My 
>verbose gajim log is on
>http://mcepl.fedorapeople.org/tmp/gajim-log-pyOpenSSL.txt
>
>Unfortunately the server is behind VPN, so you have to tell me whatever 
>tests or debugging you need to be done.

There are some known interoperability issues between OpenSSL and the SSL 
libraries used by some Java XMPP services.  If this is the problem, you 
can work around it by setting the OP_NO_TICKET (0x00004000) option in 
the client.  If this doesn't fix the problem, then I don't have any 
other guesses as to what might be wrong.

Jean-Paul



From mcepl at redhat.com  Wed Oct 14 12:25:52 2009
From: mcepl at redhat.com (=?UTF-8?B?TWF0xJtqIENlcGw=?=)
Date: Wed, 14 Oct 2009 12:25:52 +0200
Subject: [pyOpenSSL] cannot connect to XMPP server with gajim
	(using	pyOpenSSL)
In-Reply-To: <20091013172116.11350.820957483.divmod.xquotient.6@localhost.localdomain>
References: <4AD4B4A8.2010902@redhat.com>
	<20091013172116.11350.820957483.divmod.xquotient.6@localhost.localdomain>
Message-ID: <4AD5A730.9060204@redhat.com>

Dne 13.10.2009 19:21, exarkun at twistedmatrix.com napsal(a):
> There are some known interoperability issues between OpenSSL and the SSL
> libraries used by some Java XMPP services.  If this is the problem, you
> can work around it by setting the OP_NO_TICKET (0x00004000) option in
> the client.  If this doesn't fix the problem, then I don't have any
> other guesses as to what might be wrong.

tcpsock._sslObj.get_context().set_options(OpenSSL.SSL.OP_NO_TICK)

bradford:gajim$ git diff HEAD^1
diff --git a/src/common/xmpp/tls_nb.py b/src/common/xmpp/tls_nb.py
index 5ed1072..e7302a1 100644
--- a/src/common/xmpp/tls_nb.py
+++ b/src/common/xmpp/tls_nb.py
@@ -359,6 +359,7 @@ class NonBlockingTLS(PlugIn):
    tcpsock._sslObj = OpenSSL.SSL.Connection(tcpsock._sslContext,
       tcpsock._sock)
    tcpsock._sslObj.set_connect_state() # set to client mode
+   tcpsock._sslObj.get_context().set_options(OpenSSL.SSL.OP_NO_TICK
    wrapper = PyOpenSSLWrapper(tcpsock._sslObj)
    tcpsock._recv = wrapper.recv
    tcpsock._send = wrapper.send

(indenting got screwed up in the email)

But no observeable change happened.

Mat?j

P.S.: BTW, would it be possible to add this list to gmane.org? I prefer
it much for dealing with email lists.
-- 
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Those to whom evil is done \\ Do evil in return.
    -- W. H. Auden, September 1, 1939
       http://www.poets.org/viewmedia.php/prmMID/15545

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3284 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/pyopenssl-users/attachments/20091014/93eab294/attachment.bin>

From sebvieira at gmail.com  Sun Oct 18 15:45:44 2009
From: sebvieira at gmail.com (Sebastian Vieira)
Date: Sun, 18 Oct 2009 15:45:44 +0200
Subject: [pyOpenSSL] CRL & PKCS12 patch
In-Reply-To: <20090718015501.2543.483943539.divmod.quotient.3198@henry.divmod.com>
References: <4A5BAFCC.5040303@imperial.ac.uk>
	<20090718015501.2543.483943539.divmod.quotient.3198@henry.divmod.com>
Message-ID: <279239c70910180645h70390c30va734d9d4f99f26b0@mail.gmail.com>

Hi,

Is there any progress on this? I mean, will the CRL functionality be in the
next pyOpenSSL release and if so, when will that be? I'm trying to get a
python app into Fedora but while a part of its functionality is based on a
custom patched pyOpenSSL it will probably not be accepted.

Apart from that, it's of course a great feature for pyOpenSSL that will
benefit everyone :)

thanks,

S.

On Sat, Jul 18, 2009 at 3:55 AM, Jean-Paul Calderone <exarkun at divmod.com>wrote:

> On Mon, 13 Jul 2009 23:06:04 +0100, Phil Mayers <p.mayers at imperial.ac.uk>
> wrote:
> >> Looking at <https://code.launchpad.net/pyopenssl>, I see that there are
> >> presently four different branches related to either CRL or PKCS12.
> >>
> >>   lp:~exarkun/pyopenssl/pkcs12-crl
> >>   lp:~arnaud-desmons/pyopenssl/pkcs12
> >>   lp:~rick-fdd/pyopenssl/pkcs12_mod_and_export
> >>   lp:~sebvieira/pyopenssl/pkcs12-crl-0.8
> >
> >I believe at least 3 of those are actually the same patch; numbers 1 &
> >2, and 3 is a forward-port to 0.8
> >
> >My work was just a quick port (again) of the 0.8 branch to the 0.9
> >release code.
>
> Hm, if I'd had my head on straight, I would have pinged Rick (owner of
> branch number 3) and made sure he coordinated with you in this effort.
> Instead, I only just now realized that you and he have some PKCS12
> overlap in the work you're doing.
>
> Looking at his branch (not the one above though, he has since created
> a newer one with a "2" on the end) and yours, I think his PKCS12 code
> is more complete overall.  However, it could still benefit from some of
> the things your version does (you have better type checking code, I
> think).
>
> I'm going to point him at your work along with my other feedback.
>
> Once the PKCS12 stuff is out of the way, I'll dig into the CRL parts
> of your branch more (I've still only just skimmed them).
>
> There is currently a PKCS12 ticket, I see:
>
>  https://bugs.launchpad.net/pyopenssl/+bug/349304
>
> I also now see that there is a ticket which talks about CRLs!  The summary
> didn't make this obvious so I missed/forget about it.  It has a patch
> attached which I haven't looked at at all yet.  The ticket is
>
>  https://bugs.launchpad.net/pyopenssl/+bug/385178
>
> And to keep things interesting, it sounds like it mixes in a bunch of PKCS7
> changes.
>
> > [snip]
> >
> >Do you have C indent preferences?
> >
>
> I wish I did.  I think I'm leaning towards 4 space indents.  However, if
> you're modifying existing code, go with the local prevailing convention.
> I'm trying to keep things consistent, but I'm sure I'm failing at that in
> places.
>
> Apologies again for not pointing out those two tickets in my previous
> message.
>
> Jean-Paul
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> pyopenssl-list mailing list
> pyopenssl-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyopenssl-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pyopenssl-users/attachments/20091018/557154e0/attachment.html>

From exarkun at twistedmatrix.com  Sun Oct 18 18:05:14 2009
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Sun, 18 Oct 2009 16:05:14 -0000
Subject: [pyOpenSSL] CRL & PKCS12 patch
In-Reply-To: <279239c70910180645h70390c30va734d9d4f99f26b0@mail.gmail.com>
References: <4A5BAFCC.5040303@imperial.ac.uk>
	<20090718015501.2543.483943539.divmod.quotient.3198@henry.divmod.com>
	<279239c70910180645h70390c30va734d9d4f99f26b0@mail.gmail.com>
Message-ID: <20091018160514.11571.1080353407.divmod.xquotient.699@localhost.localdomain>

On 01:45 pm, sebvieira at gmail.com wrote:
>Hi,
>
>Is there any progress on this? I mean, will the CRL functionality be in 
>the
>next pyOpenSSL release and if so, when will that be? I'm trying to get 
>a
>python app into Fedora but while a part of its functionality is based 
>on a
>custom patched pyOpenSSL it will probably not be accepted.
>
>Apart from that, it's of course a great feature for pyOpenSSL that will
>benefit everyone :)
>
>thanks,

Hi,

So far, no progress on CRLs in pyOpenSSL.  I just took a quick look at 
the patch attached to https://bugs.launchpad.net/pyopenssl/+bug/385178 - 
just thoroughly enough to see that it is a long way from being ready to 
include in trunk.  Here's a semi-complete list of what I'd like to see 
changes about it:

  * It makes unexplained changes to test_crypto.py; these have nothing to 
do with CRLs and, if important, should be split out into a separate 
patch/branch associated with a new ticket that explains their 
significance.

  * It makes a memory management change to x509.c which is similarly 
unexplained and also untested.  This should have a unit test and 
possibly also be split off onto a separate ticket.

  * It adds get_extension, get_extensions, check_privatekey, verify, 
repr, and str methods to the X509 type.  Also apparently unrelated to 
CRLs.  Also untested.  Aside from str and repr these seem valuable and 
should be added elsewhere, with tests.  Maybe str and repr are good too, 
but I need to be convinced.

  * It adds str and repr methods to the X509Name type.  Also untested and 
unrelated.

  * Likewise for X509Req.

  * There's a bunch of new code in crypto.c about "crypto_ui" and engines 
which looks like it might be neat, but has nothing to do with crls (and 
has no tests).

  * For the new code that's actually x509 crl related:

    * the whitespace is totally crazy and should be cleaned up

    * there are no unit tests.  I am trying to raise pyOpenSSL to 100% 
line coverage.  That means all new code has to have unit tests.

    * the function docstrings all use the weird old style which is more 
aimed at C programmers than Python programmers.  They should be updated 
to be Python programmer friendly.

    * there's code for dealing with asn1 times copied from another 
pyOpenSSL source file; this should be factored into a common file that 
can be re-used, instead of duplicated.


A lot of these things are easy to remedy.  Just delete some of the 
patch.  However, adding the CRL unit tests is probably real work. 
Someone who's familiar with the CRL APIs can probably make a significant 
dent in this without too much trouble.  If someone can do that, I'll 
make time to re-review the new submission and accept it or provide 
further feedback.

Jean-Paul



From rick at fdd.com  Sun Oct 18 21:43:53 2009
From: rick at fdd.com (Rick Dean)
Date: Sun, 18 Oct 2009 14:43:53 -0500
Subject: [pyOpenSSL] CRL & PKCS12 patch
In-Reply-To: <20091018160514.11571.1080353407.divmod.xquotient.699@localhost.localdomain>
References: <4A5BAFCC.5040303@imperial.ac.uk>
	<20090718015501.2543.483943539.divmod.quotient.3198@henry.divmod.com>
	<279239c70910180645h70390c30va734d9d4f99f26b0@mail.gmail.com>
	<20091018160514.11571.1080353407.divmod.xquotient.699@localhost.localdomain>
Message-ID: <20091018194353.GA31150@two.fdd.com>


Sebastian,

Did you look at the patch for CRL that I wrote?
https://bugs.launchpad.net/pyopenssl/+bug/404436
Would it meet your needs?

--
Rick


On Sun, Oct 18, 2009 at 04:05:14PM -0000, exarkun at twistedmatrix.com wrote:
> On 01:45 pm, sebvieira at gmail.com wrote:
> >Hi,
> >
> >Is there any progress on this? I mean, will the CRL functionality be in 
> >the
> >next pyOpenSSL release and if so, when will that be? I'm trying to get 
> >a
> >python app into Fedora but while a part of its functionality is based 
> >on a
> >custom patched pyOpenSSL it will probably not be accepted.
> >
> >Apart from that, it's of course a great feature for pyOpenSSL that will
> >benefit everyone :)
> >
> >thanks,
> 
> Hi,
> 
> So far, no progress on CRLs in pyOpenSSL.  I just took a quick look at 
> the patch attached to https://bugs.launchpad.net/pyopenssl/+bug/385178 - 
> just thoroughly enough to see that it is a long way from being ready to 
> include in trunk.  Here's a semi-complete list of what I'd like to see 
> changes about it:
> 
>   * It makes unexplained changes to test_crypto.py; these have nothing to 
> do with CRLs and, if important, should be split out into a separate 
> patch/branch associated with a new ticket that explains their 
> significance.
> 
>   * It makes a memory management change to x509.c which is similarly 
> unexplained and also untested.  This should have a unit test and 
> possibly also be split off onto a separate ticket.
> 
>   * It adds get_extension, get_extensions, check_privatekey, verify, 
> repr, and str methods to the X509 type.  Also apparently unrelated to 
> CRLs.  Also untested.  Aside from str and repr these seem valuable and 
> should be added elsewhere, with tests.  Maybe str and repr are good too, 
> but I need to be convinced.
> 
>   * It adds str and repr methods to the X509Name type.  Also untested and 
> unrelated.
> 
>   * Likewise for X509Req.
> 
>   * There's a bunch of new code in crypto.c about "crypto_ui" and engines 
> which looks like it might be neat, but has nothing to do with crls (and 
> has no tests).
> 
>   * For the new code that's actually x509 crl related:
> 
>     * the whitespace is totally crazy and should be cleaned up
> 
>     * there are no unit tests.  I am trying to raise pyOpenSSL to 100% 
> line coverage.  That means all new code has to have unit tests.
> 
>     * the function docstrings all use the weird old style which is more 
> aimed at C programmers than Python programmers.  They should be updated 
> to be Python programmer friendly.
> 
>     * there's code for dealing with asn1 times copied from another 
> pyOpenSSL source file; this should be factored into a common file that 
> can be re-used, instead of duplicated.
> 
> 
> A lot of these things are easy to remedy.  Just delete some of the 
> patch.  However, adding the CRL unit tests is probably real work. 
> Someone who's familiar with the CRL APIs can probably make a significant 
> dent in this without too much trouble.  If someone can do that, I'll 
> make time to re-review the new submission and accept it or provide 
> further feedback.
> 
> Jean-Paul
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> pyopenssl-list mailing list
> pyopenssl-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyopenssl-list

-- 
Rick 



From sebvieira at gmail.com  Mon Oct 19 21:36:58 2009
From: sebvieira at gmail.com (Sebastian Vieira)
Date: Mon, 19 Oct 2009 21:36:58 +0200
Subject: [pyOpenSSL] Fwd:  CRL & PKCS12 patch
In-Reply-To: <279239c70910191235s64827314v2d43125da502fcfb@mail.gmail.com>
References: <4A5BAFCC.5040303@imperial.ac.uk>
	<20090718015501.2543.483943539.divmod.quotient.3198@henry.divmod.com>
	<279239c70910180645h70390c30va734d9d4f99f26b0@mail.gmail.com> 
	<20091018160514.11571.1080353407.divmod.xquotient.699@localhost.localdomain>
	<20091018194353.GA31150@two.fdd.com>
	<279239c70910181337t171351u9b4c9eb5aef8e13e@mail.gmail.com> 
	<20091019020645.GA31736@two.fdd.com>
	<279239c70910191235s64827314v2d43125da502fcfb@mail.gmail.com>
Message-ID: <279239c70910191236o2285efb6w405d2304bb99ec0@mail.gmail.com>

Replied only to Rick, but this concerns others as well, i think:

---------- Forwarded message ----------
From: Sebastian Vieira <sebvieira at gmail.com>
Date: Mon, Oct 19, 2009 at 9:35 PM
Subject: Re: [pyOpenSSL] CRL & PKCS12 patch
To: Rick Dean <rick at fdd.com>


Hi Rick,

On Mon, Oct 19, 2009 at 4:06 AM, Rick Dean <rick at fdd.com> wrote:

>
> Yeah, I wrote it before JP merged the modifiable PKCS12 stuff.
> The merge to the tip of trunk was pretty easy and is now posted
> to the bug report.  It passes all the unit tests.
>
> FWIW, the patch included updates to the documentation, and several CRL
> automated test cases make good examples (test/test_crypto.py).
>
> --
> Rick
>
>

Works fine here! I especially like the load_crl() function as this was
something the original patch from Arnaud Desmons lacked. Great help were the
unit tests, so i didn't have to figure out how to 'migrate' my app to this
style of CRL handling.

Great work, and with the unit tests and documentation i think JP will like
it as well :)

regards,

Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pyopenssl-users/attachments/20091019/c6f09a5c/attachment.html>

From p.mayers at imperial.ac.uk  Tue Oct 20 11:55:31 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 20 Oct 2009 10:55:31 +0100
Subject: [pyOpenSSL] Fwd:  CRL & PKCS12 patch
In-Reply-To: <279239c70910191236o2285efb6w405d2304bb99ec0@mail.gmail.com>
References: <4A5BAFCC.5040303@imperial.ac.uk>	<20090718015501.2543.483943539.divmod.quotient.3198@henry.divmod.com>	<279239c70910180645h70390c30va734d9d4f99f26b0@mail.gmail.com>
	<20091018160514.11571.1080353407.divmod.xquotient.699@localhost.localdomain>	<20091018194353.GA31150@two.fdd.com>	<279239c70910181337t171351u9b4c9eb5aef8e13e@mail.gmail.com>
	<20091019020645.GA31736@two.fdd.com>	<279239c70910191235s64827314v2d43125da502fcfb@mail.gmail.com>
	<279239c70910191236o2285efb6w405d2304bb99ec0@mail.gmail.com>
Message-ID: <4ADD8913.9040208@imperial.ac.uk>

> Works fine here! I especially like the load_crl() function as this was 
> something the original patch from Arnaud Desmons lacked. Great help were 
> the unit tests, so i didn't have to figure out how to 'migrate' my app 
> to this style of CRL handling.
> 
> Great work, and with the unit tests and documentation i think JP will 
> like it as well :)

That looks good for me too; I like the API and it works fine in my 
micro-CA application.



From rick at fdd.com  Wed Oct 21 03:43:21 2009
From: rick at fdd.com (Rick Dean)
Date: Tue, 20 Oct 2009 20:43:21 -0500
Subject: [pyOpenSSL] Fwd:  CRL & PKCS12 patch
In-Reply-To: <4ADD8913.9040208@imperial.ac.uk>
References: <4A5BAFCC.5040303@imperial.ac.uk>
	<20090718015501.2543.483943539.divmod.quotient.3198@henry.divmod.com>
	<279239c70910180645h70390c30va734d9d4f99f26b0@mail.gmail.com>
	<20091018160514.11571.1080353407.divmod.xquotient.699@localhost.localdomain>
	<20091018194353.GA31150@two.fdd.com>
	<279239c70910181337t171351u9b4c9eb5aef8e13e@mail.gmail.com>
	<20091019020645.GA31736@two.fdd.com>
	<279239c70910191235s64827314v2d43125da502fcfb@mail.gmail.com>
	<279239c70910191236o2285efb6w405d2304bb99ec0@mail.gmail.com>
	<4ADD8913.9040208@imperial.ac.uk>
Message-ID: <20091021014321.GA24945@two.fdd.com>


Thanks.

--
Rick  :-)

On Tue, Oct 20, 2009 at 10:55:31AM +0100, Phil Mayers wrote:
> > Works fine here! I especially like the load_crl() function as this was 
> > something the original patch from Arnaud Desmons lacked. Great help were 
> > the unit tests, so i didn't have to figure out how to 'migrate' my app 
> > to this style of CRL handling.
> > 
> > Great work, and with the unit tests and documentation i think JP will 
> > like it as well :)
> 
> That looks good for me too; I like the API and it works fine in my 
> micro-CA application.
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> pyopenssl-list mailing list
> pyopenssl-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyopenssl-list