Slashdot Mirror

jammag writes "Open source advocate Bruce Perens writes in Datamation about a major court victory for open source: 'An appeals court has erased most of the doubt around Open Source licensing, permanently, in a decision that was extremely favorable toward projects like GNU, Creative Commons, Wikipedia, and Linux.' The case, Jacobsen v. Katzer, revolved around free software coded by Bob Jacobsen that Katzer used in a proprietary application and then patented. When Katzer started sending invoices to Jacobsen (for what was essentially Jacobsen's own work), Jacobsen took the case to court and scored a victory that — for the first time — lays down a legal foundation for the protection of open source developers. The case hasn't generated as many headlines as it should."

jammag writes "Open source advocate Bruce Perens writes in Datamation about a major court victory for open source: 'An appeals court has erased most of the doubt around Open Source licensing, permanently, in a decision that was extremely favorable toward projects like GNU, Creative Commons, Wikipedia, and Linux.' The case, Jacobsen v. Katzer, revolved around free software coded by Bob Jacobsen that Katzer used in a proprietary application and then patented. When Katzer started sending invoices to Jacobsen (for what was essentially Jacobsen's own work), Jacobsen took the case to court and scored a victory that — for the first time — lays down a legal foundation for the protection of open source developers. The case hasn't generated as many headlines as it should."

arcticstoat writes "Microsoft has said that it plans to remove a lot of the standard apps from Windows 7 in order to make the new OS 'cleaner.' Among the apps for the chop are Windows Mail, Windows Photo Gallery and Windows Movie Maker, which will no longer be included with the operating system as standard. Instead, equivalent versions of the apps will be available from Microsoft's Windows Live download service as optional free downloads, much like the new BETA versions of the apps that Windows Live offers today." Meanwhile, jammag writes that "tech pundit Mike Elgan posits that the rushed-to-market Windows 7 — due in 2010, now being beta released this October — may in fact merely be Vista with new packaging.

arcticstoat writes "Microsoft has said that it plans to remove a lot of the standard apps from Windows 7 in order to make the new OS 'cleaner.' Among the apps for the chop are Windows Mail, Windows Photo Gallery and Windows Movie Maker, which will no longer be included with the operating system as standard. Instead, equivalent versions of the apps will be available from Microsoft's Windows Live download service as optional free downloads, much like the new BETA versions of the apps that Windows Live offers today." Meanwhile, jammag writes that "tech pundit Mike Elgan posits that the rushed-to-market Windows 7 — due in 2010, now being beta released this October — may in fact merely be Vista with new packaging.

jammag writes "When Linux journalist Bruce Byfield tried to dig for details about the security breach in Fedora's servers, a Red Hat publicist told him the official statement — written in non-informative corporate-speak — was all he would get. In the wake of Red Hat's tight-lipped handling of the breach, even Fedora's board was unhappy, as Byfield details. He concludes: 'If Red Hat, one of the epitomes of a successful FOSS-based business, can ignore FOSS when to do so is corporately convenient, then what chance do we have that other companies — especially publicly-traded ones — will act any better?'"

jammag writes "When Linux journalist Bruce Byfield tried to dig for details about the security breach in Fedora's servers, a Red Hat publicist told him the official statement — written in non-informative corporate-speak — was all he would get. In the wake of Red Hat's tight-lipped handling of the breach, even Fedora's board was unhappy, as Byfield details. He concludes: 'If Red Hat, one of the epitomes of a successful FOSS-based business, can ignore FOSS when to do so is corporately convenient, then what chance do we have that other companies — especially publicly-traded ones — will act any better?'"

A week ago, we discussed Microsoft's contribution to the Apache Foundation. Now, Bruce Perens has written an analysis "exploring the new relationship of Microsoft and the Apache project, how it works as an anti-Linux move on Microsoft's part, and what some of the Open Sourcers are going to do about having Microsoft as a rather untrustworthy partner." In particular, he notes: "...Microsoft can still influence how things go from here on. If they have to live with open source, the Apache project is Microsoft's preferred direction. Apache doesn't use the dreaded GPL and its enforced sharing of source-code. Instead, the Apache license is practically a no-strings gift, with a weak provision against patent lawsuits as its most relevant term. Microsoft can take Apache software and embrace and enhance, providing their own versions of the project's software with engineered incompatibility and no available source, just as they forced incompatibility into the Web by installing IE with every Windows upgrade."

StoneLion writes "After months of development and controversy, the KDE project announced the release of KDE 4.1 today. Linux.com (a Slashdot sister site) took a hands-on look at the new code, and reviewer Jeremy LaCroix says, 'KDE 4.1 simply rocks.'" Bruce Byfield's review is quite positive, as well.

jammag writes "According to Matt Hartley, many Linux desktop users don't like to admit that there's scads of closed source code commonly used with the Linux desktop. Hartley points to examples like proprietary drivers, the popularity of Skype among Linux users (in preference to the open source Ekiga), and the use of Wine. He concludes that, hey, if the code works, use it — a stance that won't sit well with purists. But his article raises the question: is it better to embrace some closed source fixes, and so create a larger user base, or to remain pure, and keep Linux for the specialists?"

jammag writes "According to Matt Hartley, many Linux desktop users don't like to admit that there's scads of closed source code commonly used with the Linux desktop. Hartley points to examples like proprietary drivers, the popularity of Skype among Linux users (in preference to the open source Ekiga), and the use of Wine. He concludes that, hey, if the code works, use it — a stance that won't sit well with purists. But his article raises the question: is it better to embrace some closed source fixes, and so create a larger user base, or to remain pure, and keep Linux for the specialists?"

jammag writes "Linux pundit Bruce Byfield takes a look at the latest KDE beta and finds it wanting: 'Very likely, KDE users will have to wait for another release or two beyond 4.1 before the new version of KDE matches the features of earlier ones, especially in customization.' He notes that the second beta is still prone to unexplained crashes, and goes so far as to say, 'Everyone agrees now that KDE 4.0 was a mistake.' I'm not too sure about that — really, 'everyone?'"

