]> gitweb.fluxo.info Git - keyringer.git/commitdiff
Manpage formatting
authorSilvio Rhatto <rhatto@riseup.net>
Fri, 25 Oct 2013 23:14:50 +0000 (21:14 -0200)
committerSilvio Rhatto <rhatto@riseup.net>
Fri, 25 Oct 2013 23:14:50 +0000 (21:14 -0200)
index.mdwn
share/man/keyringer.1.mdwn

index cc70d60047554f31ffe052d12651fc6e8c48625a..a26f90375e7a7f14cab8dad574feb44ee7f430a0 100644 (file)
@@ -5,7 +5,7 @@ commands to encrypt, decrypt, recrypt, create key pairs, etc.
 
 - Project page: [https://keyringer.pw](https://keyringer.pw)
 - Manpage: [keyringer.1](share/man/keyringer.1)
-- License: [GPLv3+](LICENSE).
+- License: [GPLv3+](LICENSE)
 - Issue tracker: [https://keyringer.pw/trac](https://keyringer.pw/trac)
 - Tor hidden service: [http://y6ntvl5bzs3c7ffa.onion](http://y6ntvl5bzs3c7ffa.onion)
 - Releases: [https://keyringer.pw/releases](releases)
index 7e79b3566fab66cbf7aa2832ad15b9098359d88e..6b7915e8522ad7de99ff4b15c1367c4f3482f354 100644 (file)
@@ -198,23 +198,23 @@ $KEYRING_FOLDER/config/options
 
 Keyringer currently has the following limitations:
 
-* Metadata is not encrypted, meaning that an attacker with access to a keyringer
+1. Metadata is not encrypted, meaning that an attacker with access to a keyringer
   repository knows all public key IDs are 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 *--hidden-recipient* GnuPG
   option.
 
-* History is not rewritten by default when secrets are removed from a keyringer
+2. History is not rewritten by default when secrets are removed from a keyringer
   repository. After a secret is removed with *del* action, it will still be
   available in the repository history even after a commit. This is by design
   due to the following reasons:
 
-  1. It's the default behavior of the Git content tracker. Forcing the
+  - 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 is someone
      mistakenly overwrites a secret.
 
-  2. History rewriting cannot be considered a security measure against the
+  - 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.