Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Marius Bakke]

Luke  writes:

> On 02/20/2019 05:10 PM, Marius Bakke wrote:
>> bill-auger  writes:
>>
>>> On Wed, 20 Feb 2019 15:50:02 +0100 Marius wrote:
 That message says we are no longer using a _fork_ of
 Ungoogled-Chromium. Earlier revisions of the patch was pulling from
 my repository[0], now we use the canonical upstream repository
 directly:
>>> but then what do you do to the upstream sources? - we all agree the
>>> upstream sources are not FSDG-free - arent the ungoogled patches the
>>> keystone of your liberation procedure?
>> The liberation procedure is right there in the package definition:
>>
>> .
>>
>> This script is what creates the FSDG-free source tarball presented to
>> users when they run `guix build --source ungoogled-chromium`.
>>
>>> that is entirely why i am confused now - it would help tremendously if
>>> you could tell us what you did to the upstream sources that you believe
>>> makes the FSDG-free - like a liberation recipe in plain english would
>>> be awseome
>> There are comments in the script.  Please ask if any of the steps are
>> unclear!  Improvements welcome.
>>
>
> Correct me if I'm wrong, but Widevine DRM and the ability to run
> proprietary codecs is still being built according to the provided
> package source?
> That's definitely a blocker.

Widevine is *not* built.  The ability to run proprietary codecs is
provided by the system "ffmpeg" library, thus it makes no sense for
Chromium to place additional restrictions on top of that.

> Some GN prefs missing from chromium.scm:
> ---
> ;; Disable non-free codecs
> "proprietary_codecs=false"
>
> ;; Disable DRM https://www.defectivebydesign.org
> "enable_widevine=false"

I explicitly disabled Widevine in this commit to prevent further
confusion:
.


> ;; Not XMPP compliant, walled-garden SaaSS:
> https://www.zdnet.com/article/google-moves-away-from-the-xmpp-open-messaging-standard/
> "enable_hangout_services_extension=false"

This option is disabled by default and (I believe) deprecated.

> ;; Note: https://www.fsf.org/licensing/h264-patent-license:
> "use_openh264=false"
> "rtc_use_h264=false"

I'm not an expert, so I'll defer judgement on this topic to someone more
knowledgeable.  My understanding is that the OpenH264 library in use is
sufficiently free.  Is that incorrect?


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Giovanni Biscuolo]

Hello Luke,

I'm replying _only_ about the DRM issue you reported

please consider there is an opened bug for this issue:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34565

for specific issues about DRM in Guix ungoogled-chromium package please
comment that bug including 34...@debbugs.gnu.org

...at least until is still open :-)

I'm not including 34...@debbugs.gnu.org because IMHO all your concerns
are well addressed in the bug report thread

Luke  writes:

[...]

> Correct me if I'm wrong, but Widevine DRM and the ability to run
> proprietary codecs is still being built according to the provided
> package source?

no

> That's definitely a blocker.
>
> While completely removing the DRM ability and creating a clean source
> tarball is optimal, it should at minimum be disabled at compile time to
> protect users.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34565#58

--8<---cut here---start->8---
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.
--8<---cut here---end--->8---

this means that DRM *is* disabled at compile time and _also_ that
libwidevinecdm.so is not included in Guix ungoogled-chromium source

[...]

Thanks!
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Jason Self]

On Wed, 2019-02-20 at 19:37 -0500, Luke wrote:
> Additionally, the patches are expected to be ran against specific
> Chromium releases. Future releases of Chromium are not
> patched/audited
> yet by the ungoogled-chromium project and may leak to Google.
> See: https://github.com/Eloston/ungoogled-chromium/releases
> 
> The Guix package is building against Chromium 72.0.3626.109 whereas
> the latest release of Ungoogled-Chromium as of this moment is for
> 72.0.3626.96-1.

Ah I had missed this. Thank you for catching that. 

If Guix is going to use ungoogled-chromium not only as a way to remove
privacy problems but also to fix freedom problems (although it's not
clear to me that ungoogled-chromium actually solves all of the freedom
problems in the first place; an audit will need to be done) then they
will need to be limited to whatever releases ungoogled-chromium
provides, and updated only in lockstep with each other lest other
unknown freedom problems creep in due to not having been
reviewed/audited by the people behind ungoogled-chromium.

signature.asc
Description: This is a digitally signed message part

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Luke]