jammag writes "Linux pundit Bruce Byfield takes a look at the latest KDE beta and finds it wanting: 'Very likely, KDE users will have to wait for another release or two beyond 4.1 before the new version of KDE matches the features of earlier ones, especially in customization.' He notes that the second beta is still prone to unexplained crashes, and goes so far as to say, 'Everyone agrees now that KDE 4.0 was a mistake.' I'm not too sure about that — really, 'everyone?'"

jammag writes "'"You are an idiot." That was how I was greeted on an already gloomy, rainy Monday morning.' Eric Spiegel offer his a first-hand account of dealing with a tech world geek-gone-bad and presents some ideas for coping. 'These bullies are quick to aggressively divert blame for any problem back to someone else, because they couldn't possibly be responsible. Some are passive aggressive, where they will subtly lay blame behind your back. Others enjoy getting in your face and being as confrontational as possible.'" What experiences have others had that defied all logic and possibly made you want to start looking for rifles and bell towers?

jammag writes "'"You are an idiot." That was how I was greeted on an already gloomy, rainy Monday morning.' Eric Spiegel offer his a first-hand account of dealing with a tech world geek-gone-bad and presents some ideas for coping. 'These bullies are quick to aggressively divert blame for any problem back to someone else, because they couldn't possibly be responsible. Some are passive aggressive, where they will subtly lay blame behind your back. Others enjoy getting in your face and being as confrontational as possible.'" What experiences have others had that defied all logic and possibly made you want to start looking for rifles and bell towers?

jammag writes "If the marriage of Microsoft and Yahoo were to be consummated, GNU/Linux would be hindered, argues Roy Schestowitz. Yahoo's funding of open source initiatives would dry up. Yahoo, which acquired Zimbra, would lose its love for the open source competitor of Microsoft Outlook. The list goes on..."

jammag writes "If the marriage of Microsoft and Yahoo were to be consummated, GNU/Linux would be hindered, argues Roy Schestowitz. Yahoo's funding of open source initiatives would dry up. Yahoo, which acquired Zimbra, would lose its love for the open source competitor of Microsoft Outlook. The list goes on..."

hedley writes "A prior article on the damage Java does to CS education was discussed here recently. There was substantial feedback and the mailbox of one of the authors, Prof Dewar, also has been filled with mainly positive responses. In this followup to the article, Prof. Dewar clarifies his position on Java. In his view the core of the problem is universities 'dumbing down programs, hoping to make them more accessible and popular. Aspects of curriculum that are too demanding, or perceived as tedious, are downplayed in favor of simplified material that attracts a larger enrollment.'"

christian.einfeldt writes "Computer scientist and media maven Roy Schestowitz takes a look at platforms where GNU Linux gained the most ground in 2007. In a thorough review which is the first of a two-part series, Schestowitz looks at trends in supercomputers, mobile phones, desktops, low-end laptops and tablets, consoles, media players and set-top boxes. Schestowitz finds that GNU Linux solidified its dominant grip on supercomputers; made huge gains in low-end laptops and tablets; won major OEM and retail support on the desktop; gained new entries into game consoles; and also spawned new businesses in set-top boxes while holding its ground in pre-existing product lines. He sums it all up by saying that '2007 will be remembered as the year when GNU/Linux became not only available, but also properly preinstalled on desktops and laptops by the world's largest companies.'"

jammag writes "Linux pundit Bruce Byfield looked inside the pre-release of Gutsy Gibbon and found what he calls 'Windows thinking.' His article, Divining from the Entrails of Ubuntu's Gutsy Gibbon, notes that Ubuntu is the dominant distro, having achieved a level of success that might be leading to complacency. He opines: 'Only once or twice did I find a balance between accessibility to newcomers and a feature set for advanced users. At times, I wondered whether the popularity might be preventing Ubuntu from finishing some rough edges.'"

jammag writes "Linux pundit Bruce Byfield looked inside the pre-release of Gutsy Gibbon and found what he calls 'Windows thinking.' His article, Divining from the Entrails of Ubuntu's Gutsy Gibbon, notes that Ubuntu is the dominant distro, having achieved a level of success that might be leading to complacency. He opines: 'Only once or twice did I find a balance between accessibility to newcomers and a feature set for advanced users. At times, I wondered whether the popularity might be preventing Ubuntu from finishing some rough edges.'"

jammag writes "An article at the site Datamation, entitled Becoming a Linux OEM: A Roadmap, talks about the challenges (and rewards) of selling hardware with Linux pre-installed — most likely a growth market in the years ahead. The interesting part is the description of how some smaller Linux OEMs have made it. The bottom line: surviving as a Linux OEM requires far more than making it as a Windows OEM. In particular, you have to make the systems idiot-proof for users who don't care a whit about what OS they're using."

jammag writes "An article at the site Datamation, entitled Becoming a Linux OEM: A Roadmap, talks about the challenges (and rewards) of selling hardware with Linux pre-installed — most likely a growth market in the years ahead. The interesting part is the description of how some smaller Linux OEMs have made it. The bottom line: surviving as a Linux OEM requires far more than making it as a Windows OEM. In particular, you have to make the systems idiot-proof for users who don't care a whit about what OS they're using."

jammag writes "In this article, Adrian Kingsley-Hughes points out why he keeps giving money to Microsoft and Apple despite the clear advantages of Linux: the scary legalese dialogs you have to click through to install codecs for common multimedia formats. Quoting: 'Despite strong points that go far beyond price, Linux falls short when it comes to legally supporting file formats such as MP3, WMA/WMV and DVDs.' He talks about using Ubuntu and booting up Totem Movie Player, only to be confronted with a burst of legalese about what a hardened criminal he'll be if he uses Totem without a license. This problem is 'a deal breaker' for him."

jammag writes "In this article, Adrian Kingsley-Hughes points out why he keeps giving money to Microsoft and Apple despite the clear advantages of Linux: the scary legalese dialogs you have to click through to install codecs for common multimedia formats. Quoting: 'Despite strong points that go far beyond price, Linux falls short when it comes to legally supporting file formats such as MP3, WMA/WMV and DVDs.' He talks about using Ubuntu and booting up Totem Movie Player, only to be confronted with a burst of legalese about what a hardened criminal he'll be if he uses Totem without a license. This problem is 'a deal breaker' for him."

An anonymous reader writes "A great deal of attention is paid to numbers, but rarely does one actually ask what these numbers mean. One problem that many people have been trying to tackle is gauging the extent of use of Free software, including Linux. Questionnaires are not a solution here and neither are statistics, which are usually derived from the wrong data. The following article looks at the various challenges at hand and concludes that the growth rate of Linux is likely to remain an enigma."

42istheanswer writes "Open source is so much more than Linux these days. A lot is happening beyond the popular operating system. Open source models are thriving in CRM (SugarCRM), messaging (Scalix), and systems management (Zenoss). Datamation has identified ten leading commercial open-source innovators and the projects they are working on in their article, Ten Leading Open Source Innovators."

Quill345 writes "The days of high-paying technology-based jobs right out of highschool are over. As writers for ACM report, the skill-sets required for jobs have grown over time. Academia has responded to the evolution with novel programs recruiting women and integrating IT into MBA programs. And as technology finds its way into every aspect of business life, the NSF is creating a grant program to fund service science, a blend of IT into other industries. Researchers at City University of NY are working on an NSF-funded project to infuse technology into Liberal Arts courses taken by students who are in primary tech-producer or tech-consumer majors. What are these crucial modern skills? Knowledge of laws like the DMCA? Interpersonal and group work skills? Experience with different technology platforms? The ability to discriminate between useful and useless information sources?"

Ronald Dumsfeld writes "The odds of folks under the age of 25 on Slashdot having heard of DECnet are pretty slim. This article over at Datamation gives some insight into people who've not given up on it. Poke around and find the documentation for the OSI-compliant version, or download the Linux version of the older DECnet IV and bask in the Security Through Obscurity."

Ronald Dumsfeld writes "The odds of folks under the age of 25 on Slashdot having heard of DECnet are pretty slim. This article over at Datamation gives some insight into people who've not given up on it. Poke around and find the documentation for the OSI-compliant version, or download the Linux version of the older DECnet IV and bask in the Security Through Obscurity."

abertoll writes "In this story at ZDnet, Red Hat has apparently added NX support to Linux. NX security technology is a hardware attempt at stopping malicious code." (We recently posted about Transmeta's announcement that its chips will incorporate the NX bit as well.)

Mostly a lurker asks: "I am a consultant with a need for a high performance machine (fast I/O and minimum 1GB RAM, perhaps more) with which I sometimes travel. I am willing to accept anything up to a 20lb traveling weight, but it must be compact enough to take by air. I would obviously welcome something that does not break the bank. Right now, the best I can come up with is something built around the Shuttle SB51G XPC with a separate LCD monitor and keyboard. It is really frustrating at the apparent lack of good alternatives. If I could wait six months then, the best desknotes would probably fit the bill (with the new IBM 7200 RPM drives). Today's desknotes fall short on I/O performance, and I would not be able to push RAM past 1GB. The lunchbox computers that qualify for air travel are mostly expensive rubbish, unless one's main concern is ruggedization. All-in-one computers like the IBM NetVista, Gateway Profile and ECS Aio's also seem to fall short. So, am I totally missing another great option? Have I mis-evaluated one of the options above? If I go the Shuttle XPC route, is there a really good light (and, equally important, compact) LCD monitor out there that someone wants to recommend [15" minimum, 17" would be nice, 30ms refresh or better, XGA acceptable, SXGA nice]? Thanks."

randomErr writes "Earthweb/Internet.com has this article about a new ultra slim camera for $130. It has no flash, zoom, or LCD monitor, and takes snapshots instead of spectacular pictures. The advertised resolution is 1.3 megapixels with and actual resolution of 640 by 480. But it's the size of a credit card, half an inch thin, with all-day battery and image capacity."

randomErr writes "Earthweb/Internet.com has this article about a new ultra slim camera for $130. It has no flash, zoom, or LCD monitor, and takes snapshots instead of spectacular pictures. The advertised resolution is 1.3 megapixels with and actual resolution of 640 by 480. But it's the size of a credit card, half an inch thin, with all-day battery and image capacity."

windows bios world writes: "As this article states, 'There was little love from the leaders of the Java movement toward Microsoft's new framework for creating Web services, but there were signs of accommodation among some at the conference.' One of the most popular booth-trinkets was a button with a slash through it that said .NOT. A video shown at the first keynote depicted the Java Smart Car driving circles around a Bill Gates look-alike. The back of Bill's T-shirt, of course, was emblazoned with a J-flat logo instead of J-sharp."

viperjsw writes: "Earthweb is running an interesting article on how there seems to be a failing trend in newer 7,200 RPM IDE hard drives. I am the lead hardware engineer for my co with four thousand 7,200 RPM ATA100 Maxtor and IBM hard drives. I have not seen any failure trends, though failure rates are at about 5-10%. Are Earthweb's reports verifiable?"

viperjsw writes: "Earthweb is running an interesting article on how there seems to be a failing trend in newer 7,200 RPM IDE hard drives. I am the lead hardware engineer for my co with four thousand 7,200 RPM ATA100 Maxtor and IBM hard drives. I have not seen any failure trends, though failure rates are at about 5-10%. Are Earthweb's reports verifiable?"

Charles Connell writes: "What makes a programmer highly productive? Is it lines of code per day? Lines of good code? In this article, I examine the concept of software productivity. I look at some of the standard definitions for productivity and show why they are wrong. I then propose a new definition that captures what programming really is about." Read on for Connell's stab at a better way of evaluating the worth of programmer time. CT Originally the contents of an article were here but there was a communication problem resulting in us thinking we were given permission to print the article here. Now that things have been cleared up, we've linked the original article which you can read instead. Sorry about the inconvenience.

idiotnot writes: "This editorial from the New York Times, by Jonathan L. Zittrain, a professor at Harvard Law School, urges legislators to exercise caution in regulating the PC. Eisner, et. al. want to limit the PC's capability, which will limit what PC users are allowed to do. See this earlier story about Eisner's testimony to Congress. '[W]e should beware the haste with which some would sacrifice flexibility for control.'" Other readers submitted a story in Hardware Central and an AP article. Seems like the ruckus over the SSSCA is finally reaching the mainstream press.

Dare Obasanjo contributed this followup to an article entitled The Myth of Open Source Security Revisited that appeared on the website kuro5hin. He writes: "The original article tackled the common misconception amongst users of Open Source Software(OSS) that OSS is a panacea when it comes to creating secure software. The article presented anecdotal evidence taken from an article written by John Viega, the original author of GNU Mailman, to illustrate its point. This article follows up the anecdotal evidence presented in the original paper by providing an analysis of similar software applications, their development methodology and the frequency of the discovery of security vulnerabilities." Read on below for his detailed analysis, especially relevant with the currency of security initiatives in the worlds of both open- and closed-source software.

The Myth of Open Source Security Revisited v2.0 The purpose of this article is to expose the fallacy of the belief in the "inherent security" of Open Source software and instead point to a truer means of ensuring the quality of the security of a piece software is high.

Apples, Oranges, Penguins and Daemons

When performing experiments to confirm a hypothesis on the effect of a particular variable on an event or observable occurence, it is common practice to utilize control groups. In an attempt to establish cause and effect in such experiments, one tries to hold all variables that may affect the outcome constant except for the variable that the experiment is interested in. Comparisons of the security of software created by Open Source processes and software produced in a proprietary manner have typically involved several variables besides development methodology.

A number of articles have been written that compare the security of Open Source development to proprietary development by comparing security vulnerabilities in Microsoft products to those in Open Source products. Noted Open Source pundit, Eric Raymond wrote an article on NewsForge where he compares Microsoft Windows and IIS to Linux, BSD and Apache. In the article, Eric Raymond states that Open Source development implies that "security holes will be infrequent, the compromises they cause will be relatively minor, and fixes will be rapidly developed and deployed." However, upon investigation it is disputable that Linux distributions have less frequent or more minor security vulnerabilities when compared to recent versions of Windows. In fact the belief in the inherent security of Open Source software over proprietary software seems to be the product of a single comparison, Apache versus Microsoft IIS.

There are a number of variables involved when one compares the security of software such as Microsoft Windows operating systems to Open Source UNIX-like operating systems including the disparity in their market share, the requirements and dispensations of their user base, and the differences in system design. To better compare the impact of source code licensing on the security of the software, it is wise to reduce the number of variables that will skew the conclusion. To this effect it is best to compare software with similar system design and user base than comparing software applications that are significantly distinct. The following section analyzes the frequency of the discovery of security vulnerabilities in UNIX-like operating systems including HP-UX, FreeBSD, RedHat Linux, OpenBSD, Solaris, Mandrake Linux, AIX and Debian GNU/Linux.

Security Vulnerability Face-Off

Below is a listing of UNIX and UNIX-like operating systems with the number of security vulnerabilities that were discovered in them in 2001 according to the Security Focus Vulnerability Archive. AIX 10 vulnerabilities[6 remote, 3 local, 1 both] Debian GNU/Linux 13 vulnerabilities[1 remote, 12 local] + 1 Linux kernel vulnerability[1 local] FreeBSD 24 vulnerabilities[12 remote, 9 local, 3 both] HP-UX 25 vulnerabilities[12 remote, 12 local, 1 both] Mandrake Linux 17 vulnerabilities[5 remote, 12 local] + 12 Linux kernel vulnerabilities[5 remote, 7 local] OpenBSD 13 vulnerabilities[7 remote, 5 local, 1 both] Red Hat Linux 28 vulnerabilities[5 remote, 22 local, 1 unknown] + 12 Linux kernel vulnerabilities[6 remote, 6 local] Solaris 38 vulnerabilities[14 remote, 22 local, 2 both] From the above listing one can infer that source licensing is not a primary factor in determining how prone to security flaws a software application will be. Specifically proprietary and Open Source UNIX family operating systems are represented on both the high and low ends of the frequency distribution.

Factors that have been known to influence the security and quality of a software application are practices such as code auditing (peer review), security-minded architecture design, strict software development practices that restrict certain dangerous programming constructs (e.g. using the str* or scanf* family of functions in C) and validation & verification of the design and implementation of the software. Also reducing the focus on deadlines and only shipping when the system the system is in a satisfactory state is important.

Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record. Debian's track record is particularly impressive when one realizes that the Debian Potato consists of over 55 million lines of code (compared to RedHat's 30,000,000 lines of code).

