Re: Missing source in firefox-esr: EME module
The binary-only wildvine component of Firefox, as incorporated in the package currently shipped by Debian, can not reasonably be understood as an "optional addon that is downloaded separately in response to an explicit user request". It is intended as integral functionality of the browser, and the technical mechanism of downloading that component separately exists only as an attempt to game standards such as the DFSG that prefer free software.
This can be clearly seen in the Mozilla bug where the initially included mechanism to (even) opt-out was intentionally removed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1234355
Comparing this to the librejs question is unreasonable. That's like asking if Debian should package Java Web Start because someone might run a proprietary app that way. That's certainly an interesting question, but not the right point of comparison for this case.
A better comparison is something like the old "flashplugin-nonfree" package. It contained no non-free software directly, but downloaded and installed a non-free component by default. It even had UI elements that made it harder to download that component by mistake - it popped up an EULA screen with a "no" button before downloading. Should that package have been in main? How about "winetricks", where the components *are* clearly optional and explicitly requested?
Having something like the "don't ask again" button should be an absolute minimum requirement here. Even then, I'd still be disappointed to see stock Firefox in Debian. There may be a way to practically solve this with UI, but the more reasonable standard would be to say that programs that include hardcoded paths to download specific binary components innately violate the spirit of the DFSG.
Are there other packages in Debian main that have hardcoded URLs to download to non-free components from third parties? How do they handle this?
Is this a security issue? If someone hijacks Mozilla's web infrastructure does that allow them arbitrary remote code execution on Debian systems?
On Fri, Jun 21, 2019, at 13:09, Ian Jackson wrote:
> Nat Tuck writes ("Missing source in firefox-esr: EME module"):
> > The firefox-esr package in Buster includes the encrypted media extension
> > functionality, which relies on library called "wildvine". Source for
> > this library is not included in the firefox-esr source package.
> >
> > This has been an outstanding bug since 2016, but it hasn't been
> > considered as a serious issue with the package:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837091
>
> That bug seems to contradict you.
>
> Firstly, it says that firefox-esr only downloads this proprietary
> software after explicit user action. Is that right ?
>
> Secondly, it is indeed tagged as "serious", ie release critical.
>
> I think the behaviour described at the end of that bug is quite
> undesirable. I think user action to download non-free sofware should
> be more explicit, and not so easily invited.
>
> Overall, in Debian, we do not have a good enough mechanism for user
> control over these kind of suggestions. There should be a single
> place where a user can say, during installation, what their posture is
> for non-free software.
>
> Options should probably include:
>
> 0 Never suggest non-free software to me; simply don't mention it.
>
> 1 Explicitly confirm for each piece of non-free software.
>
> 2 Automatically download and run non-free software whenever
> it is likely to be convenient.
>
> We would have to have some kind of argument about JavaScript on web
> pages. I don't think the FSF's "librejs" stuff is useful in practice
> but we should probably offer it as an option. Something like a ublock
> configuration that turns off JS by default and can be fiddled with,
> would probably be appropriate for users who select 0 or 1.
>
> Ian.
>
> --
> Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
>
>
Reply to: