Firefox desktop download pages for Linux should include links to software repositories where available

NEW
Unassigned

Status

--
enhancement
7 years ago
6 years ago

People

(Reporter: me, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
Currently, the download pages for Firefox, Beta, and Aurora use UA sniffing to pick the right OS version to present for download. GNU/Linux users are only presented with binary downloads on these and the Nightly download pages. These binary downloads are only available over insecure HTTP (bug #358384). The stub installer will not be available for these operating systems.

These binary downloads & their updates are not consistent with the way that the user's OS securely manages software and updates.

Instead, when a user is running an operating system with an effective package manager, they should also be presented with the option to choose either the current insecure binary download, or a secure package repository compatible with their OS. This is especially valuable since we already have software repositories all versions of Firefox and Thunderbird for Ubuntu and Debian:

- <https://launchpad.net/~mozillateam>
- <https://launchpad.net/~ubuntu-mozilla-daily>
(Reporter)

Updated

7 years ago
See Also: → bug 358384

Comment 1

7 years ago
I think it might make sense to make the most simple stub installer possible - sorta like Google does with Chrome. Why not offer an rpm or deb that just installs things as expected, uses the package manager and adds the repos that users are expected to have? If anything, it means that using HTTP at that point isn't as big of a deal.

Denial of updates is still an issue, obviously. :(

Comment 2

7 years ago
I thought you were talking about Linux, and suddenly you talk Ubuntu... :P
(As that distro doesn't talk about Linux anywhere on their website, they seem to not consider themselves being Linux, or so you could argue.)

That aside, most distro packages are being done later than our builds, and they feature different build IDs than our own builds, and so are less helpful when e.g. analyzing crash reports coming from those. And while on that topic, their crash reports usually (intentionally) don't come with the "correct" channel set, so we ignore them in our crash stats completely, at least for non-release builds.

Also, security is a bit of a lame excuse, as the stub installer comes over the same insecure HTTP (and once you launch that, it can download from wherever it wants), and AFAIK you can even access the downloads via https is wanted (not sure why that alone would give one more security, though) - and the updates done via our own update mechanism are fully secured, I heard arguments that our update channel is better secured than some Linus distro update mechanisms, actually.

Comment 3

7 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2)
> I thought you were talking about Linux, and suddenly you talk Ubuntu... :P
> (As that distro doesn't talk about Linux anywhere on their website, they
> seem to not consider themselves being Linux, or so you could argue.)

He specifically mentioned Debian; I mentioned debs and rpms.

> 
> That aside, most distro packages are being done later than our builds, and
> they feature different build IDs than our own builds, and so are less
> helpful when e.g. analyzing crash reports coming from those. And while on
> that topic, their crash reports usually (intentionally) don't come with the
> "correct" channel set, so we ignore them in our crash stats completely, at
> least for non-release builds.
> 

Why not release the builds you want people to use and that are properly packaged in a repository that is safe to use?

> Also, security is a bit of a lame excuse, as the stub installer comes over
> the same insecure HTTP (and once you launch that, it can download from
> wherever it wants),

The stub installer is specifically supposed to be provided over HTTPS.

> and AFAIK you can even access the downloads via https is
> wanted (not sure why that alone would give one more security, though)

is? Or if? I guess if?

> - and
> the updates done via our own update mechanism are fully secured, I heard
> arguments that our update channel is better secured than some Linus distro
> update mechanisms, actually.

I think you heard incorrectly. What taxonomy of attacks on updating/installing is being consulted here when you make that assertion?

Comment 4

7 years ago
(In reply to Tom Lowenthal [:StrangeCharm] from comment #0)
>  
> - <https://launchpad.net/~mozillateam>
> - <https://launchpad.net/~ubuntu-mozilla-daily>

Tom - how about a stub installer for Ubuntu that installs the right PPA for your Ubuntu platform, the right debian repo, etc?

Here's a very simple stub install for a modern Ubuntu:

{{{
#!/bin/bash
sudo add-apt-repository ppa:mozillateam/firefox-next
sudo apt-get update --fix-missing
sudo apt-get install -t ppa:mozillateam firefox
}}}

What is the canonical list of all such repos? It would be rather simple to write a stub installer for basically all Gnu/Linux distros where there are binary packages in repos, etc. Such a program could be inserted into the most simple and small of packages available over HTTPS for download and run at package install time.
(Reporter)

Comment 5

7 years ago
(In reply to Jacob Appelbaum from comment #4)
> Tom - how about a stub installer for Ubuntu that installs the right PPA for
> your Ubuntu platform, the right debian repo, etc?

Jake, I don't know what the right UX is for someone who wants to get/update Firefox through their package manager. A short (easy-to-serve-even-over-SSL) script that just adds the repos (& keys as applicable) and does the install seems pretty slick. On the other hand simply having text (served over SSL) stating the identities and keys for the repos would cost less to implement, and be more transparent & maintainable, and probably doesn't have much of a usability cost for the target demographic.

> What is the canonical list of all such repos?

I don't know. Hopefully, the download page can be.

---

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2)
> That aside, most distro packages are being done later than our builds, and
> they feature different build IDs than our own builds, and so are less
> helpful when e.g. analyzing crash reports coming from those. And while on
> that topic, their crash reports usually (intentionally) don't come with the
> "correct" channel set, so we ignore them in our crash stats completely, at
> least for non-release builds.

I'm not suggesting promoting distros' builds, but linking to Mozilla repositories of our own builds.
 
> Also, security is a bit of a lame excuse..., as the stub installer comes over
> the same insecure HTTP (and once you launch that, it can download from
> wherever it wants), and AFAIK you can even access the downloads via https is
> wanted (not sure why that alone would give one more security, though) - and
> the updates done via our own update mechanism are fully secured, I heard
> arguments that our update channel is better secured than some Linus distro
> update mechanisms, actually.

I'm not suggesting another stub installer, I'm suggesting text with the URIs and keys of the repositories, served over SSL like the rest of the download page.

Does that make sense?

Comment 6

7 years ago
(In reply to Tom Lowenthal [:StrangeCharm] from comment #5)
> Jake, I don't know what the right UX is for someone who wants to get/update
> Firefox through their package manager.

openSUSE has this 1-click-install thing that might do the right thing there, but not sure.

> I'm not suggesting promoting distros' builds, but linking to Mozilla
> repositories of our own builds.

Hmm, so we'd need to add build tooling to repackage our official builds into a few different distro packaging formats and offer a few different repos for them. Surely doable, but quite a bit of work for a really small amount of people it affects. Not sure if releng has the resources for that.

Comment 7

7 years ago
(In reply to Tom Lowenthal [:StrangeCharm] from comment #5)
> (In reply to Jacob Appelbaum from comment #4)
> > Tom - how about a stub installer for Ubuntu that installs the right PPA for
> > your Ubuntu platform, the right debian repo, etc?
> 
> Jake, I don't know what the right UX is for someone who wants to get/update
> Firefox through their package manager. A short (easy-to-serve-even-over-SSL)
> script that just adds the repos (& keys as applicable) and does the install
> seems pretty slick. 

I'm happy to write such an installer for Debian/Ubuntu. If it's best prototyped in bash or python, I'd be happy to do so.

>On the other hand simply having text (served over SSL)
> stating the identities and keys for the repos would cost less to implement,
> and be more transparent & maintainable, and probably doesn't have much of a
> usability cost for the target demographic.
> 

I'd say that downloading a .deb or .rpm and having it automate the process is very usable.

> > What is the canonical list of all such repos?
> 
> I don't know. Hopefully, the download page can be.

Sure! But who knows what would go there? :)

> 
> ---
> 
> (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2)
> > That aside, most distro packages are being done later than our builds, and
> > they feature different build IDs than our own builds, and so are less
> > helpful when e.g. analyzing crash reports coming from those. And while on
> > that topic, their crash reports usually (intentionally) don't come with the
> > "correct" channel set, so we ignore them in our crash stats completely, at
> > least for non-release builds.
> 
> I'm not suggesting promoting distros' builds, but linking to Mozilla
> repositories of our own builds.

It seems to make sense that if Ubuntu has Firefox - we would want to promote that unless it was a bad version of Firefox or something, no?

>  
> > Also, security is a bit of a lame excuse..., as the stub installer comes over
> > the same insecure HTTP (and once you launch that, it can download from
> > wherever it wants), and AFAIK you can even access the downloads via https is
> > wanted (not sure why that alone would give one more security, though) - and
> > the updates done via our own update mechanism are fully secured, I heard
> > arguments that our update channel is better secured than some Linus distro
> > update mechanisms, actually.
> 
> I'm not suggesting another stub installer, I'm suggesting text with the URIs
> and keys of the repositories, served over SSL like the rest of the download
> page.
> 

I guess my suggestion of a shell script is sorta a stub installer and I am suggesting it over just having text. But text is a good start and we're not there, obviously.

> Does that make sense?

Yep.

Comment 8

7 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #6)
> (In reply to Tom Lowenthal [:StrangeCharm] from comment #5)
> > Jake, I don't know what the right UX is for someone who wants to get/update
> > Firefox through their package manager.
> 
> openSUSE has this 1-click-install thing that might do the right thing there,
> but not sure.
> 

For openSUSE, I think that is probably the right answer.

> > I'm not suggesting promoting distros' builds, but linking to Mozilla
> > repositories of our own builds.
> 
> Hmm, so we'd need to add build tooling to repackage our official builds into
> a few different distro packaging formats and offer a few different repos for
> them. Surely doable, but quite a bit of work for a really small amount of
> people it affects. Not sure if releng has the resources for that.

In the simplest form, we'd just add text to point to what already exists.

In a slightly more complex form, I think it would require no rebuilding - we'd just add a tool to set up the right thing for the releases that already exist.

Comment 9

7 years ago
(In reply to Jacob Appelbaum from comment #7)
> It seems to make sense that if Ubuntu has Firefox - we would want to promote
> that unless it was a bad version of Firefox or something, no?

As I pointed out in comment #2, using the distro builds as opposed to ours creates several difficulties, one of which is that we don't get the kind of crash analysis of pre-releases we need as those builds (for good reasons) don't set our release channels as expected.
Another problem with those is that they usually apply some patches to their builds, and we want what we ship to be our own pristine code.

Comment 10

7 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9)
> (In reply to Jacob Appelbaum from comment #7)
> > It seems to make sense that if Ubuntu has Firefox - we would want to promote
> > that unless it was a bad version of Firefox or something, no?
> 
> As I pointed out in comment #2, using the distro builds as opposed to ours
> creates several difficulties, one of which is that we don't get the kind of
> crash analysis of pre-releases we need as those builds (for good reasons)
> don't set our release channels as expected.

Sure - that's why it makes sense to promote only the builds that are the option of last resort. As it stands now, I don't actually know if that's the case with my distro today - should I be installing some tar.gz or is the Ubuntu package OK? Is there an OK Mozilla produced Ubuntu package that is best?

> Another problem with those is that they usually apply some patches to their
> builds, and we want what we ship to be our own pristine code.

Sure, I agree that is a problem.

Comment 11

7 years ago
There are no rpm, deb or other distro-format packages created by Mozilla right now. The only builds we produce are the .tar.bz2 packages we put on FTP and also offer for our official downloads.
AFAIK, we offer checksums and signatures to those checksums so people can ensure they download accurate packages, but most people probably will never care to check those. The updates we provide on those builds are fully secured through our usual update system, though.

Comment 12

7 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #11)
> There are no rpm, deb or other distro-format packages created by Mozilla
> right now. 

Huh! What about the Ubuntu packages by the Mozilla team?

> The only builds we produce are the .tar.bz2 packages we put on
> FTP and also offer for our official downloads.

Ok.

> AFAIK, we offer checksums and signatures to those checksums so people can
> ensure they download accurate packages, but most people probably will never
> care to check those. The updates we provide on those builds are fully
> secured through our usual update system, though.

That's a strong argument for a stub installer that uses local packaging tools. If they won't check the signature once, they'll never have to check it again and it will be forever upgraded with all of the rest of their packages.

Comment 13

7 years ago
(In reply to Jacob Appelbaum from comment #12)
> Huh! What about the Ubuntu packages by the Mozilla team?

AFAIK that's not any official Mozilla team, and pretty sure not Mozilla Release Engineering, this is just a team of people from the ubuntu community who are maintaining Mozilla builds.

Comment 14

7 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #13)
> (In reply to Jacob Appelbaum from comment #12)
> > Huh! What about the Ubuntu packages by the Mozilla team?
> 
> AFAIK that's not any official Mozilla team, and pretty sure not Mozilla
> Release Engineering, this is just a team of people from the ubuntu community
> who are maintaining Mozilla builds.

Ah, understood.
(Reporter)

Comment 15

7 years ago
I feel like the options here are clear:

* If we use distros' builds, users get their tweaks, and their build numbers.
* If we run out own builds, we have to spend some additional releng resources.

The question is just whether the uniformity & crash (&c) tracking benefit is worth the releng implementation cost to package our builds inside appropriate packages and run our own repo for users to get them from. Aesthetically, I like the idea of being able to get signed, distro-specific packages directly form Mozilla. On the other hand, if we track distro's build number for crash reporting, we may be able to notify maintainers of issues, and help improve distro-specific packages. In the end, I don't really have a stake in that decision.

Whatever the result, our download pages should offer options better than a .tar.gz over HTTP, since that's basically the worst option both from a security and experience perspective. There are loads of options now that are undiscoverable: distro packages, our signed checksums, and so forth. At the very least we should make these obvious. If we have the inclination, we should offer better options (our own repositories, SSL downloads, a stub installer that takes care of package management), and make those obvious too.

Comment 16

7 years ago
(In reply to Tom Lowenthal [:StrangeCharm] from comment #15)
> On the other hand, if we track distro's
> build number for crash reporting

We can't, at least not without a really really high amount of work and manual tracking of builds outside of our control. I won't go into all details here, that would be too much for the bug report.
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Duplicate of this bug: 541737
Blocks: 837778
Severity: normal → enhancement
Component: General → Pages & Content
You need to log in before you can comment on or make changes to this bug.