incorrect OQSPROVIDER_VERSION_TEXT in 0.7.0 release

[jschauma]

Describe the bug
After installing the 0.7.0 release, openssl list -providers shows:

  oqsprovider
    name: OpenSSL OQS Provider
    version: 0.7.1-dev
    status: active

This is due to 60417e9, which erroneously was included in the 0.7.0 release, it seems.

[baentsch]

Hmm -- how did you test this? There was an error in the initial release but when I built right now against tag "0.7.0", the release ID is correct.

[jschauma]

$ curl -L -O https://github.com/open-quantum-safe/oqs-provider/archive/0.7.0.tar.gz
$ md5 0.7.0.tar.gz 
MD5 (0.7.0.tar.gz) = a82cb549c32c118139507f6fa72d7cff
$ tar zxf 0.7.0.tar.gz
$ md5 oqs-provider-0.7.0/CMakeLists.txt 
MD5 (oqs-provider-0.7.0/CMakeLists.txt) = 18613ab96caba07c0dd00bee99f567b7
$ grep OQSPROVIDER_VERSION oqs-provider-0.7.0/CMakeLists.txt 
set(OQSPROVIDER_VERSION_TEXT "0.7.1-dev")

[baentsch]

Ahh, thanks for the description @jschauma . @praveksharma , was there a reason the artifacts of the release didn't get corrected (to also be) in line with the release tag?

[praveksharma]

Thank you for catching this @jschauma. I've fixed this, the artifacts should be correct now. The release notes should also include reflect that. Could you please check again?

@baentsch I am not entirely certain. I believe I followed the same process then that I did right now.

[jschauma]

Yes, confirmed that the release archive now has the right version in it.

However, this brings with it a problem: the release archive was changed, but the version hasn't changed. This will trip up package management systems that verify archives against known checksums (e.g., NetBSD's pkgsrc). It'd be ideal if any time a release archive is changed, its version number changes. So you might e.g., include additional micro numbers or some other signifier to indicate to the user that this is a different archive from the previously published one (e.g., 0.7.0.1 or 0.7.0r1).

[praveksharma]

This will trip up package management systems that verify archives against known checksums (e.g., NetBSD's pkgsrc).

I see, this makes sense. @baentsch should we do a 0.7.2 patch release to avoid this and any other issues that may arrise due to the mistakes made in #534? I say 0.7.2 specifically to avoid the 0.7.0/0.7.1 ambiguity caused by said error.

[jschauma]

Yeah, that would work. I have no strong preference for how you bump versions, but even though this seems like a cosmetic change, it might be easiest to just jump to 0.7.2 and then roll forward with every change.

[iyanmv]

However, this brings with it a problem: the release archive was changed, but the version hasn't changed. This will trip up package management systems that verify archives against known checksums (e.g., NetBSD's pkgsrc). It'd be ideal if any time a release archive is changed, its version number changes. So you might e.g., include additional micro numbers or some other signifier to indicate to the user that this is a different archive from the previously published one (e.g., 0.7.0.1 or 0.7.0r1).

+1 to this comment

I maintain the AUR package for Arch Linux and only now I noticed the checksum mismatch when setting up a new device.

[baentsch]

@praveksharma as you volunteered doing a release fixing this issue, what about doing it now? The latest additions bringing the code in line with the different specs (IANA code points, Composite) IMO justifies, possibly even warrants, a release.

[ghen2]

You may want to hold off a little bit, as IANA will likely still alter the MLKEM codepoints: https://mailarchive.ietf.org/arch/msg/tls/0mVA6kJugR5XhSjqLLhLUActjQM/