Running "n stable" removed bin, lib, share, include directories from /usr/local
github.com
github.com
Except it can do also a lot of other bad things, and its too much to review. So in the end you trust the tree owner, and he blindly trust a zillion people.
I actually have zero good solution to this, but it'll be interesting when it is used for a large attack.
> I actually have zero good solution to this, but it'll be interesting when it is used for a large attack.
The only solution is intelligence and prudence on the part of the tree owners. Large software systems need to ultimately be in the hands of smart and wise people. Unfortunately, that wasn't the case here.
Wow, it must be awesome to be you.
Writing a package manager is actually really serious business. This package manager runs under user credentials and is expected to modify the filesystem. You can't sandbox around those requirements. No amount of whinging avoids that. This story is one of many examples why you can't take it trivially.
If you're afraid to point out incompetence - and where it is most dangerous - you won't know it when you see it. And it will bite you, hard.
But your previous post can be interpreted as an implication that the people themselves are neither smart, nor wise. A somewhat harsh attack. I re-read it with more emphasis on the "here" part of the sentence and it sounded a bit more as though you are saying that in this instance the people were not wise.
Pointing out incompetence is helpful, but it's also very useful to do so in a way that attempts to minimize the chance of an extremely negative interpretation.
Look at the pull request they merged in. Any line added to a script which starts with "rm -rf $VARIABLE" cannot be scrutinized enough.
The first commit was created at: 2012-09-30T10:25:44-07:00.
The pull request was accepted at: 2012-09-30T10:59:08-07:00.
34 minutes to accept on a Sunday morning. I suspect that wasn't 34 minutes of review. I suspect it was closer to 34 seconds of review.
Unacceptable.
Otherwise you're just throwing shit at a wall and seeing what sticks.
* These sort of packages should be run by people who are smart and wise * The fact that this happened suggests that this person is not smart and wise * It is unfortunate that he is running a project used by many people.
It's perfectly valid to criticise a person (or a person's fitness for a responsibility) based on their actions. An ad hominem is the opposite - it is criticising a persons actions or arguments based on who the person is (rather than the actions or arguments themselves).
Hint: he doesn't. He wouldn't accept a line of code starting with "rm -rf $VAR" in ~30 minutes on a Sunday morning.
I linked Ken's paper because it's related. His conclusion is that it doesn't matter how smart the users or maintainers are if somebody wants to install a clever bug. Smart and clever people can still choose not to accept contributions from people they don't know.
this means, the person may eventually do bad stuff, after earning your trust. OK. But if that's ever detected, at least you can trace back to him.
I don't know what this software is or anything about it aside from an estimating that it appears from comments here and on GH that it's serious as it deletes highly important directories and is possibly a widely used software package.
Whenever I install from source I run the installer as non root. It will error on higher than my user privilege deletes telling me I need to be root. In this case I believe I would have seen the attempt to remove important directories as an error alert.
If I have to be root, running as non root first has helped me as a purely investigative method to installations.
What if everyone adopted an 'rm -rfi' type command for any deletes. Then you are asked: "You are about to remove $dir are you sure you are okay with this? Y/N?
In this case, what I don't get is how it's now been three days and there hasn't been a rollback, pulling of the software, patch, notice, billboard, radio announcement, Emergency Broadcast Syatem alert, or otherwise some way to halt this problem dead in it's tracks right this very second.
It's almost like: README This software is 'use at your own risk', etc., etc., etc., see Hacker News for any potentially dangerous side-effects caused by installing this software.
I've actually run into a similar issue with another installer via a Rakefile that lacked uninstalling capabilities and a confusing method of determining the $PREFIX which resulted in me shredding my /usr/local/bin directory for a couple seconds before my ^C spamming stopped the process.
"Running and stable with no bin, lib, share, include directories in /usr/local".
Which didn't seem all that exciting to me, so I clicked just to see what all the excitement was with not having a /usr/local.
PS. "n" is a terrible name for a program - it's impossible to google.
The best advantage of nvm is that I can easily install global packages without being the root user, because it installs your Node.js files in a per-user ~/nvm/ folder (this is customizable to whatever folder you choose).
One of us is very confused (it easily could be me). I do not understand this statement at all. How is something global if its in a user directory?
| for d in bin lib share include; do
| rm -rf $N_PREFIX/$d
LGTM!(speaking as a FreeBSD user myself)
When I say considerable expense, I mean _very_ considerable expense. I know of no efficient implementation and only one practical implementation: TxF. TxF is not very fast either, it requires double the writes and, on top of that, is not easy to use. Microsoft is considering deprecating TxF due to the cost of continuing it's maintenance at the expense of other features [1]
I think a more reasonable model for what you want is filesystem snapshots. This is a feature that can be implemented with relatively high performance and without causing terribly large amounts of complication (needing to transact file descriptors, etc.)
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/hh80...
If you're thinking of switching there really isn't much difference between FreeBSD and Linux (at least if you're talking about a traditional Linux like Slackware); most of the admin commands work like Linux did up until 5 years ago, and obviously the UI is just KDE or whatever you like.