TCP/IP bounty beta release

Wonderful. Fortunately it seems that mbed TLS upgrades are easy to drop in!

It looks like ARM are already on the case, with a mention in the change log of their fix though it’ll likely take a few weeks to ripple through as a release, that’s considerably better than 10+ year old ‘secure’ modules.

I was also interested to see that the IETF has been mulling the kill date of TLS 1.0, and it’s pretty soon, with most major browser vendors picking early 2020 as it’s now too easy to crack you might as well not bother (rather than give https a bad name).

But it is normal for apps to do RMEnsures in their !Run files to determine if the correct version of a module for the app is available, and to load it if necessary, giving an error if not available. That is what I am trying to resolve.

Looking at task manager it looks like I have only 3 non-ROM module tasks:

• AcornURI – loaded by FTPc – it does RMLoad then has a helper app in BASIC which does the equivalent of ‘XWimp_StartTask Desktop’
• KeyExtend – loaded by StrongEd – it does RMLoad then ‘Desktop_KeyExtend’
• OLE support – loaded by Pluto – it RMLoads it but does nothing, so it’s not until some time later when I run an unrelated Desktop file that that starts

So there’s not much consensus there.

So there’s not much consensus there.

Limited set of applications but all consistently doing a workaround for something that doesn’t quite match the needs of the system users/developers.
Let’s not add another that needs a workaround.

AcornURI – loaded by FTPc – it does RMLoad then has a helper app in BASIC which does the equivalent of ‘XWimp_StartTask Desktop’

Desktop was used because help desktop_acornuri says ‘Do not use *Desktop_AcornURI, use *Desktop’. Using wimp_starttask stopped the screen flashing. Most of the *Desktop_. commands say use *desktop.

@Frank:

RMEnsure AcornSSL 1.01 StartDesktopTask RMRun System:Modules.Network.URL.AcornSSL

will work … but the inevitable following line in the Obey…
RMEnsure AcornSSL 1.01 ERROR App requires AcornSSL 1.01 or later to run
will fail, because the new task to load the module has not yet run.

A further requirement is that whatever is used must work on all versions RO3.50 and upwards (like AcornSSL). Is StartDesktopTask a more recent command?

@Martin,

Yes, if your application won’t run without AcornSSL, you’ll need something better. The StartDesktopTask bit is what I use in MSC’s !Run. That app will run fine without AcornSSL. It just won’t do secure connections.
In AntiSpam I use a function (FNmodule) in the main program. A function based on something written by you, actually. :)

I have no idea whether StartDesktopTask is recent or not. It’s in RO 4.39.

I’m definitely in favour of having the module start the task itself (e.g. via TaskManager_StartTask). But there is a restriction with TaskManager_StartTask (and other approaches?) which is that the task only starts on the next wimp poll – which can cause problems if software loads the module and then immediately tries using any features which require the module’s task to be running. This is one of the reasons why I abandoned having the VideoOverlay module be a wimp task (the overlay create SWI would return the handle of a window owned by the VideoOverlay task – which doesn’t work if the VideoOverlay task hasn’t had a chance to start yet)

Possibly for AcornSSL that problem could be worked around (e.g. if the task isn’t active when the certificate error occurs, wait half a second and see if it starts up, before giving up and doing a single-tasking prompt)

there is a restriction with TaskManager_StartTask (and other approaches?) which is that the task only starts on the next wimp poll

Can you force the Wimp to start it by putting a Wimp_Initialise / Wimp_Poll / Wimp_CloseDown sequence in the Module initialization directly after TaskManager_StartTask?

which can cause problems if software loads the module and then immediately tries using any features which require the module’s task to be running

Is this liable to be an issue in reality? The module is likely to be loaded in an !Run file, the application itself will then be starting up, and it’s probably worth polling a few times in the beginning because of the various things that the Wimp does at app start?

I think asking the app author to be sure to poll the Wimp before using socket calls is less onerous than asking app authors to do the module’s work for it…

Can you force the Wimp to start it by putting a Wimp_Initialise / Wimp_Poll / Wimp_CloseDown sequence in the Module initialization directly after TaskManager_StartTask?

Yes, no, maybe. :-)
You’re not supposed to do that from SVC code, but that’s exactly what I do in the initialisation of my OLED module because the Wimp is too dumb to realise that writing VDU commands to a redirected sprite is not something that requires a “Click mouse or press Space to continue”…

there is a restriction with TaskManager_StartTask (and other approaches?) which is that the task only starts on the next wimp poll

Can you force the Wimp to start it by putting a Wimp_Initialise / Wimp_Poll / Wimp_CloseDown sequence in the Module initialization directly after TaskManager_StartTask?

Possibly – but that seems like a bit of a bodge!

If the module is being loaded from a !Run file, then maybe we just need a *StartDesktopTaskNow command (or whatever you want to call it) which does the Wimp_Initialise / Poll / CloseDown dance which you suggest. That will avoid any dangers associated with having the module force-start its task on any RMLoad (although it does still require the person loading the module to know that StartDesktopTaskNow may be required)

I’m also wondering (if AcornSSL only wants to be a Wimp task so that it can ask the user a question) whether it would be possible/worth having a small, generic “ask the user a question” module which can be loaded by default by the boot sequence (+ built into ROM for new machines).

I’m also wondering (if AcornSSL only wants to be a Wimp task so that it can ask the user a question) whether it would be possible/worth having a small, generic “ask the user a question” module which can be loaded by default by the boot sequence (+ built into ROM for new machines).

Definitely a useful feature. If that’s the reason for the task status then eliminating it by providing an alternate user interaction is good.

Possibly worth expanding into something that pops up messages that don’t lock the machine and also logs message and response into a file / syslog which we could use in the Boot as one example. Interactive messaging/logging

This, surely, is the multi-tasking error reporter that has been discussed previously. The upgraded replacement for Wimp_ReportError.

the inevitable following line in the Obey…
RMEnsure AcornSSL 1.01 ERROR App requires AcornSSL 1.01 or later to run
will fail, because the new task to load the module has not yet run.

Is it possible to RMLoad then RMRun the module in sequence? It’s a bit of a bodge, but the RMLoad would be sufficient to not trip the RMEnsure. The question is whether the RMRun will conflict. Maybe I’ll try it when I get home…

However, I agree with others; it would be best if the module could handle this all automagically when RMLoaded.

The question is whether the RMRun will conflict.

The primary issue here is that RMRun is much like Run – it does not return, until the application terminates, which is a difficult thing to stick in an Obey file that’s supposed to carry on and Run something else.

Possibly worth expanding into something that pops up messages that don’t lock the machine

The difficulty here is that an application using it needs to:

• Keep running in the background even with what might be an important prompt showing
• Carry on responding to Wimp events (redraws, mode changes, etc) even with what might be an important prompt showing
• Etc

I wrote an application eons ago that had nice multitasking error boxes. It required a lot of hoop jumping to not get tripped up with things like an “Are you sure you want to discard unsaved data” prompt on screen not to be rendered useless by a drag-to-app or simply Quit; plus the fun of handling redraws whilst complaining about missing data (that the redraws would normally require).
It’s not impossible, but it was a pain. So multitasking error boxes are low in my list of priorities.

PS: The Windows approach of “this application freezes and won’t even bother trying to redraw itself until the error box has been dismissed” was not something I was planning to aspire to. It still disturbs me that when WinSCP is uploading a file, I can’t move or manipulate the parent (file list) window without the machine going “dong!” and flashing the title bar of the transfer status dialogue, in a very thou shalt not manner…

The primary issue here is that RMRun is much like Run – it does not return, until the application terminates, which is a difficult thing to stick in an Obey file that’s supposed to carry on and Run something else.

Apologies; I meant Filer_Run, not RMRun. This works, although it’s hacky:

RMEnsure AcornSSL 1.00 Filer_Run System:Modules.Network.URL.AcornSSL
RMEnsure AcornSSL 1.00 RMLoad System:Modules.Network.URL.AcornSSL
RMEnsure AcornSSL 1.00 Error You need AcornSSL to run this app

The app in question does a Wimp_Poll before attempting any HTTPS.

@Chris: Cunning! It may be hacky, but to me it looks the neatest solution so far … unless and until the module manages to do it itself!

Although I am using FIOASYNC successfully for notification of Internet Events on sockets, I realised that this does not affect Connects, and they were still blocking.