On 02/20/2019 05:10 PM, Marius Bakke wrote:
> bill-auger  writes:
>
>> On Wed, 20 Feb 2019 15:50:02 +0100 Marius wrote:
>>> That message says we are no longer using a _fork_ of
>>> Ungoogled-Chromium. Earlier revisions of the patch was pulling from
>>> my repository[0], now we use the canonical upstream repository
>>> directly:
>> but then what do you do to the upstream sources? - we all agree the
>> upstream sources are not FSDG-free - arent the ungoogled patches the
>> keystone of your liberation procedure?
> The liberation procedure is right there in the package definition:
>
> .
>
> This script is what creates the FSDG-free source tarball presented to
> users when they run `guix build --source ungoogled-chromium`.
>
>> that is entirely why i am confused now - it would help tremendously if
>> you could tell us what you did to the upstream sources that you believe
>> makes the FSDG-free - like a liberation recipe in plain english would
>> be awseome
> There are comments in the script.  Please ask if any of the steps are
> unclear!  Improvements welcome.
>

Correct me if I'm wrong, but Widevine DRM and the ability to run
proprietary codecs is still being built according to the provided
package source?
That's definitely a blocker.

While completely removing the DRM ability and creating a clean source
tarball is optimal, it should at minimum be disabled at compile time to
protect users.

Some GN prefs missing from chromium.scm:
---
;; Disable non-free codecs
"proprietary_codecs=false"

;; Disable DRM https://www.defectivebydesign.org
"enable_widevine=false"

;; Not XMPP compliant, walled-garden SaaSS:
https://www.zdnet.com/article/google-moves-away-from-the-xmpp-open-messaging-standard/
"enable_hangout_services_extension=false"

;; Note: https://www.fsf.org/licensing/h264-patent-license:
"use_openh264=false"
"rtc_use_h264=false"
---

Cleaning these modules properly would involve patching them out
completely and providing the cleaned tarball for end-users to compile.
Ungoogled-Chromium does remove the majority of Google SaaSS during the
patch process, but does not currently try to reach FSF compliance by
removing any of these proprietary anti-features or providing a cleaned
tree.

Additionally, the patches are expected to be ran against specific
Chromium releases. Future releases of Chromium are not patched/audited
yet by the ungoogled-chromium project and may leak to Google.
See: https://github.com/Eloston/ungoogled-chromium/releases

The Guix package is building against Chromium 72.0.3626.109 whereas the
latest release of Ungoogled-Chromium as of this moment is for
72.0.3626.96-1.



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Marius Bakke]

bill-auger  writes:

> On Wed, 20 Feb 2019 15:50:02 +0100 Marius wrote:
>> now we use the canonical upstream repository
>
> maybe im just confused about those words - this "canonical upstream
> repository" i assumed meant the chromium upstream repository - i was
> under the impression that "ungoogled" was just a set of scripts or
> patches that must be run against the chromium source
>
> perhaps that is saying "ungoogled" is the "canonical upstream
> repository"? - but if there is no web browser source code in that
> repository, i would not consider that *the* upstream - chromium
> would be the canonical upstream, "ungoogled" is more like a
> third-party helper tool

Sorry for the confusion, canonical was probably the wrong choice of word
here.  The Ungoogled repository only contains scripts and patches
against the Chromium code base.

Earlier revisions of the Guix package used my "fork" of the Ungoogled
repository, that is no longer the case.


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Marius Bakke]

bill-auger  writes:

> On Wed, 20 Feb 2019 15:50:02 +0100 Marius wrote:
>> That message says we are no longer using a _fork_ of
>> Ungoogled-Chromium. Earlier revisions of the patch was pulling from
>> my repository[0], now we use the canonical upstream repository
>> directly:
>
> but then what do you do to the upstream sources? - we all agree the
> upstream sources are not FSDG-free - arent the ungoogled patches the
> keystone of your liberation procedure?

The liberation procedure is right there in the package definition:

.

This script is what creates the FSDG-free source tarball presented to
users when they run `guix build --source ungoogled-chromium`.

> that is entirely why i am confused now - it would help tremendously if
> you could tell us what you did to the upstream sources that you believe
> makes the FSDG-free - like a liberation recipe in plain english would
> be awseome

There are comments in the script.  Please ask if any of the steps are
unclear!  Improvements welcome.

> this audit would be an incredibly difficult task even with your full
> co-operation

I don't understand this statement.  We all know it's an extremely
difficult task.  I have done a large part of it and am glad that others
are joining in.  Do you feel that I have not been cooperative?


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[bill-auger]

