InetRes updating automatic

Every once in a while I see “Updated trusted root CA data” on the GitLab change list.

It would be very useful to have the file with the root CAs or the InetRes someplace where it can be fetched at ease – just a simple static URL would suffice (I’d then simply use wget or something like that to fetch automatically and check if the one inside the system needs to be updated). Even better would be a short text file indicating the version, date and URL where to fetch to even reduce bandwidth need more.

Being able to update that CA list is kind of important – fetching the nightly harddisc builds and extracting it from there or something along those lines can be done but is basically a waste of resources (especially the bandwidth and download volume on ROOLs website).

If this is already in place and me just blind as a bat having not found that one, thanks to point me in the right direction.

Oh I did check PackMan and ROOL repositories … having it on there would be good too (perhaps as a separate container so that the package list fetching is faster)

Thanks
Herbert (publishing GAG-News since 30 years)

https://davehigton.me.uk/Progs/UpdCaCert.htm

Just as first idea this small obey updates the CertData… (if you copy remove the space between the option dashes – I had to insert that to prevent the forum to format things with strike out)

wget – -quiet – -ca-certificate=InetDbase:CertData – -output-document=RAM::RamDisc0.$.CertData https://gitlab.riscosopen.org/RiscOS/Sources/SystemRes/InetRes/-/raw/master/Resources/files/CertData
ifthere RAM::RamDisc0.$.CertData then copy <Boot$Dir>.Resources.!Internet.files.CertData <Boot$Dir>.Resources.!Internet.files.CertDataOld ~a~cdf~l~n~p~q~r~s~t~v
ifthere RAM::RamDisc0.$.CertData then copy RAM::RamDisc0.$.CertData <Boot$Dir>.Resources.!Internet.files.CertData ~a~cdf~l~n~p~q~r~s~t~v

It fetches CertData from the ROOL Git Repository onto the RAMDisc using wget and if after the act the file is there it renames CertData to CertDataOld (overwriting a potential previous CertDataOld) just in case and then moves the newly fetched CertData from the RAMDisc to the good place (move is done due to option “d” in the *copy).

What might be worth considering is to do some checks and balances, i.e. after the wget (you want to use a current port from http://www.riscos.info/packages/NetworkDetails.html since some older wget ports do not support https) take a look at the CertData file if it looks complete and/or check if wget was successful in the first place.

It would be very useful to have the file with the root CAs or the InetRes someplace where it can be fetched at ease – just a simple static URL would suffice

It’s here.

Thanks Chris – oddly enough I did discover that one too after some research…

It looks we both posted at the same time :)

Every once in a while I see “Updated trusted root CA data” on the GitLab change list […] Oh I did check PackMan and ROOL repositories … having it on there would be good too (perhaps as a separate container so that the package list fetching is faster)

Everything in the HardDisc4 image outside of !Boot has been packaged since Feb 2019, so you can use PackMan to check for any updates there, or just pick the individual ZIP files if you prefer to do things manually.

The stuff inside of !Boot is more tricky because there’s a web of dependencies to describe which the tool which generates the other packages doesn’t currently handle. The 5 which are definitely not interconnected (like !PrintDefs) were added as packages in Jul 2021.

My proposed strategy for the other bits is to try to make !Boot be able to have fewer user things much as the even older packaging the boot structure thread.

What does that look like? I’m currently testing

• A 1 line change so !Scrap can be optionally be placed outside boot
• An updated SetChoices which allows all choices to optionally be in a !Choices container application
• Both !Choices and !Scrap need to be in a known location (the root of the boot drive) so !Boot can find them programmatically
• A new option for the Filer which hides all these system things, partly to simplify the directory display, but also prevents them being accidentally deleted or moved
• Corresponding option in the Filer setup plug-in (so you can have them showing if you prefer)
• A change to FSLock to allow !Scrap to live outside !Boot

If anyone’s feeling brave I could roll a test ROM (because of FSLock) with the changes in to try.

If anyone’s feeling brave I could roll a test ROM (because of FSLock) with the changes in to try.

Well I could set up a Pi3 I have to test a rolled ROM and the other updates as no need to be that brave then :-)

Moving Choices and !Scrap seems a good idea to me.
What would the Filer optionally hide? Just !Choices & !Scrap, or !Boot as well? Or even anything starting in pling?
I also have a test RPi3, which I do not have to be brave with.

I could try it on a Titanium (soft load) and a RPi4 if you like.

It fetches CertData from the ROOL Git Repository onto the RAMDisc using wget and if after the act the file is there it renames CertData to CertDataOld (overwriting a potential previous CertDataOld) just in case and then moves the newly fetched CertData from the RAMDisc to the good place (move is done due to option “d” in the *copy).

