30 ms·

I think a comment like this makes light of the timeframe that ABI/API compatibility has been for the 1.0.0 series. 0.9.8's ABI/API has been floating around sinc

I think a comment like this makes light of the timeframe that ABI/API compatibility has been for the 1.0.0 series. 0.9.8's ABI/API has been floating around since 2005 and 1.0.0's been floating around since 2010- yet major things have been added such as TLS 1.1 and TLS 1.2. The ABI/API of the older versions had eventually become inadequate to describe what modern TLS/crypto applications need to do, and people had just consciously worked around it to dig into structs that they should have never been accessing anyway. Most problems I have fielded regarding this almost always turn out to be things that you never should have been accessing to begin with, but because of necessity people did. If anything this highlights a more general problem with linking strategy against core libraries. There is no ability to add accessors without having a high risk of breaking the universe, and this makes the OpenSSL problem worse because packagers downstream like Debian and RHEL are making a bet against doing nothing and breaking nothing or doing anything and breaking everything.

tedunangst 10y ago
> There is no ability to add accessors without having a high risk of breaking the universe Not sure what you're trying to say. Sure there is. You add the accessors but don't simultaneously convert all structs to opaque types. Accessor functions work just fine on transparent structs, too.
awalton 10y ago
> There is no ability to add accessors without having a high risk of breaking the universe Hogwash. Adding a function doesn't affect existing programs at all. The tricky part is getting people to use the function instead of the field to get the same information. That's the point of introducing the macro around field access: either forcing people to define things in their build to keep things compiling (acknowledging their impending doom and refusing to do anything) or fix their code. If you write the macros in a clever enough way, they'd have to touch every access site to get things building again anyways, so they might as well use accessor functions when they go to port. Then define a hard date in which things are going to break (near enough in the future to call people to action, far enough to actually complete a port if they're trying), and then break as close to that date as you can to both build trust and confidence in the community. (This of course includes feedback; if everyone is saying the port is taking twice as long as planned, adapt your break date.) This is not actually difficult, it just requires software maintainers that care, and a healthy environment of engineers willing to do the work to clean up their software. And it also requires software landfills like Debian and RHEL repos systematically purge software that refuses to update or has zero active upstream maintainers, as it's likely filled with badware, or at the very lease insecureware, anyways. Where OpenSSL breaks down is the healthiness to take these steps; although recovering thanks in a large part on the spotlight placed upon them and the few paltry dollars offered up by various tech companies to maintain the commons, they still haven't caught up to simple practices like these. (I'll partially blame this on fragmentation like LibreSSL and BoringSSL as enabled by software licensing and companies like Apple (and to a lesser extent Amazon, s2n) deciding to abandon public implementations and write their own based on these public ones rather than returning effort to community solutions, but that's a topic for another day when I feel like donning asbestos armor and beating up trolls with cluebats.)

tedunangst 10y ago

> There is no ability to add accessors without having a high risk of breaking the universe Not sure what you're trying to say. Sure there is. You add the accessors but don't simultaneously convert all structs to opaque types. Accessor functions work just fine on transparent structs, too.

awalton 10y ago

> There is no ability to add accessors without having a high risk of breaking the universe Hogwash. Adding a function doesn't affect existing programs at all. The tricky part is getting people to use the function instead of the field to get the same information. That's the point of introducing the macro around field access: either forcing people to define things in their build to keep things compiling (acknowledging their impending doom and refusing to do anything) or fix their code. If you write the macros in a clever enough way, they'd have to touch every access site to get things building again anyways, so they might as well use accessor functions when they go to port. Then define a hard date in which things are going to break (near enough in the future to call people to action, far enough to actually complete a port if they're trying), and then break as close to that date as you can to both build trust and confidence in the community. (This of course includes feedback; if everyone is saying the port is taking twice as long as planned, adapt your break date.) This is not actually difficult, it just requires software maintainers that care, and a healthy environment of engineers willing to do the work to clean up their software. And it also requires software landfills like Debian and RHEL repos systematically purge software that refuses to update or has zero active upstream maintainers, as it's likely filled with badware, or at the very lease insecureware, anyways. Where OpenSSL breaks down is the healthiness to take these steps; although recovering thanks in a large part on the spotlight placed upon them and the few paltry dollars offered up by various tech companies to maintain the commons, they still haven't caught up to simple practices like these. (I'll partially blame this on fragmentation like LibreSSL and BoringSSL as enabled by software licensing and companies like Apple (and to a lesser extent Amazon, s2n) deciding to abandon public implementations and write their own based on these public ones rather than returning effort to community solutions, but that's a topic for another day when I feel like donning asbestos armor and beating up trolls with cluebats.)