permit js files #50
permit js files #50
Conversation
|
I'm nervous about allowing this, but I'll let others decide on its fate. |
|
What am I missing @baudehlo? For this to be exploited, someone needs to drop a js file onto the filesystem in one of the config directories. If an attacker can do that, haven’t we already lost the security game? The other way this could be exploited is by embedding a malicious js file in a npm package, but how is this any different/worse than what can be achieved currently with a malicious npm js file? Maybe I can think of worse things after coffee... |
|
Those, plus basically the reason I sandboxed plugins (a decision we
continue to debate the usefulness of) was to prevent people from shooting
themselves in the foot.
Like I said, I don't really feel the need to veto it though. If the
consensus is that it's useful and not problematic, then put it in.
…On Tue, Oct 8, 2019 at 11:56 AM Matt Simerson ***@***.***> wrote:
What am I missing @baudehlo <https://github.com/baudehlo>?
For this to be exploited, someone needs to drop a js file onto the
filesystem in one of the config directories. If an attacker can do that,
haven’t we already lost the security game?
The other way this could be exploited is by embedding a malicious js file
in a npm package, but how is this any different/worse than what can be
achieved currently with a malicious npm js file?
Maybe I can think of worse things after coffee...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#50?email_source=notifications&email_token=AAFBWY7BAHSXKB4WY3CGIXLQNSUQ3A5CNFSM4I6PRYZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAUVVLA#issuecomment-539581100>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAFBWY5SQQNZW6K47EFODPDQNSUQ3ANCNFSM4I6PRYZQ>
.
|
|
@msimerson those were exactly my thoughts, however, @baudehlo we could also load this within a sandboxed environment that allows access to |
|
As I've let this gestate in my head today, my gut feel has been, golly, it sure was great that Thompson, Richie, and the fellows that invented unix didn't feel obligated to protect us from ourselves. Somehow we've managed to create and administer great and wonderful things without being nannied. Much of the strength and utility comes from being just a fat-finger away from |
|
I'm going to let this sit for a couple more days for feedback, but in the meantime, please also update Changes.md and bump the version in package.json. |
|
Yeah let's not let the horrible Node sandboxing infect any other parts of
the Haraka codebase. One day I'd like to remove it from plugins too.
…On Wed, Oct 9, 2019 at 1:08 AM Matt Simerson ***@***.***> wrote:
I'm going to let this sit for a couple more days for feedback, but in the
meantime, please also update Changes.md and bump the version in
package.json.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#50?email_source=notifications&email_token=AAFBWY2BFU6CXRWJJXH55Q3QNVRMRA5CNFSM4I6PRYZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAWTDLI#issuecomment-539832749>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAFBWY6ZHDU47J7ODJVCN4DQNVRMRANCNFSM4I6PRYZQ>
.
|
|
@oreoluwa , your change is published on NPM. Thanks for your contribution. |
Basically, this seem like a simpler/non-complicated workaround for environment variables haraka/Haraka#2098
As the user may inject the environment variables, manipulate as needed and also be able to load other dynamic configurations within node's runtime.