Slashdot Mirror
White House Releases Federal Source Code Policy To Help Government Agencies Go Open Source (whitehouse.gov)
dwheeler writes: The U.S. federal government just released a new Federal Source Code policy (PDF). For each of the next 3 years, at least 20 percent of custom-developed Federal source code is to be released as open-source software. Earlier this year, Tony Scott, Federal CIO of the U.S. government, wrote on the White House blog that the U.S. government "can save taxpayer dollars by avoiding duplicative custom software purchases and promote innovation and collaboration across Federal agencies." Today, they released the Federal Source Code policy. TechCrunch reports: "The main requirement is that any new custom source code developed 'by or for the Federal Government' has to be made available for sharing and re-use by all Federal agencies. For example, this means that the TSA can have access to custom made software that was commissioned by the FBI. Considering there is probably a great deal of overlap in applications needed by certain branches of the Federal Government, this rule alone should save the government (and taxpayers) a great deal of money. In fact, the policy states that 'ensuring Government-wide reuse rights for custom code that is developed using Federal funds has numerous benefits for American taxpayers.'"
I, the taxpayer, paid for it and demand that it's open. If it gets attacked, it will be fixed.
I can haz teh codez 2 HealthCare.gov? No thank U.
Security through obscurity is a phantasm. But closed source companies (and their sympathizers) continue to tout it.
This is not to say that open source has had no vulnerabilities. But far fewer than closed source, albeit closed source has more attackers.
Just a cheese promotion bait from Tony Scott before the Obama implosion.
Using the song "National Brotherhood Week" we can sing:
The NSA hates the FBI
The FBI hates the NSA
The Whitehouse Hates Wikileaks
and everybody hates the DEA
National Brotherhood Week
Haha
The source code should be secret, which will help keep out hostile countries.
Obscurity is not security. I'm more comfortable looking at a disassembly than I am with source code. The disassembly doesn't lie.
I'm a white hat, for the record. It's my job to help people, not inconvenience or hurt them.
I'd prefer it if trolls were hunted down by hungry dogs with steel fangs, castrated, and then sent to work in coal mines without air filters.
I guess neither one of us is going to get what we want.
The world's burning. Moped Jesus spotted on I50. Details at 11.
IME, writing code that is reusable is quite hard. Getting it into a form that using it in another project is worthwhile is costly. It'll be interesting to put in a FOI enquiry in a few years to see whether the benefits outweigh the costs.
I'd really prefer that federal agencies be secure against hackers. If they use open source, hostile countries like Iran and North Korea will be able to look for vulnerabilities in the code and more easily hack into the federal government. The source code should be secret, which will help keep out hostile countries. Security should be the primary goal, and therefore the source must be closed.
All this means is that you don't understand software security. There's no guarantee that open source is free of security issues, of course. But at the very least, it does mean that you're not depending on some "secret" in the code to remain secure, which is NOT any sort of security at all.
The most widely used security algorithms in the world are open specifications and have open source reference implementations, in case you aren't aware. These algorithms and implementations can never be proven secure except by their resistance to determined attacks over time, and this can only occur when they are publicly available for researches to work on ways to crack them.
Irony: Agile development has too much intertia to be abandoned now.
Public software from public money. The model works well for scientific software at NASA, ESA, CSA, etc.
If he didn't, there probably will be some large software companies that gladly give him Uber fare to the nearest bridge.
Don't worry, they only have to release 20% of the code as open source. All the Norks will get is several thousand new implementations of left-pad.js every year.
"is meant to be read by people" -- it's the law now motherfucker! hahaha!
The original article doesn't use Open Source as a term. Why does the editor add it as a buzzword?
They're sharing code across Federal agencies only.
Big problem here: a lot of software where the functionality could be reused can't be reused because it wasn't written for reuse. It'll have a lot of instance-specific code scattered throughout, for example logging functions that're specific to the system it was first written to run in. The result is it's easier and faster to write it from scratch than to try and remove the instance-specific code from the original source to make it suitable for use somewhere else. An open-source policy doesn't need just a mandate for reuse, it needs a mandate for making software reusable at the time it's written. That, unfortunately, is something any developer can tell you is really hard to get management to agree to.
I don't honestly care if the software is open source, use what works best regardless of whether RMS approves or not. What I really want to see instead is publicly accessible document management for the laws and regulations. I want to be able to determine exactly who entered in every single word, made every single edit, and when they were committed to the document. No more "I don't recall who added that" or "I have no idea who made that change". And make sharing a login a felony, so a member of Congress can't give out their login credentials to their entire staff and then disavow personal responsibility. If someone pastes in 5 pages from a lobbyist late at night hours before the vote, I want to know precisely who did it and under what circumstances. Full transparency, right down to the single word or punctuation mark. The technology is cheaply available right off the shelf, they could implement GitLaw across the entire government by year's end for less than they spend on lawyers to defend FOIA lawsuits in a single quarter.
You're just jealous 'cuz the voices talk to *me*
From: https://18f.gsa.gov/2014/11/26...
Security and open source
"System security should not depend on the secrecy of the implementation or its components."
-- Guide to General Server Security, National Institute of Standards and Technology
A codebase is a terrible secret.
Because a codebase is so large, it cannot easily be changed. Furthermore, it must be known, or at least knowable, to the large number of people who work on it, so it cannot be kept secret very easily. This is represented at the bottom of figures two and three. Therefore "security through obscurity" is a terrible idea when it comes to a codebase. In most cases your system will consist of code which you reuse as well as code that your write yourself. Therefore both of these types of code should be open.
Of course, your system will have secrets in most cases -- keys, passwords, and the like -- but you should assume they have been discovered and change them often. We call these secrets a "red thread", because, like a red thread in a white handkerchief, they should be as vivid and thin as possible. By making them thin, such as a single password, you make them very easy to change and keep secret. Although these secrets are tiny, they must be managed carefully and conscientiously. We believe this concept is so important that we have placed it on our reusable version of the Wardley-Duncan map linked to above.
There are risks of defects and complexity associated with using open source modules indiscriminately. There are also security vulnerabilities to any system, either through negligence or by the intention of a bad actor. The key to preventing this is code review.
You must make sure that each component you use is code reviewed. In practice this means either that you must use very popular projects whose code is looked at by a large number of people on a regular basis, or you must use small projects which your team can code review itself. In practice, the criteria for making this decision for reused components is similar to the rules of thumb that we have already laid down for managing risk.However, you may need to adjust these rules of thumb based on how often you plan to update the component.
For example, a small component which is very stable need not be updated at all. If it is small and you can code review it or pay a team to code review it, then you may use it. On the other hand if the project has frequent updates, your team will have to decide how to manage these updates. A large project may have both stable and experimental branches. In general your team will want to update as frequently as the major number of the branch. If the project is very active and many people are looking at it, this does not represent a security risk. If however a project is changing rapidly and producing many releases and your team does not have the resources to ensure that each new release is code reviewed and you do not trust the community to do so, then you probably should not use that component.
With an open source component, it is at least possible to understand how much code review it is receiving.We know of no way to do this for closed source code kept as a secret.A firm which is asked to maintain the security of the code that it has written is placed in a conflict of interest. It isn't in its short-term interest to spend resources on this code review, and it is not in its short-term interest to admit defects.
Security of your own code
Make all your code open and examinable from the start. Moreover, it is best to encourage as many people to look at it, because the more people who seriously review the code the more likely a security flaw is to be found. Programmers will code more securely when their code is in the public's eye from the beginning.
Code that you write or contract to have written should be open source from the start, because it relieves you of the terrible risk and burden of maintaining the secrecy of the codebase. This means not only that it is published under an open source license as explained in our open source policy, but that it is published in a modern source code control system.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
So we should have a government repository that's available and open for hosting the code, right?
No, thank you!
Most of that government code is shit written by someone who doesn't know what they are doing either through inexperience or incompetence hired by the lowest contact bidder.
I know because I've seen and rewritten some of it because it was utterly wrong, wrong and um... wrong.
Wouldn't it be dependent on the project, the maintainers, the organization, the feedback mechanisms and the underlying structure of the code to begin with?
Or should we get into a "Which is better, Chocolate or Vanilla?" thing.
Open source projects managed by systems like GitHub and forums are often maintained very well. But there are hundreds of projects placed into the open source that are left floating with no support for every one project which actually has a support infrastructure.
Federal contracts work in such a way where the code will now be made open (at least within the federal government) and once the contract is half way done or delivered, the contractors will be moved to something else and the code will die a slow painful death with no support.
Closed code itself isn't more secure than open source. They are exactly the same. It's how well they were made and how well they were maintained that matters. What really matters is whether there's an organization that is supporting the product open or closed. If a company prefers their code to be closed and that they maintain it themselves, that's their choice. The government should however require that they receive a source license to all code they use.
Hello,
I did not see any mention of a bug bounty program. Is there one? If the federal government would like to not just have its open sourced software reviewed but actually receive reports of bugs, they should consider adding a bug bounty program to encourage programmers to report any errors they find to the federal government, instead of selling it to an adversary.
Regards,
Aryeh Goretsky
Dexter is a good dog.
At the _minimum_ a source code escrow service, so if a contract is left unfinished or a business files for bankruptcy, the work made can be picked up by others and things continued. If I were paying someone megabucks to write up something, either the source code will be part of the contract, or it will be escrowed so that one party doesn't have a monopoly.
Has 'open source' been redefined to mean nothing more than custom government software being shared with other branches of the same federal government?
He went open source, like all the villians!
It's also a myth that closed source is truly closed, the source code is out there somewhere and malicious parties certainly have the source for various closed source software.
The difference is that when the only way to obtain the source is illegal, legitimate whitehat researchers won't be able to look at it which gives the upper hand to those who don't care about legality. With open source, everyone has equal access.
It's also not really true that closed source has more attackers... Most networks place devices running open source code in front of devices running closed source to protect them (eg most firewalls and other security appliances are linux or bsd based), and there are many systems out there running on open source which would be highly sought after by various blackhats (eg the fastest supercomputers in the world run linux). There are plenty of people attacking open source code, and plenty of motivation for them to do so.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Is there overlap in operating systems, database engines, data table layout, numeric encoding? A language like SQL was designed to bring platform independence to database processing. That still doesn't cover the issue of data mapping (eg. letters or digits). Solve that and the UI for every system can use the same mapping and same source code at least. That doesn't cover the transaction engine since each department will have it's own rules on what happens to a (Age: 29, Income: 50,000, Married: no) tuple.
Wether code is open or closed has no relevance on the decision of the original authors to continue supporting it, the two things are not directly related at all.
Many closed source projects also cease being maintained, you just don't see the code languishing on github because its languishing on an internal code repository at the original vendor instead.
Some vendors decide to open source code that they no longer have any interest in, but the fact they're open sourcing it is not the reason they've lost interest in it - that's usually already happened or would have happened anyway. Open sourcing in this instance is just the equivalent of leaving goods on the curb with a "free to a good home" sign.
If closed source code is unmaintained the code is dead... If you use or depend on that code you're screwed.
If open source code is unmaintained the opportunity exists for someone else to take over maintenance. If the code still has users, those users can take over maintenance themselves or band together to do so. If noone is using the code then it doesn't really matter and it remains online as an educational reference which may still help someone in the future.
Being open presents additional opportunities which being closed does not, and being closed does not prevent code from ending up abandoned and unmaintained.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
> The disassembly doesn't lie.
When you're debugging it, it's merely incorrect. I wish you luck understanding what it was _supposed_ to do.
When the Air Force first was mandated to use SharePoint to make electronic documentation easier, no thought was put toward storage of the imagined electronic documents. Personnel were told they had to use it before storage was available. That was obviously not possible.
This sounds much the same. You're not looking for just a place where you can upload/download a folder of files. If you want a repository, seriously, use Github as your example. You're going to need a dedicated data center with redundant backup (if it's important, you want to keep it, right?). Also, there are serious user interface and model concerns. You want people to be able to commit new versions of documents in an authenticated/non-repudiatable manner. You will want to be able to see the log of all changes and be able to revert to any version of the document. You will also want search features, by text in the files, by user, and by filename. A step up from that would be some way to group duplicate versions of documentation (if this was performed on documents automatically, it could reduce the amount of storage needed at the expense of processing) and show where they branch, as well as be able to select any part of the tree easily, as well as see who is involved with each branch. The available tools to do this kind of thing could use a huge ease of use upgrade.
DISA does have a repository, but now they are charging for any use of it, in a fashion which is not necessarily provided for in agency budgets, and it does not have the above functionality - it is more of a place where static projects are hosted, which is not what is required.
I've been using Linux and FreeBSD for half my life and have released a couple projects on sourceforge/freshmeat, so believe me when I say I love open source software. However, it has its place.
I work for a small company that mainly does government contracting. Some of this includes custom software, much of which is developed partly under SBIR funding. The whole point of the SBIR program is to create products for the government which can also be marketed for a profit. While some of our contracts require us to provide source code for our specific government customer, we'd be in a bad business position if we had to give it away to any/all contractors for potential re-use. As we cater to a niche market, our product being rebranded and sold by another company would severely hurt our business.
Putting that aside, another huge problem would be searching for useable code. Say I need a function that does XYZ on a data set. I can spend a week writing and testing this. Or... I can spend a day searching for it in some mess of a function catalog that we all know will be poorly implemented, spend another day filling out the required forms to get access to this function, wait a few weeks for this to be processed (hands-off at least, but still downtime), use another couple days reading the documentation and figuring out the interface, take time writing go-between code because it expects its data to be organized differently, and messing with the results because it wasn't *quite* for the same application, then another day testing it out, and end up with a slower, larger program that takes just as long. And that's a good case scenario.
Unless I'm missing something there, but this just requires that code developed for one agency should be available to other agencies. Not that it should be 'open'.
This just sounds like 'we wanna get past licence agreements and not have to pay for it', not 'we want to make our code open'.
The government cannot copyright their own work so it would not be any type of open source license but instead public domain.
One example would be md5deep.
This guy clearly doesn't understand how cut-throat and back-stabbing federal contracting is. People will throw you under the bus in a heartbeat if it means they can weasel their way to a contract ahead of you. Hardware is easy to duplicate/copy, software is not. By forcing private industry to give up their intellectual property rights opens the door to well-connected contractors stealing from the little guy.
Not so. It's true that the policy focuses more on sharing within the federal government, but it also specifically requires that at least 20% of the code be shared with the public as OSS. It's a start.
- David A. Wheeler (see my Secure Programming HOWTO)
I don't think that "open source software" has been significantly redefined. Here's the definition of Open Source Software in this memo: "Software that can be accessed, used, modified, and shared by anyone. OSS is often distributed under licenses that comply with the definition of "Open Source" provided by the Open Source Initiative (https://opensource.org/osd) and/or that meet the definition of "Free Software" provided by the Free Software Foundation (https://www.gnu.org/philosophy/free-sw.html)." That's a little laxer than I'd prefer, but it seems reasonable enough.
- David A. Wheeler (see my Secure Programming HOWTO)
My take is that it's just the ability to share the codebase; the policy does not set up a common program office for each and every software development acquisition. If you have an issue, you now have the means to fix it but it will not be fixed on your own behalf. That requires money and I'm sure Program Managers and their sponsoring SES's will use this as another posturing tool in the coming years.
It will help if it's not bastardized or explicitly written out of contracts by contractor collusion to the point where no one will bid on a contract specifying this Policy as a requirement (like with attempts to implement fixed fee contracts)
Open source does not mean that it has to be community developed. It means that the customer (the part of the government paying for it) must receive a bunch of rights along with the source code, including the rights to modify and distribute the code. On the same front page as this is a story about the Metropolitan Police having 27,000 computers still running Windows XP, which has known remotely exploitable vulnerabilities. The biggest reason for companies sticking with old versions of Windows is that they have some bit of software that doesn't work with Windows 7 and doesn't have updates. If a branch of the government has some open source software that doesn't work with their new OS, then it's 'just' a matter of cost to fix. They won't have problems where the original supplier has gone out of business, or isn't interested in producing a new version, or wants to sell you a different and incompatible product. They can always pay someone to port the code to the new OS, and then decide whether it's cheaper to do that than to migrate to a different system.
I am TheRaven on Soylent News
Oh this time it is about how cool and hip the White House is now. 20 trillion in debt and now the White House is going open source.
Isn't that fucking swell guys?
Will it be open source DRM? or is that next story where some Iranian-Russian alliance tried to hack it so they had to put cop protections in it?
Will it be available for Pokemon GO?
How FBI is Slashdot? They shit walkie talkies.
I spy a troll....
http://www.schlockmercenary.co...