Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Remove obfuscation of the Loggly authtoken #32
Conversation
ivangonekrazy
commented
Aug 31, 2013
|
|
|
I dunno. People are pretty lazy... seems legit. |
Remove obfuscation of the Loggly authtoken
| @@ -95,7 +95,7 @@ | |||
|
|
|||
| _LOG_SOCKET = None | |||
| OUR_PROGNAME = "configure-syslog" | |||
| LOGGLY_AUTH_TOKEN = "MWVjNGU4ZTEtZmJiMi00N2U3LTkyOWItNzVhMWJmZjVmZmUw" | |||
| LOGGLY_AUTH_TOKEN = "1ec4e8e1-fbb2-47e7-929b-75a1bff5ffe0" | |||
vinhn
Sep 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.
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.
ivangonekrazy
Sep 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:
In configure-syslog.py:
@@ -95,7 +95,7 @@
_LOG_SOCKET = None
OUR_PROGNAME = "configure-syslog"
-LOGGLY_AUTH_TOKEN = "MWVjNGU4ZTEtZmJiMi00N2U3LTkyOWItNzVhMWJmZjVmZmUw"
+LOGGLY_AUTH_TOKEN = "1ec4e8e1-fbb2-47e7-929b-75a1bff5ffe0"
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
someone and still complains to us that it doesn't work.
—
Reply to this email directly or view it on GitHubhttps://github.com//pull/32/files#r6102777
.
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:
In configure-syslog.py:
@@ -95,7 +95,7 @@
_LOG_SOCKET = None
OUR_PROGNAME = "configure-syslog"
-LOGGLY_AUTH_TOKEN = "MWVjNGU4ZTEtZmJiMi00N2U3LTkyOWItNzVhMWJmZjVmZmUw"
+LOGGLY_AUTH_TOKEN = "1ec4e8e1-fbb2-47e7-929b-75a1bff5ffe0"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
someone and still complains to us that it doesn't work.—
Reply to this email directly or view it on GitHubhttps://github.com//pull/32/files#r6102777
.
hooverjbeaver
Sep 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:
In configure-syslog.py:
@@ -95,7 +95,7 @@
_LOG_SOCKET = None
OUR_PROGNAME = "configure-syslog"
-LOGGLY_AUTH_TOKEN = "MWVjNGU4ZTEtZmJiMi00N2U3LTkyOWItNzVhMWJmZjVmZmUw"
+LOGGLY_AUTH_TOKEN = "1ec4e8e1-fbb2-47e7-929b-75a1bff5ffe0"
This is a loggly owned token used to track install script usage and to report failures.
…
—
Reply to this email directly or view it on GitHub.
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,
In configure-syslog.py:
@@ -95,7 +95,7 @@
_LOG_SOCKET = None
OUR_PROGNAME = "configure-syslog"
-LOGGLY_AUTH_TOKEN = "MWVjNGU4ZTEtZmJiMi00N2U3LTkyOWItNzVhMWJmZjVmZmUw"
+LOGGLY_AUTH_TOKEN = "1ec4e8e1-fbb2-47e7-929b-75a1bff5ffe0"
This is a loggly owned token used to track install script usage and to report failures.
…
—
Reply to this email directly or view it on GitHub.
philip-loggly
Sep 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.
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.
vinhn
Sep 2, 2013
Yep, this is Vinh. Not sure why github is showing my recent comment as coming from "hooverjbeaver".
Yep, this is Vinh. Not sure why github is showing my recent comment as coming from "hooverjbeaver".
vinhn
Sep 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.
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.
