“All code paid for by taxpayer dollars should be open source, available for comment, for feedback, for people to build on and for people in other agencies to replicate. It saves everyone money and it is our [taxpayers’] IP,” she said. “This is just good government and should absolutely be the standard that government technologists are held to.”"
Nice sentiment, but bad take. Open-sourcing the software that runs our military equipment would be a fantastic gift to the bad actors of the world.
So open sourcing Tor, which protects our foreign operatives, was a bad idea? Implementing secure sockets for the web (TLS) was a bad idea? Publishing security vulnerabilities publicly (CVE system) was a bad idea?
All of those help our adversaries, but our adversaries also have an incentive to improve the code so everyone benefits.
Sure, there are probably some things that shouldn’t be released (i.e. something w/ a legitimate national security concern), but by and large, most things should. Tax software absolutely should, because there’s zero reason for the software you use to file your taxes (which is a legal requirement) to not be publicly auditable, because you’re on the hook for any mistakes it makes.
Security can mean security against hackers, but it can also mean security against revealing classified information. Classified information about weapons systems (e.g. performance characteristics) is inherently embedded into the code running on those systems, and therefore shouldn’t be open sourced.
Any information that shouldn’t be public knowledge such as specs, account credentials, access tokens etc should be in a configurable/dynamic format such as an ENV variable or a config file, that way confidential info isn’t part of the working tree.
This should not be an issue in a properly maintained codebase.
Eh, there’s an intrinsic amount of information about the system that can’t be moved into a configuration file, if the platform even supports them.
If your code is tuned to make movement calculations with a deadline of less than 50 microseconds and you have code systems for managing magnetic thrust vectoring and the timing of a rotating detonation engine, you don’t need to see the specific technical details to work out ballpark speed and movement characteristics.
Code is often intrinsically illustrative of the hardware it interacts with.
Sometimes the fact that you’re doing something is enough information for someone to act on.
It’s why artefacts produced from classified processes are assumed to be classified until they can be cleared and declassified.
You can move the overt details into a config and redact the parts of the code that use that secret information, but that still reveals that there is secret code because the other parts of the system need to interact with it, or it’s just obvious by omission.
If payload control is considered open, 9/10 missiles have open guidance control, and then one has something blacked out and no references to a guidance system, you can fairly easily deduce that that missile has a guidance system that’s interesting with capabilities likely greater that what you know about.
Eschewing security through obscurity means you shouldn’t rely on your enemies ignorance, and you should work under the assumption of hostile knowledge. It doesn’t mean you need to seek to eliminate obscurity altogether.
I think when it comes to the code that controls the navigation, control, detonation, etc, or our munitions, that perhaps that should not be publicly reviewable. Not because of hacking concerns, but it does give info to a potential enemy that could render them less effective.
A lot of functionality can be decoupled from anything that needs to be classified. A HUD is a HUD and no one should be hard coding in performance characteristics of the F-35 into it. I’ve also worked on government projects and holy crap does the code quality vary wildly, even before you get into “it’s still working so deal with the problems, it doesn’t have the budget for updates”.
Using ‘off the shelf’ parts/code can save significant time and money. There’s a reason subs use xbox controllers. Government websites and data interfaces at the very least should have the audit-ability that open source provides.
sure but the HUD from the F-35 is very specifically designed to work in an F-35. It’s very similar, and comes from the same family, as the software running on other planes. But it’s not identical.
And yes, performance limits would be hard coded into the software because the HUD needs to alert the pilot when they are getting close.
Edit: and that’s ignoring the fact that a lot of this stuff comes from private companies so you’ll run into things like IP/patent laws
That’s what config files are for. It would be a nightmare to hardcode weight and balance and have to recompile the HUD every time you change the loadout or refuel the plane.
Most code, algorithms, etc are not any more sensitive than the concept of desks and file cabinets. No, guidance programs for missiles probably shouldn’t be put on GitHub, but there’s a reason RSA and other encryption algorithms were open sourced. It’s better to have more eyes looking for inefficiencies, weaknesses, and vulnerabilities than to just assume it’s good because no-one on the team responsible is smart/engaged enough to find them.
For the F35 unfortunately a lot of its capabilities seems to be cloud based. (At least for maintenence, I don’t know of on the air).
That’s why I’m angry my stupid government still has wants to buy the stupid things instead of sitting this generation out and going to an own 6gen aircraft.
Yes, I agree, so as Vlad learned even if you leave them on the ground and put tires on them so they don’t fly off, something might come along and successfully migrate around 40 of them to the cloud.
If it’s developed for the government, even by a private contractor, it’s still considered US government code and is public domain. It’s why sqlite is public domain.
I personally doubt there’s much available in the off-the-shelf fighter HUD system market, personally.
Not all source code, documentation and metadata used in the development of Direct File is included in this repository. Specifically, any code or data that is considered Personally Identifiable Information (PII), Federal Tax Information (FTI), Sensitive But Unclassified (SBU), or source code developed for National Security Systems (NSS), as defined in 40 U.S.C. § 11103, is exempt. Due to these restrictions, certain pieces of functionality have been removed or rewritten.
The problem you’re describing (open sourcing critical software) could both increase the capabilities of adversaries and also make it easier for adversaries to search for exploits. Open sourcing defeats security by obscurity.
Leaving security by obscurity aside could be seen as a loss, but it’s important to note what is gained in the process. Most security researchers today advocate against relying on security by obscurity, and instead focus on security by design and open security. Why?
What’s the alternative for the military? If you rely on security by design and open security for military equipment, it’s possible that adversaries will get a hold of the software, but they will get a hold of software that is more secure. A way to look at it is that all the doors are locked. On the other hand, insecure software leaves supposedly secret doors open. Those doors can be easily bashed by adversaries. So much for trying to get the upper hand.
The choice between (1) security by obscurity and (2) security by design and open security is ultimately the choice between (1) insecurity for all and (2) security for all. Security for all would be my choice, every time. I want my transit infrastructure to be safe. I want my phone to be safe. I want my election-related software to be safe. I want safe and reliable software. If someone is waging a war, they’re going to have to use methods that can actually create a technical asymmetry of power, and insecure software is not the way to gain the upper hand.
I’m sure there are exceptions for classified systems. Personally, I do believe all things developed by tax payer money should be released to the public including classified systems, given enough time has passed that the release of such information wouldn’t put anything or anyone at risk.
For the most part they are. You can find enormous troves of classified documents that have been made public, and a huge amount of once top secret technology and engineering eventually makes its way into the public space.
You know open-source doesn’t mean publicly available. It means the person, or in this case the US government, that brought the software should have free access to the source code to edit and distribute it as they like.
So yes, the military should use something functional equivalent to open source to prevent vender lock in and to allow for external audits. They probably shouldn’t give it to Russia or make it freely available online though.
Ideally, any software the government buys or any firmware that ships on hardware the government buys should be FOSS, but not necessarily released to the public right away (i.e. if there’s a legitimate national security risk). That gives the government the option to fix issues they run into instead of being forced to wait for the vendor to fix them (if they ever do).
Don’t worry, that’s all written by defense contractors anyways, so they’ll sell it to the US, and to others the US allows, all closed source. The source won’t even be open to the US government, either, as that’d harm the bottom line of the contractor (support & maintenance contracts for that closed-source software).
I really don’t get why the government does this. The US government is a massive client, and they could probably force their suppliers to provide them an open source license so they can maintain it themselves. What else are military contractors going to do, not sell their guns? It’s not like the US gov is going to let them sell to countries we don’t like anyway, so it’s in their interest to play ball.
Watch this thread from here on in carefully separate the idealists from those who know what defence is like.
yes, open-source is the goal of everything that can be opened.
no, defence code isn’t on the list of what can be opened
yes, obscurity isn’t good as a sole effort
yes, defence in depth
no the funding to get it to where it’s safe to open for randos to submit changes isn’t there today
Anything I missed?
Yes, Virginia, it’s better to open all the things right now, but there are risks you haven’t taken into account because you’re not aware of them. The pros are; it’s their job and their work, so listen to their expertise no matter what the oppositional/defiant disorder suggests otherwise.
Defense code can absolutely be open source, even the very sensitive code that goes into guidance systems on rockets and whatnot. Open source != publicly available, it means those who receive the code get certain rights to use and modify the code. This is imperative for the US government to provide timely updates to their equipment if the vendor is doing a poor job at it.
Yes, it’s ideal to open source everything, but not ideal to release it to the public. Once the code is no longer sensitive (i.e. the equipment is obsolete), it should be released publicly.
Nice sentiment, but bad take. Open-sourcing the software that runs our military equipment would be a fantastic gift to the bad actors of the world.
So open sourcing Tor, which protects our foreign operatives, was a bad idea? Implementing secure sockets for the web (TLS) was a bad idea? Publishing security vulnerabilities publicly (CVE system) was a bad idea?
All of those help our adversaries, but our adversaries also have an incentive to improve the code so everyone benefits.
Sure, there are probably some things that shouldn’t be released (i.e. something w/ a legitimate national security concern), but by and large, most things should. Tax software absolutely should, because there’s zero reason for the software you use to file your taxes (which is a legal requirement) to not be publicly auditable, because you’re on the hook for any mistakes it makes.
security through obscurity is not security
Security can mean security against hackers, but it can also mean security against revealing classified information. Classified information about weapons systems (e.g. performance characteristics) is inherently embedded into the code running on those systems, and therefore shouldn’t be open sourced.
Source: used to write classified code
then the code maintainers are doing it wrong.
Any information that shouldn’t be public knowledge such as specs, account credentials, access tokens etc should be in a configurable/dynamic format such as an ENV variable or a config file, that way confidential info isn’t part of the working tree.
This should not be an issue in a properly maintained codebase.
Eh, there’s an intrinsic amount of information about the system that can’t be moved into a configuration file, if the platform even supports them.
If your code is tuned to make movement calculations with a deadline of less than 50 microseconds and you have code systems for managing magnetic thrust vectoring and the timing of a rotating detonation engine, you don’t need to see the specific technical details to work out ballpark speed and movement characteristics.
Code is often intrinsically illustrative of the hardware it interacts with.
Sometimes the fact that you’re doing something is enough information for someone to act on.
It’s why artefacts produced from classified processes are assumed to be classified until they can be cleared and declassified.
You can move the overt details into a config and redact the parts of the code that use that secret information, but that still reveals that there is secret code because the other parts of the system need to interact with it, or it’s just obvious by omission.
If payload control is considered open, 9/10 missiles have open guidance control, and then one has something blacked out and no references to a guidance system, you can fairly easily deduce that that missile has a guidance system that’s interesting with capabilities likely greater that what you know about.
Eschewing security through obscurity means you shouldn’t rely on your enemies ignorance, and you should work under the assumption of hostile knowledge. It doesn’t mean you need to seek to eliminate obscurity altogether.
I think when it comes to the code that controls the navigation, control, detonation, etc, or our munitions, that perhaps that should not be publicly reviewable. Not because of hacking concerns, but it does give info to a potential enemy that could render them less effective.
It seems to be working out fine in Ukraine…
A lot of functionality can be decoupled from anything that needs to be classified. A HUD is a HUD and no one should be hard coding in performance characteristics of the F-35 into it. I’ve also worked on government projects and holy crap does the code quality vary wildly, even before you get into “it’s still working so deal with the problems, it doesn’t have the budget for updates”.
Using ‘off the shelf’ parts/code can save significant time and money. There’s a reason subs use xbox controllers. Government websites and data interfaces at the very least should have the audit-ability that open source provides.
sure but the HUD from the F-35 is very specifically designed to work in an F-35. It’s very similar, and comes from the same family, as the software running on other planes. But it’s not identical.
And yes, performance limits would be hard coded into the software because the HUD needs to alert the pilot when they are getting close.
Edit: and that’s ignoring the fact that a lot of this stuff comes from private companies so you’ll run into things like IP/patent laws
That’s what config files are for. It would be a nightmare to hardcode weight and balance and have to recompile the HUD every time you change the loadout or refuel the plane.
Most code, algorithms, etc are not any more sensitive than the concept of desks and file cabinets. No, guidance programs for missiles probably shouldn’t be put on GitHub, but there’s a reason RSA and other encryption algorithms were open sourced. It’s better to have more eyes looking for inefficiencies, weaknesses, and vulnerabilities than to just assume it’s good because no-one on the team responsible is smart/engaged enough to find them.
Lmfao I can tell you’ve never worked in embedded systems before. They don’t really have config files. They don’t have the space.
For the F35 unfortunately a lot of its capabilities seems to be cloud based. (At least for maintenence, I don’t know of on the air).
That’s why I’m angry my stupid government still has wants to buy the stupid things instead of sitting this generation out and going to an own 6gen aircraft.
Aren’t all planes cloud based though?
Yes, I agree, so as Vlad learned even if you leave them on the ground and put tires on them so they don’t fly off, something might come along and successfully migrate around 40 of them to the cloud.
If it’s developed for the government, even by a private contractor, it’s still considered US government code and is public domain. It’s why sqlite is public domain.
I personally doubt there’s much available in the off-the-shelf fighter HUD system market, personally.
Uh, clearly you haven’t seen the quarterly earnings reports.
Our entire Internet, the backbone of all encryption, all runs on open source software.
It is more secure because people can see and audit the code.
Let me flip what you wrote:
Our military equipment already is vulnerable. We just don’t know how badly because it’s not open source.
Prove it’s secure by releasing the code.
I’m gonna be honest, I’m sure China has many copies of the source code already
The GitHub page has a section for this:
But does it build?!
Maybe it’s the military that’s incompatible with our values, not open source
yet just a few days ago, open source software was the key to destroying dozens of bomber planes in Russia
The problem you’re describing (open sourcing critical software) could both increase the capabilities of adversaries and also make it easier for adversaries to search for exploits. Open sourcing defeats security by obscurity.
Leaving security by obscurity aside could be seen as a loss, but it’s important to note what is gained in the process. Most security researchers today advocate against relying on security by obscurity, and instead focus on security by design and open security. Why?
Security by obscurity in the digital world is very easily defeated. It’s easy to copy and paste supposedly secure codes. It’s easy to smuggle supposedly secret code. “Today’s NSA secrets become tomorrow’s PhD theses and the next day’s hacker tools.”
What’s the alternative for the military? If you rely on security by design and open security for military equipment, it’s possible that adversaries will get a hold of the software, but they will get a hold of software that is more secure. A way to look at it is that all the doors are locked. On the other hand, insecure software leaves supposedly secret doors open. Those doors can be easily bashed by adversaries. So much for trying to get the upper hand.
The choice between (1) security by obscurity and (2) security by design and open security is ultimately the choice between (1) insecurity for all and (2) security for all. Security for all would be my choice, every time. I want my transit infrastructure to be safe. I want my phone to be safe. I want my election-related software to be safe. I want safe and reliable software. If someone is waging a war, they’re going to have to use methods that can actually create a technical asymmetry of power, and insecure software is not the way to gain the upper hand.
I’m sure there are exceptions for classified systems. Personally, I do believe all things developed by tax payer money should be released to the public including classified systems, given enough time has passed that the release of such information wouldn’t put anything or anyone at risk.
For the most part they are. You can find enormous troves of classified documents that have been made public, and a huge amount of once top secret technology and engineering eventually makes its way into the public space.
Yeah, they get open sourced by publishing them over the usual channels during disputes on the War Thunder discord server.
Well yeah, when someone on the internet is wrong, you need to prove it!
I am fairly confident that theNSA is aware of this kind of concern and they have an pretty cool repo.
Idk, they didn’t appreciate Snowden open sourcing a lot of their documents.
Depends on the application.
In some cases, it would be fantastic. But it’s clearly not a one size fits all, yeah.
You know open-source doesn’t mean publicly available. It means the person, or in this case the US government, that brought the software should have free access to the source code to edit and distribute it as they like.
So yes, the military should use something functional equivalent to open source to prevent vender lock in and to allow for external audits. They probably shouldn’t give it to Russia or make it freely available online though.
At least not while it presents a national security risk. Once it’s largely obsolete, everything should be made public.
I’m sure a lot of military software, in contrast, is acquired from private companies that retain IP rights. Likely legal exceptions aside.
Ideally, any software the government buys or any firmware that ships on hardware the government buys should be FOSS, but not necessarily released to the public right away (i.e. if there’s a legitimate national security risk). That gives the government the option to fix issues they run into instead of being forced to wait for the vendor to fix them (if they ever do).
Good thing no bad actors have root access!Agreed; open source software is so notoriously insecure.
Don’t worry, that’s all written by defense contractors anyways, so they’ll sell it to the US, and to others the US allows, all closed source. The source won’t even be open to the US government, either, as that’d harm the bottom line of the contractor (support & maintenance contracts for that closed-source software).
I really don’t get why the government does this. The US government is a massive client, and they could probably force their suppliers to provide them an open source license so they can maintain it themselves. What else are military contractors going to do, not sell their guns? It’s not like the US gov is going to let them sell to countries we don’t like anyway, so it’s in their interest to play ball.
Watch this thread from here on in carefully separate the idealists from those who know what defence is like.
Anything I missed?
Yes, Virginia, it’s better to open all the things right now, but there are risks you haven’t taken into account because you’re not aware of them. The pros are; it’s their job and their work, so listen to their expertise no matter what the oppositional/defiant disorder suggests otherwise.
Defense code can absolutely be open source, even the very sensitive code that goes into guidance systems on rockets and whatnot. Open source != publicly available, it means those who receive the code get certain rights to use and modify the code. This is imperative for the US government to provide timely updates to their equipment if the vendor is doing a poor job at it.
Yes, it’s ideal to open source everything, but not ideal to release it to the public. Once the code is no longer sensitive (i.e. the equipment is obsolete), it should be released publicly.