The Road To Secure Software

Exploitable security vulnerabilities in a software application are typically evidence of bugs in the design or implementation of the application. Thus the process of writing secure software is an extension of the process behind writing robust, high quality software. Over the years a number of methodolgies have been developed to tackle the problem of producing high quality software in a repeatable manner within time and budgetary constraints. The most successful methodologies have typically involved using the following software quality assurance, validation and verification techniques; formal methods, code audits, design reviews, extensive testing and codified best practices.

1. Formal Methods: One can use formal proofs based on mathematical methods and rigor to verify the correctness of software algorithms. Tools for specifying software using formal techniques exist such as VDM and Z. Z (pronounced 'zed') is a formal specification notation based on set theory and first order predicate logic. VDM stands for "The Vienna Development Method" which consists of a specification language called VDM-SL, rules for data and operation refinement which allow one to establish links between abstract requirements specifications and detailed design specifications down to the level of code, and a proof theory in which rigorous arguments can be conducted about the properties of specified systems and the correctness of design decisions.The previous descriptions were taken from the Z FAQ and the VDM FAQ respectively. A comparison of both specification languages is available in the paper, Understanding the differences between VDM and Z by I.J. Hayes et al.
   
   
2. Code Audits: Reviews of source code by developers other than the author of the code are good ways to catch errors that may have been overlooked by the original developer. Source code audits can vary from informal reviews with little structure to formal code inspections or walkthroughs. Informal reviews typically involve the developer sending the reviewers source code or descriptions of the software for feedback on any bugs or design issues. A walkthrough involves the detailed examination of the source code of the software in question by one or more reviewers. An inspection is a formal process where a detailed examination of the source code is directed by reviewers who act in certain roles. A code inspection is directed by a "moderator", the source code is read by a "reader" and issues are documented by a "scribe".
   
   
3. Testing: The purpose of testing is to find failures. Unfortunately, no known software testing method can discover all possible failures that may occur in a faulty application and metrics to establish such details have not been forthcoming. Thus a correlation between the quality of a software application and the amount of testing it has endured is practically non-existent.
   
   There are various categories of tests including unit, component, system, integration, regression, black-box, and white-box tests. There is some overlap in the aforementioned mentioned testing categories.
   
   Unit testing involves testing small pieces of functionality of the application such as methods, functions or subroutines. In unit testing it is usual for other components that the software unit interacts with to be replaced with stubs or dummy methods. Component tests are similar to unit tests with the exception that dummmy and stub methods are replaced with the actual working versions. Integration testing involves testing related components that communicate with each other while system tests involve testing the entire system after it has been built. System testing is necessary even if extensive unit or component testing has occured because it is possible for seperate subroutines to work individually but fail when invoked sequentialy due to side effects or some error in programmer logic. Regression testing involves the process of ensuring that modifications to a software module, component or system have not introduced errors into the software. A lack of sufficient regression testing is one of the reasons why certain software patches break components that worked prior to installation of the patch.
   
   Black-box testing also called functional testing or specification testing test the behavior of the component or system without requiring knowledge of the internal structure of the software. Black-box testing is typically used to test that software meets its functional requirements. White-box testing also called structural or clear-box testing involves tests that utilize knowledge of the internal structure of the software. White-box testing is useful in ensuring that certain statements in the program are excercised and errors discovered. The existence of code coverage tools aid in discovering what percentages of a system are being excercised by the tests.
   
   More information on testing can be found at the comp.software.testing FAQ .
   
   
