> >>> 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
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
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.
>
>
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
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
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
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
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
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
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
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
> > >
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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,
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,
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
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
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
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
>
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
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
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
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
>
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
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
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
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
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
>
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
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
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
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
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
> > >
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
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
> > > >
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 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
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
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
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
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
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
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
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
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
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 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
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,
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:
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
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
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
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
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
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
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
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
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
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:
> > #
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
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,
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
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.
>
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 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
... 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
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
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
>
> 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
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'
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:
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,
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
>
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 --
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
89 matches
Mail list logo
