from:"Michael Catanzaro"

On Sat, Mar 30 2024 at 02:55:21 PM +00:00:00, Zbigniew 
Jędrzejewski-Szmek  wrote:

CMake for many years fought against pkgconf and pushed people towards
copying those scripts into sources. It is still very common for 
projects

using CMake to come with a whole directory of badly written detection
scripts that each replace a single-line pkgconf invocation.

And of course nobody has time to look into those scripts, making it
easy to smuggle something through there.


It's still better than Autotools, though. If a project doesn't want to 
switch to Meson for whatever reason, then CMake is a reasonable 
alternative.


I agree that CMake is not as good as Meson, and that CMake find modules 
are inferior to pkg-config. The CMake developers are working on 
replacing find modules with CPS [1] which is intended to be a 
replacement for pkg-config that will work better on non-Linux 
platforms, where pkg-config is not always adequate. It looks like that 
work has maybe stalled? but if successful that would fix the problem 
with find modules.


[1] https://cps-org.github.io/cps/overview.html

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Sat, Mar 30 2024 at 09:45:06 AM -05:00:00, Michael Catanzaro 
 wrote:

No, that is not correct, as explained by [1] and [2].


I pasted the wrong link for [2]. I meant to paste:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GRMSYVY6AM7OZBGQCQWIKRAF7DEMOKJM/

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Sat, Mar 30 2024 at 12:26:48 PM +00:00:00, Christopher Klooz 
 wrote:
 If I got Rich right, the malicious code is likely to be broken on 
F40,


