Live data from Hacker News

Awless: A Mighty CLI for AWS

github.com

71–80 of 120 posts

Re: Awless: A Mighty CLI for AWS

#71
post #67

I hate to pile on to the complaints about sending usage metrics to a server, but this is pretty funky. The metrics include the instance id, account id, a list of the commands run with timestamps, the region, a bunch of metadata about the number of VPCs, Subnets, IAM users and policies, etc. Which is kind of a lot to get, and definitely isn't anonymous. Why do they need to know how many VPCs, Subnets, IAM users, and I…

> compressing then encrypting is a no-no Perhaps it is just my own meager understanding of cryptography, but I didn't know of anything that would make this a bad idea. Can you explain why it is potentially a problem?

It's called a compression oracle attack https://en.wikipedia.org/wiki/Oracle_attack Basically, since you know about how big the plaintext is, and you can determine the size of the compressed payload by monitoring the traffic, so you can measure the amount of entropy in the plaintext.

An example is the CRIME attack. But that involves a chosen plaintext attack, so I'm not sure if something can be done with this method.

Re: Awless: A Mighty CLI for AWS

#72

I hate to pile on to the complaints about sending usage metrics to a server, but this is pretty funky. The metrics include the instance id, account id, a list of the commands run with timestamps, the region, a bunch of metadata about the number of VPCs, Subnets, IAM users and policies, etc. Which is kind of a lot to get, and definitely isn't anonymous. Why do they need to know how many VPCs, Subnets, IAM users, and I…

> This seems unnecessarily convoluted Sounds like a standard hybrid approach. https://en.m.wikipedia.org/wiki/Hybrid_cryptosystem

I get that part, but I don't see why they are encrypting it in the first place. It's being sent over SSL, so why bother?

Plus, hybrid cryptosystems exist because symmetric encryption is much faster than asymmetric, which matters for large amounts of data. But this is (even before compression) probably only about a kilobyte of data. Why have the extra complexity?

Re: Awless: A Mighty CLI for AWS

#73

I hate to pile on to the complaints about sending usage metrics to a server, but this is pretty funky. The metrics include the instance id, account id, a list of the commands run with timestamps, the region, a bunch of metadata about the number of VPCs, Subnets, IAM users and policies, etc. Which is kind of a lot to get, and definitely isn't anonymous. Why do they need to know how many VPCs, Subnets, IAM users, and I…

Thanks all for the feedback. We understood that the data collection could be done with much care. As a result, until we design a better way to send truly anonymous data, we have disabled the data collection (cf. https://github.com/wallix/awless/commit/f6389e75787390bd7797...). We will let you know when we have something better, keeping everything transparent, as we will always do.

Re: Awless: A Mighty CLI for AWS

#74
post #13

Earlier quoted context omitted.

Project creator here (but obviously not the OP). Yes, we do collect minimal anonymised statistics in the sole goal of improving awless. All the statistics code is here: https://github.com/wallix/awless/blob/master/stats/stats.go As the project is Apache licensed, you're free to modify it if you don't want this. Also, if you're conscious about privacy you should use application firewalls on your client side like Littl…

I appreciate that your folks released this OSS tool. However: Where I work, as long as the data collection code is in there, whether I can modify it or not, they won't allow it on our computers. I know this is not uncommon. Dismissing this concern by saying "other software does this" while awless falls into a different category (small CLI tool) is also problematic.

Thanks for the feedback. Until we provide a way to allow/disable data collection, we have disabled completely the data sending (see https://github.com/wallix/awless/commit/f6389e75787390bd7797...).

Re: Awless: A Mighty CLI for AWS

#75

Can someone explain why this is different/better than the official CLI application?

For me, the output is friendlier, which is great if you're just trying to make a quick query about the running instances or something. However, the whole thread above pointing out the data collection issues makes me far less likely to be moving away from the official cli + bash magic any time soon

I concur, I really don't see what value this brings over the official aws cli.

Re: Awless: A Mighty CLI for AWS

#76

Earlier quoted context omitted.

Seems like a non sequitur when discussing an open source project they have released.

The tool phones home. Their website doesn't have HTTPS. It's plausible that the tools phones home over an unencrypted channel (I didn't look, so I could be wrong). My overall impression is that they don't do security very well.

Anyone can release a project on Github; the project should be based on its merits, not how well an unrelated project is implemented. (and vice versa)

A quick search of the repo of https:// and then http:// shows that the stats collection is apparently https.

Re: Awless: A Mighty CLI for AWS

#77
post #45
post #40

Earlier quoted context omitted.

It seems your GOPATH is not set correctly. First freshly install Go independently. Verify it is installed correctly with "go env". Then do a "go get github.com/wallix/awless", "cd $GOPATH/src/github.com/wallix/awless" and "go install". Then in the same prompt do "awless"

I downloaded the release tarball, so why would I also use "go get" to get the source I just downloaded ?

"go get" will download dependencies. You can also cd to the source as run "go get ."

Re: Awless: A Mighty CLI for AWS

#78
post #21

Earlier quoted context omitted.

I like the look of this, so on the software side it's a thumbs up. However, the fact that the code is active at all will rule it out for some companies (firewall or not). Perhaps make it something users can turn off in a config file? Not everyone can code in go, especially if their job is as a sysadmin, which isn't unlikely given that this is an infrastructure tool, so it might not be as simple as forking and editing…

Or make it turn-off-able (?) with an environmental variable. There are a couple of ways to make the tool default to report and allowable in non-reportable environments. The key thing is to make what is happening transparent.

Must be an explicit "turn-on" option.
Post reply on HN