From latitia.haskins at GMAIL.COM  Thu Mar  1 20:41:33 2007
From: latitia.haskins at GMAIL.COM (Latitia Haskins)
Date: Thu, 1 Mar 2007 14:41:33 -0500
Subject: [PYTHON-CRYPTO] Execute connect_ssl() twice to connect - is this right?
In-Reply-To: <45E5F0DF.1050303@osafoundation.org>
References: <c35169a20702280645i55a10978td22ed78d9958b852@mail.gmail.com>
            <45E5F0DF.1050303@osafoundation.org>
Message-ID: <c35169a20703011141m210dfff0va9aa06b0d60b0f0b@mail.gmail.com>

My server is based on the demo echod-async.py (echo.py as the client). The
demo currently fails because of bad certificates, but the basic idea looks
like it still applies.

I'm not sure what you find strange about the code, but I want to be very
specific in the context version and cipher combination that I use, so I
initialize some things that I may not have to otherwise.

In my code, if you replace <server.home.com> with localhost and setup a
client before accepting any ssl connections, it should work (in other words,
the client socket needs to be connected before even trying to accept any ssl
connections from the client). Of course, all of this is what makes me think
that I'm simply missing something.


On 2/28/07, Heikki Toivonen <heikki at osafoundation.org> wrote:
>
> Latitia Haskins wrote:
> > I would like to verify some behavior that I observe in my code when I
> > connect a client and server using M2Crypto. I am finding that I have to
>
> I find your code very strange, and the server code does not work for me
> at all. I would advice you to take a look at the test_ssl.py file for
> some guaranteed to work client samples. After that take a look at the
> demos for some more samples, including server samples, but keep in mind
> that the demos may no longer work.
>
> --
>   Heikki Toivonen
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070301/316a966f/attachment.html>

From heikki at OSAFOUNDATION.ORG  Thu Mar  1 22:35:22 2007
From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen)
Date: Thu, 1 Mar 2007 13:35:22 -0800
Subject: [PYTHON-CRYPTO] Execute connect_ssl() twice to connect - is this right?
In-Reply-To: <c35169a20703011141m210dfff0va9aa06b0d60b0f0b@mail.gmail.com>
References: <c35169a20702280645i55a10978td22ed78d9958b852@mail.gmail.com> 
            <45E5F0DF.1050303@osafoundation.org>
            <c35169a20703011141m210dfff0va9aa06b0d60b0f0b@mail.gmail.com>
Message-ID: <45E7471A.7060207@osafoundation.org>

Latitia Haskins wrote:
> I'm not sure what you find strange about the code, but I want to be very
> specific in the context version and cipher combination that I use, so I
> initialize some things that I may not have to otherwise.

I'll reply to that in the next message.

> In my code, if you replace <server.home.com <http://server.home.com>>
> with localhost and setup a client before accepting any ssl connections,
> it should work (in other words, the client socket needs to be connected
> before even trying to accept any ssl connections from the client). Of
> course, all of this is what makes me think that I'm simply missing
> something.

Are you saying the client needs to be connected before the server can be
started? That would make no sense.

-- 
  Heikki Toivonen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070301/054e884a/attachment.pgp>

From heikki at OSAFOUNDATION.ORG  Thu Mar  1 22:36:19 2007
From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen)
Date: Thu, 1 Mar 2007 13:36:19 -0800
Subject: [PYTHON-CRYPTO] Execute connect_ssl() twice to connect - is this right?
In-Reply-To: <c35169a20702280645i55a10978td22ed78d9958b852@mail.gmail.com>
References: <c35169a20702280645i55a10978td22ed78d9958b852@mail.gmail.com>
Message-ID: <45E74753.4090209@osafoundation.org>

I'll quantify what I find strange in the code...

Latitia Haskins wrote:
> #----------- server ----------------
>>>> import M2Crypto
>>>> ss = M2Crypto.SSL.ssl_dispatcher()

I haven't actually used the dispatcher or tested it much or perhaps at
all in the last 3 years.

The test server I have mainly used is echod-eg1.py.

>>>> ss.ssl_ctx = M2Crypto.SSL.Context('tlsv1')
>>>> ss.ssl_ctx.set_cipher_list('ADH-AES128-SHA')
>>>> ss.ssl_ctx.set_tmp_dh('dhparam.pem')
>>>> ss.ssl_ctx.set_tmp_dh_callback()
>>>> ss.ssl_ctx.set_info_callback()

