3 ms·

> Honest question, what is your source for this? Is it opinion or is it part of some declaration from some group? > What happens when a developer is also a use

> Honest question, what is your source for this? Is it opinion or is it part of some declaration from some group? > What happens when a developer is also a user? As I get it, for this particular developer, the end effect is the same. I think the parent comment's point was that open source doesn't mean everyone is entitled to contribute back to the main project. As a user you may be a developer by trade, and you are certainly free to modify and share the source code, but the project maintainers are free to not include your changes back into their repository. A prime example of this is SQLite, which is open source despite the fact that they don't accept code submissions outside of the core team. >> They're trying to keep Iranian contributors out of the code base because they fear the Iranian government can lean on him to plant malicious code. > This is not a threat vector, not really. It really is. The Linux kernel has itself thwarted what appeared to be an attempt by U.S. intelligence services to inject vulnerabilities into the kernel source code. Now the fact that the U.S. government was itself the threat may make worries about Iran doing the same seem rather silly, but in this case I think the fact that Fedora source code is used by the DoD makes sense. All this to say, I'm certainly not happy about this situation. A big part of the spirit of open source is to overcome our differences in an attempt to solve shared problems. That's why the OSI definition of open source requires that open source licenses not discriminate against persons, groups, or fields of endeavor. That being said, however much open source may not want to be interested in politics, it is certainly true that politics is interested in open source.

csydas 5y ago
I appreciate all that, but at least with the example of SQLLite, that's a decision by the developers, not because of an external influence (presumably). My issue here is that a government has decided that a specific country is not allowed to participate in open source; yes, Redhat implemented it, but they did so out of fear of retribution from the US government and because their understanding is that the US government required it. Maintainers controlling what gets into the project is not the same as a foreign entity not at all contributing/participating in a project declaring who can and cannot participate. >It really is. The Linux kernel has itself thwarted what appeared to be an attempt by U.S. intelligence services to inject vulnerabilities into the kernel source code. Now the fact that the U.S. government was itself the threat may make worries about Iran doing the same seem rather silly, but in this case I think the fact that Fedora source code is used by the DoD makes sense. I think this is tangential though to what I'm saying. It's not about whether or not attacks like this __are possible__, it's that there's absolutely no reason that a contributor from a specific region is any more of a threat than any other. Nothing stops Iran or any other sanctioned country from getting US based VMs + crypto and slipping/sneaking in some code. It's not about if a specific country makes a backdoor, it's "is there a backdoor at all?" Any secret backdoor snuck in for sale by an interested party is just as usable by a given government as one made by Iran. For me, it just falls flat as a real security analysis; heck, I imagine a sick irony where a US created back-door inserted by one agency ends up being used to leak data from another agency. A backdoor is a backdoor.

csydas 5y ago

I appreciate all that, but at least with the example of SQLLite, that's a decision by the developers, not because of an external influence (presumably). My issue here is that a government has decided that a specific country is not allowed to participate in open source; yes, Redhat implemented it, but they did so out of fear of retribution from the US government and because their understanding is that the US government required it. Maintainers controlling what gets into the project is not the same as a foreign entity not at all contributing/participating in a project declaring who can and cannot participate. >It really is. The Linux kernel has itself thwarted what appeared to be an attempt by U.S. intelligence services to inject vulnerabilities into the kernel source code. Now the fact that the U.S. government was itself the threat may make worries about Iran doing the same seem rather silly, but in this case I think the fact that Fedora source code is used by the DoD makes sense. I think this is tangential though to what I'm saying. It's not about whether or not attacks like this __are possible__, it's that there's absolutely no reason that a contributor from a specific region is any more of a threat than any other. Nothing stops Iran or any other sanctioned country from getting US based VMs + crypto and slipping/sneaking in some code. It's not about if a specific country makes a backdoor, it's "is there a backdoor at all?" Any secret backdoor snuck in for sale by an interested party is just as usable by a given government as one made by Iran. For me, it just falls flat as a real security analysis; heck, I imagine a sick irony where a US created back-door inserted by one agency ends up being used to leak data from another agency. A backdoor is a backdoor.