Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove obfuscation of the Loggly authtoken #32
Remove obfuscation of the Loggly authtoken #32
Changes from all commits
6c7e3dcFile filter...
Jump to…
vinhnSep 1, 2013
Just curious...is this a Loggly-owned auth token? If so, is it really required to have this special auth token in order to send logs to Loggly? I don't believe this is true.
Or is it a user-owned token? If so, shouldn't it be passed into the script as a command line parameter? We should not expect an end user to modify the script to make it work. That just calls for trouble, like if they messed up something and still complains to us that it doesn't work.
ivangonekrazySep 1, 2013
Author
Contributor
This is a loggly owned token used to track install script usage and to
report failures.
On Sep 1, 2013 9:38 AM, "vinhn" notifications@github.com wrote:
hooverjbeaverSep 2, 2013
Sounds like a cool idea. But in reality, if I as an end user knew that the script was tracking me, I would NEVER use it!
So far, I was under the impression that the purpose of this script is to configure syslog on a host machine for a customer. That's it, nothing more. Exactly what it says it does in the file's header comments. And this should be very simple to do.
I finally became curious to see what this script was all about, especially with the various on-going commits on this. So as a developer, when I looked at the length of code required to do this, I became highly skeptical. And Ivan just confirmed this. I strongly feel that the script is doing more than necessary, and we should revisit this ASAP before going live with it.
First, this is a red flag for privacy issues. Second, we must be absolutely sure the additional code for tracking/debugging doesn't have bugs that would cause the core functionality to fail, which is to simply configure syslog given a end user's auth token.
If needed, separate out this "debugging" feature into a separate script. If users have issues with the original script, we can have them run the second script so that we can help debug. We'd notify them that the second script is collecting info, so they'd be well aware of what it is doing before they run it.
The alternate option is to clearly document in the current script script header what it is doing, and clearly indicate that by running the script, the end user agrees to what it is doing. And most importantly, that they don't hold Loggly responsible for any issues if this script causes problems for the user. At the very least, we definitely need this agreement documented somewhere, whether in the same script or in a separate README file that should be downloaded with the script.
On Sep 1, 2013, at 11:50 AM,♥ Ivan Tam ♥ notifications@github.com wrote:
philip-logglySep 2, 2013
Contributor
I presume this is Vinh.
I was also surprised that the script was logging these details, and mentioned it to Jim a few days back. My initial request was to pull this functionality (though I had different reasons for wanting it removed). Jim feels this information is really valuable to us, and was worth it. I'll drop him an e-mail, and mention your concerns too.
vinhnSep 2, 2013
Yep, this is Vinh. Not sure why github is showing my recent comment as coming from "hooverjbeaver".
vinhnSep 2, 2013
Thanks, Philip, for looking into this:) I do agree we should help users. But we should be especially careful when it involves the user running a script/tool we provide which automatically modifies their system. There needs to be an agreement of expectations here.
It's very different than us verbally telling users over the phone what to modify on their system because in that case, they have full control over the decisions and are directly making the changes, not us.