AcornSSL date/version number again

Hi folks,

I think we need to re-open discussions of the version number situation on AcornSSL.

I was trying to help a NetFetch tester today, and it got rather ridiculous. Although the module is changing with different mbedTLS versions, both the version number and date in the module header are unchaged.

Needless to say, the customer was baffled – “but they’re both September 2019… I don’t need to update?” came the response. I don’t blame him.

If we can’t agree on version number bumps (or consider whether we should be introducing sub-version support into module versions / rmensure – probably a massive job), then at the very least, the date of the module should be updated when mbedTLS is updated, to indicate that the contents have changed. Basically, if we’re going to be lumbered with lots of different modules with the same base (ie. RISC OS) version number, the least we can try and do is different by date.

As a side note, this also makes it impossible (as far as I can see) for me to RMensure a modern SSL module, or otherwise (easily) report to the user that they’ve forgotten to update.

I guess if the proposed changes for connection re-use come in, that’ll justify a 1.06 version number which will help, but we’ll be having the same conversion a year from now, if we’re not careful.

Personally, I’d advocate bumping the RISC OS version along with the mbedTLS version. After a hundred or so mbedTLS updates (about 10+ years at the current rate of knots) we’ll be around a RISC OS module version of (say) 2.10 – hardly the end of the world. It would make life much easier for coders, and ensure that users are prompted/kicked into staying up-to-date SSL-wise by applications RMensuring the latest AcornSSL at the time of writing.

There’s even room to have a big version number change on AcornSSL when mbedTLS adds a major new TLS level support. Even then, we’d probably only be at (say) version 5.10 of the module!

The easiest solution is to include the MbedTLS library in AcornSSL instead of it being a separate library. That way it is just a part of AcornSSL so an mbedtls update is a AcornSSL update.

If it is just a mbedTLS change why not add a letter at the end e.g #.##A B C etc

The problem is mbedtls is compiled separately to AcornSSL. So someone updates mbedtls and this has the effect of updating AcornSSL but the AcornSSL version number doesn’t change. Adding a letter – which it effectively does by adding the mbedtls version used for the compilation – doesn’t help when you want to RMEnsure the modified version. A separate mbedtls library also has the side effect of when you download AcornSSL to modify you have to also have the latest Disc distribution to get the same mbedtls version used by the existing version otherwise the mbedtls version is old – a problem that bit me recently. It also occurs to me that rolling back to an earlier version of AcornSSL is problematic.

Module version numbers can have 4 digits either side of the decimal point so why not make use of the last 2 digits and so instead of say, 1.04, make it 1.0400 and every time the TLS bit changes bump it to 1.0401 and so on till you get to 1.0499 and then it’s 1.0500.
But as was pointed out last time whilst it will work for RMEnsure it won’t work for Installer.

Personally, I’d advocate bumping the RISC OS version along with the mbedTLS version.

I agree totally. The version and date of a module should be changed whenever its processing changes, whether from main code or an included library which is a significant portion of the module (eg AcornSSL and mbedTLS). I would suggest using the RO normal version of n.nn – as Andrew says, we are not likely to run out!

Then, if an application requires a particular version it is able to RMEnsure it.

If an application does not care about a later version, then there is no need to change any RMEnsure from the lowest it does require.

An application may depend on a change in the AcornSSL RISC OS code, or be particularly vulnerable to a security problem fixed in some mbedTLS change. Currently, it is impossible to ensure the latter. There have been at least 5 different versions of AcornSSL v1.05 (09 Sep 2019) that do not appear in any change logs for AcornSSL.

I understand that AcornSSL is different from other modules in that its code comes from elsewhere. (And that’s the best way to keep it – if we include it in the RISC OS sources, it’s frozen at that version, so we wouldn’t automatically get updates.)

But I disagree with making a special case for its version number and date. Whenever the source code for a module changes, in any way and for any reason, its version number and date must change.

It’s as simple as that. Any other treatment breaks the system we’ve all known for years now.