So after
SYS "Socket_Creat" No error to create socket
SYS "XAcornSSL_CreateSession" No error to get ssl handle
SYS "XAcornSSL_Setsockopt" No error to set Host name
SYS "Socket_Ioctl",socket No error to set FIOASYNC

before the Connect I added a
SYS "XAcornSSL_Ioctl",ssl handle,FIONBIO%,On%
where FIONBIO%=&8004667E and !On%=1 … but although the Ioctl ends without an error, the Connect blocks and eventually fails with Error=&20E3C Operation timed out.

The connection is to my NAS … which is deliberately turned off for this test.

Am I doing something wrong, or has anyone else seen this effect?

Is it possible to read the status of FIONBIO and FIONASYNC?
Ioctl seems to allow reading of some settings but not these.

I notified ROOL of the AcornSSL module loading problems, and they have just confirmed to me that the next beta (whenever that is) will automatically start its task after an RMload.

…they have just confirmed to me that the next beta (whenever that is) will automatically start its task after an RMload.

Excellent job.
…and a peek at the recent changes in CVS today suggests that it will also include the fix for the vulnerability listed in CVE-2018-19608 raised in late November.
So, we appear to be moving from a situation where the only SSL module available was rather old to one with updates fixing vulnerabilities noted just 11 days ago.
Next thing you know someone will go and make the base OS secure.

Yes, I never thought I would see CVE changes in RISC OS, never mind such recent ones!

From the location of the module, i.e. in the 350 directory, I take it that means it won’t work in any OS prior to 3.5?

Yup. It uses dynamic areas.

https://www.riscosopen.org/forum/forums/8/topics/11950?page=6#posts-84601

From the location of the module, i.e. in the 350 directory, I take it that means it won’t work in any OS prior to 3.5?

It’s the proverbial omelette making and a small number of eggs have been broken.
How many of those pre-3.5 versions had a working TCP/IP implementation as part of the OS?

and a small number of eggs have been broken.

Not really. New apps using AcornSSL may not be able to work on 3.10, however old apps will have been using something else, so they could carry on doing that for 3.10.
Manga, for example, uses either SecureSockets or AcornSSL (and it is recommended to use SecureSockets for now, until I have time to work out why non-blocking isn’t working) simply by looking to see which module is actually presently loaded…

How many of those pre-3.5 versions had a working TCP/IP implementation as part of the OS?

Zero, unless it was loaded from, say, an Atomwide network card but that’s not really any different to loading it from disc…
As for RISC OS 3.5, the built in one is useless.

From the PRM: The version of the Internet module in the RISC OS 3.5 ROM is only a partial implementation of the Internet stack, supporting only those protocols needed by then-existent Acorn products. It uses version 2 of the DCI (Driver Control Interface). The Internet module in the RISC OS 3.6 ROM (and later) uses DCI 4, and provides a full implementation of the protocol stack.

It’s the proverbial omelette making

At any rate, I don’t think we should be losing sleep over an potential inability to fully support a ~27 year old version of RISC OS. Exactly how many people are seriously expecting modern applications to run on such hardware? Remember, there’s also a severe limitation in memory capabilities (most machines max out at 4MB) so loading a ~200K module in addition to all of the Internet support stuff and the necessary newer CLib…
Let’s just say I wrote QuickVoy to act as a replacement front end to the Voyager suite because the default front end was very nice but required nearly half a megabyte of memory which meant so much less for using for other tasks such as the browser. QuickVoy requires only 128K, and there’s a QuickVoy Small version that will get you on-line in a mere 32K app.

So, no, I’m not losing any sleep on leaving 3.10 behind…

At any rate, I don’t think we should be losing sleep over an potential inability to fully support a ~27 year old version of RISC OS. Exactly how many people are seriously expecting modern applications to run on such hardware?

OK, so my phrase should have been “a small number of eggs may have been broken”.

So, no, I’m not losing any sleep on leaving 3.10 behind…

So we accept that enabling support in the OS build for features that are only used by apps that won’t run on hardware old enough to run that version of the OS. Seems entirely reasonable.
I’d have to dig through a few piles to put the old kit in a position to power up anyway never mind twiddling around with fanciful upgrades.