No, that is not correct, as explained by [1] and [2]. We have already 
asked Red Hat to investigate and fix the blog post. This is still an 
evolving situation; apologies for the confusion as we sort this out.


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/
[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/


Then we must have had some communication snafu regarding the Fedora 
Magazine article, because multiple people including myself flagged the 
incorrect statement there before the article was published. Hopefully 
we can get one this fixed, too.


Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

On Sat, Mar 30 2024 at 09:37:44 AM +00:00:00, Richard W.M. Jones 
 wrote:

In the xz case this wouldn't have been enough, it turns out we would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates.  I don't fully understand why that is.


I agree that running autoreconf on our packages makes sense to start 
doing. Still, to avoid this backdoored m4 file, we would have needed to 
stop using release tarballs altogether and switch to using git tags 
directly instead. That would at least force the malicious attacker to 
commit their code to version control, making it slightly harder to hide 
the attack.


Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Fri, Mar 29 2024 at 04:10:53 PM -05:00:00, Michael Catanzaro 
 wrote:
OK, I am going to ask Product Security to edit their blog post to 
remove the incorrect information. I will CC you on that request.


Or maybe I should rephrase this as a "request for clarification," 
because maybe they know something that we don't. E.g. the Ars article 
[1] says


"The build environment on Fedora 40, for example, contains 
incompatibilities that prevent the injection from correctly occurring. 
Fedora 40 has now reverted to the 5.4.x versions of xz Utils."


[1] 
https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/


Now, that's a secondary source, and I'm not confident if it is true, 
but perhaps Product Security had time to analyze the build logs before 
publishing and found something that we don't know about. Richard, what 
do you think?


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Fri, Mar 29 2024 at 08:16:55 PM +00:00:00, Richard W.M. Jones 
 wrote:

These are the exact builds which were vulnerable.  Note the tags are
all empty because Kevin untagged them last night, so you'll probably
need to cross-reference these with bodhi updates.


OK, I am going to ask Product Security to edit their blog post to 
remove the incorrect information. I will CC you on that request.


Thanks,

Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Fri, Mar 29 2024 at 07:44:12 PM +01:00:00, Mikel Olasagasti 
 wrote:

Do we know if GH release tarballs are safe?


The tarballs generated by GitHub that just include the contents of the 
git repo should be safe (at least from this particular issue), but the 
Fedora package is not built from those. It was built from the malicious 
release tarballs.


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Fri, Mar 29 2024 at 07:56:49 PM +00:00:00, Richard W.M. Jones 
 wrote:

secalert are already well aware and have approved the update.  Kevin
Fenzi, myself and others were working on it late last night :-(


Sorry, I linked to the wrong article. I meant to link to [1] which says 
that "At this time the Fedora Linux 40 builds have not been shown to be 
compromised. We believe the malicious code injection did not take 
effect in these builds." But this statement contradicts my findings 
above, and you just replied "yes" to those, implying that my 
understanding is correct. So I guess either this blog post is wrong and 
needs to be updated, or you're wrong about me being right. Er, correct? 
:)


[1] 
https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Fri, Mar 29 2024 at 06:46:59 PM +00:00:00, Christopher Klooz 
 wrote:

Yes, F40 beta is affected, along with rawhide, but not F38/F39.


Unless I'm misunderstanding something, it looks xz-5.6.0-1.fc40 and 
5.6.0-2.fc40 are backdoored, yes? Then rjones unknowingly broke the 
backdoor in two different ways in 5.6.0-3.fc40, (a) by adding the 
--disable-ifunc configure flag [1], and also (b) by running everything 
through autoreconf to regenerate the malicious autogoo files [2]. So 
F40 stable was never affected, but F40 updates-testing looks like it 
really was backdoored for about one week, between February 27 [3] and 
March 4 [4].


Hey Richard, if you agree with my quick assessment, then we should ask 
secal...@redhat.com to update the warning article [5]. (I also don't 
like the confusing references to "Fedora 41" in that article, since 
Fedora 41 does not yet exist as something separate from rawhide.)


[1] 
https://src.fedoraproject.org/rpms/xz/c/c837ae96c716c6d63da2b4a016e9034ade2a01f7?branch=f40
[2] 
https://src.fedoraproject.org/rpms/xz/c/d2408dde878851ca6350297a738a72496a9558c4?branch=f40

[3] https://bodhi.fedoraproject.org/updates/FEDORA-2024-a7fba89402
[4] https://bodhi.fedoraproject.org/updates/FEDORA-2024-f5033032b8
[5] https://access.redhat.com/security/cve/CVE-2024-3094

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Redis will no longer be OSS... now what?

2024-03-22 Thread Michael Catanzaro

On Fri, Mar 22 2024 at 02:44:33 PM +01:00:00, Kevin Kofler via devel 
 wrote:
Once concern I have with this is the use of LGPL 3.0 *only*. This 
will not
be compatible with a GPL 4 or newer. (The upgrade clause in the 
LGPLv2 that
allowed that was unfortunately dropped in the LGPLv3, now you have to 
put
the "or later" clause on the LGPLed code to be compatible with newer 
GPL

versions.)


So I'm not an expert on redis, but it's primarily accessed via sockets, 
so the license doesn't actually matter for most users. I expect it will 
probably be fine regardless of the choice of license (as long as it 
doesn't go crazy and use AGPL).


But redis also has "modules" and I'm not familiar with them. The 
modules were switched back to BSD-3-Clause yesterday after I complained 
to Neal and then Neal complained to Drew:


https://codeberg.org/redict/redict/commit/d47ce2f24063728c09c3449e5deef3eddb9eceec

But I'm not sure how much that really achieves. If the modules also 
link to LGPL-3.0-only code, then that probably accomplishes nothing.


I agree that most GPL or LPGL projects won't be willing to touch 
anything that uses an -only license rather than an -or-later license 
because the risk of not being able to "upgrade" the license in the 
future is extreme and prohibitive. And of course permissively-licensed 
projects will not touch anything that uses LGPL-3.0-only or 
LGPL-3.0-or-later anyway. But as long as there is the IPC/socket 
boundary in the middle, most programs should be fine. I wonder about 
these modules, though


Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

2024-02-21 Thread Michael Catanzaro

On Wed, Feb 21 2024 at 05:38:00 PM +01:00:00, Jun Aruga (he / him) 
 wrote:
ImportError: /lib64/libdnf.so.2: undefined symbol: 
g_once_init_enter_pointer

https://bugzilla.redhat.com/show_bug.cgi?id=2265336


This means dnf was built against a newer version of glib than is 
available at runtime. Like most libraries, glib is backwards-compatible 
but not forwards-compatible. i.e. it will add new APIs, and you have to 
build against the oldest version that might be used at runtime. 
g_once_init_enter_pointer is simply a new API.


I don't know what exactly has gone wrong or how to fix it, but 
hopefully that helps us get a little closer to the solution here.


Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

2024-02-14 Thread Michael Catanzaro

On Wed, Feb 14 2024 at 09:38:39 PM +00:00:00, Sérgio Basto 
 wrote:

I found "cc1plus: out of memory allocating 603 bytes after a total
of 86921216 bytes"



Thanks. This was a big help.

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

2024-02-14 Thread Michael Catanzaro



I checked the build log for 
https://koji.fedoraproject.org/koji/taskinfo?taskID=113473592 but 
unfortunately I don't actually see any error message. I searched for 
"error:" (indicating a compiler error) and I also searched for "Killed" 
(indicating OOM).


No doubt something is wrong somewhere in that build log, but I'm not 
sure where.


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Feedback requested on potential change to hosts line in nsswitch.conf

2024-02-08 Thread Michael Catanzaro


Hi,

If you're interested in name resolution or mDNS, please review this bug 
report:


Default authselect profiles break `hostname --fqdn`
https://bugzilla.redhat.com/show_bug.cgi?id=2257197

We are looking for feedback on whether to move nss-myhostname, and 
possibly also nss-mdns4_minimal.


I wonder if anybody has recently tested systemd-resolved's ability to 
handle mDNS resolution. Previously we decided it was broken, which is 
why nss-mdns4_minimal is currently run before nss-resolve. But I don't 
know if that's still the case.


Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Figure out what killed an app (rhbz#2253099)

2024-01-31 Thread Michael Catanzaro

On Wed, Jan 31 2024 at 06:53:25 PM +01:00:00, Milan Crha 
 wrote:
Evo itself doesn't use any seccomp or such, these things can be used 
by

the WebKitGTK. A quick grep revealed:

https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp#L258

but that code does not seem to be called at this time (or my debug 
code

was wrong, it's possible).


That code is for terminating child processes. It's certainly not 
supposed to terminate itself.


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Figure out what killed an app (rhbz#2253099)

2024-01-31 Thread Michael Catanzaro

On Wed, Jan 31 2024 at 04:42:08 PM +01:00:00, Clemens Lang 
 wrote:
Throwing some ideas out there, is it possible that evolution runs 
with a seccomp filter or other BPF program configured to kill the 
process on violation, and that’s what’s happening here?


I don't think so. flatpak does use seccomp filters [1], but on 
violations the syscalls should just fail with EPERM or ENOSYS, not kill 
the process.


[1] 
https://github.com/flatpak/flatpak/blob/d5f891e0035e50b24211688a7fa5f61924a2e51c/common/flatpak-run.c#L1791


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Figure out what killed an app (rhbz#2253099)

2024-01-31 Thread Michael Catanzaro

SIGKILL is almost always sent by systemd-oomd (or the kernel OOM 
killer). That's the most likely explanation. Theoretically it could 
also be sent by systemd if a service didn't quit quickly enough 
following a SIGTERM. Maybe it could also be sent by mutter if a program 
is unresponsive?


WebKitGTK doesn't use SIGKILL to clean up after itself. The parent 
process just closes its IPC socket to the child process, then the child 
should either (a) exit normally, or (b) crash itself, if its watchdog 
thread detects the main thread has hung.


On Wed, Jan 31 2024 at 11:08:16 AM +01:00:00, Milan Crha 
 wrote:

Jan 31 10:49:23 localhost.localdomain xdg-desktop-por[2697]: Realtime
error: Could not map pid: Could not determine pid namespace: Could not
find instance-id in process's /.flatpak-info


This one is https://bugs.webkit.org/show_bug.cgi?id=238403 (fixed 
recently)


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Vala workaround for C type errors now in rawhide

2024-01-19 Thread Michael Catanzaro



Thank you!

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: -fcf-protection dropped from i686 compiler flags

2024-01-18 Thread Michael Catanzaro



Unfortunately this is causing gating tests to fail for rawhide builds, 
e.g.:


https://artifacts.dev.testing-farm.io/081ad2a3-76cd-4aa0-b95e-e870ff75a65c/

Hardened: /usr/bin/pkcon: FAIL: cf-protection test because 
.note.gnu.property section did not contain the necessary flags


I'm not sure whether to report a bug to rpminspect or to annocheck. One 
or the other needs to stop testing for this.


The timing is unfortunate because the mass rebuild has started today. 
I'm not sure what the impact will be. I guess packages will build, but 
get stuck in gating?


Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: how to package dconf configuration for different language environments

2023-12-20 Thread Michael Catanzaro

On Wed, Dec 20 2023 at 04:33:22 PM +01:00:00, Vojtěch Polášek
wrote:

Is it possible to somehow insert a different string in the dconf file
depending on locale of the environment where the package is installed?

So first of all, dconf overrides are for system administrators, not
distro packagers. I would generally suggest dropping that and use a
gsettings override instead [1]. dconf is a gsettings backend. It's not
the only one. E.g. if ocrdesktop gets packaged as a flatpak, it will
use keyfiles for settings instead of dconf, and will never see your
dconf override.

OK, with that general advice out of the way, I'm not sure whether you
can set a locale-specific value via a gsettings override. Probably not,
so that is actually probably not what you want this time. In this case,
I would just patch the gsettings schema. For example, see [2]. This
allows translators to provide a good default value for the setting.
It's a lot easier if you do this upstream so that upstream translators
handle the translations for you.

[1]
https://src.fedoraproject.org/rpms/gnome-settings-daemon/c/440fa05202b0365e07b2cb3e3e693263888ca530?branch=f37
[2]
https://gitlab.gnome.org/GNOME/epiphany/-/blob/598cf2618e23dc1b7dab46d3e01dafa9bc35baf8/data/org.gnome.epiphany.gschema.xml#L36

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: libcap-ng upcoming change

2023-12-18 Thread Michael Catanzaro

On Mon, Dec 18 2023 at 01:17:43 PM -05:00:00, Steve Grubb 
 wrote:
So, what should I do to remove the patch? Do I push the new release 
into
rawhide without the patch or does this need to go through the Fedora 
Change

Process? And if so, self-contained or system wide?


Just remove it in rawhide. You don't need a change proposal to fix a 
bug. That's too much overhead!


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5: Checking signatures of packages installed out of a repository?

2023-11-14 Thread Michael Catanzaro

On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher 
 wrote:

I think for the sake of security, it'd be better if this were on by
default, and you just had to specify the --nogpgcheck
For convenience, the error message should probably say "Error: GPG
check FAILED (try again with '--nogpgcheck' to ignore)"
I don't think this use case is so important that everybody's security
should be lowered to avoid the minor inconvenience of passing a simple
flag.


Thing is, when manually installing RPMs that don't come from a 
repository, 98% of the time they are not expected to be signed by a GPG 
key that you have installed, so the check is expected to fail. GPG 
check is just not the right thing to do in this case. If we enable GPG 
checking when not appropriate, ***we will train users to reflexively 
ignore GPG errors.***


(We have already trained users to approve importing new GPG keys as 
long as they claim to be from Fedora, since this is required every 
Fedora release. This is bad enough.)


GPG check makes sense when installing RPMs from a configured 
repository, not when manually installing RPMs from a filesystem path or 
URL.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: EXIV2 BMFF Patents situation

2023-11-12 Thread Michael Catanzaro

On Sun, Nov 12 2023 at 01:48:25 PM +0100, Robert-André Mauchin 
 wrote:
So while I appreciate the caution, I think it's OK to just enable the 
BMFF code by
default (perhaps have an option to disable it, if someone is still 
for some reason worried,
but imo that would be an unfounded worry). Otherwise most of the 
modern image codecs (jp2,
jxl, avif and heic) end up being unsupported by default, for no good 
reason, which seems a

suboptimal situation.


Hi, Fedora already supports all of these except for HEIC (for good 
reasons). Honestly it doesn't seem like there is a real serious concern 
here.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packaging guidelines - validation of AppStream metadata files

2023-10-24 Thread Michael Catanzaro

On Tue, Oct 24 2023 at 08:06:12 AM -0400, Neal Gompa 
 wrote:

The two tools don't have incompatible ideas of valid metadata, we
intentionally don't do strict validation.


Well for one example incompatibility, you can review that issue:

https://github.com/ximion/appstream/issues/476

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packaging guidelines - validation of AppStream metadata files

2023-10-24 Thread Michael Catanzaro

On Mon, Sep 25 2023 at 09:15:37 PM -0400, Neal Gompa 
 wrote:

There was no switching. Both appstream-util and appstreamcli are
considered conformant.

Ultimately, the only way we can stop relying on appstream-glib is if
appstream-builder[1] was reimplemented on top of libappstream-compose.

Long ago, I tried to see if we could have our AppStream data produced
as repodata instead of a package, but the answer I got was that we
need the functionality added to createrepo to do it[2]. If someone
ever got around to making that happen, a lot of things in our pipeline
could be simplified.

[1]: 
https://github.com/hughsie/appstream-glib/tree/main/libappstream-builder

[2]: https://github.com/rpm-software-management/createrepo_c/issues/75


Hi,

Matthias Klumpp has suggested using a tool called appstream-generator:

https://github.com/ximion/appstream/issues/476#issuecomment-1776286096

It's pretty clear the two tools have incompatible ideas of what 
metadata is valid, and the apptsream-glib repo has a big warning that 
you shouldn't actually use it, so upstreams will continue to migrate 
from appstream-util to appstreamcli regardless of what Fedora does. 
We'll probably encounter more problems as time goes on.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - Miracle of the Sun edition

2023-10-13 Thread Michael Catanzaro

On Fri, Oct 13 2023 at 08:15:39 AM +0200, Miroslav Suchý 
 wrote:
Scancode-toolkit is not yet in Fedora, but you can instal it form 
PyPI:


$ pip install scancode-toolkit
 $  ~/.local/bin/scancode --license --html /tmp/spdx.html .



I attempted this, but unfortunately it depedns on intbitset which is 
incompatible with python 3.12, so it won't work if you've upgraded to 
Fedora 39. Example errors:


 intbitset/intbitset.c: In function ‘__Pyx_Raise’:
 intbitset/intbitset.c:15725:34: error: ‘PyThreadState’ {aka 
‘struct _ts’} has no member named ‘curexc_traceback’

 15725 | PyObject* tmp_tb = tstate->curexc_traceback;
   | ^~
 intbitset/intbitset.c:15728:19: error: ‘PyThreadState’ {aka 
‘struct _ts’} has no member named ‘curexc_traceback’

 15728 | tstate->curexc_traceback = tb;
   | ^~


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning all my packages

On Tue, Oct 3 2023 at 03:32:36 PM -0400, Solomon Peachy via devel 
 wrote:

However, this has _always_ been the situation for RHEL.  Only the
sources for the _latest_ point release (eg RHEL 7.4) were ever made
available to the general public; updates/fixes backported to prior
versions (eg RHEL 7.3) never saw the precise corresponding sources
released (directly) to the public.  Pre-Stream CentOS therefore only
ever received updates for the _latest_ point release of RHEL.


So as you mention, we've indeed never published the code for "Extended 
Update Support" branches; that has always been private to customers 
only. But we did previously publish the code for the latest stable RHEL 
branches on git.centos.org, and no longer do so. That's what has 
changed.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning all my packages

On Tue, Oct 3 2023 at 02:23:34 PM -0400, Stephen Gallagher 
 wrote:

The *exact* set of source code that the package was built for is
included in the Source RPM and all of the individual changes that
comprised it are part of the c9s branch in CentOS Stream (or the
maintainer has been regressing code, in which case that should be
addressed). No, the git repo might not contain a specific git
reference that directly matches the SRPM you cite, but that's not at
all the same thing as "the code isn't available in git".


OK, technically the changes are indeed sort of included in the c9s 
branch in CentOS Stream, but only along with 6000 other upstream 
changes from the upstream source tarball. You'll never plausibly figure 
out what changes correspond to this RHEL update from CentOS Stream. You 
really need that RHEL subscription to get the SRPMs and diff them to 
see what changed. It's really an incredible stretch to claim the code 
is there in CentOS Stream when you have to search for the needle in a 
haystack to find them (and how would you possibly know what to look 
for?). And even this much is not guaranteed. I could have easily 
applied a different fix to this RHEL branch than I did to CentOS 
Stream. Such situations are hardly uncommon.


So let's stop this weird claim that the code is there, please; it's 
silly and just spreading confusion. We publish code for CentOS Stream. 
We don't publish code for RHEL anymore except to customers. That's just 
how it is.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning all my packages




On Tue, Oct 3 2023 at 07:46:58 PM +0100, Sérgio Basto 
 wrote:



it is here :
https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9


Well OK yes, but that only worked because my example was from before we 
stopped publishing sources to git.centos.org. You were supposed to use 
CentOS Stream for this exercise. :P


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning all my packages

On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce  
wrote:
Additionally *all* of the code is fully available in git form on 
gitlab

as part of CentOS Stream.


We all know or should know that this is false. It's easy enough to 
disprove with a counterexample:


https://access.redhat.com/errata/RHSA-2023:1918

Try to find the code for that webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in 
CentOS Stream. It isn't there, and never will be.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide

2023-09-27 Thread Michael Catanzaro

On Wed, Sep 27 2023 at 12:52:17 PM -0400, Carlos O'Donell 
 wrote:
You have 5 years of excellent documentation by Florian and others to 
catch up on! :-)


Random compliment: this documentation is indeed quite good.

Upstream freedesktop-sdk and GNOME build flags are based on Fedora's 
because these docs clearly explain what every flag does and why it's 
wanted.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packaging guidelines - validation of AppStream metadata files

2023-09-23 Thread Michael Catanzaro

On Sat, Sep 23 2023 at 10:26:48 PM +0200, Alexander Ploumistos 
 wrote:

Could someone involved
with AppStream please provide some information? Shouldn't our
documentation be changed to reflect these changes? Does the FPC need
to decide on this?


From upstream perspective: appstream-util is indeed obsolete. Upstream 
software should stop using it and switch to appstreamcli instead.


But as you've noticed, it seems Fedora isn't ready for that yet

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 39 Beta Released

2023-09-19 Thread Michael Catanzaro



Um, sorry, actually yes it is a cache control issue. My browser's 
shortcut to "reload bypassing cache" is actually Shift+F5, not Ctrl+F5. 
Well, drat, that would have been good to know a long time ago. Now 
after trying the correct shortcut I see the beta downloads toggle.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 39 Beta Released

2023-09-19 Thread Michael Catanzaro

On Tue, Sep 19 2023 at 08:14:04 AM -0700, Kevin Fenzi  
wrote:

Caching issue?


Nope, I've used Ctrl+F5 to "reload bypassing cache."

I actually now notice that a toggle (presumably the "show beta 
releases" toggle) briefly appears when loading the page with Ctrl+F5, 
but then it immediately disappears.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 39 Beta Released

2023-09-19 Thread Michael Catanzaro

On Tue, Sep 19 2023 at 04:01:59 PM +0200, Tomas Hrcka 
 wrote:

Download the prerelease from our Get Fedora site:
* Get Fedora Linux 39 Beta Workstation:
https://getfedora.org/workstation/download/
* Get Fedora Linux 39 Beta Server: 
https://getfedora.org/server/download/

* Get Fedora Linux 39 Beta IoT: https://getfedora.org/iot/download/
* Get Fedora Linux 39 Beta CoreOS: 
https://fedoraproject.org/coreos/download/
* Get Fedora Linux 39 Beta Cloud: 
https://fedoraproject.org/cloud/download


Uh-oh. I see we can download the beta version of Server and Cloud by 
toggling the "Show Beta Downloads" switch, but there doesn't appear to 
be any way to download the beta for Workstation or IoT.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: An update on RHEL moving to issues.redhat.com

2023-09-11 Thread Michael Catanzaro

On Mon, Sep 11 2023 at 08:00:29 AM -0400, Solomon Peachy via devel 
 wrote:

Not to retread old drama, but doesn't Fedora now rely on a proprietary
version of Gitlab?


No? All of our packages are on https://src.fedoraproject.org/ and our 
Fedora-specific source code goes on https://pagure.io/. These are both 
Pagure, not GitLab. It is open source.


I think we *should* move to GitLab, but only if it's an open source 
GitLab instance like most other major open source projects use (GNOME, 
KDE, freedesktop.org, Debian, etc.) We should not depend on proprietary 
services to build Fedora unless there is no suitable alternative, and 
there are *many* suitable alternatives here. This is core to Fedora's 
mission and identity. It wouldn't be strategic to compromise on this.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Adding Passim as a Fedora 40 feature?

2023-09-07 Thread Michael Catanzaro

On Thu, Sep 7 2023 at 12:55:03 PM +0200, Fabio Valentini 
 wrote:

Sure, but that means it will still be started on Fedora with default
configuration, unless I misunderstand something?


It will. D-Bus services are a little weird because they often ship 
systemd services but they're still effectively enabled by default even 
if the systemd service is disabled. The disabled preset means systemd 
*itself* will not activate the service, but dbus-broker still will. 
This is sort of an end run around the expectation that FESCo approve 
new services, but FESCo only approves systemd presets, and no preset is 
required for D-Bus services. And almost all desktop services are D-Bus 
services.


It's actually not *too* serious of a problem IMO, because packages 
generally make good decisions, and somebody is going to notice if 
something unwanted appears. But it's probably not what you're expecting 
if you're thinking that new services have to be approved.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F38 to F39

2023-08-29 Thread Michael Catanzaro

On Tue, Aug 29 2023 at 08:26:42 AM -0700, Adam Williamson 
 wrote:

This is likely because it defaults to `--allowerasing` behaviour? This
is kinda a controversial topic. GNOME Software also does this, and I
don't *love* it as it can result in people being surprised by packages
having disappeared on upgrade. ('allowerasing' means, basically, if a
package like this is blocking the transaction, just remove it).


GNOME Software warns exactly which packages would be removed by an 
upgrade, so there should be no surprises. (This is afaik the only place 
where packages are exposed in the UI. Normally Software only shows 
applications and plug-ins.)


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Heads-up: webkit2gtk4.0 and javascriptcoregtk4.0 subpackages to be dropped

2023-08-15 Thread Michael Catanzaro


Hi,

Since Fedora 39 has been branched, it's now time to remove the 
webkit2gtk4.0 (and javascriptcoregtk4.0) subpackages from rawhide to 
implement the Fedora 40 change proposal:


https://fedoraproject.org/wiki/Changes/Remove_webkit2gtk-4.0_API_Version

A reminder that webkit2gtk4.0 provides WebKitGTK for applications that 
use GTK 3 and libsoup 2. The migration path is to switch to 
webkit2gtk4.1, which contains no API changes but links to libsoup 3 
instead of libsoup 2. All applications that still depend on both 
WebKitGTK and libsoup 2 [1] will break until fixed.


Michael

[1] 
https://fedoraproject.org/wiki/Changes/Remove_webkit2gtk-4.0_API_Version#Dependencies


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Broken Discrete/Dedicated GPU support

2023-08-14 Thread Michael Catanzaro

On Mon, Aug 14 2023 at 07:19:05 PM +0200, Jan Drögehoff 
 wrote:
I've looked into contributing to fix the issue, but from the outside, 
it
appears that RedHat is no longer interested in spending resources on 
it,

essentially leaving it unmaintained for the time being.


Unfortunately yes. There is more info here:

https://www.hadess.net/2023/08/new-responsibilities.html

Red Hat has instructed us to stop work on several core desktop 
components. All of these components need new maintainers now. The 
switcheroo-control repo has now been archived, and a future new 
maintainer will need to recreate the repo in a new location. It's 
certainly not good news. :(


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently

2023-08-11 Thread Michael Catanzaro

On Fri, Aug 11 2023 at 02:24:22 PM +, Christopher Klooz 
 wrote:
First of all, I don’t use my Fedora installations until their end 
of life, so I don’t know if we have any means in place that shall 
make users aware once their release reaches end of life?


Fedora Workstation will display a nag notification once per week when a 
newer release is available, so unless you uninstall GNOME Software or 
ignore all notifications, you should at least be aware that a newer 
version is available.


I had thought we had daily nag notifications once the release has 
reached end of life, but maybe I was imagining it because I can't find 
any evidence that this actually exists. I think GNOME Software should 
look at SUPPORT_END in /etc/os-release and nag more frequently.


Highly recommend other Fedora editions consider similar notifications.

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

2023-07-24 Thread Michael Catanzaro

On Mon, Jul 24 2023 at 10:08:50 AM -0400, Demi Marie Obenour 
 wrote:
I saw that libguestfs has a guestmount(1) tool, and I think this 
could be
a potential solution.  An exploit against the kernel FS driver would 
only
grant access to a KVM guest, and the QEMU process can be tightly 
sandboxed

by means such as seccomp and SELinux.


Ah, interesting. Maybe something like that would work, indeed

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

2023-07-24 Thread Michael Catanzaro

On Sun, Jul 23 2023 at 11:18:45 PM -0400, Demi Marie Obenour 
 wrote:

Then the mount needs to be done in a sandbox, such as a KVM guest or
sandboxed userspace process.


Hmmm... I don't think traditional sandboxing accomplishes anything 
here, because we're trying to protect against kernel bugs, not 
userspace bugs, and if the kernel is compromised then you escape the 
sandbox. A KVM virtual machine would solve that, certainly, but that 
sounds really complicated to do? We don't have any precedent for 
spinning up virtual machines to perform normal desktop operations. 
Doesn't that require hardware support anyway? i.e. virtualization might 
be disabled at the firmware level?


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

2023-07-22 Thread Michael Catanzaro

I've been thinking about this for a while. The status quo is really 
awful.


On Sat, Jul 22 2023 at 11:31:22 AM +, Zbigniew Jędrzejewski-Szmek 
 wrote:

A bigger problem I see, is that if a user plugins in a usb stick,
expecting to make use of it, and it's not automounted without any
explanation, they are most likely to just click for it to be mounted,
or to even issue an explicit 'mount', defeating the whole protection.


Yup, there's the problem. The user will almost always mount it 
manually, so disabling automount seems pointless.



A more reasonable UI would be to display a pop-up that says "Device
ASDF uses file system AmigaFS 1982 which is not well supported. See
https://some.link/ for details. Do you want to a) mount once, b) not
mount, c) mount this fs type always?". This would require some work
in DE.


The UI would have to not mention technical details like the name of the 
filesystem. Also, warning a user that the filesystem is not 
"well-supported" is also not likely to accomplish much. The user 
plugged in the USB stick in order to look at files, and will almost 
always choose to do so if presented with the option. Even if we warn 
that the device may be malicious (which we don't actually know), users 
will still just think about it and decide "probably not, I want to see 
my files."


The desktop security model assumes the kernel is robust to malformed 
filesystems and removing that assumption is just not workable. This 
development mindset might be prevalent among kernel developers, but 
it's not acceptable for desktop users.  Filesystems that are not 
designed to be robust to untrusted input should be disabled outright 
and not supported at all. I'm not sure how practical this actually is, 
though, because I think it would probably entail disabling common 
filesystems (ext4? xfs? btrfs?) in addition to uncommon filesystems. 
Starting with disabling uncommon filesystems is better than nothing, 
though.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-22 Thread Michael Catanzaro

On Sat, Jul 22 2023 at 02:44:30 AM +, "Smith, Stewart via devel" 
 wrote:
I’d almost prefer we work out a policy where anything of the sort 
is disabled by default, and with a distro-wide standard bcond to not 
even compile it in as an option. (No, I don’t quite know how that 
could be worded sensibly as a policy…. but it’s where I think 
I’d prefer to start from).


You can just not package the eos- packages (eos-metrics, 
eos-event-recorder-daemon, eos-metrics-instrumentation). 
eos-event-recorder-daemon is the package that actually sends metrics. 
Without that, no metrics. And nothing should have a hard dependency on 
it, so no bconds should be needed. If you have some denylist somewhere 
that throws an error if an unwanted package exists, that should 
robustly ensure it's never enabled.


For everything else, the test for whether to send metrics is "is the 
event recorder bus name owned?" so no conditional compilation or bconds 
is needed.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

2023-07-20 Thread Michael Catanzaro

On Wed, Jul 19 2023 at 06:50:24 PM -0400, Chris Murphy 
 wrote:
If restricted to desktops, then we can only do it with kernel 
parameters. That probably means doing it in Anaconda kickstart, with 
a per edition/spin option for doing so.


I'm not fond of this solution. In practice, this would likely mean the 
new preemption mode would apply only to new installs and not also to 
upgraded systems, right?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

2023-07-11 Thread Michael Catanzaro

On Tue, Jul 11 2023 at 09:18:57 PM +0200, Leon Fauster via devel 
 wrote:

C8S ends 2024, while RHEL8 ends 2029
C9S ends 2027, while RHEL9 ends 2032


You're forgetting the Extended life cycle support phase. RHEL 8 and 9 
will both have a 13-year lifecycle (down from 14 years). See this table:


https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-11 Thread Michael Catanzaro

On Tue, Jul 11 2023 at 02:19:31 PM -0500, Jeremy Linton
wrote:
Having finally had a chance to look at the list of collected metrics
i'm

a bit worried about just how much information is being/can be gathered
by the project, as well as the frequency it is being gathered.

Personally, I think it would benefit fedora if questions such as "is
anyone actually using this hardware/driver/package" could be answered.
OTOH, the metrics presented above go far beyond that. I'm not sure why
its necessary to know how many times, or how long a particular
application is being used.

I think Endless needs more data than we do. ;) If they don't have
application usage data then they could be *really* wasting their time
developing stuff that users are not using. Fedora works a quite
differently, but I can imagine we'd still be interested in counting use
of at least some applications (e.g. was GNOME Builder started today?).

For avoidance of doubt, we won't actually collect the same metrics that
Endless does. Metrics collected by Fedora will need to be individually
approved via some sort of community process.

So, I would suggest that the intended metrics are included as part of
this proposal as well as the interval, and that it wouldn't be changed
without further community approval. Doing this would go a long way to
convincing me, and likely others, that its not worth the effort to
manually rip the entire subsystem out of fedora at the first chance on
my machines.

I agree that community approval should be required to make changes to
what data we collect.

I was really hoping the initial proposal would not include particular
metrics, so that each metric could be discussed separately outside the
discussion of whether we should do this at all, but a lot of people are
requesting this, so maybe we'll need to add a few.

If there is to be a "process" for changing them, then I think that
needs

to be documented here rather than hand waving it away too.

I agree. Once we agree on what process should be used, I'll edit it
into the change proposal. I've started a discussion on this here:

https://discussion.fedoraproject.org/t/potential-process-and-policies-for-approving-particular-metric-collection-a-breakout-topic-for-the-f40-change-request-on-privacy-preserving-telemetry-for-fedora-workstation/85632/2

IMHO, the data shouldn't be collected more frequently than every 6
months or so, which allows each collection to be presented to the
user,

rather than having it just uploading the data in the background. Nor
should it be tracking _user_ actions, which I would differentiate from
machine state (bios machine type, RAM, installed packages, application
crashes, failed suspend/resume, kinds of things).

But given course grained tracking, why isn't it part of server/IoT/etc
as well, other than the current focus on gnome? Surely knowing that
only

one user is running $APPLICATION on a server is useful too.

We do want to track user action, though (e.g. "what control center
panels are used the most?"

6 months is too infrequent. I'm open to discussing how frequently
metrics are uploaded, but I think the current value is 30 minutes.
Presenting each collection to the user would be too much clutter, but
I'll plan to build some way to inspect this manually for users who want
to do so.

I think telemetry would be useful for server, IoT, and Fedora spins as
well, but this is something for each edition or spin to decide for
themselves. The technology is somewhat tied to GNOME because it depends
on D-Bus and GVariant, but it can be used on servers too.

I also think its useful here to describe _exactly_ how to
disable/remove

the component, as well as where the opt-in/out settings are stored in
the filesystem, how to change it, and where the log of reported data
for

a given machine can be retrieved.

You can do: sudo dnf remove eos-event-recorder-daemon

The settings are stored in /etc/metrics/eos-metrics-permissions.conf

I'm not sure about logs of reported data, I agree but we'll have to
build such functionality if it doesn't exist already.

I'll create a note to edit this into the change proposal.

To make this a little more confusing, metrics collection is actually
separate from uploading. Collection is always initially enabled,
while

uploading is always initially disabled. The graphical toggle enables
or disables both at the same time. That is, a newly-installed Fedora
system will always collect metrics locally at first, but the
collected

metrics will be deleted and never submitted to Fedora if the user
disables the metrics collection toggle on the privacy page. If the
user leaves the toggle enabled, then the collected metrics may be
submitted only after finishing the privacy page.

(trimmed rest)

Thanks for getting this far.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-11 Thread Michael Catanzaro



I think what happens is: somebody (anybody) can report a post, if it 
gets enough reports it gets proactively hidden before a moderator can 
review it. Do our moderators eventually review such posts to ensure 
they're truly inappropriate? Seems clear that the post is question 
should not have been hidden.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-08 Thread Michael Catanzaro

On Fri, Jul 7 2023 at 09:21:15 PM -0400, Demi Marie Obenour 
 wrote:
For metrics to not be personally identifiable, it is necessary that 
the
set of metrics collected have sufficiently low entropy that on 
average,
_many_ users will send _the exact same metrics_.  It is very hard for 
me

to see any useful set of metrics having such low entropy.

If Fedora has 2 million users (possibly an overestimate) then the
metrics would need to have entropy much less than 2^21, which means
that the entire metrics set would need to be able to be represented
as a 20-bit integer.  In practice, I suspect one would need to fit
the entire set in a 16-bit integer or less, and possibly
_significantly_ less.


We're not going to build creepy user profiles. Particular metrics will 
be stored individually, not correlated together.


Let's say we have two metrics:

Key | Value

User launched GNOME Builder today? | y/n
User has NVIDIA proprietary driver | y/n

We would know how many users launched Builder and how many users have 
NVIDIA graphics, but we wouldn't know how many NVIDIA users launched 
Builder because there's just no need to tie those two data points 
together.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-08 Thread Michael Catanzaro

On Sat, Jul 8 2023 at 12:08:09 AM +, Randy Barlow via devel 
 wrote:

I agree.

I think it is important to make it possible for a user to ask for the
data collected from their machine to be deleted in the event they
mistakenly submitted data, or changed their mind.


To be able to delete your data on request, we would have to maintain 
user profiles such that we can tell which user submitted the data. 
That's invasive and would drastically reduce your privacy. We don't 
want to be able to figure out which user submitted particular data. 
That doesn't make sense for Fedora.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-07 Thread Michael Catanzaro

On Fri, Jul 7 2023 at 12:25:12 PM -0500, Bruno Wolff III 
 wrote:
Is there going to be a recommended way to not accidentally install 
this stuff? I'm guessing the least work (for Fedora) would be to 
black list the key packages in the repo files. Making available a 
package that conflicts with them could be done, but it could 
accidentally get removed during and --allowerasing change. But this 
might be easier when doing installs.


Well I wouldn't necessarily expect it to be easy to install by mistake, 
but I do want to make sure it's not harmful if that happens somehow. So 
even if the packages are installed, they're still not going to upload 
metrics to Fedora without further user consent.


The local collection is a bit of a hole, but I like your suggestion to 
put a short time limit on that. Perhaps we can collect for something 
like one hour locally, then delete if the user has not consented to 
upload before then. Something like that.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-07 Thread Michael Catanzaro

On Fri, Jul 7 2023 at 12:03:14 PM -0500, Bruno Wolff III 
 wrote:
Note that collecting the data by default increases the harm if 
someone accidentally enables telemetry and then notices the issue 
after data is reported.


Is there going to be some time limit on the data that is stored and 
not uploaded yet?


We can implement a time limit. The main purpose of this is so that we 
have the ability to collect data between first boot and the privacy 
panel in gnome-initial-setup. I'll add this to the feedback section of 
the change proposal.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-07 Thread Michael Catanzaro

On Thu, Jul 6 2023 at 09:27:47 PM +0200, Florian Weimer 
 wrote:

What about packages which already collect metrics and report them
somewhere (not necessarily to Red Hat)?  Would these packages need to
change under this proposal?  If not, how do we explain this to our
users?


No, packages that are already collecting their own metrics separately 
would not be affected.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

On Thu, Jul 6 2023 at 09:40:59 PM -0400, Demi Marie Obenour 
 wrote:

It needs to be off by default.  See KDE’s telemetry policy


Again, if it's off by default then the data will be garbage. There is 
no point in doing opt-in telemetry. I would withdraw the proposal 
entirely if we cannot do it opt-out.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

On Fri, Jul 7 2023 at 01:39:24 AM +, Maxwell G  
wrote:

I don't see an attachment.


Trying again.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

On Thu, Jul 6 2023 at 07:42:47 PM -0400, Demi Marie Obenour 
 wrote:

Then make the metrics be neither opt-in nor opt-out.  Have
“Enable telemetry (y/n)?” be a mandatory question in the 
installer,

which the user must answer.


The problem is if users are expected to answer, they are going to 
probably answer No and it's effectively the same as an opt-in. But if 
we have a default value, users will be inclined to leave the default 
value.


My plan is to put this switch in gnome-initial-setup, not the 
installer. But it will have a default value.


Remember, for avoidance of doubt, we will NEVER enable telemetry upload 
without the user's consent, which is indicated by either (a) not 
flipping the telemetry switch in gnome-initial-setup to the off 
position, or (b) flipping the telemetry switch in gnome-control-center 
to the on position. (The telemetry might be enabled *locally only* for 
users who upgrade from previous versions of Fedora Workstation and who 
therefore have not seen the consent switch, but the data will never be 
uploaded to Fedora. And upgraded users will see the switch default to 
off rather than on, so it really will be opt-in for upgraded users.)


I'm attaching a screenshot to give an idea of what this would look like 
in gnome-initial-setup. I don't have a gnome-control-center screenshot 
handy, but it would be similar, except there it would default to off.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)




On Thu, Jul 6 2023 at 11:33:03 PM +0200, Michal Domonkos 
 wrote:
Given the detailed proposal, it's probably too late now for any 
fundamental
changes, but there's a formal research area called Differential 
Privacy [1]
that deals with the collection of user data in such a way that it 
preserves the

privacy of each participating individual.


No, it's not too late for fundamental changes. Big changes would make 
this harder and take longer, but we're still very early on here. If the 
Fedora community wants to completely throw out the Endless system and 
use something else instead, that would be sad since it would mean more 
work for me, but we're still at the point where that's possible. (I'd 
*much* rather make changes to the existing system to adapt it to our 
needs, though. :)


But remember we do not want to keep information about individuals in 
the data set in the first place. It's easier to dodge privacy concerns 
if we just don't store such associations at all.


As for differential privacy, I'm quite unfamiliar with this topic so I 
don't know to what extent it could be useful, but Endless is interested 
in adding randomized response [1], where say 50% of the data sent is 
fake and the other half is accurate. This only works for boolean and 
possibly integer data, but it would make it even harder to deanonymize 
reporterd data. But that is not supported yet.


[1] 
https://blogs.gnome.org/wjjt/2023/07/05/endless-oss-privacy-preserving-metrics-system/



Have you guys, by any chance, considered looking into that for some
inspiration?

Either way, if anyone is curious, there's a nice and easy-to-read 
write up on

the key concepts:
https://desfontain.es/privacy/differential-privacy-awesomeness.html


I will add that to my reading list. Certainly it seems a lot less 
intimidating than the Wikipedia article. ;)


A specific set of algorithms (RAPPOR) for collecting arbitrary user 
strings
that preserves Differential Privacy has been proposed (and 
implemented) by

Google a while back, too:
http://arxiv.org/abs/1407.6981
https://github.com/google/rappor


Wow. I'll add this to my reading list too, although remains to be seen 
whether I'll be able to understand it. :D


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)




On Thu, Jul 6 2023 at 11:08:15 PM +0200, Björn Persson 
 wrote:

As a non-user of Gnome 3 who normally never runs any Gnome 3 settings
programs, I get the impression that Fedora 40 will begin accumulating
unused metrics somewhere in the filesystem. To prevent a constantly
growing waste of storage space, I'll have to run one of two Gnome 3
settings programs – which may or may not require starting a Gnome 3
desktop session – and find the right switch to either turn on 
uploading

or turn off collection. I'll have to remember to do that after
upgrading around a year from now, and also on any new installations in
the distant future.

If my impression is wrong, then the change proposal needs to be 
amended.


Well this change proposal is for Fedora Workstation specifically. 
That's in the title. :) I would envision installing 
eos-event-recorder-daemon via a Recommends: from the 
gnome-control-center and gnome-initial-setup packages (and probably 
also by adding it to the workstation-product comps group), so if you 
don't have gnome-initial-setup or gnome-control-center installed, you 
wouldn't get in on upgrade. I'm not sure whether I want to amend this 
level of detail into the change proposal in case we might want to 
change the specifics of how it gets installed, but that's just to give 
you an idea of what I'm thinking currently. Certainly the metrics 
components should not be installed for non-GNOME users as part of this 
change proposal.


However, I've heard that Fedora KDE might also be interested in adding 
metrics once we have this working in Workstation. But that would be up 
to the people contributing to Fedora KDE and would need to be proposed 
separately.


I think eos-event-recorder-daemon uses some sort of ring buffer to 
eventually discard old events, so that storage space does not increase 
forever and should not become an issue? But please don't quote me on 
this; I have a lot of comments to respond to, and I'm not super 
familiar with the code, and I don't want to dive in to look at how it 
works right now. If there's really an issue with space growing without 
bound, then that's a bug we should fix, but I don't think it's so.


(BTW, the GNOME 3 era concluded with the release of GNOME 40 in Fedora 
34, so I wouldn't except Fedora users to still be using GNOME 3. :)


Michael




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)



On Thu, Jul 6 2023 at 08:19:07 PM +0200, Vitaly Zaitsev via devel 
 wrote:

All telemetry collection MUST be an opt-in feature (disabled by
default). I'm strongly against enabling it by default.


As explained in the proposal document, we know that opt-in metrics are 
not very useful because few users would opt in, and these users would 
not be representative of Fedora users as a whole. We are not interested 
in opt-in metrics.



Please add the ability to completely get rid of it by removing the
telemetry collector package.


It should be possible to uninstall eos-event-recorder-daemon and 
eos-metrics-instrumentation. I'm not sure if eos-metrics will be 
uninstallable, but that package basically just provides D-Bus API and 
doesn't do anything on its own. (eos-event-recorder-daemon is the 
component that actually uploads metrics.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)



On Thu, Jul 6 2023 at 08:41:03 PM +0200, Simon de Vlieger 
 wrote:
I don't understand where my reply is supposed to go so here it is on 
the mailing list *and* on the forums? Are the change proposal owners 
reading both?


In theory, we're supposed to be discussing this on Discourse to make 
sure that platform is indeed suitable for change proposal discussions. 
I will respond to comments on this list too, though.


Since you posted this on Discourse as well, I'll respond to you there.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-07-03 Thread Michael Catanzaro

On Mon, Jul 3 2023 at 12:32:02 PM -0400, Demi Marie Obenour 
 wrote:

Why is that?  WebKitGTK+ is one of those packages that one should only
ship if one is willing to take every update from upstream, but my
understanding is that WebKitGTK+ tries quite hard to make this easy.


The set of packages to include in ELN is a business decision (which is 
in contrast to normal Fedora, where Fedora contributors should 
hopefully be making decisions in the best interest of the Fedora 
community). Although I don't get to talk directly about future 
enterprise Linux, what we are doing in ELN is inherently public and you 
can see some discussion here:


https://src.fedoraproject.org/rpms/webkitgtk/pull-request/4

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-07-03 Thread Michael Catanzaro

On Mon, Jul 3 2023 at 06:15:43 PM +0200, Simon de Vlieger 
 wrote:
Funnily enough it was switched explicitly from webkitgtk to Firefox 
for

a reason I forget; I think it was related to disk size. Perhaps Martin
or Jiri has more details to share on that.


It's because we're going to remove WebKitGTK from ELN.

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

On Sun, Jul 2 2023 at 06:27:48 PM -0400, Demi Marie Obenour 
 wrote:

What about stuff that is too urgent to wait on Red Hat QA?  There have
been vulnerabilities (such as CVE-2013-0156 and Log4Shell) for which
unauthenticated, fully automated, remote code execution exploits have
been found very, _very_ quickly.  There may well be times when
attackers can write and use an exploit faster than Red Hat QA can
process an update.  For these vulnerabilities waiting on Red Hat QA
is not an option.


Dire emergencies like these are extremely rare, but when they do occur, 
everybody needs to work together to get updates out to all users ASAP. 
That's true for every distro. Hypothetically speaking, if I were ever 
unfortunate enough to be responsible for an emergency scenario like 
that, I'd still want enough basic QA to at least ensure that the update 
won't eat your disk, but such decisions would surely be handled on a 
case-by-case basis.


In a more normal situation, updates take a few days to prepare. I 
really don't think there's any problem with how CVEs are handled in 
CentOS Stream *except* for the problem I mentioned earlier about 
maintainers forgetting to push package updates to CentOS Stream by 
mistake. We need a better process to ensure human error doesn't result 
in CentOS Stream missing security or non-security updates. (This 
impacts RHEL too, because future minor releases are built from CentOS 
Stream, and we don't want fixes to disappear in future releases.)


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages




On Sun, Jul 2 2023 at 04:59:39 PM -0400, Demi Marie Obenour 
 wrote:



Fedora Flatpaks are also a security disaster: they are shipped in OCI
format instead of OSTree format, but they aren’t signed by anyone.
I’ve disabled the Fedora remote and recommend that others do the 
same.


I didn't know about this problem. I agree that sounds pretty bad. I'm 
going to ask some colleagues to comment on this.


There are, frankly, many other serious problems with Fedora Flatpaks, 
most notably lack of regular updates when the app or bundled 
dependencies are updated in Fedora. I think of them as a tech preview 
that we shipped too early. But these problems are not insurmountable, 
and if we can get it right, building Flatpaks from RPMs will allow 
Fedora to deliver applications packaged at Fedora's high level of 
quality in a modern and safer format.



 My $0.02: maintaining complex desktop applications as part of the
 operating system requires significant effort and produces low value 
for

 users when you can easily install that app from Flathub instead. (It
 *especially* doesn't make sense to do in RHEL, but let's focus on
 Fedora here.)


What is your reasoning here?  I’m not saying I disagree with you, 
but
I want to know *why* you believe this, especially since flatpaks 
consume

additional memory and disk space compared to RPMs.


I do not believe that Flatpaks consume significant additional memory. 
OK, host shared libraries and flatpaked libraries will be loaded at the 
same time, but I really doubt that's going to be at all significant. 
They do consume significant disk space if your disk is really small. 
ostree deduplication is pretty good, though (and OCI images are 
deduplicated too):


https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

So I don't think many users will seriously care about additional memory 
use or disk space.


As a matter of strategy, packaging applications is fine, but nowadays 
it is *optional*. 15 years ago, if Fedora did not ship an application, 
you had to compile it yourself or, more likely, switch to Ubuntu or 
Debian because they have more applications available. That is not the 
case today. Our most popular applications are nowadays available from 
Flathub or other third-party sources, and users are going to install 
them regardless of whether we package them. Having Fedora packages 
provides users with another way to use applications they would use on 
Fedora anyway. So for the most complex applications, where packaging is 
difficult or time-consuming, Fedora packagers will have to decide for 
themselves whether it still makes sense to do that work as opposed to 
other possible Fedora work.


(Flatpaks without sandbox holes are also dramatically more secure than 
Fedora RPMs, which is why I'm *really* interested in Flatpaks. But 
currently application declare too many holes: 
https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html 
)


Anyway, I don't mean to suggest we should stop packaging applications 
or that the work to keep the LibreOffice packages maintained is not 
valuable (thank you to everyone working on that). Being able to 
continue shipping LibreOffice by default is especially important for 
users who do not already know about LibreOffice and would otherwise not 
realize that Linux has an office suite available. What I really meant 
there was that packaging applications is not the most valuable way for 
Red Hat to contribute to Fedora. Contrast the LibreOffice announcement 
to Bastien's announcement that Red Hat is orphaning a large number of 
core desktop packages that are not applications and cannot be replaced 
by Flatpaks. This one will be much more challenging for Fedora deal 
with. :/


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat & Fedora -- largely stepping out of this ecosystem




On Sun, Jul 2 2023 at 08:33:46 AM -0700, Carlos Rodriguez-Fernandez 
 wrote:

Hi Michael,

We have been told repeatedly that "the source is there" in CentOS
stream.


The source for the next minor version is there.


I can see the scenario that RH branches from CentOS stream to
create a new minor release, and during QA, a bug is discovered and a
patch is backported (or created) to fix it internally in your minor
release branch. However, if that bug wants to be addressed also in the
next minor release, it will need to appear in the CentOS stream at 
some

point, whether via a patch or an entire source version bump.


Right; nobody wants regressions. In this particular example, the fix is 
there via "an entire source version bump."


If that's not the case, then RH is having some long living parallel 
git

repo which will eventually create ABI compatibility issues, and it is
also not what we have been told.


So I'm really primarily here to talk about Fedora and CentOS Stream, 
because we often can't talk very much about RHEL. I'm going to point 
you to this page:


https://access.redhat.com/support/policy/updates/errata/

And in particular this graphic:

https://access.redhat.com/sites/default/files/images/337_rhel_9_life_cycle_updates_0423.png

Suffice to say the lifecycle you see here only works if there are lots 
of long-lived parallel branches. ;) Branching does not inherently lead 
to ABI issues. For more info on ABI:


https://access.redhat.com/articles/rhel9-abi-compatibility

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

On Sun, Jul 2 2023 at 09:53:30 PM +, "Smith, Stewart via devel" 
 wrote:
With this development model, what is the thought for those who may 
want to / be able to submit pull requests to CentOS Stream with 
security fixes?


It really depends. CentOS Stream does accept merge requests. With 
respect to security fixes in particular, I would certainly expect Red 
Hat would accept most merge requests that fix security problems. 
However, landing any change requires a relatively high amount of effort 
from a relatively large amount of people compared to Fedora, where 
packagers are in charge and things are much simpler. So whether or not 
your merge request will be accepted into CentOS Stream will be a 
business decision rather than a community decision. Factors that are 
outside your control will be considered (e.g. "how busy is QA team 
right now?") So my suggestion is to talk to the developers you see in 
the package changelog before submitting a merge request. Merge requests 
will often (hopefully even generally) be welcome, but not always. It's 
open source, but it's not a true community project like Fedora.


For WebKitGTK specifically, I'm not interested in patching individual 
CVEs in CentOS Stream: it's generally much easier and safer to just 
always update to the latest upstream release instead.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

On Fri, Jun 30 2023 at 05:40:33 AM +0200, Kevin Kofler via devel 
 wrote:
So Red Hat is essentially killing all work on desktop packages, not 
just on

LibreOffice?


No. Losing Bastien is extremely unfortunate and demoralizing, but we 
are not killing all work on desktop packages.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

On Fri, Jun 30 2023 at 11:09:41 AM -0700, Carlos Rodriguez-Fernandez 
 wrote:

Going forward, you will see those patches contributions going into
Centos stream first, and they will be accepted by RH engineers, and 
then

they will end up in CentOS Stream distro first, and finally in RHEL.


Just for the record: no, you'll never see updates like those in CentOS 
Stream because that was a stable branch update after RHEL had already 
branched from CentOS Stream. Those patches will never appear in CentOS 
Stream because I do not push them there.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

2023-06-28 Thread Michael Catanzaro




On Thu, Jun 29 2023 at 12:24:23 AM +0200, Fabio Valentini 
 wrote:
Thanks for the clarification, though this is only partially 
reassuring:

I'm not sure how this accounts for the fact that there are some
situations in which weak dependencies are *not installed at all*.
Most notably, they are not installed into build environments *at all*
(i.e. mock sets `install_weak_deps=0`).


I guess this is OK. It's not what I would have expected, but if 
something important winds up missing, it just means you need more 
BuildRequires and is generally not a big deal.



I'm not sure how the process that builds ISOs and container images
handle this, but I assume they set this option as well.
So we'd need to be careful not to remove "hard" dependencies on tzdata
and replace them with lots of "weak" dependencies all over the place -
just to find out that it ends up missing from important places because
they disable weak dependencies.


For Recommends/Supplements weak dependencies to be useful, packagers 
must be able to assume they are installed by default. With that 
assumption, you can stop second-guessing when to use weak deps; without 
that assumption, nothing works and the weak deps are not useful.  
Accordingly, most ISOs, container images, etc. should be built with 
weak dependencies enabled; it would be a serious bug if weak deps were 
missing from the Fedora Workstation images, for example. Opting out of 
weak deps should be done with the understanding that there will be 
degraded functionality and some features will not work. E.g. minimal 
images will want to be really minimal and not install the weak deps, 
even though this means missing timezones.


Because Recommends and Supplements are installed by default, we need to 
be careful and use them sparingly, only when it really makes sense for 
some package to be pulled in for almost all users of another package. 
Thus far, Fedora and RHEL have done a good job of this, primarily 
because we were very late to the weak dep party and have had much more 
time to learn best practices and much less time to screw up. This is in 
contrast to some other distros where it's common for users to disable 
weak deps to avoid "bloat." We don't ever want our 
Recommends/Supplements to be considered bloat. (That's what 
Suggests/Enhances is for. :) And since they're not bloat, they should 
be respected when building most non-minimal images.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-06-28 Thread Michael Catanzaro

On Wed, Jun 28 2023 at 07:06:13 PM +0200, Jiří Konečný 
 wrote:
However, I'm not sure how you can start Orca on the Workstation Live 
environment. Would be great to find that out from someone who knows 
GNOME more than me.


Should be: Alt+Super+S

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

2023-06-24 Thread Michael Catanzaro




On Sat, Jun 24 2023 at 10:24:58 AM -0500, Chris Adams 
 wrote:

Is there any chance of having a CentOS Stream repo along the lines of
Fedora's updates-testing, so that CVEs at least would have some type 
of
available update in a timely manner?  With 7 there's the fasttrack 
repo,
but it doesn't actually seem to be used currently (and IIRC wasn't 
ever

a "testing" type channel).


A new -testing repo might make sense indeed. I believe currently 
updates are held until after Red Hat QA has tested them, which 
introduces significant delay (although not any delay relative to RHEL 
updates). I don't know what the chances of this happening are, though. 
It works really well for Fedora though, where community members 
regularly catch bugs that would otherwise have reached stable users, so 
it's certainly something to consider.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

2023-06-24 Thread Michael Catanzaro

On Sat, Jun 24 2023 at 03:26:46 PM +, Gary Buhrmaster 
 wrote:

If one does find a security update that did not get
streamed, is there a way for a non-customer[0] to
open an appropriate ticket both now, and in the
future when RH moves their internal bug tracker
to jira[1]?


Yes, you do not have to be a customer to use Bugzilla/Jira to report 
bugs.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

2023-06-24 Thread Michael Catanzaro



On Sat, Jun 24 2023 at 08:53:32 AM -0500, Chris Adams 
 wrote:
Is it?  At one point, there were considerable gaps in security 
updates;

RHEL 9.x would get an update while CentOS Stream 9 (as the target for
RHEL 9.[x+1]) didn't get a corresponding update for quite a while.  If
Stream doesn't get security updates in a timely fashion, it is not at
all suitable for production use.


So here is the reality with security updates. The vast majority of 
security updates are shipped in RHEL 3-9 months after we fix them, 
because minimizing the quantity of updates is an important goal in RHEL 
to reduce update churn for customers, so we only want to release quick 
fixes for issues that pose serious risk. (Most security issues are just 
not very urgent.) This means you get most security fixes drastically 
sooner in CentOS Stream than you would in RHEL. However, 
higher-severity security updates do get fixed in RHEL first. Developers 
are not permitted to fix higher-severity security issues in CentOS 
Stream until after the fix is shipped in at least one RHEL update. 
We're encouraged to do so immediately after the fix ships in RHEL, so 
there *should* only be a minor delay of, say, one or two business days 
for the developer to notice the update has shipped. So in general, 
CentOS Stream *should* generally be ahead of RHEL and ideally only 
slightly behind for the more serious CVEs.


But in practice, we actually currently have a lot of desynced packages 
where RHEL is ahead of CentOS Stream for various reasons. I believe 
most such cases are mistakes that need to be corrected, not intentional 
delays. E.g. if a particular developer just forgets to fix the CVE in 
CentOS Stream, currently nobody is checking to catch that and complain 
and get things fixed. Red Hat needs to catch and fix these issues 
proactively, but is not currently doing so. Since only Red Hat is able 
to commit to CentOS Stream, the community is limited to tracking 
desyncs and complaining when it happens. (That would be really valuable 
to do IMO.)


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What is Fedora?

2023-06-23 Thread Michael Catanzaro

On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer 
 wrote:

Which means equivalent fixes are in CentOS Stream and anyone wanting
to recreate exactly what is in RHEL is welcome to backport that code
from CentOS Stream or upstream.


Yes, but that's going to be pretty hard to do if you cannot see what 
needs to be backported because you don't have a Customer Portal 
subscription. :)


In this particular case, there are two CVEs fixed somewhere in the 
middle of maybe 100 other upstream changes, and the correspondence 
between CVE vs. upstream commit is intentionally not public to 
discourage distros from backporting individual security fixes. (It's 
not a smart idea. Only 5% of WebKit security bugs get CVEs. I sometimes 
do security backports for RHEL anyway for regulatory rather than 
security reasons.) Anyway, to figure out what to backport in order to 
match what's in RHEL, you'd have to either somehow get access to the 
RHEL SRPM, or else email me and ask what to do.


I don't really have any strong opinion about this change. Just pointing 
out that it's going to be effectively impossible to reverse-engineer 
RHEL from CentOS Stream. Let's not pretend that's realistic. Rebuilders 
are going to need to get copies of the RHEL SRPMs somehow if they want 
to match RHEL, and they do.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What is Fedora?

2023-06-23 Thread Michael Catanzaro

On Fri, Jun 23 2023 at 06:16:52 PM +0200, Vít Ondruch 
 wrote:

Ah, there is actually webkit2gtk3-2.38.5-1.el9_2.2 not
webkit2gtk3-2.38.5-1.el9.2. I got it now.


Oh sorry, I mentally expanded the dist tag incorrectly. My bad.

Anyway, in this example, CentOS Stream is on 2.40 while RHEL 9.2 is on 
2.38. The RHEL security update is never visible in CentOS Stream 
because it's not needed there.


Hopefully 2.40 is better overall than 2.38 (and certainly much more 
secure), but certainly there are always plenty of new regressions and 
bugs that were not there before. No way to pretend you're 
bug-compatible with RHEL if you're pulling sources from CentOS Stream.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What is Fedora?

2023-06-23 Thread Michael Catanzaro

On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch 
 wrote:

Please understand that (speaking of the user space packages, I cannot
speak for kernel) there are no other sources then the sources in 
GitLab,

which is publicly accessible (AFAIK).


The sources that are actually used for RHEL releases are certainly not 
available on GitLab. E.g. the latest released version of webkit2gtk3 is 
currently 2.38.5-1.el9.2. You can try finding the source for that on 
GitLab, but it's not there because we don't have stable branches on 
GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

2023-06-07 Thread Michael Catanzaro



Ideally all bundled dependencies should be hooked up to some sort of 
automation that notices when there are upstream updates available, 
comparable to upstream release monitoring. On Flathub this is done by 
flathub-external-data-checker [1], but using it is optional and it's 
not useful if it's not used. For Fedora Flatpaks, I don't think any 
comparable mechanism exists, but it should be as simple as "update 
whenever any component RPM is updated."


[1] https://github.com/flathub/flatpak-external-data-checker

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

On Mon, Jun 5 2023 at 04:46:42 PM -0400, Demi Marie Obenour 
 wrote:

Fedora could, of course ship its own SELinux policy for Flatpak (and I
recommend this), but Flatpak will not (and cannot reasonably be 
expected

to) integrate with SELinux natively.


Well it would have to be a very permissive policy, because it would 
need to allow everything that any Flatpak app might ever want to do. 
Doesn't selinux work best when you have a good understanding of the 
software that you are trying to confine?


Could Flatpak be changed to use e.g. KVM + crosvm for isolation?  
Flatpak
does (via seccomp) prevent applications from creating _new_ user 
namespaces.


Maybe in theory, but in practice that won't work because (a) it would 
be a major breaking change, and (b) flatpaks are integrated with the 
host system via D-Bus APIs, and throwing a VM boundary into the middle 
would make D-Bus rather difficult to do.


For example, when you want to open a file, the application does not 
have any access to the host filesystem, so if it attempts to display 
its own file chooser, you'll see only a sad empty home directory. 
Instead, an application designed for Flatpak will use the 
org.freedesktop.portal.FileChooser D-Bus API to ask the portal running 
on the host system to show a file chooser instead. (The application's 
UI toolkit, e.g. GTK or Qt, will usually handle this.) Then the user 
interacts with the host file chooser, and the host mounts the selected 
file in the sandbox so that the application can only see the file that 
the user selected. That would need to somehow work across the VM 
boundary. No doubt it's possible somehow, but using a VM would 
certainly make that a lot more complicated.


Now that's just one of dozens of portal APIs that allow sandboxed apps 
to interact with the host system. Another example: 
org.freedesktop.portal.FileTransfer, which allows drag-and-drop to and 
from the sandboxed application. All the portals would need to be 
reimplemented to ensure they still work with virtual machines instead 
of containerized applications. I don't want to say "no don't ever 
attempt this" but it sounds like a huge undertaking. We have to balance 
isolation vs. functionality; adding so much isolation such that 
applications no longer function as expected is too much. (We also have 
to satisfy users who expect flatpak to add no overheard relative to 
host system applications, which isn't possible but would be especially 
not possible if using VMs.)


So I don't expect upstream to be interested in this.

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

On Mon, Jun 5 2023 at 04:49:07 PM -0400, Demi Marie Obenour 
 wrote:
“several hundred megabits a second on tap at all times” is 
completely
out of the question for the majority of the world’s population.  
I’m not
sure what the median bandwidth in the developing world is, but it is 
far

FAR less than that, not to mention often being metered.


My standard response to concerns about image size is to point to:

https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

Endless OS is designed for developing world users with metered 
connections or nonexistent connections, where updates have to be 
manually copied from a device that does have an internet connection to 
other devices via a USB stick. All the apps are Flatpaks.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages




On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb 
 wrote:

Yes. And how does it's security model work?


The security model is that the application is assumed to be compromised 
by malicious input and is trying to do evil things to the host system, 
like read your home directory and send copies of your files to a 
ransomware operator or nation state. Linux namespaces plus seccomp 
filters are used to confine applications to prevent them from messing 
with the host system, or reading your personal files, etc.


It's great in theory. Problem is, as a transition measure to encourage 
developers to adopt Flatpak, you can give your application extra 
permissions that totally break the security model, and this is 
extremely common in practice. You should only trust applications that 
don't do this, but most apps do. See [1] for a discussion of this.


[1] 
https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html


There are different degrees of badness. E.g. Epiphany, which I 
maintain, has a sandbox hole that allows it to read and write your 
Downloads directory, and another hole that allows it to talk to 
Geoclue. These are both unacceptable, but certainly not as bad as 
allowing read/write access to the user's home directory or root 
filesystem, which many apps actually do.


Flatpak could be pretty darn secure, but only if we stop allowing this, 
and I fear that would likely result in applications abandoning the 
platform. This is a major threat IMO. I'd love to see more effort 
towards improving our portals so that applications don't need to use 
static permissions anymore. We need to really clamp down on this so 
that users can trust the Flatpak ecosystem.



What is the root of trust?


I think there is no root. A GPG key is provided when installing a 
runtime or application.



Are they signed by a Fedora key that I already
have?


Nope (except presumably for Fedora Flatpaks).


How can we verify it's integrity?


I think the GPG keys are trust-on-first-use.


Once installed, how do I verify it's
integrity? How do I check if anything has been modified?


I don't know. Non-Fedora Flatpaks are stored using ostree, so people 
familiar with ostree would be able to answer this question. Fedora 
Flatpaks are OCI containers, so people familiar with OCI containers 
would know about that.


ostree is a "git for binaries" and you can detect normal non-malicious 
modification by looking at the history, e.g. `flatpak remote-info --log 
flathub org.gnome.Platform//44`; however, this only tells you when 
something changed, not what actually changed.



Does it integrate
well with SE Linux,


No. selinux is entirely outside the Flatpak security model because 
Flatpak is a cross-distro tool and selinux is not used outside Fedora 
and Red Hat distros.



IMA, fapolicyd, or openscap?


I'm not familiar with these technologies, but I think the answer is: no.


On a locked down system, are
there sysctls  that I have undo such as user namespaces?


Technically, Flatpak can work without user namespaces, but this is a 
legacy configuration and it only works if bubblewrap (/usr/bin/bwrap) 
is built to use suid root instead of user namespaces, which is not 
recommend and which we do not do in Fedora. (I think Debian maybe still 
does this?) So it will surely break if you disable user namespaces, but 
you might be able to make it work by rebuilding your own bubblewrap 
instead of using Fedora's.


The Flatpak sandbox does not attempt to guard against kernel bugs -- it 
can't, because it has to allow access to all syscalls that applications 
might reasonably want to use -- so if you don't trust the kernel to be 
secure (including user namespaces), Flatpak is not the tool for you.



If an app coredumps,
does a problem report get generated? Who gets it?


Nope, there's nothing. You have to manually create a backtrace using 
flatpak-coredumpctl and then create a bug report yourself. This is 
really bad. We need ABRT to handle this so we can generate crash 
reports like we do for Fedora's packaged software.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages




On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen 
 wrote:


1. What is a flatpak and what does it mean to have an application in 
it? Is it everything bundled in it or does it use layers?


Two layers:

* Runtime (base platform, responsibility of runtime maintainers)
* Application (including bundled dependencies not present in the 
runtime)


It's a compromise between traditional distribution-style dynamic 
linking for the most common dependencies (the runtime), plus bundling 
for the less-common dependencies the application needs that are not 
present in the runtime.


2. So there are these 'SDKs' that people mention? What is in them? 
How are they built? How are they updated? Who maintains them and how 
can we 'verify' in the 'trust and verify' method (aka source code, 
build flags, build system).


Confusingly, SDK has two meanings.

First, the SDK is an alternate version of the runtime intended for 
developers. The runtime normally used by users is the "platform" 
runtime and the runtime for developers is the SDK. The SDK adds 
developer tools like gdb, valgrind, etc. For example, GNOME 
applications usually run against the org.gnome.Platform runtimes, but 
you might need to tell them to use org.gnome.Sdk instead if you need to 
debug something.


Second, there is freedesktop-sdk, which is the name of the project that 
produces the base runtime that is the de facto default runtime that 
most Flatpak applications use. Both the GNOME and KDE runtimes are 
based on freedesktop-sdk. (The Fedora runtime is a notable exception in 
that it is mostly independent of freedesktop-sdk, with everything built 
from Fedora RPMs instead.)


The runtimes are maintained in places like [1] and [2] and [3] and [4] 
by friendly neighborhood open source people, so it's easy to check what 
they contain. They are built in different ways. [1] and [2] are built 
using Buildstream. [3] is built using flatpak-builder. [4] is built 
using modulemd (but that will have to change due to failure of Fedora 
modularity). So these are three quite different ways of building 
runtimes.


I'm familiar with the Buildstream runtimes. For source code, there are 
references to tarballs or git repos in each Buildstream element. For 
build flags, the freedesktop and GNOME runtimes use build flags based 
on Fedora's build flags [5] with some adjustments (there are no GCC 
specs, GCC is configured a bit differently than ours). As far as 
verification, I guess you want to look at build logs? Unfortunately I'm 
not smart enough to do this reliably anymore, as Buildstream likes to 
reuse cached builds and I don't know how to see logs for these builds. 
:( It's a problem. But for at least freedesktop-sdk and GNOME, you can 
see *some* build logs by looking at the CI artifacts.


[1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk
[2] https://gitlab.gnome.org/GNOME/gnome-build-meta
[3] https://invent.kde.org/packaging/flatpak-kde-runtime
[4] https://src.fedoraproject.org/flatpaks/flatpak-runtime/
[5] 
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/include/flags.yml


I think a FAQ around these and others would probably cut down a lot 
of the uncertainty and doubt people feel.


Probably, but I'm not going to volunteer to help with that. :) There is 
[6], but it's pretty basic and doesn't answer your questions.


[6] https://flatpak.org/faq/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages




On Mon, Jun 5 2023 at 01:05:25 PM -0500, Chris Adams 
 wrote:

It's layered, but from what I understand, an upper layer depends on a
specific build of a lower layer.  So using the up-thread example, if
there's a security update to zlib, the lower layer can rebuild to pick
it up, but until the upper layer (like say LO) also rebuilds on top of
the new lower layer, they'll be running on the old version.


Well, *generally* that is entirely untrue. But sometimes it really is 
true.


That's the simple answer. Apologies for turning this into an essay, but 
there's no simple way to explain this. There are two different 
considerations here.


Point 1:

TL;DR what Adam Williamson already said is correct.

Flatpak itself only knows about two layers: the runtime and the 
application. You do have to rebuild the application to use a new 
*major* version of the runtime (comparable to new major versions of 
Fedora), but not for normal updates of that runtime. Let's 
hypothetically say that your app is using the GNOME 44 runtime and 
there is a bug in the zlib provided by the runtime. You do not need to 
rebuild your app for users to get the new zlib. However, let's say your 
application is instead using the GNOME 42 runtime, which is end of life 
and won't receive any further updates. To get the updated zlib, the 
application has to update to the newer GNOME 44 or 43 runtime, and 
users will suffer from the zlib bug until it does so.


You can think of different versions of the runtimes as entirely 
different runtimes: org.gnome.Platform/x86_64/42, 
org.gnome.Platform/x86_64/43, org.gnome.Platform/x86_64/44. Each 
runtime receives regular updates independently from your application, 
but you have to update your application to switch between major 
versions. It's a compromise between updating too much and breaking your 
app, vs. updating too little and leaving users to suffer from bugs and 
security issues.


(Compromise is a theme of Flatpak: the split between runtime vs. 
application is also a compromise between which dependencies are updated 
by the runtime maintainers, comparable to traditional distribution 
maintenance, vs. which dependencies are bundled and have to be updated 
by application maintainers, at the mercy of the app developers' 
attentiveness.)


Point 2:

But now, to make things more complicated, sometimes runtimes and 
applications are *themselves* built from different layers. Flatpak 
itself doesn't know about these layers, and most Flatpak users don't 
know about it either, and I wouldn't have even mentioned it here except 
for your comment, but when you build things this way, you really do 
have to rebuild the upper layer to update the lower layer. This is why 
I couldn't say your comment was entirely incorrect.


Let's start with runtimes. For example, the GNOME runtimes 
org.gnome.Platform are based on the freedesktop-sdk runtimes 
org.freedesktop.Platform. zlib is actually maintained as part of the 
freedesktop-sdk, so we do not have our own GNOME packaging for zlib: 
it's all inherited from freedesktop-sdk. We do have to manually update 
the GNOME runtime to use a newer version of freedesktop-sdk. That is, 
when we update the zlib element in freedesktop-sdk, users do not 
actually receive the newer zlib until we update the freedesktop-sdk 
element in the GNOME runtime. That happens regularly, but it does 
introduce delay. The GNOME and KDE runtimes are both based on 
freedesktop-sdk, so these are layered runtimes. The freedesktop-sdk 
runtime is not based on anything else. Then the Fedora runtimes are the 
only runtimes I'm aware of that are not based on freedesktop-sdk. So 
some runtimes are layered, and some are not.


Now, most applications are just a single layer, but some include a 
"base app" which is basically a way for multiple applications to share 
the same set of bundled dependencies between themselves. Most 
applications do not use base apps, but if you do, then you do need to 
rebuild the application in order to update the dependencies from the 
base app. I think Flathub *could* theoretically do that for you 
automatically, but I've asked and I'm told it doesn't. What do base 
apps look like? I searched Flathub for "base" [1] and it looks like 
base apps are mostly used for web engines. For example, there is an 
io.qt.qtwebengine.BaseApp and that seems to be how Flathub applications 
are expected to use QtWebEngine. This means that apps using QtWebEngine 
need to be careful to monitor for updates and rebuild as required, or 
else users will wind up using old versions. This is not great, but at 
least it's somewhat better than manually bundling your own QtWebEngine. 
(In contrast, WebKitGTK is part of the GNOME runtime, so applications 
don't have to worry about updating it and can trust that the runtime 
maintainers will handle that.)


Conclusion:

* Runtime maintainers are responsible for updating dependencies that 
are components of the runtime (including freedesktop-sdk)
*

Re: LibreOffice packages