Slashdot Mirror
Can Open Source Be Trusted?
"I also menitoned OpenBSD to him as an example of a secure system that was open source. I argued that it was exactly because of the OpenBSD/FreeBSD development model (i.e. closely controlled with a top down hierarchy) that it was able to be more secure. Dr. Spafford still felt that OpenBSD did not fit the criteria of a well-trusted system: because it was not designed to a formal spec, and there are no formalized tests or standards being applied to it. Are there some ways in which we can get OpenBSD more trusted by testing it against some infosec standards?
For the rabid reader, I would just like to point out that Dr. Spafford NEVER disagreed with the 'more eyeballs means less bugs' tenet of faith that so many open source advocates preach. He just felt this was irrelevant to his point--how do you judge whether a system is more trusted than another system when there was no design spec or goals listed out to which to test the system against?
All in all, it was a challenging lecture. I felt myself start to get irritated, but by the end of his lecture, I was convinced he had a good point. How do you think we can address his criticisms?"
Honestly, I would say the same thing about a lot of commercial software as well. Just because you sell something doesn't mean that it's been designed properly, and likely just because something is free doesn't mean it's been slapped together with duct tape. Further more I'd trust a program with source more than one without and many open source developers are always willing to accept a better design. I'd also like to say that just because there aren't many pieces of Open Source that proceed with fully documented design goals, that this won't always be the case for future projects.
"His assertion is that Open Source systems such as Linux are developed in too chaotic a system to ever reach a trusted state. "
What does the way something is developed have to do with the final product (or a given release), and the tests performed on it? You are testing the product, not the developement environment, surely?
Basically, he's right. All he's saying is that with no formal design spec or test process, a system can't be considered secure. Yes, we have some design specs in the form of RFCs, POSIX and so on, but we certainly don't do rigorous compliance testing for them with each new release. For systems that aren't done that way, though (a category which applies to more than 99% of all available software, at a guess) I'd much rather take an open source one than a closed source one.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Because of the way Open Source is developed it will have less bugs than some commercial software, but it will never be developed to a formal specification using tried and tested Software Engeering principles.
Commercial software (i.e. closed source) benefits from not being developed in a chaotic way and can be more secure. Techniques such as the Cleanroom approach, software inspection can lead to almost zero-defect software. Which is something I don't think Open Source can ever really achieve.
The use of formal methods for specification and verification does achieve secure systems, the only way Open Source can match commerical systems developed in this way is for them to be developed in a similar fashion. Sure, you can still give the source away, but developement does need to be centralized for these techniques IMHO.
Open source software can be trusted more than closed source software when it comes to security, for all the reasons that you all know (quicker bugfixes, code open to scrutiny, etc). Closed source software can have hidden APIs, bad implementations and bugs, and the release cycle is slow.
OpenBSD is interesting, as they do audits on software to get rid of the security holes. They can only do this because the source code is available.
Of course, software like Sendmail, various ftpds, POP3 daemons etc, all mess up the security aspect of an OS. The OS can be as secure as it can possible be whilst still being usable and useful, but if the software being run on it is vulnerable, then backdoors into the system will be found. Having the source code available allows the cracker to find better access methods than having to guess and feel their way into a system.
You just have to remember that there will never be perfect security, and plan accordingly.
My assertion is that open source challenges the notion that you need a formal spec to develop trusted software. Much like the submitter of this story, I would hold up OpenBSD as an example of a system that I consider trusted, yet was not developed under any formal spec. Perhaps it's time to realize that formal specs help to get things done correctly, and they certainly help get things done quickly (by preventing, in theory at least, feature-creep), but they certainly are a requirement.
Werd.
Honestly, I would say the same thing about a lot of commercial software as well.
I suspect that Dr Spafford would agree with you. Whether or not a piece of software is open source is orthogonal to whether or not it can be trusted.
Just because you sell something doesn't mean that it's been designed properly, and likely just because something is free doesn't mean it's been slapped together with duct tape.
Just because you sell something doesn't mean that it's not open source.
I don't see that there is any connection between where your code comes from and the specifications it is built to.
A benevolent dictator, acting much like Linus, could accept only code that brings the product closer to the design.
The test suite or testing procedure could be released along with the code. Sure, goals like "ISO 9000 security compliance" are less popular than "a working operating system", but that doesn't mean you have to keep your source closed. And it doesn't mean you can't accept patches that bring you closer to your goal.
Thank you for not thinking.
Trusted, Assured, Safety Critical, these are all areas where IMO Open Source won't work. They require a level of discipline and upfront analysis and design that doesn't merge well with release early and often. OSS creates great software for large user bases, however it tends to create products rather than enterprise applications.
The key to trusted, assured or Safety Critical is the specification. You must know in advance what you have to prevent. Its no good after you've lost all of your data fixing the bug that allowed it open.
An Eye for an Eye will make the whole world blind - Gandhi
The article didn't mention any bias against open vs. closed source. Actually (if you'd read instead of shouting out OPEN SOURCE ROOLZ just to be cool), he mentioned that more developers looking at the code usually tends to produce a better system. However, open or closed source, if a system is not designed to rigorous specs and tests, it cannot be trusted. I think he has a good point.
It doesn't matter whether the source is open or closed.
Eric Allman is the sendmail hacker, ESR wrote fetchmail
And yes, sendmail sucks. run qmail or postfix instead.
(I can't belive that I actually reply to such a blunt flamebait ... )
Don't know what exactly a system has to be to be considered 'trusted' but OMG tested MICO against their CORBA spec for free in recognition of their efforts. MICO passed and hence can be legally branded as a CORBA implementation. Could MICO be considered a 'trusted system' then? It was tested in a very formal way.
Then what makes a trusted system? What systems would be considered trusted?
Just because something is closed source, that doesn't mean it's developed to a formal specification with formalized testing.
Furthermore, what constitutes a formal specification? Both OpenBSD and Linux derive their security models from the Unix security model. That model *is* a specification. But is it a *formal* specification, and if not exactly what constitutes a formal specification?
FInally, as for formalized testing, I don't know that much about what Linux kernel hackers do, but I'm to understand its a very chaotic environment. I agree with the professor here: I don't think Linux has had formalized testing for *anything*, let alone the area where it matters (security.) Yes, to a bazillion eyeballs all bugs are shallow, but formalized testing means creating a formal benchmark test that puts the program into virtually every conceivable situation. I'm not saying that closed source developers do that (isn't it obvious? look at the number of security holes in the Windows operating systems over the years.) but I do think that Linux, and software development community as a whole, needs serious improvement in the areas of testing.
From what I can see, the proessor's whole gist is this: software development needs develop an engineering culture. Software needs to follow a systems development life cycle (SDLC)where formal specifications (requirements documents) are written up in advance, the software is developed within an engineering culture, and there is formalized testing and user acceptance. These seemingly superfluous controls, especially in the area of infosec, are vital to controlling the inevitable bugs that crop up and to making sure that software meets the requirements.
I think Linux and *BSD at least need to take a hard look at requirements gathering and testing phases and see if there is any room for improvement.
My journal has hot
Open source can be more trusted than closed source
Formally designed and reviewed software can be more trusted than chaotically assembled software.
These seem orthogonal to me (and to each other! wakka wakka wakka!). Sure, most all of the software out there is NOT formally designed for security first. A lot of it is open source, a lot of it isn't. Open source obviously doesn't make a programme or suite instantly bulletproof, neither does formal design and review. Nothing is 100% secure, trustworthy, or bug free. Loads of things can help or hurt the process.
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
I'd agree that open or closed source has little to do with trusted or not trusted. Either open or closed source software can follow strict design guidelines or be flakey. With closed source we get what a company wants to sell us and no way to prove if it is or isn't what we want. With opened source it's exactly what we want it to be. If that means trusted then it'll be trusted because otherwise what would be the point of coding it? The bottomline is that we are in control of our destiny.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
As long as trusted systems are evaluated in a many-month long process as defined in the Red Book (NCSC Trusted Systems Evaluation Criteria), most Open Source OS's will continue to fall, simply because they cannot afford to have the testing or certification performed.
What we really have to remember is that Open Source OS's simply don't have the features that the trusted system evaluation criteria dictate -- it has nothing to do with whether or not they're secure in practice, but has *everything* to do with if they're secure in theory, such that a poor implementation can't break the security model.
Memory that's segmented in hardware such that even increasing your process priveleges doesn't allow access to the memory space of another process? Filesystems that log every transaction (including read/stat operations)? Systems that log every system call reliably, in an untamperable state? These are the features of government critically evaluated trusted systems, and until Open Source OS's support them, we shouldn't gripe. =)
I think that it could be worthwhile to reconsider Ken Thompsons all time classic Reflections on Trusting Trust in this context.
Peer review (as one of the streanths in opensource) won't alone give you a secure system, there are far to many other factors to be considerd. Peer review is however one very important factor.
>Honestly, I would say the same thing about a lot of commercial software as well.
Well, yes. But that's not the point. You're playing the ad hominem deflection game: "seeeeee, they're just as bad, toooo!!!"
Boiling this issue down to open versus commercial is completely orthogonal to the actual point: well-designed, specced-out systems are going to be more trustable than ad-hoc slapped together ones.
Where the code comes from should be irrelevant -- if the spec is good and the code actually matches, all is well, regardless of origin. Granted, open source makes bugs easier to find, but also adds an element of chaos into the implementation phase that could be detrimental; the bazaar doesn't necessarily follow specifications. It's a tradeoff....
Trying to cast this issue in the light of open versus closed is really just playing the 'when what you have is a hammer everything looks like a nail' card with the Slashdot open-good-closed-bad mentality.
Not every software development issue can be solved by a free license. Really. I promise.
--
Without hearing the seminar it sounds as if Dr Spafford is talking about Trusted Systems, not security in general.
Trusted systems are usually of the kind where every action is auditable and traceable; system administrators do not have access to delete logs or change audit trails, etc. The 'trustiness' and 'security' of these types of systems is rather designed through system architecture and specification of how, exactly, everything works, and very strict definitions of security access and permission. Bugs and exploits dont even figure into wether or not the system is 'trusted'. It's a measure of how it works; ie, your sysadmin cant add a $50000 bonus to his salary in the economy system (he probably cant even access that data) and wipe the logs of his doing it, bugs notwithstanding.
Of course, no commercial or free 'standard' unix lives up to that, simply because of design (some trusted unix-like systems do tho).
Which, I think, would be his point; no open source OS currently exists that implements something like that, and the usual design methods in opensource favour functionality and features above things like total fascistic control and auditing of every action taken in the system.
That is not to say an opensource model wouldnt work for a trusted system; it would probably even be better, but bugs are irrelevant to the very idea of wether a system is considered a Trusted System or not.
To describe this you generally start off with what you don't want it to do. Examples include "kill someone" or "let someone write to a file without authorisation". Then you have to say exactly what you mean by that (e.g. how might the system kill someone, and what constitutes "authorisation"), and before you know where you are you have a document several hundred pages long, much of which should be Z or VDM. Then you need to check that for any holes.
Then you have to prove that the system fulfils these requirements. Now a full formal proof of this is going to be a larger project than the original software by an order of magnitude, even with today's automated support. So the only feasible solution is to write the software very carefully. You have to identify each piece of code that might cause a non-spec event to occur, and then explain how it prevents any execution which might be outside the spec. And since this is important, you have to leave an audit trail behind so that potential clients (who are going to be staking lives and fortunes on your software) can see that you have done this properly. Unless you do all this, your system cannot be trusted.
(Aside: you also have messy recursive problems with trusting your development tools and hardware)
Put it this way. We all know Linux is reliable, right? But would you stake your life, or even your house, on keeping your Linux box up continuously for the next 12 months? I sure wouldn't. I wouldn't even do that with BSD. There are a few bits of software I would do that with, but... they were all written to these kinds of standards.
No matter how you slice it, this stuff requires a lot of hard work and bureaucracy. The question of "who will watch the watchers" is particularly germaine to the creation of trusted software.
Paul.
You are lost in a twisty maze of little standards, all different.
We think of Linux and Open Source projects as being "secure." They are safe from most attacks in general... Once a problem arises, it is quickly fixed by the community -- and it is very likely to be found quickly.
The problem is that "trusted" within the infosec community means that you can reliably assume in a beyond-mission-critical environment that the system is totally secure from attack.
This means a careful, meticulous design, and very rigid, formal implementation and testing. The aspects involved are far more comprehensive and cohesive than Open Source generally considers...
We look at Open Source software in terms of the safety of a package. Sendmail is not secure, or QMail is secure, and imapd is not secure or... You get the idea... Building a trusted system means looking at the big picture -- as low level as how kernel data structures are defined and manipulated, to as high level as individual file permissions and pretty much everything in between...
IIRC, "trusted" Solaris tends to lag a couple versions behind the general release of Solaris and takes a bit of a performance hit. Why? Because it takes a lot of time to evaluate, and fix an OS to make it "trusted."
A simpler way of looking at the difference is this: A "trusted" system goes to great lengths to meticulously ensure that no edge cases exist. A "secure" Open Source system takes the shotgun approach: With enough monkeys pounding on enough keyboards for a long enough time you'll get the works of Shakespeare... Translation: Open Source counts on enough talented, skilled developers working on a project to cover all the cases without anyone specifically telling them to do so.
In the end, Open Source may or may not come out with a product whose security matches that of a "trusted" system -- but you wouldn't be able to recognize it if it did come out. You couldn't *verify* it.
-JF
MrJoy.com -- Because coding is FUN!
...completely adhering to specs, it probably would be trusted. However no one ever done that -- even systems that are supposed to be "trusted" contain parts that aren't. Probably some embedded stuff can be "trusted", however it's the place where security problems are the least important, and only proper behavior with certain hardware is necessary -- what is much less of a challenge compared to, say, HTTP server + operating system, desktop environment or even a router. If people had many decades for the development of each version of operating system, switch from "chaotic" development to formal specs and proofs that a piece of code adheres to them probably would improve things, however this is not the case, and even if it was, it's possible that specs would end up being developed even slower than anyone would be able to follow then, thus slowing the pace of development to a halt.
Contrary to the popular belief, there indeed is no God.
Check the code against what? Besides looking for obvious bugs, how do you verify that the code meets the requirements if they have never been written down?
Mea navis aericumbens anguillis abundat
The difference in trying to build a trusted system is the formalization. The team which tries to break a system (or certify it), is called upon to review the design, and try to find all weaknesses that might be used to break it. While this could be done with open source, you'd have to find someone to play the role of review team. This could be a serious problem.
I think that it's certainly possible for an open source project to build an operating system to match "C2" specifications, or better. The problem with meeting the Orange Book requirements is that they require trained people to review and test a system. This requires a large commitment of time, effort, and especially, money. Then when you are done, you have certified one version of the system, and nothing supsequent. The open source model is one of many releases, with bug fixes as we go, which has many strengths, but makes the rapid obsolencence of what would be the "blessed" version a big weakness. So, it's possible, but I don't think we should try for it.
I do think that there is a better way, if the testing procedures can be automated, so that the code can be covered from every angle, by the a set of computers pounding on a system, this could be MORE secure than a "Trusted System", at least at the C2 level. A set of workstations could be set up to pound a system, and try to find weaknesses, ala "SATAN", with emphasis on stack overflow weaknesses, etc. If a computer does all the functional tests that a human review team does during C2 certification, this is a good step in the right direction, if nothing else. Add to this a group dedicated to adding test conditions for new flaws, as they are found, or hypothosized, and I think you've got the winning combination for a truely secure platform.
What is really needed is a way to make all of the consequences of a line of source code visible. With C, C++, Delphi, Fortran, et al, there is no way to see all of the possible (side) effects of a line of code. That simple iteration, could have a bounding condition that causes a major hole in security, or it might be perfect, how can anyone know? I consider this to be the problem of brittle code
Object Oriented Programming is a good step in the direction, it does, if properly used, make code testable down to the object level. There need to be better tools for hammering on each object, and making sure they work as delivered, but at least you have something which CAN be tested on a unit level. OOP is good, but still not good enough. It does go in the right direction, because cracks in a system can be traced down to a single component, but those components can be brittle. Testing those components to a high degree brings us close to the goal (my goal, actually) of perfect code. Close, but no cigar.
A platform needs to be built which can make writing a computer program as simple as working with physical objects, such as hammer, nail, etc. When you pound a nail into a 2x4, you know right away if something goes wrong, and what all the effects are. It's easy to test, and visually verify the results. Coding needs to be the same way. This would take a lot of the "magic" out of the process of coding (and uncertainty). What ideas are out there for making this happen? Is a system of individually tested components good enough?
I have a few ideas, which I posted more than a year ago with my own manifesto at basicsoftware.com, ( and I need to review those ideas myself) but really haven't contributed anything myself. So I'm in the same boat... my contribution is a possible pointer in the right direction, and a keen eye on others, and their response.
The goal should be to make software better than any possible real world analogy. We need components that don't fail, and work predictably in a all conditions. If that's not possible, it would be good for the component to signal exactly what went wrong. Nails holding things together loosen over time, software doesn't have that weakness. Nails don't signal failure, but wouldn't it be nice if the nails in your roof signaled failure before the disaster struck?
--Mike--
First of all, based on this definition of "trusted", the open source issue is irrelevant. Software could be "trusted" whether you could know the source or not, so long as the thing was designed to a precise formal specification and underwent sufficiently rigorous testing. None of the software I use (directly) is "trusted" in this sense.
That doesn't mean I don't trust my software. I put a certain amount of trust in it -- some more than others. But this is "trust" in the more usual sense. The sense in which it is used in the article above is an unfortunate jargonisation of a word with a well-defined meaning in everyday use. Let us rather refer to these systems as formal systems. That's probably an overloading of the term "formal", but at least there's less chance of getting confused relative to "trusted". Of course, you would expect such a formal system to be highly trustworthy by merit of the rigorous design and testing, and critical systems should almost certainly be constructed in a formal manner.
In general, I think more systems should be handled in a more formal manner. Indeed, in my opinion, lack of formality is one of the major reasons we have crap software. Usually we have specifications written by marketroids or by hackers scratching whatever itch is pestering them most at the moment. This doesn't make for good formality. Even when formality is attempted, it's rarely done well.
What's surprising about open source is that it seems to have a generally higher reliability than many commercial offerings, despite the fact that the development process is unfunded and chaotic. In that sense, it is relatively trustworthy, despite being informal. This isn't an absolute statement: there's a huge spectrum of quality, and it's mostly the top end of the quality that's interesting.
It would be interesting if a formal open source system were to be developed. The code contribution process could still be informal, but the specification and testing would have to be more organised. Infrastructure systems like DNS and TCP/IP stacks would do well from this, I think. Would there be enough interested parties to write the test harnesses? Who knows.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
What we're seeing here is a big, old, fat dichotomy between the software engineering community who consider themselves engineers and the open source community who thinks of themselves as programmers or coders. I've traditionally always fallen into the latter group, however there is no doubt in my mind that the SE tactic of actually coming up with a sensible plan in advance is better. *This concept does NOT threaten open source software.* What it threatens is the culture of open source community. There's a difference between hundreds of programmers simultaneously fixing bugs within a predesigned and well thought out architechture, and those same hundred programmers randomly going off on their own design tangents. Any successful open source project has some kind of centralized authority- even if it a guy who just does the builds. What I'd like to see is a vast expansion of the whole TODO file concept. Rather than have a handful of items listed such as: "Somebody needs to figure out a way to blah blah", the TODO list should be a detailed spec. The process of coming up with that spec could itself be an distributed process but a very detailed and heavily reviewed spec should be developed before everyone starts coding.
I think that an important part of what you have to understand on this issue is that he's refering to a very formal concept of a trusted system. If you read the government guidelines on building trusted computer systems (e.g. the Orange book), one of the specific factors that is involved in designing systems at level B3 (IIRC) and above is that they be formally specified and proven to meet that specification.
While it's easy to gloss over this kind of requirement, there's some reason to think that it's actually a good idea. By the time you get to a class B system, you have to think about things like mandatory access controls, covert channel analysis, and the like. A formal demonstration that A) your system specification succeeds in meeting those goals and B) the system as built successfully implements the specification seems like a reasonable basis for reaching a high state of trust.
It's not impossible that you could build a free software project that could achieve this kind of goal. It certainly seems to be the case that every time someone says that free software can't do this, that, or the other thing, they've been proven wrong. But it's going to be tough to attract people to a project where you have to do stuff like keeping records of what you've done to meet design specifications, which is actually a requirement of high level trusted systems.
There's no point in questioning authority if you aren't going to listen to the answers.
Next, copy losetup, bash and your kernel to an unencrypted /boot partition. Encrypt everything else. Add an option to lilo specifying that /boot/myscript.sh is init. I disrecall if you need to specify boot as the root partition and remount it, so some experimentation may be necessary.
In the myscript.sh, there should be the set of commands to run losetup and prompt you for your passphrase(s) to mount your partitions. Enter them. Script should then remount root and exec the real init. System boots normally.
Dear sir, I humbly ask that you attempt to bypass the login: prompt and access my data on a system so configured. You may use any tool you like.
Open Source not secure my arse...
"If it has to secured, DON'T put it on a computer".
I used to believe he was joking but now, with a little more experience, I totally agree with this declaration. If it's sensitive, for goodness's sake, don't put it on a computer, and especially on a computer which is connected to ANY form of network.
With all due respect to a senior 'net citizen such as Dr Spafford (who is certainly more intelligent than I am or ever will be), it is true that Linux (or *BSD) evolve in a chaotic and ramshackle way. But we should always remember a few points:
Want to keep something a secret? Remember the advice of that engineer: write it down on a piece of paper, use a one-time-pad, lock the paper in a steel box and put the box in a military-grade safe. Burn all other traces and throw the ashes in a vat of acid. But, for goodness sake, DON'T leave it on a computer!
Of course, this is just my US$0.02...
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
... Security is not something that can be tested for.
Makes sense if you think about it. And it blows a truck right through the "you need a formal spec to test against" premise.
I think Schnier makes much more sense from a theoretical point of view.
From http://www.counterpane.com/crypto- gram-9911.html
The only reasonable way to "test" security is to perform security reviews. This is an expensive, time-consuming, manual process. It's not enough to look at the security protocols and the encryption algorithms. A review must cover specification, design, implementation, source code, operations, and so forth. And just as functional testing cannot prove the absence of bugs, a security review cannot show that the product is in fact secure.
No mention of a formal spec.
Go Bruce!
DWR is Ajax for Java
Open source can be more trusted than closed source. Formally designed and reviewed software can be more trusted than chaotically assembled software. These seem orthogonal to me...
In fact, the two are orthogonal to one another in most aspects, but they can be aligned. I don't see any dichotomy between open source and the kind of intense process that produces trusted systems, it's just that the open source movement hasn't matured to that level yet.
Spafford's observation is correct today, but he makes the erroneous assumption that open source community will continue its current practices of doing inadequate planning and testing to ensure real trusted systems. This is one of those areas where the arrival of the commercial backers of open source, like IBM, an offer substantial contributions.
The one thing that has marked the open source movement from the beginning is the ability to respond and change quickly to get the job done. We are in the adolescence of the open source movement, and since trusted systems do require more process than the standard open source method provides, and since people will want trusted open source systems, it's only reasonable to assume that the open source process will morph as required to "scratch the itch"
"The future's good and the present is nothing to sneeze at." - Roblimo's last
"How do you think we can address his criticisms?"
A few outdated man-pages, HOWTOs and pointers to Web-URLs just won't cut it in this context. In Trusted systems you will need formal proof of ownership, wholistic design, white-box testing/analysis and black-box testing, plus other things I can't come up with now. Documentation on the whole process of conceiving and creating the system would be a great benefit. This would have to be Applied To The Whole Shebang(tm), down through every library, including formalization of every function and good comments on most of their lines.
Now doing this properly _after_ the actual implementation has always been a bad idea, and would further require much harder work than if it had been done in the first place. However, this is an impossibility when regarding how the Open Source-process really works. It would never be as good as it could have been.
If more companies started supporting Open Source solutions, they could perhaps fund this kind of work and release it to the public (either for free or for a fee). It could benefit these companies, because now they can Trust and use free software. Actually, I saw a book that documented the whole Linux kernel once, so I know that has been done successfully.
Of course, "trust" is a word of many meanings. I for one trust many Open Source solutions simply because I know they have stood the test of time again and again. However, I'm always aware that new versions may break things considerably, and the documentation is not always updated. That is why Open Source is not currently a good process for building really Trusted systems. (This has nothing to do wether you release the source or not, which should always be a benefit to trust.)
So to me personally it is good enough, and currently the Open Source-process has quite a few benefits over closed source in this context (and many more regarding price and freedom):
1) Peer review (less bloat, great functionality and inter-operability, harder to put in trojan-functionality)
2) Large techsavvy userbase (quicker bugfind- and fix cycle, easy to get help and gain a community)
3) Ability to find and fix errors or improve the system yourself (Although this should never be necessary in a trusted system. Doing so may also contaminate the system with eg. bad binaries. However, it can be done safely if you use the right process of doing so.)
Note that these points are connected to the very fundamentals of how Open Source works, and should be seriously considered by companies that not merely want to ride the "Open Source Wave".
However, if I were to buy a Trusted system from a company, I would make sure there was a contract that held them accountable. That would be one point to proprietary software I guess. I think it would be hard to find a company that wants to be held accountable for Open Source code (written by others) that they have merely certified..
And lastly, always remember this: There's no such thing as 100% security. You cannot prove security, only prove insecurities or specific lacks thereof.
So don't put your trust arbitrarily.
- Steeltoe
http://www.debunkingskeptics.com/
... And you need to remember that his bread is (as I've said before) partially buttered by closed-source development, and that butter may be threatened by open-source code and economics. Also, beyond just his livelihood, open-source does not necessarily obey his notions of secure design and practices. Academics REALLY HATE when real-world practice doesn't fit into their theoretical structures.. So inconvenient!
We can definitely learn from this man, listen to his experience and knowledge, steal his ideas, and write more secure software, but leave the obsolete preconceptions behind. Then again, he should know that the only reliable crypto is open/peer-reviewed crypto, and security in general needs to be scrutinized by many people of different talent areas to be of quality.
Your Working Boy,
The following is dry, and opinionated, from the POV of an old-timer VV&T/QT/Tester.
I'm big on specifications, and will argue both sides of a contract when a spec is violated. I've even been in a couple shouting matches over them, fighting for the correct implementation, not supposed "flexibility" though they do need to be bent at times.
Fortunately, the shouting matches are rare and as a Contractor Scum(tm), I never take them personally...only as a barganing point and to help stiffen the backs of those who are easily swayed. It's a shame when good projects go bad, but that's other people's money!
Good specifications are invaluable in eliminating all sorts of conflicts and allow projects to actually end without different groups wanting to kill each other.
Unfortunately, specifications are by necessity limited in scope. If it's not in the spec, it can't easily be added. If it's in the spec, it can't be modified easily.
On a formal contract, adding in goals like "The system shall be fast" don't work well, so more detail is usually specified; "The system shall retrieve a query on the client stations within 4 seconds at all times".
There's always a few details that slip by, and if the people on the project aren't reasonable the details will cause quite a few social and technical problems.
Even relying on an outside specification is a problem...since APIs/protocols/... are usually vauge on some level.
The people who implement it and the environment have a much greater impact on the results; there will be good and bad free software / open source projects...as there are good and bad commercial projects.
From what I've seen, I'll trust open source as much or more in most cases...but I'll test it first.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
You've managed to miss the entire point of the discussion. As the original poster pointed out, this isn't about "enough eyes make all bugs shallow"; it isn't even really about bugs. It's not about "open == good && closed == bad", no matter how much faith the Slashdot crowd may have in this doctrine.
It's about OSS not being developed in a careful, thoroughly planned and controlled fashion. It's about the fact that right now, no OSS system out there can be satisfactorily considered "trusted", not even the high-and-mighty, "look ma I'm secure" OpenBSD.
I've pointed out elsewhere why a formal definition of the term "trusted" is important. Shortly, it's not enough to simply say "the general consensus is that it's secure, so let's just say it's trusted".
(And your absurd overgeneralisation to the effect that all expert reviews are corrupted doesn't help your case one bit. FYI, in the Real World (i.e. outside of Slashdot), ad hominem is frowned upon.)
To the editors: your English is as bad as your Perl. Please go back to grade school.
Your testing is all very well-defined. If the pre-conditions are violated, then your input is in error. Your routine should determine this (how is unimportant) and exit safely. To test this, run the routine in a test harness and see what happens when you enter "normal", extreme and erronious data. (Ok, hands up! How many of you have heard exactly the same thing from Comp Sci lecturers, throughout school and University? Just cos they're lecturers doesn't make them wrong. At least, not all the time.)
The next round of testing is the post-conditions. If your routine exits and violates a post-condition, then the logic in the routine is faulty. The case being tested is not being handled correctly, according to the specification. So you fix the routine. Big deal.
Who defines the pre-conditions and post-conditions? That's simple. For IP-based networking, the IETF RFC's define those very nicely. For device drivers, the specs for the device do the same. Then, there are POSIX and UNIX98 standards docs. Since Linux is a mish-mash of BSD and SysV, the specs for both of these are usable.
All in all, the problem with Linux is NOT that there aren't enough formal specs (there are plenty!) but that Linux doesn't have any wide-spread test harnesses, or databases of pre/post-conditions.
If someone (anyone!) could come up with a way of plugging ANY Linux module into a test harness, and pound it with different cases, and then have the responses checked against the pre/post-condition DB to see if the module violated the specs, you'd have ALL the formal testing you'd ever need and auditing would become a breeze.
Dibs Linux for B1 before Windows!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Specifically, it wants all access to all objects on the system to be fully logged, leveled security, and blatant marking, plus whatever else is in there and too dry to read.
However, remote access to systems is a job not only for the operating system of the host, but also for the network it runs on. Being that networks in 1983 were a little different than they are now, I would hope that a system that was meant to provide access to possibly classified data would rely on more than simply the security of the selected operating system, regardless of the openness of the sourcecode. The system in that case would take into consideration the OS, the firewall, and the network connection from client to server. The possibility probably exists to buld a system based on Linux that could be trusted, but would need to be spec'd out with "system" referring to more than just the OS of a host computer.
When it comes down to it, would you really want the good name of Linux drug in the mud by some military stiffs who can't secure the Army web servers?
--m
Gene Spafford's argument seems to proceed simply as a tautology from his definition of "trusted", if I've understood the summary correctly. By this definition, a system is "trusted" if and only if a formal specification and testing process exists, and the system satisfies the spec and passes the tests. Thus it's trivially true (if we accept the definition) that a system that doesn't satisfy these criteria isn't "trusted".
It is *not* true, however, that an Open Source system could never satisfy this definition. Set your formal specification and get your Open Source coders to work on fulfilling the spec. When they're done, then voila! A "trusted" Open Source system.
Alternatively, one could reject Spafford's definition of "trusted", as not matching the intuitive notion of trust. One could reasonably argue that "trust", in the common and intuitive sense, can only be realistically achieved by extensive peer review. I would furthermore argue that satisfying a formal spec is not enough for trust, because a spec might fail define a system that most of us would intuitively view as trustworthy.
If all he's saying is that all we need is a spec in order for a system to be "trusted", without saying what such a spec has to be like, then I say he's wrong; because a spec can specify any kind of untrustworthy foolhardiness you imagine.
To demonstrate this, I hereby give a formal specification of "trust": A system is "trusted" if and only if it crashes at least once for every six hours of operation. The formal test is: Run the system for sixty hours; if it crashes ten times or more, then it's "trusted". There you are, a formal spec and testing process. But hardly anyone could describe such a system as "trusted".
BTW, although I'm disagreeing with him, I remember Gene Spafford with great respect as a major driving force in the early days of Usenet, and the author of an O'Reilly book on security. I'm a bit dismayed that so many Slashdotters don't recognize him.
Always keep a sapphire in your mind
Once there was a young monk who saw another young monk from a rival temple on the road.
"Where are you going!" he said in a rude voice to the rival monk.
"I am going wherever my feet take me" said the rival in a mysterious voice.
This flustered the first monk. When the first monk went to his masters and related this, they beat him, and said "You fool! Ask him, 'What if you had no feet?'"
The next day, the monk saw the same rival walking down the same road.
"Where are you going!" he challenged.
"I am going whereever the wind blows," replied the rival solemnly.
This flummoxed the first monk, who was not expecting this. Again he related this to his masters, and they beat him, and said "Idiot! Ask him, 'What if there were no wind?'"
Thinking he had this figured out, he lay in wait for his rival, who in due course came down the road.
"Where are you going?", he challenged.
"I am going to the market to buy vegetables" said the rival.
---
The point of this is that when somebody is thinking on a deeper level and carefully factoring in your own methods of reasoning, he can defeat you. The Morris worm was a perfect example.
I agree that open source is not a panacaea, but neither is formal specification and testing. Paranoia suggests multiple and orthagonal methods for enhancing security, not relying exlusively on one strategy.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
ISO certification is a great comfort to purchasing managers who prefer trusting a bureaucratic process to trusting individuals or their own judgment. This is similar to companies that require job candidates to have a certification, rather than independently assessing the candidate's skills and knowledge. It's not meant to be an equal opportunity process. It's meant to be a discriminating process that allows a decision to be made without anyone having to exercise their own judgment and thereby risk their reputation. It means you aren't risking your own reputation, and you don't trust anyone else's.
The fact is that making judgments of quality or security is difficult, and most people are lazy. Nothing prevents anyone from coming up with a way to measure security and putting OpenBSD to the test. This mentality, however, would make it an imperative that the software be retested with every change. Any what assurance is there that the test itself, or the person conducting it, can be trusted. ("We'll need to see some certification").
Certain types of people will always have greater confidence in the legal recourse to hold someone else accountable than they have in their own judgment. It's just too bad that those people are given so much credit.
Ahhh, I see the New Jersey mentality is at work again. "If it works (however marginally), why bother getting it right?"
No wonder so much software sucks. I wonder how long a civil engineer would stay out of jail if he went by "if it hasn't fallen down so far, why should we bother making sure that it won't?"
To the editors: your English is as bad as your Perl. Please go back to grade school.
Remember the NT C1 (now C2) compliance thing? Because NT's design happened to include some of the elements of the C2 definition, they were able to come up with a configuration that could be trusted. Not bugfree or secure, but trusted. (Note, NT's C2 security used to involve no NIC, but I think they fixed it).
OpenBSD is really fucked secure, but isn't designed to the spec, doesn't include the ACLs and other stuff needed for DoD compliance, etc.
Neither does FreeBSD, but remember the Trusted FreeBSD project? They are trying to make a B1 compliant (trusted) BSD based off FreeBSD.
Also, Operating Systems are not inherently trustable. It is the entire system that earns a security rating. It largely involves a fine tuned control of file access, but not a fine tuned fixing of bugs.
Alex
Yes, I picked NT as my "trusted OS" mostly because it will generate the stupid /. effect of "waah waah waah, NT is horrible, you must be a moron" the required "you are the stupidest ass in the world" and other stuff like that.
Get a grip kids! OSes are NOT the end all and be all of life. Further, drop the prejudices. I am an MCSE, that does not make me a moron, clueless, or a lemming. Indeed, just because all the MCSEs that you know are dumb does not mean that they are dumb BECAUSE they are MCSEs. Some of us happen to be very competant administrators, and happen to have a certification. Some of us actually learned are shit to get it, instead of just memorizing study guides.
Quit hurling insults to people that sometimes disagree.
Alex
First, the big fallacy in his argument: Open Source is not the Bazaar! Specifically, there is nothing to stop a person from getting a group of programmers together, writing up a formal spec, paying them to write code, paying a third party to do a formal audit and testing it against formal standards, and then releasing it under an Open Source license. It wouldn't cost any more than the analagous proprietary effort he's presumably advocating.
Secondly, you can use the Bazaar to reduce the cost of developing such software. Take a Bazaar-developed program that does pretty much what you want it to, draw up a formal spec, pay some programmers to audit the program and bring it up to spec, and then go through the formal testing. If you pick wisely, this could greatly reduce the cost of such development, and it should comfortably meet his definition of "Trusted".
Thirdly, I question whether formal specifications improves security; granted, that's no consolation if you're working for an organization that requires it. Formal specification merely means that some thought went into design before the program was written (or modified in the above example). It is very difficult to test a specification for security problems, for obvious reasons. Also, it is easy to write a program that matches a formal specification, yet introduces subtle security holes.
Fourth, there is no reason why you can't perform formal testing (for what it's worth) on any piece of Open Source software, Bazaar or not. Then you have a formally tested program. You must refrain from upgrading without running through the testing procedure again; just like proprietary security software.
The bottom line is, if you want formally trusted software, you've got to spend some money. Open Source will not prevent this, Free Software will not prevent this, neither the Cathedral nor the Bazaar will prevent this. That doesn't mean they should be excluded from consideration.
----
----
Open mind, insert foot.
THe problem with specifications, is exactly its benefits.
.. minutes?
When WYSYWYG interfaces, someone point out that not only is What You See Is What You Get, but also that What you see is ALL you get. This means that while you can see on the surface what document or page or whatever that your creating, and how its looking, but thats all your going to get, nothing else, no more, no less.
Take example a standard graphics program like the GIMP, and compare it to POVRay. The GIMP's WYSYWIG interface is really slick, but with POVRay, you can create ray traced images that would be next to impossible in a WYSYWYG environment, but you dont get to see the exact creation before its done.
With programming, a formalized, structured process ensures that the program will give you what you want, but it will never provide more than that.
True "Innovation" will never occur. No one may spot the flaw in the security model, no one may realize that 40-bit encryption is a bad way to protect DVD's from being copied, no one may predict that a Record-Industry defined "secure" file will only be effective for a couple of
But by setting Goals, but allowing for large amounts of flexibility of the Programmers allows for products to be delivered that are not only Programs that meet their requirements, to Products that truly meet their needs.
And trust me, clients requirements and their needs are almost always two completely separate things.
Use Gnumeric as an example - the author did what? Copied Excel. What did excel do? Copied Lotus? Lotus? They copied VisiCalc.
But the question remains, these products are meeting requirments, but are they really meeting the NEEDS of the people that use them. Couldnt someone have thought of a better way of setting up a spreadsheet? Making the formulas? Hell, why are there formulas at all?
But I'm sure you get the point.
Linux may not have the strict methodology that modern business management and Quality Testing require, and that, is exactly why it ends up with higher quality products in a shorter amount of time.
... hi bingo
Call me chaotic
Formal specs are safe but dull
While I live, I hack
------
------
You are in a twisty little maze of open source licenses, all different.
Hmmm, well - you can easily test if the networking components of open source software live up to the RFCs that they are designed to meet. Sounds like a bunch of specs to me. A description showing overall protocols and spefic situations, with specified function and response to stimulus sounds like a pretty good control document to me.
The HTTP RFCs are a good example.
This is what you MUST do:
This is what you SHOULD do:
This is what you CAN do (if you feel like it):
This is what you MUST NOT do:
Pretty cut and dry, and rather effective (the web works, don't it?).
I'd say that most JAVA implementations (from most companies) would fail full compliance to the Java spec (well, at least some of the Java specs... there's so many these days).
"It's tough to be bilingual when you get hit in the head."
A trusted system does not necessarily mean that it is secure.
:-) (the transformation produces an awful lot of clauses so your complextity grows *very* fast).
I can specify a (software) system in a formal way using formal languages like Z or TROLL (TROLL really is a formal specification language, honestly). But this does not mean that it has to be more secure, it only means that I am able to define the systems behavior *exactly*, so that the resulting software system behaves in a predictable way.
This is working fine in theory but to my knowledge there are no working (as in usuable) tools to automate the derivation of the software system from the formal sepcification. So you are still left with several gaps in the design/implementation process.
Proofing of your specification is simple: Transform your spec into predicate logic clauses und do a resolution
Until this process is fully automated, formal specification and *verification* (!) is too difficult and cumbersome for widespread use.
So this talking about trusted/untrusted systems is completely unrelated to any Open/Closed Source security debate.
+++ after all, it's just my thoughts +++
bye,
blurred
I think this man is more concerned with developing a secure world than he is by profiteering off a particular economic model.
I agree, my issues are largely related to the academic vs. real-world differences. OSS works pretty well in the real world, but it doesn't fit into a traditional academic perception of security design (though peer-review of code and algorithms _is_ a standard tenet of secure design). Perhaps it was unfair to put the caveat at the top of the note, it should not have conveyed that much emphasis, but I still stand by my belief that Dr. Spafford may have his objectivity clouded somewhat by institutional oldthink and, possibly, by conflicting interest.
However, as an earlier post pointed out, Spafford's lecture seems to be aimed at a controlled, replicable, process (gee...that sounds like software engineering).
Yes, that's why I said (in that earlier post I referred to) that while we can agree that software designed by small teams of competent designers and coders makes for stronger, more secure software, that isn't the actual point. The point is, in the real world, we have to deal with all kinds of software from different companies and groups, and often the decision process for selecting software isn't the most logical or objective process. So how do we live in that world? Dr. Spafford puts forth a view of a software world in which we'd like to live, my thing is we don't live in that world, it's not coming anytime soon, so how the hell do we deal with what we have to deal with, while doing our best to improve matters when we can? Again, it's academic vs. real-world. Both can appreciate the Right Thing, but you can't always get it in the Real World, for a variety of reasons. It's a respectful difference of opinion, not a flame.
Aside from the fact that he gives his information out for free (it's payed by research money but donated to the community at large), it's illegal, immoral, and, from a socio-economic point of view, inappropriate to steal.
Good artists borrow, great artists steal. And smart artists properly attribute.
Your Working Boy,
It would be nice to know what the requirements are of this spec. If the spec were or is an open spec it would then be possible to make Linux, OpenBSD, or any other OS abide by this spec.
I think that it is important to understand as some have pointed out that trusted does not mean secure. This is one of those english language semantic things. Trusted means that they have a set of requirements that this OS / program is supposed to do and it does them. Basically they can trust that if this happens the software will do what they wanted it to do. Secure means that if someone tries to hack in or exploit a buffer overrun then the system wont let them. OpenBSD is secure, NT is trusted. This does not mean that NT is not secure, it is in its own right, but I wont get into that. It also does not mean that OpenBSD cannot be made to be trusted either.
The advantage to them of Open Source would be that if the sytem is not trusted, they have the source and can make or have the system made into a trusted system.
Wouldn't it make more sense for them to take a secure system and make it trusted as well?
Just my .02 cents, but I think that the goverment needs to start rethinking some of its policies of doing things.
send flames > /dev/null
Only 'flamers' flame!
However, this kind of formally verified system is extremely costly to develop, extremely difficult to adapt to changing circumstances (and retain the verified properties), and still doesn't guarantee that it does what you want it to do - mistakes in the specification or mistakes in the verification process are just as likely as mistakes in coding.
Frankly, for 99.9% of the software written in the world, this kind of thing is utterly impractical and will remain so. I don't mind consigning the remaining 0.1% to cathedral-style approaches (though open source can still help spot bugs that the verification doesn't catch).
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Neither open source nor closed source by itself makes a system secure. There are way too many systems, both open ones and closed ones, that are swiss cheese, to even think that security can derive from either mechanism.
With regard to security, what open source would allow you to do is verify whether or not a given system truly is designed to a rigid trusted specification. None are now, and OpenBSD seems to have the greatest potential. But I'm absolutely NOT going to trust the security of a closed system just because the marketing folks, and their hired security consultant, says it's perfectly secure.
The question I think is this: If you do have a system you believe is truly secure, does making it open source compromise that security? I believe that if it did, it is flawed in design and can't possibly meet spec.
Where closed systems get an advantage with regard to security is when they are really not secure. That advantage gained is a delay between market introduction and discovery of its insecurity (perhaps by reverse engineering).
now we need to go OSS in diesel cars
Read the decade of CERT advisories for Sendmail and BIND to convince yourself of this.
The notion of "root" is bad enough, but "set-UID to root" is worse. This results in far too much code being trusted. In particular, it should be impossible to run non-trusted code as root. This means no root log-ins, for example. In a secure system, as your privileges go up, the amount of software you're allowed to run goes down. In a sandbox, you can run anything. As administrator, you can only run a few tools that do very specific things with lots of checking. This is completely alien to UNIX.
A serious attacker will find their own holes, and will keep quiet about them until they break in and steal something. Fixing known holes protects against script kiddies.
DoD has a simple security model, which is reasonably enforceable. See the Orange Book. There's Linux support for it. You take a performance hit and can't run some popular software. But in that direction lies real security.
With discretionary security, users can turn off security. "chmod 777" is the usual way. With mandatory security, if you're processing SECRET information, nothing you or your programs can do makes it non-SECRET. The problem with discretionary security is that it's extremely difficult to tell if the system is in a secure state, and it's very easy to make a change that opens a security hole.
OK, you've got a secure system. Want to run Napster? No way; it's acting as a server and transmits your files. Want to download a game? If it will run in a sandbox, OK, but it can't talk to other players. Running a web browser may be OK, but the browser will be shot down if it tries to launch MS Word to read a
A secure open-source system is quite possible. But it won't be Linux as we know it.
This doesn't sound like the earlier posts. Script changes after the specifications are created isn't the same as scripts that are made once and run throughout the project. Making updates can suck up an amazing amount of time.
Are you talking about testing at the end of a cycle, ongoing, or both? The projects I tend to do usually have a GUI-intensive part covers a few hundread forms plus related specialty screens. That part doesn't work well with automated tests. The backend parts do, though, since the interface to them tends to change very little.
For me, testing starts with a formal test plan (from the spec), occurs constantly, and the remaining time is used to plan for the milestone releases and do documentation. Automated testing is time consuming and isn't worth setting up for most rapidly changing projects. In limited parts, yes, across the whole project noooo.
Yes, definately. Each group talking as early as possible and hashing out the details is definately benificial.
I wouldn't dare create a script for something that's changing on a regular basis unless it were small or I had a big staff (about ~1/2 size of development group).
If you get away with this kind of thing and don't drive yourself mad, I'd like to know how!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
If you cannot see the source code, then all the formal design or testing amounts to nothing. At best, you have someone's guarantee that the system is secure.
Also, empirical tests are insufficiently strong to prove anything. You can test the binaries ad nauseum and not find every security flaw.
So basically, this is just another bullshit attack on free software.
The problem is that you aren't sure that your tests cover all the cases and that you haven't left anything out. More importantly, you aren't sure exactly how the system should react in all situations. For instance, what should the maximum response time on a component of the system should be? If you don't specify this then you can't test it to make sure the system responds correctly. BTW, you need specifications like this in order to make sure the system can handle the environment its in and doesn't say start applying the brakes too late.
Basically what the formal spec does is it lets you determine how much testing you need to make sure that you've covered all the cases and that the program will respond the way the spec says it will. Personally I would prefer a software that went through this sort of procedure rather than the first public release of some open source program controlling the brakes on my car or the controls on the plane I'm flying in.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
It may be true that lot of free software starts its life chaotically. However, claiming that big, succesful projects are developed chaotically is complete nonsense. The proces of specifying the direction in which free software moves is different from what people working in traditional software developement may be used to. Maybe these new organisatory schemes are difficult for Dr. Spafford to understand, but claiming that developement of "Apache", "Gnome", "KDE"... are chaotic is complete nonsense.
As for the question wether Open-source project can become "thrusted" or not, this depends on only two factors:
If these two are in synch, chances are that Open source project will reach the state where you can trust it much faster than a project coded in traditional way.
Since, according to an article in Ars Technica, modern processors will effectively rewrite code at execution time, can any program or OS running on a recent processor be considered a "trusted system" by the definitions used by Dr. Spafford and others?
They are mixing up the development model with the final product.
Can "Linux" be trusted? What do you mean by "Linux"?
If you mean a particular kernel version, as released by Linus... there you have it. Can you trust it? depends on your criteria. Do you *need* to trust it, or can you simply take a certain version and stick with it?
Linux is more about a process than the technology.. open source is about lots of developers working together in a scientific (as opposed to market driven) way to produce better code and better software.
Er, one thing. Z isn't a programming language, it's a specification system. I'm sure my Z lecturers would agree that I'm no expert on the subject, but from all I was ever taught about it there simply isn't enough information in there to produce code directly from the spec.
Don Knuth's comment is worth bearing in mind, but it's a distraction in many ways. He's saying - or at least appears to be saying - that he has proved that the fundamental design and architecture is correct, but isn't certain that, in the translation of specification to code, he hasn't made a typo or two. That's still possible, but a very different source of bugs.
The problem with the standard 'open source' development model is that it's too chaotic to tightly control adherence to specs, IMO. That's what our original source here seemed to be talking about when he doubted whether 'open source' development could ever produce trusted code.
Your last two paragraphs seem to miss the point somewhat, though. A trusted system needs to have the specification tightly drawn up before a single line of code is created, if we wish to have any serious prospect of trustworthiness. If you try and draw up a 'de facto' specification after the event, it's inevitably going to contain problems as you're merely documenting behaviour that isn't necessarily trustworthy in the first place. Trusted reimplementation may be possible, but I'd still want a new codebase.
BTW, before anyone gets annoyed, the only reason I've been referring to 'open source' development as opposed to open source development is that, in this context, it implies something about the structure of the development team and that's mostly what's relevant. I could produce a project with a tightly controlled, exclusively internal team which decided to publish its source as it was going along. We'd still have source which was open but it wouldn't be conforming to what's normally accepted as the open source development model.
Greg
(Inside a nuclear plant)
Aaaarrrggh! Run! The canary has mutated!