Open MasterOdin opened 2 years ago
With the v3.0.0-rc.1 release that includes the support for mysql_clear_password
, I'd like to bump up this issue before a final v3.0.0 goes out such that doing this would then constitute a breaking change.
cc @sidorares
thanks for the ping, yeah wanted to review that before final release, after that its going to be more difficult to change api
I don't think there is any expectation from this library to respect LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN
or any other environment variable libmysql expects, but would be good to have some similar behaviour and consistent names for createConnection/createPool config flags
Looping in plugin users - @rathboma @silverbullettruck2001 - wdyt?
What I see the main attack vector is dns poisoning and mysql honeypot server stealing passwords.
What we discuss I guess is
enableCleartextPlugin: true
is passed to a config or potentially LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN
environment variable is setsounds reasonable to me
I agree with the above. Happy to put up a PR to tackle that, though would appreciate a pointer for (2) on where you'd like to see that in the code.
For anything dealing with databases, given how sensitive the data that might live in it, having the mechanisms to connect start as secure as possible and then only weaken security at the user's request is important to me.
I agree with the above. Happy to put up a PR to tackle that, though would appreciate a pointer for (2) on where you'd like to see that in the code.
Probably here:
add something along the lines of
if (pluginName === 'mysql_clear_password') { // add steps to see if OK to accept
I'm a bit hesitant re LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN but at the same time not against it
I'd be perfectly fine with having it be the library consumer who has to manually opt into using cleartext, and so they would have to deal with LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN
or whatever other mechanism they care to have in their program.
Hey all, I know I started the original PR that was merged to add cleartext support, but I agree with @MasterOdin that it makes sense for it to be disabled by default.
If possible, could it be enabled in some way when instantiating the client on a connection-by-connection basis, rather than through an environment variable, or another static method?
So as @sidorares suggested higher up the thread, adding a config parameter to createConnection
or createPool
sounds perfect.
mysql.createPool({
enableCleartextPlugin: true
...
})
// this would be amazing
@MasterOdin would you be able to provide PR with this change?
enableCleartextPlugin
to ConnectionConfig somewhere near https://github.com/sidorares/node-mysql2/blob/74cb14229bc9deced4d7fdbba8da3869f020764b/lib/connection_config.js#L115 ( default false )end to end test covering happy and error path. This is probably the most complicated step. I haven't found an easy way to configure real mysql server with mysql_clear_password auth, possible option is to have mysql2.createServer server but not sure how much work is to have that running
Yeah, neither have I, without also configuring something like ldap alongside it. I agree the best option is to use mysql2.createServer
. My plan was to base a test on one of:
I think this is shouldn't be too bad, just haven't yet found time, hoping to at some point this week.
sorry this has not received enough attention and I did release 3.0 in the end. I'll try to get the above functionality done and release as 3.1
probably depends on #1113 in order to be able to add e2e test
1552 added support for the
mysql_clear_password
auth plugin, but made it enabled by default. Per the manual docs on it:I would propose to make it disabled by default, and only enable it implicitly if the
LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN
environment variable is set to1
,Y
ory
(per the docs), or that a library consumer can add it themselves viaconfig.authPlugins
(following #1497 being merged to make it easy to reference).