Mozilla Firefox

Ubuntu build of Firefox lacks Google OAuth ID, prevents contact import in Hello

Bug #1401402 reported by Eugene Crosser
44
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Won't Fix
Medium
firefox (Ubuntu)
Fix Released
Medium
Chris Coulson

Bug Description

Starting from verstion 34.0, Firefox, including Ubuntu build thereof, supports WebRTC based voice/video communication feature named "Hello":
https://support.mozilla.org/en-US/kb/firefox-hello-make-receive-calls-without-account

This feature works in Ubuntu build, except importing contacts from Google account:
https://bugzilla.mozilla.org/show_bug.cgi?id=1106854
Attempt to import contacts results in this Google error page:
====
401. That’s an error.

Error: invalid_client

The OAuth client was not found.
Request Details

    scope=https://www.google.com/m8/feeds
    response_type=code
    redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto
    client_id=no-google-oauth-api-clientid
====

Apparently, for the import feature to work, the build needs to include Google OAuth Client ID. The process is discussed here:
https://wiki.mozilla.org/Loop/OAuth_Setup

Apparently, Ubuntu's build of Firefox does not include this Client ID.
Please consider adding it. Hopefully then "Hello" will be fully functional, including contacts import.

Revision history for this message
In , HoracioDos (horaciodos) wrote :

Created attachment 8531307
Screenshot - 021214 - 17:42:41.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141127111021

Steps to reproduce:

I enabled firefox hello in linux mint 17 - Qiana and tried to import contacts from Google

Actual results:

A new window opens indicating an error

401. That’s an error.
Error: invalid_client
The OAuth client was not found.
Request Details
    scope=https://www.google.com/m8/feeds
    response_type=code
    redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto
    client_id=no-google-oauth-api-clientid
That’s all we know.

Expected results:

Contacts should be imported from Google.

Revision history for this message
In , Jorge Martínez López (jorgeml) wrote :

Same thing for me (Firefox 34.0 with Fedora 21).

Revision history for this message
In , jack gurulian (jack-gurulian) wrote :

Same for me on Ubuntu 14.10 / Firefox 34.

Revision history for this message
In , Adam-nostrum (adam-nostrum) wrote :

This looks like an issue with the downstream OAuth setup. The basic steps are here: https://wiki.mozilla.org/Loop/OAuth_Setup

Lawrence: do you know who our contacts are at our downstream projects? We need to reach out to them and let them know about this new requirement on their builds...

Revision history for this message
In , Lmandel (lmandel) wrote :