set_info_callback can cause problems in some cases, like multithreaded
programs. I don't think it is a problem here, though.

As an SSL server I would also have expected it to load a server
certificate into the context.

>>>> ss.create_socket(ss.ssl_ctx)
>>>> ss.set_reuse_addr()
>>>> ss.socket.setblocking(0)
>>>> ss.bind(('server.home.com ', 8888))
>>>> ss.listen (5)
>>>> sa = ss.socket.accept()

It seems like a lot of work when SSL.Connection has an accept() method.

> #--------- client -------------------------------
>>>> import M2Crypto
>>>> import socket
>>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>>> ctx = M2Crypto.SSL.Context('tlsv1')
>>>> ctx.set_cipher_list('ADH-AES128-SHA')
>>>> ctx.set_tmp_dh('dhparam.pem')
>>>> ctx.set_tmp_dh_callback()
>>>> ctx.set_info_callback ()
>>>> s = M2Crypto.SSL.Connection(ctx, sock)

Again, I wonder why you create socket separately when
SSL.Connection.__init__ can do it for you.

>>>> s.addr=('server.home.com', 8888)
>>>> s.socket.connect(s.addr)
>>>> s.setup_ssl()
>>>> s.set_connect_state()
>>>> s.setblocking(0)
>>>> s.connect_ssl()

Again seems like a lot of work when SSL.Connection has connect() method.

-- 
  Heikki Toivonen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070301/b219e2b7/attachment.pgp>

From latitia.haskins at GMAIL.COM  Thu Mar  1 23:21:57 2007
From: latitia.haskins at GMAIL.COM (Latitia Haskins)
Date: Thu, 1 Mar 2007 17:21:57 -0500
Subject: [PYTHON-CRYPTO] Execute connect_ssl() twice to connect - is this right?
In-Reply-To: <45E74753.4090209@osafoundation.org>
References: <c35169a20702280645i55a10978td22ed78d9958b852@mail.gmail.com>
            <45E74753.4090209@osafoundation.org>
Message-ID: <c35169a20703011421j73e2836ag56e1cefb07480114@mail.gmail.com>

> >>>> ss.ssl_ctx = M2Crypto.SSL.Context('tlsv1')
> >>>> ss.ssl_ctx.set_cipher_list('ADH-AES128-SHA')
> >>>> ss.ssl_ctx.set_tmp_dh('dhparam.pem')
> >>>> ss.ssl_ctx.set_tmp_dh_callback()
> >>>> ss.ssl_ctx.set_info_callback()
>
> set_info_callback can cause problems in some cases, like multithreaded
> programs. I don't think it is a problem here, though.
>
> As an SSL server I would also have expected it to load a server
> certificate into the context.


I am using anonymous Diffie Hellman (the default is to turn off this
cipher), which only requires the DH parameter file (dhparam.pem), so a
certificate is not necessary at all here. The set_info_callback() was just
so I can verify the handshaking between the server and client. I can remove
it and I still have the same issue.

>>>> ss.create_socket(ss.ssl_ctx)
> >>>> ss.set_reuse_addr()
> >>>> ss.socket.setblocking(0)
> >>>> ss.bind(('server.home.com ', 8888))
> >>>> ss.listen (5)
> >>>> sa = ss.socket.accept()
>
> It seems like a lot of work when SSL.Connection has an accept() method.


I still get the same result either way...

> #--------- client -------------------------------
> >>>> import M2Crypto
> >>>> import socket
> >>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> >>>> ctx = M2Crypto.SSL.Context('tlsv1')
> >>>> ctx.set_cipher_list('ADH-AES128-SHA')
> >>>> ctx.set_tmp_dh('dhparam.pem')
> >>>> ctx.set_tmp_dh_callback()
> >>>> ctx.set_info_callback ()
> >>>> s = M2Crypto.SSL.Connection(ctx, sock)
>
> Again, I wonder why you create socket separately when
> SSL.Connection.__init__ can do it for you.


Except in this case, the peer certificate is verified by default and I have
no interest in verifying the peer certificate - since there isn't one.  So I
do all of the initializing instead of using all of the defaults.

What I mean by client connection, I meant the client socket connecting (with
a regular socket - the "s.socket.connect()"). The client doesn't truly
connect to the server until after the accept is executed and when it does,
it uses SSL. It is very strange.

