[openssl-dev] The evolution of the 'master' branch

[Matt Caswell]

On 04/02/15 06:51, Timo Teras wrote:
> On Tue, 3 Feb 2015 17:02:31 -0500
> Rich Salz <rsalz at openssl.org> wrote:
> 
>> As we've already said, we are moving to making most OpenSSL data
>> structures opaque. We deliberately used a non-specific term. :)
>> As of Matt's commit of the other day, this is starting to happen
>> now.  We know this will inconvenience people as some applications
>> no longer build.  We want to work with maintainers to help them
>> migrate, as we head down this path.
>>
>> We have a wiki page to discuss this effort.  It will eventually
>> include tips on migration, application and code updates, and anything
>> else the community finds useful.  Please visit:
>>
>> 	http://wiki.openssl.org/index.php/1.1_API_Changes
> 
> Not sure if my questions are already answered. But I'll go ahead and
> ask them...
> 
> Which structures this includes? I'm thinking application level
> extensibility.

At the moment in master this includes all libssl structures, and bn
structures in libcrypto. My expectation is that this will be extended to
"most" structures in libcrypto too.

> 
> If I have a custom cipher implementation, and it requires shipping
> EVP_CIPHER (which is basically virtual ops table). Is that planned to
> be opaque too? Or it gets a set of accessors?
> 
> How would off-tree engine modules be implemented? Or is their
> integration possibilities limited?
> 
> Or would there be the "public headers" for applications? And than the
> "private headers" for version bound extensions that need to access the
> internals?

The general approach is to make structures opaque and provide accessors
where they don't already exist. For the examples you have cited,
unfortunately, that comes under the category of TBD. We haven't yet
decided how that will be done - so I'm happy to hear any opinions on how
it should be tackled.

Matt