CertData Catch-22

There’s a Catch-22 with CertData files, isn’t there? The file is available from https://curl.se, but only via https. If you attempt to get it via http, you’ll get a message “301 Moved Permanently” giving the https URL.

This means you’ve got to have a valid CertData file somewhere on your system, used by a suitable app, to go and get CertData.

If we reach the situation where everything is available via https only, how does anyone get the first CertData file?

Getting updates thereafter should be OK, providing the CertData file is not allowed to fall too far out of date or validity.

You don’t need a CertData file to use https. Just means all https URLS will be untrusted.

The other day I had a bit of a senior moment and set up a system to use https:// paths in PackMan. Of course this didn’t work, so I installed the CaCertificates package over http:// and then the https:// paths in PackMan worked fine.

Dumping PackMan shows that it references both <CaCertificates$Dir>/ca-certificates.crt and InetDbase:CertData, the latter of which was present when the https:// accesses were failing.

Which one should the libraries be using?

Which one should the libraries be using?

As I understand it, the “one true” file is InetDBase:CertData.

If anyone knows different, now would be a very helpful time to say!

InetDBase:CertData is the one used by AcornSSL and curl. Of those I’m certain, because I’ve worked on AcornSSL and I’ve seen the string InetDBase:CertData in curl’s binary; and by experiment, in both cases, if InetDBase:CertData is missing, they won’t do https fetches.

If we reach the situation where everything is available via https only, how does anyone get the first CertData file?

CA’s send data for verification, revoke etc over HTTP.
Irony: could actually be a process for removing creases from clothes…

Stuart: what’s the date in your InetDBase:CertData file? It’s very near the top.

Stuart: what’s the date in your InetDBase:CertData file? It’s very near the top.

14 Oct 2020

CertData doesn’t seemed to be referred to by anything in !PackMan’s package info. How does CertData get updated?

It’s almost a year out of date, though whether an update would fix your problem is not something I can answer.

The most recent one, at time of posting this message, is 30 September 2021.

Dumping PackMan shows that it references both <CaCertificates$Dir>/ca-certificates.crt and INetDbase:CertData, the latter of which was present when the https:// accesses were failing.

The current version of PackMan is linked with an old version of libcurl that points to CaCertficates$Dir/ca-certificates.crt.
Newer versions of libcurl point to InetDBase:Certdata.

You don’t need a CertData file to use https. Just means all https URLS will be untruested.

Is this what I get from the “-k” option to curl?

Presumably we have to be wary of the riscosopen.org server deciding to go HSTS or 310 redirecting for package management. I’m sure that there will be people+ in a few years’ time who will fire up an old copy of PackMan referring to CaCertficates$Dir/ca-certificates.crt (possibly having never installed CaCertificates) and be stymied and of course it will be RISC OS Open’s fault, rather than theirs for not keeping PackMan up-to-date.

+You know the ones…

Is this what I get from the “-k” option to curl?

or —insecure.

The equivalent for wget is —no-check-certificates.

The other day I had a bit of a senior moment and set up a system to use https:// paths in PackMan. Of course this didn’t work, so I installed the CaCertificates package over http:// and then the https:// paths in PackMan worked fine.

Dumping PackMan shows that it references both <CaCertificates$Dir>/ca-certificates.crt and INetDbase:CertData, the latter of which was present when the https:// accesses were failing.

Which one should the libraries be using?

Same for me, which is why I had to provide the extra instructions for people wanting to use my Packman repository to install !CaCerts via HTTP first.

The current version of PackMan is linked with an old version libcurl that points to CaCertficates$Dir/ca-certificates.crt.
Newer versions of libcurl point to InetDBase:Certdata.

Thanks Chris, so should I update my instructions on my blog? probably not, given that people may still be using outdated versions of !Packman?

Thanks!

Chris: they say you learn something new every day, so I thank you for your very useful lesson!

The problem I’m trying to solve is that of having multiple certificate files, in various locations, with various names, and with various dates. Only some of them will get updated. Many people have found out recently the consequences of having out of date certificate files. I’m sure Mr. Pampling will have one or two horror stories in that regard.

I’m trying to push for one file in one location, known to everyone; and I’m trying to create a reasonably idiot-resistant app to update that file. An app that can be used frequently (let’s say, once a week) and not put excessive load on the server, i.e. it doesn’t just download regardless, it only downloads if the available file is more recent.

So: Paolo, I’d suggest that you should update your instructions, but in a way that allows for how things are likely to be in the near future, not merely how they are now.

@ Dave

So: Paolo, I’d suggest that you should update your instructions, but in a way that allows for how things are likely to be in the near future, not merely how thay are now.

Thanks! Now, knowing my “interesting” way to explaining things in English (sometimes), this is going to be fun, I am sure! XD

Thanks! Now, knowing my “interesting” way to explaining things in English (sometimes), this is going to be fun, I am sure! XD

I think that given that there isn’t a current update mechanism for InetDbase:CertData, it might be best to ask users to try using the https:// path and if they see a certificate error, try making sure that PackMan is up-to-date, retry, and if still failing, follow your how to get CaCertificates instructions.

Hopefully Dave H. will package his InetDbase:CertData updating app to make it easy for bears with a very small brain like me ;-)

Or why not just create a package for InetDbase:CertData and update that regularly. Isn’t that what the autobuilder is for?
An updated PackMan could have that as a Recommended (or if you feel strongly enough about it, Required) package.

I have an unreleased app that uses wget to fetch the latest CaCertificate and place it in a RAM disc.

It uses the —no-check-certificate switch in wget.

Does the prog try HTTPS first – if it fails – then ‘no-check-
certificate’ ?

No just the no certifcate check as if the certificate is out of date you download an empty file.