The old awk implementation always worked on lines beginning with 'Ciphers:' until it found 'Hash:'.
This fails for locales where a respective gnupg2.mo entry exists (Example: Ciphers in german is translated as Verschlü.:).
This is replaced by pointing awk on a specific line, which is for gpg1 and gpg2 the same. Work is done until awk stumbles up on a line which marks a new section (marked by keyword and :)
This closes#299
Firstly the printed binary path is in the wrong place. Reading the text, one assumes Ciphers coming next.
Secondly it doesn't make sense to check there for a missing gnupg installation. Before calling list_gnupg_ciphers(), there is a direct call for gpg --version. If that fails the whole text is scrambled and no error reported
Dropping the output from which allows to remove the space from printing the ciphers. The text is correctly aligned now
pinentry --version invocation includes License information.
As the same applies for gpg, and the information is not displayed there, we should the same with pinentry.
And tomb doesn't deal with the gpg sourcecode in any way.
This closes#300
this reverts commit 843b7fdfc4
and refers to various issues, among them #268
on the long term its easy to realise how this is a usability feature for most
users, so we just provide a new '-p' flag to preserve ownership on open.
fix#147 introducing an extra check on TOMBNAME that, if returned
empty by the first transormation that removes the last .extension,
then is filled with the full TOMBFILE name without any transformation
As debated in issue #282 Zsh introduced a bug in v5.3.1 which briefly affected
our mechanism for closing tombs. The bug is fixed, but while investigating the
issue @aude realised there can be a better way to apply this regex for the
detection of mounted volumes on distro dependent /run/media/$USER paths.
This change drops usage of the regex optional module in Zsh to use the built-in
=~ comparison and improves the match using round parenthesis. It may fix the
close command on some distributions.
this fixes a mount-related functionality (finding the volume label) in new
versions of util-linux, that since v2.30 does not list anymore volume labels
with its mount -l command. Since findmnt needs sudo to list labels, this also
introduces the need for sudo in more commands: is_valid_tomb(), list, index and
search. The issue was examined in PR #283 and this is a rebase of it.
As debated in issue #282 Zsh introduced a bug in v5.3.1 which briefly affected
our mechanism for closing tombs. The bug is fixed, but while investigating the
issue @aude realised there can be a better way to apply this regex for the
detection of mounted volumes on distro dependent /run/media/$USER paths.
This change drops usage of the regex optional module in Zsh to use the built-in
=~ comparison and improves the match using round parenthesis. It may fix the
close command on some distributions.
this small bug caused rewriting the $i variable (often used as
iterator in loops) whenever a log message was produced. Fix also
includes an acceleration of log printing by substituting seq with
native zsh notation.
also removed pre-open and post-close as they don't really make sense
since all hooks are contained inside the Tomb. The post-close may be
implemented using a temp file, if a use case turns up for it.
Renamed file from "post-hooks" to more appropriate "exec-hooks".
Implemented and documented a more consistent call system made of 4
different stages: pre-open, post-open, pre-close, post-close.
Addresses issue #265
- Remove --no-options gpg option when using GPG key.
- Improve gpg default key tests
To use the default key, ~/.gnupg/gpg.conf needs:
default-key <keyid>
default-recipient-self
Or
default-recipient <keyid>
Otherwise the first key in the keyring is used.
When opening a tomb file with "ro" passed through the -o option, the
writability check in is-valid-tomb() is skipped. This allows tomb files
to be opened without write permission.
test-open-read-only() now succeeds.
Due to the hidden-recipient, GPG will try all the available keys. User
can speed up this process providing the recipent using the -r
option. Therefore, 'tomb open' optionaly support the -r option.
tomb doesn't need lsof for anything else, and can work regulary without it.
So make it an optional feature, which allows to slam a tomb if lsof is installed
Updates additionally the man page and generates a new pdf from it
The -r option always requires an arguments. However GPG does not need
any recipient when decrypting a key. In order to be able to open a tomb
without writing (the long) recipient, the user can use the -f option to
short-cut the valid recipient checking. A dummy recipient is still required.
Sharing feature is a very sensitive action, the user needs to trust the
GPG public key it is going to share its tomb. This is why this feature
needs to be explicitly activated using in more the flag --shared
on the key encryption commands.
A tomb key can be encrypted with more than one recipient. Therefore, a
tomb can be shared between different user. The multiple recipients are
given using the -r (or/and -R) option and must be separated by ','.
Multiple recipients can be given for the commands: forge, setket and passwd
Decryption/Encryption works without these improvment, however, there
are needed in order to have clean key (without empty line).
Moreover, tests showed not doing cause troubles when changing the GPG key
used to encrypt a tomb key.
The tomb policy is to use the same password to encrypt
the key and to bury it. However, steganography cannot be
done with GPG key. Therefore, we check the user can
decrypt the tomb with its GPG key and we ask for a
steganography password. Having different method is a
technical requirement and should enhance security.
Apparantly fuser didn't report back, if the tomb was mounted in a subdir of /run (whereas /run itself is often a tmpfs mount).
With no list of process ids those couldn't be killed, so slamming the tomb failed.
lsof is capable to report back the sought information.
Fixes#220
Additionally fixing the debug output, where a hardcoded mountpoint was used
Addresses issue #238: as 512 bit key length triggers use of AES256.
Apparently so far tombs used AES128 due to key length 256.
Change passes all tests and has no regression implications.
The chmod/chown launched on the mounted volume is not really effective
for security, plus the UID is not correctly guessed when tomb is
launched using sudo. It is now up to the user to correctly set
ownership and permission on mounted volumes. There is also one less
check on the ownership of the tomb file which was failing with a
warning in the same case.
