[pkg-cryptsetup-devel] any reason why askpas blocks all signals?
Christoph Anton Mitterer
calestyo at scientia.net
Mon Oct 11 21:56:59 BST 2021
Hey again.
(I took the liberty to add David Härdeman and Jonas Meurer to CC, who
have made the most commits on askpass,... maybe they can help me to
clarify why signals were blocked in askpass in the first place. See [0]
for the original thread.)
Okay turns out that actually there are some issues for my use case
(that is calling askpass with coreutils' timeout ahead):
1) Just cosmetic, since timeout has to use KILL for killing, a nasty
"Killed" would be printed (unless askpass is still in reading mode,
where ECHO is disabled).
2) When killed while askpass is reading the line, then the terminal's
ECHO is never re-enabled, so one has a broken terminal and has to call
reset.
Still something I could work around (more or less cleanly) by calling
stty echo...
3) There's a remote chance that the KILL is sent while the passphrase
is just being printed to stdout.
AFAIU, if this key is used directly for key derivation and that used on
a plain dm-crypt device (and there is noch checking of it's content)...
this could mean data corruption.
I've made a MR which adds some signal handling:
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/merge_requests/26
The idea is basically, that everything is kept blocked, until just
before the reading phase of all the methods... and blocked again, after
that.
I checked it for the console method and there it seems to do it's job.
But I cannot easily check it for the other methods.
As written before, I don't know why signals were blocked in the first
place, but if the only reason was also the partial passphrase
possibility, we could also just move the whole blocking of signals down
to the place before the passphrase is printed.
Cheers,
Chris.
[0] https://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/2021-October/009211.html
More information about the pkg-cryptsetup-devel
mailing list