Good point. Check testing it is actually expected unix socket would be
quite nice. Especially when the file sd-daemon.c implements
sd_is_socket_unix function, but never uses it itself. libsystemd
verifies this using socket_address_parse_unix or
socket_address_parse_vsock in
On Di, 02.04.24 19:44, Petr Menšík (pemen...@redhat.com) wrote:
> Function pid_notify_with_fds_internal from
> ./src/libsystemd/sd-daemon/sd-daemon.c certainly is not just few lines, as
> suggested. Should I ask why, if not necessary?
The version in sd-daemon.c is a bit more complex because it
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
On 02. 04. 24 14:17, Lennart Poettering wrote:
On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote:
I am not convinced dlopen will it make secure in the end. I am not sure this
is a good solution. dlopen makes those dependencies non-obvious from
packaging side and non-visible from
On Tue, 2 Apr 2024 at 08:18, Lennart Poettering
wrote:
> On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote:
>
>
> > Could be even smaller library libsystemd-notify linked from libsystemd,
> > which would allow end applications to explicitly declare they need more
> > limited set of
On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote:
> I am not convinced dlopen will it make secure in the end. I am not sure this
> is a good solution. dlopen makes those dependencies non-obvious from
> packaging side and non-visible from ldd or similar checking programs.
>
> I think
I am not convinced dlopen will it make secure in the end. I am not sure
this is a good solution. dlopen makes those dependencies non-obvious
from packaging side and non-visible from ldd or similar checking programs.
I think it should be considered to offer more than one dynamic library.
For
On Mon, Apr 1, 2024 at 9:17 PM Matthew Miller wrote:
>
> On Mon, Apr 01, 2024 at 05:47:10PM +, Gary Buhrmaster wrote:
> > It does bring up a potential point that perhaps
> > Fedora should have an additional repo (let's
> > call it "emergency fixes") that is not community
> > mirrored (so any
On Mon, Apr 01, 2024 at 05:47:10PM +, Gary Buhrmaster wrote:
> It does bring up a potential point that perhaps
> Fedora should have an additional repo (let's
> call it "emergency fixes") that is not community
> mirrored (so any mirrors for load sharing
> would be fully controlled by the
On Mon, Apr 1 2024 at 10:25:16 AM -07:00:00, Adam Williamson
wrote:
Oh, ISWYM. Well, I suppose yes, that does happen to be true. We could
communicate that if it's done very carefully and made really clear
that
it's about the *time frame*, nothing to do with the repositories.
It's been
On 01-04-2024 19:12, Adam Williamson wrote:
On Mon, 2024-04-01 at 09:32 -0500, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz
wrote:
"Fedora Linux 40 branched users (i.e. pre-Beta) likely received the
potentially vulnerable 5.6.0-2.fc40 build if the
On Mon, Apr 1, 2024 at 5:27 PM Kevin Fenzi wrote:
> Yes. The downgrade was pushed out on friday along with the f40 one.
Of course, your mirror may vary as to availability
(as I recall, in my particular case, my test VM
for rawhide did not get the update for a day
or so).
It does bring up a
On 01/04/2024 19.27, Kevin Fenzi wrote:
On Mon, Apr 01, 2024 at 05:07:13PM +, Christopher Klooz wrote:
On 31/03/2024 23.08, Kevin Fenzi wrote:
On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:
Not sure, if it was already mentioned -> containers. I had here a toolbox
On Mon, Apr 01, 2024 at 05:07:13PM +, Christopher Klooz wrote:
>
> On 31/03/2024 23.08, Kevin Fenzi wrote:
> > On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:
> > > Not sure, if it was already mentioned -> containers. I had here a toolbox
> > > environment with F40.
On Mon, 2024-04-01 at 12:16 -0500, Michael Catanzaro wrote:
> On Mon, Apr 1 2024 at 10:12:55 AM -07:00:00, Adam Williamson
> wrote:
> > This is not really correct, or at least at all relevant. The bug
> > wasn't
> > in F40 Beta simply because the update never made it to 'stable'. Only
> >
On Mon, Apr 1 2024 at 10:12:55 AM -07:00:00, Adam Williamson
wrote:
This is not really correct, or at least at all relevant. The bug
wasn't
in F40 Beta simply because the update never made it to 'stable'. Only
'stable' packages go into *composes*. However, saying that is not
really useful
On Mon, 2024-04-01 at 09:32 -0500, Michael Catanzaro wrote:
> On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz
> wrote:
> > "Fedora Linux 40 branched users (i.e. pre-Beta) likely received the
> > potentially vulnerable 5.6.0-2.fc40 build if the system updated
> > between March
On 31/03/2024 23.08, Kevin Fenzi wrote:
On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:
Not sure, if it was already mentioned -> containers. I had here a toolbox
environment with F40. That I had not in my first actions
on the screen. The last state had 5.6.0-3 installed
On 01/04/2024 16.32, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz
wrote:
"Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially
vulnerable 5.6.0-2.fc40 build if the system updated between March 2nd and March 6th.
Fedora
On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz
wrote:
"Fedora Linux 40 branched users (i.e. pre-Beta) likely received the
potentially vulnerable 5.6.0-2.fc40 build if the system updated
between March 2nd and March 6th. Fedora Linux 40 Beta users only
using stable repositories
On 31/03/2024 21.33, Sandro wrote:
On 31-03-2024 20:54, Christopher Klooz wrote:
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication
On 31/03/2024 23.11, Kevin Fenzi wrote:
On Sun, Mar 31, 2024 at 08:55:37PM +, Christopher Klooz wrote:
The repo files should be the same on Fedora containers, so if the container is
F40 and the testing repo is enabled, it might have installed the malicious
build.
Right, if it was dnf
On Sun, Mar 31, 2024 at 08:55:37PM +, Christopher Klooz wrote:
> The repo files should be the same on Fedora containers, so if the container
> is F40 and the testing repo is enabled, it might have installed the malicious
> build.
Right, if it was dnf updated during the time that the bad
On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:
>
> Not sure, if it was already mentioned -> containers. I had here a toolbox
> environment with F40. That I had not in my first actions
> on the screen. The last state had 5.6.0-3 installed but not sure
> if the previous
On Sun, Mar 31, 2024 at 03:52:12PM -0500, Alex Thomas wrote:
> Just to be clear, as I was getting ready to put 40 Beta on a test
> machine, this has been fixed. I do the install and run updates and the
> compromised version of xz is never installed?
Correct.
kevin
signature.asc
Description:
On 31/03/2024 22.30, Leon Fauster via devel wrote:
Am 31.03.24 um 21:33 schrieb Sandro:
On 31-03-2024 20:54, Christopher Klooz wrote:
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
Just to be clear, as I was getting ready to put 40 Beta on a test
machine, this has been fixed. I do the install and run updates and the
compromised version of xz is never installed?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To
Am 31.03.24 um 21:33 schrieb Sandro:
On 31-03-2024 20:54, Christopher Klooz wrote:
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication
On 31-03-2024 20:54, Christopher Klooz wrote:
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication regarding this issue.
Does anybody
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication regarding this issue. Does anybody
know who can fix this?
The Fedora Magazine
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication regarding this issue. Does anybody
know who can fix this?
The Fedora Magazine article has been fixed (thanks!).
"*Fedora
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication regarding this issue.
Does anybody know who can fix this?
The Fedora Magazine article has been fixed (thanks!).
--
___
devel mailing
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
--
On 31/03/2024 16.56, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 12:55:23 PM +00:00:00, Christopher Klooz
wrote:
In case someone from the Fedora Magazine is in the devel mailing list and reads
this:
I'm really frustrated with our communication regarding this issue. Does anybody
know
On Sun, Mar 31 2024 at 07:15:42 AM -04:00:00, Neal Gompa
wrote:
Well, an easy solution is to make it so "dnf update" is coerced to
"dnf distro-sync" for development releases. Then it doesn't matter. We
could make that happen for Fedora 41 with the DNF 5 transition
(there's already code to make
On Sun, Mar 31 2024 at 12:55:23 PM +00:00:00, Christopher Klooz
wrote:
In case someone from the Fedora Magazine is in the devel mailing list
and reads this:
I'm really frustrated with our communication regarding this issue. Does
anybody know who can fix this?
If we don't know who can fix
On Sun, 31 Mar 2024 at 13:55, Christopher Klooz wrote:
[..]
BTW all that scandal with xz backdoor.
Looks like if fedora spec file would be using not
Source0:
https://github.com/tukaani-project/%{name}/releases/download/v%{version}/%{name}-%{version}.tar.gz
but
Source0:
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 Sun, Mar 31, 2024 at 6:50 AM Kevin Kofler via devel
wrote:
>
> 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
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
On 31-03-2024 00:41, Kevin Fenzi wrote:
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
On Sat, 2024-03-30 at 16:41 -0700, Kevin Fenzi wrote:
> 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
> >>> 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
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 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 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
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
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
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
>
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
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 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 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
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
This might be a good place to start
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1936
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
More about this is now published on the Fedora Magazine as well in this
statement:
https://fedoramagazine.org/cve-2024-3094-security-alert-f40-rawhide/
Thank you to all of our Fedora first responders who stopped something that
could have been much worse. We should feel proud here. As far as
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
distributions by the culprit. Are they a contributor to any other
software in
There is a chance Fedora is not affected according to the following
analysis:
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Quoting:
=
If those conditions check, the payload is injected into the source tree. We
have not analyzed this payload in detail. Here are the main
On Fri, Mar 29, 2024 at 04:46:54PM -0500, Michael Catanzaro wrote:
> On Fri, Mar 29 2024 at 04:10:53 PM -05:00:00, Michael Catanzaro
> wrote:
> >OK, I am going to ask Product Security to edit their blog post to
> >remove the incorrect information. I will CC you on that request.
>
> Or maybe I
On Fri, Mar 29 2024 at 04:10:53 PM -05:00:00, Michael Catanzaro
wrote:
OK, I am going to ask Product Security to edit their blog post to
remove the incorrect information. I will CC you on that request.
Or maybe I should rephrase this as a "request for clarification,"
because maybe they know
Please add “Fedora ELN” as well. We have updates ready that should be
composed by midnight tonight, but it should be mentioned in the
announcements.
On Fri, Mar 29, 2024 at 5:11 PM Michael Catanzaro
wrote:
> On Fri, Mar 29 2024 at 08:16:55 PM +00:00:00, Richard W.M. Jones
> wrote:
> > These
On Fri, Mar 29 2024 at 08:16:55 PM +00:00:00, Richard W.M. Jones
wrote:
These are the exact builds which were vulnerable. Note the tags are
all empty because Kevin untagged them last night, so you'll probably
need to cross-reference these with bodhi updates.
OK, I am going to ask Product
On 29/03/2024 21.01, Richard W.M. Jones wrote:
On Fri, Mar 29, 2024 at 06:46:59PM +, Christopher Klooz wrote:
Yes, F40 beta is affected, along with rawhide, but not F38/F39.
Michael Catanzaro wrote:
> On Fri, Mar 29 2024 at 07:44:12 PM +01:00:00, Mikel Olasagasti
> wrote:
> > Do we know if GH release tarballs are safe?
>
> The tarballs generated by GitHub that just include the contents of the
> git repo should be safe (at least from this particular issue),
So
Mikel Olasagasti wrote:
> For whatever reason Source for xz was changed 2 months ago[1] to use
> GH releases instead of tukaani.org site.
The public key jia_tan_pubkey.txt did not change at the same time. It
was introduced on 2023-05-04 when the package was updated to version
5.4.3. Apparently
Once upon a time, Richard W.M. Jones said:
> On Fri, Mar 29, 2024 at 07:44:12PM +0100, Mikel Olasagasti wrote:
> > Do we know if GH release tarballs are safe?
> > @richard, do you remember why you had to change the source for the tarball?
>
> Sadly the release tarballs we used *do* contain the
On Fri, Mar 29, 2024 at 07:44:12PM +0100, Mikel Olasagasti wrote:
> Hi,
>
> I'm seeing weird things.
>
> For whatever reason Source for xz was changed 2 months ago[1] to use
> GH releases instead of tukaani.org site.
>
> The XZ page[2] has a note stating:
>
> "Note: GitHub automatically
On Fri, Mar 29, 2024 at 03:01:34PM -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
It would be interesting to study how SELinux would have reacted to such
kind of attack against sshd
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Fri, Mar 29 2024 at 07:44:12 PM +01:00:00, Mikel Olasagasti
wrote:
Do we know if GH release tarballs are safe?
The tarballs generated by GitHub that just include the contents of the
git repo should be safe (at least from this particular issue), but the
Fedora package is not built from
On Fri, Mar 29 2024 at 07:56:49 PM +00:00:00, Richard W.M. Jones
wrote:
secalert are already well aware and have approved the update. Kevin
Fenzi, myself and others were working on it late last night :-(
Sorry, I linked to the wrong article. I meant to link to [1] which says
that "At this
On Fri, Mar 29, 2024 at 06:46:59PM +, Christopher Klooz wrote:
> Yes, F40 beta is affected, along with rawhide, but not F38/F39.
>
>
On Fri, Mar 29, 2024 at 02:40:48PM -0500, Michael Catanzaro wrote:
> On Fri, Mar 29 2024 at 06:46:59 PM +00:00:00, Christopher Klooz
> wrote:
> >Yes, F40 beta is affected, along with rawhide, but not F38/F39.
>
> Unless I'm misunderstanding something, it looks xz-5.6.0-1.fc40 and
> 5.6.0-2.fc40
On Fri, Mar 29 2024 at 06:46:59 PM +00:00:00, Christopher Klooz
wrote:
Yes, F40 beta is affected, along with rawhide, but not F38/F39.
Unless I'm misunderstanding something, it looks xz-5.6.0-1.fc40 and
5.6.0-2.fc40 are backdoored, yes? Then rjones unknowingly broke the
backdoor in two
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 --
Yes, F40 beta is affected, along with rawhide, but not F38/F39.
https://discussion.fedoraproject.org/t/warning-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683
Hi,
I'm seeing weird things.
For whatever reason Source for xz was changed 2 months ago[1] to use
GH releases instead of tukaani.org site.
The XZ page[2] has a note stating:
"Note: GitHub automatically includes two archives Source code (zip)
and Source code (tar.gz) in the releases. These
Has this shipped on f40 beta?
Barry
> On 29 Mar 2024, at 18:08, Richard W.M. Jones wrote:
>
>
>> On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote:
>> Hi,
>>
>> wow: https://www.openwall.com/lists/oss-security/2024/
>>
>> I think at this point we clearly cannot trust
On Fri, Mar 29, 2024 at 12:08 PM Richard W.M. Jones wrote:
> On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote:
> > Hi,
> >
> > wow: https://www.openwall.com/lists/oss-security/2024/
> >
> > I think at this point we clearly cannot trust xz upstream anymore and should
> >
On Fri, Mar 29, 2024 at 2:08 PM Richard W.M. Jones wrote:
>
>
> On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote:
> > Hi,
> >
> > wow: https://www.openwall.com/lists/oss-security/2024/
> >
> > I think at this point we clearly cannot trust xz upstream anymore and should
> >
On 3/29/24 11:00, Kevin Kofler via devel wrote:
wow: https://www.openwall.com/lists/oss-security/2024/
Specifically:
https://www.openwall.com/lists/oss-security/2024/03/29/4
I think at this point we clearly cannot trust xz upstream anymore and should
probably fork the project.
--
On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote:
> 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.
I kind of agree here, though it saddens me to
That would be a bit premature. At this point it looks like one bad actor,
and the other maintainer probably wasn't even aware. We should wait and
see how this plays out.
On Fri, Mar 29, 2024 at 1:01 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> Hi,
>
> wow:
87 matches
Mail list logo
