On Fri, 2024-03-29 at 15:01 -0500, Michael Catanzaro wrote:
> On Fri, Mar 29 2024 at 07:56:49 PM +00:00:00, Richard W.M. Jones
> wrote:
> > secalert are already well aware and have approved the update. Kevin
> > Fenzi, myself and others were working on it late last night :-(
>
> Sorry, I linked
Thanks so much for the concerted effort and handling of this, this stuff isn't
easy.
Would it be wise to revert to the last version that was signed by Lasse Colin
instead or would the impact be too high?
--
___
devel mailing list -- devel@lists.fedorap
On Fri, Mar 29, 2024 at 07:25:56PM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones said:
> > (1) We built 5.6.0 for Fedora 40 & 41. Jia Tan was very insistent in
> > emails that we should update.
>
> So this wasn't just a "hey, new upstream version", this was PUSHED on
> distrib
I'm not pretending these will solve everything, but they should make
attacks a little harder in future.
(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, generat
I tried this command on the default Fedora installation... the TAB Key gave me
this error:
[root@fedora mythcat]# dnf5 search scV: __reassemble_comp_words_by_ref: command
not found
terminate called after throwing an instance of 'std::invalid_argument'
what(): stoi
V: __reassemble_comp_words_by
W dniu 30.03.2024 o 10:37, Richard W.M. Jones pisze:
(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' lookin
> On 30 Mar 2024, at 09:40, Cătălin George Feștilă
> wrote:
>
> [root@fedora mythcat]# dnf5 search scV: __reassemble_comp_words_by_ref:
> command not found
> terminate called after throwing an instance of 'std::invalid_argument'
> what(): stoi
> V: __reassemble_comp_words_by_ref: command no
Hey Richard,
> 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
> defaul
On Sat, Mar 30 2024 at 09:37:44 AM +00:00:00, Richard W.M. Jones
wrote:
In the xz case this wouldn't have been enough, it turns out we would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates. I don't fully understand why that is.
I agree that running autoreconf on our
... maybe it is not completed and gets that error or it has not been tested
finally ...
yes , the development is fast in this moment and is much to do.
you can see I used a kernel for devel :
Linux fedora 6.9.0-0.rc1.20240327git7033999ecd7b.18.fc41.x86_64 #1 SMP
PREEMPT_DYNAMIC Wed
Mar 27 17:29
Richard W.M. Jones wrote on Sat, Mar 30, 2024 at 09:37:44AM +:
> In the xz case this wouldn't have been enough, it turns out we would
> also have to delete m4/build-to-host.m4, which then autoreconf
> regenerates. I don't fully understand why that is.
I'm not 100% sure about the theory, but i
Kevin Kofler via devel kirjoitti 25.3.2024 klo 20.34:
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
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.
>
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 'seria
On Sat, Mar 30, 2024 at 7:54 AM Kevin Kofler via devel
wrote:
>
> 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, generate
On Sat, Mar 30, 2024 at 08:22:06PM +0900, Dominique Martinet wrote:
> > 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
On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel
wrote:
>
> 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-
Once upon a time, Michael Catanzaro said:
> I agree that running autoreconf on our packages makes sense to start
> doing. Still, to avoid this backdoored m4 file, we would have needed
> to stop using release tarballs altogether and switch to using git
> tags directly instead. That would at least f
On 29/03/2024 22.10, Michael Catanzaro wrote:
On Fri, Mar 29 2024 at 08:16:55 PM +00:00:00, Richard W.M. Jones
wrote:
These are the exact builds which were vulnerable. Note the tags are
all empty because Kevin untagged them last night, so you'll probably
need to cross-reference these with bod
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 Fedo
On Sat, Mar 30, 2024 at 8:53 AM Kevin Kofler via devel
wrote:
>
> 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 fo
Kevin Kofler 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
OLD: Fedora-Rawhide-20240329.n.1
NEW: Fedora-Rawhide-20240330.n.0
= SUMMARY =
Added images:2
Dropped images: 4
Added packages: 0
Dropped packages:0
Upgraded packages: 24
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size
OLD: Fedora-40-20240329.n.1
NEW: Fedora-40-20240330.n.0
= SUMMARY =
Added images:1
Dropped images: 2
Added packages: 7
Dropped packages:0
Upgraded packages: 14
Downgraded packages: 0
Size of added packages: 2.20 MiB
Size of dropped packages:0 B
Size of
On Sat, Mar 30, 2024 at 08:23:48AM -0400, Neal Gompa wrote:
> On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel
> wrote:
> > > (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
On Sat, Mar 30 2024 at 12:26:48 PM +00:00:00, Christopher Klooz
wrote:
If I got Rich right, the malicious code is likely to be broken on
F40,
No, that is not correct, as explained by [1] and [2]. We have already
asked Red Hat to investigate and fix the blog post. This is still an
evolving s
On Sat, Mar 30 2024 at 09:45:06 AM -05:00:00, Michael Catanzaro
wrote:
No, that is not correct, as explained by [1] and [2].
I pasted the wrong link for [2]. I meant to paste:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GRMSYVY6AM7OZBGQCQWIKRAF7DEMOKJM/
On Sat, Mar 30, 2024 at 09:09:35AM -0400, 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 is actually a weakness:
On Sat, Mar 30, 2
On Sat, Mar 30, 2024 at 9:38 AM Richard W.M. Jones wrote:
>
> I'm not pretending these will solve everything, but they should make
> attacks a little harder in future.
Thanks for starting the discussion.
A well resourced supply chain attack is probably
not preventable (no matter how many eyes ar
On Sat, Mar 30 2024 at 02:55:21 PM +00:00:00, Zbigniew
Jędrzejewski-Szmek wrote:
CMake for many years fought against pkgconf and pushed people towards
copying those scripts into sources. It is still very common for
projects
using CMake to come with a whole directory of badly written detection
On 30/03/2024 15.45, Michael Catanzaro wrote:
On Sat, Mar 30 2024 at 12:26:48 PM +00:00:00, Christopher Klooz
wrote:
If I got Rich right, the malicious code is likely to be broken on F40,
No, that is not correct, as explained by [1] and [2]. We have already asked Red
Hat to investigate and
On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote:
> Once upon a time, Michael Catanzaro said:
> > I agree that running autoreconf on our packages makes sense to start
> > doing. Still, to avoid this backdoored m4 file, we would have needed
> > to stop using release tarballs altogether a
Tim Landscheidt writes:
A major factor seems to have been the discrepancy between
"the source code" at GitHub & Co. that was probably
scrutinized by many eyes and the shipped, but different
artifact. So one step (as a inter-distribution effort)
could be to continuously automatically compare shi
On Sat, Mar 30, 2024 at 10:02:42AM -0500, Michael Catanzaro wrote:
> On Sat, Mar 30 2024 at 02:55:21 PM +00:00:00, Zbigniew Jędrzejewski-Szmek
> wrote:
> > CMake for many years fought against pkgconf and pushed people towards
> > copying those scripts into sources. It is still very common for proj
On Sat, Mar 30, 2024 at 03:23:55PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote:
> > Once upon a time, Michael Catanzaro said:
> > > I agree that running autoreconf on our packages makes sense to start
> > > doing. Still, to avoid this bac
Dne 30. 03. 24 v 1:25 odp. Chris Adams napsal(a):
Using a signed tarball is ideally better than a git tag (it's an extra
level of author attestation).
In this case signed tarball would not help at all. And git-tag would prevent
this attack.
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and
On Sat, Mar 30, 2024 at 11:47 AM Miroslav Suchý wrote:
>
> Dne 30. 03. 24 v 1:25 odp. Chris Adams napsal(a):
>
> Using a signed tarball is ideally better than a git tag (it's an extra
> level of author attestation).
>
> In this case signed tarball would not help at all. And git-tag would prevent
Kevin Kofler via devel wrote:
> Dominique Martinet wrote:
>> 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 patc
On Sat, Mar 30, 2024 at 11:36 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sat, Mar 30, 2024 at 10:02:42AM -0500, Michael Catanzaro wrote:
> > On Sat, Mar 30 2024 at 02:55:21 PM +00:00:00, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > CMake for many years fought against pkgconf and pushed people t
Dne 30. 03. 24 v 10:37 dop. Richard W.M. Jones napsal(a):
I'm not pretending these will solve everything, but they should make
attacks a little harder in future.
4) Fetch build artifacts before executing tests
https://github.com/rpm-software-management/mock/issues/1352
(3) We should have a "
On Sat, Mar 30, 2024 at 02:44:32PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Mar 30, 2024 at 08:23:48AM -0400, Neal Gompa wrote:
> > On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel
> > wrote:
> > > > (At which point I'd suggest it's probably faster to convert it all to
> > > > mes
On Sat, Mar 30, 2024 at 12:10 PM Richard W.M. Jones wrote:
>
> On Sat, Mar 30, 2024 at 02:44:32PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sat, Mar 30, 2024 at 08:23:48AM -0400, Neal Gompa wrote:
> > > On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel
> > > wrote:
> > > > > (At which
On Sat, Mar 30, 2024 at 11:53:07AM -0400, Neal Gompa wrote:
> On Sat, Mar 30, 2024 at 11:36 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Sat, Mar 30, 2024 at 10:02:42AM -0500, Michael Catanzaro wrote:
> > > On Sat, Mar 30 2024 at 02:55:21 PM +00:00:00, Zbigniew Jędrzejewski-Szmek
> > > wrot
I like the idea of the security path as well, where all packages in that
path have upstream subject to higher security standards (that means
helping them to achieve it as well), and greater defense downstream in
any way possible.
Two things that came to mind I shared in another channel:
* no b
Am 30.03.24 um 15:44 schrieb Zbigniew Jędrzejewski-Szmek:
Meson outclasses CMake in functionality, clarity, and brevity.
I doesn't make sense to consider switching to CMake at this point.
While I do agree on clarity and brevity, I don't on functionality.
Meson doesn't allow you do create your
On Sat, 2024-03-30 at 12:53 +0100, Kevin Kofler via devel wrote:
> 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 i
Hi,
It was sheer luck that the exploit was discovered and major distros haven't yet
included it in their stable releases. It's quite possible and plausible it
could have reached RHEL, Debian, Ubuntu, SLES and other distros and it's almost
reached Fedora 40.
I don't know how to talk to RedHat/I
On Sat, 30 Mar 2024 at 13:26, Artem S. Tashkinov via devel <
devel@lists.fedoraproject.org> wrote:
>
> I propose this issue to be tackled in a centralized way by the
> collaboration of major distros.
>
> There must be a website or a central authority which includes known to be
> good/safe/verified
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).
It appears that libsystemd links to libraries for lzma/xz, bzip2, gzip and also
zstd, because some systemd utilities provide them as options in various
different contexts (but not consistently, zstd for instance is seemingly
supported by some utilities and not by others, and I see some code such
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 har
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 s
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
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 pkg
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 softwa
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
On Sat, Mar 30, 2024 at 05:59:36PM -, Daniel Alley wrote:
> It appears that libsystemd links to libraries for lzma/xz, bzip2, gzip and
> also zstd, because some systemd utilities provide them as options in various
> different contexts (but not consistently, zstd for instance is seemingly
> s
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
On Sat, Mar 30, 2024 at 1:07 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> > 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
On Sat, Mar 30, 2024 at 09:20:28AM -0700, Carlos Rodriguez-Fernandez wrote:
> I like the idea of the security path as well, where all packages in that
> path have upstream subject to higher security standards (that means helping
> them to achieve it as well), and greater defense downstream in any w
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, dh
Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> Here, OTOH, I'd just say that the tarball generated from a git clone
> should be bit-identical to the tar.gz pulled in by the spec.
That might change with zlib-ng... expecting compressed data to match is
probably not a reasonable expectation,
On 30-03-2024 13:26, Christopher Klooz wrote:
I don't know how the assumption came up that F40 is only affected if
users opted in for testing, but that interpretation already ended up in
the Fedora Magazine and in the official linkedin post of Fedora (I
already asked to correct it).
I believe
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
regarding sabotaged Landlock sandbox
https://mastodon.social/@dander...@hachyderm.io/112185746170709381
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I'm not sure my proposal has been understood at all.
This website/authority is a sort of advisory board where each member's
participation is 100% voluntary and distros are free to **ignore** it
altogether.
What this website will contain is just a nice list of vetted open source
packages, versi
Am 30.03.24 um 20:11 schrieb Kevin Kofler via devel:
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
This approach
> let's delete autoconf-generated cruft from upstream projects and regenerate
> it in %prep
To me sounds woefully inappropriate for the task at hand. You remove a single
attack vector while completely overlooking that many of your maintainers don't
have the qualifications to vet
Dear Kevin,
On Sat, Mar 30, 2024 at 8:12 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> 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 w
Hi Artem,
I disagree that the idea is not appropriate. Ensuring that the tar.gz
you are getting is exactly what it is in the git repo reduces a lot of
risk. So, it makes a lot of sense to get rid of the practice of
distributing tar.gz with pregenerated build scripts not present in the
git rep
On Sat, 30 Mar 2024 at 15:29, Artem S. Tashkinov via devel <
devel@lists.fedoraproject.org> wrote:
> I'm not sure my proposal has been understood at all.
>
>
Probably not.. proposals like this need to be thought about, reviewed and
thought about. Some people who like to say NO to various things wi
On 2024-03-30 02:37, Richard W.M. Jones wrote:
(3) We should have a "security path", like "critical path".
sshd is linked to a lot of libraries:
I really don't want to start a systemd thread, but... the xz, lz4, and
zstd libraries are pulled in by libsystemd, merely so that sshd can call
"s
Otto Liljalaakso kirjoitti 30.3.2024 klo 13.41:
Kevin Kofler via devel kirjoitti 25.3.2024 klo 20.34:
Miroslav Suchý wrote:
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
It's not how free software works, but there are some interesting projects
working on (distributed, not centrally managed) code review systems that are
kind of similar in spirit to what OP describes.
https://github.com/crev-dev/crev
https://github.com/crev-dev/cargo-crev
https://mozilla.github.io
On Sat, Mar 30, 2024 at 07:28:43PM +0100, Kevin Kofler via devel wrote:
> 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
On 30/03/2024 20.08, Sandro wrote:
On 30-03-2024 13:26, Christopher Klooz wrote:
I don't know how the assumption came up that F40 is only affected if users
opted in for testing, but that interpretation already ended up in the Fedora
Magazine and in the official linkedin post of Fedora (I alrea
On Sat, Mar 30, 2024 at 08:00:29PM +0100, Kevin Kofler via devel wrote:
> 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
It was unreasonable before zlib-ng too [0], but zlib-ng does make it a slightly
bigger issue.
[0] https://github.com/rpm-software-management/createrepo_c/pull/336
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Sat, Mar 30, 2024 at 08:51:03PM +0100, Dmitry Belyavskiy wrote:
> Dear Kevin,
>
> On Sat, Mar 30, 2024 at 8:12 PM Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
> > Miroslav Suchý wrote:
> > > 4) Fetch build artifacts before executing tests
> > >
> > > https://github.com/rp
Once upon a time, Kevin Kofler said:
> Unit tests are something for upstream developers. They should NEVER be run
> in a distribution build.
Upstream developers aren't testing in every Fedora release (which
whatever the current compiler+library+app combo is), so unit tests
should always be run w
For some time, I have been maintaining python-jose[1] since it is a
minor test dependency for python-fastapi. While the Fedora package for
python-jose is in good condition, the project has been unmaintained
upstream for some time[2][3].
I have just chosen to skip the FastAPI tests that require
On Sat, Mar 30, 2024 at 06:58:05PM +0100, Kevin Kofler via devel wrote:
> 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
On Sat, Mar 30, 2024 at 04:30:53PM -0500, Chris Adams wrote:
> Once upon a time, Kevin Kofler said:
> > Unit tests are something for upstream developers. They should NEVER be run
> > in a distribution build.
>
> Upstream developers aren't testing in every Fedora release (which
> whatever the cur
On 30-03-2024 22:10, Christopher Klooz wrote:
On 30/03/2024 20.08, Sandro wrote:
On 30-03-2024 13:26, Christopher Klooz wrote:
I don't know how the assumption came up that F40 is only affected if
users opted in for testing, but that interpretation already ended up
in the Fedora Magazine and in
On Sat, Mar 30, 2024 at 06:56:27PM +0100, Kevin Kofler via devel wrote:
> 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
Il 30/03/24 23:12, Sandro ha scritto:
From what I understood, F40 Beta, the official Beta release, available
from the website as of March 26, has updates-testing disabled by
default. That was confirmed by several people in #devel yesterday when
the Fedora Magazine article was still being worked
On Sat, Mar 30, 2024 at 09:07:19PM -, Daniel Alley wrote:
> It's not how free software works, but there are some interesting projects
> working on (distributed, not centrally managed) code review systems that are
> kind of similar in spirit to what OP describes.
>
> https://github.com/crev-d
On Sat, Mar 30, 2024 at 11:12:02PM +0100, Sandro wrote:
>
> From what I understood, F40 Beta, the official Beta release, available from
> the website as of March 26, has updates-testing disabled by default. That
Nope.
> was confirmed by several people in #devel yesterday when the Fedora Magazin
> >>> I don't know how the assumption came up that F40 is only affected if
> >>> users opted in for testing, but that interpretation already ended up
> >>> in the Fedora Magazine and in the official linkedin post of Fedora (I
> >>> already asked to correct it).
> >>
> >> I believe that statement is
89 matches
Mail list logo
