[PATCH] gnu: ungoogled-chromium: Fix WebRTC.

  • Open
  • quality assurance status badge
Details
5 participants
  • Andreas Enge
  • Danny Milosavljevic
  • Nicolas Goaziou
  • Maxim Cournoyer
  • Noé Lopez
Owner
unassigned
Submitted by
Danny Milosavljevic
Severity
normal

Debbugs page

D
D
Danny Milosavljevic wrote on 24 Apr 16:04 -0700
(address . guix-patches@gnu.org)(name . Danny Milosavljevic)(address . dannym@friendly-machines.com)
dde8a839eb121b3ca7e17db5e00ea8c1d0544c40.1744895822.git.dannym@friendly-machines.com
* 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

Toggle diff (64 lines)
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@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@chromium.org>
+Commit-Queue: Jan Grulich <grulja@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
M
M
Maxim Cournoyer wrote on 28 Apr 23:28 -0700
(name . Danny Milosavljevic)(address . dannym@friendly-machines.com)(address . 78052@debbugs.gnu.org)
87o6wfbhwx.fsf@gmail.com
Hi Danny,

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

Toggle quote (2 lines)
> * 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
M
M
Maxim Cournoyer wrote on 28 Apr 23:31 -0700
(name . Danny Milosavljevic)(address . dannym@friendly-machines.com)
87jz73bhsg.fsf@gmail.com
Hello,

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

Toggle quote (4 lines)
> * 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
N
N
Nicolas Goaziou wrote on 29 Apr 00:57 -0700
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87a57zv1rd.fsf@nicolasgoaziou.fr
Hello,

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

Toggle quote (14 lines)
> Danny Milosavljevic <dannym@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

Of course, it would be nice to update it.

Regards,
--
Nicolas Goaziou
M
M
Maxim Cournoyer wrote on 29 Apr 01:14 -0700
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
87bjsfbczh.fsf@gmail.com
Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

Toggle quote (24 lines)
> Hello,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Danny Milosavljevic <dannym@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:

Toggle snippet (5 lines)
$ guix lint -c cve ungoogled-chromium
fetching CVE database for 2025...
gnu/packages/chromium.scm:484:2: ungoogled-chromium@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

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

--
Thanks,
Maxim
N
N
Noé Lopez wrote on 29 Apr 01:45 -0700
87ikmngxtz.fsf@xn--no-cja.eu
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (17 lines)
> Hello,
>
> Danny Milosavljevic <dannym@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é
-----BEGIN PGP SIGNATURE-----

iQHFBAEBCAAvFiEEXVTPJVeyOOiNwYCiLSIyQQq3QEMFAmgQkbgRHG5vZWxvcGV6
QGZyZWUuZnIACgkQLSIyQQq3QEMI0gv/W7Ly6uNsvz7KQNmxWlBP4/GcIZ1nVBCF
gdF0VLq+jaTOUwz9JfkWmUK692j+T8bvQcbZyBLagi1Bp2aOcsCitxQw5cC+qjy9
vFxNXnwXU4jeKzTgYkDkx15ID2FB6WtMKGxVFpGg8svnL25/TB84ZAAhwvc4WSWW
ymUAT1aPHB4G7sDH9neJIst9N0Gvbm8MPbX0k/s2fxuTRaOYDk+LTCHqNtRdc4as
TFaNTI5W0NP4AKFZzo1QYXHynp08btAOK+M/NopXtFKE8xFTDsA6APVzb4Z64wbe
KjvGAskMHoOl1WZbfTO0xy3PdBfjZ9kZP3vOAxt+RNpzh1f787HPSpPQoQpoSWeV
dCF+FDSNzrDYd9B7IYxb84EIbDlC3gcacbLWR1WM2vOv2krSKN1X8gymz6hF9ea+
nZLuoZjbASYJCWMhcgJKFNt6onxMp4eTqJP9E2LmNVuo66CDVSZrCK+Ns1jgQ5fx
/MvS9y1iHGvi8v8B5bbPinfneZ9/Wqwj
=mnfa
-----END PGP SIGNATURE-----

N
N
Nicolas Goaziou wrote on 29 Apr 06:07 -0700
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
874iy7undh.fsf@nicolasgoaziou.fr
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (7 lines)
> Nicolas Goaziou <mail@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.

Toggle quote (3 lines)
> But I'm not sure that this value is worth the exposure of unsuspecting
> user to tens of CVEs:

[...]

Toggle quote (3 lines)
> 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?
A
A
Andreas Enge wrote on 29 Apr 12:07 -0700
(name . Noé Lopez)(address . noelopez@free.fr)
aBEjgEm92flD5zKg@jurong
Hello,

Am Tue, Apr 29, 2025 at 10:45:44AM +0200 schrieb Noᅵ Lopez:
Toggle quote (3 lines)
> 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
N
N
Noé Lopez wrote on 29 Apr 12:18 -0700
(name . Andreas Enge)(address . andreas@enge.fr)
87cycuhj3j.fsf@xn--no-cja.eu
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (13 lines)
> 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.

Toggle quote (3 lines)
> Of course, someone needs to update it, which is a daunting task...
>

For sure…

Good evening,
Noé
-----BEGIN PGP SIGNATURE-----

iQHFBAEBCAAvFiEEXVTPJVeyOOiNwYCiLSIyQQq3QEMFAmgRJhARHG5vZWxvcGV6
QGZyZWUuZnIACgkQLSIyQQq3QEMX6gwAjo3SFK0tv4PFsCXoMmCSGbyrsE9vzb0V
wLO1cbzinsutQhrK1FNxLVn3EPg2UBQ2c+urN7gUKwLSjizFAFcCELCJM9lVM9Fk
1yRiJsnbTjcMRHNb9LeDuc8PT/Sx5H8JGngv/pzc41vl2kqz6B/XLkCA72nFxTYR
xZXKBAPxqK2eHKjyBi0zoVYf5T/Gs8KCy7yqhjeFGcZBHazINH4F5O07iGP65H4Q
SWauMtpKOiZkFm7pVgvCm25jQhdnBH98DQmzMlmju2SyJMg99ywsctbLni0wuCi3
uk0NcLWo+wcSZAscGdi74ShFyJqUjEwBK0Wo4jpN1c1rxCIZvn2GYTSPtrAZJg3P
epuAQWsFEMnHy7Lxsv7D++sXZnBK0hZlvK4s3Il+/q+V1mvAU2vNWnL0pJEQLxVx
nW8Q13GtfwD25n/CcECZHe1QII+YGIldGIVWFRzHmI2u4NcZ4D7N9PGaSO3sbYBw
hmqk7o6AXlDN3FMSeM4F/WAnpgiJET8d
=HaAg
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 29 Apr 16:11 -0700
(name . Nicolas Goaziou)(address . mail@nicolasgoaziou.fr)
87selqa7hj.fsf@gmail.com
Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

Toggle quote (22 lines)
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Nicolas Goaziou <mail@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
M
M
Maxim Cournoyer wrote on 29 Apr 16:12 -0700
(name . Andreas Enge)(address . andreas@enge.fr)
87o6wea7fv.fsf@gmail.com
Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (14 lines)
> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 78052@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 78052
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch