GNU bug report logs - #78052
[PATCH] gnu: ungoogled-chromium: Fix WebRTC.

Previous Next

To reply to this bug, email your comments to 78052 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> friendly-machines.com>
To: guix-patches <at> gnu.org
Cc: Danny Milosavljevic <dannym <at> friendly-machines.com>
Subject: [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Fri, 25 Apr 2025 01:04:29 +0200

* gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file.
* gnu/packages/chromium.scm (%guix-patches): Add reference to it.
* gnu/local.mk (dist_patch_DATA): Add reference to it.

Change-Id: I91b7c3243345f6f1eda71aa4ec68faf3ef4a98f4
---
 gnu/local.mk                                  |  1 +
 gnu/packages/chromium.scm                     |  3 ++
 .../ungoogled-chromium-fcntl-fix.patch        | 28 +++++++++++++++++++
 3 files changed, 32 insertions(+)
 create mode 100644 gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 62cfe230bb..582296e3c9 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -2344,6 +2344,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/uftrace-fix-tests.patch			\
   %D%/packages/patches/ultrastar-deluxe-no-freesans.patch		\
   %D%/packages/patches/ungoogled-chromium-extension-search-path.patch	\
+  %D%/packages/patches/ungoogled-chromium-fcntl-fix.patch	\
   %D%/packages/patches/ungoogled-chromium-ffmpeg-compat.patch	\
   %D%/packages/patches/ungoogled-chromium-RUNPATH.patch		\
   %D%/packages/patches/ungoogled-chromium-system-ffmpeg.patch	\
diff --git a/gnu/packages/chromium.scm b/gnu/packages/chromium.scm
index 5da5f10da6..45fd719822 100644
--- a/gnu/packages/chromium.scm
+++ b/gnu/packages/chromium.scm
@@ -385,6 +385,9 @@ (define %guix-patches
   (list (local-file
          (assume-valid-file-name
           (search-patch "ungoogled-chromium-extension-search-path.patch")))
+        (local-file
+         (assume-valid-file-name
+          (search-patch "ungoogled-chromium-fcntl-fix.patch")))
         (local-file
          (assume-valid-file-name
           (search-patch "ungoogled-chromium-RUNPATH.patch")))
diff --git a/gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch b/gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch
new file mode 100644
index 0000000000..e9e8664b6f
--- /dev/null
+++ b/gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch
@@ -0,0 +1,28 @@
+From 7b0d7f48fbffb412f0c485f86ef33b0dea605d1d Mon Sep 17 00:00:00 2001
+From: Jan Grulich <grulja <at> gmail.com>
+Date: Fri, 12 May 2023 20:59:06 +0200
+Subject: [PATCH] PipeWire capturer: fix fcntl call when duplicating a file descriptor
+
+The fcntl() call has variable arguments, therefore we need to pass 0 to
+specify there are no other arguments for this call, otherwise we might
+end up with an argument that is random garbage.
+
+Bug: webrtc:15174
+Change-Id: I34f16a942d80913b667d8ade7eed557b0233be01
+Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305120
+Reviewed-by: Alexander Cooper <alcooper <at> chromium.org>
+Commit-Queue: Jan Grulich <grulja <at> gmail.com>
+Cr-Commit-Position: refs/heads/main@{#40060}
+---
+
+--- ./third_party/webrtc/modules/desktop_capture/linux/wayland/shared_screencast_stream.cc.orig	2024-11-18 21:48:23.280303055 +0100
++++ ./third_party/webrtc/modules/desktop_capture/linux/wayland/shared_screencast_stream.cc	2024-11-18 21:48:24.860287444 +0100
+@@ -447,7 +447,7 @@
+ 
+     if (fd >= 0) {
+       pw_core_ = pw_context_connect_fd(
+-          pw_context_, fcntl(fd, F_DUPFD_CLOEXEC), nullptr, 0);
++          pw_context_, fcntl(fd, F_DUPFD_CLOEXEC, 0), nullptr, 0);
+     } else {
+       pw_core_ = pw_context_connect(pw_context_, nullptr, 0);
+     }

base-commit: a36ff7d51110403295a359e7f40c3eb42ccfd509
-- 
2.49.0

Message #8 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Danny Milosavljevic <dannym <at> friendly-machines.com>
Cc: 78052 <at> debbugs.gnu.org
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Tue, 29 Apr 2025 15:28:30 +0900

Hi Danny,

Danny Milosavljevic <dannym <at> friendly-machines.com> writes:

> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file.

Is this an upstream patch now included in recent releases?  Our
ungoogled-chromium package is probably ridden with many CVEs at this
point (it's poorly maintained).  If you use it, perhaps you could try
updating it?

-- 
Thanks,
Maxim

Message #11 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Danny Milosavljevic <dannym <at> friendly-machines.com>
Cc: guix-devel <guix-devel <at> gnu.org>, 78052 <at> debbugs.gnu.org
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Tue, 29 Apr 2025 15:31:11 +0900

Hello,

Danny Milosavljevic <dannym <at> friendly-machines.com> writes:

> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file.
> * gnu/packages/chromium.scm (%guix-patches): Add reference to it.
> * gnu/local.mk (dist_patch_DATA): Add reference to it.

Ouch, the last time ungoogled-chromium was updated was in 2023.  That's
terrible for something is sensitive as a web browser that runs arbitrary
javascript by default.

If nobody champions an update, I'd suggest we remove the package.

What do people think? (+CC guix-devel).

-- 
Thanks,
Maxim

Message #14 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: guix-devel <guix-devel <at> gnu.org>, 78052 <at> debbugs.gnu.org,
 Danny Milosavljevic <dannym <at> friendly-machines.com>
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Tue, 29 Apr 2025 09:57:10 +0200

Hello,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Danny Milosavljevic <dannym <at> friendly-machines.com> writes:
>
>> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file.
>> * gnu/packages/chromium.scm (%guix-patches): Add reference to it.
>> * gnu/local.mk (dist_patch_DATA): Add reference to it.
>
> Ouch, the last time ungoogled-chromium was updated was in 2023.  That's
> terrible for something is sensitive as a web browser that runs arbitrary
> javascript by default.
>
> If nobody champions an update, I'd suggest we remove the package.
>
> What do people think? (+CC guix-devel).

It still builds, so I disagree that it should be removed. It can still
be useful locally, assuming casting is fixed (see
<https://issues.guix.gnu.org/58581>).

Of course, it would be nice to update it.

Regards,
-- 
Nicolas Goaziou

Message #17 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: guix-devel <guix-devel <at> gnu.org>, 78052 <at> debbugs.gnu.org,
 Danny Milosavljevic <dannym <at> friendly-machines.com>
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Tue, 29 Apr 2025 17:14:58 +0900

Hi Nicolas,

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:

> Hello,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Danny Milosavljevic <dannym <at> friendly-machines.com> writes:
>>
>>> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file.
>>> * gnu/packages/chromium.scm (%guix-patches): Add reference to it.
>>> * gnu/local.mk (dist_patch_DATA): Add reference to it.
>>
>> Ouch, the last time ungoogled-chromium was updated was in 2023.  That's
>> terrible for something is sensitive as a web browser that runs arbitrary
>> javascript by default.
>>
>> If nobody champions an update, I'd suggest we remove the package.
>>
>> What do people think? (+CC guix-devel).
>
> It still builds, so I disagree that it should be removed. It can still
> be useful locally, assuming casting is fixed (see
> <https://issues.guix.gnu.org/58581>).
>
> Of course, it would be nice to update it.

I agree that it has value; wouldn't it only be for testing website
problems (it's still a thing in 2025 to find a website feature that only
works with Chromium, in a nudge to the good old Internet Explorer days).

But I'm not sure that this value is worth the exposure of unsuspecting
user to tens of CVEs:

--8<---------------cut here---------------start------------->8---
$ guix lint -c cve ungoogled-chromium
fetching CVE database for 2025...
gnu/packages/chromium.scm:484:2: ungoogled-chromium <at> 112.0.5615.165-1 : probablement vulnérable à CVE-2025-0291, CVE-2025-0434, CVE-2025-0436, CVE-2025-0437, CVE-2025-0438, CVE-2025-0439, CVE-2025-0441, CVE-2025-0442, CVE-2025-0443, CVE-2025-0444, CVE-2025-0445, CVE-2025-0446, CVE-2025-0447, CVE-2025-0448, CVE-2025-0451, CVE-2025-0611, CVE-2025-0612, CVE-2025-0762, CVE-2025-0995, CVE-2025-0996, CVE-2025-0997, CVE-2025-0999, CVE-2025-1006, CVE-2025-1426, CVE-2025-1914, CVE-2025-1916, CVE-2025-1918, CVE-2025-1919, CVE-2025-1920, CVE-2025-1921, CVE-2025-1923, CVE-2025-2135, CVE-2025-2136, CVE-2025-2137, CVE-2025-2476, CVE-2025-3066, CVE-2025-3067, CVE-2025-3068, CVE-2025-3069, CVE-2025-3070, CVE-2025-3071, CVE-2025-3072, CVE-2025-3073, CVE-2025-3074, CVE-2025-3619, CVE-2025-3620, CVE-2024-0222, CVE-2024-0223, CVE-2024-0224, CVE-2024-0225, CVE-2024-0333, CVE-2024-0517, CVE-2024-0518, CVE-2024-0519, CVE-2024-0804, CVE-2024-0805, CVE-2024-0806, CVE-2024-0807, CVE-2024-0808, CVE-2024-0809, CVE-2024-0810, CVE-2024-0811, CVE-2024-0812, CVE-2024-0813, CVE-2024-0814, CVE-2024-10229, CVE-2024-10230, CVE-2024-10231, CVE-2024-10487, CVE-2024-10488, CVE-2024-1059, CVE-2024-1060, CVE-2024-1077, CVE-2024-10827, CVE-2024-11110, CVE-2024-11111, CVE-2024-11113, CVE-2024-11116, CVE-2024-11117, CVE-2024-12053, CVE-2024-12381, CVE-2024-12382, CVE-2024-12692, CVE-2024-12693, CVE-2024-12694, CVE-2024-12695, CVE-2024-1283, CVE-2024-1284, CVE-2024-1669, CVE-2024-1670, CVE-2024-1671, CVE-2024-1672, CVE-2024-1673, CVE-2024-1674, CVE-2024-1675, CVE-2024-1676, CVE-2024-1938, CVE-2024-1939, CVE-2024-2173, CVE-2024-2174, CVE-2024-2176, CVE-2024-2400, CVE-2024-2625, CVE-2024-2626, CVE-2024-2627, CVE-2024-2628, CVE-2024-2629, CVE-2024-2630, CVE-2024-2631, CVE-2024-2883, CVE-2024-2884, CVE-2024-2885, CVE-2024-2886, CVE-2024-2887, CVE-2024-3156, CVE-2024-3157, CVE-2024-3158, CVE-2024-3159, CVE-2024-3168, CVE-2024-3169, CVE-2024-3170, CVE-2024-3171, CVE-2024-3172, CVE-2024-3173, CVE-2024-3174, CVE-2024-3175, CVE-2024-3176, CVE-2024-3515, CVE-2024-3516, CVE-2024-3832, CVE-2024-3833, CVE-2024-3834, CVE-2024-3837, CVE-2024-3838, CVE-2024-3839, CVE-2024-3840, CVE-2024-3843, CVE-2024-3844, CVE-2024-3845, CVE-2024-3846, CVE-2024-3847, CVE-2024-3914, CVE-2024-4058, CVE-2024-4059, CVE-2024-4060, CVE-2024-4331, CVE-2024-4368, CVE-2024-4558, CVE-2024-4559, CVE-2024-4671, CVE-2024-4761, CVE-2024-4947, CVE-2024-4948, CVE-2024-4949, CVE-2024-4950, CVE-2024-5157, CVE-2024-5158, CVE-2024-5159, CVE-2024-5274, CVE-2024-5496, CVE-2024-5497, CVE-2024-5498, CVE-2024-5499, CVE-2024-5500, CVE-2024-5830, CVE-2024-5831, CVE-2024-5832, CVE-2024-5833, CVE-2024-5834, CVE-2024-5835, CVE-2024-5836, CVE-2024-5837, CVE-2024-5838, CVE-2024-5839, CVE-2024-5840, CVE-2024-5841, CVE-2024-5842, CVE-2024-5843, CVE-2024-5844, CVE-2024-5845, CVE-2024-5846, CVE-2024-5847, CVE-2024-6100, CVE-2024-6101, CVE-2024-6102, CVE-2024-6103, CVE-2024-6290, CVE-2024-6291, CVE-2024-6772, CVE-2024-6774, CVE-2024-6775, CVE-2024-6776, CVE-2024-6777, CVE-2024-6778, CVE-2024-6779, CVE-2024-6989, CVE-2024-6990, CVE-2024-6991, CVE-2024-6994, CVE-2024-6996, CVE-2024-6997, CVE-2024-6998, CVE-2024-6999, CVE-2024-7000, CVE-2024-7001, CVE-2024-7003, CVE-2024-7004, CVE-2024-7005, CVE-2024-7018, CVE-2024-7019, CVE-2024-7020, CVE-2024-7022, CVE-2024-7024, CVE-2024-7025, CVE-2024-7255, CVE-2024-7532, CVE-2024-7534, CVE-2024-7535, CVE-2024-7536, CVE-2024-7550, CVE-2024-7965, CVE-2024-7966, CVE-2024-7967, CVE-2024-7968, CVE-2024-7969, CVE-2024-7970, CVE-2024-7971, CVE-2024-7972, CVE-2024-7973, CVE-2024-7974, CVE-2024-7975, CVE-2024-7976, CVE-2024-7978, CVE-2024-7981, CVE-2024-8193, CVE-2024-8194, CVE-2024-8198, CVE-2024-8362, CVE-2024-8636, CVE-2024-8638, CVE-2024-8904, CVE-2024-8905, CVE-2024-8906, CVE-2024-8907, CVE-2024-8908, CVE-2024-9121, CVE-2024-9122, CVE-2024-9123, CVE-2024-9369, CVE-2024-9602, CVE-2024-9603, CVE-2024-9859, CVE-2024-9954, CVE-2024-9955, CVE-2024-9958, CVE-2024-9959, CVE-2024-9960, CVE-2024-9962, CVE-2024-9963, CVE-2024-9964, CVE-2024-9966, CVE-2023-2459, CVE-2023-2460, CVE-2023-2462, CVE-2023-2464, CVE-2023-2465, CVE-2023-2466, CVE-2023-2468, CVE-2023-2721, CVE-2023-2723, CVE-2023-2724, CVE-2023-2725, CVE-2023-2726, CVE-2023-2929, CVE-2023-2930, CVE-2023-2931, CVE-2023-2932, CVE-2023-2933, CVE-2023-2934, CVE-2023-2935, CVE-2023-2936, CVE-2023-2937, CVE-2023-2938, CVE-2023-2940, CVE-2023-2941, CVE-2023-3214, CVE-2023-3215, CVE-2023-3216, CVE-2023-3217, CVE-2023-3420, CVE-2023-3421, CVE-2023-3422, CVE-2023-3598, CVE-2023-3727, CVE-2023-3728, CVE-2023-3730, CVE-2023-3732, CVE-2023-3733, CVE-2023-3734, CVE-2023-3735, CVE-2023-3737, CVE-2023-3738, CVE-2023-3740, CVE-2023-4068, CVE-2023-4069, CVE-2023-4070, CVE-2023-4071, CVE-2023-4072, CVE-2023-4074, CVE-2023-4075, CVE-2023-4076, CVE-2023-4077, CVE-2023-4078, CVE-2023-4349, CVE-2023-4351, CVE-2023-4352, CVE-2023-4353, CVE-2023-4354, CVE-2023-4355, CVE-2023-4356, CVE-2023-4357, CVE-2023-4358, CVE-2023-4360, CVE-2023-4362, CVE-2023-4364, CVE-2023-4365, CVE-2023-4366, CVE-2023-4367, CVE-2023-4368, CVE-2023-4427, CVE-2023-4428, CVE-2023-4429, CVE-2023-4430, CVE-2023-4431, CVE-2023-4572, CVE-2023-4761, CVE-2023-4762, CVE-2023-4763, CVE-2023-4764, CVE-2023-4860, CVE-2023-4863, CVE-2023-4901, CVE-2023-4902, CVE-2023-4904, CVE-2023-4905, CVE-2023-4906, CVE-2023-4908, CVE-2023-4909, CVE-2023-5186, CVE-2023-5187, CVE-2023-5217, CVE-2023-5218, CVE-2023-5346, CVE-2023-5472, CVE-2023-5473, CVE-2023-5474, CVE-2023-5475, CVE-2023-5476, CVE-2023-5477, CVE-2023-5478, CVE-2023-5479, CVE-2023-5480, CVE-2023-5481, CVE-2023-5482, CVE-2023-5483, CVE-2023-5484, CVE-2023-5485, CVE-2023-5486, CVE-2023-5487, CVE-2023-5849, CVE-2023-5850, CVE-2023-5851, CVE-2023-5852, CVE-2023-5853, CVE-2023-5854, CVE-2023-5855, CVE-2023-5856, CVE-2023-5857, CVE-2023-5858, CVE-2023-5859, CVE-2023-5996, CVE-2023-5997, CVE-2023-6112, CVE-2023-6345, CVE-2023-6346, CVE-2023-6347, CVE-2023-6348, CVE-2023-6350, CVE-2023-6351, CVE-2023-6508, CVE-2023-6509, CVE-2023-6510, CVE-2023-6511, CVE-2023-6512, CVE-2023-6702, CVE-2023-6703, CVE-2023-6704, CVE-2023-6705, CVE-2023-6706, CVE-2023-6707, CVE-2023-7010, CVE-2023-7011, CVE-2023-7012, CVE-2023-7013, CVE-2023-7024, CVE-2023-7281, CVE-2023-7282
--8<---------------cut here---------------end--------------->8---

I'd think that most users expect that security matters for web browsers
and that they are kept up to date/secure.

-- 
Thanks,
Maxim

Message #20 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Noé Lopez <noelopez <at> free.fr>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Danny Milosavljevic
 <dannym <at> friendly-machines.com>
Cc: guix-devel <guix-devel <at> gnu.org>, 78052 <at> debbugs.gnu.org
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Tue, 29 Apr 2025 10:45:44 +0200

[Message part 1 (text/plain, inline)]

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hello,
>
> Danny Milosavljevic <dannym <at> friendly-machines.com> writes:
>
>> * gnu/packages/patches/ungoogled-chromium-fcntl-fix.patch: New file.
>> * gnu/packages/chromium.scm (%guix-patches): Add reference to it.
>> * gnu/local.mk (dist_patch_DATA): Add reference to it.
>
> Ouch, the last time ungoogled-chromium was updated was in 2023.  That's
> terrible for something is sensitive as a web browser that runs arbitrary
> javascript by default.
>
> If nobody champions an update, I'd suggest we remove the package.
>
> What do people think? (+CC guix-devel).
>

IMO its important that we have one of webkit, chromium and gecko in our
repos for when those pesky websites refuse to work with X browser.

I’m thinking of microsoft teams that somehow manages to crash on all
three. Might be the worst piece of software ever.

Have a nice day,
Noé

[signature.asc (application/pgp-signature, inline)]

Message #23 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: guix-devel <guix-devel <at> gnu.org>, 78052 <at> debbugs.gnu.org,
 Danny Milosavljevic <dannym <at> friendly-machines.com>
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Tue, 29 Apr 2025 15:07:54 +0200

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:
>
> I agree that it has value; wouldn't it only be for testing website
> problems (it's still a thing in 2025 to find a website feature that only
> works with Chromium, in a nudge to the good old Internet Explorer
> days).

My hypothetical use-case is simply to display PDF on a Chromecast. It
only needs to connect to a LAN.

> But I'm not sure that this value is worth the exposure of unsuspecting
> user to tens of CVEs:

[...]

> I'd think that most users expect that security matters for web browsers
> and that they are kept up to date/secure.

Wouldn’t a big fat warning in the description of the package help?

Message #26 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Noé Lopez <noelopez <at> free.fr>
Cc: guix-devel <guix-devel <at> gnu.org>,
 Danny Milosavljevic <dannym <at> friendly-machines.com>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 78052 <at> debbugs.gnu.org
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Tue, 29 Apr 2025 21:07:44 +0200

Hello,

Am Tue, Apr 29, 2025 at 10:45:44AM +0200 schrieb Noé Lopez:
> IMO its important that we have one of webkit, chromium and gecko in our
> repos for when those pesky websites refuse to work with X browser.

I concur. In particular, many ecommerce websites do not work with icecat,
even after disabling all extensions (of which "Searxes' Third-party
Request Blocker" is the most meaningful one). 

So I end up using ungoogled-chromium routinely for "commercial" sites.

Of course, someone needs to update it, which is a daunting task...

Andreas

Message #29 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Noé Lopez <noelopez <at> free.fr>
To: Andreas Enge <andreas <at> enge.fr>
Cc: guix-devel <guix-devel <at> gnu.org>,
 Danny Milosavljevic <dannym <at> friendly-machines.com>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 78052 <at> debbugs.gnu.org
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Tue, 29 Apr 2025 21:18:40 +0200

[Message part 1 (text/plain, inline)]

Andreas Enge <andreas <at> enge.fr> writes:

> Hello,
>
> Am Tue, Apr 29, 2025 at 10:45:44AM +0200 schrieb Noé Lopez:
>> IMO its important that we have one of webkit, chromium and gecko in our
>> repos for when those pesky websites refuse to work with X browser.
>
> I concur. In particular, many ecommerce websites do not work with icecat,
> even after disabling all extensions (of which "Searxes' Third-party
> Request Blocker" is the most meaningful one). 
>
> So I end up using ungoogled-chromium routinely for "commercial" sites.
>

Personally, I would just use the profile with extensions disabled all
the time so I switched to librewolf which offers better privacy and has
more active development.

Unless there are special things that Icecat does compared to librewolf,
I think we could reproduce a newer icecat by bundling librewolf with the
default icecat extensions. To have the best of both worlds.

> Of course, someone needs to update it, which is a daunting task...
>

For sure…

Good evening,
Noé

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: guix-devel <guix-devel <at> gnu.org>, 78052 <at> debbugs.gnu.org,
 Danny Milosavljevic <dannym <at> friendly-machines.com>
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Wed, 30 Apr 2025 08:11:20 +0900

Hi Nicolas,

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:
>>
>> I agree that it has value; wouldn't it only be for testing website
>> problems (it's still a thing in 2025 to find a website feature that only
>> works with Chromium, in a nudge to the good old Internet Explorer
>> days).
>
> My hypothetical use-case is simply to display PDF on a Chromecast. It
> only needs to connect to a LAN.
>
>> But I'm not sure that this value is worth the exposure of unsuspecting
>> user to tens of CVEs:
>
> [...]
>
>> I'd think that most users expect that security matters for web browsers
>> and that they are kept up to date/secure.
>
> Wouldn’t a big fat warning in the description of the package help?

I'm not convinced that'd be enough; existing users would probably not
see it for example.  I think going through the deprecation route would
be a more visible option.

Our (info "(guix) Deprecation Policy") suggests a one month period after
the removal PATCH is submitted, plus a news to etc/news.scm broadcasting
the removal in this case, because ungoogled-chromium is probably
considered a 'popular' package.

This would give someone one month to update it, or move it to another
channel (perhaps guix-past could keep legacy browser versions around,
for testing for example).

-- 
Thanks,
Maxim

Message #35 received at 78052 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Andreas Enge <andreas <at> enge.fr>
Cc: guix-devel <guix-devel <at> gnu.org>,
 Noé Lopez <noelopez <at> free.fr>, 78052 <at> debbugs.gnu.org,
 Danny Milosavljevic <dannym <at> friendly-machines.com>
Subject: Re: [bug#78052] [PATCH] gnu: ungoogled-chromium: Fix WebRTC.
Date: Wed, 30 Apr 2025 08:12:20 +0900

Hi Andreas,

Andreas Enge <andreas <at> enge.fr> writes:

> Hello,
>
> Am Tue, Apr 29, 2025 at 10:45:44AM +0200 schrieb Noé Lopez:
>> IMO its important that we have one of webkit, chromium and gecko in our
>> repos for when those pesky websites refuse to work with X browser.
>
> I concur. In particular, many ecommerce websites do not work with icecat,
> even after disabling all extensions (of which "Searxes' Third-party
> Request Blocker" is the most meaningful one). 
>
> So I end up using ungoogled-chromium routinely for "commercial" sites.
>
> Of course, someone needs to update it, which is a daunting task...

Have you tried librewolf for this use case?  It works for me (and unlike
ungoogled-chromium, it is maintained thus safer to use).

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.