Jeff Atwood on Coding Horror blog reports a serious problem with G-Archiver, a Windows program for archiving GMail mailboxes. Dustin Brooks had emailed Atwood his discovery that the software was sending users' GMail login credentials to a GMail account hard coded in the software.
Atwood states, " I generally try to give people the benefit of the doubt, but it's difficult to imagine any scenario where this isn't a completely malicious violation of people's trust." Various other bloggers seem to agree.
Looking at G-Archiver's Web site, I see a warning for people not to use the version 1.0 release. They will be soon releasing a version "that corrects the flaw". (Flaw is rather mild term for the bad code.) G-Archiver is also apologising for the bad code:
We place much trust in software providers. Even more if their software is closed source.
But, we free/open source software supporters shouldn't get cocky. Most of us don't examine the source code of all our tools. (Yes, I am speaking for myself when I say this.) Still, the odds, are better that somebody will look at the open source code than the closed source. Sometimes, the source code examination occurs because a person wants to learn how the program works so he can build upon it. This seems to be what motivated Dustin Brooks, a programmer, to analyse G-Archiver with Reflector. Open source makes analysis easier and more likely to spot problems.
Finally, this incident is a horror story hinting that we can use testing methods and sample data that are less likely to cause problems if they slip into the final release. I recollect the unverified story of the "Dear Rich Bastard" test string that slipped into a real mass mailing to a bank's customers. Humour is great but some forms in testing might not have people laughing if they slip out.
Atwood states, " I generally try to give people the benefit of the doubt, but it's difficult to imagine any scenario where this isn't a completely malicious violation of people's trust." Various other bloggers seem to agree.
Looking at G-Archiver's Web site, I see a warning for people not to use the version 1.0 release. They will be soon releasing a version "that corrects the flaw". (Flaw is rather mild term for the bad code.) G-Archiver is also apologising for the bad code:
<< What happened was that a member of our development team had inserted coding used for testing G-Archiver in the debug version and forgot to delete it in the final release version.Although it is good G-Archiver is trying to resolve the problem, this incident raise various issues of trust. For example, what happened with quality control code checks before releasing the final version?
We sincerely apologize and assure you that this coding mishap was in no way intentional. >>
We place much trust in software providers. Even more if their software is closed source.
But, we free/open source software supporters shouldn't get cocky. Most of us don't examine the source code of all our tools. (Yes, I am speaking for myself when I say this.) Still, the odds, are better that somebody will look at the open source code than the closed source. Sometimes, the source code examination occurs because a person wants to learn how the program works so he can build upon it. This seems to be what motivated Dustin Brooks, a programmer, to analyse G-Archiver with Reflector. Open source makes analysis easier and more likely to spot problems.
Finally, this incident is a horror story hinting that we can use testing methods and sample data that are less likely to cause problems if they slip into the final release. I recollect the unverified story of the "Dear Rich Bastard" test string that slipped into a real mass mailing to a bank's customers. Humour is great but some forms in testing might not have people laughing if they slip out.
J.D. Abolins
- Mood:
calm
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