I initially ran this in linux and today tried it in Windows with a different
result - no need to execute s.connect_ssl() twice! And instead of returning
a result of 0 it actually returns 1. I'm not totally sure what the
difference is between the two. Same exact code, just a different environment
(and build process - that's probably a hint).... If I figure it out, I'll
let you know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070301/fb3e2b7a/attachment.html>

From dclark at POBOX.COM  Fri Mar  2 01:41:31 2007
From: dclark at POBOX.COM (Daniel Clark)
Date: Thu, 1 Mar 2007 19:41:31 -0500
Subject: [PYTHON-CRYPTO] Implementing XML-RPC public key auth with minimal dependencies
Message-ID: <5422d5e60703011641u98d109fv1bca7992701f6d31@mail.gmail.com>

We are having a discussion on the bcfg2-devel mailing list [1] about
the best way to introduce public key authentication into the software.

A big consideration for us is minimizing client dependencies - ideally
all we want to have as dependencies are a Python 2.5 install with
OpenSSL compiled in statically, and the Bcfg2 distribution itself (on
some platforms, we may also try using cx-freeze to remove the Python
requirement).

Currently there is a scheme in use that uses Python's built-in httplib
module [2], which provides encryption, but no certificate
verification, and a shared secret password. We would like to move to a
public key based scheme, so it is not trivial for one client to spoof
another and get information not intended for it.

Does anyone have suggestions as to what the best approach would be?

I was thinking that it might be possible to continue to use httplib
HTTPS for encryption, but then as part of the session negotiate access
with a pure python RSA module (this suffers from the fact I have been
unable to find one of those that is recently maintained, but there was
at least one good candidate [3] the looked like it could be made to
work with recent Python versions with a little bit of work --
currently it goes into infinite recursion).

In general, do people who know much more about cryptology than I do
think that would be a secure solution?

Would it be more vulnerable than SSL or SSH to session hijacking?

[1] RFC: Bcfg2 Security Specification - Discussion Draft 1
http://thread.gmane.org/gmane.comp.sysutils.bcfg2.devel/1608

[2] 18.7 httplib -- HTTP protocol client
http://docs.python.org/lib/module-httplib.html

[3] RSA module for Python
http://www.stuvel.eu/rsa

Thanks for any comments,
-- 
Daniel Clark # http://dclark.us # http://opensysadmin.com


From heikki at OSAFOUNDATION.ORG  Fri Mar  2 02:20:18 2007
From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen)
Date: Thu, 1 Mar 2007 17:20:18 -0800
Subject: [PYTHON-CRYPTO] Implementing XML-RPC public key auth with minimal dependencies
In-Reply-To: <5422d5e60703011641u98d109fv1bca7992701f6d31@mail.gmail.com>
References: <5422d5e60703011641u98d109fv1bca7992701f6d31@mail.gmail.com>
Message-ID: <45E77BD2.5090104@osafoundation.org>

Daniel Clark wrote:
> We are having a discussion on the bcfg2-devel mailing list [1] about
> the best way to introduce public key authentication into the software.
> 
> A big consideration for us is minimizing client dependencies - ideally
> all we want to have as dependencies are a Python 2.5 install with
> OpenSSL compiled in statically, and the Bcfg2 distribution itself (on
> some platforms, we may also try using cx-freeze to remove the Python
> requirement).

Like you have noted, you can't do it with stdlib unless you are willing
to implement most of the stuff yourself. I definitely recommend NOT
doing this, due to it being notoriously difficult to get everything done
correctly. Better use stuff that already works.