On Wed, 20 Feb 2019 15:50:02 +0100 Marius wrote:
> now we use the canonical upstream repository

maybe im just confused about those words - this "canonical upstream
repository" i assumed meant the chromium upstream repository - i was
under the impression that "ungoogled" was just a set of scripts or
patches that must be run against the chromium source

perhaps that is saying "ungoogled" is the "canonical upstream
repository"? - but if there is no web browser source code in that
repository, i would not consider that *the* upstream - chromium
would be the canonical upstream, "ungoogled" is more like a
third-party helper tool

sorry if i am confused here - i have never ungoogled anything myself,
and i am trying to understand the actual logistics of this

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[bill-auger]

On Wed, 20 Feb 2019 15:50:02 +0100 Marius wrote:
> That message says we are no longer using a _fork_ of
> Ungoogled-Chromium. Earlier revisions of the patch was pulling from
> my repository[0], now we use the canonical upstream repository
> directly:

but then what do you do to the upstream sources? - we all agree the
upstream sources are not FSDG-free - arent the ungoogled patches the
keystone of your liberation procedure?

that is entirely why i am confused now - it would help tremendously if
you could tell us what you did to the upstream sources that you believe
makes the FSDG-free - like a liberation recipe in plain english would
be awseome

this audit would be an incredibly difficult task even with your full
co-operation

Re: [GNU-linux-libre] question about GNU FSDG compliance process

[bill-auger]

On Wed, 20 Feb 2019 12:24:47 +0100 Giovanni wrote:
> should be updated, since there "The List" is called "Software
> blacklist"

i agree it should be changed - that wiki page has not been updated in a
long time - my suggestion was the "blacklist rescue list"


On Wed, 20 Feb 2019 12:24:47 +0100 Giovanni wrote:
> and should be open to be reviwed if someone finds a way to liberate
> one of the listed software

absolutely, that is exactly what we are trying to do - unfortunately,
the only people who have claimed to liberate it to date, have not
yet shared their recipe with us; so there is nothing yet to review


On Wed, 20 Feb 2019 12:24:47 +0100 Giovanni wrote:
> this is in direct contraddiction with the concept of "the list is not
> a blacklist"

no contradiction at all - these are my very words:
> > a blacklist implies that something is to be shunned, and permanently
> > so - the main point of that list is not only to point out programs
> > that have known problems, but more importantly to offer known
> > recipes for how they can be liberated and used in freedom  

the only reason that the chromium entry is *essentially* blacklisted is
because there is currently no known liberation procedure - everyone is
hoping that someday one will be found and submitted to the group for
review - when that day arrives, and if the proposed liberation
procedure is agreed upon, by consensus, to be FSDG-compliant, then the
list entry can be updated to recommend that known liberation procedure


On Wed, 20 Feb 2019 12:24:47 +0100 Giovanni wrote:
> _word_ (chromium-browser) included in "The List" is even more
> embarrassing

the 'chromium-browser' has been shown to bee non FSDG-free
on multiple counts, definitively and repeatedly - just yesterday in a
very cursory review, jason point out like three different things that
are clearly not FSDG-free - there is no doubt ion anyone's mind that it
belongs on the list

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Jason Self]

bill-auger wrote:
> the most recent news regarding this (what appears to be the official
> release notes) indicates that guix is no longer using the "ungoogled"
> team as an upstream[1]

I think that message "no longer using a fork of Ungoogled-Chromium"
means the opposite: Whereas they'd previously been using a modified
(aka "forked" version) now they're using upstream directly. Perhaps
upstream made some changes which made it more suitable for their
purposes.

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Marius Bakke]

bill-auger  writes:

> however, now to add to the mystique, the most recent news regarding
> this (what appears to be the official release notes) indicates that guix
> is no longer using the "ungoogled" team as an upstream[1] - i have no
> idea what that implies; but it does appear to make the task of
> determining exactly what the guix chromium consist of, significantly
> more difficult

[...]

> [1]: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00367.html

That message says we are no longer using a _fork_ of Ungoogled-Chromium.
Earlier revisions of the patch was pulling from my repository[0], now we
use the canonical upstream repository directly:

.

[0] https://github.com/mbakke/ungoogled-chromium/tree/guix


signature.asc
Description: PGP signature

Re: [GNU-linux-libre] question about GNU FSDG compliance process

