Saves the connection password in a sidecar ETS table.

[eloraburns]

This could allow us to remove show_sensitive_data_on_connection_error as an option, as the sensitive data won't be in the main process' state (just a pid). There are also cases where passwords are still dumped, e.g. when we hit https://github.com/xerions/mariaex/issues/151 (this happened at work a couple of weeks ago).

I'm definitely happy to chat about alternatives! I hope that the :private ETS table is OK in this context (i.e. connect's caller is a persistent process for this connection, or at least this class of connection…).

Thanks!

[coveralls]

Coverage increased (+0.04%) to 86.312% when pulling b8cd583bdfc49a63bf69b99c44901600b9468997 on taavi:save-password-in-sidecar-process into e594a3e5ffdf997c0160b209b8fc5e2b1d7d5a9f on xerions:master.

[coveralls]

Coverage decreased (-0.3%) to 85.985% when pulling 789f9e4370e861817a334212a8f58643494e48de on taavi:save-password-in-sidecar-process into e594a3e5ffdf997c0160b209b8fc5e2b1d7d5a9f on xerions:master.

[eloraburns]

Ah, I see Elixir 1.4 support is a thing. :)

[cdegroot]

This will create an ETS table per connection, not? That would quickly exhaust the amount of available ETS tables.

[eloraburns]

@cdegroot Yes, an ETS table per connection. But those tables should be recycled as the connections are recycled, so shouldn't run completely out of control. The docs also note that in modern Erlang releases (at least), there is no longer a limit on the number of ETS tables (except for the RAM they consume).

http://erlang.org/doc/man/ets.html

[cdegroot]

Ah - I missed the memo on "no more limits" and forgot that ETS tables are GC'd when the owning process dies. Thanks for clearing it up!

[eloraburns]

Huh. Though it looks like a process would be a lot cheaper memory-wise than an ets table. http://erlang.org/doc/efficiency_guide/advanced.html