[AG-TECH] AG2.1.2 Certificate Manager with python2.3
Robert Olson
olson at mcs.anl.gov
Wed Jan 21 17:48:38 CST 2004
the summary is basically the pyOpenSSL docs ..
--bob
On Wed, 21 Jan 2004, Ivan R. Judson wrote:
>
> I did get Keith to commit to putting these interfaces in pyGLobus today, so
> if we can get them summarized for Matt he can blow through them next week.
>
> --Ivan
>
> > -----Original Message-----
> > From: Robert Olson [mailto:olson at mcs.anl.gov]
> > Sent: Wednesday, January 21, 2004 5:38 PM
> > To: Christoph Willing
> > Cc: Ivan R. Judson; 'AG-TECH'
> > Subject: RE: [AG-TECH] AG2.1.2 Certificate Manager with python2.3
> >
> > I may reexamine how the extension stuff is done in there;
> > I've been poking around at that code today, as a matter of
> > fact, for a different reason.
> >
> > I'll keep you posted, and will try to reproduce your crash.
> >
> > --bob
> >
> > On Thu, 22 Jan 2004, Christoph Willing wrote:
> >
> > > On Wed, 2004-01-21 at 16:46, Robert Olson wrote:
> > > > are you using openssl 0.9.7 by any chance? this sounds
> > like an open
> > > > issue we have with pyOpenSSL and that version of the openssl libs.
> > > >
> > > > --bob
> > > >
> > >
> > >
> > > On a system with python2.2, we have openssl-0.9.7b and all is OK.
> > >
> > > On a system with python2.3, we have openssl-0.9.7c and
> > Cert. Manager
> > > does a seg fault trying to do:
> > > xext = crypto.X509Extension(name, critical, value) at
> > line 604 of
> > > CertificateRepository.py.
> > >
> > > If I additionally install python2.2 in this second system, then the
> > > Certificate Manager runs OK again. This makes me suspect the python
> > > version.
> > >
> > >
> > >
> > > While googling for possible clues, I came across
> > > http://mail.python.org/pipermail/python-list/2003-July/174843.html
> > > - unhelpful resolution, but that email questions using pyOpenSSL
> > > (where I think the crypto class lives), when the python2.3 socket
> > > module already has SSL support built in.
> > >
> > >
> > > Also, I see in pyOpenSSL_AG-0.5.1/src/utils.h that pymemcompat.h is
> > > included, which is supposed to massage some different python memory
> > > APIs. Could these differing memory APIs still be problem
> > despite the
> > > attempt at compatibility? - the crypto.X509Extension90 call
> > produces a
> > > seg fault...
> > >
> > >
> > > chris
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
More information about the ag-dev
mailing list