The differences in sequences between ROL and ROOL modules that have the same names are a red herring, and I hope they will recede into the past, given recent events.

AcornSSL isn’t any different. MBedTLS is in RiscOS.SourcesL.Lib like other libraries which don’t cause a version change when they are modified. SharedCLibrary changes don’t cause a version bump and so on. It is normal for downstream changes not to cause upstream version bumps. What is different is that MBedTLS is the only reason to have AcornSSL. It doesn’t need to be a special case it just needs the library to be part of the AcornSSL git repository where the mbedtls version number becomes meaningless as it becomes an implementation feature of AcornSSL just like any other file in the AcornSSL distribution.

It’s as simple as that. Any other treatment breaks the system we’ve all known for years now.

This. As I’ve been saying for quite a while.

Anything else is asinine stupidity.

The module changes. There are reasons to tell one from another (to ensure the latest is installed, for example) and this unwillingness to bump the version is wilfully breaking the way the OS tells one module version from another.

This behaviour flies in the face of common sense. Different binary = different module = different version. Why is this hard for some people to grasp?

SharedCLibrary changes don’t cause a version bump and so on.

They don’t? Then how come we’re on six-point-something already?

Here’s the one you can read in NetSurf: https://www.riscosopen.org/viewer/view/apache/RiscOS/Sources/Lib/RISC_OSLib/VersionNum

It stops at v6.00.

Here’s the one that might not work on NetSurf: https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/commits/master/VersionNum

There have been four changes (since the change to Git), and… behold, it’s now v6.04.

Different binary = different version. It’s that simple.

The only anomaly here is RISC OS itself, which uses odds for development and evens for stable, which might be understandable otherwise we’d be on RISC OS 87.35 right now, with no way of knowing which versions were denoted as stable.

Otherwise, let me repeat it – different binary = not the same thing = different version. Anything else is broken.

Agreed.

There have been at least 5 different versions of AcornSSL v1.05 (09 Sep 2019)

And one of those was broken…

SharedCLibrary changes don’t cause a version bump and so on.

They don’t?

No, they don’t. None of the C-based ROM apps bump their versions if the SCL gets an update, because they’re not – themselves – being updated.

They don’t? Then how come we’re on six-point-something already?

updating SharedCLib does not cause a version change in every program/module that uses SharedCLibrary similarly with Riscoslib that’s all I’m saying. The same thing happens with MbedTLS.

The easiest solution is to include the MbedTLS library in AcornSSL instead of it being a separate library.

Wasn’t the whole point of the exercise of creating the new AcornSSL to keep mbedTLS separate, so that upstream changes dropped in without any work being required?

Needless to say, the customer was baffled – “but they’re both September 2019… I don’t need to update?” came the response.

This is the bit that I really don’t get. If the user has got so far that they’re looking at the date, they have the mbedTLS version on screen in front of them, just to the right of where they’re reading. It shows up with *Help Modules and *Help AcornSSL.

Wasn’t the whole point of the exercise of creating the new AcornSSL to keep mbedTLS separate, so that upstream changes dropped in without any work being required?

That functionality doesn’t change by dropping the MbedTLS library folder in the AcornSSL folder instead of the Lib folder and compiling it from the AcornSSL makefile and storing it in the AcornSSL repository.

None of the C-based ROM apps bump their versions if the SCL gets an update, because they’re not – themselves – being updated.

Of course not, because they are not changing. The entity known as SharedCLibrary is changing.

Just like the entity known as AcornSSL is changing…

No. if you view them as not changing then AcornSSL is not changing either.

At present MbedTLSLib is its own thing like riscoslib is its own thing. When Mbedtls is changed its version is changed. When the rom is compiled AcornSSL links to the new MbedTLSLib but is unaware of any change and doesn’t have the version modified. Similarly a change to riscoslib results in !edit linking with a new version of riscoslib but doesn’t have the !edit version modified. Similarly When SharedCLib changes it changes every program that uses it but none of them change their version number.

