diff --git a/ChangeLog b/ChangeLog
index 5b1c53e7ce554fda8a321cef332fc90920916749..aa63787859aae5cdb6d06ad4bbf816745b4f6a92 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,32 @@
+2014-05-16 - 0.3.4 - Silvio Rhatto <rhatto@riseup.net>
+
+	Workaround for open/edit action returning instantaneously (#49)
+
+	Use 'nobackup' and 'nowritebackup' if VIM is set as $EDITOR (#50)
+
+	Find: rollback: use find+grep instead of 'find -iname' (#53)
+
+	Edit/open: wait for background process to finish (#49)
+
+	Edit: use encrypt action
+
+	Encrypt: support for KEYRINGER_ADD_EXTENSION environment variable
+	which controls if file extension should be appended to secret name
+
+	Genpair: generate ssh and ssl keys with 4096 bits size
+
+	Fix usage message inside keyringer shell
+
+	Fix recryption error when using gpg-agent in text mode (#55)
+
+	Be more verbose on recrypt errors
+
+	Adding "commit" action which is a wrapper around "git commit"
+
+	Align command output
+
+	Avoid viminfo if VIM is set as $EDITOR (#50)
+
 2014-03-22 - 0.3.3 - Silvio Rhatto  <rhatto@riseup.net>
 
 	Use --recv-keys instead of --refresh-keys
diff --git a/development.mdwn b/development.mdwn
index cf969fee33c8797eaba3bdcb863018edab8c2d01..67c64567b9509b05b42cc799405f53897c4f630f 100644
--- a/development.mdwn
+++ b/development.mdwn
@@ -37,12 +37,25 @@ These steps should be run once in a while to ensure we have an up to date packag
 
     DIST=sid sudo cowbuilder --update
 
+Coding standards
+----------------
+
+  - Respect the existing coding style.
+
+  - Be clear: easy audability must be one of keyringer's requirements.
+
+Development workflow
+--------------------
+
+We use [git-flow](https://github.com/nvie/gitflow) for the development workflow.
+
 Release workflow
 ----------------
 
-Go to master branch
+Go to develop branch and start a new release
 
-    git checkout master
+    git checkout develop
+    git flow release start VERSION
 
 Prepare the source code:
 
@@ -52,6 +65,8 @@ Prepare the source code:
 
 Create and upload a new release:
 
+    git flow release finish $VERSION
+    git checkout master
     make release
 
 Update the debian branch:
diff --git a/index.mdwn b/index.mdwn
index f9df557698cae8fcc65cf43a0114d176368b0396..a886930870ceaca6bce7efafcc8ebfab0a3a963a 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -7,7 +7,7 @@ commands to encrypt, decrypt, recrypt, create key pairs, etc.
 - Manpage: [keyringer.1](share/man/keyringer.1)
 - License: [GPLv3+](LICENSE)
 - Issue tracker: [https://keyringer.pw/trac](https://keyringer.pw/trac)
-- Tor hidden service: [http://y6ntvl5bzs3c7ffa.onion](http://y6ntvl5bzs3c7ffa.onion)
+- Tor hidden service: [http://wewbqck6m3ffkn44.onion](http://wewbqck6m3ffkn44.onion)
 - Releases: [https://keyringer.pw/releases](releases)
 - Contact: rhatto at riseup.net
 
@@ -40,7 +40,7 @@ a new keyring (or register an existing one with your config file), run:
 
     keyringer <keyring> init <path> [remote]
 
-This will 
+This will
 
   1. Add an entry at `$HOME/.keyringer/config` aliasing 'keyring' to 'path'.
   2. Initialize a git repository if needed.
@@ -49,52 +49,21 @@ For example,
 
     keyringer friends init $HOME/keyrings/friends
 
-will create an alias "friends" pointing to `$HOME/keyrings/friends`. All
-other keyring actions should be called using this alias.
+creates an alias "friends" pointing to `$HOME/keyrings/friends`. All
+other keyring actions for this keyring should be called using this alias.
 
 If there is an existing remote keyring git repository and you just
 want to checkout it, use
 
     keyringer friends init $HOME/keyrings/friends <repository-url>
 
-Managing recipients
--------------------
-
-Your next step is tell keyringer the OpenPGP key IDs to encrypt files to:
-
-    keyringer <keyring> recipients edit [recipient-name]
-    keyringer <keyring> recipients ls
-
-Keyringer support multiple recipients in a per-folder style. Try it by
-creating a sample keyringer
-
-    keyringer <keyring> recipients edit closest-friends
-
-Fill it with your friends key IDs. Now encrypt a secret just for then:
-
-    keyringer <keyring> encrypt closest-friends/secret
-
-In other words, if keyringer finds a recipient file matching a given path,
-it will use it instead of the global recipients file.
-
-Each recipient list is defined in a file placed at `config/recipients` in your
-keyring repository. Take care to add just trustable recipients.
-
 Managing secrets
 ----------------
 
-Each secret has a corresponding file in your `keys` subdirectory.
-
-Keyringer is agnostic about how you store your secrets. You may choose to have
-one encrypted file that contains one line for each secret, e.g. a single file called
-secrets with lines such as:
+Each `secret` has a corresponding file inside `keys` subdirectory from the
+keyring folder. Keyringer has plenty of actions to operate in these secrets:
 
-    emma : root : secret1
-    emma - /dev/hda : : secret2
-
-Or you may also have a different encrypted file for each secret, e.g. a file called
-emma.root that contains the root passphrase for the server named `emma` and
-another called emma.hda with the passphrase to decrypt `/dev/hda` on `emma`.
+   keyringer <keyring> commands
 
 Encrypting a secret
 
@@ -127,9 +96,6 @@ Listing secrets
 
     keyringer <keyring> ls [arguments]
 
-Each `<secret>` is stored as a file inside the `keys/` folder of your keyring
-directory.
-
 Git wrapper
 -----------
 
@@ -139,17 +105,29 @@ Keyringer comes with a simple git wrapper to ease common management tasks:
     keyringer <keyring> git push keyringer master
     keyringer <keyring> git pull
 
-Configuration files, preferences and options
---------------------------------------------
+Configuration files, preferences, options and recipients
+--------------------------------------------------------
+
+Basic keyringer operation depends in a set of configuration files:
 
   1. Main config file: `$HOME/.keyringer/config`: store the location of
      each keyring.
 
   2. User preferences per keyring: `$HOME/.keyringer/<keyring>`: managed by
-     "keyringer <keyring> preferences".
+     "keyringer <keyring> preferences". Preferences aren't shared among
+     users, so each user can have it's own set of preferences.
 
   3. Custom keyring options: `$KEYRING_FOLDER/config/options`: managed by
-     "keyringer <keyring> options".
+     "keyringer <keyring> options". Options are shared among all
+     keyring users.
+
+  4. Recipients: `$KEYRING_FOLDER/config/recipients/`: controls the list of
+     OpenPGP public key fingerprints that should be used when encrypting content.
+     Multiple recipients are supported, so secrets can be encrypted to
+     different sets of OpenPGP pubkeys in the same keyring.
+
+Other configuration parameters used by keyringer and it's actions are stored at
+`$KEYRING_FOLDER/config/`.
 
 Using a non-default OpenPGP key
 -------------------------------
@@ -163,31 +141,104 @@ Example:
 
     keyringer <keyring> preferences add KEYID=0123456789ABCDEF0123456789ABCDE012345678
 
-Concepts
---------
+Managing recipients
+-------------------
 
-Basic idea is:
+Keyringer uses the `default` recipient stored at `$KEYRING_FOLDER/config/recipients/default`
+as the standard list of OpenPGP public key fingerprints to which secrets should be encrypted.
 
-  - Encrypt screts using multiple users's OpenPGP public keys and commit the output in a git repository.
+Additionally, keyringer supports multiple `recipient` files which can have a different set
+of OpenPGP public key fingerprints used for encryption.
 
-  - Let users keep it in sync with the repository and the secrets are shared :)
+Recipients are matched against secrets according to it's path. If there exists a recipient
+called `accounting`, the following secret will be encrypted using it's OpenPGP public key
+fingerprints:
 
-Secrets can be any regular file as the script work with stdin and output things to
-files, so it can be passphrases, private keys or other kind of information.
+    keyringer <keyring> encrypt accounting/balance
 
-With theses scripts, the workflow is more or less like this:
+In other words, the `accounting` recipient file is used because the secret name begins
+with `accounting`.
 
-  - You have a git repo for secret keys.
+So it's the case that recipients listed in the `default` recipient but not in the
+`accounting` recipients won't be able to decrypt this secret.
 
-  - You run the "encrypt" command and paste your private key to this
-    command (so no plaintext is written to disk).
+When you first initalized your keyring, keyringer might have asked you to populate
+the `default` recipient list or you cloned a keyring repository which already has
+the `default` recipient.
 
-  - The encrypt command writes an encrypted file to the repo.
+If you want more recipient files, your next step is tell keyringer the OpenPGP
+key IDs to encrypt files to:
 
-  - You manually add it to git and push it to remote repositories.
+    keyringer <keyring> recipients edit [recipient-name]
+    keyringer <keyring> recipients ls
 
-  - Optionally, other users pulls the changes but they dont need to
-    decrypt anything until they need to use the keys.
+Remember that keyringer support multiple recipients in a per-folder style. Try
+it by creating a sample recipient file:
+
+    keyringer <keyring> recipients edit closest-friends
+
+Fill it with your friends key IDs. Now encrypt a secret just for then:
+
+    keyringer <keyring> encrypt closest-friends/secret
+
+In other words, if keyringer finds a recipient file matching a given path,
+it will use it instead of the global recipients file.
+
+You can even create recipient files with your friends' key IDs but without
+yours: then you shall be able to encrypt secrets for them that even you cannot
+access. Try to find an use case for that ;)
+
+Each recipient list is defined in a file placed at `config/recipients` in your
+keyring repository. Take care to add just trustable recipients.
+
+Design
+------
+
+Keyringer's basic concepts are as follows:
+
+  - Each secret is encrypted using multiple users's OpenPGP public keys and commit the
+    output in a git repository we call a "keyring".
+
+  - A "recipient" a list of OpenPGP keys associated with a path in the keyring, so each
+    keyring can have multiple recipient definitions so secret compartmentalization is
+    builtin. All encryption should respect recipient definition.
+
+  - Users can keep their keyring copies in sync using any git remote and push/pull
+    strategy they like, so key sharing gets easy.
+
+  - A secret is not limited to passphrases or text: keyringer supports any file encryption,
+    so managing private keys, spreadsheets and media files are handled without distinction.
+
+  - Secret is stored with OpenPGP ASCII-armoured output, so one doesn't need any special
+    program besides GnuPG to actually decrypt information.
+
+  - Keyringer is agnostic about how you store your secrets. You may choose to have
+    one encrypted file that contains one line for each secret, e.g. a single file called
+    secrets with lines such as:
+
+      emma : root : secret1
+      emma - /dev/hda : : secret2
+
+    Or you may also have a different encrypted file for each secret, e.g. a file called
+    `emma.root` that contains the root passphrase for the server named `emma` and
+    another called `emma.hda` with the passphrase to decrypt `/dev/hda` on `emma`.
+
+    Creating a logical structure to store your secrets is up to you :)
+
+Workflow
+--------
+
+Keyringer can be used as a personal or shared password/secret manager:
+
+  - Each keyring is a full git repository used to store encrypted secrets
+    using ASCII-armoured OpenPGP.
+
+  - Actions like `encrypt` allows you to paste your secrets directly to
+    GnuPG so no plaintext is written to disk.
+
+  - By commiting, pushing and pulling each keyring repository, you can
+    easily share secrets with other people and systems and they don't
+    need to decrypt this information until they need.
 
 In summary, keyringer data store is basically gpg-encrypted data atop of a git
 repository (one can think of a kind of distributed encrypted filesystem).
@@ -195,21 +246,13 @@ repository (one can think of a kind of distributed encrypted filesystem).
 Git was chosen to host encrypted info mostly for two reasos: easy to distribute
 and its the only VCS known to make easier repository history manipulation.
 
-One possible drawback: the repo has pubkey information attached, which can be
-linked to real people (and then disclose the information about who has access to a
-given key).
-
-To mitigate that, it's possible to:
-
-  - Keep the repo just atop of an encrypted and non-public place.        
-
-  - Or to consider an integration with gpg's --hidden-recipient option.
+Limitations
+-----------
 
-Never decrypt a key and write it to the disk, except if you're adding it to
-your personall keyring.
+  - See the [manpage](share/man/keyringer.1) for details.
 
-Check [this page](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
-a comparison on different password management tools.
+  - Check [this page](https://wiki.koumbit.net/PasswordManagementService/SoftwareComparison)
+    a comparison on different password management tools.
 
 Requirements
 ------------
@@ -218,7 +261,7 @@ Keyringer needs:
 
   - [Bash](http://tiswww.case.edu/php/chet/bash/bashtop.html)
   - [Git](http://git-scm.com)
-  - [GNU](Privacy Guard - http://gnupg.org)
+  - [GNU Privacy Guard](http://gnupg.org)
   - Grep, awk, tail, cut, sed and other GNU tools
 
 Optional dependencies if you want to manage ssl keys:
diff --git a/keyringer b/keyringer
index 6a1eda5e554705b41dde01b584dcb4619de3761e..e1f405f064dfc699a2df2e1779ee5027f29f6b73 100755
--- a/keyringer
+++ b/keyringer
@@ -138,7 +138,7 @@ function keyringer_dispatch {
 
 # Config
 NAME="keyringer"
-KEYRINGER_VERSION="0.3.3"
+KEYRINGER_VERSION="0.3.4"
 CONFIG_VERSION="0.1"
 CONFIG_BASE="$HOME/.$NAME"
 CONFIG="$CONFIG_BASE/config"
diff --git a/lib/keyringer/actions/commit b/lib/keyringer/actions/commit
new file mode 100755
index 0000000000000000000000000000000000000000..b1249275cfe04a1ddbf0120e90cd93846b873e32
--- /dev/null
+++ b/lib/keyringer/actions/commit
@@ -0,0 +1,14 @@
+#!/bin/bash
+#
+# Git commit wrapper.
+#
+
+# Load functions
+LIB="`dirname $0`/../functions"
+source "$LIB" || exit 1
+
+# Fix positional arguments
+shift
+
+# Run git command
+keyringer_exec git "$BASEDIR" commit $*
diff --git a/lib/keyringer/actions/edit b/lib/keyringer/actions/edit
index 03ccdab0315d1d8e708b6a84e4a616a8efd5d8e7..3ccf97745139fe880c06705744c3789daf2aea9f 100755
--- a/lib/keyringer/actions/edit
+++ b/lib/keyringer/actions/edit
@@ -38,11 +38,27 @@ fi
 
 # Prompt
 echo "Press any key to open the decrypted data with $APP, Ctrl-C to abort"
-read key
+echo "WARNING: please make sure that $APP doesn't leak data to external applications or files"
+echo "Press ENTER to continue"
+read -s key
 $APP "$TMPWORK"
 
+# Wait for background process to finish
+wait
+
+# Workaround for some applications running in client/server mode, handling open file requests
+# to a daemon and exiting immediatelly, making keyringer guess the editing is over and the file
+# must be encrypted again (See #49).
+#
+# Thus, we cannot just wipe the file and exit keyringer, as the user might have a buffered copy
+# of the unencrypted file in the application, which can lead to information leakage if the user
+# saves the file and leaves the editor.
+echo "Press any key when done using the file and you're sure that $APP is closed."
+read -s -n 1
+
 # Encrypt again
-$GPG --yes -o "$KEYDIR/$FILE" --use-agent --armor -e -s $(keyringer_recipients "$RECIPIENTS_FILE") "$TMPWORK"
+export KEYRINGER_ADD_EXTENSION=false
+keyringer_exec encrypt "$BASEDIR" "$FILE" "$TMPWORK"
 
 # Check exit status
 errcrypt="$?"
diff --git a/lib/keyringer/actions/encrypt b/lib/keyringer/actions/encrypt
index e9bf4534c7ccb3a0ade182d5fad7fe54bc9c26d8..7415267dc7f3a27ea3741faf2cd499bec07fccec 100755
--- a/lib/keyringer/actions/encrypt
+++ b/lib/keyringer/actions/encrypt
@@ -57,9 +57,11 @@ if [ ! -z "$3" ]; then
     #
     # Useful when opening files and the application needs the
     # extension to guess the file type.
-    if ! echo $BASEPATH | grep -q -e "\.$EXTENSION$"; then
+    if [ "$KEYRINGER_ADD_EXTENSION" != "false" ] && ! echo $BASEPATH | grep -q -e "\.$EXTENSION$"; then
       echo "Appending '$EXTENSION' into secret name..."
       FILE="$BASEPATH.$EXTENSION"
+    else
+      FILE="$BASEPATH"
     fi
   else
     FILE="$BASEPATH"
diff --git a/lib/keyringer/actions/find b/lib/keyringer/actions/find
index 21afc7a7096f392297c2f71d45f1ec8a1d12cbd5..9b18d66891ab7190054dda76ee6925b10eb30bb8 100755
--- a/lib/keyringer/actions/find
+++ b/lib/keyringer/actions/find
@@ -15,5 +15,5 @@ shift
 ARGS="`echo "$*" | sed -e "s|^/*||"`"
 
 # Run find command
-cd "$KEYDIR/$RELATIVE_PATH" && find -iname "*$ARGS*" | sed -e 's|^./||g'
+cd "$KEYDIR/$RELATIVE_PATH" && find | grep -i "$ARGS" | sed -e 's|^./||g'
 cd "$CWD"
diff --git a/lib/keyringer/actions/genpair b/lib/keyringer/actions/genpair
index 6898b0ff4dee93a91605e142a38189feed54d1eb..6fc6dcd834fa8ddf8a6c6c97bdd7cb61295d2012 100755
--- a/lib/keyringer/actions/genpair
+++ b/lib/keyringer/actions/genpair
@@ -12,7 +12,7 @@ function genpair_ssh {
   read -p "Hit ENTER to continue." prompt
 
   # We're using empty passphrases
-  ssh-keygen -t rsa -P '' -f "$TMPWORK/id_rsa" -C "root@$NODE"
+  ssh-keygen -t rsa -b 4096 -P '' -f "$TMPWORK/id_rsa" -C "root@$NODE"
 
   # Encrypt the result
   echo "Encrypting secret key into keyringer..."
@@ -132,7 +132,7 @@ EOF
   cat openssl.conf
   read -p "Hit ENTER to continue." prompt
 
-  openssl req -batch -nodes -config openssl.conf -newkey rsa:2048 -sha256 \
+  openssl req -batch -nodes -config openssl.conf -newkey rsa:4096 -sha256 \
           -keyout ${NODE}_privatekey.pem -out ${NODE}_csr.pem
 
   openssl req -noout -text -in ${NODE}_csr.pem
diff --git a/lib/keyringer/actions/git b/lib/keyringer/actions/git
index d4e7aa439d1842dcd2b8e1acaa66939586b5155c..059b20e14a53a4d4fa59c453b58db0a1a130bb51 100755
--- a/lib/keyringer/actions/git
+++ b/lib/keyringer/actions/git
@@ -10,8 +10,9 @@ source "$LIB" || exit 1
 # Aditional parameters
 CWD="`pwd`"
 
-# Run git command
+# Fix positional arguments
 shift
 
+# Run git command
 mkdir -p "$BASEDIR" && cd "$BASEDIR" && git $*
 cd "$CWD"
diff --git a/lib/keyringer/actions/recrypt b/lib/keyringer/actions/recrypt
index 696399be63d014f32144879b760ffe07082ff43c..30c925493dc758495cc17d156b36ad6c82cc3798 100755
--- a/lib/keyringer/actions/recrypt
+++ b/lib/keyringer/actions/recrypt
@@ -16,10 +16,10 @@ function keyringer_recrypt {
   keyringer_set_recipients "$FILE"
 
   # Decrypt
-  decrypted="$($GPG --use-agent -d "$KEYDIR/$FILE" 2> /dev/null)"
+  decrypted="$($GPG --use-agent -d "$KEYDIR/$FILE")"
 
   if [ "$?" != "0" ]; then
-    echo "Decryption error."
+    echo "Decryption error on $1."
     exit 1
   fi
 
@@ -27,7 +27,7 @@ function keyringer_recrypt {
   recrypted="`echo "$decrypted" | $GPG --use-agent --armor -e -s $(keyringer_recipients "$RECIPIENTS_FILE")`"
 
   if [ "$?" != "0" ]; then
-    echo "Recryption error."
+    echo "Recryption error on $1."
     exit 1
   fi
 
diff --git a/lib/keyringer/functions b/lib/keyringer/functions
index f1af9515761ee4ec3001baceccf288a8a3663db6..50d01db29a00b0bbcbce22660db29d881698fb3f 100755
--- a/lib/keyringer/functions
+++ b/lib/keyringer/functions
@@ -284,6 +284,13 @@ function keyringer_set_env {
     fi
   fi
 
+  # Avoid viminfo, see https://keyringer.pw/trac/ticket/50
+  if $EDITOR --help | grep -q -e "^VIM"; then
+    if ! echo $EDITOR | grep -q -- "-i NONE"; then
+      EDITOR="$EDITOR -i NONE '+set nowritebackup' '+set nobackup'"
+    fi
+  fi
+
   if [ ! -f "$OPTIONS" ]; then
     echo "No option config was found"
     exit 1
@@ -429,7 +436,7 @@ function keyringer_get_file {
   elif [ ! -f "$KEYDIR/$FILE" ]; then
     # Try to find a similar file
     count=0
-    candidates=(`keyringer_exec find "$BASEDIR" "$1*.asc"`)
+    candidates=(`keyringer_exec find "$BASEDIR" | grep -i "$1" | grep -e '.asc$'`)
 
     if [ ! -z "$candidates" ]; then
       echo "Could not find exact match for \"$1\", please choose one of the following secrets:"
@@ -510,7 +517,7 @@ function keyringer_action_usage {
 
 # Return available actions
 function keyringer_show_actions {
-  ls $ACTIONS
+  ls -C $ACTIONS
 }
 
 # Usage
@@ -518,7 +525,7 @@ function keyringer_usage {
   local keyrings="$(ls --color=never `dirname $CONFIG` | sed -e 's/config//' | xargs)"
 
   printf "Keyringer $KEYRINGER_VERSION\n"
-  printf "Usage: %s <keyring> <action> [arguments]\n\n" "$BASENAME"
+  printf "Usage: keyringer <keyring> <action> [arguments]\n\n"
 
   # Display only when not in a keyring context
   if [ ! -z "$keyrings" ] && [ -z "$1" ]; then
@@ -531,6 +538,7 @@ function keyringer_usage {
     printf "\tinit <path> [remote]\n" $BASENAME
   fi
   keyringer_show_actions | sed -e 's/^/\t/'
+  printf "\n"
 }
 
 # Check repository integrity
diff --git a/share/man/keyringer.1 b/share/man/keyringer.1
index f460cbf889499602319262525bc562d77c92bcf5..95c236da9d28c95da77ca3d9af04ccafa75224e9 100644
--- a/share/man/keyringer.1
+++ b/share/man/keyringer.1
@@ -62,6 +62,11 @@ applied in the keyring repository.
 .RS
 .RE
 .TP
+.B commit [\f[I]arguments\f[]]
+Alias to "git commit".
+.RS
+.RE
+.TP
 .B ls <\f[I]path\f[]>
 List contents from the toplevel repository \f[I]keys\f[] folder or from
 relative paths if \f[I]path\f[] is specified.
@@ -169,6 +174,10 @@ Edit a secret by temporarily decrypting it, opening the decrypted copy
 into the text editor defined by the \f[I]$EDITOR\f[] environment
 variable and then re-encrypting it.
 .RS
+.PP
+Please make sure to use an
+\f[I]\f[I]E\f[]\f[I]D\f[]\f[I]I\f[]\f[I]T\f[]\f[I]O\f[]\f[I]R\f[] * \f[I]w\f[]\f[I]h\f[]\f[I]i\f[]\f[I]c\f[]\f[I]h\f[]\f[I]d\f[]\f[I]o\f[]\f[I]e\f[]\f[I]s\f[]\f[I]n\f[]\f[I]o\f[]\f[I]t\f[]\f[I]l\f[]\f[I]e\f[]\f[I]a\f[]\f[I]k\f[]\f[I]d\f[]\f[I]a\f[]\f[I]t\f[]\f[I]a\f[]\f[I]l\f[]\f[I]i\f[]\f[I]k\f[]\f[I]e\f[]\f[I]h\f[]\f[I]i\f[]\f[I]s\f[]\f[I]t\f[]\f[I]o\f[]\f[I]r\f[]\f[I]y\f[]\f[I]b\f[]\f[I]u\f[]\f[I]f\f[]\f[I]f\f[]\f[I]e\f[]\f[I]r\f[]\f[I]s\f[]. \f[I]K\f[]\f[I]e\f[]\f[I]y\f[]\f[I]r\f[]\f[I]i\f[]\f[I]n\f[]\f[I]g\f[]\f[I]e\f[]\f[I]r\f[]\f[I]t\f[]\f[I]r\f[]\f[I]i\f[]\f[I]e\f[]\f[I]s\f[]\f[I]t\f[]\f[I]o\f[]\f[I]d\f[]\f[I]e\f[]\f[I]t\f[]\f[I]e\f[]\f[I]c\f[]\f[I]t\f[]\f[I]i\f[]\f[I]f\f[] * EDITOR\f[]
+is set to VIM and disables the \f[I]\&.viminfo\f[] file.
 .RE
 .TP
 .B encrypt <\f[I]secret\f[]> [\f[I]file\f[]]
@@ -329,7 +338,10 @@ keyringer repository can discover all public key IDs used for
 encryption, and which secrets are encrypted to which keys.
 This can be improved in the future by encrypting the repository
 configuration with support for the \f[I]\-\-hidden-recipient\f[] GnuPG
-option.
+option and encrypted repository options.
+.PP
+To mitigate that, it\[aq]s possible to keep the repo just atop of an
+encrypted and non-public place.
 .IP "2." 3
 History is not rewritten by default when secrets are removed from a
 keyringer repository.
@@ -354,6 +366,10 @@ knowledge of the previous secret.
 Users wishing to edit their repository history should proceed manually
 using the \f[I]git\f[] action.
 .RE
+.IP "3." 3
+Keyringer does not protect data which were not encrypted to a keyring,
+so be careful when decrypting secrets and writing them to the disk or
+other storage media.
 .SH SEE ALSO
 .PP
 The \f[I]README\f[] file distributed with Keyringer contains full
diff --git a/share/man/keyringer.1.mdwn b/share/man/keyringer.1.mdwn
index adbaaa232d8de6a6552f54334c2370b1477914e0..407baaa9683911bc649a0183d1213c502fb658d8 100644
--- a/share/man/keyringer.1.mdwn
+++ b/share/man/keyringer.1.mdwn
@@ -57,6 +57,9 @@ git <*action*> <*options*>
 :   Git wrapper that operates from the toplevel keyring repository. You can issue any
     *GIT(1)* subcommand with this action to have it applied in the keyring repository.
 
+commit [*arguments*]
+:   Alias to "git commit".
+
 ls <*path*>
 :   List contents from the toplevel repository *keys* folder or from relative paths
     if *path* is specified. Like the git wrapper, this is a wrapper around the *LS(1)*
@@ -129,9 +132,12 @@ mv <*secret*> <*dest*>
 :   Rename a secret.
 
 edit <*secret*>
-:   Edit a secret by temporarily decrypting it, opening the decrypted copy into the 
+:   Edit a secret by temporarily decrypting it, opening the decrypted copy into the
     text editor defined by the *$EDITOR* environment variable and then re-encrypting it.
 
+    Please make sure to use an *$EDITOR* which does not leak data like history buffers.
+    Keyringer tries to detect if *$EDITOR* is set to VIM and disables the *.viminfo* file.
+
 encrypt <*secret*> [*file*]
 :   Encrypts content from standard input or *file* into *secret* pathname. No spaces
     are supported in the *secret* name. If *file* is actually a folder, keyringer
@@ -245,31 +251,38 @@ $KEYRING_FOLDER/config/options
 Keyringer currently has the following limitations:
 
 1. Metadata is not encrypted, meaning that an attacker with access to a keyringer
-  repository can discover all public key IDs used for encryption, and which secrets
-  are encrypted to which keys. This can be improved in the future by encrypting
-  the repository configuration with support for the *--hidden-recipient* GnuPG
-  option.
+   repository can discover all public key IDs used for encryption, and which secrets
+   are encrypted to which keys. This can be improved in the future by encrypting
+   the repository configuration with support for the *--hidden-recipient* GnuPG
+   option and encrypted repository options.
+
+   To mitigate that, it's possible to keep the repo just atop of an encrypted and
+   non-public place.
 
 2. History is not rewritten by default when secrets are removed from a keyringer
-  repository. After a secret is removed with the *del* action, it will still be
-  available in the repository history even after a commit. This is by design
-  for the following reasons:
+   repository. After a secret is removed with the *del* action, it will still be
+   available in the repository history even after a commit. This is by design
+   for the following reasons:
 
   - It's the default behavior of the Git content tracker. Forcing the
-     deletion by default could break the expected behavior and hence limit
-     the repository's backup features, which can be helpful if someone
-     mistakenly overwrites a secret.
+    deletion by default could break the expected behavior and hence limit
+    the repository's backup features, which can be helpful if someone
+    mistakenly overwrites a secret.
 
   - History rewriting cannot be considered a security measure against the
-     unauthorized access to a secret as it doesn't automatically update all
-     working copies of the repository.
+    unauthorized access to a secret as it doesn't automatically update all
+    working copies of the repository.
+
+    In the case that the secret is a passphrase, the recommended measure
+    against such attacks is to change the passphrase, making useless the
+    knowledge of the previous secret.
 
-     In the case that the secret is a passphrase, the recommended measure
-     against such attacks is to change the passphrase, making useless the
-     knowledge of the previous secret.
+    Users wishing to edit their repository history should proceed manually
+    using the *git* action.
 
-     Users wishing to edit their repository history should proceed manually
-     using the *git* action.
+3. Keyringer does not protect data which were not encrypted to a keyring,
+   so be careful when decrypting secrets and writing them to the disk or
+   other storage media.
 
 # SEE ALSO