GNU bug report logs - #38341
webauthn support?

Previous Next

To reply to this bug, email your comments to 38341 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Chris Marusich <cmmarusich <at> gmail.com>
To: Jack Hill <jackhill <at> jackhill.us>
Cc: Mark H Weaver <mhw <at> netris.org>, bug-gnuzilla <at> gnu.org
Subject: Re: webauthn support?
Date: Fri, 22 Nov 2019 22:14:30 -0800

[Message part 1 (text/plain, inline)]

Chris Marusich <cmmarusich <at> gmail.com> writes:

> I have a non-Guix GNU/Linux machine with Firefox, on which this
> problem does not occur, and I am able to log in correctly using my
> token (in Firefox).  I will try building IceCat 68 from source
> manually on that distribution.

I have successfully built IceCat using the Guix preview source (guix
build -S icecat) on a foreign GNU/Linux distro.  Things I noticed:

- When IceCat 68 is built from source on this foreign distro (without
  using any software from Guix to do the build), the built IceCat 68
  works.  The "Unknown U2F Error" does not occur.  This means that the
  system is configured correctly to allow me to use my security token,
  and IceCat is built correctly to use it.

- However, on the same foreign distro, when I install IceCat 68 from
  Guix, it doesn't work.  I get an "Unknown U2F Error".

- Reminder: Firefox also works on this foreign distro.  The "Unknown U2F
  Error" does not occur.

This suggests a bug in the Guix IceCat 68 packaging, but not the IceCat
68 source built by Guix.  For example, perhaps the Guix package
definition for IceCat 68 lacks a required runtime dependency for this
use case.  I will see if I can figure it out.  I think I will look into
the configuration/build logs/logic to see if we're missing a dependency
that is required for webauthn, U2F, PKCS11, or some other hardware token
thing.  I also think it might be productive to experiment using strace
to see if I can determine any differences in what's going on between the
good case and the bad case.  If anyone has any advice about how to
determine what code is actually emitting the "Unknown U2F Error", that
would really help me narrow down the possibilities quite a bit.

-- 
Chris

