Skip to content
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

Saves the connection password in a sidecar ETS table. #247

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

eloraburns
Copy link

@eloraburns eloraburns commented Nov 16, 2018

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 #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!

This should 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 xerions#151 .
@coveralls
Copy link

Coverage Status

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

@coveralls
Copy link

coveralls commented Nov 16, 2018

Coverage Status

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

@eloraburns
Copy link
Author

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

@eloraburns eloraburns changed the title Saves the connection password in a sidecar process. Saves the connection password in a sidecar ETS table. Nov 16, 2018
@cdegroot
Copy link

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

@eloraburns
Copy link
Author

@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
Copy link

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants