AcornSSL module version?
Pages: 1 2
Martin Avison (27) 1491 posts |
I think there is what should be considered a bug in the AcornSSL module build process, because the module version and date are not changed when the module contents change only because the mbedTLS library has changed. For example: So much of RISC OS operation depends on the version number being used in *RMEnsure commands and other checks, which cannot be used if this continues. As the base module code stabilises, probably the only changes will be mbedTLS ones. What makes it worse is that the new modules generated because of mbedTLS library changes do not get listed in the ‘Recent changes’, or even in the AcornSSL module history at all. While it is undoubtedly a massive improvement that mbedTLS changes can now be incorporated into RISC OS so quickly, please can the changes be made more obvious, both to us and to our machines? |
nemo (145) 2538 posts |
It is perfectly feasible to have module versions 1.041, 1.042, 1.043 etc. |
Steve Pampling (1551) 8164 posts |
Or even 2.160, 2.161, 2.162, 2.163 etc See what I did there? |
Martin Avison (27) 1491 posts |
I suspect that using n.nnn version numbers may cause other problems? Would RMEnsure still work? I think the Style Guide says n.nn should be used, but I do not have mine with me to check. Using the mbedTLS version would solve the static version when mbedTLS changed … but the rest of the module may also change without mbedTLS changing, as they did between v1.04 and v1.05 for a bug fix. And is the mbedTLS version guaranteed to only be n.nn.n, or could it be n.nn.nn? So I am afraid neither suggestion would get my vote! |
Rick Murray (539) 13817 posts |
If it changes, it’s not the same module. It doesn’t matter which bit changes, it is not the same module. Bump the version number. It is not the same module, it should not have the same version. <mic drop> |
Rick Murray (539) 13817 posts |
The DDE PDF version doesn’t mention RMEnsure at all. However PRM1, in describing the module header, says: The version number contains three digits and a full stop, eg ‘1.00’. Therefore:
Can this be demonstrated as working on all releases of RISC OS (save 2.xx)? Edit – yes. https://www.riscosopen.org/viewer/view/apache/RiscOS/Sources/Kernel/s/MoreComms?rev=4.8#l574 Looks like the code is quite capable of dealing with 1234.5678 as a version number, so that ought to cover however many mbedtls incarnations happen in the lifetime of RISC OS. |
Dave Higton (1515) 3503 posts |
It’s just a number. Tradition and documentation both have two digits following the dot. There is NO reason to invent a different system for AcornSSL. NO reason AT ALL. |
Chris Mahoney (1684) 2165 posts |
Doubly so when the mbedTLS version is already listed alongside the module version when you do *Help Modules! |
Steve Pampling (1551) 8164 posts |
So, RMEnsure and such can identify the difference then? To quote Rick in Nemo mode:
As to “Tradition and documentation” being a reason not to use clear distinction of ‘minor’ changes – phfft. |
Frank de Bruijn (160) 228 posts |
No. Only the user can, by looking at the *Help Modules output. RMEnsure only uses the module version. |
Chris Mahoney (1684) 2165 posts |
No, but it shouldn’t need to. What I was attempting to say is that AcornSSL should follow normal module versioning (i.e. new version = increment the number) rather than doing anything special. In that case, RMEnsure will work just like it always does. Along the same lines, I was also trying to dissuade “encoding” the mbedTLS version number in the module version number. If you, the user, need to know which version of mbedTLS it’s using then you can run *Help Modules. |
Dave Higton (1515) 3503 posts |
All you need to know is whether it’s the same or different. The established numbering system does that perfectly well. |
Dave Higton (1515) 3503 posts |
If a bug is fixed, it makes no difference whatsoever whether it was in mbedTLS or the RISCOSification code. Code change = change in behaviour = increment the version number. Simple as that. |
Jeffrey Lee (213) 6048 posts |
If SysMerge can’t detect that a new AcornSSL version needs installing, then that’s a major problem. There’s no point regularly incorporating mbedTLS bug/security fixes into AcornSSL if the new module can’t automatically be rolled out to users. Easiest solution would probably be to have AcornSSL refuse to build if the mbedTLS version doesn’t match the expected version. That way, whenever mbedTLS changes, we’d also be forced to change the “expected version” that’s in the AcornSSL sources, which will in turn trigger the usual .01 increment in AcornSSL version number. |
Sprow (202) 1155 posts |
At time of writing, the mbedTLS changes are 3rd in the list.
Conceptually I don’t see this as being different to when a bug in the C library gets fixed, we don’t bump all the C modules up by 0.01 for that. Likewise RISC_OSLib gets tickled which results in a bug fix to any components it gets used in (eg. MakeModes, Edit, etc). Same when a compiler bug is fixed – a whole new set of modules appear, possibly different binaries (if they happened to trigger whatever bug it was) but same versions. We also have several copies of the FPEmulator and Wimp in !System, all for different targets but same versions. The key bit is, from your application’s point of view, the AcornSSL module still matches the minimum criteria (SWI/API-wise) of the RMEnsure so it should be fully compatible.
Unfortunately because of the way the decimal counting system works that’d come unstuck resolving 2.123 whether that was 2.1.23 or 2.12.3
Furthermore, you shouldn’t assume mbedTLS will always be the supporting library. It wasn’t for AcornSSL 0.xx which used OpenSSL, and looks like ARM are mulling rebranding it in future too.
Fortunately Ben (dammit when he’s right!) had the foresight to catch this exact case in Installer as far back as 1998. In the event of a tie for version numbers the newer date (stamp of the file) breaks the tie – hence any newer release of AcornSSL will always overwrite the existing. |
Jeffrey Lee (213) 6048 posts |
That’s better than nothing, but I wouldn’t say it’s a cast-iron solution. It’s too easy for file timestamps to be lost or misleading. |
Steve Pampling (1551) 8164 posts |
Or even be changed by a user action using existing facilities in the Filer Let’s just re-iterate the Nemo mode comment from Rick
|
nemo (145) 2538 posts |
Martin worried
Starts like a statement and ends like a question. Not for the OS. Possibly for anyone who invented their own restrictions on version numbers based on what they thought they could see. RO is not immune to cargo cult programming.
Yes. Of course.
Do you see what I mean about the historical quality of RO documentation? Risible. Dave demanded
Nobody has invented a new system. Just clarified the one you misunderstood. Confirmation bias is a terrible thing. For the avoidance of doubt, the definitive statement is: Module version numbers are 16.16 binary coded decimal numbers.Please forward all further confusion on the matter to OS_Module 20 or every implementation of EMEnsure since RISC OS 2. |
Andrew Rawnsley (492) 1444 posts |
By which yardstick perhaps the best version numbering for AcornSSL would probably be: (riscos-specific-build-number).(mbedtls-build-number) eg. 5.2163 However, I see this falling apart when mbedtls exceeds 4 digits eg. 2.16.13. Actually that’d probably be OK, because 16bits should give us 65535 numbers. But then perhaps 7.16.13 would be an issue. Nemo, am I being thick? |
nemo (145) 2538 posts |
You’ve missed the BCD bit, so it’s 10,000 not 65,536 Module version numbers are 0.0000 to 9999.9999, and be careful about signed/unsigned at the top end.
An excerpt from OSCommands 0.13 (01 Dec 2003) FSCommands 0.061 (04 Sep 2019) © nemo 2019 (portions) ModuleCommands 0.08 (08 Jan 2004) ... HostFS 0.62 (01 May 2004) © Graeme Barnes HostFSFiler 0.071 (11 Aug 2019) © Graeme Barnes 2009, © nemo 2009-2018 Internet 6.11 (17 Jul 2004) for Virtual Acorn © Graeme Barnes ... SpriteUtils 1.19 (02 Dec 2003) SuperSample 2.002 (30 Dec 2017) © nemo 2017 (portions) System Devices 1.28 (03 Dec 2003) TaskWindow 0.76 (04 Dec 2003) Window Utils 2.51 (04 Dec 2003) Filter Manager 0.261 (04 Dec 2003) © nemo 2018 (portions) WaveSynth 1.16 (01 Dec 2003) ... ROMPatch 0.14 (15 Mar 2004) CallASWI 0.051 (27 May 2010) SyncClock 0.10 (27 Feb 2002) ZeroCLI 0.02 (25 Jan 2011) © nemo 2011 Deep Key Buffer 2.08 (14 Feb 2004) © Cerilica 1999-2004 Auto CLI space 1.02 (05 Sep 2019) © nemo 2019 CrashF12 0.02 (11 Aug 2019) © nemo 2018-2019 FixUpDown 1.00 (09 Dec 2010) © nemo 2010 ModuleCredits 1.02 (11 Aug 2019) © nemo 2011-2019 UTF8Alphabet 1.07α (31 Aug 2019) © nemo 2018-2019 VDUMode 0.01 (28 Sep 2017) © nemo 2017 WriteReg 1.04 (11 Aug 2019) © nemo 2002-2019 CloseHook 1.01 (13 Aug 2019) © nemo 2019 (thanks to Martin Avison) CerilicaAlphabets 0.24 (21 Apr 2019) © Cerilica 2001-2019 TransTIFF 1.00 (27 Sep 1993) [nemo] You will note that version numbers can be followed by other characters, so 1.23a is legal… but there’s no way for |
Richard Coleman (3190) 54 posts |
Installer however only reads the first 2 digits after the full stop so would see 5.2163 as 5.21, and if I understand the C code correctly it returns -1 if there is no full stop, so will not accept “17” as a valid version number, whilst RMEnsure does. |
nemo (145) 2538 posts |
Then Installer is broken. |
Andrew Rawnsley (492) 1444 posts |
Ugh, Installer. That one commits a lot of sins. This very site includes a “current” !System download containing a 26bit version with a current version number. The same version (or higher) than 32bit ones. So, yes, you can update your !System and have Installer delete itself and replace a 32bit version of itself with a 26bit one, because the 32bit version in 500 folder is lower version than the 26bit one in the ROOL zip. And yes, that has happened. Recently. To some not-stupid users. And people wonder why no-one uses Installer outside of Cambridge… There’s a very strong argument for 32bit versions of Installer using a higher master-version number eg. 1.xx for 26bit versions and 2.xx ofr 32bit ones (or even 5.xx for 32bit ones). !System/Installer will allow older versions to exist “downwards” but not “upwards”, so 26bit versions for legacy OS builds should have a lower version number than 32bit RO5 builds. |
nemo (145) 2538 posts |
Why wouldn’t Installer be agnostic? Doing different things on different OSes is not the same as needing to have different binaries on different OSes. |
Steve Pampling (1551) 8164 posts |
Erm, I think Sprow may have when replying to my n.nnn suggested format where he introduced the concept of more than one dot – which isn’t something I understood to be supported, hence me simply taking out one dot from the mbedTLS version string: Or even 2.160, 2.161, 2.162, 2.163 etc So, the n.nnn format is viable (as is n.nnnn etc for a limited number of repetitions) and we have the additional information that some old software (Installer etc) may be broken and require a fix. By which yardstick perhaps the best version numbering for AcornSSL would probably be: The temptation there is to see this as only applying to RO5.x (I’m not sure it does) and to head toward a module number of 527.2163 which covers the fact that the build is beta RO5.27 and the TLS is 2.163. |
Pages: 1 2