UpdCaCert released

This seems to work on RISC OS 5. If CertData doesn’t exist then NetSurf will use it’s own file.

Make sure this is set before running NetSurf.

Set NetSurfBundle$Path InetDbase:CertData,NetSurf:Resources.ca-bundle

Add

ca_bundle:NetSurfBundle:

to Boot:Choices.WWW.NetSurf.Choices

Yes, my apologies. I wasn’t going to reply until I’d looked up the configuration option, which I had applied some months ago (long enough to have forgotten what I did!), but now you’ve explained it to the world.

I have been trying the UpdCaCert program and while it works.

I have seen some potential issues, I have several CertData files

Boot.Choices.Default.Internet.Files.CertData

Boot.Resources.!Internet.files.CertData

Plus more in !CaCertificates in !Obrowser (Otter), and !Iris
Plus !NetSurf uses ca-bundle

This could take some untangling I think.

I have several CertData files

This is, of course, a manifestation of the mess I’m trying to clear up!

Which version of RISC OS are you running?

Does anyone know why there is a Boot.Choices.Default.Internet.Files.CertData file, and/or what uses it? To put it another way, if that file were deleted, what would stop working?

UpdCaCert canonicalises the InetDBase:CertData path and treats that as the file to be updated. In RISC OS 5, that’s Internet.files.CertData, which, other than a leading pling, is the second path you gave. Which file on your system does UpdCaCert update?

NetSurf, at least, can be configured to use InetDBase:CertData. I don’t have Otter or Iris, so I can’t speak for them, but I hope the author(s) can be persuaded to use the central file by default.

Does anyone know why there is a Boot.Choices.Default.Internet.Files.CertData file, and/or what uses it?

That is supplied in RComp’s NetFetch AcornSSl update so it will work with RISCOS 4.39’s Boot setup so I believe.

I agree everything needs to be standardised…

Which version of RISC OS are you running

5.29 on an ARMX6

Does anyone know why there is a Boot.Choices.Default.Internet.Files.CertData file, and/or what uses it? To put it another way, if that file were deleted, what would stop working

Don’t know

UpdCaCert canonicalises the InetDBase:CertData path and treats that as the file to be updated. In RISC OS 5, that’s Internet.files.CertData, which, other than a leading pling, is the second path you gave. Which file on your system does UpdCaCert update

Its updated that one, the second one.

Iris and OBrowser have an Application called !CaCertificates within them and inside the application are CertData files

The packaged Otter-Browser, amongst its many dependencies, requires the CaCertificates package, which provides <CaCertificates$Dir>.ca_certificates/crt

In theory it would be possible to push a new CaCertificates package that sets <CaCertificates$Dir> to point to InetDBase. The original one probably originates in the RISC OS Firefox era, when there was no other certificate store.

However it would need to cover several cases:

• People who don’t have anything in InetDBase: Should it install the CertData there?
• Should it override a CertData that’s already there?
• It would need to provide InetDBase:ca_certificates/crt, given it’s not possible to change the leafname if it’s already baked into apps. So, given we don’t have symlinks, there would be two copies of the same file.
• How is CertData updated (by committing stuff to the ROOL tree, or pulling from some other database?)? If the package is not managing CertData but only ca_certificates/crt, how to ensure they remain in sync?
• What if somebody is running both the package and UpdCaCert?

It seems that now there are two parallel systems they’re complicated to try and unify, at least until everything is rebuilt to point to the new place.

People who don’t have anything in InetDBase: Should it install the CertData there?

There should be a file InetDBase:CertData, and it should be reasonably up to date. That’s what UpdCaCert tries to do.

Should it override a CertData that’s already there?

UpdCaCert replaces a CertData file in InetDBase: if, and only if, there is one newer than the one there, or there isn’t one there at all.

How is CertData updated (by committing stuff to the ROOL tree, or pulling from some other database?)?

I don’t know, but CertData is updated frequently (not regularly!), so committing to the ROOL database is only at best going to help users when they update HardDisc4 or something similar. UpdCaCert gives users a free and easy way to update as often as they wish – and it comes with a recommendation to try once a week.

If the package is not managing CertData but only ca_certificates/crt, how to ensure they remain in sync?

There’s no issue about keeping things in sync; only up to date.

What if somebody is running both the package and UpdCaCert?

UpdCaCert downloads a new CertData if, and only if, it’s newer than any existing InetDBase:CertData (or if the file does not already exist). If something else tries to overwrite InetDBase:CertData, I hope the default Copy options would only replace with newer. At worst, an out of date overwritten one would only remain until the user runs UpdCaCert again.

The problem is that now we have three ways to manage the certificates: the ROOL gitlab database, the CaCertificates package, and UpdCaCert (which is fetching from curl.se). I agree that there needs to be a mechanism to update them (they aren’t a static thing that you just get once and use forever), and I see the merits of a standalone app like UpdCaCert (especially for folks not using RISC OS 5).

But it gets complicated given that there are still two places they live, and those places can’t be trivially merged into one place. And it would seem to make sense to not then produce two ways of updating them, which may end up with the two places becoming out of sync.

