Directories and symlinks, a link command and support for unencrypted files

Grouping (directories)

KeyNanny allows you to group related information (secrets and metadata,
see below) together in directories. These directories have no special
meaning in KeyNanny and are treated simply as part of the name of an
entity. KeyNanny entities are referred to by their path name relative
to the applications storage directory.

Example: Application "app1" has its data stored in
"/var/lib/keynanny/storage/app1/". In there we could have a directory
called "database" that stores the "dbuser" and "password" objects.
These are then accessible via "keynanny ... get database/dbuser" and
"keynanny ... get database/password".

Metadata (unencrypted)

KeyNanny allows you to store metadata in the storage area. This
metadata is not encrypted. To avoid storing secrets unencrypted by
accident, KeyNanny will always encrypt data stored using "keynanny ...
set ...". However, you can place unencrypted files in the storage area
and KeyNanny will deliver them via the "keynanny ... get ..." command.
This allows you to put non-confidential information, such as a database
username, alongside your secrets for easier management (see Symlinks).

Symlinks

To allow easy switching of credentials and to provide transactional
(atomic) changes KeyNanny supports symbolic links (symlinks, as in "ln
-s"). Symlinks can point to files or directories and they are treated
as if they were real. In other words, if you have a directory called
"orginal" and create a symlink by issuing "ln -s original linked", then
"linked" and its content is treated as if it were a directory. This
allows for transactional changes of any number of credentials and
metadata.

Example: Assume "db1" is a directory containing encrypted credentials
and unencrypted metadata for database access. "db-current" is a symlink
to "db1". The application uses "db-current" to refer to the current
configuration. When you need to change the password and/or metadata,
you can copy "db1" to "db2" and make the necessary changes in there.
Once done, re-link "db-current" to "db2". The application will now use
the new configuration.
Note that this will break the current assumption of KeyNanny being binary safe. In case of unencrypted entries this will only return the very first line.
Suggestion: slurp data and compare beginning of string
local $/;
open my $handle, '<', $arg
$data = <$handle>
close $handle;
if ($data =~ m{ \A ------BEGINE PKCS7 ----- }xms)
...

In addition consider caching the unencryted data via cache_store()