As mentioned above, CLib and Edit are separate things. You can obtain this CLib (with a version number) and that Edit (with a version number) and use them together. It’s how I updated my !Paint to follow the work Andy has been doing (it’s a softload for 3.5).

Conversely, AcornSSL and mbedTLS are the same thing. It doesn’t matter if the sources are here or there or split into infinity parts, the end result is an executable (module) containing all of it. Multiple versions, same version number. This is completely broken.

Thus, your CLib/Edit analogy would only work if Edit was supplied with all of the library built in (ansilib?), and indeed I would hope that if Edit was released with new library components, that it would indeed have a version bump. Although it is less important with Edit as the OS doesn’t provide a mechanism to tell applications apart by version number like it does for modules.

AcornSSL and mbedTLS are the same thing.

We’ll have to agree to differ. It was a riscoslib/edit analogy.

I am not totally convinced on, ‘if the binary changes, then so must the version number’. So a tiny tweak, then another a day later, and voila… We have incremented by 0.02? And what if we upgraded, say, the compiler? Same source, different binary… Different version?!

When we are talking about officially released versions (such as stable ROM images and disc images) then I would expect the black-and-white rule, and version numbers never to be re-usee.

But daily builds, intended for developers or geeks? Really?

At present MbedTLSLib is its own thing like riscoslib is its own thing.

Except they’re behaving differently. At present, when RISC_OSLib is changed, a new CLib gets built with a new version number. However, when mbedTLS is changed, a new AcornSSL gets built with the same version number.

given recent events

Please decode this.

My apologies for the drivel I spoke yesterday.

It was based on the premise that in RISCOS changes to upstream components (libraries) do not cause downstream components (modules/apps which use the library) to change their version number. I have no evidence of this so I may be wrong. It just felt intuitively correct as it needs the modifier of a library to track all components that use that library manually and bump their version number – a process prone to error.

If I am wrong then not updating the version of AcornSSL when mbedtlslib was modified is an oversite. If I’m right then it is the world that we live in hence my suggestion to move mbedtlslib into AcornSSL so that a change in mbedtls results in an AcornSSL version change.

I reserve the right for the above to be drivel too.

Colin – I think the mistake made was associating Clib and RISC_OSlib in one sentence/idea. Clib exists a a shared module (with stubs), separate to any application or code that uses it.

RISC_OSlib is a linkable library that gets embedded into applications, and isn’t shared in any way. Indeed, many people who use(d) it had their own versions of it (sometimes per-application). I know I have several for different purposes with more/less modifications (eg. the HTML syntax colouring that we added to the !edit-engine code that is part of RISC_OSlib), and DataPower uses different versions and so on. Personally, if an embedded library I use changes, I would bump my application version number, because the result is different, and the new library may offer new/better/more-stable functionality. (Obviously this is much less practical/sensible for shared-library approach).

mbedTLS works like RISC_OSlib in this respect, except that the only thing it links to (and likely ever links to) is AcornSSL.

As Rick (I think) said – it’s less important for applications anyway, as there’s no equivalent of RMensure. But, conversely, for users, app versions are more visible.

To answer Richard Walker, I always think in terms of “release version”. This is different to “stable version” (what does that even mean, really – everything has bugs). By “release version” I mean: “if I make it available in any form, so someone may have it, other than me”. In reality, I bump my versions more frequently – once I “complete” (ie. working to my satisfaction) the ideas I have buzzing in my head that I must implement today(ish). That produces a version I could release, even if I don’t necessarily do so. Either way, the idea of being able to make a new build available is key to the version number bump.

So, yes, if it is a different binary, and made available, the version should bump.

Also, in the case of something like AcornSSL, it is particularly important because a key way a developer can enforce security is by ensuring current versions of security modules are installed and used. This is most easily/effectively done via RMensure.

Finally, someone brought up “Installer”. I’m not sure how Installer module works. Can it even cope with AcornSSL’s current version system, or is it just going to say “that’s another 1.05 – we’re up to date”. In other words, would a SysMerge actually even work?