4. Design Reviews: The architecture of a software application can be reviewed in a formal process called a design review. In design reviews the developers, domain experts and users examine that the design of the system meets the requirements and that it contains no significant flaws of omission or commission before implementation occurs.
   
   
5. Codified Best Practices: Some programming languages have libraries or language features that are prone to abuse and are thus prohibited in certain disciplined software projects. Functions like strcpy, gets, and scanf in C are examples of library functions that are poorly designed and allow malicious individuals to use buffer overflows or format string attacks to exploit the security vulnerabilities exposed by using these functions. A number of platforms explicitly disallow gets especially since alternatives exist. Programming guidelines for such as those written by Peter Galvin in a Unix Insider article on designing secure software are used by development teams to reduce the likelihood of security vulnerabilities in software applications.

Projects such as the OpenBSD project that utilize most of the aforementioned techniques in developing software typically have a low incidence of security vulnerabilities.

Issues Preventing Development of Secure Open Source Software

One of the assumptions that is typically made about Open Source software is that the availability of source code translates to "peer review" of the software application. However, the anecdotal experience of a number of Open Source developers including John Viega belies this assumption.

The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including

• complexity of code in addition to a lack of documentation makes it difficult for casual users to understand the code enough to give a proper review
  
  
• developers making improvements to the application typically focus only on the parts of the application that will affect the feature to be added instead of the whole system.
  
  
• ignorance of developers to security concerns.
  
  
• complacency in the belief that since the source is available that it is being reviewed by others.
  
  

Also the lack of interest in unglamorous tasks like documentation and testing amongst Open Source contributors adversely affects quality of the software. However, all of these issues can and are solved in projects with a disciplined software development process, clearly defined roles for the contributers and a semi-structured leadership hierarchy.

Benefits of Open Source to Security-Conscious Users

Despite the fact that source licensing and source code availability are not indicators of the security of a software application, there is still a significant benefit of Open Source to some users concerned about security. Open Source allows experts to audit their software options before making a choice and also in some cases to make improvements without waiting for fixes from the vendor or source code maintainer.

One should note that there are constraints on the feasibility of users auditing the software based on the complexity and size of the code base. For instance, it is unlikely that a user who wants to make a choice of using Linux as a web server for a personal homepage will scrutinize the TCP/IP stack code.

References

1. Frankl, Phylis et al. Choosing a Testing Method to Deliver Reliability. Proceedings of the 19th International Conference on Software Engineering, pp. 68--78, ACM Press, May 1997. < http://citeseer.nj.nec.com/frankl97choosing.html >
   
   
2. Hamlet, Dick. Software Quality, Software Process, and Software Testing. 1994. < http://citeseer.nj.nec.com/hamlet94software.html >
   
   
3. Hayes, I.J., C.B. Jones and J.E. Nicholls. Understanding the differences between VDM and Z. Technical Report UMCS-93-8-1, University of Manchester, Computer Science Dept., 1993. < http://citeseer.nj.nec.com/hayes93understanding.ht ml >
   
   
4. Miller, Todd C. and Theo De Raadt. strlcpy and strlcat - consistent, safe, string copy and concatenation. Proceedings of the 1999 USENIX Annual Technical Conference, FREENIX Track, June 1999. < http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/ >
   
   
5. Viega, John. The Myth of Open Source Security. Earthweb.com. < http://www.earthweb.com/article/0,,10455_626641,00 .html >
   
   
6. Gonzalez-Barona, Jesus M. et al. Counting Potatoes: The Size of Debian 2.2. < http://people.debian.org/~jgb/debian-counting/coun ting-potatoes/ >
   
   
7. Wheeler, David A. More Than A Gigabuck: Estimating GNU/Linux's Size. < http://www.counterpane.com/crypto-gram-0003.html >
   
   

Acknowledgements

The following people helped in proofreading this article and/or offering suggestions about content: Jon Beckham, Graham Keith Coleman, Chris Bradfield, and David Dagon. © 2002 Dare Obasanjo

Dare Obasanjo contributed this followup to an article entitled The Myth of Open Source Security Revisited that appeared on the website kuro5hin. He writes: "The original article tackled the common misconception amongst users of Open Source Software(OSS) that OSS is a panacea when it comes to creating secure software. The article presented anecdotal evidence taken from an article written by John Viega, the original author of GNU Mailman, to illustrate its point. This article follows up the anecdotal evidence presented in the original paper by providing an analysis of similar software applications, their development methodology and the frequency of the discovery of security vulnerabilities." Read on below for his detailed analysis, especially relevant with the currency of security initiatives in the worlds of both open- and closed-source software.

The Myth of Open Source Security Revisited v2.0 The purpose of this article is to expose the fallacy of the belief in the "inherent security" of Open Source software and instead point to a truer means of ensuring the quality of the security of a piece software is high.

Apples, Oranges, Penguins and Daemons

