In Ruby 4.0, how do you keep a secret instance variable such as @password out of an object's inspect output, and where can it still leak?

Any object that holds a credential - a database password, an API token, a signing key - is one `p` call, console session or error report away from printing it. This question is about Ruby's tools for preventing that, and their limits. ## Why the default leaks `Kernel#inspect`, the default behind `p` and every collection's `inspect`, shows the class name, the object's address and **every instance variable** with its value: ```ruby conf = DbConfig.new("db.local", "timetable", "hunter2") p conf # #<DbConfig:0x... @host="db.local", @user="timetable", @password="hunter2"> ``` Because arrays and hashes render their elements with `inspect`, the secret also appears when the object sits inside a collection that is logged, and `pp` builds its own listing of the same instance variables. ## Ruby 4.0: instance_variables_to_inspect Ruby 4.0 added a hook. When `Kernel#inspect` runs, it calls the object's `instance_variables_to_inspect` method (a private default on `Kernel` returns `nil`) and interprets the result: | Return value | Effect on `inspect` | |---|---| | `nil` | every instance variable is shown (the old behaviour) | | an Array of names, e.g. `[:@host, :@user]` | only those instance variables are shown | | an empty Array | no instance variables; the output is just `#<DbConfig:0x...>` | | anything else | `TypeError`: "Expected #instance_variables_to_inspect to return an Array or nil" | The documented style is a private one-liner using an endless method: ```ruby private def instance_variables_to_inspect = [:@host, :@user] ``` Listing what to **show** rather than what to hide is the safer default: a new `@api_token` added later stays hidden until someone deliberately lists it. ## Before 4.0: override inspect On 3.x the only option is to define `inspect` yourself, for example returning `"#<DbConfig host=#{@host.inspect} user=#{@user.inspect}>"`. This still works in 4.0 and gives full control of the format, at the cost of keeping it in sync with the class by hand. ## Where the secret can still leak Filtering `inspect` closes one path, not all of them: 1. **`pp` with a private hook.** The pp library shipped with Ruby 4.0.7 (pp 0.6.3) builds its list of instance variables with `respond_to?(:instance_variables_to_inspect) ? instance_variables_to_inspect : instance_variables`. `respond_to?` ignores private methods by default, so with the private style above, `pp conf` prints **all** instance variables, `@password` included. Making the hook public, or overriding `inspect` (pp uses a class's own `inspect` when one is defined), closes it. 2. **A hand-written `to_s` or log message** that interpolates `@password` - `inspect` filtering does not touch `to_s`. 3. **Direct access**: `instance_variables`, `instance_variable_get`, serialisation with `Marshal`, and interactive debuggers read the variable regardless of `inspect`. 4. **Code that copies the value out**, such as building a connection URL string that then gets logged. One path got narrower on its own: since Ruby 3.3 a `NoMethodError` message says "an instance of DbConfig" instead of embedding the receiver's `inspect`, so a typo'd method call no longer dumps the object into an exception message. ## A sturdier design Hide the secret in the **value itself**, not in every class that holds it. A tiny wrapper whose `to_s` and `inspect` both return a marker such as `"[FILTERED]"`, and which exposes the raw string only through an explicit method like `reveal`, stays redacted in `puts`, `p`, `pp`, interpolation and collections, because every printing path calls one of those two methods. The raw value then appears only where code asks for it by name, which is easy to review. ## Proving it in a spec A filter that nobody tests drifts: someone renames `@user` to `@username`, the allow-list silently stops showing it, or someone adds a new secret and switches the list to a deny-list. A two-line test pins the behaviour down - build the object with a recognisable fake password and assert that neither `inspect` nor `to_s` contains it. If the team relies on `pp` in consoles, assert on `pretty_inspect` as well, since it takes a different route to the instance variables. These tests are cheap, and they turn an easily forgotten convention into a failing build. ## Checklist for a class holding credentials - Define `instance_variables_to_inspect` (Ruby 4.0) listing only safe ivars - or override `inspect` on older Rubies. - Make the hook public or also override `inspect` if the team uses `pp`. - Never interpolate the secret in `to_s` or log lines. - Prefer a redacting wrapper object for the secret itself. - Test it: assert that `conf.inspect` does not include the password.