ungoogled-chromium may contain Widevine DRM

  • Done
  • quality assurance status badge
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
J
J
Jason Self wrote on 19 Feb 2019 04:44
ungoogled-chromium contains Widevine DRM
(address . submit@debbugs.gnu.org)
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.
L
L
Leo Famulari wrote on 19 Feb 2019 08:06
(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlxrqskACgkQJkb6MLrK
fwgzrA/9H0FJab93kOmGGYimb34J9kyy4Eu0WPw1E1owf80l6HFt6cCBsbxoEwxl
n3kgryTH5eUfcEuhErUUY19SnduA7hRgHz77VUpZHw47HFN5s2Psk0Q/OlyKRQ0R
uccDXD4NOhS0s7gmM9wcaEQjccolYDcurdfKcvpRPqJZCoNk7y2CYZclX81ELIwF
0JBK2vQ0zypoXza0+i6uqWwAxjZ9VxH+r68+s/X2j0TApeoS3HS/ssIEYsbVKuUT
heCKsx/pJjX0jE/krV0k3554KnIyhn/VvMXWOV7oQvujWjrTzbsxpXLltxkHyNkl
l2d/ny4SjqUWzkfMfYgSwwzMTdUeMflbRKaXlPRAcNN92tKEkrImX11NBDMnZhh4
9CTaoHe4unR4UUy5M+Ek4xb9sh9T4lUcQ2puNFB5SSFth+OdcwVC/EAwtLx0+OIM
HBhSCw4c1l//7zB9Sh2dC0c64fRtAN5Zd5sS3FQ3PSiLRF/XJIHqXr1dlUFnSzAv
241g+tNuTJvpwwndy7a9fVPNfa0b2Sbqs7+rWAz53CtDjYKJFYokug2ZTUntltS0
rqq0lHvVpAtSgsqNTnh3JOtSWCFsZ2HJJbDWCRxIUrOEJDBSzx1D2gpvLXcuRnhg
d3KqFIduVTaW79JEIx0kqpvgLqZLUBBhi2mGJsA5wZBlAzRP+6g=
=v/ZO
-----END PGP SIGNATURE-----


J
J
Jason Self wrote on 19 Feb 2019 14:28
(address . 34565@debbugs.gnu.org)
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?
-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJcbAR6AAoJEJ0NsxtUWjGYe9QQAISDtgdlS9ieMNmlYCNB1VON
D/TssfVcjWwMLkwPoYQ6nmojja0UtpVNPTs+4nvm/+dELwwCjIxVioLa335iWZk6
4D3chC6y/6lgybLFC+QV2asnqz/qGfOqKHAbwpPTXWKZ5A7rA7DBva4I/5nGEquN
LEIPpML4u6O3PqEpKZvgie6IWKMsFiJ1TjSa+7nTB5v9n78T1p6GHsIyoef7tXxK
pF7JIhv4QEys/gYpVkRRsyeF6NIyPo7BFECqBf5slZDQCeWChTXnlV+eQGJoFMn5
biSQziysBdSyviHMDQ7j8bt4ECE8WuCj4GOxVzYhOpa8t5Zh7IZ9e9eL0ti7Q7Pg
uGguUrJmL9cNrJYQYjJ2fQOxYnZ/B6/ECCDRuCDjmCoF0oRe5BC+f0UYzMAvnmkF
5+ufm91g5tO1WtV1YfyCzZ3tzqLd7ON0nUxiaqtsRfA6zekQAclqhnMnTCy2Q0vX
edIzFOtfthWAoR86d8IBW1wTH9QwtJJ/ku/+W1R7LorlQT1kEvojaOsTLrjTYPC1
EqL8AXIy5hMEJboEW1druos+r49ARGQ7+GM8WGEgy8TLZ6g9/WTfa2w1hJpc3ZG1
m83psCDaFDAwROAKASDD9yStL8qe+e8OLi7A4PCvPM1MlBYKvnOpi1gX+iG+01VP
Exlw9keWXMQjsBwOlJS/
=OPaZ
-----END PGP SIGNATURE-----


J
J
Julien Lepiller wrote on 19 Feb 2019 14:42
(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)
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?
L
L
Leo Famulari wrote on 19 Feb 2019 15:43
(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlxsFhsACgkQJkb6MLrK
fwj3sA/9G+BmgkEAnYEe41qMs90eVYG2jtYDRvS9S6AkXVSdKUv1TecFDAvaMddl
ymWaML/6YvRPW/9c09g+iUjkToBYTcymdD59c7GWhR73MKcZb3i0DScU/nDllxhs
dh6MqRnElK9D9Ej4Z/66y7NrrSD/5X62FXfmPDiNTP0BbAS+8FPKWLkItle3LSzA
tJUmr47wvBl+fxtSf7r3eWzj5PZk1wvBmyKHC+a8JvylK2gcg1PKVF8GnqQhgdKF
t/bQ5gnG1Gq1u9Um0rprza17gQjC6U+AG7W7VA9CkcBLVkY+FyQte2C1XmPSfIyD
LQQ3V+EL8l6bNEuE7c+x4OWWudSkRqp8xG9JbfBvGycISBUnhzZdS/C7Po59uh4S
mrGqYr1pqmIF1S/KvfphOpPt1gs0SV2ixMvPrgr4WM2lxX9UdOhpJf6PYUtLC3Yp
AB6s/fXxC2QEKBUsu6ba6SzH5660jXU9We+ywb2TliluHql7tcsivUOX3lEWc44w
A++8TltYRhdgvufgIQRqa/41SxGH7H2DiLIRC2oMqfr3wNDty1+deeCwg1NclCAV
qLUhvuEw4rOS3+VdxZcTbP4Jc/qN1Lgj9x5JnBGGucxwz3yB/H3l/szUPEz11UlB
pZvPEY9BzuP0jkLlM+qHlLGQsXmJVm834SihYPsOvdD2RJzk22M=
=Wnx/
-----END PGP SIGNATURE-----


J
J
Julien Lepiller wrote on 19 Feb 2019 15:44
(address . 34565@debbugs.gnu.org)
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!
J
J
Jason Self wrote on 20 Feb 2019 01:39
(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJcbKGwAAoJEJ0NsxtUWjGYmGAP+wTXJ80sklDLx8lp9VPxPELo
Uhu4JVBHN53JNEe/I1Q5J5Xu9AzFGbThNoGleL+CPmXGBQVym5KI+2rNQ/LHfNym
qvOGn9twPY7jCh/RhZUt7bSmm0kcKQFdfWAQDb2FaJO1dOEtV9pooWxwMwjgOzNw
1FINrdBHdDfWtjvQ2vafmQAVbjaqK9mjNTW4sE26GGKOgscRsD3uoFm2HQFEptku
Md/2I6te4KZnLm+320DGvSgWKcC5AQwVsEtHcTB21LfAk4rGZwn8XGtdH+Xagsm2
NVKevpYDtepTrxwQuxY1Cd1NSQ0VaDcCs8DrKX6SZaWCmQiXKSrvp+yhEX3P69di
orldJkCqFLNGymGEmzyQ6LPaSYIlcpFHdxZQQ7kop/z7tUyxBdsQeMjPMcyHWLt3
+OkDHGDO6jBQHxPhxsUsAK9gqCe5xW7zWk5BQZzj59WurajTXaJXR/lYlHzs+EAG
PS6VQ9RQZ0dQQWObag8HbuTW2xyRwO8xFY/o0u7+r2iB5zg26BjJhFELouP0oT2P
omcEgF8Y+4OWgnO0FE7U5M+74f6ACNKQ++PrLNw9dkur89dHIsvDd3MCp6yEuKfq
mG2zJX+P+Jg+hhPVDXA99jaJ3b3Uw85+Ldvrz+QLEuXT6+z5oH8d59RfgYTdPL2l
HnGfn+otxauemJ2jE30H
=zN5H
-----END PGP SIGNATURE-----


J
J
Jason Self wrote on 20 Feb 2019 02:12
(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJcbKlyAAoJEJ0NsxtUWjGYiNMQALC0+q6+B4fntdDAW8GLGdg3
NVD4OHfUVWce4bdinEdYLo8G44m6hUxyGAVHVi+VJWKUbFu9z1GZoOKDTCfW7qJl
NO2w3wphY2vzu5DtWfBVzX20PnAvvOo1+C3t9QoJDBJQFfJ2zy8qtq8b28Mvz3em
OagcbyQE3TAktpC3HFuqqlQV9Hdabm5knavdepYyncQbaXmr48epZtARpYsUu+nb
D/ANT2kf6kGgAc/Pg/8TW5qDMYufXZQdfeys3jLHoxYiHi2pxDEPsWNnIoUbXiwY
gRNQ4eRFWG7zFuE4BZboimjJFnWYnTI2MDrCZ+lECukQEWDIjCUd38Waa8RmJUFB
g6p0tf9LwEBRcDr+JIWCZMlw8+Ph+0HQGetx2DtjQDb59cJYgo+C6L+Xl5JhgSx3
zykZPPpQpZRf8k5uY+HtTJK9/0xyaarEJhafGE7fK0KuwW62qbwj2Evnx0Tw+8jQ
oeEjVouZb+SkpUvQUJazGtsCi3UPqD3yIBXfBik/zdSUGptpMrUzCOHBm7q/1BsB
2hegh1nVsvBVM0HLDrgwTqxBsYaD/c+ZP0YII2MJjl94F9eBiJ17FRy3mWNlgfg3
mtVnyjGwhA+EK0gn05YsnsPm2WXfJu92w+BF2vY5oSGiBIXxGrM8VMwkKkd7J3Fe
RhzK3O7wtTW2/Bff/PUP
=IL5v
-----END PGP SIGNATURE-----


J
J
Jason Self wrote on 20 Feb 2019 02:19
(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJcbKszAAoJEJ0NsxtUWjGYptMP/03CoxIb6qFWOuDbHi1bf4CS
VyWKv/OFofuPghUSWnoNWs8ugvZZma3bc4Ak3UYsR9XCWIR4lIvn30qgSczA60oT
gfB8MVUp/k0c87fufQ8qbZQRt0DdOdkYGkJOll6oZOqh8qSyRX+3DUGq9rL4wvi9
hjfELcTThu+0YIZBt+QKLSQmlPEnvMbUtJSDZ5UizUXVNktxSvbLdhg813yBEjAl
prWr9Fe1GdUrmCeCpz/OHMJGpkr157ALxI2Wal7JmaeGKH3oFMzIOAqvAL6TWEJY
wD3sWArALoLKGrbtlu/dMpbB7J2qhyR0CH2hKASixwyl+pjd8mSzPDwyHK+/YQWo
2CZX4hipXPTsb9ksTr4dh5Ai9OawjEtIMU0NohZ2oErPAW25sXmZWjkTpZm/MMet
ur8sBsBcvCA7Bq5tawDh8FTMXGbBXiy3qBH8IyxGvPevs4NovybzkoZpqLfs9ySa
0lzyklJYPrxPSeLTdCcNAKp1lUxkunMsQO7gv3jFLRvgQJXD8cHZFqXfJ0NnFkdd
ak1r95g9woP3QrwKcVz5xn99Kz+ZdS9YhUVC01OGr8Oq7Y7n2yxCYfWNTkahwcyl
2olj1CDhT8Hj62ZRC2iUtmzSiizNl/be2d9TEiUZO+YjG34jpHBMiFcDKIC1cUj6
bYdauzexlozdupfqcGB4
=NaxA
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 20 Feb 2019 06:15
(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlxs4nUACgkQJkb6MLrK
fwhsPw//TGH5826MuUVxzsxjlYgNWfcLworp6z7LEQmhq9SjjyX2gCa76bCQTyHi
+wAGo2GCnYIGuV/jMAZj/dyTrpsJjd48DQhYeEUdilQPh6ktWN5LOxj/R68mp7eP
BVTizKe+vEbJ1iJcK3B4F7UNAlRWp7ur+4gSqmFdGSd3y9EIwPgfVBTMjp0qleVk
ddJYhRYpHNmcVPcgVbyb8JewFn7ctOPsBGfpZqieirbDJRq+sjVDs2DsZzE+l+dk
C2U86gQfLM6/vGwCV9Ly7yXpxf0XvdVZrowrU8M+iGeBmpvBCBY+RwF/jE8EKg/7
i+I00wMEF8XtzC0eP3JyPxGOjjD/0/PMIhtuOE0DNW4TFkYhKKfy57ZnTA1P+8Co
yvZUyl5eJMuGy6QgYUGLbrVERS9ib7CVTWEAUoP4CBuBuj4X+LfnTyrHDRUY76FR
3SAgWQIvGkGQ8Bn+uii2UxgYhZWK6r8wTirGuu5Zjzy1vNcdaxNr5EQDu0jcxfBl
QpthGuq1fZX8U8kRyJ/OCSFyUdE2hpcDLYL9xzF4d1/J30s2s6X3LU+CBhy9c86a
05ZJNHY8wTxMtWBkq80r7HSC4jf80R2bHzjc2C0uUzpImhdQXdaFQ+dmmPLuUd5p
h9dtxEu2CgEhrDvennldvD6my8ZSA/ig6scVOy+FbjWm56/pnc4=
=vUdq
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 20 Feb 2019 06:21
(no subject)
(address . control@debbugs.gnu.org)
20190220052150.GA8951@jasmine.lan
retitle 34565 ungoogled-chromium may contain Widevine DRM
J
J
Jason Self wrote on 20 Feb 2019 06:35
Re: bug#34565: ungoogled-chromium contains Widevine DRM
(address . 34565@debbugs.gnu.org)
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.

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.
L
L
Leo Famulari wrote on 20 Feb 2019 06:42
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlxs6LsACgkQJkb6MLrK
fwhX7hAAkH8/9+45iJyItVt5t/tP/qHhK34m+Vc+tkrk3+BaCev2AFP45h8i57oI
wVXq8VGff++j575zGbZRV0+PHaOinAEo15mTWIWbpes56LM/LToOrpepd+E1ikQN
TJGqzWeus2VFWW1rjwPNM5YWcjNBBOQMSENkJkOWT5p9HS+oFaKsXsl8q5A9+bFP
cruwMyp0wmU59tdoSibik5zKcX2bI4SgWW69vGhh57lVLHtm7sKUSPySamnthTEY
wSOzBMuIYOv6W3TS7cuiMqYqT8hpPbUxddJyysfrQjNQNQ2sWv5CqVj5gSSNXQRy
H/OGQ6j5tnn+tuvSSAsP1c7d2P0NfgB/PdrmfIj2gzy9J3mxfHF2ZLzjsuRpzowG
OlxgoEF2XlZtESMvDXrDyFtRlk7KwPL5qsVOwIOW9UbEfs4sCPiUhB2iXFOQWqwJ
wwTRycbefAwzNckMsrd08Z5tegq2QMYE/yHaFCEr+p4tjFdnXWExe03sd/3IrSE2
F0DR/eRQaXf0fNP/ZqMYmG0+NvXBy4lc6GCmApgq5cJS6hkw2mtkhUNiiPKz/1hs
NyHHNNnTmJ4rR3NpGzfnXTPjPmftWk+S/hP/6uCNRPUWcXlLrfSq6xLR5aESHJBF
fuLzS9Agw+sb3j2Hcno6alIXxF5fMrTTyGV4rgR0uypx8IZejh8=
=24ni
-----END PGP SIGNATURE-----


R
R
Ricardo Wurmus wrote on 20 Feb 2019 08:59
Re: bug#34565: ungoogled-chromium might contain remnants of Widevine DRM
(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)
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
G
G
Giovanni Biscuolo wrote on 20 Feb 2019 10:22
Re: bug#34565: ungoogled-chromium contains Widevine DRM
(name . Leo Famulari)(address . leo@famulari.name)(address . 34565@debbugs.gnu.org)
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]

[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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERcxjuFJYydVfNLI5030Op87MORIFAlxtHEwACgkQ030Op87M
ORJl5w/+JddYSZeBKTdqiGMOuJo6h1oWsJB5UgW5+h8EBsrbZSRRRO9RtF2UDLus
HAQwJX3JDowo4lMb5DUERHUHPnbACvKQFWBwDeuWK+jRdo+/naodu4UPX7/gHerq
pwyYjn30Zxn6GXtdnKkISGOPXrGqpi5dJChcIpSDwaQkTn8G7guPM3KC/+mMjDeE
OnDTzhoqXfM/YyKQIXcOU823HH9Jvb0vJiEfzBmg1Gty7KzM6jJew6yxFPtzaseN
SiD0hZj4U+9ZAcGhEFE0zn7BXTsadUUsX09pk687vevi2Kk69fskLviZJ6Id56yc
ebuRZ7C2Ao/2g+nr8nU2cNWKi6DDOYEKF8YXbZfheT28s0ojkLTGH87M7q6sZNVg
IE5Cmp4pxTXKE8LvcPhED/QODzw4Ez+nVEozT3/+JBoUuhkl4NZbgNN+Wuz7rEcz
C4XZpc075JhdnnudzY4P9mbt9lJnHWwSrX/xIpRlTRguRrnSV671LkHUa7HWmVQA
tNO8tLWXHlKRRxIAVOPCsyvoP8PRlpxugrIaoORVC1f4YqX7XT91aQshTWiygtrp
6NBCLmpG6AvTj6yUOoMiJFB3iFNfPLVuyMC3AwdR/hHok2xpG0ae2QQY9My131I2
49z9IiGNxYM6F+TDbkgxSH5Uak0NvQuSF+Emc4GmQcWWmohNC/Q=
=3yTE
-----END PGP SIGNATURE-----

J
J
Jelle Licht wrote on 20 Feb 2019 11:09
(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)
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
J
J
Jason Self wrote on 20 Feb 2019 14:03
(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJcbVAkAAoJEJ0NsxtUWjGYn2gP/ixSgVt8SsabNCn8CLnq0wXd
cwnudZoYBrvVc26fsO+px1yH+Om24UHXRlwKjfsEnaZEW8G6EUSbYMWbqOxwVvHB
ktinWyp0INAriLPsdCy6PgHnOy5rSA0JVLkFTopY4Gfefn4ha/VBmXeedb8uODeZ
a1Uaijnr18j6F6Db1Hoe0cLp/9iM2WbpkoQ0SFwdxWCXNRq1w8r/Xd2ZEvds/l+B
bWEF1c2Yr0MonG8krXQukfzhgIHEg+f6LUHlO53wr2YQMXYM97H5BF6EKqlSCc6k
EEI0FZpCCPpBphDz9DJMh79rqXL6r8XrDJDet7jhVJ20Qg5onJqsaBL6W+chIs3q
BmqWuVEHa3nvURerNBEMgZiPDZt0SfbHaZrDxjoA9zUBbKMRm1d4vJtK2NNXauNQ
Nc0059VUN2jslCO+AsEL1SCP4C4YRiMxRQGgBbeU8mefDSIM8k3+9N+dQhwESVpU
5i5qRpkngIHf+S8aOA43vDP7bXrupgu9T6awX6og0Ptsw6lxsUihBiX6peVDvYTG
ePzyWuQb2XpxGqPkGTVD9ihlaoLRypnY3X7rKwtgRcqb2qm+IsqUs1kuykzuSQqS
fz1mLF4Rlbv4Ss7dIeJtz2JgLPX7jUc3GPtpTmNQVG9gXhlrIFqIW64Wcpoyyxpj
xyFNQT/BjuAO+3tykA0Q
=Lshi
-----END PGP SIGNATURE-----


M
M
Marius Bakke wrote on 20 Feb 2019 15:37
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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlxtZhsACgkQoqBt8qM6
VPqsOgf/SymCu2BiYdx8tadD4zwI1gkUYVznrflJYFeHTQuF6cx7vmMxL0HPyPTM
gEQEm8q3EXdvHOpY/j5eW/KwSv5O5/ICwaHk36zvA3AVQTgzpXfvQNjjtxRT5rIq
eSzVDEGtbsX1X+mZCeXsIv1qoJzAaOT0E9kV8qONEcYvdUh084GAGKyku+2kO452
yW+2iyKGbljWWwevx3IcDpP5Vuy8IctY224sXIH6p5LrEibEX2Cw/3PWohjse1j2
GOrVPAD39oggU4hIoHbXKYMYX/fDAHZlfFLW2mjS5cjEzOV9IZpld1rHS1w0W5i+
PEp+/7Vq8B/SvX/AxXV1zRLKljw60g==
=AyoI
-----END PGP SIGNATURE-----

M
M
Marius Bakke wrote on 20 Feb 2019 15:48
(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlxtaNMACgkQoqBt8qM6
VPotoAgAwQNR32dh2V6rnTLfpdqzb4INoSKuM6Z2LLwqrFJDd0UZnS7EqBWduZ4A
MBkRWvS/B2kN6v65x1rUT/2XN41vYzoEfTMEit5or8eH4XqnqFL7WkpeEVmjacVh
Nwk16giGflLlVwahyIMgHDzaiasZUeoqB/lGLHA+669GVAywPQ48dsLuecTz+FRP
KDaGGhSccTStHja6lDrDuG5LULPXbtZ+VKjV44lEFrC+mN697NujfT3UaJCLLJ+I
QmPgEObPiK8PCBYdRYdXMuJNnAw0K6zU0x7hdvGXpX7g0LG3gkYygshMHzyHZIBe
dQqv7TfA/5N9J+KaySHqLMFZtahrJA==
=DLQ4
-----END PGP SIGNATURE-----

J
J
Julien Lepiller wrote on 20 Feb 2019 17:18
(name . Jason Self)(address . j@jxself.org)(address . 34565@debbugs.gnu.org)
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.
A
A
Adonay Felipe Nogueira wrote on 20 Feb 2019 21:15
(address . 34565@debbugs.gnu.org)(name . Jason Self)(address . j@jxself.org)
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:
- 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:
- 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:
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
- Use comunicações sociais federadas padronizadas, onde o "social"
permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
#DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
- #DeleteNetflix #CancelNetflix. Evite #DRM:
Attachment: signature.asc
R
R
Ricardo Wurmus wrote on 20 Feb 2019 22:49
(name . Adonay Felipe Nogueira)(address . adfeno@hyperbola.info)
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
J
J
Jason Self wrote on 21 Feb 2019 03:19
(address . 34565@debbugs.gnu.org)
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.
-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJcbgqzAAoJEJ0NsxtUWjGYhi4P/1pB19ZHhMp5Z/C6OuvKUlT/
foJ+vuUbltzazI6FPxwnu1VNC5pyMcDVNFd6KzzwwgGlQrEj2FOs/jkjRR2YjEfV
Oit2SyX9O0Vt5SH5S04ejquxKXLRrose7s7qO7yi84kOMfA8v7bUVM7SPdyBG4zP
GXToTodOeNVgr0HMhst3AVC9ul0YqeF56Od0EwjiTitDam0hHycKy2w9rgz0sScf
A3v1HpMzXrepXfROcwlblxHiF5Nsy4zSGiJ5MOK/UCQFz7SZLY2RINFnZHPrR2mu
njj71qQRSlXWY9ebBC0MoE/gOh9FWXgJTWWyuRVb/x+D9/NfDIlCIzp2Ztr3GUth
axArY0T8HRzh132a2sWtLnObxe1/dsjhmzm1TRhzMm7fYJkrwo+vOWUenryOHexA
kkXvrPhH4/PAIdUSZKqtoX3+FSkBzgizatylMdHuLWIKSR/BQeAetpiCTn5pj1ty
eTqNdycrdYwE+s4jSttUyO82ZEVkprZY9C9G4AxVUSmoZ5B3icjISXQVJdxdP2vG
jiofpqfkHoq0Moc3UkvFhF6ebItgd1TqsjW7gA+/m6i30e4UdDAg933I9eiQ5Gwj
lfGXhd+IIV6qLhXpjokGqVY+awaeRBkIuUtzY6QrgWCWuZ5Cgn7OVOntAGGKaebx
3MXPuzTXMU1rrA5sn4qL
=l8JR
-----END PGP SIGNATURE-----


J
J
Jason Self wrote on 21 Feb 2019 03:43
(address . 34565@debbugs.gnu.org)
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. 

1.
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
2.0</a></div>

2. chrome/test/data/extensions/api_test/wallpaper_manager/test_bad.jpg
contains:
0/

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

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:

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.
-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJcbhBFAAoJEJ0NsxtUWjGYjtAP/3tqhVnUuT0mv9mANEm7RBWk
8RupJmjA+LQkxoao7QDM55DcbzZL2zvlHnnvyjnoJnMyq2xwqliQ4JmBq3fJGn3T
Zw1mDnvHRmfFEFDv0yOXG1MyYLVBmr3vyBrCjOsCRnuh8BPTpA8F4WYvY3CcYnLU
jHKoUDYd7PTLffGxHYftVJbujX9tZPo2M7/6X90uVWYcLzC1W+dVRabPBlkR8Zvx
I/b6HrMIhU618zeWgUvkdhP8+UrmHlaoaFefeXkH8VThHQKuaiP8Us6aw1ohxsha
lyURXL9gXKGXDFjVrgsJQ/+ObfKIuijAwXN7d9g3FOzKp5fFnR73+SDt7y8sdMoh
S7jgpXQWKqzKscTJGlKGIdX1impVHvmxq9vmrMAnaQuQVt5UWlKn2y5tQ3bnaEpy
83ZK/IbopnE4EZ87eEq1uS+ThK/EvKfEjIY1RYjAkw/rrJI4vAj1aqCU9KuMkKD4
x7dRtjY4gtiKXhH2qpf6edKC43V/T+8g8XfX3zM3YykWHZHkw8FOnDZoLHzN7xFx
Qze7G7gtcjz+BzHnbb8WaACeCKGsJHEVPmjXsDMm9fDzE4HsM38fc9mGcp/OiSPF
je2897jfYbKYmijt1qaVuEOJM882nzHjQsIxuTkMCNZAUFchVK9A1B0sQrZlIMfj
dTjGDMmzojRO9x0LVWG6
=ezW/
-----END PGP SIGNATURE-----


M
M
Marius Bakke wrote on 21 Feb 2019 08:51
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!
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlxuWGgACgkQoqBt8qM6
VPo+Jgf/Sy7SS9Pl+GpZ0AJ+WEueR6dO/eVtv37l45cgppEmpMDrEg+FWoxwVcvF
NSdIXbDdkTkncFQU0PiTB0+2s4DqaoWrnofoKn0CDYsyOy5pmbBupZJP2Z5J9UbX
moTT/3VYzpP1xtKi1FhgFdSvxDk8X8NXagGl0ZeUSeQMdDJJiPlsuCq/d5SkP6LW
AA5hoAtLImRdtMcp3Btr20a+SBtgEBWNM8A0IX+lW3bHBlC3Qw0DaVWLRPMmAwL0
xY5IikT5Jv+knd/zb3iJ8kydMUHOI0Y2bEA/GPMywucuRFCXyiSBm2aisp/W7etN
wnvD32ZrLVqfsthypYjtLh0B7wYs1Q==
=T/h/
-----END PGP SIGNATURE-----

N
(name . Marius Bakke)(address . mbakke@fastmail.com)
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).
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEqIyK3RKYKNfqwC5S4i+bv+40hYgFAl2htYkACgkQ4i+bv+40
hYjG2Q//d7H86A6PbQCJ+XD+PFCaQyNNEIe8CHjqaP2Uh97s6BQ5m3fOlLYp8wzw
fKs9c5WKHU2cWhV/ifOPufTh0z3U+1jY80cpzTfbT+JmOA7Hmk/8L0oegtGgKQrj
bK2ecA3TabsB4JbtPKDsUdzuhu00XWFOlUtMtont3ur2eVZbN6Y1NhjDL71qXWk6
OVWk7/bSVDch/2W5R2S6YzbZDGl2YbMFjwHrhQD/ab06rQR3pTDLDdvYL1NzemNI
T5D6dV1NIbCbxbhf4+e6coImLygAuzCUE6Ujwy9LXVAfPcpeQvnZ7tAypeHt7jC6
CWN/+6Pq1RUV3QHL9RRE0awGR0siEJJvRJfBSho8qJJtog7dBFrbF+h0leALqoVp
iNyk/DiWUYT9IWXCaCGkjngCYmrH6ycarBvP3tkYw9viDLZQl2AA5cDFaN/ddNUe
A5qajGdJ+zMqRmxVhxDPLJr3gnsJc+ZOs/9o1cCNmU2Zs7hFMY1MdgEyGaf+KE0K
7ImAopWZNA+eDUP9/zuuwdWaWssmc2s3UopO59Q44pfrvwPB6+AbdsL1r/wtAdtZ
VHS/tlR25ssUq40rMianw77ClkLvHJTMPxRH0jG/ltLmq5DDZbJR9y/WbQQVGKfI
4zFVfyEqFgYcie3LQzCzHenYytOMgWWftH2+E7KEUj4oDignWrY=
=REzv
-----END PGP SIGNATURE-----


M
M
Marius Bakke wrote on 12 Oct 2019 13:32
Re: bug#34565: ungoogled-chromium may contain Widevine DRM
(name . ng0)(address . ng0@n0.is)
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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl2hueQACgkQoqBt8qM6
VPoDFwgA0IBYI13YDCMtuIE9ojoc8iremaTOF/dENwhDZb9wyQfnG3cGr/CSbJv3
tWesT8TEjG3JfaCAaV3bOKJex64d3N9n2XE6uc93/h2aPMQjncj63/uOEJw6Pcuu
7YuxT2XJMjgfL2l/Vunj9JELSBuMo/zYYQukh/BAmRueM246x1ZILBpXC8zVoR2C
vGAfVs/01Hg5LnLfo2NhXZBJGl25oF+uN4sSC1rdr+VwSQCZrGbAKM51xeLE+B/0
VGVp4nv/yTE5jJQzBLlSBdVWh9TwoRmKrpFqZWzwr/0O54xltDP9IvXzBszhsirO
uPE3jEtlcysIERGkE+HPAI6Hay88ew==
=sJ5i
-----END PGP SIGNATURE-----

Closed
?