When performing experiments to confirm a hypothesis on the effect of a particular variable on an event or observable occurence, it is common practice to utilize control groups. In an attempt to establish cause and effect in such experiments, one tries to hold all variables that may affect the outcome constant except for the variable that the experiment is interested in. Comparisons of the security of software created by Open Source processes and software produced in a proprietary manner have typically involved several variables besides development methodology.

A number of articles have been written that compare the security of Open Source development to proprietary development by comparing security vulnerabilities in Microsoft products to those in Open Source products. Noted Open Source pundit, Eric Raymond wrote an article on NewsForge where he compares Microsoft Windows and IIS to Linux, BSD and Apache. In the article, Eric Raymond states that Open Source development implies that "security holes will be infrequent, the compromises they cause will be relatively minor, and fixes will be rapidly developed and deployed." However, upon investigation it is disputable that Linux distributions have less frequent or more minor security vulnerabilities when compared to recent versions of Windows. In fact the belief in the inherent security of Open Source software over proprietary software seems to be the product of a single comparison, Apache versus Microsoft IIS.

There are a number of variables involved when one compares the security of software such as Microsoft Windows operating systems to Open Source UNIX-like operating systems including the disparity in their market share, the requirements and dispensations of their user base, and the differences in system design. To better compare the impact of source code licensing on the security of the software, it is wise to reduce the number of variables that will skew the conclusion. To this effect it is best to compare software with similar system design and user base than comparing software applications that are significantly distinct. The following section analyzes the frequency of the discovery of security vulnerabilities in UNIX-like operating systems including HP-UX, FreeBSD, RedHat Linux, OpenBSD, Solaris, Mandrake Linux, AIX and Debian GNU/Linux.

Security Vulnerability Face-Off

Below is a listing of UNIX and UNIX-like operating systems with the number of security vulnerabilities that were discovered in them in 2001 according to the Security Focus Vulnerability Archive. AIX 10 vulnerabilities[6 remote, 3 local, 1 both] Debian GNU/Linux 13 vulnerabilities[1 remote, 12 local] + 1 Linux kernel vulnerability[1 local] FreeBSD 24 vulnerabilities[12 remote, 9 local, 3 both] HP-UX 25 vulnerabilities[12 remote, 12 local, 1 both] Mandrake Linux 17 vulnerabilities[5 remote, 12 local] + 12 Linux kernel vulnerabilities[5 remote, 7 local] OpenBSD 13 vulnerabilities[7 remote, 5 local, 1 both] Red Hat Linux 28 vulnerabilities[5 remote, 22 local, 1 unknown] + 12 Linux kernel vulnerabilities[6 remote, 6 local] Solaris 38 vulnerabilities[14 remote, 22 local, 2 both] From the above listing one can infer that source licensing is not a primary factor in determining how prone to security flaws a software application will be. Specifically proprietary and Open Source UNIX family operating systems are represented on both the high and low ends of the frequency distribution.

Factors that have been known to influence the security and quality of a software application are practices such as code auditing (peer review), security-minded architecture design, strict software development practices that restrict certain dangerous programming constructs (e.g. using the str* or scanf* family of functions in C) and validation & verification of the design and implementation of the software. Also reducing the focus on deadlines and only shipping when the system the system is in a satisfactory state is important.

Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record. Debian's track record is particularly impressive when one realizes that the Debian Potato consists of over 55 million lines of code (compared to RedHat's 30,000,000 lines of code).

The Road To Secure Software

Exploitable security vulnerabilities in a software application are typically evidence of bugs in the design or implementation of the application. Thus the process of writing secure software is an extension of the process behind writing robust, high quality software. Over the years a number of methodolgies have been developed to tackle the problem of producing high quality software in a repeatable manner within time and budgetary constraints. The most successful methodologies have typically involved using the following software quality assurance, validation and verification techniques; formal methods, code audits, design reviews, extensive testing and codified best practices.

1. Formal Methods: One can use formal proofs based on mathematical methods and rigor to verify the correctness of software algorithms. Tools for specifying software using formal techniques exist such as VDM and Z. Z (pronounced 'zed') is a formal specification notation based on set theory and first order predicate logic. VDM stands for "The Vienna Development Method" which consists of a specification language called VDM-SL, rules for data and operation refinement which allow one to establish links between abstract requirements specifications and detailed design specifications down to the level of code, and a proof theory in which rigorous arguments can be conducted about the properties of specified systems and the correctness of design decisions.The previous descriptions were taken from the Z FAQ and the VDM FAQ respectively. A comparison of both specification languages is available in the paper, Understanding the differences between VDM and Z by I.J. Hayes et al.
   
   
2. Code Audits: Reviews of source code by developers other than the author of the code are good ways to catch errors that may have been overlooked by the original developer. Source code audits can vary from informal reviews with little structure to formal code inspections or walkthroughs. Informal reviews typically involve the developer sending the reviewers source code or descriptions of the software for feedback on any bugs or design issues. A walkthrough involves the detailed examination of the source code of the software in question by one or more reviewers. An inspection is a formal process where a detailed examination of the source code is directed by reviewers who act in certain roles. A code inspection is directed by a "moderator", the source code is read by a "reader" and issues are documented by a "scribe".
   
   
3. Testing: The purpose of testing is to find failures. Unfortunately, no known software testing method can discover all possible failures that may occur in a faulty application and metrics to establish such details have not been forthcoming. Thus a correlation between the quality of a software application and the amount of testing it has endured is practically non-existent.
   
   There are various categories of tests including unit, component, system, integration, regression, black-box, and white-box tests. There is some overlap in the aforementioned mentioned testing categories.
   
   Unit testing involves testing small pieces of functionality of the application such as methods, functions or subroutines. In unit testing it is usual for other components that the software unit interacts with to be replaced with stubs or dummy methods. Component tests are similar to unit tests with the exception that dummmy and stub methods are replaced with the actual working versions. Integration testing involves testing related components that communicate with each other while system tests involve testing the entire system after it has been built. System testing is necessary even if extensive unit or component testing has occured because it is possible for seperate subroutines to work individually but fail when invoked sequentialy due to side effects or some error in programmer logic. Regression testing involves the process of ensuring that modifications to a software module, component or system have not introduced errors into the software. A lack of sufficient regression testing is one of the reasons why certain software patches break components that worked prior to installation of the patch.
   
   Black-box testing also called functional testing or specification testing test the behavior of the component or system without requiring knowledge of the internal structure of the software. Black-box testing is typically used to test that software meets its functional requirements. White-box testing also called structural or clear-box testing involves tests that utilize knowledge of the internal structure of the software. White-box testing is useful in ensuring that certain statements in the program are excercised and errors discovered. The existence of code coverage tools aid in discovering what percentages of a system are being excercised by the tests.
   
   More information on testing can be found at the comp.software.testing FAQ .
   
   
4. Design Reviews: The architecture of a software application can be reviewed in a formal process called a design review. In design reviews the developers, domain experts and users examine that the design of the system meets the requirements and that it contains no significant flaws of omission or commission before implementation occurs.
   
   
5. Codified Best Practices: Some programming languages have libraries or language features that are prone to abuse and are thus prohibited in certain disciplined software projects. Functions like strcpy, gets, and scanf in C are examples of library functions that are poorly designed and allow malicious individuals to use buffer overflows or format string attacks to exploit the security vulnerabilities exposed by using these functions. A number of platforms explicitly disallow gets especially since alternatives exist. Programming guidelines for such as those written by Peter Galvin in a Unix Insider article on designing secure software are used by development teams to reduce the likelihood of security vulnerabilities in software applications.

Projects such as the OpenBSD project that utilize most of the aforementioned techniques in developing software typically have a low incidence of security vulnerabilities.

Issues Preventing Development of Secure Open Source Software

One of the assumptions that is typically made about Open Source software is that the availability of source code translates to "peer review" of the software application. However, the anecdotal experience of a number of Open Source developers including John Viega belies this assumption.

The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including

• complexity of code in addition to a lack of documentation makes it difficult for casual users to understand the code enough to give a proper review
  
  
• developers making improvements to the application typically focus only on the parts of the application that will affect the feature to be added instead of the whole system.
  
  
• ignorance of developers to security concerns.
  
  
• complacency in the belief that since the source is available that it is being reviewed by others.
  
  

Also the lack of interest in unglamorous tasks like documentation and testing amongst Open Source contributors adversely affects quality of the software. However, all of these issues can and are solved in projects with a disciplined software development process, clearly defined roles for the contributers and a semi-structured leadership hierarchy.

Benefits of Open Source to Security-Conscious Users

Despite the fact that source licensing and source code availability are not indicators of the security of a software application, there is still a significant benefit of Open Source to some users concerned about security. Open Source allows experts to audit their software options before making a choice and also in some cases to make improvements without waiting for fixes from the vendor or source code maintainer.

One should note that there are constraints on the feasibility of users auditing the software based on the complexity and size of the code base. For instance, it is unlikely that a user who wants to make a choice of using Linux as a web server for a personal homepage will scrutinize the TCP/IP stack code.

References

1. Frankl, Phylis et al. Choosing a Testing Method to Deliver Reliability. Proceedings of the 19th International Conference on Software Engineering, pp. 68--78, ACM Press, May 1997. < http://citeseer.nj.nec.com/frankl97choosing.html >
   
   
2. Hamlet, Dick. Software Quality, Software Process, and Software Testing. 1994. < http://citeseer.nj.nec.com/hamlet94software.html >
   
   
3. Hayes, I.J., C.B. Jones and J.E. Nicholls. Understanding the differences between VDM and Z. Technical Report UMCS-93-8-1, University of Manchester, Computer Science Dept., 1993. < http://citeseer.nj.nec.com/hayes93understanding.ht ml >
   
   
4. Miller, Todd C. and Theo De Raadt. strlcpy and strlcat - consistent, safe, string copy and concatenation. Proceedings of the 1999 USENIX Annual Technical Conference, FREENIX Track, June 1999. < http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/ >
   
   
5. Viega, John. The Myth of Open Source Security. Earthweb.com. < http://www.earthweb.com/article/0,,10455_626641,00 .html >
   
   
6. Gonzalez-Barona, Jesus M. et al. Counting Potatoes: The Size of Debian 2.2. < http://people.debian.org/~jgb/debian-counting/coun ting-potatoes/ >
   
   
7. Wheeler, David A. More Than A Gigabuck: Estimating GNU/Linux's Size. < http://www.counterpane.com/crypto-gram-0003.html >
   
   

Acknowledgements

The following people helped in proofreading this article and/or offering suggestions about content: Jon Beckham, Graham Keith Coleman, Chris Bradfield, and David Dagon. © 2002 Dare Obasanjo

Charles Connell submitted this analysis on software estimation, a topic which keeps coming up because it affects so many many programmers. Read this post about J.P. Lewis's earlier piece as well, if you'd like more background information.

Slashback with more on Wesley Crusher; overclocking new Athlons the kindler, gentler way; building silent PCs for the more ambitious; software that stinks; and more -- just read on for the details.

That fetid odor continues to rise. cconnell writes "In September, Slashdot and Developer.com were kind enough to publish an article I wrote titled Most Software Stinks!. The article generated 748 comments on slashdot, making it one of the most active stories in recent months. Here is a follow up piece I wrote which responds to some of the comments."

Silence, fool! The Panther! writes "Here's an article I wrote that shows step by step how to achieve some measure of silence in my home office. It's different from most in that it approaches damping existing hardware rather than buying new. Some ideas were suggestions of Slashdot readers from a previous article. Lots of photos for the reading-impaired." Hemos may have been going for a rather normal-looking but quiet PC, but The Panther sure isn't.

Step 39: With your dremel strapped to the hamster, gently nudge the billiard ball ... Now that the famous pencil trick isn't an option for would-be AMD overclockers, more complicated means have been found to unlock and reclock. Carlos writes: "I saw that you have a scoopage on the unlocking of the Athlon XP by Tom's Hardware and there is a better and more reversible way by VR-Zone."

200 years is a long time even for a Congressman. Michael H. writes "Woohoo! Congress has given a $30 million shot in the arm to the Pluto-Kuiper Belt mission, previously feared canceled. CNN story here. There's still no guarantee that it won't be canceled later, but at least Congress is listening to the fact that it would take ~200 years for the next window if we missed this one."

