Hi,
I believe the minimum was 0.9.8e but the later the better.
It depends on it in a number of ways the most important being:
signature / document verification on unmarshaling
signature generation for marshaling
key verification for metadata extraction
various load/store routines for keys
regards
Bradley
On 14/02/2009, at 6:14 PM, Luke Daley wrote:
> Hey guys,
> Anyone know what the minimum version of OpenSSL that ESOE supports is?
> Out of interest, how is saml2cpp depending on OpenSSL?
> Cheers,
> LD.
Bradley Beddoes
Lead Software Architect
Intient Pty Ltd
I can clarify a little here. We developed against a 0.9.8 version (the
specific version escapes me, but 0.9.8e sounds about right). We currently
have a production SPEP running on Redhat 4 which uses 0.9.7a (not sure if
this has Redhat-specific patches).. So at the least, it is API-compatible
with that version.
As Bradley mentioned, the later the better. I wouldn't be keen on fixing any
bugs that were caused by earlier versions of OpenSSL than 0.9.7.
> Hi,
> I believe the minimum was 0.9.8e but the later the better.
> It depends on it in a number of ways the most important being:
> signature / document verification on unmarshaling
> signature generation for marshaling
> key verification for metadata extraction
> various load/store routines for keys
> regards
> Bradley
> On 14/02/2009, at 6:14 PM, Luke Daley wrote:
> > Hey guys,
> > Anyone know what the minimum version of OpenSSL that ESOE supports is?
> > Out of interest, how is saml2cpp depending on OpenSSL?
On 16/02/2009, at 8:57 AM, Shaun Mangelsdorf wrote:
> I can clarify a little here. We developed against a 0.9.8 version > (the specific version escapes me, but 0.9.8e sounds about right). We > currently have a production SPEP running on Redhat 4 which uses > 0.9.7a (not sure if this has Redhat-specific patches).. So at the > least, it is API-compatible with that version.
> As Bradley mentioned, the later the better. I wouldn't be keen on > fixing any bugs that were caused by earlier versions of OpenSSL than > 0.9.7.
Given that there are quite a few systems that ship with 0.9.7 then it's probably worth stating that as the minimum requirement if possible.
The current autoconf scripts don't check for dependencies at all, leading to compile time errors if dependencies are not satisfied. I would like to gradually make this more rigorous so it's easier to compile this stuff from scratch. The difference being is that ./ configure will give you specific error messages telling you what's wrong rather than make complaining about missing headers or symbols.
> On 16/02/2009, at 8:57 AM, Shaun Mangelsdorf wrote:
>> I can clarify a little here. We developed against a 0.9.8 version >> (the specific version escapes me, but 0.9.8e sounds about right). We >> currently have a production SPEP running on Redhat 4 which uses >> 0.9.7a (not sure if this has Redhat-specific patches).. So at the >> least, it is API-compatible with that version.
>> As Bradley mentioned, the later the better. I wouldn't be keen on >> fixing any bugs that were caused by earlier versions of OpenSSL than >> 0.9.7.
> Given that there are quite a few systems that ship with 0.9.7 then > it's probably worth stating that as the minimum requirement if > possible.
> The current autoconf scripts don't check for dependencies at all, > leading to compile time errors if dependencies are not satisfied. I > would like to gradually make this more rigorous so it's easier to > compile this stuff from scratch. The difference being is that ./ > configure will give you specific error messages telling you what's > wrong rather than make complaining about missing headers or symbols.
Sounds good to me, I am a big fan of things being as rigorous as possible.
Yes I am certain that there is probably a number of issues like this floating around the doco set. Especially in relation to changes between 0.5 and current HEAD. Would be nice to see these maintained/ updated as folks work with the code. If you need an account I can setup for you as can Shaun.
Bradley Beddoes Lead Software Architect Intient Pty Ltd
|
