Re: Intention to unretire and rename pyftpdlib
Sandro wrote:
> I was probably overthinking this. In practice it will turn out to be a
> new package submission indeed. Moreover, the last remaining active
> branch of the retired package (F38) is now EOL.
>
> I've submitted the review [1] without any Obsoletes.
Since we support upgrades from Fedora n to n+2, there SHOULD be Obsoletes in
place until at least the F40 EOL. I would recommend just keeping the
Obsoletes forever.
Kevin Kofler
--
___
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: Changing desktop file name in a stable release
Julian Sikorski wrote:
> are there guidelines advising how to handle upstream desktop filename
> change in a stable fedora release? For gnumeric I just followed upstream
> [1], which led to a bug report [2]. Now I am facing similar situation
> with pavucontrol [3]. Should I rename the desktop file to what it used
> to be, or just forgo the updates altogether? Thanks in advance.
The gnumeric bug report was about the icon .png getting renamed, not the
.desktop file.
I think it is OK if the .desktop file gets renamed during a release, but
some people are probably going to complain there too. I guess that is what
we have CLOSED NOTABUG for.
Kevin Kofler
--
___
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: Debugging fun (wrt C modernization change)
Michael J Gruber wrote:
>> %patchlist and %auto* should just go away, or at least banned from Fedora
>> by a git hook rejecting such specfiles.
>
> We also have unnumbered patch source definition lines, don't we?
IIRC, unnumbered Source: or Patch: just defaults to Source0: resp. Patch0:.
But it should not be used. Use Source0/Patch0 instead.
Kevin Kofler
--
___
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: New Fedora Planet
Pedro Moura wrote:
> To add blog posts in Fedora Planet you basically need to update RSS URL
> field at https://accounts.fedoraproject.org/
Which means that basically all blogs are going to vanish from Fedora Planet
unless people re-add them manually.
There are 809 blogs on the old Planet Fedora, the new one currently has 30
(should be at least 31 soon when it picks up my RSS URL that I have just
added to accounts.fedoraproject.org). That is less than 4%. More than 96% of
the blogs will be gone.
This is not helpful.
Kevin Kofler
--
___
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: rich deps result in packages being uninstalled from buildroot
Neal Gompa wrote: > I have the question of why is dnf5 running as if "--allow-erasing" is > always passed to it? Older versions of DNF explicitly didn't do that > because we get weird behaviors like this. Without --allow-erasing (which was actually passed explicitly, as Petr Pisar pointed out), the intended resolution: > a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and > remove add-determinism-nopython could also not possibly work because: > remove add-determinism-nopython Kevin Kofler -- ___ 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: Debugging fun (wrt C modernization change)
Panu Matilainen wrote: > Patch and source numbers start from zero, that goes for automatically > numbered patches too. So there's an off by one in the application, and > the latter %autopatch which is supposed to apply patches >= 2 simply has > nothing to do, and falls through silently. That's a bug of course in > itself, filed now: > https://github.com/rpm-software-management/rpm/issues/3093 And then they say the automagic is a good idea because it prevents people from accidentally forgetting to apply a patch, LOL. %patchlist and %auto* should just go away, or at least banned from Fedora by a git hook rejecting such specfiles. Kevin Kofler -- ___ 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Adam Williamson wrote:
> The shortest syntax is just to use Patch: foo.patch , and %autosetup .
That is not a syntax to apply a patch, it is an automagic that blindly
applies all patches in numeric order. Cannot reorder patches, cannot apply
them conditionally (e.g., based on the 0%{?fedora} version), cannot specify
a -b backup file extension for each patch. So it is not a fair comparison.
Kevin Kofler
--
___
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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Florian Festi wrote: > We have an even easier solution for you: You can just run the script at > [3] with -n on your own spec files to get them changed to the %patch N > variant. If you do that right now they will not break nor will they be > touched during the mass change. > > As I said the %patch -PN syntax is the one with the best compatibility - > reaching back into the dark ages. I am not advocating for people to use > it. Anyone is free and encouraged to move to something more modern - > before or after the change. We are using this variant so spec files > continue to work on older distributions and the chance of breakage is > minimized. This way packagers that don't care don't have to. What I do not understand is why RPM is discontinuing the most commonly used syntax and breaking hundreds of specfiles. This also leaves us with only the choice between a backwards-incompatible syntax (added only in RPM 4.18) and an ugly and redundantly verbose syntax (the -P syntax). And even the modern syntax is 1 character (space) longer for every patch. The shortest syntax was the one being dropped. Kevin Kofler -- ___ 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Neal Gompa wrote: > On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel > wrote: >> >> Am 06.05.24 um 13:56 schrieb Florian Festi: >> > Hi everyone, >> > >> > RPM has deprecated the %patchN syntax in favor of %patch -PN where N is >> > the patch number for a year now. See the RPM documentation for more >> > information [1]. In current RPM versions, this syntax only emits a >> > deprecation warning, but support for this syntax has been removed >> > completely in the upcoming RPM 4.20 release. As it will be added in >> > Fedora soon [2] it is time to switch over to the new syntax now. >> > >> > There are around 1800 packages that still use the old syntax. Later >> > this week/next week, we will run this script [3] over the affected >> > packages >> > [4][5] to update them to the modern patch syntax. For example, the >> > script will change: >> > >> > %patch0 -p1 → %patch -P0 -p1 >> > %patch0005 -p2 → %patch -P0005 -p2 >> > >> >> >> Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)? >> > > Yes. It's been supported for a very long time. %patch -P is already documented in the 1997 First Edition of Maximum RPM. Here is the link in the 2000 online edition: https://ftp.osuosl.org/pub/rpm/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-WHICH-PATCH-TAG Kevin Kofler -- ___ 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: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Carlos Rodriguez-Fernandez wrote: > How could that be expressed so that those are caught quickly at build > time? Someone wants to depend on a java lib that has been tested only in > JRE 8 to 11, but wants to build the package with JRE 17+, or vice-versa, > for example. Perhaps, the only feasible way to detect that case is with > CI. IMHO, the library should have a: Requires: (java-devel >= 1:8 with java-devel < 1:11) Sure, this will not per se prevent you from attempting to use the library with the Java 17 compiler, but if you do not have Java 8 or 11 installed, installing the library attempting to install it as a dependency should raise a red flag. As a quick check, you could write a specfile for your application with: BuildRequires: java-devel >= 1:17 BuildConflicts: java-devel < 1:17 and then run mock on that. The latter line should prevent the old version from being installed in parallel. One annoyance is that older OpenJDK packages currently drop that virtual Provides, presumably in an attempt to get all Java packages systematically built with a newer JDK. That is something that ought to get fixed. (If we switch to building with the oldest possible Java as I suggest, it will have to get fixed anyway.) As is, you may need to explicitly: BuildConflicts: java-1.8.0-devel BuildConflicts: java-11-devel Kevin Kofler -- ___ 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: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Christopher wrote: > So, I actually think that building with the *latest* JDK that we ship, > and using the `--release` flag during compilation is actually safer > than building against the lowest that we support, because it is most > likely to strictly enforce correct byte code generation for the target > JRE. The problem is, without ALSO installing the JDK for the targeted version AND explicitly pointing -bootclasspath to that JDK, this does NOT catch code trying to use class library features (as opposed to language or bytecode features) from the newer JDK, and worse, in rare occasions, even if the source code is in principle compatible with the targeted older Java, when compiled with a newer compiler and older target release, it will fail to actually run (!) with the latter (because the compiler picks up a subclass override of a method added in the newer Java instead of the baseclass method that was always available and, for performance reasons, tries calling the override explicitly rather than going through the virtual method lookup). One example of that latter issue is NetBeans, where versions 12.5 and 12.6 were supposed to be compatible with Java 8, but some upstream-published binaries of 12.5 and all of 12.6 do not actually work properly on it because they were built with Java 11 in "-release 8" mode: some editor features fail with runtime exceptions. See https://issues.apache.org/jira/browse/NETBEANS-6349 for details. (They "fixed" it by just requiring Java 11 in NetBeans 13 and newer. No fixed 12.x release was ever issued.) So I am AGAINST systematically using "-release" without "-bootclasspath", even though that works in most cases and is often successfully used in production (me and my employer use it, too, but on projects we control where we will fix the source code or add a workaround to it if any issues come up from that, not systematically on repackaging third-party projects). The compiler even warns about the missing "-bootclasspath". And the potential to cause subtle misbehavior that is a pain to debug is just too high, especially if we have the actual older JDK available and could just BuildRequire the correct version. Kevin Kofler -- ___ 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: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Carlos Rodriguez-Fernandez wrote: > Regarding the proposal as a whole, I think the proposal idea makes a lot > of sense, but for apps depending on system jar libraries, there should > be a way to specify that the app depends on a specific java bytecode > version range. System libraries packages could provide compatibility > packages, so couldn't those apps just depend on those compatibility > packages instead? That can become a maintenance burden for those libs, > though. The safest approach for library JARs would be to always build them against the lowest possible Java version (the oldest JDK branch that we still ship if the library supports that, otherwise the oldest the library supports). And IMHO, if the library is built against a higher version than the lowest we ship, it needs a versioned Requires on the JRE. Kevin Kofler -- ___ 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: pipenv removal in F40
Miro Hrončok wrote:
> If you wish to help, I guess you can send a pull request to the release
> notes...
Or Mattia could simply unretire and adopt the package.
Kevin Kofler
--
___
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 do minor bump using %autorelease?
Fabio Valentini wrote: > No, that's just wrong. > The "upgrade path" (wrt/ NVRs) is no longer enforced across release > boundaries. AFAIK, all supported release-upgrade methods now use > distro-sync or something equivalent, so NVR-based "upgrade path" is just > not important any more. That just does not make sense: We enforce upgrade paths from Rawhide to Rawhide (!) requiring lots of unnecessary Epoch bumps when things need to be reverted (which is normal for a development running release), but we happily allow the ones that actually matter to end users to break? All this just so that lazy packagers do not have to increment a number (in most cases a single-character change, in some cases (such as a minor bump or every 10 major bumps) a two-character change, rarely more) when doing a new build. Kevin Kofler -- ___ 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 do minor bump using %autorelease?
Michael J Gruber wrote:
> A minor bump (as in %{?dist}[.]) only comes into play
> if a "lower" branch needs to move forward without creating a version
> ahead of a "higher" branch. And (independent of autorelease) you cannot
> do that unless you use divergent git branches and cherry-picks in
> dist-git, in which case "version" makes sense per branch only anyways.
But Release MUST maintain the upgrade path from one release to the next.
Also, no, you do not necessarily need to allow the branches to diverge. If
you keep your branches fast-forwarded, you can just fast-forward the
"rebuild for libfoo in Fn" commit with the minor bump to all branches, but
build it only in the fn branch where it is relevant. The minor bump ensures
that doing that maintains the correct upgrade path, so you do not have to
push unnecessary rebuilds to releases where it is not relevant.
> In a dist-git where you work with release branches "contained" in
> rawhide - and use macros extensively - you automatically have commits
> which you merge down but which don't affect all branches, e.g. rebuild
> commits for dependencies or mass rebuilds. I'm not saying this is the best
> way of doing things (we should do it differently), but it's a common
> pattern. So you can have the "f40 mass rebuild" commit in an f39 branch.
> And in a world where you have and accept that, you can also push a
> "rebuild for libfoo" to rawhide and merge down to f40 if that is what
> you need to have f40 versions <= rawhide versions.
Sure, but as I explained above, this only works properly if you do a minor
bump rather than a full bump to Release. Otherwise you have to rebuild
everywhere or you break the upgrade path.
> But as others have pointed out, in the light of distrosync and
> macro-determined differences etc. we may just as well give up the
> illusion that "-5" means the same in different branches, and
> consequently lift the sorting policy between different branches.
But that breaks the upgrade path, so it is a no go.
Kevin Kofler
--
___
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 do minor bump using %autorelease?
Julian Sikorski wrote:
> I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> mame-0.265-1.fc41 is already built against it so I only need to build
> mame-0.265-1.fc40.1. Can it be done using %autorelease?
No, which is why you should not be using %autorelease.
I would just replace %autorelease with a correctly manually bumped Release
in the specfile as part of doing the rebuild.
Just letting %autorelease do its thing and ending up with a full bump would
be incorrect, so it should not even be considered as an option.
Kevin Kofler
--
___
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: systemd 256~rc1 in rawhide
Adam Williamson wrote:
> Well, it really wants to write to /lib , not to /usr. But of course, on
> Fedora, /lib is /usr/lib .
Sigh… Time for a UsrUnmerge? :-)
Kevin Kofler
--
___
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: Is there a policy for branches being merged or not
Julian Sikorski wrote:
> In this case defaulting to cherry-picking would be a safer bet. Branches
> unintentionally separated can be merged, but branches unintentionally
> merged cannot be unmerged.
This is only true if you are talking about merge-commit merges. Not if we
are keeping the branches fast-forwarded (and using %{?fedora} conditionals
in the rare event something really needs to differ between the releases). A
linear history cannot be remade truly linear once it was diverged by a
cherry-pick (or simply a separate bump from running rpmdev-bumpspec
separately on each branch, as scripted rebuilds often do). The best we can
do to restore fast-forwardability is to merge one way and then "merge back",
which will fast-forward the other branch to the same merge commit. This
still leaves an ugly knot in the history, but at least the branches can then
be fast-forwarded again. But a clean linear history is no longer possible
after someone did an unwanted cherry pick instead of a fast-forward merge.
Kevin Kofler
--
___
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 RISC-V port needs to put shared objects into /usr/lib64/lp64d
David Abdurachmanov wrote:
> We currently use a symlink (as Richard) mentioned, but it's not ideal
> and causes problems (e.g. meson generates wrong paths breaking some
> packages [one example: libplacebo]).
Which I would say is a bug in Meson and should be fixed there.
I do not think having /usr/lib64/lp64d be a symlink to /usr/lib64 is in
violation of any standard.
Kevin Kofler
--
___
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: F41 Change Proposal: Replace Redis with Valkey (system-wide)
Nathan Scott wrote:
> - it could be advantageous if the new compat sub-package contained
> the redis binary symlinks & not the primary valkey package (this could
> allow valkey and redict packages to coexist, for example). Long-term
> we may want to drop those entirely (along with the compat package, to
> complete the transition away from Redis).
I do not see why we need a separate compat subpackage at all. Valkey should
just Obsolete/Provide redis and include all the compat symlinks in the main
package.
Kevin Kofler
--
___
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
Kilian Hanich via devel wrote:
> The fact that you can share the keys is actually part of the design and
> wanted. Apple for exmaple has (or wants to) implement easy sharing of
> passkeys via AirDrop.
So the Apple Cloud can see your private key, but you cannot? Sounds like
GREAT "security", LOL…
Kevin Kofler
--
___
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
Gary Buhrmaster wrote: > [2] As I understand it, the issue is the > lack of the required trusted environment > in generic Linux. There are software > implementations that do not have the > hardware enclave protections, And to be honest, I do not see the problem there. I will use whatever will let me pass the Fedora security theater checks without investing in extra hardware. (This also means that if I am offered the choice, I will pick TOTP over FIDO2 any day, because TOTP does not require me to emulate a fake hardware crypto device like FIDO2 does.) And in my view, the fact that, in those implementations, there is no Treacherous Computing hardware preventing me from doing what I want with my own private key (e.g., just copying the same key to all my devices, as I can also do with TOTP) is actually a feature, even if it goes against the "security" model. Kevin Kofler -- ___ 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: F41 Change Proposal - Python Built with gcc -03 (self-contained)
Richard W.M. Jones wrote:
> As gcc -Os was mentioned too, that is -O2 with the following
> optimizations disabled:
>
> -falign-functions -falign-jumps
> -falign-labels -falign-loops
> -fprefetch-loop-arrays -freorder-blocks-algorithm=stc
Last I checked, there were also some hardcoded if (optimize_size) peppered
throughout various GCC optimizations and even target files (to choose
between faster or smaller instructions).
Kevin Kofler
--
___
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: F41 Change Proposal - Python Built with gcc -03 (self-contained)
Neal Gompa wrote:
> I would like for us to consider evaluating a global change to -O3. I
> am not convinced that there's a good reason anymore to remain at -O2.
>
> If we get this kind of benefit from Python, I would be interested in
> seeing what we'd get elsewhere.
How much larger is Python at -O3 compared to -O2? And other packages?
I would like to see -Os as the default.
Kevin Kofler
--
___
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
Adam Williamson wrote:
> Also, these days, most authenticator apps support some kind of backup
> mechanism. FreeOTP lets you back up to a file (which you should, of
> course, keep somewhere safe and ideally encrypted). Google
> Authenticator can backup To The Cloud.
If you use Keysmith, you can just SFTP your
~/.config/org.kde.keysmith/Keysmith.conf from/to all your GNU/Linux
computers including the PinePhone or equivalent, and they will all be able
to generate the same TOTP keys with the same master key.
Kevin Kofler
--
___
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
Zbigniew Jędrzejewski-Szmek wrote:
> So… this is what I'm talking about: there is no obvious way to
> figure out what to set. Looking at the logs and trying to figure out
> some variables from that is not very attractive.
The comments at the top of the relevant Find*.cmake module are the best
source for which variables you are supposed to set directly.
But there is also cmake-gui that can show you all the available options in a
pretty Qt GUI.
> Nevertheless, for me, CMake and autotools are outdated technologies
> that shouldn't be used in new projects.
And for me, Meson is just a poor Not Invented Here imitation of CMake, with
fewer features and in a slower programming language. :-)
And the kind of automagic you complain about is something all 3 major build
systems do (and plenty of obscure ones, too). Maybe not for the specific
case of the Python executable, but there are plenty of other cases where
autotools and Meson also do automagic, which is why building outside of a
chroot is such a bad idea.
Kevin Kofler
--
___
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: convert everything to rpmautospec?
Zbigniew Jędrzejewski-Szmek wrote: > And sorry, but saying to "process pull requests quickly" is just naive. > Busy packages often have many different pull requests concurrently, and > some of them need discussion and fixes and work in other places before > they can be merged. Generally, there should be no room for discussion there. Either the pull request is good, then merge it immediately, or it is not, then reject it immediately. People who want to contribute to Fedora packaging ought to know what they are doing, if not, just reject and let them submit a new pull request when they have done their homework. > I guess we'll just have to agree to disagree. In the other part of the > thread, a proposal that was floated to allow opt-out. I hope that's > acceptable. You have received a lot of all-negative feedback and one single message of support. So for me there is a clear consensus to NOT implement your proposal at all, not even with an opt-out option. Kevin Kofler -- ___ 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: convert everything to rpmautospec?
Zbigniew Jędrzejewski-Szmek wrote: > I'm revisting the topic of rpmautospec because I was doing some work > on various packages, and it's annoying that some packages are using > rpmautospec and others are not. The fix for that inconsistency would be to ban rpmautospec. It just makes everything more complicated. > All my packages have been converted, so in day-to-day work, I don't > even think about %changelog. When working with other packages, I'll > forget to update the Relase and/or %changelog. Today I was rebasing > some pull requests in pagure, and the _only_ conflicts that I had were > about Release and %changelog. Generally, it helps to keep all your branches in sync (and with that, I mean, fast-forwarded to the exact same commit hash – no, it is not a problem if the changelog for a Fedora release includes an entry for a Rawhide mass rebuild made after that Fedora release branched, it explains why the Release number has increased and is otherwise harmless) if you are building the same versions for all releases (which is typically the one case where you bother backporting specfile updates across releases at all), and to process pull requests quickly, before you or rel-eng or another pull request bump the specfile in Rawhide. Then you rarely have conflicts in %changelog to begin with. > I think it's time to switch to rpmautospec completely. > Thus, the proposal: > - new packages MUST use rpmautospec > - packagers SHOULD convert their packages > - provenpackagers MAY convert existing packages > (e.g. when they want to push some fix or separately from other >work) > - people submitting pull requests against src.fp.o MAY also > include a conversion in the pull request and packagers SHOULD > merge it. I am opposed to every part of this proposal. Allowing provenpackagers to convert existing packages (that they do not explicitly comaintain) would be particularly rude. I do NOT want any of this automagic (also the various %auto* macros such as %autosetup) in my specfiles, it just makes my life harder for no benefit whatsoever. Kevin Kofler -- ___ 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: convert everything to rpmautospec?
Emmanuel Seyman wrote: > I've noticed a trend in proposed changes in the way Fedora works. I am fed up of this salami tactic as well. When we complain about the new stuff, we invariably get told "don't worry, you don't have to use it, it's all optional", but the plan is always to make it mandatory later. See also 2FA that they are now trying to force on us, taking as an excuse an incident that was demonstrably NOT stopped by 2FA. > They start off as as things packagers will not have to use if they do > not want to and, over time, become default/forced (Matrix vs IRC, To be fair, part of the blame there is to be put on Libera.Chat that unilaterally turned off their Matrix bridge. (Yes, they did give Matrix some time to address the demands they had, but when Matrix told them it was not feasible in such a short time frame, they just first suspended, then permanently blocked the Matrix bridge.) But, and here is where I blame Fedora, instead of just letting the chans on Libera.Chat die and moving everything to Matrix, they should have moved the IRC chans to a network with a working Matrix bridge, such as OFTC (or pretty much anything other than Libera.Chat – I guess even Freenode under its new owners might be an option), then we could still be happily using both technologies interoperably. Instead, we get told to just use Matrix and shut up, which I do not consider acceptable. > Discourse, ...). There too, I do not see why some discussions are now being directed to Discourse instead of the mailing list. And it is not even working. Most of the pertinent feedback for new Changes still comes on this list, not on Discourse. The developers use this list, Discourse is only for users who do not know how to use a mailing list. > Perhaps it's time to discuss imposing financial and/or legal penalties > when the opt-in nature of the change goes away. Who would impose those? And from whom to whom would the money flow? I do not think this can work. Kevin Kofler -- ___ 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
I wrote:
> On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> wrote:
>> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
>> detection of python, and it found /usr/bin/python3.13t that I have
>> installed, and subsequently it got all the paths wrong.
>
> That's why you should never build packages outside of mock.
PS: Autotools also loves to autodetect random libraries that happen to be
installed on the system. It is in no way specific to CMake.
>> How do I override this?
>> ('cmake -LAH' doesn't yield anything useful.)
Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake for
the variables it uses. (First, try to figure out whether RPM is using a
system-installed FindPython or its own custom version, so you look at the
correct version.) But the safest (for all build systems) is to always build
in a mock chroot with only the expected BuildRequires installed, as I have
written.
Kevin Kofler
--
___
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
That's why you should never build packages outside of mock.
Kevin Kofler
On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
wrote:
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew
Jędrzejewski-Szmek wrote:
One particular issue I have with CMake as a downstream maintainer is
it's often very hard to override linking or compilation options
or when the project is using one of the cmake find scripts that gets
something wrong… It's possible that those projects are "doing
cmake wrong",
but it seems that CMake makes it easy to do things wrong.
I just had to interact with CMake, so let's use that as example:
I'm rebuilding rpm.rpm with some local patches using 'fedpkg local'
in F40.
The build fails with:
Directory not found:
/home/zbyszek/rpmbuild/BUILDROOT/rpm-4.19.1.1-2.fc41.x86_64/usr/lib64/python3.12/site-packages/rpm
Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
detection of
python, and it found /usr/bin/python3.13t that I have installed, and
subsequently
it got all the paths wrong. How do I override this?
('cmake -LAH' doesn't yield anything useful.)
(When compiling a python module, any other alternative would be
better.
The build uses %python3, i.e. /usr/bin/python3.12, so there's no need
to detect anything, the location of python is known and all this
binary
can be called to print all paths. Otherwise, either call
'python3-config' or 'pkgconf python', don't do you own
reimplementation.)
Zbyszek
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Peter Boy wrote: > Well, a switch from Gnome to KDE would require a lot of changes in > everyday applications, e.g. Mail. That is not required when you update > from Gnome 2 to Gnome 3. Well, in principle, GNOME applications will usually work under Plasma and the other way round. But in practice of course most default applications on the Edition would change along with the desktop environment. So if you are one of those users who never upgrades, but always reinstalls from scratch, or at least installs everything in the Edition's group on upgrades, you will be in for a few surprises indeed. > Provide a reliable solution which includes a non breaking evolvement of > the Edition. I would argue that people upgrading to a newer Fedora should just upgrade in place with the packages they have installed, ignoring the new defaults of the Edition, so they would remain on GNOME and GNOME applications if that is what the release they had initially installed was shipping. Though of course then there will be some people complaining that an upgraded Workstation is completely different from a freshly installed Workstation. But IMHO, that would be a feature, not a bug. > Too bad, an explicit scientific desktop edition might have helped me > propagate a Linux desktop in our University research cluster of excellence > a good decade ago. Scientific Linux for Servers was a great success. We tried, but it was deemed not distinctive enough to warrant an Edition, our application was rejected on those grounds. After all, it was still a desktop spin, just with some scientific applications preinstalled on top of it. So it was accepted just as yet another Spin (next to the regular KDE Spin), and eventually the Labs category was created for this and other use- case-specific (former) Spins. So a Scientific Spin (now Scientific Lab) did in fact exist around a decade ago, but maybe "a good decade ago" was slightly too early, just before it was created. In addition, there was also pushback against this suggested compromise (having the Plasma Edition be a Scientific Edition) from non-scientific KDE users who understandably did not want to have to install a Scientific Edition and then uninstall lots of niche apps they will never use from it. But that discussion became moot because the Edition application was rejected anyway. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leslie Satenstein via devel wrote: > The Cellphone user is very comfortable with Gnome. So much so, that I > believe that if he was given KDE as the interface, two things would > happen. a) The user will switch to Gnome, or b) The user will find a way > to add his favourite applications to the desktop. b) is actually very easy on modern Plasma (I tried it on Plasma 5), just right-click on the application in the menu and click "Add to desktop" in the context menu. KDE upstream has long given up trying to deprecate desktop icons (as they tried to do in early Plasma 4 releases, though even those allowed you to put a folder view widget displaying the Desktop folder (and hence, icons) on the desktop). In Plasma 6, the desktop is always a folder view. Or the user can just switch the menu type to something icon-based and very similar to the menu in GNOME Shell with right-click on the menu button, "Show Alternatives…" and "Application Dashboard". And if the user really wants a smartphone UI with a smartphone-style menu, always-maximized windows, etc., they should use Plasma Mobile, not Plasma Desktop. But a customized Plasma Desktop as described above is probably a better fit for traditional desktop/notebook computers. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Tomasz Torcz wrote:
> GNOME (Mutter) maximizes windows if they initially take 80% of more
> screen space.
And I believe that that, too, was a refinement added in later releases.
IIRC, GNOME 3.0 just maximized everything.
Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
ing is inherent to what atomic systems are and what the Everything ISO is, and should be obvious to anyone who actually understands what they want to install. > Basically, we have one domain *now*: fedoraproject.org But that domain has subdomains such as spins.fedoraproject.org, labs.fedoraproject.org, etc. distinct from the main fedoraproject.org domain (though technically the subdomains redirect to pages on the main domain these days). > If you have a look on the statistics Matthew reported on Flock last year, > you would know that the numbers for Workstation were declining, whereas > the numbers for Server raised steeply and for CoreOS and IoT steadily up. The numbers for Workstation might be declining because people are installing other desktop Spins, or a custom selection from Everything, instead. :-) None of those will have fedora-release-workstation installed. Kevin Kofler -- ___ 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
I wrote:
> That is exactly the problem with autotools code, almost nobody understands
> what the heck it does, almost everybody just copies and pastes somebody
> else's snippet hoping it does not do bad things. And gnulib is a
> particularly ugly piece of the puzzle.
PS: Here is a pretty good post summarizing the issues with autotools, both
generally and in the context of the xz vulnerability:
https://felipec.wordpress.com/2024/04/04/xz-backdoor-and-autotools-insanity/
Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Neal Gompa wrote: > By default, GNOME only presents the close window button. The other > buttons are missing, and there isn't really an intuitive way to > discover the other window management actions. In the version I tried, and judging from end user reports, for several years, it did not even present that, leading to fun issues such as some KDE dialogs that could not be closed at all (because they were missing a "Close" button and relying on the window decoration exclusively). >> "the shut down options in the mouse menu hidden behind a keyboard dead >> key, etc.)" this is also not the case for ages, or at least not in its >> completeness. > > Yes, this did change a few GNOME releases ago. Of course, having only tried GNOME 3 once, I could not know this. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leon Fauster via devel wrote: > 10 minutes is not enough to do a remodeling of the "familiar" > experience, so that you reaches the so called realm of intuition. > The latter is something that we learn over time and the desktop > environment does not offer this on its own. It provides only a > framework where this can happen. But that is exactly the issue with the GNOME design: It is really arrogant to expect me to unlearn decades of learned familiar experience and retrain to something completely different that in the end has at most minor advantages, it is not significantly better, just different. I want the software to ideally behave the way I am used to (i.e., the way Windows 95 worked, see below) out of the box, or if not, at least have an "old-school mode" toggle in the preferences that makes it work that way (and I will almost certainly use that toggle). > PS: Imagine the first CLI steps and the corresponding bad > experience, but we have not given up :-)! Oh, my first computer was actually an XT clone running IBM PC-DOS 3.3. So I actually started with a CLI. :-) Then Windows 95 on a Pentium 120 (MHz). And on that Pentium, I also got started with versions of Red Hat Linux of the time (not sure what the first one was), first from CD-ROMs bundled with computer magazines, then the downloadable FTP edition. And I also tried one magazine CD-ROM with an edition of Caldera "OpenLinux" (which was actually much less open than RHL, and Caldera eventually became the infamous SCO) with the at the time brand new KDE 1 (version 1.1.1). Having used DOS, the bash CLI was not that bad to work with, but the distros at the time already came with GUI environments (FVWM95, then came KDE 1 and GNOME 1). Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kilian Hanich via devel wrote:
> About the release cycle: After the initial release of Plasma 6 when dust
> has mostly settled down (approx. 2 point releases), they want to switch
> over to a release cycle which would align (which is likely also the
> reason why F42 was choosen in this proposal).
Interesting point. And there I thought it was only because the answer is
always 42. ;-)
Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Gordon Messmer wrote: > If RPM's ELF dependency generator were better, the importance of > stability would be debatable, but as it is, I really think Fedora should > be more stable than it is, especially for whatever it defines as "the > OS." Today, dnf/rpm will happily allow users to install an application > that will not run because that application actually depends on newer > versions of dependencies than are installed on the system. If a > significant portion of the standard desktop regularly rebased in the > middle of a release, I expect that would be a more common problem. Symbol versioning helps with this, because the ELF dependency generator extracts the symbol versions (though not the individual symbols, only the versions) that are required. And, e.g., Qt uses symbol versioning. The KDE packages also often have explicit versioned Requires on the dependencies where it matters. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Gordon Messmer wrote: > "When you are using the Linux mark pursuant to a sublicense, it should > never be used as a verb or noun. It should be used only as an adjective > followed by the generic name/noun. In other words, “Super Dooper Linux > OS” is okay, but “Super Dooper Linux” isn’t." > > https://www.linuxfoundation.org/legal/the-linux-mark Kinda the same recommendation that also applies to the Fedora trademark, by the way. But everyone only cares about their own trademark. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Aaron Rainbolt wrote: > Still, one could make some case for this. Plasma is, for one, obviously > going to be more familiar to newcomers to the Linux world simply by > virtue of the fact that the paradigms presented by its initial > configuration are more familiar to those coming from the Windows or > ChromeOS worlds, and (hopefully) those paradigms aren't sufficiently > different from MacOS to be too uncomfortable for a user coming from the > Apple world. You make a good point there. The thing is, GNOME tries really hard to design for new users, whom they define as a user who has never before used a computer. Such users are basically on the edge of extinction. A paradigm that works great for someone seeing a computer for the first time in their life does not necessarily work all that great for someone trained to use different paradigms used in the operating system(s) they have used for decades. As you point out, for users switching from a different operating system, which is a much more likely scenario, the GNOME Shell design is really confusing and disruptive, and GNOME's reluctance to make it easy to switch some things back (instead requiring you to install shell extensions for any such change) does not help. Even if the other operating systems' patterns happen to be counterintuitive if you have never seen them before, once trained to them, you will not only be able to work efficiently with them, but also be confused by GNOME's intuitive design that they carefully usability-tested on people with little to no computer experience. That leaves GNU/Linux power users who have used nothing but GNU/Linux for decades. I am in that category, like many regulars of this mailing list. (Well, I am particularly extreme in that even my smartphone runs GNU/Linux, but that is a different story.) And I would argue that GNOME is also a very bad default for users in that category because of its deliberate lack of configurability. Not to mention that the same (concept familiarity) concerns applying to people switching from other operating systems also apply to people switching from any other GNU/Linux desktop environment. Personally, when I tried GNOME 3 once, it took me less than 10 minutes to decide that this is just completely unusable for me personally. So I think it is pretty clear that we do NOT "have two equally good options" as Adam Williamson wrote (in the post to which you were replying). Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leon Fauster via devel wrote: > I already had RHL installed on a Sun IPX with Gnome, so I'm biased. Interesting that you were not put off by the changes that have happened to GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was actually pretty good. (It was very configurable back then. Remember when it shipped Enlightenment as the window manager, how many options that had?) Then GNOME 2 came, removing much of the configurability of GNOME 1. And then GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME 2, leading to a very hardcoded experience. GNOME 2 was already too much for me, and I switched back to KDE, back because I had already tried KDE 1.1.1 on another distro. And I have never looked back. Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it out once. But it took less than 10 minutes for me to realize that it is not for me. The user experience is just too unfamiliar (the unified application menu and open window selector (launch menu AND task bar replacement), the always maximized windows, the lack of a system tray, the shut down options in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does not make it easy for you to change it. (You can actually get a pretty standard desktop experience nowadays if you install a lot of "unbreak this", "unbreak that" GNOME Shell extensions, but that kinda defeats the point of GNOME.) The default experience felt pretty much unusable to me personally. KDE Plasma not only has more familiar defaults (actually looking and feeling much more similar to GNOME 1 than GNOME 3 does), but also lets you easily change those defaults that you do not like. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Stephen Smoogen wrote: > Downloads are very hard to measure because too many things are grabbing > everything from mirrors for different reasons. [Plus various people seem > to think manipulating the stats for their particular spin on the number of > downloads will make it more popular (I am looking at the several dozen ips > which were downloading the same spin every ten minutes). The countme > stats for 'running' systems > https://data-analysis.fedoraproject.org/csv-reports/countme/ can probably > give you the data on number of active systems. Countme stats do not tell you though how many of those users actually downloaded their Edition from fedoraproject.org vs. getting it preinstalled by some cloud/VPS/dedicated server provider. If people are not going to fedoraproject.org to download, say, the Cloud Edition or the Server Edition, then it is pointless to feature that particular Edition prominently on fedoraproject.org. That is why I was asking for download statistics specifically. And is there a statistical evaluation of that data somewhere? Downloading 350 MiB (!) of raw CSV data does not sound to me like a convenient way to work with it. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Another route would be to go the Ubuntu route, if you really don't want to > stop having Workstation as the default: Spin (pun intended) the KDE spin > on it's own branding. Though I do understand that is an undertaking on > it's own. It would still be Fedora, about as much as Kubuntu is Ubuntu. > (Though, I don't know about 'Kedora' as it has absolutely no meaning XD) > Though I feel like we should really only go this route if the other ideas > get completely exhausted... That is what I tried with Kannolo. Success was… limited, to say the least. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Andreas Tunek wrote: > From Red Hat's POV it is not Fedora Gnome Workstation ( > https://blogs.gnome.org/uraeus/2020/05/07/gnome-is-not-the-default-for-fedora-workstation/ > ). TL;DR: "We do not want 'GNOME' in the name because we want to only support GNOME in Workstation, whereas 'GNOME Workstation' would imply that there are other Workstations." I am not sure I buy this argument. By the same argument, we should also not call the OS "Fedora Linux" because it implies there is also a "Fedora BSD" or "Fedora Hurd" or even "Fedora Windows" ;-) or something. Giving a product a clear name does not imply existence of another product. (And that is not even arguing the premise of the "one single Workstation that happens to use GNOME" concept, only the branding implications!) > One of the best things with Fedora Workstation is that it is a complete > user facing OS (like Windows, macOS and iOS) that you actually can develop > applications for (if you want to). You don't have to target the extremely > fluffy "Linux desktop", you can target Fedora Workstation. This proposal > would totally eliminate the good points of having this single OS and app > platform. That "conveniently" ignores the existence of that pesky thing called "other distributions". The GNU/Linux version of vendor lock-in. Thanks Red Hat! And besides, a standalone application (as opposed to a desktop widget or similar) developed for one of the Fedora desktop deliverables (Workstation Edition, desktop Spins) is also going to work on any of the others. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > to you? They are quite relevent to others... I would really like to see what the proportion of users downloading the Server, IoT, Cloud, and CoreOS Editions is compared to Workstation or the Spins. I would not expect it to be very high. Most Fedora users are desktop users. And server or cloud users will mostly install Fedora by picking "Fedora" in a combo box at their commercial cloud, VPS, and/or dedicated server provider's web interface, not from fedoraproject.org. I would be surprised if the percentage of users both running a home server or a private cloud (as opposed to a hosted commercial offering in a remote datacenter) AND picking Fedora as the OS to run on it (as opposed to a more conservative OS such as Rocky/Alma or Debian stable) were significant. CoreOS is also mostly a server thing, desktop users get pointed to Atomic Desktop variants (Silverblue/Kinoite/"… Atomic") instead. And IoT is just completely niche. So why do you expect those Editions to be more relevant to users downloading Fedora from fedoraproject.org than the Spins? Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Luis Correia wrote: > I'm mostly a user and I can accept a change from GNOME to KDE, IF and only > if I'm not forced to use Wayland. > > For me it isn't usable in my setup and most things are plain broken. As the maintainer of plasma-workspace-x11 and kwin-x11, I can assure you that that will not be the case. I have been through a whole FESCo debate just to be allowed to maintain those packages. 1. sudo dnf install plasma-workspace-x11 2. Select "Plasma (X11)" as the session type in your display manager. 3. Enjoy! (It is also possible to force SDDM to itself use X11 rather than Wayland, if even SDDM does not work properly under Wayland for you.) Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Peter Boy wrote:
> We would be pretty silly if we did that. This differentiation and the
> associated quality and safeguarding criteria are a model for success and
> one of our differentiation criteria.
I think that is a quite pointless "differentiation criteria". Most users do
not even understand the difference between an "Edition" and a "Spin" or
"Lab". And technically, there is none. I do not see how Fedora's success has
anything to do with such an implementation detail.
All this differentiation achieves is creating first-class ("Edition") and
second-class ("Spin" or "Lab") spins, for no benefit whatsoever.
Kevin Kofler
--
___
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: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Joe Orton wrote: > Given that the ENGINE API is deprecated upstream since OpenSSL 3.0, the > API is optional upstream, and its use has produced compiler warnings > since it was introduced in Fedora 36, it seems perfectly reasonable to > disable this API in Fedora 41. I disagree. Disabling an API that is still widely used and for which there is still no complete replacement (several replies have pointed out issues still preventing "providers" from working in all use cases in which "engines" work) is NOT reasonable. > We have to deal with a very large numbers of FTBFS bugs from e.g. Python > API breaks every other release cycle, or the latest compiler flag > tuning. The fact that the transition creates work for other package > maintainers is obviously not a reasonable blocker for a Fedora Change. And that is exactly the kind of cultural issue we need to solve. The Python 3 transition is exactly an example of a transition that was handled horribly, kicking out lots of useful packages from Fedora just because they were not ported to Python 3. Python 2, or a fork like Tauthon (which has the advantage that it supports some Python 3 features, so some Python-3-only libraries / library versions can be backported to Tauthon more easily than to stock Python 2), should have been retained as a compatibility platform in Fedora. (There is technically still a "python27" package, but the modules available for it are intentionally limited and there are strict rules on what packages are allowed to depend on it.) It should NEVER be considered reasonable to break other people's work. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Putting aside that i heard from Neal Gompa that anaconda cannot > accommodate a « multi-flavor » media, can you imagine how big that iso > would be? Forget 4gb, it’d probably be closer to 20gb! We used to have multiboot live images that let you pick the live image flavor to boot and then install. At one point (for one or two, maybe three, releases only, then came "Fedora.next" and the Ambassadors were pressured to hand out only "Workstation"), we even handed DVDs with those (yes, in those good old days, a multiboot live image still fit on a DVD… then bloat happened!) out at events. (I even did a custom one once for the Vienna event in May 2015, which dual-booted the latest Fedora 21 KDE live-respin with Plasma 4 and the Fedora 22 Beta KDE live with Plasma 5. I did not put Workstation on those because we had tons of pressed Fedora 21 Workstation DVDs anyway.) Unfortunately, the scripts that generated those were unable to keep up with all the complications caused by UEFI and so-called "Secure Boot". (They used to work back when everything still booted in legacy BIOS mode.) So some engineering effort will probably be needed, and a lot of testing on different hardware will definitely be needed, to make the multiboot generator work (reliably) again. Kevin Kofler -- ___ 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
Eric Blake wrote: > The upstream autoconf discussion says that 'autoreconf -fi' behavior > on which 'serial NN' .m4 files to update is determined by automake, > not autoconf, in part inspired by semantics desired in gnulib. And > the automake and gnulib developers have argued that the upstream > behavior is intentional: > > https://lists.gnu.org/archive/html/bug-autoconf/2024-04/msg5.html Don't you love intentional bugs? Yet another reason to avoid autotools at all costs. By the way, the documentation of the serials "feature" actually warns about this (and seems to imply that even without serials, --force does not work as advertised for those files): https://www.gnu.org/software/automake/manual/html_node/Serials.html | Finally, note that the --force option of aclocal has absolutely no effect | on the files installed by --install. For instance, if you have modified | your local macros, do not expect --install --force to replace the local | macros by their system-wide versions. If you want to do so, simply erase | the local macros you want to revert, and run ‘aclocal --install’. But the documentation of "autoreconf --force" does not include that warning. And this also makes "--force" pretty much useless as it stands. We and Debian both need to patch aclocal downstream immediately to make --force actually work. And then of course Fedora needs to actually always run autoreconf -i -f as Debian already does, or the patch will not do much good. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > Why not the opposite: > > Download Workstation > > [I'm a linux user and know what I want, just show me the full list of > downloads, click here]? Because that still leads people to click that "Download Workstation" link before even seeing the options. "I do not want to have to choose" should be a concious choice, also considering that the mostly unconfigurable (by design) GNOME is very likely to be the wrong option for anybody not in that category. And besides: > (Which is pretty much what we have now) Well, not quite, it is more like: [LOGO Workstation (Download Now) (Learn More)] [LOGO Server (Download Now) (Learn More)] [LOGO IoT (Download Now) (Learn More)] [LOGO Cloud (Download Now) (Learn More)] [LOGO CoreOS (Download Now) (Learn More)] Want more Fedora options? Atomic Desktops (Learn More) ← no frame nor logo nor mention of "download" Fedora Spins (Learn More) ← no frame nor logo nor mention of "download" Fedora Labs (Learn More) ← no frame nor logo nor mention of "download" Fedora ALT Downloads (Learn More) ← no frame nor logo So you get offered a lot of (most likely) irrelevant (to you) options (Server, IoT, Cloud, CoreOS) before even being told that there are more options than those (and Workstation), the "Workstation" link does not tell you that (even though those are clearly workstation/desktop-targeted options too), and you also do not see the full list of options anywhere, but just a list of lists. You actually have to click on "Learn More" after "Fedora Spins" to even see what desktop environments are available. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Adam Williamson wrote:
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next
That was for Fedora 21 in 2014! As you stated it, I know you and I have been
around forever and 2014 feels like yesterday, but it was really quite a long
time ago. ;-)
Now we are planning for Fedora 2*21, which would be a good time to revisit
this decision.
> which was explicitly based around making it much more focused and less of
> a choose-your-own-adventure, specifically including making the download
> page much more opinionated.
Which is exactly what we (KDE users) are complaining about and have been
complaining about for those 10 years. And we know many users have complained
about it, too. If they even found out Fedora supports KDE/Plasma at all,
which not all of them did.
The download page now is not as horrible as it was 10 years ago, but the
main issue (the featuring of the Editions at the expense of everything else,
making the GNOME "Workstation Edition" much more prominent than the other
desktop environment options) is by design and thus still present.
> AFAIR, the numbers Matthew tracks strongly indicate this was associated
> with a very significant immediate bump in Fedora usage.
There is no evidence that this was a consequence of the change itself and
not of the massive marketing done around it. Media loves announcing when
something changes. So if Fedora changes things again to make Editions and
Spins equal, and comes up with a fancy codename (like the old "Fedora.next")
for that ("Fedora.equality"? "Fedora.flexible"? "Fedora.choice"? "Your
Fedora"? Or whatever the marketers can come up with), I expect that we will
get lots of media coverage and another bump in downloads from that.
Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Sorry, that's pretty much how things are right now, is that what you were > trying to demonstrate? > > I'm not really following. Not really. The current design is better than those old designs that immediately served you an ISO when you clicked "Download now", but the focus is still on the Editions (which are framed and have logos) at the expense of the Spins and the other options (which have neither frames nor logos). Clicking on Workstation then gives you a selection of architectures, but not of desktop environments; for those, you have to find and pick the (much less prominent) Spins option on the front page instead. I think the first thing to offer users should be the Spins (including the "Workstation Edition" which is technically no different from a Spin). Most users are looking for a desktop distribution. The non-desktop options should come last, after all the desktop-ish (desktop, mobile, lab, and atomic) options. Fedora 21 has introduced the Editions vs. Spins distinction, Fedora 2*21=42 would be a good time to retire it. And selecting a desktop/workstation download should require you to select the desktop environment, with a skip option clearly labeled something like "I do not want to choose" or "Options confuse me" (or "I HATE OPTIONS!" as I had called it somewhat hyperbolically), which happens to be a pretty good description of the GNOME design philosophy. Or maybe even just: (·) GNOME (default) A desktop environment focused on ease of use **Pick this option if questions like this one confuse you.** ( ) KDE Plasma Desktop A highly customizable desktop environment ( ) Xfce A lightweight desktop environment etc. But there should be no link directly to any GNOME Edition/Spin/whatever (except Labs, if that specific Lab exists only as a GNOME-based version) without a clearly visible selection of desktop environments (which is unfortunately what the current "Workstation" link is). (And for Labs, the selection should at least visibly state somewhere what desktop environment they are based on, an information which some Labs now put in their description, requiring an extra click to see it, and some not even there.) Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > Ok, thats obvously somewhat tounge in cheek, but if we promote multiple > things, we need some way to describe them to uses who might not know the > history of things and do it in a quick enough way that they won't decide > it's all confusing and go do something else. It is actually quite simple: Here are your options: [I HATE OPTIONS, JUST GIVE ME SOMETHING WITH NO OPTIONS!] (big button) → downloads GNOME x86_64 DESKTOP SPINS: Desktop: ( ) GNOME (Workstation) ( ) KDE Plasma Desktop ( ) Xfce etc. Architecture: ( ) x86_64 (64-bit x86/AMD64) ( ) aarch64 (64-bit ARM) etc. [DOWNLOAD SELECTED] MOBILE SPINS: Mobile Environment: ( ) Phosh etc. Architecture: ( ) aarch64 (64-bit ARM) etc. [DOWNLOAD SELECTED] LABS: Lab: ( ) Astronomy etc. Architecture: etc. [DOWNLOAD SELECTED] ATOMIC DESKTOPS: Desktop: ( ) GNOME (Silverblue) ( ) KDE Plasma Desktop (Kinoite) ( ) Sway (Atomic) ( ) Budgie (Atomic) Architecture: etc. [DOWNLOAD SELECTED] OTHER EDITIONS: Edition: ( ) Server etc. Architecture: etc. [DOWNLOAD SELECTED] Of course there is going to be a lot of bikeshedding about the order of the options. I would put them in that order, because I think desktop spins are most likely to be downloaded by a new user, then mobile, then use-case- specific labs, then experiments like Atomic, and then non-desktop stuff like Server. But the most important feature is the "I HATE OPTIONS!" button, because it serves exactly the users you think will be confused by the options and will give them a desktop environment designed exactly for them. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > We essentially just want more visibility on the website, if that makes > sense. Back when I was still a KDE SIG member, whenever we brought that up with the Websites Team, they would just point us to the Board (what is now the Council), and the Board would point us back to the Websites Team. That fingerpointing was very effective at preventing any change. And the Websites Team has always been really creative at hiding the KDE Spin the best they could, hiding it behind extra "Additional options" links in fine print, even with a grayed-out "Spins" icon (looking as if they were somehow unavailable), while having a huge "Download" button on the front page immediately serving you a GNOME ISO for a default architecture (for a long time i686 even though many people already actually wanted x86_64, then x86_64 even while 32-bit was still supported) with no further confirmation. Any reasonable Free Software project does not have the download link on the front page serve directly an arbitrary file, but a download page with explanations and a choice of download options, but the Fedora Websites Team insisted that "'Download' means 'Download'" and that a button with a verb must trigger an immediate action. Kevin Kofler -- ___ 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Adam Williamson wrote:
> Change proposals can be, and frequently are, rejected.
If you look at the statistics, they very rarely are. A lot of bad changes
with lots of criticism on the mailing list were waved through by FESCo. But
if they dare touching a Red Hat holy cow such as the dogma of defaulting to
GNOME everywhere, they are likely to be rejected. (Been there, done that.)
Kevin Kofler
--
___
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
Richard W.M. Jones wrote: > Yes, in this case the attacker had set the serial number to 30, but > the latest upstream serial number was 3. autoreconf won't replace the > file in this case unless it is deleted. There really should be an > "always replace if you can" option in autoreconf. Is that not what -f is supposed to do? At least, the documentation claims so, but the implementation does not actually do what is documented. Kevin Kofler -- ___ 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 we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]
Gary Buhrmaster wrote: > And, more importantly, the industry has agreed > to use the term supply chain. Is the term > perhaps overloaded, or perhaps too > ill-defined/imprecise? Sure. But if one wants > to use a different term one would need to work > across the industry to change the term, and > that is not going to happen. Well, one could argue that Free Software is a community, not an industry, so "the industry" cannot agree on anything, and "supply chain" as an industrial term obviously does not apply. And also that it is called "Free Software" and not "Open Source". :-) Kevin Kofler -- ___ 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
Adam Williamson wrote: > It occurs to me - maybe you don't agree, but this is how it looks to me > - that, ironically, you and I usually argue the exact *opposite* side > of this case, no? I argue in *favor* of somewhat-arbitrary delays to > packages appearing in 'stable', and you argue *against* them. :D I have never argued against updates-testing existing or that all packages should skip updates-testing. "Please pick up this new upstream version, it has some great new features" as was done here is exactly the kind of changes that SHOULD go through updates-testing. But if the maintainer has something urgent to push out, such as an important regression fix or a critical security fix (e.g., a fix for a backdoor like this one), they should be allowed to decide to skip testing and not be treated as being too incompetent for that (while at the same time allowing any other person, with no other credentials than a FAS account, to +1 the package, allowing it to be autopushed to stable – everyone except the one person most qualified to make that decision). THAT is what I have been arguing for all this time, and I do not see how this contradicts my position here in any way. Kevin Kofler -- ___ 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
Gordon Messmer wrote:
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.
This proves again that this is a very targeted attack that carefully
analyzed the individual targeted distributions, the distributions whose
packaging tools the build script attempts to detect were not just picked
because they are known to link OpenSSH to liblzma, but also individually
tested and targeted.
Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Aoife Moloney wrote:
> Switch the default desktop experience for Workstation to KDE Plasma.
> The GNOME desktop is moved to a separate spin / edition, retaining
> release-blocking status.
It is funny that the KDE SIG is proposing that now. I have a sense of déjà-
vu:
https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default
Back then, the KDE SIG was NOT willing to support my proposal (even though
the timing would have been ideal, given that GNOME was badly hit at the time
by the GNOME 3 transition and users disappointed by the radical cuts in
customizability). Now they are refloating it as their own, without even
citing my original proposal.
Kevin Kofler
--
___
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
Chris Adams wrote:
> However, it's a good trigger to review Fedora's security approach in
> general (like 2FA use).
Using such an issue that made it through upstream 2FA and would also have
made it through any 2FA enforcement in Fedora as an excuse to force 2FA on
us is just pure nonsense.
Kevin Kofler
--
___
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
Matthew Miller wrote:
> I sometimes see unit test failures. The developer ran the tests, but not
> on S390.
Why would I want a test failure on such an exotic architecture to fail my
build? The only reason Fedora supports that architecture at all is pressure
from IBM. Basically nobody uses it.
Kevin Kofler
--
___
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
Lennart Poettering wrote: > It *literally* is just sending a text string "READY=1" in an AF_UNIX > datagram to a socket whose path is provided to you in the > $NOTIFY_SOCKET env var. I see so many ways one can get this wrong. E.g., using some abstraction for the socket write that can also write to regular files, without checking that "$NOTIFY_SOCKET" is really a socket (or checking it with a TOCTOU vulnerability), introducing an arbitrary file overwrite vulnerability. Kevin Kofler -- ___ 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
Adam Williamson wrote: >> * Deleting ALL files automatically generated or imported by autotools in >> %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it >> would NOT have done the right thing here. Delete the files, THEN run >> autoreconf.) > > No. This would not have avoided the attack, because it would not have > regenerated the malicious file. We have already established that. Just running autoreconf would not. As I wrote: "DO NOT trust autoreconf, it would NOT have done the right thing here." Deleting the file with an explicit rm -f in %prep, and THEN running autoreconf would have regenerated (reimported, actually, this comes from gnulib and is copied unchanged, but in any case it would NOT have contained the malicious additions) the file. That said, autoreconf needs fixing too, because -f is supposed to regenerate all files that can be regenerated, which is not happening. But if you explicitly delete the files before running autoreconf, then it has to regenerate them no matter what. Kevin Kofler -- ___ 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
Adam Williamson wrote: > I would argue there's a danger of getting too tied up in very specific > technical details of this attack. But the fact is: What WOULD have stopped this attack: (one or more of:) * Deleting ALL unit tests in %prep (and then of course not trying to run them later). * Deleting ALL files automatically generated or imported by autotools in %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it would NOT have done the right thing here. Delete the files, THEN run autoreconf.) * NOT patching OpenSSH downstream to link it against libsystemd against upstream's recommendation. What WOULD have greatly reduced the impact of this attack: * NOT enabling updates-testing by default for Branched releases. What WOULD NOT have stopped this attack: (any or all of:) * 2FA. GitHub already enforces 2FA. It did NOT stop this attack. * Any stricter vetting of Fedora contributions. The attack was performed upstream, NOT in Fedora. * More distrust of new Fedora contributors. The offending upgrade was imported by a TRUSTED Fedora contributor. The untrusted new person operated upstream, NOT in Fedora. Kevin Kofler -- ___ 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
Adam Williamson wrote:
> Maybe this needs to go on the growing pile of reasons why the
> traditional Linux model *does* need to go away. Maybe Fedora, with its
> foundation of First, should be kind of at the forefront of making that
> happen.
Switching to a container-based model is just going to introduce more
different library versions (in the worst case, one per container) with a
higher probability that one of them is compromised.
Kevin Kofler
--
___
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
Adam Williamson wrote:
> Do we require 2FA for provenpackager yet?
No. I am a provenpackager and do not have 2FA enabled (nor do I want it to
be).
> People would say, justifiably so, that it was absolutely unacceptable for
> us to be allowing single-factor authentication for contributors to a
> general-purpose operating system in 2024. It is.
This is nonsense propaganda. Most 2FA implementations cannot even guarantee
that the second factor is not stored right next to the first factor. Open
standards that do not depend on commercial hardware or telecommunication
operators, such as TOTP, cannot guarantee it by design. Any 2FA app that
works on my PinePhone is also going to work directly on my computer, so you
have no way to enforce that I use a different device for the second factor.
2FA is pointless security theater that just makes it a pain to contribute,
when we are all this time talking about lowering, not rising, the barrier to
entry.
Kevin Kofler
--
___
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
Neal Gompa wrote: > Well, an easy solution is to make it so "dnf update" is coerced to > "dnf distro-sync" for development releases. That would not have helped containing this vulnerability. Keeping updates- testing disabled by default would have. Kevin Kofler -- ___ 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: Obsoleted packages in F40
Otto Liljalaakso wrote:
> So, I would actually much prefer if package retirement automatically
> added the package to fedora-obsolete-packages. Perhaps there are special
> cases where that would not be a good idea - if there are some, `fedpkg
> retire` could have a flag to prevent that from happening.
We have had this discussion several times on this list. The compromise that
was agreed upon is that packages should be added to fedora-obsolete-packages
ONLY if having those packages installed BREAKS something, e.g., prevents
upgrading some other package due to broken dependencies, or causes a file
conflict with some other package. Being retired is by itself NOT a reason to
forcefully remove a package that users may depend on from their systems. So
that is what should be documented, not your personal wishes.
Kevin Kofler
--
___
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
Adam Williamson wrote: > 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still > don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE > COMPULSORY 2FA FOR FEDORA PACKAGERS*. This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for contributors for a while, starting with "important" projects, then getting stricter and stricter. It has done absolutely nothing to stop this attack. How could it, when the backdoor was apparently introduced by the authorized maintainer? (Or if not, the attacker must have had access to their 2FA secret as well.) So, 2FA DOES NOT SOLVE THIS PROBLEM! STOP FORCING 2FA ON US! And especially DO NOT abuse this incident as an excuse to force 2FA down our throats, since 2FA DOES NOT SOLVE THIS PROBLEM. Sorry for being repetitive, but you were, too. THIS 2FA NONSENSE NEEDS TO STOP! > 2. Our process for vetting packagers is, let's face it, from a security > perspective almost *comically* patchy. There are 140 sponsors in the > packager FAS group. Any one of those people - or someone who > compromises any one of those 140 accounts - can grant any other person > on earth Fedora packager status. Our policy on how they should do this > is > https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Sponsor_a_New_Contributor/#sponsoring_someone_for_fedora_package_collection > . The words "trust" and "identity" do not appear in it. There is, > AFAIK, no policy or procedure by which inactive sponsors have this > power removed. There is no mandatory 2FA policy for sponsors. We already have a manpower problem, how is removing sponsors going to improve the situation? > 3. We have no mechanism to flag when J. Random Packager adds > "Supplements: glibc" to their random leaf node package. As a reminder, > *we are a project that allows 1,601 minimally-vetted people to deliver > arbitrary code executed as root on hundreds of thousands of systems*, > and this mechanism allows any one of those people to cause the package > they have complete control over to be automatically pulled in as a > dependency on virtually every single one of those systems. This would get noticed pretty quickly, when that package comes up in update transactions for no reason. I believe this has never happened so far. It is just too obvious. Kevin Kofler -- ___ 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
Kevin Fenzi wrote:
> Branched enables updates-testing... so if you installed f40 anytime, you
> will have it enabled and if you then applied updates it would be in them
Yet another thing I always said was a bad idea, and this incident proves it.
This would have been filtered before reaching most people if we made people
only test what actually ends up in the composed Beta and Final images, i.e.,
updates that made it out to stable. In addition, having updates-testing
enabled makes it unsafe to upgrade a Beta installation to Final because
suddenly updates-testing gets disabled, but people still have packages from
updates-testing (such as the backdoored xz, but also tons of untested
packages or ones that explicitly failed testing) installed.
Kevin Kofler
--
___
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
Miroslav Suchý wrote:
> 4) Fetch build artifacts before executing tests
>
> https://github.com/rpm-software-management/mock/issues/1352
Or better: Do not execute tests to begin with! rm -rf test in %prep and
NEVER run tests during builds. Even when the tests are all legitimate, all
it does is slow down the build (e.g., compare glibc build times without and
with tests) and every so often break it because the test, not the software,
is broken. And a claimed "test file" is what allowed the payload to be snuck
in here.
Unit tests are something for upstream developers. They should NEVER be run
in a distribution build.
Kevin Kofler
--
___
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
Zbigniew Jędrzejewski-Szmek wrote: > I think there's some useful points here, but this would need to be > qualified and/or made more flexible to be applied. > > For example, systemd repo has fuzzer case files, which are a mix of > text, mojibake, and actual binary protocol samples. For example, dhcp > input packets, dns packets. There are also other ~binary test files, > for example corrupted journal files. > > The tests are defined via meson.build, so those files are "referred to > in the build tools", and would not be allowed by the above definition. > But if we dropped those, we'd lose very valuable testing of the codebase. On the other hand, "test files" are exactly how the payload of this backdoor was disguised! So a policy that deletes all binary test files or even all test files altogether would have prevented this backdoor. Kevin Kofler -- ___ 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
Artem S. Tashkinov via devel wrote: > There must be a website or a central authority which includes known to be > good/safe/verified/vetted open source packages along with e.g. > SHA256/384/512/whatever hashes of the source tarballs. In addition, the > source tarballs (not their compressed versions because people may use > different compressors and compression settings) and their hashes must be > digitally signed or have the appropriate PGP signatures from the trusted > parties. > > Some parties must be assigned trust to be able to push new packages to > this repository. Each push must be verified by at least two independent > parties, let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't > matter. The representatives of these parties must be people whose > whereabouts are known to confirm who they physically are. No nicknames > allowed. This is just fundamentally not how Free Software works. Kevin Kofler -- ___ 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
Gary Buhrmaster wrote: > What I do think we should start with is look at the > list of dependencies in the list of whatever we > can agree are security critical packages (running > as root and opening network ports is always a > good start) and dependencies which are not > supported by a large-ish organization (even if > only informal), with a set of experienced > developers, and sufficiently funded to continue > support of the package, and has a good security > reporting and response process in place. What if, as in the case of SELinux, said "large-ish organization" is exactly the kind of organization one would expect to plant a backdoor like this? Also, a "large-ish organization" can be secretly contacted by the intelligence agencies of the country it resides in and tasked to implement secret backdoors for them. It has happened with large proprietary software providers, so why could it not happen with a large organization developing Free Software? Projects done by a "large-ish organization" are NOT immune to this kind of attack. It would just be executed differently, not as a hostile takeover by one "motivated new maintainer" as for an individual hobbyist project like xz. Kevin Kofler -- ___ 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
Zbigniew Jędrzejewski-Szmek wrote:
> In fact, we should probably make the effort to add pkgconf files for the
> few libraries that don't have it to make it completely standard and
> expected.
That is a particularly bad idea. Downstream .pc files are a nuisance. If
someone develops upstream software on Fedora, they will end up relying on
those .pc files, thinking they are a supported way to link that library,
then only after releasing the code, finding out that those .pc files do not
exist upstream or in any other distribution (or worse, other distributions
may have their own, incompatible, downstream .pc file for the same library).
I have already been in that situation as a developer. It just sucked.
If a library does not support pkg-config upstream, you MUST NOT use pkg-
config to find it. It is not portable. So shipping such a downstream .pc
file advertises a false interface to developers.
Kevin Kofler
--
___
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
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. Find*.cmake scripts for many common libraries are actually shipped with CMake itself. More and more libraries even ship their own *Config.cmake which makes a Find*.cmake script entirely unnecessary. For less common libraries, you are probably better off simply using the CMake pkg-config integration, which exists. Assuming of course that that library ships a .pc file to begin with, otherwise, pkg-config is not going to help you. (And when I write "pkg-config", I mean either the original pkg- config or pkgconf, the build system should not need to care about the difference.) The reason CMake upstream recommends against using pkg-config directly, and instead to use it at most as a source of hints for CMake's find_* commands (e.g., find_library) in a Find*.cmake script, is that using pkg-config on Windows is often frowned upon. So typically, the way it works is that someone first writes a Find*.cmake that finds the library in the standard paths using find_library, then extends it to invoke pkg-config using the CMake pkg-config integration under "if (UNIX)" and to add the result as a path hint to the already written find_library call. > And of course nobody has time to look into those scripts, making it > easy to smuggle something through there. You are right that bundled Find*.cmake scripts are a problem. Kevin Kofler -- ___ 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
Neal Gompa wrote:
> And in CMake's favor, there's a huge ecosystem of helpers and
> integrations that make it easier for people to understand what CMake
> is doing as it's being developed, built, and shipped. That makes it
> much more attractive than Autotools simply because the knowledge and
> the tooling is there for developers and users to dig into it.
Well, to be fair, I have also seen (more than once!) arcane stuff being done
in CMake, with almost a whole new build system being built on top of CMake
(tons of custom macros implementing things such as bundled libraries, before
CMake had native support for that), which was not particularly easy to
understand either.
If you use CMake the way it was intended, a CMakeLists.txt is a lot more
readable than even a configure.ac and Makefile.am, let alone the generated
blobs autoconf spits out based on those. But there is potential for abuse,
too.
That said, I do not believe completely banning custom functions and macros
as Meson does is a workable solution.
Kevin Kofler
--
___
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
Kilian Hanich via devel wrote: > Meson doesn't allow you do create your own functions. While one should > try to avoid them in build systems, there are cases where you need them. > I work on a project where they are needed, but it also wouldn't make > sense to upstream it because it's too project specific, and creating a > loop out of every call like Meson's FAQ recommends > (https://mesonbuild.com/FAQ.html#why-doesnt-meson-have-user-defined-functionsmacros) > would create one heck of spagetthi code. Yes, that is exactly what makes Meson all hardcoded and not extensible. If you need to do anything that the Meson developers did not think of, you end up having to work around the build system (using external commands, or a Meson file generator that preprocesses macros, or some other ugly hack) instead of with the build system or just having to switch to a better build system (such as CMake ;-) ). Using loops instead of functions or macros also misses one important point: the function or macro can be shared between projects and even eventually upstreamed to the build system (both of which happen regularly in the CMake world). By the way, CMake allows defining both macros and actual functions, and macros are what you want to use in most cases. The main reason functions were introduced is to allow recursion (which is a two-edged sword because it makes the language Turing-complete with all its implications). Kevin Kofler -- ___ 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
Neal Gompa wrote:
> Note that dlopen() doesn't fix the problem of the giant libsystemd in
> the first place. It just obfuscates the true dependency graph of
> libsystemd.
At least it (hopefully) means liblzma will not be opened if you do not use
an API that needs liblzma. But it makes it even harder to tell whether
liblzma will end up being loaded or not.
> Long ago (I think like ~10 years ago), libsystemd was actually several
> separate smaller libraries. Perhaps we could consider asking upstream
> to switch back to that model?
+1
Kevin Kofler
--
___
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
Zbigniew Jędrzejewski-Szmek wrote: > Meson outclasses CMake in functionality, LOL, how so? Everything in Meson is hardcoded, you have very little flexibility (but still enough to plant a backdoor if that is what you want, because you can just invoke a shell script or any other external command). CMake is completely extensible with a complete programming language (it is Turing-complete if and only if you use recursive functions; if you avoid FUNCTION or at least recursive ones, then it is guaranteed to always terminate and still usually expressive enough, but Turing-completeness through recursion is there if you really need it). > clarity, and brevity. That is very much in the eye of the beholder, and it also depends on whether you use modern CMake or legacy constructs that are often overly verbose. Meson does not have so much legacy stuff simply because 1. it is much newer (which also means it is less mature) and 2. it cares less about backwards compatibility (which is not a good thing, backwards compatibility is essential if you want to avoid upstreams bundling old copies of build tools). > I doesn't make sense to consider switching to CMake at this point. CMake being what the whole Qt and KDE community uses nowadays (even Qt itself switched to it with Qt 6), it very much makes sense to switch to CMake now more than ever. The main reason Meson is a thing at all (and not just one person's little- known project as it initially was) is that GNOME did not want to use the same build tool KDE was already using (even though they had the exact same issues with autotools). > I don't think a separate library would be particularly useful. > sd_notify() as used by sshd just writes a static string to a unix > socket. This can be implemented in ~10 lines of C, including error > handling. Copy is exactly what we do not want here. (It can easily be done wrong, either accidentally or deliberately, introducing security issues, and any security issue discovered in the copied code has to be fixed in all the copies.) If daemons are likely to need only one function (sd_notify), then a library containing only that one function is exactly what is needed, no matter how small it is. > If that is the _only_ thing needed from libsystemd, then open-coding it > is a good option. I guess it'd make sense for systemd to provide a header > file that provides a reference documentation as an inline function. That is an option which is better than copy, but it still means that all users will need to be rebuilt if a bug in that header file is fixed (as for a static library, but unlike a shared library). > One thing which is happening, mostly for unrelated reasons, it that > systemd code is being changed to use dlopen() for various libraries which > are usually not needed at runtime. The primary motivation for this is to > omit such libraries from the initrd. But this also helps with overlinking. > > In systemd git main, libsystemd is only linked to libc, libcap, > and libgcrypt + libgpg-error. A pull request to convert that that last > pair to dlopen is under review. That helps somewhat (it would have prevented this backdoor from working), but it also makes things even less transparent: How do we know whether some random sd_foobarify() function or some random foobard linked against libsystemd will (always or ever (and when?)) end up dlopening liblzma or not? Distribution packagers tend to dislike dlopen due to the hidden dependencies it introduces. Kevin Kofler -- ___ 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
Neal Gompa wrote: > This is not helpful in the slightest and the tone is not appreciated at > all. Well, I have been arguing against this exception (exempting prebuilt autotools output) from the "no prebuilt blobs" rule for years, and it saddens me that something like this had to happen for Fedora to finally realize that that exception has always been a bad idea. > That said, this is being tracked by the Packaging Committee: > https://pagure.io/packaging-committee/issue/1350 Finally, thanks! (But you filed that only now after this incident, see above. Still, thanks that you are bringing this up now!) > Yes, we should scrutinize things like this. Though I will note that we > didn't actually suffer an attack through this venue with library code, > just the build scripts. Generally, people do not pay attention to > build scripts, and that was how this slipped by for so long. But even > so, Autotools is particularly difficult to understand and I don't > think we would have ordinarily caught it anyway. I definitely agree there, build scripts are indeed an attractive target for backdoor authors, and autotools is indeed a big part of the problem. The whole architecture of autotools was designed for a situation that is mostly obsolete these days: people running some proprietary Unix with some buggy implementation of a Bourne-like shell and no centralized build tools who want to just untar a tarball and build it with only what they already have installed (the buggy shell). Hence all this concept of shipping prebuilt obfuscated shell blobs full of workarounds for bugs in ancient shell implementations. Nowadays, people are either running GNU/Linux, where centralized build tools such as CMake or Meson are readily installable from the repository (and where most builds are done by distributions, for whom it is just a matter of adding, e.g., "BuildRequires: cmake"), or Microsoft Windows, where an environment that can run autotools scripts (e.g., MSYS2) is NOT part of the system and actually as hard or harder to install than something like CMake. So, nowadays, pregenerating shell scripts is a completely outdated and unhelpful way of working. > That said, I agree that pretty much every display manager and > compositor for every Fedora variant should be critpath'd. Well, where we disagree is that I actually want to see LESS stuff in critpath, not more. It cannot be scrutinized well enough because there is just too much stuff in it. E.g., at times, we had MySQL/MariaDB in critpath because Akonadi required it. (Nowadays, Akonadi actually recommends using SQLite instead.) That just does not make sense. Kevin Kofler -- ___ 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
Dominique Martinet wrote: > I'm not 100% sure about the theory, but it looks like `autoreconf -fi` > looks at the 'serial' in the first line of the script. > The one bundled in the xz sources was marked very high: > # build-to-host.m4 serial 30 > But the one in the system (as of f39) is only 'serial 1'. > > Artificially lowering the serial back to 0 in the file and running > `autoreconf -fi` again properly reinstall the one from the system over > it, but anything higher will keep it... > > So if we want to go this route, we should remove the full m4 dir, but > unfortunately I've seen quite a few projects that depend on non-standard > m4 scripts so we'll need to fix these as we go... Well, it all depends on whether those m4 scripts are really source code or whether they are autoimported from somewhere like gnulib. True source code needs to be retained, anything that can be autoimported should be autoimported at build time. (And upstreams should stop using imported copylibs to begin with, but that is a different story.) > (At which point I'd suggest it's probably faster to convert it all to > meson or another new shiny, and saner, build system, but getting upstreams > to agree will be fun) CMake! :-) >> (2) We should discourage gnulib as much as possible. >> [...] >> In the xz case it was a gnulib-derived script which was modified to do >> the initial injection (original: >> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). > > (Honestly I did compare the backdoored script and the real one this > morning and I would be hard pressed to say if either is backdoored just > looking at either version... Admitedly it was 3AM when I looked at it, > but I don't think it's just a late hour problem) That is exactly the problem with autotools code, almost nobody understands what the heck it does, almost everybody just copies and pastes somebody else's snippet hoping it does not do bad things. And gnulib is a particularly ugly piece of the puzzle. > Before making each of these safer we should make sshd not link with so > many things in the first place. Indeed. E.g., Arch Linux does not transitively link sshd against liblzma. Fedora does because of this innocuous-looking patch: https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch which is what ultimately allowed this to happen. This drags in libsystemd for sd_notify, and libsystemd is linked to way too much stuff including liblzma. Either we need a split libsdnotify that contains only sd_notify, or we should just stop using sd_notify at all. It increases the attack surface of daemons a lot just to allow the service to be "Type=notify" rather than one of the other available approaches. Arch Linux is also systemd-based nowadays, but still does not link OpenSSH against libsystemd. Kevin Kofler -- ___ 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
Richard W.M. Jones wrote: > (1) We should routinely delete autoconf-generated cruft from upstream > projects and regenerate it in %prep. It is easier to study the real > source rather than dig through the convoluted, generated shell script > in an upstream './configure' looking for back doors. > > For most projects, just running "autoreconf -fiv" is enough. > > Yes, there are some projects that depend on a specific or old version > of autoconf. We should fix those. But that doesn't need to delay us > from using autoreconf on many projects today. I have always said that. We do not allow other prebuilt binary blobs and require rebuilding everything from source. I do not see how the obfuscated autogenerated shell scripts from the autotools are any different. Sadly, I was ignored. Now you folks (Fedora) see where this leads. Told You So. > 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. Looks like autoreconf does not work as advertised. With -f, it is supposed to regenerate all files that it knows how to regenerate. It clearly does not do what it is supposed to and ought to be fixed. > (2) We should discourage gnulib as much as possible. > > In libvirt we took the decision a few years ago to remove gnulib. > It's extremely convoluted and almost no one understands how it really > works. It's written in obscure m4 macros and shell script. > > It's also not necessary for Linux since gnulib is mainly about > porting to non-Linux platforms. There are better ways to do this. > > In the xz case it was a gnulib-derived script which was modified to do > the initial injection (original: > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). There too, I agree completely. Also because gnulib is a "copylib", which is a very broken concept. A true library would not be subject to this kind of "take the file from the copylib and inject bad code into it" attack. > (3) We should have a "security path", like "critical path". > > sshd is linked to a lot of libraries: > > /lib64/libaudit.so.1audit-libs > /lib64/libc.so.6glibc > /lib64/libcap-ng.so.0 libcap-ng > /lib64/libcap.so.2 libcap > /lib64/libcom_err.so.2 libcom_err > /lib64/libcrypt.so.2libxcrypt > /lib64/libcrypto.so.3 openssl-libs > /lib64/libeconf.so.0libeconf > /lib64/libgcc_s.so.1libgcc > /lib64/libgssapi_krb5.so.2 krb5-libs > /lib64/libk5crypto.so.3 krb5-libs > /lib64/libkeyutils.so.1 keyutils-libs > /lib64/libkrb5.so.3 krb5-libs > /lib64/libkrb5support.so.0 krb5-libs > /lib64/liblz4.so.1 lz4-libs > /lib64/liblzma.so.5 xz-libs > /lib64/libm.so.6glibc > /lib64/libpam.so.0 pam-libs > /lib64/libpcre2-8.so.0 pcre2 > /lib64/libresolv.so.2 glibc > /lib64/libselinux.so.1 libselinux > /lib64/libsystemd.so.0 systemd-libs > /lib64/libz.so.1zlib / zlib-ng > /lib64/libzstd.so.1 zstd > > Should we have a higher level of attention to these packages? We > already have "critical path", but that's a broad category now. These > seem like they are "security path" packages, an intentionally small > subset associated with very secure services which are enabled by > default. I think the issue is that there is just too much stuff in critpath these days. Whole desktop environments and all their transitive dependencies probably ought to not be in there. If at all, I would put the display manager in there, maybe the window manager, and no further. Kevin Kofler -- ___ 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
Mikel Olasagasti wrote:
> And they wayback WayBackMachine[3] doesn't have previous versions.
We have the previous versions in the dist-git lookaside cache and in the old
SRPMs.
Kevin Kofler
--
___
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
xz backdoor
Hi, wow: https://www.openwall.com/lists/oss-security/2024/ I think at this point we clearly cannot trust xz upstream anymore and should probably fork the project. Kevin Kofler -- ___ 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: F41 Change Proposal: Change Compose Settings (system-wide)
Daniel Alley wrote: >>ry xz -9, it should be better than zstd. It will take longer to compress, >>but should actually be FASTER (!) to decompress, which is what really >>matters. > > Please provide data - any data - to support this claim, because it flies > completely in the face of every benchmark the internet has to offer, > including the one Sirius performed below. In any case, according to Sirius' benchmark, it looks like zstd -19 actually beats even xz -9 at compression ratio (while being worlds faster to decompress), so it looks like a good alternative. It takes 3 times longer to compress, but who cares, since that happens only once per compose, on one computer, vs. millions of Fedora users having to download and decompress the file. The tradeoff should be obvious. (You can also see that the decompression time does in fact go down from xz -4 to -6 to -7, then stays constant on -7, -8, -9 where little to no further size reduction is reached. This is consistent with what I explained in my previous reply to your post above. But of course zstd at any level is about 6 times faster to decompress than xz at any level.) Given the benchmark results on one of the actually affected files, I now think zstd -19 is what we want to use, not xz -9. Kevin Kofler -- ___ 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: F41 Change Proposal: Change Compose Settings (system-wide)
Daniel Alley wrote: >>ry xz -9, it should be better than zstd. It will take longer to compress, >>but should actually be FASTER (!) to decompress, which is what really >>matters. > > Please provide data - any data - to support this claim, because it flies > completely in the face of every benchmark the internet has to offer, > including the one Sirius performed below. I think you misunderstood what I wrote (which admittedly was somewhat misleading). I mean xz decompresses faster when the input was compressed with xz -9 than when it was compressed with just xz (which according to the manpage currently defaults to xz -6, but in any case, less than -9), which was the context. If you look at https://quixdb.github.io/squash-benchmark/ , wherever a higher compression level actually compresses better (e.g., on the enwik8 or mozilla benchmarks), xz gets slower to compress, but faster to decompress with increasing compression level. (Though if the maximum compression ratio is reached before -9, as on ooffice, decompression will actually get slower again with higher levels. The speedup comes from having less input to process.) xz at any level will of course still be nowhere near zstd in decompression speed. That is not what I intended to claim (and I thought it is obvious that that is not the correct interpretation), though my message was somewhat ambiguous, and I apologize for that. Kevin Kofler -- ___ 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: Hoping to unorphan package edb
Pekka Oinas via devel wrote: > The package for edb, a GUI debugger application, has been orphaned in > Fedora for many years: https://src.fedoraproject.org/rpms/edb > > I like this application and think it's useful, and would like to see it > unorphaned. I have been building it in COPR at > https://copr.fedorainfracloud.org/coprs/peoinas/edb-debugger/ for some > time and just now updated my packaging configuration there to the newest > version, 1.5.0, released a few days ago (though I am sure my spec files > aren't up to mainline standards). > > Unless some existing maintainer reading this mailing list becomes inspired > to adopt this package, I would be interested in pursuing the packager > sponsoring process in order to adopt or co-maintain this package. I would > like some input, particularly from maintainers experienced in packaging Qt > applications, on if this sounds like a good idea. Given that this has been retired for more than 8 weeks (in fact, for way longer, more than 3 years), it needs a rereview anyway, see: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming So you can mostly just follow the usual process for getting sponsored: submit your specfile for review (but mention in the bug comments that it is a rereview for a retired package) and follow: https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/ until the point where you would request a new dist-git repository to be created. The repository already exists, so in this case, you want instead to request unretirement as per: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming – but please only after you got sponsored and the review request got approved! I hope this helps, Kevin Kofler -- ___ 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: F41 Change Proposal: Change Compose Settings (system-wide)
Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Mar 25, 2024 at 04:50:28PM -0400, Neal Gompa wrote: >> Keep in mind we also want to make the compose process faster too, I >> don't know if it's worth it to spend 20x more time compressing >> repodata when we keep trying to get back hours and minutes in the >> compose time. > > I wanted to write that the compression times are small enough for this not > not matter, but indeed, at the very highest levels, they do become > noticable. 5 minutes? On a process that is run once every 24 hours? While at the same time saving download time for all Fedora users? I fail to see the issue. > $ time xz -k -v > 8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060- filelists.xml > 8e09489af54bbd4ab85470d449f0b0afa4a26fc3eb97c1665c741427bbc8f060- filelists.xml > (1/1) > 100 %44.3 MiB / 862.9 MiB = 0.05133 MiB/s 0:26 > xz -k -v 196.88s user 0.63s system 749% cpu 26.337 total > (This is multithreaded, and gives a compression ratio of 5.14%.) That is not the highest compression level of xz though. Try xz -9, it should be better than zstd. It will take longer to compress, but should actually be FASTER (!) to decompress, which is what really matters. Kevin Kofler -- ___ 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: Obsoleted packages in F40
Miroslav Suchý wrote: > I just upgraded my workstation to F40 and it surprised how many packages > were reported by `remove-retired-packages`. There was lots of orphaned > packages - there is nothing to do about them. But there was lot of > packages that were removed intentionally. See the list at the end of my > email. > > I want to highlight that we have policy for removing policy > > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#complete_removal > which at the end mention adding the package to > https://src.fedoraproject.org/rpms/fedora-obsolete-packages The point of fedora-obsolete-packages is to remove packages that actually BREAK things when they remain installed. Otherwise, the best thing to do is to NOT obsolete those packages. Users might still rely on them. E.g., they might have locally built software that depends on the dropped compatibility libraries. Forcefully obsoleting those will break the locally installed software. Kevin Kofler -- ___ 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: F41 Change Proposal: Change Compose Settings (system-wide)
Daniel Alley wrote: > One more point: createrepo_c uses zstd compression level 10, but the range > goes all the way up to level 22. I would oppose making the default much > computationally heavier than it is currently, but if spending 20x longer > to compress the repo 10% more is desirable to the fedora project, then > createrepo_c could perhaps add a the ability to select a compression > level. > > zstd at high compression levels is very nearly as good at compressing as > xz and sometimes better, while remaining much faster to decompress. -- Considering that compression happens once on the server and downloading and decompression happens many times on many computers, I think we should use the highest possible compression level. By the way, xz also supports stronger parameters than -9 in principle, there is just no preset for it. Kevin Kofler -- ___ 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?
Neal Gompa wrote: > It looks like Redis, Inc. has announced that future versions of Redis > are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a > fork of Redis coming up, we will likely need to remove Redis from > Fedora. > > All I can say is... :( Amazon (AWS) is setting up a BSD-licensed fork, but has not yet decided on the final name: https://github.com/placeholderkv/placeholderkv We will see whether that or redict will get the most attention. Cloud companies like Amazon will probably prefer BSD, whereas contributors worried about another "Redis, Inc." coming up and taking their forked code proprietary too will most likely prefer the LGPL fork (redict) (unless they are unhappy about the use of version 3.0 only of the LGPL by that fork). Kevin Kofler -- ___ 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?
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.) Filed: https://codeberg.org/redict/redict/issues/10 – not holding my breath though… Kevin Kofler -- ___ 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?
Kevin Kofler via devel wrote: > Neal Gompa wrote: >> I think the immediate fix is pulling in redict once it makes its first >> release: https://codeberg.org/redict/redict > > 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.) Also, the discussion under: https://discourse.writefreesoftware.org/t/redis-switches-to-dual-source-available-licensing-model/154 makes it pretty clear that the person behind the fork has no intent to make any compromises on this issue. For the redis executable, I guess this is not a blocking issue, but they also intend to fork the hiredis library (which currently is still BSD- licensed upstream [https://github.com/redis/hiredis]), and there, LGPL 3.0 only would really be a problem in the long run. Kevin Kofler -- ___ 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?
Scott Williams wrote:
> Yeah, I was going to say it depends on the dotnet8 runtime. There are
> containers for it, but that's a lot of extra dependency load.
It is actually already packaged in Fedora:
https://src.fedoraproject.org/rpms/dotnet8.0
But yes, it is bloat.
Kevin Kofler
--
___
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?
Neal Gompa wrote: > I think the immediate fix is pulling in redict once it makes its first > release: https://codeberg.org/redict/redict 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.) Kevin Kofler -- ___ 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