If you want to go with minimal dependencies, I would recommend TLS Lite
(http://trevp.net/tlslite/). It has a pure Python implementation of SSL
3.0 and TLS 1.0. It can also use other cryptographic libraries to speed
things up if they are present (m2crypto etc.). Depending on your needs,
the pure Python implementation may be too slow for you. If that is the
case, you may want to go directly to some other library.

If TLS Lite speed is an issue, I would recommend you to check out
M2Crypto (I am the maintainer of that) or pyOpenSSL-extended. Both are
wrappers for OpenSSL. I believe the former wraps more of OpenSSL, but it
does require SWIG to build, which pyOpenSSL-extended does not.

-- 
  Heikki Toivonen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070301/a3748e2d/attachment.pgp>

From redhog at REDHOG.ORG  Thu Mar 15 10:57:22 2007
From: redhog at REDHOG.ORG (=?UTF-8?B?RWdpbCBNw7ZsbGVy?=)
Date: Thu, 15 Mar 2007 10:57:22 +0100
Subject: [PYTHON-CRYPTO] M2Crypto: Loading own cert and key from BIO
Message-ID: <45F91882.2070307@redhog.org>

Hi!
In modern M2Crypto:s (0.1.16) you can load certificates (including CA
cert) to use to verify the peer's cert into a context from e.g. a
database with:

def loadCert(ctx, certDataAsString):
	store = ctx.get_cert_store()
	bio = M2Crypto.BIO.MemoryBuffer()
	bio.write(certDataAsString)
	store.add_x509(M2Crypto.X509.load_cert_bio(bio))

But how do you load your own cert and key from a string, that is, a call
analogous to ctx.load_cert(filename)?

I am developing a peer-to-peer protocol, and would like to store
everything at a node in its database, even the certificate and key for
the node.

Thanks in advance,
Egil M?ller
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redhog.vcf
Type: text/x-vcard
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070315/08d1e1e1/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070315/08d1e1e1/attachment.pgp>

From latitia.haskins at GMAIL.COM  Thu Mar 15 18:52:36 2007
From: latitia.haskins at GMAIL.COM (Latitia Haskins)
Date: Thu, 15 Mar 2007 13:52:36 -0400
Subject: [PYTHON-CRYPTO] M2Crypto: Loading own cert and key from BIO
In-Reply-To: <45F91882.2070307@redhog.org>
References: <45F91882.2070307@redhog.org>
Message-ID: <c35169a20703151052q442bc1c9xf69676caf61972f6@mail.gmail.com>

Hi Egil,

I'm not sure about the version that you listed (typo maybe?). If I am
understanding your question correctly, you want to look at the
load_cert_chain() method in the Context class. It takes the filename where
the certificate is stored.

Latitia

On 3/15/07, Egil M?ller <redhog at redhog.org> wrote:
>
> Hi!
> In modern M2Crypto:s (0.1.16) you can load certificates (including CA
> cert) to use to verify the peer's cert into a context from e.g. a
> database with:
>
> def loadCert(ctx, certDataAsString):
>         store = ctx.get_cert_store()
>         bio = M2Crypto.BIO.MemoryBuffer()
>         bio.write(certDataAsString)
>         store.add_x509(M2Crypto.X509.load_cert_bio(bio))
>
> But how do you load your own cert and key from a string, that is, a call
> analogous to ctx.load_cert(filename)?
>
> I am developing a peer-to-peer protocol, and would like to store
> everything at a node in its database, even the certificate and key for
> the node.
>
> Thanks in advance,
> Egil M?ller
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070315/41f94c6a/attachment.html>

From latitia.haskins at GMAIL.COM  Fri Mar 16 20:57:26 2007
From: latitia.haskins at GMAIL.COM (Latitia Haskins)
Date: Fri, 16 Mar 2007 15:57:26 -0400
Subject: [PYTHON-CRYPTO] Execute connect_ssl() twice to connect - is this right?
In-Reply-To: <c35169a20703011421j73e2836ag56e1cefb07480114@mail.gmail.com>
References: <c35169a20702280645i55a10978td22ed78d9958b852@mail.gmail.com>
            <45E74753.4090209@osafoundation.org>
            <c35169a20703011421j73e2836ag56e1cefb07480114@mail.gmail.com>
Message-ID: <c35169a20703161257q48be49c1pe3640d698442bcdb@mail.gmail.com>

Just in case anyone is interested, this issue is due to the inclusion (or in
the case of linux: the exclusion) of applink.c in openssl. When building
without using applink.c, the same phenomenon takes place in Windows as it
does in Linux. So this is an issue with openssl (and the "need" for
rebuilding python using applink.c) not necessarily m2crypto. Also, as it
turns out, a 1 is finally returned after the 3rd connect_ssl() call. A funky
kludge, but it connects just fine in the end.

On 3/1/07, Latitia Haskins <latitia.haskins at gmail.com> wrote:
>
>
> >>>> ss.ssl_ctx = M2Crypto.SSL.Context('tlsv1')
> > >>>> ss.ssl_ctx.set_cipher_list('ADH-AES128-SHA')
> > >>>> ss.ssl_ctx.set_tmp_dh('dhparam.pem')
> > >>>> ss.ssl_ctx.set_tmp_dh_callback()
> > >>>> ss.ssl_ctx.set_info_callback()
> >
> > set_info_callback can cause problems in some cases, like multithreaded
> > programs. I don't think it is a problem here, though.
> >
> > As an SSL server I would also have expected it to load a server
> > certificate into the context.
>
>
> I am using anonymous Diffie Hellman (the default is to turn off this
> cipher), which only requires the DH parameter file (dhparam.pem), so a
> certificate is not necessary at all here. The set_info_callback() was just
> so I can verify the handshaking between the server and client. I can remove
> it and I still have the same issue.
>
> >>>> ss.create_socket(ss.ssl_ctx)
> > >>>> ss.set_reuse_addr ()
> > >>>> ss.socket.setblocking(0)
> > >>>> ss.bind(('server.home.com ', 8888))
> > >>>> ss.listen (5)
> > >>>> sa = ss.socket.accept ()
> >
> > It seems like a lot of work when SSL.Connection has an accept() method.
>
>
> I still get the same result either way...
>
> > #--------- client -------------------------------
> > >>>> import M2Crypto
> > >>>> import socket
> > >>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> > >>>> ctx = M2Crypto.SSL.Context('tlsv1')
> > >>>> ctx.set_cipher_list('ADH-AES128-SHA')
> > >>>> ctx.set_tmp_dh('dhparam.pem')
> > >>>> ctx.set_tmp_dh_callback()
> > >>>> ctx.set_info_callback ()
> > >>>> s = M2Crypto.SSL.Connection(ctx, sock)
> >
> > Again, I wonder why you create socket separately when
> > SSL.Connection.__init__ can do it for you.
>
>
> Except in this case, the peer certificate is verified by default and I
> have no interest in verifying the peer certificate - since there isn't one.
> So I do all of the initializing instead of using all of the defaults.
>
> What I mean by client connection, I meant the client socket connecting
> (with a regular socket - the "s.socket.connect()"). The client doesn't
> truly  connect to the server until after the accept is executed and when it
> does, it uses SSL. It is very strange.
>
> I initially ran this in linux and today tried it in Windows with a
> different result - no need to execute s.connect_ssl() twice! And instead
> of returning a result of 0 it actually returns 1. I'm not totally sure what
> the difference is between the two. Same exact code, just a different
> environment (and build process - that's probably a hint).... If I figure it
> out, I'll let you know.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070316/b2bcd045/attachment.html>

From bugbee at MAC.COM  Sat Mar 17 06:06:59 2007
From: bugbee at MAC.COM (Larry Bugbee)
Date: Fri, 16 Mar 2007 22:06:59 -0700
Subject: [PYTHON-CRYPTO] Python, Windows, OpenSSL and applink.c      (was Execute connect_ssl() twice...)
In-Reply-To: <PYTHON-CRYPTO%200703170000553210.0583@NIC.SURFNET.NL>
References: <PYTHON-CRYPTO%200703170000553210.0583@NIC.SURFNET.NL>
Message-ID: <DF89DB69-6085-453D-9A1F-9313241B7D3A@mac.com>

> Just in case anyone is interested, this issue is due to the  
> inclusion (or in
> the case of linux: the exclusion) of applink.c in openssl. When  
> building
> without using applink.c, the same phenomenon takes place in Windows  
> as it
> does in Linux. So this is an issue with openssl (and the "need" for
> rebuilding python using applink.c) not necessarily m2crypto.

The applink.c problem was identified on this list last Spring.  I'm  
sad to see another manifestation at this late date.  (This seems to  
be a Windows thingy; I am having no problems under OSX nor do I  
recall problems under Linux.)

Windows versions of Python need to be compiled with applink.c  
included in python.c if Python is to talk to OpenSSL, regardless of  
wrapper.  Attempts to build M2Crypto with applink failed because  
OPENSSL_ApplinkTable etc need to be visible from main().

It sure would be nice to be able to distribute Python/OpenSSL apps  
without having to ask every casual Windows user to recompile Python.   
Does it make sense the distribution versions of python.exe be pre- 
built with applink?  ...conditional to windows only.  Yes?  No?  Does  
compiling in applink cause problems elsewhere?

To whom should this be directed?

See also:
   http://www.openssl.org/support/faq.html#PROG2
   http://svn.python.org/projects/external/openssl-0.9.8a/FAQ

Thanks,

Larry


From dclark at POBOX.COM  Sat Mar 17 17:56:06 2007
From: dclark at POBOX.COM (Daniel Clark)
Date: Sat, 17 Mar 2007 12:56:06 -0400
Subject: [PYTHON-CRYPTO] Python, Windows, OpenSSL and applink.c (was Execute connect_ssl() twice...)
In-Reply-To: <DF89DB69-6085-453D-9A1F-9313241B7D3A@mac.com>
References: <PYTHON-CRYPTO%200703170000553210.0583@NIC.SURFNET.NL>
            <DF89DB69-6085-453D-9A1F-9313241B7D3A@mac.com>
Message-ID: <5422d5e60703170956p17117b1bg110c06c95076bff6@mail.gmail.com>

On 3/17/07, Larry Bugbee <bugbee at mac.com> wrote:
> > Just in case anyone is interested, this issue is due to the
> > inclusion (or in
> > the case of linux: the exclusion) of applink.c in openssl. When
> > building
> > without using applink.c, the same phenomenon takes place in Windows
> > as it
> > does in Linux. So this is an issue with openssl (and the "need" for
> > rebuilding python using applink.c) not necessarily m2crypto.

I think the m2crypto windows distro was also compiled with a different
compiler than Python for Windows, which also caused an
incompatibility.

> The applink.c problem was identified on this list last Spring.  I'm
> sad to see another manifestation at this late date.  (This seems to
> be a Windows thingy; I am having no problems under OSX nor do I
> recall problems under Linux.)
>
> Windows versions of Python need to be compiled with applink.c
> included in python.c if Python is to talk to OpenSSL, regardless of
> wrapper.  Attempts to build M2Crypto with applink failed because
> OPENSSL_ApplinkTable etc need to be visible from main().
>
> It sure would be nice to be able to distribute Python/OpenSSL apps
> without having to ask every casual Windows user to recompile Python.
> Does it make sense the distribution versions of python.exe be pre-
> built with applink?  ...conditional to windows only.  Yes?  No?  Does
> compiling in applink cause problems elsewhere?
>
> To whom should this be directed?
>
> See also:
>    http://www.openssl.org/support/faq.html#PROG2
>    http://svn.python.org/projects/external/openssl-0.9.8a/FAQ
>
> Thanks,
>
> Larry

Just an FYI, for some reason this doesn't seem to be an issue with
Windows and NCrypt; here are my notes from trying to get a bunch of
different Python modules that implement RSA encryption to work on
Windows:

http://tachyon.in/pipermail/ncrypt-users/2007-February/000016.html

-- 
Daniel Clark # http://dclark.us # http://opensysadmin.com


From heikki at OSAFOUNDATION.ORG  Mon Mar 19 21:17:04 2007
From: heikki at OSAFOUNDATION.ORG (Heikki Toivonen)
Date: Mon, 19 Mar 2007 13:17:04 -0700
Subject: [PYTHON-CRYPTO] Python, Windows, OpenSSL and applink.c      (was Execute connect_ssl() twice...)
In-Reply-To: <DF89DB69-6085-453D-9A1F-9313241B7D3A@mac.com>
References: <PYTHON-CRYPTO%200703170000553210.0583@NIC.SURFNET.NL>
            <DF89DB69-6085-453D-9A1F-9313241B7D3A@mac.com>
Message-ID: <45FEEFC0.8080107@osafoundation.org>

Larry Bugbee wrote:
> It sure would be nice to be able to distribute Python/OpenSSL apps
> without having to ask every casual Windows user to recompile Python. 
> Does it make sense the distribution versions of python.exe be pre-built
> with applink?  ...conditional to windows only.  Yes?  No?  Does
> compiling in applink cause problems elsewhere?

Seems like it could cause problems if you are using different version of
OpenSSL than Python was compiled with.

-- 
  Heikki Toivonen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070319/93599f14/attachment.pgp>

From latitia.haskins at GMAIL.COM  Wed Mar 21 14:29:56 2007
From: latitia.haskins at GMAIL.COM (Latitia Haskins)
Date: Wed, 21 Mar 2007 09:29:56 -0400
Subject: [PYTHON-CRYPTO] Python, Windows, OpenSSL and applink.c (was Execute connect_ssl() twice...)
In-Reply-To: <5422d5e60703170956p17117b1bg110c06c95076bff6@mail.gmail.com>
References: <PYTHON-CRYPTO%200703170000553210.0583@NIC.SURFNET.NL>
            <DF89DB69-6085-453D-9A1F-9313241B7D3A@mac.com>
            <5422d5e60703170956p17117b1bg110c06c95076bff6@mail.gmail.com>
Message-ID: <c35169a20703210629pbc155b7vfd7b811f02c45044@mail.gmail.com>

>
> >
> > It sure would be nice to be able to distribute Python/OpenSSL apps
> > without having to ask every casual Windows user to recompile Python.
> > Does it make sense the distribution versions of python.exe be pre-
> > built with applink?  ...conditional to windows only.  Yes?  No?  Does
> > compiling in applink cause problems elsewhere?
> >
>

I think it strange to have this conditional to Windows, but then again
Windows tries to show that it is special wherever it can including making a
pest of itself... Maybe the question is: which is better - to include
applink in all apps regardless of platform as a "fix" to the runtime issues
in Windows or to remove the dependency in Windows and allow applications on
different platforms to work the same? In other words, if applink is built
into python (and any other app), the aforementioned problem goes away, but
in effect applink becomes a sort of IO standard that must be included
whenever building Windows apps using python. Is this desirable?

I was able to make everything work without patching in applink as long as I
built everything with the same compiler and removed the calls from openssl,
but with the side effects described in the previous thread. So this time the
question is, do we limit ourselves on what compiler to use?

Which is the worst evil? To use the same compiler for everything or to use
the same file in different apps? In my case, I'll use the same compiler. I
like things to be consistent regardless of the platform. It makes it easier
to debug. Of course, situations change, and I may think differently in a
different situation...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070321/8d8b49ba/attachment.html>

From dclark at POBOX.COM  Wed Mar 21 15:03:36 2007
From: dclark at POBOX.COM (Daniel Clark)
Date: Wed, 21 Mar 2007 10:03:36 -0400
Subject: [PYTHON-CRYPTO] Python, Windows, OpenSSL and applink.c (was Execute connect_ssl() twice...)
In-Reply-To: <c35169a20703210629pbc155b7vfd7b811f02c45044@mail.gmail.com>
References: <PYTHON-CRYPTO%200703170000553210.0583@NIC.SURFNET.NL>
            <DF89DB69-6085-453D-9A1F-9313241B7D3A@mac.com>
            <5422d5e60703170956p17117b1bg110c06c95076bff6@mail.gmail.com>
            <c35169a20703210629pbc155b7vfd7b811f02c45044@mail.gmail.com>
Message-ID: <5422d5e60703210703n40e6df58s2e2a1c2f37f930f1@mail.gmail.com>

On 3/21/07, Latitia Haskins <latitia.haskins at gmail.com> wrote:
> I think it strange to have this conditional to Windows, but then again
> Windows tries to show that it is special wherever it can including making a
> pest of itself... Maybe the question is: which is better - to include
> applink in all apps regardless of platform as a "fix" to the runtime issues
> in Windows or to remove the dependency in Windows and allow applications on
> different platforms to work the same? In other words, if applink is built
> into python (and any other app), the aforementioned problem goes away, but
> in effect applink becomes a sort of IO standard that must be included
> whenever building Windows apps using python. Is this desirable?

Another question is, how is it that NCrypt (another OpenSSL wrapper)
seems to work fine without applink.c?

-- 
Daniel Clark # http://dclark.us # http://opensysadmin.com


From bugbee at MAC.COM  Thu Mar 22 04:25:06 2007
From: bugbee at MAC.COM (Larry Bugbee)
Date: Wed, 21 Mar 2007 20:25:06 -0700
Subject: [PYTHON-CRYPTO] Python, Windows, OpenSSL and applink.c
In-Reply-To: <PYTHON-CRYPTO%200703200000180390.7742@NIC.SURFNET.NL>
References: <PYTHON-CRYPTO%200703200000180390.7742@NIC.SURFNET.NL>
Message-ID: <13444F37-0CA6-4474-943F-5B3F3EB8B90A@mac.com>

On Mar 19, 2007, at 4:00 PM, PYTHON-CRYPTO automatic digest system  
wrote:

> The 2.4.4 Windows Binary from www.python.org (.msi) doesn't appear  
> to have
> this problem anymore (M2Crypto 0.17), so Guido may be reading this ;o)

Hope springs eternal so I downloaded a fresh copy of  
python-2.4.4.msi.  ...and got the same OPENSSL_Applink error, again.   
Ugh.  Admittedly I used mingw32 (gcc) to compile M2Crypto and that  
may be the problem.  ...which seems odd since mingw32 works nicely  
for a fair number of other extensions.  Is anybody in a position to  
list what build combinations work and which don't?  (I'm not  
equipped; Windows is not my playground.)

