Sargasso RSS feed stopped working

What I don’t follow is why Colin’s mods to Sargasso solved the problem yesterday.

Yesterdays version has a workaround for the problem to do with the chain verification depth. I have a new version available soon which uses openssl 1.1.1 which doesn’t have the problem so the workaround is no longer needed. It also uses TLSv1.3.

This debacle does, of course, raise an interesting question.

Some of the comments given by people quoted in the linked Reg article are, impolite to say the least. Because there’s a chain of certificates. Some good, some bad.

Now the question is this – “https” is supposed to work on a system of mutual trust. The site’s certificate is valid, the issuer is valid, therefore the browser can assume that the site is valid.

However in this case one (or more) of the certificates were not valid.
Is it reasonable for a security implementation to simply disregard the invalid certificates and trust the ones that are valid? Because that sounds like what is being proposed.
Would it not make more sense to consider that if any of the site’s certificate chain is invalid, then one cannot absolutely trust the encryption, so it is right to be faulted?
[faulting shouldn’t really cause things to stop working, the user ought to have a way to manually override on the understanding that they choose to do so]

What I don’t follow is why Colin’s

How embarrassing! Apologies!

There’s an updated version of Sargasso 2.06pre5 available here.

New in this release

Linked with openssl 1.1.1g. Fixes problem with certificate chains. Also supports TLSv1.3.
The log now shows the certificate chain.

Now, if only I had the option to suppress Rick’s gratuitous RSS description, then life would be so-oo much better!

And sorry again about the mis-attribution!

if only I had the option to suppress Rick’s gratuitous RSS description

The point being, that once I’ve read it once, it has no relevance, and merely becomes an unnecessary infringement on the Sargasso window space!

It’s not Rick’s fault for including a description ( tho’ he has used it aggressively!), but I feel it should be suppressible!

tho’ he has used it aggressively!)

Mais seulement pour me taquiner, c’est sûr !

Would it not make more sense to consider that if any of the site’s certificate chain is invalid, then one cannot absolutely trust the encryption, so it is right to be faulted?
[faulting shouldn’t really cause things to stop working, the user ought to have a way to manually override on the understanding that they choose to do so]

Well, my work machine does fault it, and doesn’t provide an override. I couldn’t visit the ROOL site at all from work yesterday (haven’t tried today, but presumably it’s still going to fail…)

Now, if only I had the option to suppress Rick’s gratuitous RSS description

Oh FFS John – I put the description in there because you whinged that saying “Rick’s b.log” (same as the title) wasn’t good. So, I added a description. And you’re still whinging. 🤦 ¹

tho’ he has used it aggressively!

Nah, aggressive is that American one (Time? I forget…) that had a description and a lengthy pile of “rights” that went on and on and on. 💩 ²

Mine is simply…descriptive.

[it is also valid RSS, I checked the moment you reported a problem with Sargasso]

but I feel it should be suppressible!

Yeah, to be honest I think it would be better to clip all descriptions in the feeds window to a single line (with “[…]” if longer) and show the proper description at the top of the feed entries list. That way the main list of feeds is regular and not higgledy-piggledy.

Mais seulement pour me taquiner, c’est sûr !

Ah, so you spotted the “HELLO JOHN!” in capitals followed by some emoji you won’t have been able to see on your machine? 😜 ³

¹ Facepalm emoji.

² Poop emoji.

³ Sticking-out-tongue-and-winking emoji.

I’ve dropped the faulty Sectigo (Comodo) certs out of our chain entirely, relying on up to date root certs in the client. This may not be the case for a lot of older software – and a lot of older software tends to access the ROOL site :-) – but at least it’s better than serving expired data, at least for now.

Interested to hear of any trouble. I never could see any myself, as all the s/w I’m using for access locally is already up to date and wasn’t reading the expired legacy chain items as the root cert was modern and valid. I note that the most recent Netsurf build on Windows (via Wine) was happy with both the old chain and new stuff, indicating that it either also has up to date root certs or just didn’t care about the chain issues.

I’ve dropped the faulty Sectigo (Comodo) certs out of our chain entirely, relying on up to date root certs in the client.

Thanks! I can view the site from work again :)

Is it reasonable for a security implementation to simply disregard the invalid certificates and trust the ones that are valid? Because that sounds like what is being proposed.

That wasn’t the impression I got. ICBW, but wasn’t the issue that the expired certificate was on the way to being obsolete and was only used by old software? New software continued to work, because it was served a different root cert that only expires at the end of this year (IIRC, I’ve not checked the date).

There’s an updated version of Sargasso 2.06pre7 available here.

New in this release

Two new options in the choices window.
Max Fetches is now configurable. Setting it to 1 is useful for debugging.
Use a proxy instead of a direct connection. This can speed up feed downloads on fast connections. Works around the issue in the RISC OS network stack due to network latency causing slow downloads.
<ip address or hostname>:<port number>. e.g 192.168.0.1:80

There’s an updated version of Sargasso 2.0.6pre8 available here.

New in this release,

If either the feed title or description was blank this caused the main feeds window to not format properly.
Fixed a zero pain when using ssl
fixed a few memory double frees and free before use

There’s still a ZeroPain when updating the feeds.