What are you actually proposing here? Any Ubuntu/Debian distribution contains hundreds or thousands of packages and transitive dependencies - it's unreasonable to expect corporations to contribute, even financially, to all of these.
This is supposed to be what services such as Tidelift provide - companies pay them, and OSS maintainers sign up with them for funding (and other support? unsure). But it's tough to apply this through the whole OSS ecosystem. To me, this should be what Canonical's support contracts should be for. They're perfectly positioned to help mediate these types of issues.
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?
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.
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.
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.
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.
What are you actually proposing here? Any Ubuntu/Debian distribution contains hundreds or thousands of packages and transitive dependencies - it's unreasonable to expect corporations to contribute, even financially, to all of these.
Why is it unreasonable?
I actually see it as very reasonable. You use a package in a commercial distribution, you use aggregators like Github sponsors to pay the maintainer (a subscription, not a one-off payment!). What's unreasonable about that?
I don't really see how paying the maintainers helps against insider threats. The users still has to ensure that the software is safe.
Paying the maintainers is nice, but I think the megacorps and governments has to fund an organization that does security audits of all the sensitive packages, instead of heaping yet another job on the shoulders of the maintainers. It's especially important to not saddle the developers of open source with red tape, most of them would think that getting paid is poor compensation for the lost freedom.
See the rest of my comment, where I propose using an aggregator. I think it's unreasonable to expect everyone to engage in support contracts individually with every maintainer.
Proprietary Unix vendors used to develop all the system libraries and utilities. It's very much doable, especially if the responsibility is split across Linux vendors. Vendors need to take a critical look at what they're using, who develops it etc.
Comments
What are you actually proposing here? Any Ubuntu/Debian distribution contains hundreds or thousands of packages and transitive dependencies - it's unreasonable to expect corporations to contribute, even financially, to all of these.
This is supposed to be what services such as Tidelift provide - companies pay them, and OSS maintainers sign up with them for funding (and other support? unsure). But it's tough to apply this through the whole OSS ecosystem. To me, this should be what Canonical's support contracts should be for. They're perfectly positioned to help mediate these types of issues.
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?
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?
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?
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
Why is it unreasonable?
I actually see it as very reasonable. You use a package in a commercial distribution, you use aggregators like Github sponsors to pay the maintainer (a subscription, not a one-off payment!). What's unreasonable about that?
I don't really see how paying the maintainers helps against insider threats. The users still has to ensure that the software is safe.
Paying the maintainers is nice, but I think the megacorps and governments has to fund an organization that does security audits of all the sensitive packages, instead of heaping yet another job on the shoulders of the maintainers. It's especially important to not saddle the developers of open source with red tape, most of them would think that getting paid is poor compensation for the lost freedom.
See the rest of my comment, where I propose using an aggregator. I think it's unreasonable to expect everyone to engage in support contracts individually with every maintainer.
Proprietary Unix vendors used to develop all the system libraries and utilities. It's very much doable, especially if the responsibility is split across Linux vendors. Vendors need to take a critical look at what they're using, who develops it etc.
Open source community currently discovering that charity doesn't work and why governments need taxation to provide services. Libertarians in shambles.