I want to distribute Python-OpenSSL apps without asking my users to  
recompile Python.  (They won't have a compiler, nor will they know  
how to use it even if they did.)  A while back we didn't have this  
problem.  ...not until OpenSSL made the change.  Was their decision  
really the right one?  Assuming there are good reasons, is there yet  
another solution that could satisfy both camps?

Thanks,

Larry


From arno=py at CS.VU.NL  Thu Mar 22 09:03:46 2007
From: arno=py at CS.VU.NL (Arno Bakker)
Date: Thu, 22 Mar 2007 09:03:46 +0100
Subject: [PYTHON-CRYPTO] Python, Windows, OpenSSL and applink.c
In-Reply-To: <13444F37-0CA6-4474-943F-5B3F3EB8B90A@mac.com>
References: <PYTHON-CRYPTO%200703200000180390.7742@NIC.SURFNET.NL>
            <13444F37-0CA6-4474-943F-5B3F3EB8B90A@mac.com>
Message-ID: <20070322080346.GD4197@host.few.vu.nl>

> 
> Hope springs eternal so I downloaded a fresh copy of  
> python-2.4.4.msi.  ...and got the same OPENSSL_Applink error, again.   
> Ugh.  Admittedly I used mingw32 (gcc) to compile M2Crypto and that
> may be the problem. 


