Mandos-client fails decode

[Teddy Hogeborn]

Dick Middleton <dick at lingbrae.com> writes:

> > > I'm now using mandos-client 1.7.3 on a Stretch system.
> > >
> > > If I test mandos-client fetching passcode it is successful.
> > > However at boot time it consistently fails to unlock the disk.  It
> > > reports:
> > >
> > > bad gpme_op_decode: GPME decryption failed
> > 
> > I don't know what that could be; you say it's working when you run
> > mandos-client on a running system, but fails in the initramfs?
> > What does the "gpgconf" command output?
>
> gpg:GPG for OpenPGP:/usr/bin/gpg2

OK, so it uses GnuPG 2; good to know.

> > What happens if you generate a new entry for the Mandos server's
> > /etc/mandos/clients.conf file by running "mandos-keygen --password
> > --force" on the client, install the entry in the server and restart
> > the Mandos server process?
>
> I'll get back to you. But this is a new install I did a couple of days
> ago.

In that case, it shouldn't matter.

> > > When testing mandos-client on this slow machine it can take up to
> > > 3mins to get the passphrase.  During this time it is running at
> > > 100% cpu.
>
> It's true I don't invoke with --dhparams option.  But it sure makes
> difference.  More like 5s.
>
> Where is the default location for the file?  Installer puts it in
> /etc/keys/mandos/dhparams.pem ?
>
> It's got 600 permissions and owned by root.

Yes.  It's not actually used from there; it's copied into the initramfs
and used from there at boot, just like the key files.

When the system boots, a script (part of the Debian packaging) will look
and see if any dhparams.pem file exists.  If the file exists, the script
will add a parameter to the plugin-runner's config file to in turn run
mandos-client with the --dh-params= option.  I wonder why it apparently
does not do so in your case?

> But, on my desktop (amd64) it segfaults when dh-params option given:
> 
> Mandos plugin mandos-client: Unlinking "/tmp/mandosw2gt4j/S.gpg-agent"
> Mandos plugin mandos-client: Unlinking "/tmp/mandosw2gt4j/private-keys-v1.d"
> Mandos plugin mandos-client: Unlinking
> "private-keys-v1.d/13DBD26E0DC10CE96543319E414937C7EEC55184.key"
> Mandos plugin mandos-client: Unlinking
> "private-keys-v1.d/CBCE568BDECE4A0147CA114196184F834909A49E.key"
> Mandos plugin mandos-client: Unlinking "/tmp/mandosw2gt4j/pubring.kbx"
> Mandos plugin mandos-client: Unlinking "/tmp/mandosw2gt4j/pubring.kbx~"
> Mandos plugin mandos-client: Unlinking "/tmp/mandosw2gt4j/trustdb.gpg"
> Floating point exception

That is very strange.  At that point in the program, it re-sends a
signal to itself (and thereby exits) if it had previously been
terminated by a signal, like SIGTERM for instance.  The strange thing
is, in your case it seems to send the SIGFPE (Floating point exception)
signal, but the program *shouldn't have caught* that signal!  The
program only installs a signal handler for SIGINT, SIGHUP, and SIGTERM.
All other fatal signals *should* have terminated the program
*immediately*, not apparently wait until the end.  (If a *non*-fatal
signal was received, it should simply have been ignored.)

I am mystified.

Just to be clear, the program itself doesn't do any significant floating
point operations, and neither do any libraries it uses have any reason
for doing so.  (Additionally, the GPGME library runs GnuPG in a
*subprocess*, which isolates the main program from any floating point
errors which GnuPG itself could conceivably have.)

/Teddy Hogeborn

-- 
The Mandos Project
http://www.recompile.se/mandos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20160305/43b5c7c8/attachment.sig>