UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbd in position 6: invalid start byte

[jciesla]

Explain what happens

In the latest versions of Cockpit I sometimes have difficulty opening files in the terminal tool with vim. The problem is intermittent but occurs often. Sometimes I can open the file, sometimes I can't (just a black screen), and sometimes I can open the file but the colors are changed.

Cockpit v321
Python 3.12.4
Kernel 6.6.35
Systemd 255

1. Open a cockpit session.
2. Open the terminal tool.
3. Execute vim to edit a text file.

By exemple, for editing the file /etc/e2scrub.conf (can be any other file) :

Edition is working as expected:

Edition is working but with other colors:

Edition is not working:

When result is not the expected (wrong color or not viewable), I get python errors on journald (please see the attached traces).

Version of Cockpit

~321

Where is the problem in Cockpit?

Terminal

Server operating system

other

Server operating system version

No response

What browsers are you using?

Chrome

System log

Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]: asyncio-ERROR: Exception in callback _Transport._read_ready()
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]: handle: <Handle _Transport._read_ready()>
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]: Traceback (most recent call last):
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:   File "/usr/lib64/python3.12/asyncio/events.py", line 88, in _run
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:     self._context.run(self._callback, *self._args)
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:   File "/usr/lib/python3.12/site-packages/cockpit/transports.py", line 110, in _read_ready
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:     self._protocol.data_received(data)
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:   File "/usr/lib/python3.12/site-packages/cockpit/channel.py", line 427, in data_received
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:     if not self.send_data(data):
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:            ^^^^^^^^^^^^^^^^^^^^
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:   File "/usr/lib/python3.12/site-packages/cockpit/channel.py", line 318, in send_data
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:     return self.send_text(self.__decode_frame(data))
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:                           ^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:   File "/usr/lib/python3.12/site-packages/cockpit/channel.py", line 227, in __decode_frame
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:     return self.decoder.decode(data, final=final)
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]:   File "<frozen codecs>", line 322, in decode
Jul 22 16:30:14 hw-ovf21 cockpit-ws[2879]: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbd in position 6: invalid start byte

[jelly]

Thanks for the bug report, this is fairly easy to reproduce:

my_bytes = 'hello ÿ'.encode('utf-16')
open('foo.txt', 'wb').write(my_bytes)

Then in cockpit, cat foo.txt and see errors in journal.

@allisonkarlitskaya are you interested in fixing this?

[allisonkarlitskaya]

Possibly related: #20628

[allisonkarlitskaya]

@jciesla can you please elaborate on "latest versions"? Is there a known version of Cockpit that this definitely does not occur with?

[allisonkarlitskaya]

This is caused by this line:

            self.decoder = codecs.getincrementaldecoder('utf-8')(errors='strict')

Having the decoder in strict mode is probably a bad idea. We ought to loosen that up to ignore/replace/surrogate errors. Replace, I guess.

[jciesla]

Hello @allisonkarlitskaya, on version 300.3 the problem is definitely not present. I tested with versions 321 and 318. On version 318 the problem occurs but less often (no black display, only colors issue).

[martinpitt]

@allisonkarlitskaya No, no, no. This is the protocol level, strict errors was very deliberate. I'd hate to introduce "let's try to interpret junk as something interpretable" on that low level. This is a websocket, and it's UTF-8 (which is what triggered the whole commit 1b15dcb in the first place). In situations where we can't guarantee UTF-8 or anything else, IMHO the only correct option is binary: "raw".

[martinpitt]

... and of course the bridge shouldn't crash unceremoniously like that, but close the channel with protocol-error.

[martinpitt]

This is a lot more subtle than it appears. First of all, __decode_frame() already catches UnicodeDecodeError and is supposed to close the channel with protocol-error. This somehow doesn't happen.

I created a new unit test:

@pytest.mark.asyncio
async def test_fsread1_invalid_utf8(transport: MockTransport, tmp_path: Path) -> None:
    f = tmp_path / 'valid'
    data = b'hello' + bytes([0xFF, 0xFF]) + b'world'
    f.write_bytes(data)
    ch = await transport.check_open('fsread1', path=str(f))
    transport.send_done(ch)
    await transport.assert_msg('', command='close', channel=ch, problem='protocol-error')
    transport.send_close(ch)

but instead of failing, it receives exactly "helloworld" (without the broken binary junk) both on current main and with commit 1b15dcb reverted.

[martinpitt]

Ah, this is because the fsread1 channel is outright evil!

                    if not self.is_binary:
                        data = data.replace(b'\0', b'').decode(errors='ignore').encode()

I.e. it silently gives you wrong information. This should be fixed separately, and I'll do this with the http channel.

[martinpitt]

Fixed in #20840

[jciesla]

Thank you for the fix. I tested on my side and all is now working correctly.