If I recall correctly, my succesful combinations were (1) python-2.4.4.msi
with the binary release of M2Crypto 0.17 from osafoundation.org and (2)
python-2.4.4.msi and M2Crypto 0.17 compiled with Microsoft Visual Studio 2003.

The latter involved some hacking to link the stuff correctly:
0. Ope Visual Studio Command Prompt
1. Get SWIG to work (set SWIGLIB environment variable)
2. Copy ssleay32MD.lib libeay32MD.lib from C:\OpenSSL\lib\vc to .
3. Run python setup.py build
3. Finish failed link using the following command:

"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe" /DLL /nologo /INCREMENTAL:NO /LIBPATH:c:\openssl\lib /LIBPATH:c:\Python24\libs /LIBPATH:c:\Python24\PCBuild ssleay32MD.lib libeay32MD.lib /EXPORT:init__m2crypto build\temp.win32-2.4\Release\SWIG/_m2crypto_wrap.obj /OUT:build\lib.win32-2.4\M2Crypto\__m2crypto.pyd /IMPLIB:build\temp.win32-2.4\Release\SWIG\__m2crypto.lib /LIBPATH:"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Lib" user32.lib kernel32.lib gdi32.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib imm32.lib winmm.lib wsock32.lib winspool.lib glu32.lib delayimp.lib

