search

libressl / portable

LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code. Pull requests or patches sent to tech@openbsd.org are welcome.
https://www.libressl.org
1.37k stars 265 forks source link

Problem to programatically detect stable ABI version numbers #362

Open ncopa opened 7 years ago

ncopa commented 7 years ago

There is a problem for projects supporting libressl that you can not programatically detect which version has stable ABI. Even when doing the work manually, it is confusing. You cannot even tell which versions that are stable just by looking at http://www.libressl.org/releases.html (You can tell that 2.1.5 and later, 2.2.2 and later, 2.3.3 and later are stable, but not which 2.4.x, 2.5.x and 2.6.x is stable)

I believe this is confusing for projects supporting libressl. See for example https://github.com/sfackler/rust-openssl/pull/759

Would it be an idea to switch to a versioning scheme where it is more clear which release is stable and which is development? It would be great if you could tell if a version is stable or not just by looking at the numbers.

Possible solutions:

I am sure there are other options too.

I believe that doing this would make it easier for other projects to support libressl and avoid confusion.

kinichiro commented 6 years ago

Hi, You can check the stable version on http://www.libressl.org/ as "The latest stable release is x.x.x" . And the rule of stable release transition "Support Schedule" on http://www.libressl.org/releases.html . Currently, I think there is no way to detect programatically. How about having library-stable-version.txt in your project ?

4a6f656c commented 6 years ago

@busterb, I agree that this is an issue - is there something that -portable can do to improve this situation?

artkiver commented 1 year ago

Just chiming in here as someone brought this to my attention (I have the somewhat dubious honor of now being listed as a co-maintainer for libressl and libressl-devel within MacPorts) insomuch as: it does appear that Development and Stable releases are rather clearly declared in the ChangeLog (https://github.com/libressl-portable/portable/blob/master/ChangeLog)

However, there are some releases where ambiguity remains, such as those marked "Security release" or "Reliability fix".

It doesn't even seem as if there is a rubric for just the x.x.0 releases as being the only Development releases (e.g. "3.3.2 - Development release", "3.2.1 - Development release").

Admittedly, this may be a little bit of a mismatch between my MacPorts' way of thinking and looking at it insomuch as we want to keep libressl-devel tracking the Development releases, and the standard libressl MacPort tracking the stable releases.

Where releases marked as "Security release" or "Reliability release" may fall I suppose is at our discretion, but we generally would want to keep our intention to be in alignment with the upstream project as we are primarily tracking such things within MacPorts as a convenience to our users, rather than create more work for them.

I guess, if I were to posit some sort of suggestion, it might be to make somewhat explicit with any release whether it is a Development or Stable release (since such a string can presumably be easily grepped) even if it may also be a Security or Reliability release?

Thanks for the consideration one way or another! I realize this issue was opened years ago, but I was only recently made aware of such things, so I hope I am not ruffling any feathers in the process.

busterb commented 1 year ago

Hi, thanks for the question. Once there's a stable release for a given branch, every subsequent release from that branch is also the latest stable release from that branch. It sounds like it would help you if we said something like this when putting out a subsequent stable release on a branch:

https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.5.3-relnotes.txt

We have released LibreSSL 3.5.3 (stable), which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon.

It includes the following reliability fix:

  * Fix d2i_ASN1_OBJECT(). A confusion of two CBS resulted in advancing
    the passed *der_in pointer incorrectly. Thanks to Aram Sargsyan for
    reporting the issue and testing the fix.

The LibreSSL project continues improvement of the codebase to reflect modern,
safe programming practices. We welcome feedback and improvements from the
broader community. Thanks to all of the contributors who helped make this
release possible.

@kinichiro's suggestion from a while ago of a file that just points to the latest stable version isn't hard to do either, if it helps you out.

artkiver commented 1 year ago

Hi, thanks for the question. Once there's a stable release for a given branch, every subsequent release from that branch is also the latest stable release from that branch. It sounds like it would help you if we said something like this when putting out a subsequent stable release on a branch:

https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.5.3-relnotes.txt

We have released LibreSSL 3.5.3 (stable), which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon.

It includes the following reliability fix:

  * Fix d2i_ASN1_OBJECT(). A confusion of two CBS resulted in advancing
    the passed *der_in pointer incorrectly. Thanks to Aram Sargsyan for
    reporting the issue and testing the fix.

The LibreSSL project continues improvement of the codebase to reflect modern,
safe programming practices. We welcome feedback and improvements from the
broader community. Thanks to all of the contributors who helped make this
release possible.

@kinichiro's suggestion from a while ago of a file that just points to the latest stable version isn't hard to do either, if it helps you out.

Ah, thank you for the reply!🙏

I ended up addressing the issue a little bit differently (one example PR that was merged is here: https://github.com/macports/macports-ports/pull/17127 the other is here: https://github.com/macports/macports-ports/pull/17125 )

Basically, MacPorts' livecheck code was enumerating tarballs from an ftp mirror and instead I changed that to look at https://www.libressl.org which prominently displays which are the present stable and development releases thankfully. Using that, I was able to amend the regex a little bit to so it only matches a version number string for the corresponding stable or development release version listed there?

There may be a better way to do it! I don't think the MacPorts infrastructure is quite savvy enough to be branch aware, but I may be mistaken, I am still learning how it functions.

For the time being I think we're good? My apologies for necro-ing this issue, it was linked in the Trac ticket which kind of had me going down a rabbit hole scratching my head not really knowing what to do for a little while until I realized the livecheck parameters were a little more flexible than I realized.

That is, at long as we can expect version numbers and stable/development declarations to continue appearing on the LibreSSL website, which seems plausible? ;)

Thank you!