Hey, that guy's too old to be a kernel maintainer -- we'll make him an actor. bahamat wrote yesterday: "I'm hanging out in Wil Wheaton's chat room (#rfb on undernet) and he's just announced that he's going to be making a cameo as Wesley Crusher in the new Star Trek X." Apparently, the news hit quite a few readers, too -- and for those who haven't, check out our interview with Wil. Maybe he'll get to be on The Tick, too.

Myrv writes: "There is an interesting thread over at DSL Reports discussing Phoenix Technologies new BIOS. This BIOS contains the PhoenixNet Internet Launch System . ILS resides safely within ROM and is activated the first time a user launches a PhoenixNet-enabled PC with a Windows 98 Operating System. When the PhoenixNet ILS detects an Internet connection, it makes contact with the PhoenixNet server and delivers user-selectable services. These services are delivered to the user as hotlinks on the desktop and in the web browser or, as applications that PhoenixNet automatically packages, downloads and installs. It's 3 a.m., do you know who your motherboard's talking to????" We've gotten a couple of submissions about this - another submitter pointed out this thread and this description by Phoenix. Phoenix has apparently been kicking this idea around for a while - see this old Slashdot story. Does anyone have any more information?

gabbarsingh sent this in via punchcard: "What's happening at Sun on the MAJC front? They haven't released anything new on that. The first samples were promised in first half of 2000." MAJC (pronounced "magic"), stands for Microprocessor Architecture for Java Computing, and according to EDTN is the only hardware java implementation that combines both multithreading and multiprocessing. It seems that "Java on a Chip" solutions are more commonplace now, than they were when Rockwell released the first, back in 1997. Might the promise of code that you can "Write Once, Run Anywhere" soon become reality, now that there is an actual platform on which it can run (rather than piggybacking on other platforms via JVMs)?

BrookHarty sent us a story that proves that sometimes it's the little things that are clever. Are you as annoyed as I am that those pesky IDE cables are big flat things that are hard to move around? Well, here's a HOWTO that explains, well, how to round them out! It won't solve global warming or change the world. But dang it, that's cool.

Porthop points out this "interesting developer.com story regarding the security of open source software, in regards to theories that many eyes looking at the source will alleviate security problems." It ain't necessarily so, emphasis on necessarily. Last week it was discovered that, in some (uncommon) cases, a really stupid brainfart bug makes PGP5 key generation not very random. The bug lived for a year in open-source code before being found. If you generated a key pair non-interactively with PGP5 on a unix machine, don't panic and read carefully; you may want to invalidate your key. Update, next day: several people have pointed out that although PGP5's code is available (crypto requires code review), it can't be used for any product without permission. Incentive for code review is therefore less than for other projects of its importance, and I really shouldn't have called PGP "open-source." Mea culpa.

Yep, it's that time again! Nghia gave us a link to some "Jedi Academy" trailers. Several folks wrote in to say that the guys at Themes.org have a new look. forehead graciously provided an "interesting" bit, based on this "Richard Stallman-as-Marx" posting. "I decided to rework the whole song". Orbitz pointed us at a web-controlled RC car with camera. Next is my favorite, as submitted by Electric Keet, Stick Figure Porn. Thyla pointed us in the general direction of Carbonated Borscht for the Evil Geek's Soul, with a thanks to Illiad. Crazy Man on Fire gave us a link to upcoming distributed.net projects coming out soon. poink threw us a link to The Cereal Page (Ok, someone has waaaay too much time on his hands...) J. Pierpont gave us a link to more info on Episode II and III. Now, from Armin Lenz submitted a link to a CPU Gurus, a new CPU site discussing various current and future processors. Finally, Mike Healy, one of The Bazaar dudes, sent us a status report. Read more for the skinny.

Mike Healy writes "Since Steve Blood, our event chairman, is out of the country - he is actually checking out a solar eclipse in Austria - i've taken it upon myself to give you all an update on the Bazaar. I'd wait for steve to get back, all bleary eyed, by i must squelch the rumors being promulgated by certain sales guys for other events, that we folded. This couldn't be further from the truth. Fact of the matter is we are scheduled, locked and loaded and PUMPED for December 14-16 at the javits NYC.

The Bazaar will be the first large scale conference on opensource software to hit the east coast and will stress program, program and program. Our Theory is that if you build it, they will .com

Not only does EarthWeb, by nature of being an IT content HUB have access to the freshest most imperative material, but we have also brought in an indstry expert, lydia Bennett of Dialogos fame, to aggregate and work closely with conference chairs and advisory board to make sure all tracks and tutorials are epic.

Check out the website for more on the program. The exhibit floor will be refreshingly unlike any you have seen in this space being made up of customed designed, turn key demo stations. This not only makes it a breeze for vendors , but also adds integity to the exhibit floor. No huge booths with revolving marquis, No loud PA systems. No freak shows. This is the wrong event to come to if you want to see Trumps daughter in a g string handing out T shirts... This is the right event if you want to meet some of the biggest brains out there and get no nonsense answers regarding opensource free software... Anyway, thats it for now.. More from Steve when he gets back"

Steve Blood sent an annoucment concerning the status of thebazaar, most especially it's changing status and re-scheduling.

As many of you know, the Bazaar has been going through a transition as we bring on a partner who will enable us to continue with our mission of creating a free software conference and expo that will benefit the free software development projects. That partner will be Earthweb, a company with a history of commitment to the developer community. Earthweb has been a tremendous supporter of our efforts and is excited to invest the necessary resources to bring us to a new level. Important to note: it is now definite that the dates of the Bazaar will change. We haven't settled on the new dates, but they will most likely be in July. It will still be held in New York.

Click below to read the rest of the announcement.

Unfortunately, the transition has not been as smooth as desired. The legal issues involved in teaming up with a nonprofit organization are apparently nontrivial and are still unresolved. Please bear with us, as we finalize things. I apologize for any inconveniences. If there's anything I can do please email me at sblood@thebazaar.org.

We would also like to thank all of you who have supported us throughout this entire endeavor. Those who know the history of the Bazaar are aware that this has not been an easy task, and the support from the free software community has been invaluable.

We will issue a press release as soon as everything is settled.

-steve blood

ps- speakers and developers, if you have incurred any costs due to us, please contact me and we'll make arrangements to help you cover them.