Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl
Please consider the environment before printing this e-mail
On 20-06-2024 10:08, Alexander Kanavin wrote:
On Thu, 20 Jun 2024 at 08:55, Mike Looijmans <mike.looijm...@topic.nl> wrote:
Keep in mind that there are millions of released and installed systems out
there. Their owners will get very, very angry if a software upgrade locks them
out.
Desktop distros may be able to bluntly disable some protocols, because there's
always a user that has access and can patch things up, but embedded systems
often offer no access whatsoever apart from the SSH interface, so there's no
way to go in and "fix" it if something invalidates the keys on the system.
Hence my vote is for option 3 and please ignore what the big distros do.
Four years may seem long to some people. For embedded systems, that's just a
normal number that "uptime" would return.
I'm not sure I understand your point. Pushing software updates to the
field without first testing them locally is insane. If that practice
bricks the devices, I have no sympathy for the vendor.
Since products live much longer than LTS releases, new images will be released
based on newer OE versions.
Devices will have stored SSH public keys in their configuration area, and
updating the image will not touch that. So after upgrading the firmware, the
service engineer can still SSH into the box. This is the only way to get in,
there's no serial terminal, no password, nothing else.
If the SSH server suddenly refuses to use the existing RSA key, it will lock
them out with no chance of recovery other than a full factory reset which also
deletes all user/site data.
Testing is not likely to reveil this issue, as that's typically done on a
"clean" unit.
I've been made aware now, so I'll be sure to keep this in mind... But not
everyone follows this list.
Second, a change like this will not happen in LTS. LTS doesn't
(knowingly) break things, or add new features. In master, on the other
hand, it can and it should happen: a bit part of keeping things secure
is disabling or removing insecure crypto. Various upstreams do this
all the time, and I don't see why we can't.
All that's needed is to keep the RSA support in. At least for the next LTS. It
offers a migration path without a factory reset. One can log in, install new
keys and remove the old ones.
Having RSA support by itself doesn't make the system less secure. It only has
any effect if RSA keys are being used. Which new users won't do.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63374): https://lists.yoctoproject.org/g/yocto/message/63374
Mute This Topic: https://lists.yoctoproject.org/mt/106649419/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