What might be worth considering is to do some checks and balances, i.e. after the wget (you want to use a current port from http://www.riscos.info/packages/NetworkDetails.html since some older wget ports do not support https) take a look at the CertData file if it looks complete and/or check if wget was successful in the first place.

My app does all that, I believe.

https://davehigton.me.uk and look for UpdCaCert.

Uh… Second message, Dave. ;)

No point reinventing a wheel, here, you know? UpdCaCert does the job.

Yes…

Herbert posted a long recipe, and some suggestions to improve it further, after you sent the link to my app. Perhaps he didn’t realise that a complete, ready made solution already exists, including his suggested improvements.

Is this cert file the same for Win/Linux?

Is this cert file the same for Win/Linux?

Yes.

If anyone’s feeling brave I could roll a test ROM (because of FSLock) with the changes in to try.

For the brave I’ve put a test ROM and matching disc updates here along with brief notes of how to use, and what to expect. E&OE.

There may be a few naughty applications which just write to $.!Boot.Choices directly, these should be dealt with with a stern finger wagging.

Sounds accurate :)

Both !Choices and !Scrap need to be in a known location (the root of the boot drive) so !Boot can find them programmatically.

But…able to be placed back inside Boot for those who understand the desire to separate system resources and user resources, but at the same time don’t want crap cluttering up $.

It is just so weird not seeing !Boot in its usual place of so very many years. Restoring !Boot to visibility is a simple matter of double clicking on !Boot to reset the Filer Choice.

So far I am not too sure about moving !Boot components into the root and then hiding them. But maybe …

Hiding !Boot is an interesting concept, does the user really need to be much bothered with it?

Here the invisible Boot is on the Titanium’s Drive 6 SSD thereby preserving the old fashioned way on Drive 4. To avoid a Filer_Visibilty error on starting up with an unmodified ROM the softload will be placed in PreDesk.

I will give it a whirl, to see how often !Boot needs to be unhidden.

Update In this instance Choices and Scrap remain within !Boot.

Sounded interesting, so I have tried it on my RPi3B which had been running 5.28 ROM, using just an SD card.
Installed ROM, moved !Scrap and Choices to root, added pling to Choices. All seemed ok. However when I change Config to Hide System stuff, the filer display changes … but at least !Boot & !Scrap appear with the icons but name blank. Others appear with a name of SDFS::RISCOSPi.$ and a timestamp of 8 zeros twice. Trying to do much with the Filer seems to abort, which makes debugging awkward! Opening a directory gives Data Transfer abort in Filer @&FC25F58C +70A8, which is an LDRB,[r1},#1 but r1 is &6554006B. When I manage to turn HideSys off again, all reverts to normal. I will try to determine later if I have done something wrong, and if not if the aborts are consistent.

Tried the with my Pi3B and getting similar issues to Martin.

Installed the Disc updates and new ROM and rebooted.

Went in to Configure>Filer and selected Hide System Application directories and Set.

Looked at !Boot still there.

So I manually deleted the !RunImage,Messages,Res files in FilrSetUp and then copied over again the ones from the download and again tried to hide the system applications via Filer and this time it set the box correctly and !Boot was gone.

Now unhide !Boot and moved !System to root and rebooted and system seemed Ok. So hide System application directories via Filer and rebooted and the system seemed Ok.

Unhide again and this time move Choices to !Choices in the root, Hide system directories and rebooted and this time get errors, at &FC0143EB" when testing things.

So unhide but still some issues and only cured by moving Choices back in to !Boot.

Seem to remember that lack of !Sprites in ! directories caused some issues before so is this the case for !Choices?

This time with Choices moved into the root I got an abort in the filer at +5fe8, the drive with the !Boot on it would not open and the Titanium stiffed itself. Serves me right, automatically soft loading the ROM was a BAD idea.

The next thing to try, as suggested above, is to ensure that the root !Choices is a sufficient application.

OK so the sprites things doesn’t solve any issues but found the first “naughty” app, !Netsurf 3.10.

It does not like !Choices being hidden and blows up either with “No writable memory here” or "Heap errors.

If you try to save any of it’s choices , when !Choices is hidden, then nasty things happen like the backdrop goes missing and then filer errors etc.

Unhide !Choices and reboot and Netsurf 3.10 plays nicely with !System and !Choices outside of !Boot.

I have now tried Netsurf 3.11 and it is still the same when system applications are hidden.

StrongEd and Packman seem to play nicely though but Store is another application that doesn’t like the system applications being hidden.

Now that we’re looking at hiding Boot… any possibility we could revisit the idea of a right click on Switcher opening up the system configuration? You know, what running Boot does.