The unfortunate problem with this is that while piping directly into bash can be exploited, it remains as one of the easiest ways to install programs.
Taking RVM for example. Their instructions are to run this: `curl -sSL https://get.rvm.io | bash -s stable`. The script that is executed is 887 lines long. The installation is "complex", requiring a lot of different stages. Now, the solution to this is "Use a package manager". Sure, that works in a lot of cases. However, when you have something like RVM which is used across several major operating systems, and hundreds of different flavours, each with their own quirks and package managers it suddenly gets difficult to manage each of these.
The problem we face is, how can we make it easy to install something, while still being safe and maintainable?
Breaking this down further, there are 2 issues to solve. The first is "How do we ensure what we download is what the maintainer says that we should download?". I.e. How do we make sure there are no malicious injections. That one is simple. Use SSL.
The second issue is, "I want to install this thing but I don't know if I can trust the installer". Are you crazy!? This isn't an issue. If you don't trust the installer, you sure as hell can't trust the product. If you don't trust either of them, then you automatically don't trust the other and shouldn't be installing it.
The result is that, yes, people can maliciously serve up code when you pipe the output of curl through bash without you realising. However, this is no different than blindly trusting and installing a script.
> If you don't trust the installer, you sure as hell can't trust the product
I can't think of ten pieces of software with excellent installers.
Software distributors generally pay very little attention to the installer. That is because installers are written by people who want to try and make it easy to install something, and don't really care about anything else. If they can get you to install something, helping you remove it isn't their problem.
If they can get you to install something, protecting you from really unlikely things like someone hacking their CDN and delivering malware is a high quality problem: Either they have enough users so that they will be forgiven, or they won't have enough users and the project is abandoned anyway.
I don't trust installers.
I don't trust installers to document what they're doing, or tell me where files go, because they don't.
I don't trust installers to deliver a secure transparent experience, because they don't.
I don't trust installers to consider conflicts, like what else do I have installed because they don't.
I don't trust installers to create security boundaries, protecting me and my files from bugs in the software, because they don't.
For things that are open source, I try to use the software in-tree without installing it. For other things, I evaluate using a virtual machine. Seriously, I don't trust installers because all of you are bad at them.
> The problem we face is, how can we make it easy to install something, while still being safe and maintainable?
Google, Apple, Microsoft, et al have recommended publishing platforms (aka "app stores") that are designed to specifically solve this problem.
For Debian and the derived, we can approach a Debian Maintainer and ask them for help getting it into Debian. For other distributions, we can take similar steps.
If we insist on publishing things ourselves, we can make our software really portable: Let it live in any directory, and not touch any files. Make it easy for the user to verify this.
If we can't do that, we can document the details: Explain all the files we touch and why, and recommend users create separate user accounts (or containers/virtual machines) to really protect themselves. Try to get people used to this level of care because having a positive experience with good software with excellent documentation[1] will give you pause when faced with anything else.
Honestly, the number of programs that want to run as root or as my user account is terrifying, and the amount of work necessary to sandbox unknown apps really makes me not want to bother. I know most people don't worry about this, so purely from a "hurr hurr move fast" point of view, this isn't anything anyone needs to worry about: `curl | bash` is good enough, and will likely be good enough for a long time.
I don't think the installer problem will ever get better, though the portable software idea would make things better as the application wouldn't be scattered all over the place.
Its why I stick everything in a container now, as then I don't care what software does to its filesystem, and I only push what directories I want it to have into it. This also lets me run multiple versions of software when the software does not normally support that.
> However, when you have something like RVM which is used across several major operating systems, and hundreds of different flavours, each with their own quirks and package managers it suddenly gets difficult to manage each of these.
I'm not sure that really changes with an install script. You've got several major operating systems, hundreds of flavours with all kinds of quirks. And you don't even know what shell you're really running on. How do you know your install script will work in any reasonable way?
For example, all reasonable package managers will make sure existing files aren't overwritten, existing configs are not modified, all ownership/modes are reasonable by default. Sure, you can override that in post-install script, but it will stand out that you're doing something non-standard, because there's a post-install script.
> how can we make it easy to install something, while still being safe and maintainable?
> Are you crazy!? This isn't an issue. If you don't trust the installer, you sure as hell can't trust the product.
I do not trust either the installer or the app. If I have a simple package to deploy, I can: 1) check that there are no post/pre-install scripts 2) install the files on the system 3) contain/sandbox them using selinux / grsec / apparmor / chroot / separate user. I cannot easily do the same thing with an installer script, which by definition wants to merge foreign files into my running system.
Even better, it's in the interest of app creator to care about this and provide sandboxing by default, even if they trust the app.
When light interferes with itself it creates a "pattern". When the light beams are out of phase, the interference pattern is different. The gravitational waves basically minutely increase the distance that one of the beams travels and causes it to go out of phase with the other, thus changing the interference pattern.
Convenience is great. It's part of why I use 1Password. There is a limit though to convenience. It's not convenient for me if my data is out there. If you aren't willing to automatically push this to users, at least give the users the option. You can outline the pros and cons of each choice.
Also, it's been 3 years since OPVault first came out. How careful can you be?
Well, we've been slower than we (and you) would have liked getting OPVault to different platforms. For sophisticated users, handling the switch should be fine. But we need to make the transition rock solid everyone.
If even just 1% of our customers end up synching a .agilekeychain on some devices and an .opvault on others, they will get data that slowly drifts apart. And we've grown kind of popular over the years. 1% of users is a lot of people.
Our transition from OS X keychain to Agile Keychain back in 2009 was an rough experience for customer support. And back then we were Mac only.
I'm not saying that the wait hasn't been longer than it should be. But our plans for a swift transition didn't work out as we would have liked.
That's absolutely not the case. My issue is that AgileBits need to push the new format over the old one. The old one is still the default. Most users, my self included, have no idea that the old format is insecure, or that a new format exists.
The article has very limited technical details to avoid confusing people who don't know what they are doing, but the reality is that if they are reading my blog, or are reading HN then they have the technical details to understand something much more complex than what I wrote.
I clearly state at the bottom of the article that the software still keeps your passwords secure and that I will continue to use 1Password. AgileBits still have my full support, I just want them to inform the users the downsides of using agile keychain, and to use OPVault by default.
The old format is not 'Default' but Dropbox Sync users. I'm using iCloud Sync and I'm not affect by these problem.
My point being why you are talking about these issues in YCNews but their forum. Most of us just read 140 characters but an article, This is how information transfer today. I'm not finding excuses for AgileBits. The problem you mention need to be fix. But it's important where you talk about it. If there's a news said your product 'Leaking your data' in YCNews, and everybody will know that '1Password is leaking data', but 'The author of this article is still using 1Password'.
> My point being why you are talking about these issues in YCNews but their forum.
This is the flip side of "software as a consumer product" that sells for $60. If it's open source, the author could have discussed it on the bugtracker, posted to the mailing list / forum, or even just recompiled to use the old format by default, and you would have been justified in asking them to do so.
A commercial product that sells for $60? That's like a toaster oven or something. If my toaster oven is malfunctioning, I'm not going to go complain on their forum, I'm going to air my grievances in public and demand a new toaster (in this case, an updated version of 1Password).
That's the hope with the noise. Agile keychain is old and shouldn't be used. I just want them to use OPVault by default and tell users the risks they take with Agile keychain.
Perhaps I wasn't clear in the article. This is an entirely optional feature. If you don't want to store 1Password in Dropbox you don't have to, and you certainly don't need to have it in your public folder (I'm not sure those are even a thing any more?). The concern is that if someone has access to your keychain in any way at all, it is open to this. Perhaps you left your machine unlocked for a few minutes? Set up a read only network share for friends to stream movies from you? etc.
I'm not sure I'm following you, but in short I'm not trying to attack this piece of software. All I'm saying is that I have a particular point of view and it appears based on the description that this tool isn't the one for me.
I'm not surprised I butchered it. I'm not a writer by any means. If you look at the few other things I've written, the writing there is just as terrible. Practice makes perfect though I guess.
I guess what I meant was that you are emphasizing that the old-style format is what is the problem here, and that it hasn't been the default for three years now, but the headline makes the scope sound much worse. So saying 1Password as a whole suffers from this flaw is pretty misleading. I agree it's an issue that you weren't warned about the need to migrate to the new format.
No, the problem is that they have a new format but the OLD one is the default. It's incredibly difficult to use OPVault as your keychain format if you aren't on Windows. Even if you are on Windows, you still need to change it every time.
