[pkg-cryptsetup-devel] Bug#537842: Accessibility (beep) support in cryptdisks/cryptroot

[Jonas Meurer]

Package: cryptsetup
Version: 2:1.0.7~rc1-2
Severity: wishlist

Hello again,

On 20/06/2009 Andrew Pollock wrote:
> On Tue, Jun 02, 2009 at 07:05:35PM +0200, Jonas Meurer wrote:
> > On 27/02/2009 Andrew Pollock wrote:
> > > We've got a blind user, and we've modified the cryptroot initramfs stuff so
> > > that it issues a two-tone beep when the password prompt (for disk
> > > encryption) is displayed, and another two-tone beep after the disk is
> > > successfully decrypted.
> > > 
> > > We've made these changes against cryptsetup 1.0.5-2 that's in Ubuntu 8.04,
> > > in such a way as they can be opt-out by default, and opted in by a config
> > > file in /etc/initramfs-tools/conf.d
> > > 
> > > We'd like to get the changes back in upstream so we don't have to keep
> > > maintaining them. It means for us, we'd just opt-in via the configuration
> > > file, but by default it wouldn't beep. The benefit for Debian: support for
> > > blind users with disk encryption at early boot.
> > 
> > that indeed would be a great benefit for debian. please provide any
> > patches that you have.
> > 
> > > It looks like 1.0.6 is a bit different, notably the password prompting seems
> > > to be unified into /lib/cryptsetup/askpass regardless of whether a boot
> > > splash is used or not. That simplifies things and complicates things at the
> > > same time.
> > 
> > askpass now is the prefered method to prompt for passwords. it even may
> > be used for different passphrase prompts that don't correspond to
> > cryptsetup in the future.
> > 
> > > I'm happy to provide a patch, my main question is are you okay with
> > > askpass.c calling out to the beep binary from the beep package (this would
> > > introduce a dependency on the beep package), or do we have to embed beep
> > > functionality directly into askpass.c?
> > 
> > I would prefer to not introduce any direct dependencies for askpass.
> > instead a small beep function should be provided in askpass.c directly.
> > 
> 
> So I've just put some more thought into this. Here's the problem:
> 
> the way we're currently implementing the audible prompts are as follows:
> 
> 1) the user receives a two-tone beep when the password prompt is displayed
> 
> 2) the user receives a (different) two-tone beep when the encrypted device
> is successfully decrypted
> 
> If they get their password wrong, they receive the same two-tone beep as is
> emitted at step 1. This continues until they get their password right. When
> the user hears the second type of two-tone beep, they know everything is in
> order and the system is continuing to boot.
> 
> So we've got an intern who's essentially patched (1) above into askpass.c,
> but of course askpass.c is merely prompting for the password. In order to
> implement (2), there's still the need to emit a beep outside of askpass,
> which at this point is going to introduce a dependency on the beep binary I
> think.
> 
> Do you have any suggestions or see any alternatives? I'd think at this point
> if the beep binary is still necessary in the initramfs for the
> post-decrypted beep, it makes no sense to go embedding it inside askpass.c

I see the problem. And I'm not sure what to do about it yet, as I don't
want do add yet another initramfs dependency for cryptroot.

But maybe for now the best is to use the beep binary directly and check
for both existance of the binary and a 'beep' crypttab option in askpass,
cryptroot initramfs script and initscript before actually invoking it.

the cryptroot initramfs hook could check for the beep crypttab option
and only add the beep binary to initramfs in that case.

that way the default initramfs will not differ except the few extra
lines of code that check for and invoke beep.

greetings,
 jonas

PS: I reported that as wishlist bugreport to not forget about it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20090721/5919fa03/attachment.pgp>