(In reply to Adam Roach [:abr] from comment #3)
> Lawrence: do you know who our contacts are at our downstream projects? We
> need to reach out to them and let them know about this new requirement on
> their builds...

Lukas - Do you have a list of downstream projects and contacts?
Sylvestre - You're plugged in to some of the Linux distros. Can you help here?

Revision history for this message
In , Lmandel (lmandel) wrote :

catlee - Does releng maintain a list of downstream projects and do you have contacts?

Revision history for this message
In , Eugene Crosser (crosser) wrote :

I've opened this ticket in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1401402

Revision history for this message
In , Sledru (sledru) wrote :

Usually, the way to do that is to update the configure to add a check on this. It will notify packagers about that.
n-i Mike for Debian (and our build system) in case he can help.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Sigh... one more API ID that distros can't use and that breaks features... We should probably make all the associated flags (not only this particular one, but all of them) fail to build when building with --enable-release (which distros should be using)... because failing for local developers build is not going to pan-out. Then the choice whether to add an api key or not is in the maintainer's hands, so even if they decide not use the API key, at least they are aware of it. Although I could see this as annoying... I don't know.

With my Debian hat on, iirc, most if not all of those API IDs can't be used in distros because they have to be "hidden". (that's why they're not in mozilla-central to begin with)

Now, for this specific case, I'd advise removing the import feature instead of having weird errors when Firefox doesn't have the corresponding key.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Lsblakk (lsblakk) wrote :

Afaik there is not a list of downstream projects - would be great to have one though.

Revision history for this message
In , Mozilla (mozilla) wrote :

oauth keys are a pain indeed for Linux distributions and in case of openSUSE cannot added at all since it's not possible to keep the keys secret as the whole build process and sources are completely open. I agree with Mike that the feature should be hidden/disabled if no oauth api keys are configured/built in.

Revision history for this message
In , Adam-nostrum (adam-nostrum) wrote :

(In reply to Mike Hommey [:glandium] from comment #8)
> Now, for this specific case, I'd advise removing the import feature instead
> of having weird errors when Firefox doesn't have the corresponding key.

I agree that the current behavior isn't okay. I've opened a bug to do something better, with room to discuss what "better" looks like (Bug 1110508)

Revision history for this message
In , Adam-nostrum (adam-nostrum) wrote :

(In reply to Sylvestre Ledru [:sylvestre] from comment #7)
> Usually, the way to do that is to update the configure to add a check on
> this. It will notify packagers about that.

As we were adding this new OAuth key to the build system, we did a lot of digging around for "what had been done before," including talking to releng pretty extensively and close examination of similar code landings (e.g., build system support for our geoloc API key). This didn't come up.

I know we're not trying to encourage a proliferation of secret material here, but for those cases in which we don't have a choice (like this one), it would probably be a Good Thing if we had a wiki page that captured all the collected lore on Best Current Practices.

Sylvestre: You seem to have some knowledge here. Do you have enough of an understanding of what Mozilla-specific steps need to take place in these kinds of cases to take a first stab at such a page? Or were you speaking about project behavior in general rather than from a Moz perspective?

Revision history for this message
In , Sledru (sledru) wrote :

I am sorry but I was talking in a more general perspective. However, Mike, in comment #8, explained that issue.

Revision history for this message
In , Lmandel (lmandel) wrote :

(In reply to Lukas Blakk [:lsblakk] use ?needinfo from comment #9)
> Afaik there is not a list of downstream projects - would be great to have
> one though.

To follow up on this, I've given myself a Q1 goal to create this list. If you're redistributing Firefox, please ping me as I'll be collecting distros and trying to find at least one contact for each.

Revision history for this message
In , Sescalante (sescalante) wrote :

requires outreach and private key for contact imports. will require working with folks who are just going to be hard to get through holidays.

will loop back with catlee based on comment

Chris Coulson (chrisccoulson)
Changed in firefox (Ubuntu):
importance: Undecided → Medium
assignee: nobody → Chris Coulson (chrisccoulson)
Revision history for this message
In , Standard8 (standard8) wrote :

*** Bug 1121881 has been marked as a duplicate of this bug. ***

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

The next Firefox update on Ubuntu will have this fixed

Changed in firefox (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
In , Rhubscher (rhubscher) wrote :

Thanks Chris.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to Chris Coulson from comment #17)
> The next Firefox update on Ubuntu will have this fixed

How are you fixing this?

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

We have our own OAuth ID + key (and Google API key for geolocation / safe-browsing) used for both Firefox and Chromium. They're not hidden, and it doesn't look like we're the only distribution doing that (I found public keys in Gentoo as well)

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

If every distro uses a different key, then Google can distinguish which distro users are using. Wouldn't that qualify as a privacy breach? IIRC, we explicitely don't send the google cookie for safebrowsing. If we don't do that for geoloc, that would seem like a bug. OTOH, they can probably correlate with the google cookie the user is already using in the same browser... So while using a different key means more information available to google, is it actually making things worse than they already are?

That being said, doesn't shipping those keys in the source packages in distros breach their TOS?

Revision history for this message
In , Felipe Lerena (lipe) wrote :

Same here on the ppa ubuntu build
36.0a2 (2014-12-15)

Revision history for this message
In , Saravanakumar K (akk-saravanakumar) wrote :

Same for me,
Ubuntu 14.10, (2015-feb-25)

Revision history for this message
In , Sledru (sledru) wrote :

Tracking as it is a user facing error for our GNU/Linux users (but this can indeed wait for 38).

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 36.0+build2-0ubuntu0.14.10.4

---------------
firefox (36.0+build2-0ubuntu0.14.10.4) utopic-security; urgency=medium

  * New upstream stable release (FIREFOX_36_0_BUILD2)
    - see USN-2505-1

  * Refresh patches
    - update debian/patches/unity-menubar.patch
    - update debian/patches/ubuntu-ua-string-changes.patch
    - update debian/patches/dont-include-hyphenation-patterns.patch
    - update debian/patches/dont-override-general-useragent-locale.patch
  * Don't clone the nightly profile from the default profile at startup
    - update debian/firefox.sh.in
  * Don't use --with-app-basename to create the co-installable nightly build
    as it's not useful anymore, and changing the application name to
    "Firefox-Trunk" has always been problematic for code / addons that check
    the appname. Continue to use --with-app-name as before (which just changes
    the install name and the remoting name), and add a patch to introduce
    --with-app-profile, which allows us to change the profile location
    - update debian/build/rules.mk
    - update debian/build/config.mk
    - update debian/config/mozconfig.in
    - update debian/rules
    - add debian/patches/support-coinstallable-trunk-build.patch
    - add debian/patches/set-prgname-to-remoting-name.patch
    - update debian/patches/series
  * Install the gmp-clearkey directory
  * Add Google OAuth ID so contact import for Hello works (LP: #1401402)
  * Add Uzbek language pack
  * Add patch from Bugzilla to implement non-Skia fallback for unaccelerated
    rendering of 3D transforms to fix a build failure on platforms where Skia
    is not supported
    - add debian/patches/add-non-skia-fallback.patch
    - update debian/patches/series
  * Backport patch to fix a build failure in IonMonkey on platforms without
    a codegen
    - add debian/patches/fix-ion-ftbfs.patch
    - update debian/patches/series
  * Backport patch to fix a build failure in some unified builds
    - add debian/patches/fix-unified-ftbfs.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Mon, 23 Feb 2015 13:59:59 +0000

Changed in firefox (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 36.0+build2-0ubuntu0.12.04.5

---------------
firefox (36.0+build2-0ubuntu0.12.04.5) precise-security; urgency=medium

  * New upstream stable release (FIREFOX_36_0_BUILD2)
    - see USN-2505-1

  * Refresh patches
    - update debian/patches/unity-menubar.patch
    - update debian/patches/ubuntu-ua-string-changes.patch
    - update debian/patches/dont-include-hyphenation-patterns.patch
    - update debian/patches/dont-override-general-useragent-locale.patch
  * Don't clone the nightly profile from the default profile at startup
    - update debian/firefox.sh.in
  * Don't use --with-app-basename to create the co-installable nightly build
    as it's not useful anymore, and changing the application name to
    "Firefox-Trunk" has always been problematic for code / addons that check
    the appname. Continue to use --with-app-name as before (which just changes
    the install name and the remoting name), and add a patch to introduce
    --with-app-profile, which allows us to change the profile location
    - update debian/build/rules.mk
    - update debian/build/config.mk
    - update debian/config/mozconfig.in
    - update debian/rules
    - add debian/patches/support-coinstallable-trunk-build.patch
    - add debian/patches/set-prgname-to-remoting-name.patch
    - update debian/patches/series
  * Install the gmp-clearkey directory
  * Add Google OAuth ID so contact import for Hello works (LP: #1401402)
  * Add Uzbek language pack
  * Add patch from Bugzilla to implement non-Skia fallback for unaccelerated
    rendering of 3D transforms to fix a build failure on platforms where Skia
    is not supported
    - add debian/patches/add-non-skia-fallback.patch
    - update debian/patches/series
  * Backport patch to fix a build failure in IonMonkey on platforms without
    a codegen
    - add debian/patches/fix-ion-ftbfs.patch
    - update debian/patches/series
  * Backport patch to fix a build failure in some unified builds
    - add debian/patches/fix-unified-ftbfs.patch
    - update debian/patches/series
  * Backport 2 changesets from libvpx git repo to fix an Arm-specific ICE
    on older GCC versions
    - add debian/patches/fix-vp8-ice-on-older-toolchains.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Mon, 23 Feb 2015 14:04:31 +0000

Changed in firefox (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 36.0+build2-0ubuntu0.14.04.4

---------------
firefox (36.0+build2-0ubuntu0.14.04.4) trusty-security; urgency=medium

  * New upstream stable release (FIREFOX_36_0_BUILD2)
    - see USN-2505-1

  * Refresh patches
    - update debian/patches/unity-menubar.patch
    - update debian/patches/ubuntu-ua-string-changes.patch
    - update debian/patches/dont-include-hyphenation-patterns.patch
    - update debian/patches/dont-override-general-useragent-locale.patch
  * Don't clone the nightly profile from the default profile at startup
    - update debian/firefox.sh.in
  * Don't use --with-app-basename to create the co-installable nightly build
    as it's not useful anymore, and changing the application name to
    "Firefox-Trunk" has always been problematic for code / addons that check
    the appname. Continue to use --with-app-name as before (which just changes
    the install name and the remoting name), and add a patch to introduce
    --with-app-profile, which allows us to change the profile location
    - update debian/build/rules.mk
    - update debian/build/config.mk
    - update debian/config/mozconfig.in
    - update debian/rules
    - add debian/patches/support-coinstallable-trunk-build.patch
    - add debian/patches/set-prgname-to-remoting-name.patch
    - update debian/patches/series
  * Install the gmp-clearkey directory
  * Add Google OAuth ID so contact import for Hello works (LP: #1401402)
  * Add Uzbek language pack
  * Add patch from Bugzilla to implement non-Skia fallback for unaccelerated
    rendering of 3D transforms to fix a build failure on platforms where Skia
    is not supported
    - add debian/patches/add-non-skia-fallback.patch
    - update debian/patches/series
  * Backport patch to fix a build failure in IonMonkey on platforms without
    a codegen
    - add debian/patches/fix-ion-ftbfs.patch
    - update debian/patches/series
  * Backport patch to fix a build failure in some unified builds
    - add debian/patches/fix-unified-ftbfs.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Mon, 23 Feb 2015 14:03:16 +0000

Changed in firefox (Ubuntu):
status: Fix Committed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.