[openssl.org #479] support version independent upgrade
No update in nine years, closing this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #479] support version independent upgrade
Actually, I'd prefer that I wouldn't have to relink and redistribute my application every time a security patch comes out for OpenSSL. I haven't seen any issues in our application upgrading from 0.9.6 to 0.9.7 using this non version technique on our local development nodes. The version technique doesn't just prevent backward compatibility but it prevents users from getting potential security upgrades that *may* work just fine. It's definitely not a desirable distribution scenario as it sits now. It forces developers to do relinks and redistribute whether they're needed or not. -Original Message- From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 2:10 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jim Sahaj Subject: Re: [openssl.org #479] support version independent upgrade In message [EMAIL PROTECTED] on Mon, 27 Jan 2003 22:40:24 +0100 (MET), via RT [EMAIL PROTECTED] said: rt Currently, on many Unix platforms I link my application against rt libssl.so and libcrypto.so. Typically, these are links set to resolve rt down to the versioned types of these files, like libssl.so.0.9.7 and rt libcrypto.so.0.9.7. The internal names of these shared objects rt include the major and minor version so even though I link against the rt shared objects without the version, such as libssl.so, my application rt becomes tied to the versioned shared objects at link time, for rt instance libssl.so.0.9.7. There's a reason: until OpenSSL 1, we don't guarantee backward binary compatibility. There are technical reasons for this, like the need to make changes to published structures (it may be argued that it shouldn't be needed, but to achieve such flexibility, we either need to hide them (which would require huge changes for everyone) or redo them in such a way that they become rather generic) and other stuff. Because of this, we're forced to do what we currently do with shared libraries. Perhaps you'd prefer that your applications crash mysteriously and in an unrecoverable manner? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #479] support version independent upgrade
In message [EMAIL PROTECTED] on Mon, 27 Jan 2003 23:33:24 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Actually, I'd prefer that I wouldn't have to relink and rt redistribute my application every time a security patch comes out rt for OpenSSL. I haven't seen any issues in our application rt upgrading from 0.9.6 to 0.9.7 using this non version technique on rt our local development nodes. If all you wanted was security patches, you upgrad to the next patch level of 0.9.6. 0.9.7 contains a lot more changes than just security patches. Also, as a very simple test, I built 0.9.6h and 0.9.7 with shared support, but made sure I linked the 0.9.7 test suite against the 0.9.6h libraries. Then I ran them. Kaboom (I don't recall exactly where, I did it some time ago...). So if *you* haven't had any issues, count your blessings and don't make any changes to your applications. Unfortunately, since it's easily proven that there's a risk of mysterious crashes, we can't support your claim. Sorry. rt The version technique doesn't just prevent backward compatibility rt but it prevents users from getting potential security upgrades rt that *may* work just fine. It's definitely not a desirable rt distribution scenario as it sits now. It forces developers to do rt relinks and redistribute whether they're needed or not. I agree that the current situation isn't optimal for shared libraries. What would you do in our place (and please look outside your particular sandbox, and think of all the reports of mysterious crashes that will flow in to us (which they sometimes do for systems like Windows, where there is no versioning). Basically, place yourself in our shoes). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #479] support version independent upgrade
In message [EMAIL PROTECTED] on Mon, 27 Jan 2003 23:33:24 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt Actually, I'd prefer that I wouldn't have to relink and rt redistribute my application every time a security patch comes out rt for OpenSSL. I haven't seen any issues in our application rt upgrading from 0.9.6 to 0.9.7 using this non version technique on rt our local development nodes. If all you wanted was security patches, you upgrad to the next patch level of 0.9.6. 0.9.7 contains a lot more changes than just security patches. Also, as a very simple test, I built 0.9.6h and 0.9.7 with shared support, but made sure I linked the 0.9.7 test suite against the 0.9.6h libraries. Then I ran them. Kaboom (I don't recall exactly where, I did it some time ago...). So if *you* haven't had any issues, count your blessings and don't make any changes to your applications. Unfortunately, since it's easily proven that there's a risk of mysterious crashes, we can't support your claim. Sorry. rt The version technique doesn't just prevent backward compatibility rt but it prevents users from getting potential security upgrades rt that *may* work just fine. It's definitely not a desirable rt distribution scenario as it sits now. It forces developers to do rt relinks and redistribute whether they're needed or not. I agree that the current situation isn't optimal for shared libraries. What would you do in our place (and please look outside your particular sandbox, and think of all the reports of mysterious crashes that will flow in to us (which they sometimes do for systems like Windows, where there is no versioning). Basically, place yourself in our shoes). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #479] support version independent upgrade
Currently, on many Unix platforms I link my application against libssl.so and libcrypto.so. Typically, these are links set to resolve down to the versioned types of these files, like libssl.so.0.9.7 and libcrypto.so.0.9.7. The internal names of these shared objects include the major and minor version so even though I link against the shared objects without the version, such as libssl.so, my application becomes tied to the versioned shared objects at link time, for instance libssl.so.0.9.7. So, when OpenSSL eventually comes out with security upgrades in a new version, like 0.9.8, I will be forced to relink my application against the new openssl version and redistribute it. Ideally, since I linked against the non versioned openssl shared objects, my users should be able to get the new openssl and rebuild its shared objects and run against those without any involvement from me. Since symbollic links are provided on all Unix platforms please remove the major and minor versions from the internal names of libssl.so and libcrypto.so on these platforms to allow users to upgrade version independent shared objects. I have found this condition on solaris (3264 bit), hpux (32 64 bit), sco5, and unixware7. This will involve changes to Makefile.org. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #479] support version independent upgrade
In message [EMAIL PROTECTED] on Mon, 27 Jan 2003 22:40:24 +0100 (MET), via RT [EMAIL PROTECTED] said: rt Currently, on many Unix platforms I link my application against rt libssl.so and libcrypto.so. Typically, these are links set to resolve rt down to the versioned types of these files, like libssl.so.0.9.7 and rt libcrypto.so.0.9.7. The internal names of these shared objects rt include the major and minor version so even though I link against the rt shared objects without the version, such as libssl.so, my application rt becomes tied to the versioned shared objects at link time, for rt instance libssl.so.0.9.7. There's a reason: until OpenSSL 1, we don't guarantee backward binary compatibility. There are technical reasons for this, like the need to make changes to published structures (it may be argued that it shouldn't be needed, but to achieve such flexibility, we either need to hide them (which would require huge changes for everyone) or redo them in such a way that they become rather generic) and other stuff. Because of this, we're forced to do what we currently do with shared libraries. Perhaps you'd prefer that your applications crash mysteriously and in an unrecoverable manner? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #479] support version independent upgrade
In message [EMAIL PROTECTED] on Mon, 27 Jan 2003 22:40:24 +0100 (MET), via RT [EMAIL PROTECTED] said: rt Currently, on many Unix platforms I link my application against rt libssl.so and libcrypto.so. Typically, these are links set to resolve rt down to the versioned types of these files, like libssl.so.0.9.7 and rt libcrypto.so.0.9.7. The internal names of these shared objects rt include the major and minor version so even though I link against the rt shared objects without the version, such as libssl.so, my application rt becomes tied to the versioned shared objects at link time, for rt instance libssl.so.0.9.7. There's a reason: until OpenSSL 1, we don't guarantee backward binary compatibility. There are technical reasons for this, like the need to make changes to published structures (it may be argued that it shouldn't be needed, but to achieve such flexibility, we either need to hide them (which would require huge changes for everyone) or redo them in such a way that they become rather generic) and other stuff. Because of this, we're forced to do what we currently do with shared libraries. Perhaps you'd prefer that your applications crash mysteriously and in an unrecoverable manner? -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