[signature.asc (application/pgp-signature, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jack Hill <jackhill <at> jackhill.us>
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: Mark H Weaver <mhw <at> netris.org>, bug-gnuzilla <at> gnu.org
Subject: Re: webauthn support?
Date: Sat, 23 Nov 2019 11:10:22 -0500 (EST)

[Message part 1 (text/plain, inline)]

On Fri, 22 Nov 2019, Chris Marusich wrote:

> Chris Marusich <cmmarusich <at> gmail.com> writes:
> I have successfully built IceCat using the Guix preview source (guix
> build -S icecat) on a foreign GNU/Linux distro.  Things I noticed:
>
> - When IceCat 68 is built from source on this foreign distro (without
>  using any software from Guix to do the build), the built IceCat 68
>  works.  The "Unknown U2F Error" does not occur.  This means that the
>  system is configured correctly to allow me to use my security token,
>  and IceCat is built correctly to use it.
>
> - However, on the same foreign distro, when I install IceCat 68 from
>  Guix, it doesn't work.  I get an "Unknown U2F Error".
>
> - Reminder: Firefox also works on this foreign distro.  The "Unknown U2F
>  Error" does not occur.

Great work. What dependencies did you have to provide on the non-Guix 
system?

[…]
> If anyone has any advice about how to determine what code is actually 
> emitting the "Unknown U2F Error", that would really help me narrow down 
> the possibilities quite a bit.

I don't know if this will be helpful, but as I understand webauthn, 
browsers provide a new JavaScript API for interacting with security 
tokens. I suspect that the error is being generated some code the browser 
calls a JavaScript program it has loaded calls that API. The text may not 
be in the IceCat source, but presented by the JavaScript program in 
response to and error in its API call. I was thinking, but haven't had the 
time, to set up my own webauthn-using app, so I can control the 
JavaScript.

That's my best guess at least, but it could be wrong, so don't let me lead 
you astray :)

Best,
Jack

Message #11 received at 38341 <at> debbugs.gnu.org (full text, mbox):

From: Chris Marusich <cmmarusich <at> gmail.com>
To: 38341 <at> debbugs.gnu.org
Cc: Mark H Weaver <mhw <at> netris.org>, Jack Hill <jackhill <at> jackhill.us>
Subject: Re: webauthn support?
Date: Sun, 01 Dec 2019 21:46:43 -0800

[Message part 1 (text/plain, inline)]

Hi Jack and Mark,

It seems I unintentionally created this new bug report in Debbugs
(38341) by emailing bug-gnuzilla <at> gnu.org.  Sorry about that; I'll try
not to do that again going forward.

Since the bug report was created in the middle of our discussion, I'll
reproduce some of the original discussion so the context is clear.

The original report was from Jack Hill:

https://lists.gnu.org/archive/html/bug-gnuzilla/2019-10/msg00013.html

Jack Hill <jackhill <at> jackhill.us> writes:

> Hi IceCat folks,
>
> What's the status of webauthn support? When using firefox esr 68 on
> Debian or ungoogled-chromium on GNU Guix, sites that use webauthn seem
> to work: the led color changes on my usb token, I press the button,
> and the webauthn exchange happens. However using icecat
> 68.2.0-guix0-preview1 (thanks Mark!), the led on my token never
> changes color and sites either report that step to have failed or say
> it is not supported by my browser.

I replied describing a similar problem:

https://lists.gnu.org/archive/html/bug-gnuzilla/2019-11/msg00029.html

Chris Marusich <cmmarusich <at> gmail.com> writes:

> To reiterate, the specific problem I see is this.  I go to a website
> that uses two-factor authentication.  I know it works - with my specific
> YubiKey token - because the website works fine in Firefox on other
> systems.  But in IceCat 68, when I try to log in, I get a pop-up (modal?
> not sure what the proper term is) with this error:
>
> "Unknown U2F Error"
>
> I'm typing that from memory, so it might actually be "Unknown U2F
> Exception"; I'm not 100% sure.  But it's definitely a little window that
> appears, which says something along those lines, with no additional
> information.  Is this the same problem you see, Jack?
>
> I have double checked a lot of things.  For example, I double checked
> the following on my Guix system:
>
> - The udev rules from libu2f-host are installed.
>
> - My YubiKey token is usable via other mechanisms:
>
>      - I can load the SSH key stored within it via "ssh-add -s", using
>        the OpenSC PKCS11 library, and I can SSH into machines using it.
>
>      - I can access the YubiKey via tools such as "ykinfo" and
>        "yubico-piv-tool".
>
> - In about:config, security.webauth.u2f is set to true.
>
> The big issue for me is that I have no idea how to investigate further.
> I really wish I could figure out how to extract more information from
> IceCat, so I could figure out precisely where the problem is occurring,
> and follow the trail of bread crumbs from there.  I have even tried
> grepping the IceCat source (from "guix build -S icecat") for the string
> "Unknown U2F Error", but it yields no results.  If anyone here can
> provide advice on how to collect more information about what direction
> the problem is coming from, I'd really appreciate it.
>
> Since I can't find references to that error message in the IceCat 68
> source, I'm thinking the error probably comes from something else.
> Maybe a dependency that IceCat is calling out to, or perhaps even a
> JavaScript library.  Judging by the URLs IceCat loads, I think it might
> be using some version of the following file to do the U2F logic (IceCat
> loaded a file named "fidou2f.js", which is why I think this):
>
> https://github.com/rcdevs/openotp_authentication_owncloud/blob/master/js/fidou2f.js
>
> Any tips to debug this would be welcome, even if it's just a link to
> some tutorial on how to debug JavaScript that you find useful.  I'm a
> total newbie when it comes to debugging JavaScript in IceCat (Firefox).
> I'm not even sure the error is coming from this JavaScript, anyway.
> Tips on how to debugging the non-JS portions of my problem seem more
> helpful at this point in time, honestly, but any tips would be great.
>
> Finally, I have a non-Guix GNU/Linux machine with Firefox, on which this
> problem does not occur, and I am able to log in correctly using my token
> (in Firefox).  I will try building IceCat 68 from source manually on
> that distribution.

So, that is the context for the current bug report.

Jack Hill <jackhill <at> jackhill.us> writes:

> What dependencies did you have to provide on the non-Guix system?

I build IceCat on Ubuntu 19.  I basically did this:

Build the source:

  guix pull --commit=c07bc1d2ca1029b89c807cc6e62e4c099aebedbd
  guix build -S icecat

This produces the following file:

  /gnu/store/zw9rrbash7d484f2jnash79fbidxw07n-icecat-68.2.0-guix0-preview3.tar.xz

That file's SHA512 hash is:

  4cb509f59d2141e1311c054ed7df200597a068dbd868ed043053f4dce6429f199a4aa56a99917e57bfa60ab9f1bd5d1b0af26bdf283a4d65532cc285e9d5e83f

Install the following packages using apt (e.g., "apt install cargo"):

  autoconf2.13
  build-essential
  cargo
  clang
  curl
  libdbus-glib-1-2
  libgtk-2-0
  libgtk2.0-dev
  libpango1.0-0
  libpango1.0-dev
  libpulse-dev
  nasm
  nodejs
  rustc
  yasm

Using the apt-provided cargo, install cbindgen:

  cargo install cbindgen

Extract the
zw9rrbash7d484f2jnash79fbidxw07n-icecat-68.2.0-guix0-preview3.tar.xz
file somewhere.  Then build IceCat by running commands similar to this:

  mkdir objdir
  cd objdir
  srcdir=../icecat-68.2.0-guix0-preview3
  $srcdir/configure --with-l10n-base=$srcdir/l10n
  make

Hopefully, this works for you.  It took me a couple days of on-and-off
trial and error to get everything right.

In particular, it seems you need to use the apt-provided cargo to
install cbindgen.  I tried installing cargo, rustc, and cbindgen using
apt, but the build will failed because cbindgen was too old.  I also
tried installing cargo and rustc via rustup, and then I used the
rustup-provided cargo to install cbindgen, but the build failed for
mysterious reasons while attempting to compile xpcom_macros.  When I
tried installing cargo and rustc via apt, and then used the apt-provided
cargo to install cbindgen, the build succeeded.  My guess is that rustup
gave me a rust that was too recent, so it broke the build.

Various other problems occurred before I successfully built IceCat.
Mostly they seemed to be missing dependencies, or dependencies using the
wrong version.  For example, in addition to the rust confusion in the
previous paragraph, the IceCat build system expects to use autoconf2.13
specifically.  I originally tried using Ubuntu's default autoconf
package, but it failed.  You'll probably need to repeat the "configure"
and "make" invocations a few times to flush out such errors.  Based on
my notes, it seems I invoked "configure" at least 18 times, and "make"
at least 5 times.  Hopefully if you install the dependencies like I
suggest above, you won't have to go through quite so many iterations.

Of course, if you use Guix, you won't have to go through that pain! :-)

>> If anyone has any advice about how to determine what code is
>> actually emitting the "Unknown U2F Error", that would really help me
>> narrow down the possibilities quite a bit.
>
> I don't know if this will be helpful, but as I understand webauthn,
> browsers provide a new JavaScript API for interacting with security
> tokens. I suspect that the error is being generated some code the
> browser calls a JavaScript program it has loaded calls that API. The
> text may not be in the IceCat source, but presented by the JavaScript
> program in response to and error in its API call. I was thinking, but
> haven't had the time, to set up my own webauthn-using app, so I can
> control the JavaScript.

Jack, does your error come with a specific message of any kind?  Does it
occur when using the Guix-built IceCat preview?  Does it occur when you
build it manually on a non-Guix GNU/Linux system, following a procedure
like the one I describe above?

-- 
Chris

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 38341 <at> debbugs.gnu.org (full text, mbox):

From: Jack Hill <jackhill <at> jackhill.us>
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: Mark H Weaver <mhw <at> netris.org>, 38341 <at> debbugs.gnu.org
Subject: Re: webauthn support?
Date: Mon, 2 Dec 2019 17:11:29 -0500 (EST)

On Sun, 1 Dec 2019, Chris Marusich wrote:

>> I'm typing that from memory, so it might actually be "Unknown U2F
>> Exception"; I'm not 100% sure.  But it's definitely a little window that
>> appears, which says something along those lines, with no additional
>> information.  Is this the same problem you see, Jack?

Yes, this is a similar to what I see.

On one site, I see this message: "Security key authentication failed."
On another site, I don't get an error message, but can't make it past the 
"Security device authentication page".

The hardware token I'm using is a solokey, which as an LED that changes 
color when the computer has asked it to do something and I need to press 
the button. When webauthn doesn't work the LED color never changes.

> Jack, does your error come with a specific message of any kind?  Does it
> occur when using the Guix-built IceCat preview?  Does it occur when you
> build it manually on a non-Guix GNU/Linux system, following a procedure
> like the one I describe above?

The error occurs using the Guix-built Icecat preview. I have tried 
building the preview by hand on Fedora 31, but have not gotten it to 
successfully build yet.

One error seems to be:

"""
Some errors have detailed explanations: E0119, E0204.
For more information about an error, try `rustc --explain E0119`.
error: could not compile `style`.
"""

I tried to follow your build instructions with rust and cargo from the (in 
this case) Fedora repositories, and cbindgen form `cargo install`. Perhaps 
the Fedora rust is too new?

"""
$ rustc  --version
rustc 1.39.0
"""

Some musings: I didn't see any u2f-related dependencies to satisfy before 
starting the build (I wondered if the Guix package was missing an input). 
The C++ compiler being used was clang++. I think g++ is being used on 
Guix.

Best,
Jack

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.