2007/609 Alpine: Mail User Agent

[Darren J Moffat]

James Carlson wrote:
> Darren J Moffat writes:
>> The only way we can "fix" that is if OpenSSL stops breaking ABI (not 
>> just API) compatibility in what we would know as bug fix or patch releases.
> 
> I suspect there's a pretty big difference between depending on the
> OpenSSL published interfaces and depending on the unfiltered guts of
> the implementation.

The problem here though is that the applications using OpenSSL all do so 
for different reasons and at different layers.  Some just use the SSL 
API and do so nicely.  Others use the EVP layer of libcrypto.  There are 
even those that stick their dirty little fingers deep inside the 
structures of the lowest level APIs.

How do we deal with applications in a consolidation different to the one 
OpenSSL is in (currently ON) when the version of OpenSSL changes ?

> It'd be nice if we could at least get a stability commitment for the
> published interfaces, because OpenSSL -- not PKCS#11 -- is _the_
> de-facto standard for dealing with encryption mechanisms.  We're going
> to see many more of these, not fewer, and the idea of having contracts
> for each becomes less plausible with time.

I agree contracts isn't the way to deal with this, but it is the only 
mechanism we have for finding the OpenSSL consumers and contacting them 
when we know that a new version of OpenSSL will cause breakage.

>> They don't do this lightly but it does happen and has happened recently 
>> - this is one of the reasons that an upgrade of OpenSSL version takes so 
>> long.
> 
> For what it's worth, we also obsolete interfaces and then change or
> remove them.  I think the root question here is whether there's notice
> and if there's some way to avoid a broken build.  As long as that
> exists, I don't think the contract helps.

Given that the consumers are spread over (at least) three different 
consolidations of Solaris it isn't an easy task.

>> That is why the ARC contract system is being used it allows the team 
>> that looks after OpenSSL in ONNV to contact all the other consumers and 
>> work with them on version upgrades that may cause issues.
> 
> I'll add a contract if that's what you want to see here, though I
> think it's the wrong way forward.

It is what PSARC wanted when the original case to include OpenSSL was 
reviewed.  The contact is very explicit about which OpenSSL APIs we 
believe the OpenSSL community has some commitment to (the SSL and EVP 
APIs in particular).

Personally I don't mind either way, however without one there is no 
comeback to the OpenSSL team if they introduce an updated version of 
OpenSSL and the build of another project in another consolidation starts 
failing.  That is not to say they won't help debug the issue though.


-- 
Darren J Moffat