[Giovanni Biscuolo]

Bill,

bill-auger  writes:

> the first thing i would wat to say is that no one wants to refer to
> that list as a "Software blacklist"

it was just to point out that this page
https://libreplanet.org/wiki/Group:FreedSoftware#Related_pages

should be updated, since there "The List" is called "Software blacklist"

(OT: maybe the whole FSDG set of pages should be "refactored" and kept
consistent with the GNU correspondig ones,
e.g. https://www.gnu.org/help/gnu-bucks.en.html)

> a blacklist implies that something is to be shunned, and permanently
> so - the main point of that list is not only to point out programs that
> have known problems, but more importantly to offer known recipes for how
> they can be liberated and used in freedom

and should be open to be reviwed if someone finds a way to liberate one
of the listed software

in a recent message [1] on this mailing list you said:

--8<---cut here---start->8---
 about a year ago, the FSDG review process and criteria for endorsement
 of new distros was updated - the new FSDG criteria checklist for
 community review that was adopted includes the following essential
 criteria:

   "Programs commonly known to have freedom issues are liberated or
   excluded"

 that criteria is a link to the "software that does not respect the
 FSDG" wiki page, which includes an entry for 'chromium-browser' (the
 debian package name) with the liberation procedure being specified as:

   "Remove program/package Use GNU IceCat, or equivalent"

[...]

 it was also agreed upon at that time, that the FSDG criteria should be
 applicable to all currently endorsed distros in perpetuity, so ...

[...]

 if chromium enters the guix repo it will almost surely be followed by a
 freedom bug report (which per the current FSDG criteria, would be fully
 justifiable)

[...]
--8<---cut here---end--->8---

that made me think that you were using "The List" as a blacklist, I'm
glad I was wrong

[...]

> what is clear though is that the current wording of the review process
> prevents any new distro from passing beyond the community review stage
> if it distributes chromium;

this is in direct contraddiction with the concept of "the list is not a
blacklist"

please consider the FSDG Review Guide
https://libreplanet.org/wiki/FSDG_Review_Guide#Only_Includes_Free_Software
clearly states:

--8<---cut here---start->8---
Don't assume that there's a problem just because the distribution
includes a package named on that page, though: a lot of the entries
suggest solutions that help the software comply with the guidelines
without removing it completely. You'll have to check yourself to see
whether or not the free distribution has taken those steps. Usually,
that's as simple as comparing version numbers.
--8<---cut here---end--->8---

so, please, let's use "The List" as a useful tool for addressing
problems *and* be open to enhance or update that list as soon as new
useful information is available

"The List" should keep track of the current status of discussion
(mailing list archives are not the best source of updated information on
this matter) at least with a link to the relevant new information, so
each reviewer have a possibly complete view of current situation

(OT: yes, ungoogled-chromium situation is complex, but please do not
complicate it (I'm speaking in general, not personally to you Bill))

> so it is at least, effectively mandatory for
> new incoming distros - i think we would all want to see all FSDG rules
> applied equally to all FSDG distros, present and future - it is very
> unsettling, embarrassing even, if distros contradict each other
> regarding what is FSDG-free and what is not

Bill: to flatten the discussion of what is FSDG-free or not on a _word_
(chromium-browser) included in "The List" is even more embarrassing

> i do think this is among
> the highest priorities for the group, especially now that this potential
> for conflict has been instantiated with an example

as far as I can see the conflict arises *only* if "The List" is misused,
maybe we should find a way to prevent this kind of conflict: IMHO the
words I cited above from the FSDG Guideline are probably clearer than
this whole thread, but maybe I'm oversimplifiyng

*if* (I really don't know, I did not follow the review process) "The
List" _alone_ was used to force some distribution to remove some
package, IMHO that was a mistake 

> as for the list itself, it is actually relatively short today compared
> to what it could be, and is not as well curated as it could be - it has
> been discussed how it could be refined and expanded to be a prime
> resource to anyone who wishes to customize one of those programs - if
> done well, there no reason why it should not be mandatory IMHO;

I strongly disagree, but who am I to tell?!? 

Re: [GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix

[Giovanni Biscuolo]

Hello Jason,

Jason Self  writes:

> On Tue, 2019-02-19 at 17:18 +0100, Giovanni Biscuolo wrote:
>> do you have the bug number now?
>
> 34565
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34565

thank you for the reference!

for all Guix ungoogled-chromium package DRM I'll continue on that bug
report thread

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature