view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    Encrypting swap is one way of mitigating this problem

  Clipboard access
    App::locket uses third-party tools for read/write access to the
    clipboard. It tries to detect if "pbcopy", "xsel", or "xclip" are
    available. It does this by looking in "/bin" and "/usr/bin"

  Purging the clipboard
    By default, App::locket will purge the clipboard of a secret it put
    there after a set delay. It will try to verify that it is wiping what it
    put there in the first place (so it doesn't accidentally erase something
    else you copied)

    If for some reason App::locket cannot read from the clipboard, it will
    purge it just in case

    If you prematurely cancel a secret copying operation via CTRL-C,
    App::locket will catch the signal and purge the clipboard first

  Attack via configuration

lib/App/locket.pm  view on Meta::CPAN

Encrypting swap is one way of mitigating this problem

=head2 Clipboard access

App::locket uses third-party tools for read/write access to the clipboard. It tries to detect if
C<pbcopy>, C<xsel>, or C<xclip> are available. It does this by looking in C</bin> and C</usr/bin>

=head2 Purging the clipboard

By default, App::locket will purge the clipboard of a secret it put there after a set delay. It will try to verify that it is
wiping what it put there in the first place (so it doesn't accidentally erase something else you copied)

If for some reason App::locket cannot read from the clipboard, it will purge it just in case

If you prematurely cancel a secret copying operation via CTRL-C, App::locket will catch the signal and purge the clipboard first

=head2 Attack via configuration

Currently, App::locket does not encrypt/protect the configuration file. This means an attacker can potentially (unknown to you) modify
the reading/editing commands to divert the plaintext elsewhere