Unfortunately, many of these errors are _not_ subtle. Let's take Subversion as an example. It is filled with mishandling of user passwords, by storing them in plaintext in the svnserve "passwd" file or in the user's home directory. Given that it also provides password based SSH access, and stores those passwords in plaintext, it's clear that it was written by and is maintained by people who simply _do not care_ about security. Similarly, if you read the code, you will see numerous "case" statements that have no exception handling: they simply ignore cases that the programmer didn't think of.
This is widely spread, popular open source software, and it is _horrible_ from a security standpoint. Collabnet, the maintainers of it, simply have no excuse for this: they have been selling professional services for this software for years, and could have at least reviewed if not accepted outright the various patches for it. The primary patch would be to absolutely disable the password storage features at compilation time, by default, especially for SSH access. There was simply never an excuse to do this.
I urge anyone with an environment requiring security that doesn't have the resources to enforce only svn+ssh access to replace Subversion immediately with git, which is not only faster and more reliable but far more secure in its construction.
Ladies and gentleman, the article author is making a strawman argument. By transforming the "Linus' Law" into a badly written syllogism, and pointing out examples where _his invented syllogism_ fails, he's implying that closed source is _better_. Unfortunately, the vulnerabilities of closed source are often worse, by comparison and from experience.
> True but then NASA pretty much invented formal interface definition
I've simply no idea why you think this. While NASA has perfected them to a high art form, international manufacturers of railroad components have been doing work to extremely tight international and cross-compatible tolerances since the invention of railroads, and the British did it across their empire since they actually had one on which the sun never set, and it doubless came up repeatedly in the days of Rome when they ordered marble from other countries. The level of detail NASA uses may be relatively new, because of the highly stressful environment in which the machinery absolutely _must_ work. But even mil-spec standards far, far, far precede NASA, and much of their engineering is military based.
Now, the _Russians_ would doubtless have their own solution for this. "Comrade, unbolt the handrail first!" Their aerospace manufacture tends to be very simple, very robust, and admittedly more massive than American, partly because they couldn't afford the fancy versions, and partly because they've always built larger launch vehicles to work with. But that simplicity improves its reliability, even though it's less likely to spin off new industries. (Does anyone remember "space pens"? The Russians just used pencils.)
Mock ups can only be done with the parts you have in stock, with the last set of diagrams. Unfortunately, far too many components are being manufactured in far too many different states and being manufactured at the last moment, and not enough of these things get built for the kinks of that approach to get worked out.
The multi-state manufacture has to do with how the US Congress often winds up funding a big project in as many states as possible to get as many Congresspeople as possible to vote for it. And the result is this.
Please actually read the twitter and the letter from Southwest. They sold him _2_ tickets, to accomodate his size, but he switched to an earlier flight at the last minute. That means his new pair of seats were standby, not confirmed seating, so legally they offered him 2 seats _if they had the space_. They didn't have the space, so couldn't accomodate him. They shouldn't have seated him considering his size: at the last photo I saw of Silent Bob, he was pretty big and definitely needs 2 of those teeny little Southwest seats.
Oh, my. I've not personally administered Lotus Notes, but I've been involved in managing, and cleaning up after, a number of other small and large scale email systems, both genuint MTA's and varouls "groupware" systems. Large attachments present significant storage, backup, archival, and indexing problems with _all_ of them, in particular for this scenario for detached clients.
Many people do use their email as their institutional memory, but the difficulty of sorting through, indexing, and preserving such information is exacerbated by email's multiple uses. And the _processing_ for bulk messages remains a resource problem.
Word is not the problem: Sending bulky documents by email is. That's why you set up a shared or public document repository, one that can be granted or denied access by the user as needed, and send the URL's to _that_ for bulky documents.
Well, _that_ explains a lot. No one trained by using Horde as their primary mail server should be considered trained to run a competent, large scale mail service. It was a poorly integrated mass of difficult to install demoware 5 years ago, and I've seen and heard no evidence to indicate that it has improved.
Those three are the critical facilities. "Rollout policies" is, in my experience with Active Directories, demoware that breaks down very badly when actually attempted and needs endless fussing. And the "security policies", in practice, turn into an exercise in handwaving that leaves far too many people with unnecessary and inappropriate administrative privileges, because too much software doesn't work or install properly without those privileges.
While document handling, such as the replacement of Internet Explorer and Microsoft Word dependent operations, benefit massively from the switch to standards compliant software, I'm afraid that CAD isn't there yet. Try designing circuitry or hardware with open source software and you'll see what I mean. Tools like AutoCAD for your metal work and the circuit libraries for PowerPCB just aren't avaialble in the open source equivalents.
For Active Directory, though, that monster should have been replaced by Bind and Kerberos and LDAP years ago.
Make it "two-thirds". I don't want to see every change of which party wins an election likely to flush the laws of the previous party in power without working at it.
Yes, it's a configuration management issue that people keep breaking. The number of BSD "experts" who add debris to/etc/rc.local, and forget to do it on all the servers, remains scary. The number of power supplies, disk controllers, and network based initialization tools that are mishandled in boot procedures is even scarier, especially with increasing amounts of network and fiber channel storage.
That's not because it's insanely flexible. That's because Oracle installers stink. I've had to rewrite the Linux installer every single time I've used it over more than a decade. It's nearly as stupid as the Java installers on Linux: it does _not_ take a running Java instance to simply drop a lot of files into a directory and make a few symlinks. I'm afraid that now we could have the worst of both worlds.
Pointing a gun at someone else's head is a very different kind of argument. But aim an ordinary pistol from several hundred yards away, and I'll feel fairly comfortable calling you anything I please becuase "F=mA" can't begin to measure all the "F" factors involved over such a trajectory. Even for an expert shot, such a distance for a normal handgun is a ludicrous range for a human size target. Relativity might be fairly irrelevant, but air drag isn't.
Really! Good for her. Her experience does not match that of my female Army acquaintances, nor of the female cop nor firefighters. They had hard times getting promoted, and both having kids and the _risk_ of having kids hurt their careers noticeably. They had to be that much better than the male candidates to get promoted.
The solution isn't to deny the discrimination exists, and assume that social darwinism will settle it. I don't have an easy solution, just practices and policies to help: notice the differences when they happen, especially as a matter of course, and speak up. There are lots of small practices that help. Put the toilet seat down in shared toilets, make sure uniforms can fit people with hips or busts. (Include tailoring for uniforms: the number of uniforms that have to be adjusted out of an employee's own pocket is often very harsh on their budget, especially for low-wage work, and it improves comfort and safety.) When eating out, acknowledge that most women are smaller than most men and don't eat as much, and split the bill fairly. Speak up when a woman's work is ignored in favor of her less competent but more "like the bosses" employee. Don't assume that a father can stay late but a mother can't. If a business discussion happens in a men's room or with a vendor in an adult club (and don't pretend it doesn't happen with some businesses!), make sure the women are part of the decision in other venues and informed rather than just have a decision sprung on them by their peers. If a woman has the muscle to one-hand a server into place and pop the rack screws in with her other hand, open the box for her and get out of her way. (This happened once when my hand was injured: the woman who did the work for me was amazing.)
These are not problems I see every day, but goodness, I've certainly seen them in my career. I wonder if part of it is that I'm probably older than you are: I've gotten to see more of the changes happening. Women in technical careers were quite rare when I started, and their numbers have increased quite a lot. I'd like to think I had a small part in encouraging some of them, mostly by respecting their work.
Oh, dear, yes. I've had just this happen with Adaptec controllers: this sort of nonsense is extremely common in low-end "pizza-box" servers. I've cost such vendors money and gotten the compoany I worked for barred as a customer when shown the non-spec detritus that was inside them, read the vendor the riot act on their contract, and shipped back the whole pallet of servers for them to replace components with the parts we actually ordered. The idiot over in purchasing kept buying non-approved hardware from the lowest cost vendors, as his boss kept telling him was policy, and we kept having projects delayed because the equipment didn't work the way it was supposed to. I still remember the hand-wired piece of dog filth they tried to tell us was a Rocketport remote serial controller device: it was a study in how _not_ to hand a wiring diagram to a programmer and expect something to work.
Good for your mother and your wife. So, as the ones who I suggest suffer from the gender-bias, why don't you ask _them_ if their gender interfered in their careers? Especially your mother? You're probably right that "non one leveled her playing field". But ask her if anyone tilted it against her for being female, or for having a child she was raising herself.
Oh, my. I'd be fascinated to see that conservation.
Sadly, I've heard this sort of thing stated before. It's usually statged by whoever the local white boys and especially bey the very people who stab the career-eager women in the back at performance, code reviews, or just plain old social networking, and it goes with "Manifest Destiny", "Social Darwinism", and a lot of claims that such differences are the fault of the group _not_ in power. A whole stack of social and psychological research says that a great deal is "holding them back", sometimes among themselves, but often committed by the group in power.
Oh, dear. You're missing the point: the models aren't _complete_. While the basic principle of "warmer oceans = more evaporation" is known, how much warmer would it get for more solar input? It's a hard question: you've got numerous fascinating feedback loops, such as oceanic evaporation causing cloud cover and increasing the Earth's albedo, that are extraordinarily difficult to model "completely", you've got fascinating biological feedback loops (the ones that keep our atmosphere so high in oxygen and tend to restrict fresh water flows by creating dams), and dozens of other subtle effects.
The idea that the models are "complete" is like saying that physics was "complete" when Isaac Newton discovered F=MA. There's a lot that goes on in the details.
We've seen this before, with Usenet, BBS's, MUD's, and Email. The advertisers, and the trolls, find it easy to spew their material across many thousands of targets, and get enough money or gratification from doing so that it funds their efforts. It doesn't even have to make money: they just have to believe that it _can_ make money, and the professionals will simply continue.
Whatever would make anyone think that "User Generated Content" forums would be any different?
I believe that you have it backwards. Why _wouldn't_ they. Such control gains profound benefits for lawmakers.
* Control over copyrighted, marketable materials, which aids corporate contributors and large, campaign contributing parts of the entertainment industry. * Control over network traffic: shutting down casual, incessant downloaders lets the ISP's and related industries such as telco's manage their costs far more effectively. This is actually understandable: the cost of providing basic connectivity, nationwide, is hampered by the cost of the "last mile" to remote locations. If they need fiber optic to handle all the Bittorrent traffic, it's going to take a lot longer and cost far more, and basic services for even the poor will cost far more. * Control over network content: this is desired by governments, not only for criminal traffic, but political traffic. Go look at the Great Firewall of China and Google's adventures there for proof of such, and examine the excuses of "porn" used there, and "child porn" in the US and the UK, used to harass anonymous services and dropboxes for files. * Control over information. This is related to to the others, but constitutes its own issue, because the control of _opposition_ traffic leads to better acceptance of your own claims and your own policies. Again, see the Great Firewall of China, and particularly its censure of any "Free Tibet" postings.
No, it's not. I'm not sure how much more clearly I can explain it. But a fast Google search on "ocean heating", which I cited as an example of incomplete understanding of the effects of the sun's radiative effects, yields:
And the list of articles citing new ideas and understanding of such a limited aspect of solar radiation as ocean heating go on an don. You just have to actually look at the literature to realize that the models are not _complete_. That was my point. It's a _big_ system, with a lot of complex details. ranging from incompletely understood solar flare and sunspot effects to incomplete models of oceanic weather and polar ice cap effects.
Oh, my. I did a bit of work, last year, on an ancient project shared project that turned out to still be in use. (Small project, very stable code, old client.) There was a bug in handling mixed case filenames, and another one for handling files with spaces or punctuation in them: I'd never noticed, because when I wrote it it was all UNIX and no one _did_ that. But now some of the files were being generated by Samba clients on Windows boxes, who wrote files like "March 3rd Data.txt". So I fixed the bug, which I'd never noticed, in 12 year old code. It could have become an interesting security issue, too: opening unexpected files as root due to file name mis-parsing.
It happens, and as code is exposed to new uses, it's not unusual. In a large, open source project with "many eyes" on it, I'd expect it to have been noticed a lot faster. (I was careless with filename handling: I've learned better since then, and plenty of experienced programmers would have noticed it themselves if it were more broadly used.) And my code is "trusted", from a "respected vendor". It's the sort of reason that I prefer to start with a working, well-known project and enhance it, rather than writing from scratch: usually someone has already fixed these sorts of bugs. And it's why I like to see the source on an open project, rather than merely submit a bug report to a vendor. I can see if they did that style of bug a *lot*.
In fact, I just had a long chat with a developer about his "case" statements: he refused to acknowledge that they should have "default" cases, in case he had missed something, for the program to error out or report the issue. So we went through his latest program and found 3 such instances where unreported errors would occur. He said "oh, I'll add those cases", and refused to acknowledge the point that you need to handle unexpected cases by actually _noticing_ them. I'm afraid he may have to be let go, and his code seriously reviewed top to bottom, because of this sort of thing.
Slashdot Mirror
Unfortunately, many of these errors are _not_ subtle. Let's take Subversion as an example. It is filled with mishandling of user passwords, by storing them in plaintext in the svnserve "passwd" file or in the user's home directory. Given that it also provides password based SSH access, and stores those passwords in plaintext, it's clear that it was written by and is maintained by people who simply _do not care_ about security. Similarly, if you read the code, you will see numerous "case" statements that have no exception handling: they simply ignore cases that the programmer didn't think of.
This is widely spread, popular open source software, and it is _horrible_ from a security standpoint. Collabnet, the maintainers of it, simply have no excuse for this: they have been selling professional services for this software for years, and could have at least reviewed if not accepted outright the various patches for it. The primary patch would be to absolutely disable the password storage features at compilation time, by default, especially for SSH access. There was simply never an excuse to do this.
I urge anyone with an environment requiring security that doesn't have the resources to enforce only svn+ssh access to replace Subversion immediately with git, which is not only faster and more reliable but far more secure in its construction.
Ladies and gentleman, the article author is making a strawman argument. By transforming the "Linus' Law" into a badly written syllogism, and pointing out examples where _his invented syllogism_ fails, he's implying that closed source is _better_. Unfortunately, the vulnerabilities of closed source are often worse, by comparison and from experience.
> True but then NASA pretty much invented formal interface definition
I've simply no idea why you think this. While NASA has perfected them to a high art form, international manufacturers of railroad components have been doing work to extremely tight international and cross-compatible tolerances since the invention of railroads, and the British did it across their empire since they actually had one on which the sun never set, and it doubless came up repeatedly in the days of Rome when they ordered marble from other countries. The level of detail NASA uses may be relatively new, because of the highly stressful environment in which the machinery absolutely _must_ work. But even mil-spec standards far, far, far precede NASA, and much of their engineering is military based.
Now, the _Russians_ would doubtless have their own solution for this. "Comrade, unbolt the handrail first!" Their aerospace manufacture tends to be very simple, very robust, and admittedly more massive than American, partly because they couldn't afford the fancy versions, and partly because they've always built larger launch vehicles to work with. But that simplicity improves its reliability, even though it's less likely to spin off new industries. (Does anyone remember "space pens"? The Russians just used pencils.)
Mock ups can only be done with the parts you have in stock, with the last set of diagrams. Unfortunately, far too many components are being manufactured in far too many different states and being manufactured at the last moment, and not enough of these things get built for the kinks of that approach to get worked out.
The multi-state manufacture has to do with how the US Congress often winds up funding a big project in as many states as possible to get as many Congresspeople as possible to vote for it. And the result is this.
Please actually read the twitter and the letter from Southwest. They sold him _2_ tickets, to accomodate his size, but he switched to an earlier flight at the last minute. That means his new pair of seats were standby, not confirmed seating, so legally they offered him 2 seats _if they had the space_. They didn't have the space, so couldn't accomodate him. They shouldn't have seated him considering his size: at the last photo I saw of Silent Bob, he was pretty big and definitely needs 2 of those teeny little Southwest seats.
Oh, my. I've not personally administered Lotus Notes, but I've been involved in managing, and cleaning up after, a number of other small and large scale email systems, both genuint MTA's and varouls "groupware" systems. Large attachments present significant storage, backup, archival, and indexing problems with _all_ of them, in particular for this scenario for detached clients.
Many people do use their email as their institutional memory, but the difficulty of sorting through, indexing, and preserving such information is exacerbated by email's multiple uses. And the _processing_ for bulk messages remains a resource problem.
Word is not the problem: Sending bulky documents by email is. That's why you set up a shared or public document repository, one that can be granted or denied access by the user as needed, and send the URL's to _that_ for bulky documents.
Well, _that_ explains a lot. No one trained by using Horde as their primary mail server should be considered trained to run a competent, large scale mail service. It was a poorly integrated mass of difficult to install demoware 5 years ago, and I've seen and heard no evidence to indicate that it has improved.
Those three are the critical facilities. "Rollout policies" is, in my experience with Active Directories, demoware that breaks down very badly when actually attempted and needs endless fussing. And the "security policies", in practice, turn into an exercise in handwaving that leaves far too many people with unnecessary and inappropriate administrative privileges, because too much software doesn't work or install properly without those privileges.
While document handling, such as the replacement of Internet Explorer and Microsoft Word dependent operations, benefit massively from the switch to standards compliant software, I'm afraid that CAD isn't there yet. Try designing circuitry or hardware with open source software and you'll see what I mean. Tools like AutoCAD for your metal work and the circuit libraries for PowerPCB just aren't avaialble in the open source equivalents.
For Active Directory, though, that monster should have been replaced by Bind and Kerberos and LDAP years ago.
Make it "two-thirds". I don't want to see every change of which party wins an election likely to flush the laws of the previous party in power without working at it.
Yes, it's a configuration management issue that people keep breaking. The number of BSD "experts" who add debris to /etc/rc.local, and forget to do it on all the servers, remains scary. The number of power supplies, disk controllers, and network based initialization tools that are mishandled in boot procedures is even scarier, especially with increasing amounts of network and fiber channel storage.
That's not because it's insanely flexible. That's because Oracle installers stink. I've had to rewrite the Linux installer every single time I've used it over more than a decade. It's nearly as stupid as the Java installers on Linux: it does _not_ take a running Java instance to simply drop a lot of files into a directory and make a few symlinks. I'm afraid that now we could have the worst of both worlds.
Pointing a gun at someone else's head is a very different kind of argument. But aim an ordinary pistol from several hundred yards away, and I'll feel fairly comfortable calling you anything I please becuase "F=mA" can't begin to measure all the "F" factors involved over such a trajectory. Even for an expert shot, such a distance for a normal handgun is a ludicrous range for a human size target. Relativity might be fairly irrelevant, but air drag isn't.
Really! Good for her. Her experience does not match that of my female Army acquaintances, nor of the female cop nor firefighters. They had hard times getting promoted, and both having kids and the _risk_ of having kids hurt their careers noticeably. They had to be that much better than the male candidates to get promoted.
The solution isn't to deny the discrimination exists, and assume that social darwinism will settle it. I don't have an easy solution, just practices and policies to help: notice the differences when they happen, especially as a matter of course, and speak up. There are lots of small practices that help. Put the toilet seat down in shared toilets, make sure uniforms can fit people with hips or busts. (Include tailoring for uniforms: the number of uniforms that have to be adjusted out of an employee's own pocket is often very harsh on their budget, especially for low-wage work, and it improves comfort and safety.) When eating out, acknowledge that most women are smaller than most men and don't eat as much, and split the bill fairly. Speak up when a woman's work is ignored in favor of her less competent but more "like the bosses" employee. Don't assume that a father can stay late but a mother can't. If a business discussion happens in a men's room or with a vendor in an adult club (and don't pretend it doesn't happen with some businesses!), make sure the women are part of the decision in other venues and informed rather than just have a decision sprung on them by their peers. If a woman has the muscle to one-hand a server into place and pop the rack screws in with her other hand, open the box for her and get out of her way. (This happened once when my hand was injured: the woman who did the work for me was amazing.)
These are not problems I see every day, but goodness, I've certainly seen them in my career. I wonder if part of it is that I'm probably older than you are: I've gotten to see more of the changes happening. Women in technical careers were quite rare when I started, and their numbers have increased quite a lot. I'd like to think I had a small part in encouraging some of them, mostly by respecting their work.
"Outside the US"? You don't think it happens elsewhere? What do you think informing on your neighbors is all about?
Oh, dear, yes. I've had just this happen with Adaptec controllers: this sort of nonsense is extremely common in low-end "pizza-box" servers. I've cost such vendors money and gotten the compoany I worked for barred as a customer when shown the non-spec detritus that was inside them, read the vendor the riot act on their contract, and shipped back the whole pallet of servers for them to replace components with the parts we actually ordered. The idiot over in purchasing kept buying non-approved hardware from the lowest cost vendors, as his boss kept telling him was policy, and we kept having projects delayed because the equipment didn't work the way it was supposed to. I still remember the hand-wired piece of dog filth they tried to tell us was a Rocketport remote serial controller device: it was a study in how _not_ to hand a wiring diagram to a programmer and expect something to work.
Good for your mother and your wife. So, as the ones who I suggest suffer from the gender-bias, why don't you ask _them_ if their gender interfered in their careers? Especially your mother? You're probably right that "non one leveled her playing field". But ask her if anyone tilted it against her for being female, or for having a child she was raising herself.
Oh, my. I'd be fascinated to see that conservation.
Sadly, I've heard this sort of thing stated before. It's usually statged by whoever the local white boys and especially bey the very people who stab the career-eager women in the back at performance, code reviews, or just plain old social networking, and it goes with "Manifest Destiny", "Social Darwinism", and a lot of claims that such differences are the fault of the group _not_ in power. A whole stack of social and psychological research says that a great deal is "holding them back", sometimes among themselves, but often committed by the group in power.
Oh, dear. You're missing the point: the models aren't _complete_. While the basic principle of "warmer oceans = more evaporation" is known, how much warmer would it get for more solar input? It's a hard question: you've got numerous fascinating feedback loops, such as oceanic evaporation causing cloud cover and increasing the Earth's albedo, that are extraordinarily difficult to model "completely", you've got fascinating biological feedback loops (the ones that keep our atmosphere so high in oxygen and tend to restrict fresh water flows by creating dams), and dozens of other subtle effects.
The idea that the models are "complete" is like saying that physics was "complete" when Isaac Newton discovered F=MA. There's a lot that goes on in the details.
We've seen this before, with Usenet, BBS's, MUD's, and Email. The advertisers, and the trolls, find it easy to spew their material across many thousands of targets, and get enough money or gratification from doing so that it funds their efforts. It doesn't even have to make money: they just have to believe that it _can_ make money, and the professionals will simply continue.
Whatever would make anyone think that "User Generated Content" forums would be any different?
I still do! Mind you, I make prototypes: I _expect_ the foreign factories to find ways to cut costs and streamline the manufacture.
I believe that you have it backwards. Why _wouldn't_ they. Such control gains profound benefits for lawmakers.
* Control over copyrighted, marketable materials, which aids corporate contributors and large, campaign contributing parts of the entertainment industry.
* Control over network traffic: shutting down casual, incessant downloaders lets the ISP's and related industries such as telco's manage their costs far more effectively. This is actually understandable: the cost of providing basic connectivity, nationwide, is hampered by the cost of the "last mile" to remote locations. If they need fiber optic to handle all the Bittorrent traffic, it's going to take a lot longer and cost far more, and basic services for even the poor will cost far more.
* Control over network content: this is desired by governments, not only for criminal traffic, but political traffic. Go look at the Great Firewall of China and Google's adventures there for proof of such, and examine the excuses of "porn" used there, and "child porn" in the US and the UK, used to harass anonymous services and dropboxes for files.
* Control over information. This is related to to the others, but constitutes its own issue, because the control of _opposition_ traffic leads to better acceptance of your own claims and your own policies. Again, see the Great Firewall of China, and particularly its censure of any "Free Tibet" postings.
No, it's not. I'm not sure how much more clearly I can explain it. But a fast Google search on "ocean heating", which I cited as an example of incomplete understanding of the effects of the sun's radiative effects, yields:
http://www.agu.org/pubs/crossref/2009/2008JC004825.shtml
And for recent Nature article references:
http://news.softpedia.com/news/Ocean-Heating-Causes-More-Severe-Storms-100912.shtml
And the list of articles citing new ideas and understanding of such a limited aspect of solar radiation as ocean heating go on an don. You just have to actually look at the literature to realize that the models are not _complete_. That was my point. It's a _big_ system, with a lot of complex details. ranging from incompletely understood solar flare and sunspot effects to incomplete models of oceanic weather and polar ice cap effects.
Oh, my. I did a bit of work, last year, on an ancient project shared project that turned out to still be in use. (Small project, very stable code, old client.) There was a bug in handling mixed case filenames, and another one for handling files with spaces or punctuation in them: I'd never noticed, because when I wrote it it was all UNIX and no one _did_ that. But now some of the files were being generated by Samba clients on Windows boxes, who wrote files like "March 3rd Data.txt". So I fixed the bug, which I'd never noticed, in 12 year old code. It could have become an interesting security issue, too: opening unexpected files as root due to file name mis-parsing.
It happens, and as code is exposed to new uses, it's not unusual. In a large, open source project with "many eyes" on it, I'd expect it to have been noticed a lot faster. (I was careless with filename handling: I've learned better since then, and plenty of experienced programmers would have noticed it themselves if it were more broadly used.) And my code is "trusted", from a "respected vendor". It's the sort of reason that I prefer to start with a working, well-known project and enhance it, rather than writing from scratch: usually someone has already fixed these sorts of bugs. And it's why I like to see the source on an open project, rather than merely submit a bug report to a vendor. I can see if they did that style of bug a *lot*.
In fact, I just had a long chat with a developer about his "case" statements: he refused to acknowledge that they should have "default" cases, in case he had missed something, for the program to error out or report the issue. So we went through his latest program and found 3 such instances where unreported errors would occur. He said "oh, I'll add those cases", and refused to acknowledge the point that you need to handle unexpected cases by actually _noticing_ them. I'm afraid he may have to be let go, and his code seriously reviewed top to bottom, because of this sort of thing.