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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Rich Salz-3
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

Thanks.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Timo Teras
On Tue, 3 Feb 2015 17:02:31 -0500
Rich Salz <[hidden email]> 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.

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?

Thanks,
Timo
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Matt Caswell-2


On 04/02/15 06:51, Timo Teras wrote:

> On Tue, 3 Feb 2015 17:02:31 -0500
> Rich Salz <[hidden email]> 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

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Salz, Rich
In reply to this post by Timo Teras

> Not sure if my questions are already answered. But I'll go ahead and ask
> them...

All excellent questions.  As Matt said, we don't know yet.

> Or would there be the "public headers" for applications? And than the
> "private headers" for version bound extensions that need to access the
> internals?

Yes, a service-provider interface is common.  I would be surprised if we get something that covers all desired extensibility points in the first release. I would think ENGINE is the most likely first one.  Yes, this means that adding new algorithms, etc., might become harder or even not possible without source code, at first. But that is just my opinion and maybe I'll be proven wrong.

What extensibility points are most needed?
 
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Richard Moore
In reply to this post by Rich Salz-3


On 3 February 2015 at 22:02, Rich Salz <[hidden email]> 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

I've documented what got broken in Qt by the changes so far. I've listed the functions I think we can use instead where they exist, and those where there does not appear to be a replacement.

Cheers

Rich.
 

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Matt Caswell-2


On 07/02/15 14:41, Richard Moore wrote:

>
>
> On 3 February 2015 at 22:02, Rich Salz <[hidden email]
> <mailto:[hidden email]>> 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
>
>
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.

On the wiki you wrote:
"session->tlsext_tick_lifetime_hint - we were directly accessing the
lifetime hint of the session."

I have just pushed (along with some associated documentation) some new
ticket API functions, which should cover the above gap:

int SSL_SESSION_has_ticket(const SSL_SESSION *s);
unsigned long SSL_SESSION_get_ticket_lifetime_hint(const SSL_SESSION *s);
void SSL_SESSION_get0_ticket(const SSL_SESSION *s, unsigned char **tick,
                             size_t *len);


Matt

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Richard Moore


On 10 February 2015 at 23:01, Matt Caswell <[hidden email]> wrote:
On the wiki you wrote:
"session->tlsext_tick_lifetime_hint - we were directly accessing the
lifetime hint of the session."

I have just pushed (along with some associated documentation) some new
ticket API functions, which should cover the above gap:

int SSL_SESSION_has_ticket(const SSL_SESSION *s);
unsigned long SSL_SESSION_get_ticket_lifetime_hint(const SSL_SESSION *s);
void SSL_SESSION_get0_ticket(const SSL_SESSION *s, unsigned char **tick,
                             size_t *len);


Great - I'll port the code to use those when building against 1.1 then with the fixes I've already made Qt dev branch should build fine against the current master. I've also updated the wiki to note what got broken in curl and wget BTW (only one breakage in each AFAIK).

Cheers

Rich.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev