ungoogled-chromium may contain Widevine DRM

Done

Details

9 participants

Adonay Felipe Nogueira
Giovanni Biscuolo
Jason Self
Jelle Licht
Julien Lepiller
Leo Famulari
Marius Bakke
ng0
Ricardo Wurmus

Owner: unassigned

Submitted by: Jason Self

Severity: normal

Jason Self wrote on 19 Feb 2019 04:44

ungoogled-chromium contains Widevine DRM

Recipients:(address . submit@debbugs.gnu.org)

Message-ID:1550547897.31222.1.camel@jxself.org

Package: guix

Unless I am mistaken, ungoogled-chromium is not removing Widevine DRM
from upstream Chromium. Guix should remove that if upstream won't, as I
believe this goes against "the distro must contain no DRM..." in the
FSDG.

Leo Famulari wrote on 19 Feb 2019 08:06

Recipients:(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)

Message-ID:20190219070601.GA8273@jasmine.lan

On Mon, Feb 18, 2019 at 07:44:57PM -0800, Jason Self wrote:

Toggle quote (5 lines)

> Unless I am mistaken, ungoogled-chromium is not removing Widevine DRM

> from upstream Chromium. Guix should remove that if upstream won't, as I

> believe this goes against "the distro must contain no DRM..." in the

> FSDG.

Why do you think this is the case? It doesn't work for me on any of the

Widevine demos I can find, unlike an installation of Google Chrome.

Jason Self wrote on 19 Feb 2019 14:28

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:1550582906.5431.7.camel@jxself.org

On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:

Why do you think this is the case?

We know Chromium comes with it. Have you looked through�ungoogled-

chromium to see where it's being deleted?

Julien Lepiller wrote on 19 Feb 2019 14:42

Recipients:(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)

Message-ID:ea3643bd3575de03e15d3c82c1aefe8c@lepiller.eu

Le 2019-02-19 14:28, Jason Self a écrit�:

Toggle quote (6 lines)

> On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:

> Why do you think this is the case?

> We know Chromium comes with it. Have you looked through�ungoogled-

> chromium to see where it's being deleted?

Our package definition has two widevine-related headers listed as
preserved third-party stuff... I'm not sure how widevine normally
gets into chromium, but if we don't have it, I guess we should
not need these headers? There might actually be an issue, but
I'm not sure how to check. Where is widevine in upstream (non
ungoogled) chromium? Is it downloaded at runtime?

IIUC, the rest of this widevine directory is removed before
building anything, so maybe there's nothing to worry about
after all?

Leo Famulari wrote on 19 Feb 2019 15:43

Recipients:(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)

Message-ID:20190219144342.GA2688@jasmine.lan

On Tue, Feb 19, 2019 at 05:28:26AM -0800, Jason Self wrote:

Toggle quote (3 lines)

> We know Chromium comes with it. Have you looked through�ungoogled-

> chromium to see where it's being deleted?

Please show us the paths in our package's source code. We need to remove

it if it is there.

I looked and cannot find it.

I looked at how some other distros do it.

They get the Widevine binaries by extracting them from a download of the

Google Chrome browser, which is not the browser that has been packaged

for Guix.

Julien Lepiller wrote on 19 Feb 2019 15:44

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:aba259a44a52136939babd3f3cfee6be@lepiller.eu

Le 2019-02-19 14:42, Julien Lepiller a écrit�:

Toggle quote (18 lines)> Le 2019-02-19 14:28, Jason Self a écrit�:
>> On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:
>> Why do you think this is the case?
>> 
>> We know Chromium comes with it. Have you looked through�ungoogled-
>> chromium to see where it's being deleted?
> 
> Our package definition has two widevine-related headers listed as
> preserved third-party stuff... I'm not sure how widevine normally
> gets into chromium, but if we don't have it, I guess we should
> not need these headers? There might actually be an issue, but
> I'm not sure how to check. Where is widevine in upstream (non
> ungoogled) chromium? Is it downloaded at runtime?
> 
> IIUC, the rest of this widevine directory is removed before
> building anything, so maybe there's nothing to worry about
> after all?

So I've downloaded the source tarball with `guix build -S chromium`
and here's what I found in it:

$ find -name cdm
./media/cdm
./third_party/widevine/cdm
./chrome/android/java/src/org/chromium/chrome/browser/media/cdm
./chrome/browser/media/android/cdm
./content/renderer/media/cdm
./chromecast/media/cdm
./components/cdm

$ find -name widevine
./third_party/widevine

$ find -name '*widevine*'
./third_party/widevine
./third_party/widevine/cdm/android/widevine_cdm_version.h
./third_party/widevine/cdm/widevinecdmadapter.ver
./third_party/widevine/cdm/stub/widevine_cdm_version.h
./third_party/widevine/cdm/widevine.gni
./third_party/widevine/cdm/widevine_cdm_version.h
./third_party/widevine/cdm/widevine_cdm_common.h
./chrome/common/widevine_cdm_constants.h
./chrome/common/widevine_cdm_constants.cc
./chrome/browser/component_updater/widevine_cdm_component_installer.cc
./chrome/browser/component_updater/widevine_cdm_component_installer.h
./components/cdm/common/widevine_drm_delegate_android.cc
./components/cdm/common/widevine_drm_delegate_android.h
./components/cdm/renderer/widevine_key_system_properties.cc
./components/cdm/renderer/widevine_key_system_properties.h


This 
./chrome/browser/component_updater/widevine_cdm_component_installer.cc
looks particularly suspicious to me...

Now, it seems that widevine stuff only gets built when the 
ENABLE_WIDEVINE
option is set, and it doesn't seem to be the case in guix' package. 
Since
I don't understand how the browser gets built, so I'm not sure about the
default. In any case, it would be good to get rid of these files even
if they aren't built.

HTH!

Jason Self wrote on 20 Feb 2019 01:39

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:1550623152.12316.5.camel@jxself.org

Based on�http://issues.guix.info/issue/28004#2�itis disabled at build
time; but not removed. The person said they thought this was FSDG
compliant but a reading of "the distro must contain no DRM" from the
FSDG could be taken to mean the distro still "contains" it, since it's
still within the source code of the program. "Disabled by default"
shouldn't be good enough IMHO; build flags should not be used to hide
freedom problems. The source code represents what the software *is*,
not the build flags.

Jason Self wrote on 20 Feb 2019 02:12

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:1550625137.14138.3.camel@jxself.org

A different but related matter is the build process itself. I
understand this is not exactly related to the DRM matter but it does
seem similiar. I can open another bug over this if needed. I have
recently submitted upstream's Chromium 73.0.3683.45 into my FOSSology
instance for analysis. Actually, less than a third of the total files
were classified as "BSD-like". In total it found 162 unique licenses.
Of course, automated licenses analysis is never perfect and I have not
fully vetted any particular results but it does help to at least
indicate that which is very clearly free software and that which needs
further investigation.

Even in the short time I was reviewing it I found a number of freedom
problems. I don't mean that to be an exhaustive list of everything,
merely an indicator of a symptom:

* unrar (license denies freedom 0)
* third_party/blink has some images under CC-BY-NC-SA-2.0
* Google Toolbar is in there, with a non-free EULA

Taking this and considering Guix's build process: The method of
building seems to involve downloading Chromium, then runnning
ungoogled-chromium over it, and then building. I'm not sure if any
other packages have their freedom problems fixed in this way but this,
just like build flags, should not be sufficient. Freedom problems
should not be hidden/removed after the fact by asking the user to run a
clean-up program after downloading the source, even if that has been
automated by the package manager. What is sent to the end user to
compile should itself be 100% free software and FSDG compliant from the
beginning. If not it still amounts to distributing non-free software to
the user when they want to, for example, do guix build -S chromium.

Jason Self wrote on 20 Feb 2019 02:19

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:1550625587.14780.2.camel@jxself.org

Toggle quote (8 lines)

> should not be hidden/removed after the fact by asking the user to run

> a clean-up program after downloading the source, even if that has

> been automated by the package manager. What is sent to the end user

> to compile should itself be 100% free software and FSDG compliant

> from the beginning. If not it still amounts to distributing non-free

> software to the user when they want to, for example, do guix build -S

> chromium.

I should probably add on that this position comes from my interaction
with the FSF in 2010: When LibreWRT was founded in 2010 (before it
later merged into libreCMC) we submitted a similar�question to the FSF,
as to if it was sufficient for the LibreWRT build scripts (which would
be run by the person building the firmware image from source and would
have completely automated, just like how someone might instruct Guix to
build from source) to download Linux and then run the Linux-libre
deblobbing scripts on it vs having the build scripts instead download
tarballs that were already cleaned up. I can't seem to find the email
from back then but the response was that we needed to use already
cleaned-up tarballs, not ask the user to clean up the software after
ward even if automated. So that was what we did. Guix should do
something similar.

Leo Famulari wrote on 20 Feb 2019 06:15

Recipients:(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)

Message-ID:20190220051536.GA7782@jasmine.lan

On Tue, Feb 19, 2019 at 05:12:17PM -0800, Jason Self wrote:

