From 75a1e30ead416c1e48b11ab416c4b32a3a15555d Mon Sep 17 00:00:00 2001 From: Silvio Rhatto Date: Fri, 25 Oct 2013 21:15:20 -0200 Subject: Manpage formatting (2) --- share/man/keyringer.1 | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'share') diff --git a/share/man/keyringer.1 b/share/man/keyringer.1 index 822c54e..0f6e62d 100644 --- a/share/man/keyringer.1 +++ b/share/man/keyringer.1 @@ -244,28 +244,28 @@ applied for all users that use the keyringer repository. .SH LIMITATIONS .PP Keyringer currently has the following limitations: -.IP \[bu] 2 +.IP "1." 3 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 \f[I]--hidden-recipient\f[] GnuPG option. -.IP \[bu] 2 +.IP "2." 3 History is not rewritten by default when secrets are removed from a keyringer repository. After a secret is removed with \f[I]del\f[] action, it will still be available in the repository history even after a commit. This is by design due to the following reasons: -.IP "1." 3 +.IP \[bu] 2 It\[aq]s the default behavior of the Git content tracker. Forcing the deletion by default could break the expected behavior and hence limit the repository\[aq]s backup features, which can be helpful is someone mistakenly overwrites a secret. -.IP "2." 3 +.IP \[bu] 2 History rewriting cannot be considered a security measure against the unauthorized access to a secret as it doesn\[aq]t automatically update all working copies of the repository. -.RS 4 +.RS 2 .PP In the case that the secret is a passphrase, the recommended measure against such attack is to change the passphrase, making useless the -- cgit v1.2.3