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'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.
I can haz teh codez 2 HealthCare.gov? No thank U.
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
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.
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.
"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.
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.
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!
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.
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)
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.
http://www.schlockmercenary.co...