We can’t just wish <CaCertificates$Dir>.ca_certificates/crt away since it exists and software uses it, so any solution needs to consider that location as well as the more recent one. The alternative is older software randomly stops talking to TLS servers because the certificates in that location are out of date, even if the ones in InetDBase: are current.

One solution to this is simply to update the CaCertificates package with the new certs and push updates to that, and that would be easy to do. But it won’t fix InetDBase:, until such time as that is packaged. And it won’t help for people who aren’t updating their system using PackMan. Maybe UpdCaCert is the solution for that, but it doesn’t solve the problem of their CaCertificates becoming out of date.

Theo: I agree with some of what you say. UpdCaCert provides an easy way for users to keep InetDBase:CertData up to date. I hope you agree with that.

There isn’t an automatic way to keep anything else equally up to date. Further up this thread, I pointed out that I don’t want to support efforts to keep multiple copies of the same data equally up to date; but I did point out two ways that people who don’t share my view can do it.

Since the certs are updated multiple times a year, it does require UpdCaCert, or something that works pretty much like it, to keep users’ files up to date. Packaging will do nothing to help.

One other thing: I would be quite happy for UpdCaCert to be bundled with RISC OS. I’ve licensed it GPL2, and, since my app doesn’t link with anything in RISC OS, and since the GPL does not in any way cause difficulties with mere aggregation, that wouldn’t be a problem.

Packaging will do nothing to help.

If InetDBase/CertData were packaged then PackMan would offer to update the file each time there is a change (assuming that the package was kept up to date). Complicating matters, if UpdCaCert has come along and updated CertData ‘behind the scenes’ then PackMan will fall over next time it tries to install an update…

Indeed, packaging has quite a bit to help here. The ROOL disc-based components are already packaged, and PackMan will automatically update them if there are updates. For example the Unicode package will update Unicode. If InetDBase were packaged, that mechanism would also update CertData from the copy held in ROOL gitlab. It would also update MIMEMap, which is another file that ought to get regular updates.

Arguably there’s a good reason for updates going via gitlab, because then the exact file contents that were pushed to machines are tracked. A build that pulls directly from the internet is potentially subject to difficult-to-track bugs that depended on exactly when it was pulled. But it wouldn’t be difficult to then sync gitlab with upstream sources, in a way that tracks the changes.

So the ROOL distro does have an update mechanism, and it wouldn’t be much to add CertData (and ca_certificates/crt) to it. It doesn’t solve the problem for people not using RISC OS 5, the ROOL distro or PackMan, though – and maybe UpdCaCert is useful there.

So the ROOL distro does have an update mechanism,

Unless I missed a significant announcement, that isn’t part of the ROOL build.
Automated updates probably ought to be, at that is probably an aspiration of ROOL, but I believe that’s aspiration vs. current reality

Unless I missed a significant announcement, that isn’t part of the ROOL build.

See here for details.

Unless I missed a significant announcement, that isn’t part of the ROOL build.

The packages of stuff (except !Boot) was announced at the Wakefield show in 2019 – I happen to remember as I was rent-a-presenter for ROOL at that show due to scheduling clashes.
It was repeated at the London 2019 show too by the looks of the talk.

But to Theo’s point, the official RISC OS Pi card image has the apps registered with PackMan (5.28 being the first stable release after the packages were available), so getting updates should be as simple as running PackMan.

Obviously the packages are frozen in time at the point the image was generated, so I’d bet quite a few flag as updates available out of the tin covering the various improvements since the Pi 400 came out, just as Linux goes nuts updating itself after installing from an ISO image.

Obviously the packages are frozen in time at the point the image was generated, so I’d bet quite a few flag as updates available out of the tin covering the various improvements since the Pi 400 came out, just as Linux goes nuts updating itself after installing from an ISO image.

Could be worse. I recently had to start up a couple of Windows7 laptops that were last used in 2018. After first resetting the time to the correct day/month/year so that login to Windows update worked, they then took 5 hours to catch up with the Windows updates.

Then I tried to update Firefox, which was somewhere around V35. It did six successive updates, jumping in stages to the current V94.

I learnt from this, and downloaded a new Firefox and simply installed that for the other laptops. Much quicker.

After using them for an hour, at shutdown they installed more Windows updates.

Well, whether or not UpdCaCert does anyone any good, I’m gratified by the debate that it has provoked.

Sorry to restart this thread but although I am using this !UpdaCaCert on a regular basis, I have discovered that in Packman there is also a CaCertificates download which installs !CaCertificates in !Boot.Resources. So which is being used – So now have three SSL Certificates locations, one in !Boot.Resources, another in “Boot.Resouces.internet.files” plus a copy of !CaCerticiates inside Iris, but the this seems to defer to the !CaCertificates if installed in !Boot.Resources.

This is a mess. I think ROOL need to say which should be the one to be used and updated by default and all others removed – so everyone and all browsers and other internet packages use just a known default version which is kept up todate.