I apologize as I don't have the time now to verify these statements again, but
hopefully it will point someone in the right direction.

Regards,	
	Arno Bakker


From jlj.haskins at GMAIL.COM  Thu Mar 22 16:08:08 2007
From: jlj.haskins at GMAIL.COM (Haskins Family)
Date: Thu, 22 Mar 2007 11:08:08 -0400
Subject: [PYTHON-CRYPTO] Python, Windows, OpenSSL and applink.c
In-Reply-To: <13444F37-0CA6-4474-943F-5B3F3EB8B90A@mac.com>
References: <PYTHON-CRYPTO%200703200000180390.7742@NIC.SURFNET.NL>
            <13444F37-0CA6-4474-943F-5B3F3EB8B90A@mac.com>
Message-ID: <2af029e80703220808n27e8d069m1945e18058089115@mail.gmail.com>

>
> Hope springs eternal so I downloaded a fresh copy of
> python-2.4.4.msi.  ...and got the same OPENSSL_Applink error, again.
> Ugh.  Admittedly I used mingw32 (gcc) to compile M2Crypto and that
> may be the problem.

I'm not sure if you're totally committed to Python2.4.4, but I did this
using Python2.5.
1. Install fresh python25.msi
2. Hacked the Configure file
    - remove the -DUSE_OPENSSL_APPLINK flag
3. Hacked the util\pl\VC-32.pl file
    - comment out lines ~205-226 (find "Engage Applink" and remove stuff
upto elsif statement)
4. Build openssl using MSVS 2003
5. Copy fresh libeay32.dll and ssleay32.dll to Windows/system32
6. Copy fresh libeay32.lib and ssleay32.lib to python25/libs/.
7. Build M2Crypto0.17 as normal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070322/4765c341/attachment.html>