101–110 of 280 posts
Earlier quoted context omitted.
The programmer committed a cardinal sin to be sure. But, so did everyone on the code review that let it slide.
Do we know if they do code review? Are pull requests blindly accepted?
Wow, an awful bug -- and brings back memories of a very similar bug that we had back in the late 1990s at Sun. Operating system patches on Solaris were added with a program called patchadd(1M), which, as it turns out, was actually a horrific shell script, and had a line that did this: rm -rf $1/$2 Under certain kinds of bad input, the function that had this line would be called without any arguments -- and this (like…
For those of you worried about important files, chattr +i is a useful defence. No easy way of applying this automatically. Long ago I had a kernel hack that would kill any process that attempted to delete a canary file. Worked OK but no chance of it ever going mainstream.
Part of the scripts installed a bunch of files into what was supposed to be a fakeroot, however I did not have bash's 'set -u' configured and an incorrectly spelled path variable was null, meaning something like: "${FAKEROOT}/etc" was translated into "/etc". Before I realized it, it had clobbered most of my /etc directory.
When the build failed, I was puzzled. I only noticed there was an issue when I opened a new shell and instead of seeing "myuser@host ~]#" I got "noname@unknown ~]#". Uh oh...
Needless to say I know do my development of those scripts from within a VM.
Earlier quoted context omitted.
I think Valve should be sued over this, and lose. Sure, there will be clauses in their EULA stating that they aren't liable, but morally, those clauses should not be valid in any licensing agreement. Their commercial software caused damage to people, and they should pay through the nose for it.
There are several problems with your ideas. The most important one is that programmers only call themselves engineers until it comes time to take legal responsibility for their work; then suddenly they're artists creating works for hire. Programmers have worked very hard through the years to create the current liability-free environment; people die because of health care programming bugs, pilots crash because of avio…
With a bunch of random people just making a bridge that collapses, then unless it's on their own property, they know that other people will use it and expect it to not collapse and so liability is justified there. (If it's on their own property, then morally there shouldn't be any liability unless they invited someone to use it, but legally is another matter.)
If this was ANY product other than software, there wouldn't even be a question of Valve being liable, and that's just disgusting to me.
Here's the offending shell script code: # figure out the absolute path to the script being run a bit # non-obvious, the ${0%/*} pulls the path out of $0, cd's into the # specified directory, then uses $PWD to figure out where that # directory lives - and all this in a subshell, so we don't affect # $PWD STEAMROOT="$(cd "${0%/*}" && echo $PWD)" [...] # Scary! rm -rf "$STEAMROOT/"* The programmer knew the danger and di…
Would this have stopped things getting deleted? if [ -z "$STEAMROOT" ] # something isnt right...
No. "${STEAMROOT}" will contain something when the "rm" command runs. It just might not be what's expected.
> STEAMROOT="$(cd "${0%/*}" && echo $PWD)"
Earlier quoted context omitted.
I think Valve should be sued over this, and lose. Sure, there will be clauses in their EULA stating that they aren't liable, but morally, those clauses should not be valid in any licensing agreement. Their commercial software caused damage to people, and they should pay through the nose for it.
There are several problems with your ideas. The most important one is that programmers only call themselves engineers until it comes time to take legal responsibility for their work; then suddenly they're artists creating works for hire. Programmers have worked very hard through the years to create the current liability-free environment; people die because of health care programming bugs, pilots crash because of avio…
Earlier quoted context omitted.
Would this have stopped things getting deleted? if [ -z "$STEAMROOT" ] # something isnt right...
Not if the previous line was: STEAMROOT=$SOME_OTHER_UNSET_VARIABLE/ "rm -r " is a code smell, as much as "cc -o myprog .c" is. You should always know what files make up your system, and track them in a MANIFEST file. There's rarely a good reason to use wildcards when a program is dealing with its own files. xargs rm -df -- fixes this.
This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data withou…
Isn't this the basic idea behind the sandbox in OS X? I think OS X (and mobile app development in general) shows both that this is great in theory and a net improvement over not having it, but that there are some common pitfalls to address. First, there are a handful of apps where this model doesn't work so well -- e.g. text editors, FTP clients, etc. So you're inconveniencing quite a few legit apps which need broade…
As far as Apple's implementation goes, sandboxes are for kids, not adults that need to get work done.
Earlier quoted context omitted.
I think Valve should be sued over this, and lose. Sure, there will be clauses in their EULA stating that they aren't liable, but morally, those clauses should not be valid in any licensing agreement. Their commercial software caused damage to people, and they should pay through the nose for it.
There are several problems with your ideas. The most important one is that programmers only call themselves engineers until it comes time to take legal responsibility for their work; then suddenly they're artists creating works for hire. Programmers have worked very hard through the years to create the current liability-free environment; people die because of health care programming bugs, pilots crash because of avio…
I think the problem is EULAs. Foss Eula's are pretty straight forward - no warranty: use at your own risk. Corporate software takes the same approach, and I think that's cowardly and underhanded because they are a profit driven entity which, if not incentivized properly, would literally rob you blind.
Corporations are profit driven. No profit, no corporation.
If your going to profit off of selling me something which then burns my house down because it was cheaper for the vendor to not build to standards (best practices), shouldn't they be held liable?
If someone made a lamp for themselves that wasn't up to standard, and then left it out on the curb for garbage pickup when you came along and took it home, plugged it in, and burned down your house, who's fault is that? They didn't sell it to you. There was no purchase.