Depending script invokation, behavior is not exactly similar.
Assuming that if SUDO_USER is set, the _sudo invokation can be dropped (EUID=0).
In the other case, user has created file, owner is already good, don't call chown.
Preparation:
$ tomb dig foo.tomb -s 10
Method 1:
$ sudo tomb forge foo.tomb.key -v
Method 2:
$ tomb forge foo.tomb.key -v
... ask user password to gain superuser privileges
...
Sorry, user <username> is not allowed to execute '/bin/chown <uid>:<gid> foo.tomb.key' as root on <hostname>.
Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
Depending script invokation, behavior is not exactly similar.
Assuming that if SUDO_USER is set, the _sudo invokation can be dropped (EUID=0).
In the other case, user has created file, owner is already good, don't call chown.
Method 1:
$ sudo tomb dig foo.tomb -s 10 -v
Method 2:
$ tomb dig foo.tomb -s 10 -v
... ask user password to gain superuser privileges
...
Sorry, user <username> is not allowed to execute '/bin/chown <uid>:<gid> foo.tomb' as root on <hostname>.
Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
http://zsh.sourceforge.net/Doc/Release/Files.html
TMPPREFIX defaults to /tmp/zsh (for zsh shell)
Note: --tmp command line switch is not documented?
Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
check works both for empty ("") and non-existing vars and is a fix
for regression #398 to work on older Zsh versions. It is normalized
through all tomb's code.
simplified function calls for tracking of loop mount by using global
variables whose scope is limited to execution, most computation is now
included in the `is_valid_tomb` function.
fixes bug mentioned in issue #333 that made tomb append space to a
tomb file before checking for correct password, leading to file
corruption in case the wrong password is inserted 3 times.
also changes to priority order of invokation and some code cleanups and
indentations. Invokation order is now:
- WAYLAND? pinentry-gnome3
- X11?
1. pinentry-x11 (distro specific wrapper)
2. pinentry-gtk2 (legacy, removable)
3. pinentry-gnome3
4. pinentry-qt5
5. pinentry-qt4
- NO DISPLAY? pinentry-curses
Change the mapper path using a hash of the tomb file path,
making it unique and reproducible to check if tomb is in use.
Check happens inside the new render_mapper() function which is
executed right after the key file opening.
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.