Toggle quote (12 lines)> Taking this and considering Guix's build process: The method of
> building seems to involve downloading Chromium, then runnning
> ungoogled-chromium over it, and then building. I'm not sure if any
> other packages have their freedom problems fixed in this way but this,
> just like build flags, should not be sufficient. Freedom problems
> should not be hidden/removed after the fact by asking the user to run a
> clean-up program after downloading the source, even if that has been
> automated by the package manager. What is sent to the end user to
> compile should itself be 100% free software and FSDG compliant from the
> beginning. If not it still amounts to distributing non-free software to
> the user when they want to, for example, do guix build -S chromium.

To clarify this general point about Guix for anyone who is reading
along, as a matter of policy the end user does not receive non-free
source code from Guix.

The tools provided by Guix to access source code only return source code
that is freely licensed. If the sources have to be modified to ensure
this, the unodified source code is not provided to the user. Guix is
specifically designed to do it this way.

Leo Famulari wrote on 20 Feb 2019 06:21

(no subject)

Recipients:(address . control@debbugs.gnu.org)

Message-ID:20190220052150.GA8951@jasmine.lan

retitle 34565 ungoogled-chromium may contain Widevine DRM

Jason Self wrote on 20 Feb 2019 06:35

Re: bug#34565: ungoogled-chromium contains Widevine DRM

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:1550640947.21795.7.camel@jxself.org

Leo Famulari wrote:

Toggle quote (4 lines)

> To clarify this general point about Guix for anyone who is reading

> along, as a matter of policy the end user does not receive non-free

> source code from Guix.

Right; the source is downloaded from commondatastorage.googleapis.com
but that is a technicality. What I'm saying is that the recipe should
be updated to cause it to download an already-cleaned up version
directly from Guix (it could be hosted somewhere on gnu.org for example
but exactly where can be up for negotiation) and that this excuse of
"they're getting it elsewhere" shouldn't be usable as an excuse to
sidestep the FSDG. It's still causing the user to download the software
due to the recipes provided by Guix.

Toggle quote (4 lines)

> The tools provided by Guix to access source code only return source

> code that is freely licensed. If the sources have to be modified to

> ensure this, the unodified source code is not provided to the user.

It's still being downloaded into their computer and then being cleaned

up after the fact. If there weren't freedom problems with it there

wouldn't be a need for a clean-up program (ungoogled-chromium in this

case) to be running -- as a process on the user's computer -- to do

this.

And in�https://www.gnu.org/distros/free-system-distribution-guidelines.

html�we have:

"For instance, a free system distribution must not contain browsers that implement EME, the browser functionality designed to load DRM modules."

So that should make it quite clear.

Leo Famulari wrote on 20 Feb 2019 06:42

Recipients:(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 34565@debbugs.gnu.org)

Message-ID:20190220054219.GA9386@jasmine.lan

On Tue, Feb 19, 2019 at 03:44:17PM +0100, Julien Lepiller wrote:

Toggle quote (3 lines)

> So I've downloaded the source tarball with `guix build -S chromium`

> and here's what I found in it:

[...]

Thanks for taking a look, Julien!

We need to find out if Widevine DRM is actually included in the Guix

ungoogled-chromium package or not.

Obviously the intent was to not include it, and it does not work in

practice. Widevine videos do not play and there is no prompt to install

or enable DRM, unlike in some other browsers that use DRM.

I think the next steps for this subject are to first, in general, figure

out where Widevine comes from, and then, more specifically, decide what

to do about the files you mentioned.

As I mentioned already, other distros seem to get Widevine by extracting

its binary from Chrome, even when using it for Chromium. It seems

reasonable to assume that if Widevine were included in Chromium they

would not be downloading a whole 'nother browser for that one component.

As for the specific files listed by Julien, they may be harmless, or

not, we should figure out what they do and if they need to be removed.

Ricardo Wurmus wrote on 20 Feb 2019 08:59

Re: bug#34565: ungoogled-chromium might contain remnants of Widevine DRM

Recipients:(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)

Message-ID:8736oivqkb.fsf@elephly.net

Jason Self <j@jxself.org> writes:

Toggle quote (14 lines)> Leo Famulari wrote:
>> To clarify this general point about Guix for anyone who is reading
>> along, as a matter of policy the end user does not receive non-free
>> source code from Guix.
>
> Right; the source is downloaded from commondatastorage.googleapis.com
> but that is a technicality. What I'm saying is that the recipe should
> be updated to cause it to download an already-cleaned up version
> directly from Guix (it could be hosted somewhere on gnu.org for example
> but exactly where can be up for negotiation) and that this excuse of
> "they're getting it elsewhere" shouldn't be usable as an excuse to
> sidestep the FSDG. It's still causing the user to download the software
> due to the recipes provided by Guix.

Please do not claim that Guix sidesteps or aims to sidestep the FSDG.

This is not the case as we are committed to abiding by the FSDG.

What users get when using “guix build --source” is the processed source

code from the Guix build farm. The fallback is to fetch the original

sources directly and process them (which is what the build farm does as

well).

Ricardo

Giovanni Biscuolo wrote on 20 Feb 2019 10:22

Re: bug#34565: ungoogled-chromium contains Widevine DRM

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 34565@debbugs.gnu.org)

Message-ID:87imxe95mc.fsf@roquette.mug.biscuolo.net

Hello,

maybe Marius Bakke have something interesting to say about his

judgements on this "DRM matter"

indeed, this is a pretty ignorant (aka me) comment:

Leo Famulari <leo@famulari.name> writes:

[...]

Toggle quote (10 lines)> I think the next steps for this subject are to first, in general, figure
> out where Widevine comes from, and then, more specifically, decide what
> to do about the files you mentioned. 
>
> As I mentioned already, other distros seem to get Widevine by extracting
> its binary from Chrome, even when using it for Chromium. It seems
> reasonable to assume that if Widevine were included in Chromium they
> would not be downloading a whole 'nother browser for that one
> component.

ungoogle-chromium FAQs [1] confirms that in order to install Widevine

users have to download a shared object (libwidevinecdm.so) and install

it system wide in /usr/lib/chromium or in $HOME/.local/lib/

I tried to install ungoogled-chromium from Guix but failed (another

story...) so I cannot see myself, but AFAIU there is no way for a user

to enable Widevine from the user interface *nor* manually

I don't know if the libwidevinecdm.so user loading must be forbidden

**programmatically** [2] to be FSDG compliant: what is the case with the

linux-libre kernel? are users forbidden to "insmod proprietery_module"

they _independently_ downloded or developed?

anyway, as Julien Lepiller already verified (Guix package definition is

there for anyone to check, and checking is very easy), Widevine stuff

only gets built when the ENABLE_WIDEVINE build option is set... and it's

not this case, so it's unlikely that users will be able to install

Widevine even following the above mentioned procedure

last but not least: AFAIU ungoogled-chromium Guix package documentation

nor Guix Manual contains information on how to obtain proprierary

extensions to any software; am I wrong?

Toggle quote (3 lines)

> As for the specific files listed by Julien, they may be harmless, or

> not, we should figure out what they do and if they need to be removed.

AFAIU that code allows dynamically linking Widevine (sorry cannot still

check myself), but it is _disabled_ at build time

is this enough to be FSDG compliant?

given all the above, it seems to me that ungoogled-chromium binaries

provided by Guix substitute servers _and_ sources provided by Guix build

farms (are provided by them, right?) does not ship with DRM enabled

to sum it up: AFAIU for users to be able to use Widevine they must

create a custom package definition _outside_ official Guix channels

*and* download the shared object "libwidevinecdm.so" from Chromium,

installing it "manually" system wide or locally

HTH!

Ciao

Giovanni

[1]

https://ungoogled-software.github.io/ungoogled-chromium-wiki/faq#how-do-i-install-widevine-cdm

[2] I mean by stripping away any bit of source code that allows users to

dynamically link potentially proprietary shared objects in the software

Giovanni Biscuolo

Xelera IT Infrastructures

Jelle Licht wrote on 20 Feb 2019 11:09

Recipients:(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)

Message-ID:87a7iqdb5b.fsf@fsfe.org

Jason Self <j@jxself.org> writes:

Toggle quote (11 lines)> Leo Famulari wrote:
>> To clarify this general point about Guix for anyone who is reading
>> along, as a matter of policy the end user does not receive non-free
>> source code from Guix.
>
> Right; the source is downloaded from commondatastorage.googleapis.com
> but that is a technicality. What I'm saying is that the recipe should
> be updated to cause it to download an already-cleaned up version
> directly from Guix (it could be hosted somewhere on gnu.org for example
> but exactly where can be up for negotiation) and that this excuse of

I would argue that this way of thinking is one of the issues Guix and

the broader reproducible builds community is trying to solve (in an

ethical way). Practical software freedom also includes the possibility

of not being dependent on even the gnu.org infrastructure.

Toggle quote (4 lines)

> "they're getting it elsewhere" shouldn't be usable as an excuse to

> sidestep the FSDG. It's still causing the user to download the software

> due to the recipes provided by Guix.

The implied tone of your message comes across as needlessly
aggressive. I am not sure if the GNU Kind Communications Guidelines
apply here, but I still urge you to give the broader Guix community the
benefit of the doubt in that they are committed to the FSDG and
everything it entails.

This is like arguing that curl could be used to download proprietary
software; An unmodified Guix will never present a user with non-free
software. If it does, this can be considered a bug and should be fixed
ASAP. Your proposal implies that someone else still downloads the
nonfree upstream sources to modify them, so I see this as even more of a
case of working around the spirit of the FSDG.

Toggle quote (11 lines)>
>> The tools provided by Guix to access source code only return source
>> code that is freely licensed. If the sources have to be modified to
>> ensure this, the unodified source code is not provided to the user.
>
> It's still being downloaded into their computer and then being cleaned
> up after the fact. If there weren't freedom problems with it there
> wouldn't be a need for a clean-up program (ungoogled-chromium in this
> case) to be running -- as a process on the user's computer -- to do
> this.

I do not really get the point you are trying to make, because the

software has to be downloaded at some point in time. Offering a

transparent solution in the form of the Guix store, where the

problematic bits of software only exist in a transient state seems like

it improves the situation across the board.

Whether this fits the letter of the FSDG is an interesting discussion to

be had, but arguing that it goes against the core principles is simply

silly :).

Toggle quote (8 lines)

> And inhttps://www.gnu.org/distros/free-system-distribution-guidelines.

> htmlwe have:

> "For instance, a free system distribution must not contain browsers that implement EME, the browser functionality designed to load DRM modules."

> So that should make it quite clear.

I feel most folks here agree on this, at least, so if ungoogled-chromium

still implements a functioning EME, that is a bug.

Respectfully yours,

- Jelle

Jason Self wrote on 20 Feb 2019 14:03

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:1550667811.25277.1.camel@jxself.org

Jason Self wrote:

Toggle quote (14 lines)> I should probably add on that this position comes from my interaction
> with the FSF in 2010: When LibreWRT was founded in 2010 (before it
> later merged into libreCMC) we submitted a similar�question to the
> FSF,as to if it was sufficient for the LibreWRT build scripts (which
> would be run by the person building the firmware image from source
> and would have completely automated, just like how someone might
> instruct Guix to build from source) to download Linux and then run
> the Linux-libre deblobbing scripts on it vs having the build scripts
> instead download tarballs that were already cleaned up. I can't seem
> to find the email from back then but the response was that we needed
> to use already cleaned-up tarballs, not ask the user to clean up the
> software afterward even if automated. So that was what we did. Guix
> should do something similar.

I haven't been able to find this conversation in my email. As it seems
to be directly relevant to Guix, since it seems to also be the exact
same method they use, I have emailed the FSF asking if they can locate
this in their ticketing system and to re-send the conversation to me.
More to come.

Marius Bakke wrote on 20 Feb 2019 15:37

Recipients:

Message-ID:87wolumspw.fsf@fastmail.com

Jason Self <j@jxself.org> writes:

Toggle quote (11 lines)> A different but related matter is the build process itself. I
> understand this is not exactly related to the DRM matter but it does
> seem similiar. I can open another bug over this if needed. I have
> recently submitted upstream's Chromium 73.0.3683.45 into my FOSSology
> instance for analysis. Actually, less than a third of the total files
> were classified as "BSD-like". In total it found 162 unique licenses.
> Of course, automated licenses analysis is never perfect and I have not
> fully vetted any particular results but it does help to at least
> indicate that which is very clearly free software and that which needs
> further investigation.

To avoid duplicate work, it would be useful if you ran this analysis on

the tarball produced by `guix build --source ungoogled-chromium`.

Toggle quote (6 lines)

> Even in the short time I was reviewing it I found a number of freedom

> problems. I don't mean that to be an exhaustive list of everything,

> merely an indicator of a symptom:

> * unrar (license denies freedom 0)

UnRAR is not present in the Guix source.

Toggle quote (2 lines)

> * third_party/blink has some images under CC-BY-NC-SA-2.0

I cannot find these images: grepping for CC-BY-NC-SA or 'Creative

Commons' did not aid. Did you record the absolute paths to these files?

Toggle quote (2 lines)

> * Google Toolbar is in there, with a non-free EULA

My grep-fu is really failing me today. Where is this located?

Toggle quote (12 lines)> Taking this and considering Guix's build process: The method of
> building seems to involve downloading Chromium, then runnning
> ungoogled-chromium over it, and then building. I'm not sure if any
> other packages have their freedom problems fixed in this way but this,
> just like build flags, should not be sufficient. Freedom problems
> should not be hidden/removed after the fact by asking the user to run a
> clean-up program after downloading the source, even if that has been
> automated by the package manager. What is sent to the end user to
> compile should itself be 100% free software and FSDG compliant from the
> beginning. If not it still amounts to distributing non-free software to
> the user when they want to, for example, do guix build -S chromium.

As Leo says, `guix build --source` should never return nonfree software
as a matter of policy.  Ungoogled-Chromium is no different: running
`guix build --source ungoogled-chromium` will run the pruning scripts
and generate a sanitized tarball, or (more likely) transparently
download an already-processed source from the build farm.

Marius Bakke wrote on 20 Feb 2019 15:48

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:87sgwims6k.fsf@fastmail.com

Giovanni Biscuolo <g@xelera.eu> writes:

Toggle quote (5 lines)

> Hello,

> maybe Marius Bakke have something interesting to say about his

> judgements on this "DRM matter"

[...]

Toggle quote (5 lines)

> to sum it up: AFAIU for users to be able to use Widevine they must

> create a custom package definition _outside_ official Guix channels

> *and* download the shared object "libwidevinecdm.so" from Chromium,

> installing it "manually" system wide or locally

This analysis is correct.  For DRM to work, the user has to build with
"enable_widevine=true", and then somehow obtain 'libwidevinecdm.so' and
make the browser use it.

Julien Lepiller wrote on 20 Feb 2019 17:18

Recipients:(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)

Message-ID:ece143d1e11fcb21e4c91ea33e959a3c@lepiller.eu

Le 2019-02-20 14:03, Jason Self a écrit�:

Toggle quote (21 lines)> Jason Self wrote:
>> I should probably add on that this position comes from my interaction
>> with the FSF in 2010: When LibreWRT was founded in 2010 (before it
>> later merged into libreCMC) we submitted a similar�question to the
>> FSF,as to if it was sufficient for the LibreWRT build scripts (which
>> would be run by the person building the firmware image from source
>> and would have completely automated, just like how someone might
>> instruct Guix to build from source) to download Linux and then run
>> the Linux-libre deblobbing scripts on it vs having the build scripts
>> instead download tarballs that were already cleaned up. I can't seem
>> to find the email from back then but the response was that we needed
>> to use already cleaned-up tarballs, not ask the user to clean up the
>> software afterward even if automated. So that was what we did. Guix
>> should do something similar.
> 
> I haven't been able to find this conversation in my email. As it seems
> to be directly relevant to Guix, since it seems to also be the exact
> same method they use, I have emailed the FSF asking if they can locate
> this in their ticketing system and to re-send the conversation to me.
> More to come.

I think the situation is different though. You can see the build script
inside the "origin" record as the liberation procedure that anyone can
see and verify. It's also a procedure targeted at our build farms, so
that they can produce the liberated source code. Users never manipulate
non-free source code, unless something is wrong on the build farm side.

Essentially, users only download the liberated sources, and build the
package from that, or they download the sources from the build farm
and build the package from that. The source they download is the
one that `guix build -S foo` gives you, and the semantics is
"give me the sources to build foo", not "build the sources of foo".

I think that this way is more transparent, since we can independently,
altough with tooling not provided by guix, check and re-run the
liberation procedure that is documented as part of the guix package
recipe. This is much better than trusting someone to have actually
run the right liberation procedure as you can examine both the result
and the procedure itself.

I hope this is clearer now :)

Well, I'm still interested by that discussion on libreWRT.

Adonay Felipe Nogueira wrote on 20 Feb 2019 21:15

Recipients:(address . 34565@debbugs.gnu.org)(name . Jason Self)(address . j@jxself.org)

Message-ID:bc360447-79ad-87d7-181a-a25da8b7a87a@hyperbola.info

Em 20/02/2019 13:18, Julien Lepiller escreveu:

Toggle quote (6 lines)

> I think the situation is different though. You can see the build script

> inside the "origin" record as the liberation procedure that anyone can

> see and verify. It's also a procedure targeted at our build farms, so

> that they can produce the liberated source code. Users never manipulate

> non-free source code, unless something is wrong on the build farm side.

I'm not taking any sides here, but to give some more information, if for
example you do `guix edit ungoogled-chromium' you will be presented to
the package definition of Ungoogled-Chromium, taking that as an example
you can see that it has a "source (origin ...) ...)" definition, inside
the inner part (the "origin") you have:

* the upstream download location and method, see (method ...), (uri ...)
and (sha256 ...);
* patches that should be applied immediatelly after downloading and
extracting the source files, per (patches ...);
* snippets and modules to be used with these, also to be applied
immediatelly after downloading and extracting the source files, as seen
in (snippet ...) and (modules ...).

When `guix build -S ungoogled-chromium' is done, first it checks the
build farms for the "prepared" source that matches the given package
definition, version, hash and so on; and lastly it tries to "prepare"
the source according to (patches ...) and (snippet ...) declarations
before even telling the user that the download is ready/done.

Having the (origin ...) visible in this way brings the advantages that
the people of Guix told about here, but as far as I can tell, the user
also sees the original location of the non-free source from upstream if
they do `guix edit ungoogled-chromium'.


-- 
- Página com formas de contato:
  https://libreplanet.org/wiki/User:Adfeno#vCard
- Ativista do software livre (não confundir com o gratuito). Avaliador
  da liberdade de software e de sites.
- Página com lista de contribuições:
  https://libreplanet.org/wiki/User:Adfeno#Contribs
- Para uso em escritórios e trabalhos, favor enviar arquivos do padrão
  internacional OpenDocument/ODF 1.2 (ISO/IEC 26300-1:2015 e
  correlatos). São os .odt/.ods/.odp/odg. O LibreOffice é a suíte de
  escritório recomendada para editar tais arquivos.
- Para outros formatos de arquivos, veja:
  https://libreplanet.org/wiki/User:Adfeno#Arquivos
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
  https://libreplanet.org/wiki/User:Adfeno#Suporte
- Use comunicações sociais federadas padronizadas, onde o "social"
  permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
  (https://libreplanet.org/wiki/XMPP.pt),#DeleteFacebook
  #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
  #Mastodon (https://joinmastodon.org/).
- #DeleteNetflix #CancelNetflix. Evite #DRM:
  https://www.defectivebydesign.org/

Attachment: signature.asc

Ricardo Wurmus wrote on 20 Feb 2019 22:49

Recipients:(name . Adonay Felipe Nogueira)(address . adfeno@hyperbola.info)

Message-ID:87zhqq3zb1.fsf@elephly.net

Adonay Felipe Nogueira <adfeno@hyperbola.info> writes:

Toggle quote (9 lines)

> Em 20/02/2019 13:18, Julien Lepiller escreveu:

>> I think the situation is different though. You can see the build script

>> inside the "origin" record as the liberation procedure that anyone can

>> see and verify. It's also a procedure targeted at our build farms, so

>> that they can produce the liberated source code. Users never manipulate

>> non-free source code, unless something is wrong on the build farm side.

> I'm not taking any sides here, but to give some more information […]

I would appreciate it if this discussion could be moved elsewhere. This

is about whether the package in Guix contains “Widevine DRM”. As far as

I understand it does not (as a third-party binary needs to be obtained).

If it does after all contain objectionable files please point them out

so that we can remove them ASAP.

Thanks!

Ricardo

Jason Self wrote on 21 Feb 2019 03:19

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:1550715570.3891.5.camel@jxself.org

On Wed, 2019-02-20 at 22:49 +0100, Ricardo Wurmus wrote:

Toggle quote (3 lines)

> If it does after all contain objectionable files please point them

> out so that we can remove them ASAP.

That was done earlier in the thread. It might also be interesting to
try building with enable_widevine=true.

In the context of the FSDG's "a free system distribution must not
contain browsers that implement EME, the browser functionality designed
to load DRM modules", I wonder if the browser would still be considered
as "implementing" the "functionality ... to load DRM modules" from the
FSF's viewpoint since it's only a build flag and the support for
loading the module (even if not provided by Guix since it's non-free)
seems otherwise intact.

Jason Self wrote on 21 Feb 2019 03:43

Recipients:(address . 34565@debbugs.gnu.org)

Message-ID:1550716997.3891.12.camel@jxself.org

Marius Bakke wrote:

Toggle quote (2 lines)

> not present in the Guix source.

Please keep in mind I was discussing upstream Chromium in that piece.

It's also not an exhaustive list.

Toggle quote (4 lines)

> I cannot find these images: grepping for CC-BY-NC-SA or 'Creative

> Commons' did not aid.��Did you record the absolute paths to these

> files?

Of course - FOSSology records everything as it recursively unpacks and

searches files, metadata of files, etc.�

third_party/blink/web_tests/fast/backgrounds/size/resources/SquirrelFis

h.svg has within it:

<a rel="cc:attributionURL" href="http://www.flickr.com/photos/goopymart

/">http://www.flickr.com/photos/goopymart//a ; / a rel="license"

href="http://creativecommons.org/licenses/by-nc-sa/2.0/"CC BY-NC-SA

2.0</a></div>

2. chrome/test/data/extensions/api_test/wallpaper_manager/test_bad.jpg

contains:

xmpRights:WebStatement="http://creativecommons.org/licenses/by-nc-sa/2.

3. chrome/test/data/extensions/test.jpg contains within it:

http://creativecommons.org/licenses/by-nc-sa/2.0/

4. chrome/test/data/extensions/api_test/wallpaper/test.jpg

Identified by FOSSology as being identical to file 3.

5. chrome/test/data/extensions/api_test/wallpaper_manager/test.jpg

contains within it:

http://creativecommons.org/licenses/by-nc-sa/2.0/

Toggle quote (2 lines)

> My grep-fu is really failing me today.��Where is this located?

chrome/test/data/import/firefox/macwin.zip/Profiles/brn6z0fz.default/ex

tensions/{3112ca9c-de6d-4884-a869-9855de68056c}/chrome/google-

toolbar.jar

chrome/test/data/import/firefox/macwin.zip/Profiles/brn6z0fz.default/ex

tensions/{3112ca9c-de6d-4884-a869-9855de68056c}/LICENSE.txt

Keep in mind this was not an exhaustive report of all of upstream

Chromium 73.0.3683.45 and there is much left out. They were intended

only as examples to show freedom problems within Chromium itself.

As for the rest I guess we'll need to wait on a response from the FSF

since I seem to be receving pushback myself.

Marius Bakke wrote on 21 Feb 2019 08:51

Recipients:

Message-ID:877edtmvfb.fsf@fastmail.com

Jason Self <j@jxself.org> writes:

Toggle quote (6 lines)

> Marius Bakke wrote:

>> not present in the Guix source.

> Please keep in mind I was discussing upstream Chromium in that piece.

> It's also not an exhaustive list.

I don't think upstream Chromium is relevant to this discussion.

Toggle quote (7 lines)

>> I cannot find these images: grepping for CC-BY-NC-SA or 'Creative

>> Commons' did not aid.��Did you record the absolute paths to these

>> files?

> Of course - FOSSology records everything as it recursively unpacks and

> searches files, metadata of files, etc.�

I was not aware of FOSSology, and admit that I have not checked file

metadata. It would be great to have this tool in Guix!

None of the reported files are present in the Guix source. I believe

they are all scrubbed by the Ungoogled binary pruning script.

I really appreciate your effort here, but please only use this bug

tracker for problems that affect the Guix package. Thanks!

ng0 wrote on 12 Oct 2019 13:14

Recipients:(name . Marius Bakke)(address . mbakke@fastmail.com)

Message-ID:20191012111417.bqw7xynqpcqtawgx@uptimegirl

Marius Bakke transcribed 1.2K bytes:

Toggle quote (18 lines)> Giovanni Biscuolo <g@xelera.eu> writes:
> 
> > Hello,
> >
> > maybe Marius Bakke have something interesting to say about his
> > judgements on this "DRM matter"
> 
> [...]
> 
> > to sum it up: AFAIU for users to be able to use Widevine they must
> > create a custom package definition _outside_ official Guix channels
> > *and* download the shared object "libwidevinecdm.so" from Chromium,
> > installing it "manually" system wide or locally
> 
> This analysis is correct.  For DRM to work, the user has to build with
> "enable_widevine=true", and then somehow obtain 'libwidevinecdm.so' and
> make the browser use it.

Can this bug be closed?
The wording is very vague ("may") and for Guix to distribute widevine.so
legally, you have to get permission and sign an NDA with Google, both of
which are reportedly hard for 3rd party devs even, not sure how hard it is
for new operating systems. Your stand on software with NDAs should be clear
(as per policy not applicable, no NDAs).
So even if traces of the code to build this might still be left, you have
to master additional steps to make it work, and after having read some
of widevine.so I doubt it would work out of the box with Guix System
(elfpatching could get it to work with Guix, but you are still entering
the field where official distribution requires legal paperwork).

Marius Bakke wrote on 12 Oct 2019 13:32

Re: bug#34565: ungoogled-chromium may contain Widevine DRM

Recipients:(name . ng0)(address . ng0@n0.is)

Message-ID:87lftq2o7v.fsf@devup.no

ng0 <ng0@n0.is> writes:

Toggle quote (21 lines)> Marius Bakke transcribed 1.2K bytes:
>> Giovanni Biscuolo <g@xelera.eu> writes:
>> 
>> > Hello,
>> >
>> > maybe Marius Bakke have something interesting to say about his
>> > judgements on this "DRM matter"
>> 
>> [...]
>> 
>> > to sum it up: AFAIU for users to be able to use Widevine they must
>> > create a custom package definition _outside_ official Guix channels
>> > *and* download the shared object "libwidevinecdm.so" from Chromium,
>> > installing it "manually" system wide or locally
>> 
>> This analysis is correct.  For DRM to work, the user has to build with
>> "enable_widevine=true", and then somehow obtain 'libwidevinecdm.so' and
>> make the browser use it.
>
> Can this bug be closed?

Yes, I am closing this now; thanks for the reminder.

The actual Widevine implementation is not part of Chromium, and the

interfaces for loading it are disabled at build time.

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 34565@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 34565

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date