Sargasso RSS feed stopped working

As of this morning !Sargasso 2.03 generates an error trying to access the ROOL Forum RSS feed: Peer certificate cannot be authenticated with given CA certificates.

!Sargasso 2.05 also fails with a different error displayed : SSL peer certificate or SSH remote key was not OK

note: I am using I believe the current CertData files or CAbundles.

Anyone else getting this error?

is there another way to see new posts to the forum in an easy way.

Same here.

(0.000000s) src/rufl_init.c rufl_init 169: new font manager (v 3.80)
(0.000000s) src/rufl_init.c rufl_init 179: 112 faces, 26 families
(0.000000s) src/rufl_init.c rufl_load_cache 1578: 112 charsets loaded
added feed <a href="https://www.riscosopen.org/forum/posts.rss">https://www.riscosopen.org/forum/posts.rss</a>
status <a href="https://www.riscosopen.org/forum/posts.rss">https://www.riscosopen.org/forum/posts.rss</a> FETCHING => FETCHING
fetching feed <a href="https://www.riscosopen.org/forum/posts.rss">https://www.riscosopen.org/forum/posts.rss</a>
*   Trying 91.203.57.172:443...
* Connected to <a href="http://www.riscosopen.org">www.riscosopen.org</a> (91.203.57.172) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: InetDBase:CertData
  CApath: none
* SSL certificate problem: certificate has expired
* Closing connection 0
finished <a href="https://www.riscosopen.org/forum/posts.rss">https://www.riscosopen.org/forum/posts.rss</a> with result 60 SSL peer certificate or SSH remote key was not OK
status <a href="https://www.riscosopen.org/forum/posts.rss">https://www.riscosopen.org/forum/posts.rss</a> ERROR => ERROR

CertData is the latest.

## Bundle of CA Root Certificates
##
## Certificate data from Mozilla as of: Wed Jan  1 04:12:10 2020 GMT

Firefox and NetNewsWire on the Mac don’t complain.

Peer certificate cannot be authenticated with given CA certificates.

[…]

Firefox and NetNewsWire on the Mac don’t complain.

It’s an interesting question.

There is a problem.

Technically, Sargasso is correct.

ROOL provides four certificates:

1. RSA 2048 bits, expires Tue 1st December 2020 at 23:59:59.
2. RSA 4096 bits, EXPIRED today at 10:48:38.
3. RSA 2048 bits, expires Tue 31st December 2030 at 23:59:59 (10 years?!?).
4. RSA 2048 bits, External CA Root, EXPIRED today at 10:48:38.

I would imagine, since my Firefox isn’t whinging either, that it probably uses logic like “well, some of these certificates check out so we’ll carry on” whereas Sargasso is thinking “something is wrong here and the CA Root is duff, so we’d better not proceed”.

At any rate, this is a server side whoopsie.

Determined using https://www.ssllabs.com/ssltest/analyze.html?d=www.riscosopen.org

There’s an updated version of Sargasso 2.06pre3 here. It should work again with the ROOL forum recent posts feed.

If you have a mo, could you look at the plotting of the feed description? John reported that my blog feed was obscuring the information of the subsequent feed.

Here’s a screenshot:

The feed is at https://heyrick.eu/blog/blog-rss.xml and it is valid RSS – validator link.

Thanks.

Just a note to say that Sargasso 2.06pre3 seems to have restored order here. Will monitor.

Thanks Chris Gransden for the quick fix.

Sargasso 2.06pre3 is also fine here on the RPi4, but for some reason it fails on the Titanium. ATM the I have no idea why.

Both are running the latest OS5.27.

From the Titanium.

(0.000000s) src/rufl_init.c rufl_init 169: new font manager (v 3.80)
(1.000000s) src/rufl_init.c rufl_init 179: 111 faces, 25 families
(1.000000s) src/rufl_init.c rufl_load_cache 1561: "NSSymbol" not in font list
(1.000000s) src/rufl_init.c rufl_load_cache 1578: 111 charsets loaded
added feed <a href="https://www.riscosopen.org/forum/posts.rss">https://www.riscosopen.org/forum/posts.rss</a>
added feed <a href="http://gitlab.riscosopen.org/RiscOS.atom">http://gitlab.riscosopen.org/RiscOS.atom</a>
status <a href="https://www.riscosopen.org/forum/posts.rss">https://www.riscosopen.org/forum/posts.rss</a> FETCHING => FETCHING
fetching feed <a href="https://www.riscosopen.org/forum/posts.rss">https://www.riscosopen.org/forum/posts.rss</a>
status <a href="http://gitlab.riscosopen.org/RiscOS.atom">http://gitlab.riscosopen.org/RiscOS.atom</a> FETCHING => FETCHING
fetching feed <a href="http://gitlab.riscosopen.org/RiscOS.atom">http://gitlab.riscosopen.org/RiscOS.atom</a>
*   Trying 91.203.57.172:443...
*   Trying 45.56.75.187:80...
* Connected to <a href="http://www.riscosopen.org">www.riscosopen.org</a> (91.203.57.172) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x41ec4c (Main Thread)
  (  507f30) pc:   34390c lr:   343db8 sp:   507f34  __write_backtrace()
  (  507fa0) pc:   343a2c lr:   34486c sp:   507fa4  __unixlib_raise_signal()
  (  507fb0) pc:   344768 lr:   354920 sp:   5057b8  __h_cback()

  Register dump at 00507fb4:

    a1:        0 a2:        1 a3:        7 a4:      c17
    v1:        1 v2:      c17 v3:        7 v4:        1
    v5: 203bda38 v6:   4ae738 sl:        0 fp:       22
    ip: 204d9d96 sp:   5057b8 lr:   354920 pc:   34470c
    cpsr: 60000093

  003446f8 : .†. : 11a0f00e : MOVNE   PC,R14
  003446fc : D.úÂ : e59c0044 : LDR     R0,[R12,#68]
  00344700 : .¿å„ : e38cc002 : ORR     R12,R12,#2
  00344704 : D.å : e58c0044 : STR     R0,[R12,#68]
  00344708 : ..†„ : e3a00010 : MOV     R0,#&10            ; =16
  0034470c : H.å : e58c0048 : STR     R0,[R12,#72]
  00344710 : .¿†„ : e3a0c001 : MOV     R12,#1
  00344714 : .†· : e1a0f00e : MOV     PC,R14
  00344718 : __h_ : 5f685f5f : SWIPL   &685F5F

Stack frame has gone out of bounds with address 16

On the RPi4 the log continues :-

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: InetDBase:CertData
  CApath: none
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

I have now also had a fault from 2.06pre3 on ARMX6

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x41ec4c (Main Thread)
  (  507f30) pc:   34390c lr:   343db8 sp:   507f34  __write_backtrace()
  (  507fa0) pc:   343a2c lr:   34486c sp:   507fa4  __unixlib_raise_signal()
  (  507fb0) pc:   344768 lr:    104d4 sp:   506d58  __h_cback()

  Register dump at 00507fb4:

    a1:        0 a2:        1 a3:        2 a4:     8900
    v1:        1 v2:     8900 v3:        2 v4:        1
    v5: 20112df8 v6:      602 sl:        0 fp:       22
    ip: 20219fd6 sp:   506d58 lr:    104d4 pc:   34470c
    cpsr: 60000193

  003446f8 : .ð . : 11a0f00e : MOVNE   PC,R14
  003446fc : D.†å : e59c0044 : LDR     R0,[R12,#68]
  00344700 : .À…ã : e38cc002 : ORR     R12,R12,#2
  00344704 : D.…å : e58c0044 : STR     R0,[R12,#68]
  00344708 : .. ã : e3a00010 : MOV     R0,#&10            ; =16
  0034470c : H.…å : e58c0048 : STR     R0,[R12,#72]
  00344710 : .À ã : e3a0c001 : MOV     R12,#1
  00344714 : .ð á : e1a0f00e : MOV     PC,R14
  00344718 : __h_ : 5f685f5f : SWIPL   &685F5F

 Fatal signal received: Segmentation fault

 Stack backtrace:

 Running thread 0×41ec4c (Main Thread)

  (  507f30) pc:   34390c lr:   343db8 sp:   507f34  __write_backtrace()

  (  507fa0) pc:   343a2c lr:   34486c sp:   507fa4  __unixlib_raise_signal()

  (  507fb0) pc:   344768 lr:    104d4 sp:   506d58  __h_cback()

   Register dump at 00507fb4:

    a1:        0 a2:        1 a3:        2 a4:     8900

    v1:        1 v2:     8900 v3:        2 v4:        1

    v5: 20112df8 v6:      602 sl:        0 fp:       22

    ip: 20219fd6 sp:   506d58 lr:    104d4 pc:   34470c

    cpsr: 60000193

  003446f8 : .ð . : 11a0f00e : MOVNE   PC,R14

  003446fc : D.†å : e59c0044 : LDR     R0,[R12,#68]

  00344700 : .À…ã : e38cc002 : ORR     R12,R12,#2

  00344704 : D.…å : e58c0044 : STR     R0,[R12,#68]

  00344708 : .. ã : e3a00010 : MOV     R0,#&10            ; =16

  0034470c : H.…å : e58c0048 : STR     R0,[R12,#72]

  00344710 : .À ã : e3a0c001 : MOV     R12,#1

  00344714 : .ð á : e1a0f00e : MOV     PC,R14

  00344718 : __h_ : 5f685f5f : SWIPL   &685F5F

Actually, this is a bug in Unixlib, that ORR R12, R12, #2 should probably be ORR R0, R0, #2. I’ll sort it out.

Ok, this is now fixed in GCCSDK.

There’s an updated version of Sargasso 2.06pre4 here. The only change is it’s linked with the fixed UnixLib.

There’s an updated version of Sargasso 2.06pre4

That is working on the Titanium. Many thanks.

When I try to visit https://www.riscosopen.org.uk/forum/posts using NetSurf I get an error:

The certificate is for a different host than the server.

I can bypass this.

Is this connected with the Sargasso failure to load the RSS feed?

Does the actual fault lie with the certificate provided by the RiscOsOpen server?

After various attempts at updating certificates, my Sargasso 2.01 now fails on both ROOL and Rick’s feed with “unsupported protocol”, and Chris’ later versions always take-down various filers etcetera on this RPi running the current 5.27, though the latest version did appear to run for a second or so before disappearing with the usual train of errors as various other stuff failed in sequence.

Chris’ later versions always take-down various filers etc.

Not so the very latest updated version of Sargasso 2.06pre4. So thank you, Chris.

Back in business!

in connection with John Williams comment re !NetSurf. I am using !Netsurf 3.10 and that is flagging the forum pages as not having a valid certificate, but rest of ROOL site has a valid certificate.

I am using !Netsurf 3.10 and that is flagging the forum pages as not having a valid certificate

It is even odder than that. When I saw your post I noticed that indeed, there was a warning on the padlock icon, but expanding it to display the certificates did not identify what was wrong. Worse, when I looked at other forum pages some seem valid and some not! I cannot see the logic yet – the certificates look identical to me in all cases.

Indeed it is odd. I had not realised until you mentioned it you could click on the message from the padlock icon to see the more info.

I had contacted Andrew (webmaster) about this yesterday and he replied overnight to say there should be only two certificates so is puzzled by Rick’s upthread reporting of four certs – two expired. I have sent him all the info I had. But its looks like something is broken and seems to mainly affect the forum pages

Worse, when I looked at other forum pages some seem valid and some not! I cannot see the logic yet – the certificates look identical to me in all cases.

You need a better browser… :-)

Firefox (Linux) makes it fairly clear what is going on, when it says “Parts of this page are not secure (such as images)”. This page of this thread is affected, as Rick has linked in a screen shot from his website which is being served over HTTP. Since the browser has no way to tell if that’s desirable or not, it flags the problem up.

I’ve looked at this a few times, and invariably when there’s a warning, the page contains an image linked in from an insecure server.

There’s an expired root certificate causing issues elsewhere as well, like with wget on Debian. No idea whether that’s involved here, but the expiry date Rick mentioned looks suspicious.

https://lists.gnu.org/archive/html/bug-wget/2020-05/msg00043.html

as Rick has linked in a screen shot from his website which is being served over HTTP.

Private server, not website.
It’s WebJames. ;-)

Since the browser has no way to tell if that’s desirable or not, it flags the problem up.

Technically, any non-encrypted content on an encrypted site is unacceptable. But I think hell will freeze over before WebJames gains support for https. I put it there, as I can just dump it into the relevant directory and magically everybody else can see it.
Putting it on the real website is……

…….impossible under RISC OS. Needs a PC. Specifically, needs Windows running WinSCP (as I never got it to work under Ubuntu).

So, you can see why I drop screenshots and such into my WebJames served directory. ;-)

That said, there’s something else going on here with regards the expired certificate. Looking at the link that Frank posted, I wonder if one of the CAs screwed up?

But I think hell will freeze over before WebJames gains support for https

But perhaps HTTPServ will do that one day :)

Just seen this on The Register website relating to Sectigo AddTrust lagacy root certificate and they seem to be the ones that created the issue in Sargasso and showed as expired in a check of RISCOSOpen.org.uk certs.

https://www.theregister.com/2020/06/02/sectigo_root_cert_expires/

they failed at exactly the time the issue on here and Sargasso occured.

It’s what I referred to yesterday. The libraries are out of date. They should have moved away from that old certificate ages ago.

It’s what I referred to yesterday. The libraries are out of date.

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

Have we compromised security, worked around this problem, or what?