Re: [openssl-dev] The evolution of the 'master' branch
On 10 February 2015 at 23:01, Matt Caswell m...@openssl.org 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
Re: [openssl-dev] The evolution of the 'master' branch
On 07/02/15 14:41, Richard Moore wrote: On 3 February 2015 at 22:02, Rich Salz rs...@openssl.org mailto:rs...@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 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
Re: [openssl-dev] The evolution of the 'master' branch
On 3 February 2015 at 22:02, Rich Salz rs...@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 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
Re: [openssl-dev] The evolution of the 'master' branch
On 3 February 2015 at 22:02, Rich Salz rs...@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 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
Re: [openssl-dev] The evolution of the 'master' branch
On 04/02/15 06:51, Timo Teras wrote: On Tue, 3 Feb 2015 17:02:31 -0500 Rich Salz rs...@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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] The evolution of the 'master' branch
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
[openssl-dev] The evolution of the 'master' branch
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
Re: [openssl-dev] The evolution of the 'master' branch
On Tue, 3 Feb 2015 17:02:31 -0500 Rich Salz rs...@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. 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
