Hacker News Reader

Comment by michelsedgh | Hacker News Reader

Im proposing that high security packages like this that effect ssh and main parts of the OS critical for security and safety should be maintained by actual enterprises not by one developer. Im not saying they should maintain everything, only the high importance parts of it. They should make sure that one bad actor cant compromise the whole ecosystem. I really don’t think what im saying is that far out of reach or that crazy. Edit: also, why should a package like ssh have so many random dependencies? They should make sure these kind of packages have the least of dependencies especially on these kind of packages that have one maintainer to reduce the security risks?

View on HN

why should a package like ssh have so many random dependencies

It's worth noting that vanilla upstream OpenSSH DOESN'T depend on xz. The dependency was patched in by the major distros to better integrate with systemd - and it's (AIUI) a transitive dependency from systemd - even the patch doesn't use it, but it gets pulled in with other systemd stuff.

vanilla upstream OpenSSH DOESN'T depend on xz

that's what i believed as well, but i didn't take time to verify. and i didn't know about the details. thanks. as you describe it ssh still doesn't depend on xz (and why would it?) so part of the problem here is software architecture.

how is it possible that a seemingly unrelated dependency somewhere within systemd can affect and be exploited through ssh directly?

shouldn't it be possible to keep that separate?

doesn't openssh itself already implement some form of privilege separation?

how does software architecture here and in general need to change to prevent things like this?

i am sure somewhere these questions are already being discussed. i'd appreciate any pointers.

That is worth noting, thanks for posting this and letting me know.

why should a package like ssh have so many random dependencies

that's the critical question here. it's not that enterprises need to take over maintenance of xz, but that the critical packages and their dependencies need to be audited on a regular basis. the development of xz is ok. what it needs is help with code reviews. and if it can't receive those, then it needs to be removed as a dependency of openssh.

Yes, exactly, these high security packages that every distro uses must be very tightly maintained and looked over with the least dependencies. SSH is one of the most important packages in security and it just feels clumsy that they are using such packages like XZ. Just WHY? Who made that decision? Why doesn’t all the distros work together maybe to maintain the security? Why depend on one person that does this as a hobby?

> high security packages like this that effect ssh and main parts of the OS critical for security and safety should be maintained by actual enterprises not by one developer.

I don’t remember the company names, but I guess people will remember the incidents.

- Solarwinds have been breached end to end.

- A company has been bribed (forced?) to ship backdoored encryption algorithms.

- A network hardware supplier’s firmware had been backdoored by Chinese IIRC.

- NSA backdoored national standards.

- Microsoft has been breached end to end.

In short, even if you’re a company, you’re one NSL, one bad actor, one misstep away from “total pwnage”.

I trust some individuals for developing critical software than entire “enterprise”s.

Everything is as strong as their weakest link.

Actual enterprises do not have a better track record. I would go as far to say that if Big Corp maintained an SSH client and server then a lot of distributions would shun it out of distrust. How many products from actual enterprises phone home with telemetry or leak data in other ways?

> Edit: also, why should a package like ssh have so many random dependencies? They should make sure these kind of packages have the least of dependencies especially on these kind of packages that have one maintainer to reduce the security risks?

Using standard libraries for common stuff like compression, cryptography and whatnot is vastly more preferable over everyone shipping their own crypto, or worse, patches of crypto (see the Debian SSH key vulnerability of 2008 for an example [1]). For protocols it's in the end just as bad, it's a nightmare to keep different versions of the same program to be able to talk to each other, but now imagine a literal ton of programs who all have a wild mixture of statically shipped libraries, homegrown stuff that has barely been tested... no, just no. Not a world I'd like to live in.

[1] https://jblevins.org/log/ssh-vulnkey

Reply on news.ycombinator.com