When is it ok not to open all source code?
gds.blog.gov.uk
gds.blog.gov.uk
#2: Hide the code/software that performs security-enforcing functions. Um... What? No. This is stupid. This is exactly the kind of thing you want out in the open so people can find flaws and let you know about them before "the bad guys" get ahead of you. It's Wizard of Oz security: Pay no attention to the software behind the curtain.
#3: Who cares? Why do they feel the need to justify delaying the release of code? Of course you'll want time to prepare it "for public consumption." As long as it gets opened up in a timely matter.
For example, suppose the government was going to establish a new video codec for its own video releases (ie, suppose that Dirac doesn't exist). There are several options: create a new and unencumbered license, negotiate a license for an existing system, or purchase the patent right from the patent holder.
The final choice depends on the cost to develop a new codec, the success of that codec, and the cost of buying or licensing the patent(s). The government can explore all of these at the same time, eg, set up a group to develop a new codec while negotiating with various rights-holders.
The new codec might be finished while the negotiating is ongoing. The government knows how well it fits their goals, but the rights-holders do not. This gives a negotiation advantage to the government.
On the other hand, if the completed codec were immediately published, that advantage disappears. The rights-holders might decide to raise their prices after seeing just how bad the new codec is, which makes the government goal of more open access to their video archives more expensive.
Thus, the government could rightly "judge the public interest not to be served by publishing [their] own software", even if, after the negotiations have completed, the software will be published.
Definitely going to use this.
2. Security by obscurity
Also, they list antivirus software as a security measure - all the more reason to publish it all so people with some actual expertise in IT security can have a look at it.
Not to mention the fact that big contracts with AV/security vendors are usually public knowledge and easily accessible. Heck, they probably have press releases indexed by Duck Duck Go!
I understand the argument that you want to show your code to smart people so you can proactively find and fix holes in it, but that's not always feasible or smart.
TLS? SSH? They are considered "secure" because the numbers they use are really, really, really obscure. So obscure that it would take too long to find them through any kind of naive search, to be useful.
Security is not binary, though. Anything that extends the naive search time extends the security. Even if hiding the source code only doubles the search time for an exploit, that's still an improvement.
Where people get in trouble is by overestimating the time extension. For example, by assuming that secret code can never be exploited because it's secret.
That's where the scorn for "security by obscurity" comes from. Not because obscurity is useless, but because the value of obscurity is so easily overestimated.
The useful distinction that is usually made between secrecy and obscurity hinges essentially on how easy it is to swap out the thing that's unknown to the attacker that security depends on. If your crypto key leaks, you generate a new one, and you are secure again, which is why the crypto key is a secret. If your source code leaks, no such thing, which is why hiding it is obscurity.
My uninformed guess is many people stick to the former.
* Transparency.
* The ability to fix it yourself.
Also consider this: No one submits patches to fix vulnerabilities in closed source software because that's not possible without the source. This results in all sorts of problems that just don't exist when the code is available:
* After reporting a vulnerability you now have to wait for the vendor to fix it. If the vulnerability isn't out in the open (yet) they might take their sweet time while you nervously twiddle your thumbs.
* If the vendor doesn't support the product anymore (or the vendor doesn't exist anymore) then there's really no options at all. You have to live with the vulnerability or get a new product.
* When the vendor releases a fix how do you know if they fixed the core vulnerability or just the edge case that was given to them? All too often vendors apply hacks to detect specific edge cases instead of fixing underlying problems. This is why attackers are able to take advantage of old vulnerabilities by means of simple fuzzing (or just being clever).
For example, I reported a horrific information disclosure vulnerability (SSNs in the clear) once and their 'fix' was to base64-encode the data. If I didn't keep track and follow up with them (took them four months to release that 'fix') it is likely that vulnerability would still be present.
There's actually a lot of other problems related to closed source vulnerabilities and fixes but I'm out of time...
Left a comment there but it's awaiting moderation. The GDS do a good job for the most part, but I very strongly disagree with how they're handling this one.