I have a module Crypt::SecretBuffer which prevents a scalar from being seen "unless you really want to" (ideally passing it directly to an XS function to prevent copies from being made). Right now the API for viewing the secret is using 'local' on an attribute 'stringify_mask' and an overloaded stringification on the object: 
$password= secret(...);
...
local $password->{stringify_mask}= undef if ref($password) eq 'Crypt::
+SecretBuffer';
$db= DBI->connect($dsn, $user, $password, \%attr);

[download]

On Github, robrwo [suggested a new more functional-programming-like API, namely that a method of SecretBuffer would pass the secret to a callback. My thought on the matter was that the *real* missing feature is a duck-typing API that doesn't need to be specific to SecretBuffer, which should provide an easy and convenient recipe for code that doesn't have a hard dependency on SecretBuffer to gain access to secrets.

I'd like to conduct an informal poll of which design people like the best:

  1. "apply", a method which takes a callback of one argument: 
    if ($password isa 'Crypt::SecretBuffer') {
  $db= $password->apply(sub { DBI->connect($dsn, $user, $_[0], \%attr)
+ });
else {
  $db= DBI->connect($dsn, $user, $password, \%attr);
}

    [download]
  2. A more distinct method name that could be used for duck-typing and apply to other types of object: 
    if (blessed $password && $password->can("unmask_secret_to")) {
  $db= $password->unmask_secret_to(\&DBI::connect, 'DBI', $dsn, $user,
+ $password, \%attr);
} else {
  $db= DBI->connect($dsn, $user, $password, \%attr);
}

    [download]
    1. reveal_secret_to
    2. unmask_secret_to
    3. call_with_secret
    4. call_unmasked
  3. Use a scalar-ref overload: 
    $db= DBI->connect($dsn, $user, ref $password? $$password : $password, 
+\%attr);

    [download]

I just came up with that scalar-ref idea, and seems pretty safe because no code would normally scalar-dereference a ref unless the ref type was 'SCALAR'. Still, that's drastically lowering the bar for leaking the secret, and isn't advertising that it has this capability...

While pondering your preference, also consider the question "If someone contributed a patch to a module I maintain that added support for receiving secrets via SecretBuffer, how much boilerplate would I be willing to accept?"

In reply to Name a method that exposes a secret by NERDVANA

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.