[pkg-cryptsetup-devel] Accessibility in the initramfs

[Andrew Pollock]

On Tue, Jun 02, 2009 at 07:05:35PM +0200, Jonas Meurer wrote:
> Hello, and sorry for the delayed response.
> 
> 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

regards

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20090620/2e26860b/attachment.pgp>