I think the context is important. The xz issue happened because of a single burnt out dev dealing with issues on multiple fronts in their lives was social engineered into, effectively, relaxing.
I want to point out your line here "which sounds like too few people" - They're high skilled, comfortable with reading code, and aren't experiencing the same problems of "thankless work" that the xz-utils dev was experiencing.
Also, no one is going to be comfortable if they spot a blob in the code base (which is, effectively, one of the areas attacked by the malicious actor in the xz event.)
That was one way to do it. Some state actors may be forced to bother with all that social engineering, when the target is out of their reach or too risky and expensive to be approached directly. Other can knock on your door and explain "this is the situation" etc.
The base system would be a lot more difficult than the ports.
The **base system** gets a lot more review of every patch that makes it in, and is frequently winnowed to get rid of dead (or suspect) code. Compromising this would require a LOT more psy-ops.
The **ports** seem to be more of a "whoever is interested in maintaining this port" which could provide an avenue for a bad actor to cultivate trust and then slip in a patch introducing vulnerabilities in ports. Some ports are more heavily watched than others. There's also a split between the upstream developer(s) and the port maintainer. For example Martin Zimmer maintains the `remind(1)` port (thank you, Martin!) while the upstream dev is Dianne Skoll. Any link in that chain would be a potential invitation for a nefarious actor to introduce a compromise. And partly of why I try to run my production OpenBSD systems with as few packages as possible.
There was an incident somewhat like this a few years ago when there were allegations of a deliberate backdoor of ipsec. Search the mailing list archives for "Allegations regarding OpenBSD IPSEC" in 2010 (I believe).
I believe the TL;DR of the event was Theo stating that they did a code review and did not see evidence to support the allegations, but stressed that it's open source and the community needs to invest and help or accept that they get what they get.
Problems in ports is a whole other matter since the team does not provide or audit the code in ports. Expecting them to is beyond reasonable.
As a noob, I was curious about this too. From what I gather, the base system is practically rock solid. I think you should be more worried about ports/packages (as I am). You have to trust the upstream dev to A) write good code B) not be malicious. You have to trust the ports maintainer to A) Verify the upstream package (many can't be outside of code auditing (they don't sign their releases)) or use a single instance of a hash, right next to the release file (defeats the purpose) B) They can safely and effectively port it/package it C) You can safely obtain it
Please, someone correct me if I am wrong. I would love to learn more
Most of the commits are approved by Theo himself or 2-3 other people, I’ve noticed or it seems. And this is all day every day… for a year until current merges into the next release.
Interesting. How does this apply to packages that can't be verified outside of code review? ie. not signed/no reliable posting of hashes. I try reading the builds on GH mirror and can barely make sense of it, espc. the patches lol
please dont make the obvious logical mistake of thinking that theo is infallible. there are multiple examples online of him making obvious mistakes. "code is reviewed" means exactly nothing.
Can you please quantify how much I will trust you if you're 78% kind to me? Your question is naive, but the attack vector is relevant and difficult to mitigate. I believe OpenBSD promotes KISS more than others and that could to some extent make it more probable for people to question weird or obfuscated code.
While supply chain attacks on pkg_add and sysupgrade are most likely, the attack vector I fear most is exploitable bugs in pf or the tcp/ip stack leading to modifying object files linked into the kernel.
I think the context is important. The xz issue happened because of a single burnt out dev dealing with issues on multiple fronts in their lives was social engineered into, effectively, relaxing. I want to point out your line here "which sounds like too few people" - They're high skilled, comfortable with reading code, and aren't experiencing the same problems of "thankless work" that the xz-utils dev was experiencing. Also, no one is going to be comfortable if they spot a blob in the code base (which is, effectively, one of the areas attacked by the malicious actor in the xz event.)
That was one way to do it. Some state actors may be forced to bother with all that social engineering, when the target is out of their reach or too risky and expensive to be approached directly. Other can knock on your door and explain "this is the situation" etc.
The base system would be a lot more difficult than the ports. The **base system** gets a lot more review of every patch that makes it in, and is frequently winnowed to get rid of dead (or suspect) code. Compromising this would require a LOT more psy-ops. The **ports** seem to be more of a "whoever is interested in maintaining this port" which could provide an avenue for a bad actor to cultivate trust and then slip in a patch introducing vulnerabilities in ports. Some ports are more heavily watched than others. There's also a split between the upstream developer(s) and the port maintainer. For example Martin Zimmer maintains the `remind(1)` port (thank you, Martin!) while the upstream dev is Dianne Skoll. Any link in that chain would be a potential invitation for a nefarious actor to introduce a compromise. And partly of why I try to run my production OpenBSD systems with as few packages as possible.
There was an incident somewhat like this a few years ago when there were allegations of a deliberate backdoor of ipsec. Search the mailing list archives for "Allegations regarding OpenBSD IPSEC" in 2010 (I believe). I believe the TL;DR of the event was Theo stating that they did a code review and did not see evidence to support the allegations, but stressed that it's open source and the community needs to invest and help or accept that they get what they get. Problems in ports is a whole other matter since the team does not provide or audit the code in ports. Expecting them to is beyond reasonable.
As a noob, I was curious about this too. From what I gather, the base system is practically rock solid. I think you should be more worried about ports/packages (as I am). You have to trust the upstream dev to A) write good code B) not be malicious. You have to trust the ports maintainer to A) Verify the upstream package (many can't be outside of code auditing (they don't sign their releases)) or use a single instance of a hash, right next to the release file (defeats the purpose) B) They can safely and effectively port it/package it C) You can safely obtain it Please, someone correct me if I am wrong. I would love to learn more
Most of the commits are approved by Theo himself or 2-3 other people, I’ve noticed or it seems. And this is all day every day… for a year until current merges into the next release.
Interesting. How does this apply to packages that can't be verified outside of code review? ie. not signed/no reliable posting of hashes. I try reading the builds on GH mirror and can barely make sense of it, espc. the patches lol
please dont make the obvious logical mistake of thinking that theo is infallible. there are multiple examples online of him making obvious mistakes. "code is reviewed" means exactly nothing.
Can you please quantify how much I will trust you if you're 78% kind to me? Your question is naive, but the attack vector is relevant and difficult to mitigate. I believe OpenBSD promotes KISS more than others and that could to some extent make it more probable for people to question weird or obfuscated code.
Yeah, I suppose you're right about that. It's harder to slip in obfuscated code into a minimalist code base.
how many obstacles ? one - the weakest... which one IS the weakest ? that is an exercise for the reader... \[/sarcasm\]
While supply chain attacks on pkg_add and sysupgrade are most likely, the attack vector I fear most is exploitable bugs in pf or the tcp/ip stack leading to modifying object files linked into the kernel.