>[1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379
> .
>If that was part of zstd or even actively being looked at, then yes.
I mean, per your own comment on that thread, the API *is* available and it's in
zstd, but no frontend supports it yet.
And per the maintainer's
On Thu, 04 Apr 2024 13:51:59 +, Arnie T via devel wrote:
> The 'basic issue' I see is the "one or two" developers, some that nobody
> knows in person, vis-à-vis "many" developers on a big project.
>
The same sort of a secret agent's infiltration attack on a project would
also be possible
Hi!
+1
The sequence must be: measure -> think -> act.
Not:
act (in panic) ->
think (oh, that ist not the correct way, or even worse: oh, this is the
way the attacker wants us to go.)
measure (we have a weakness)
Best regards
Christoph
Am 04.04.24 um 20:11 schrieb Leon Fauster via devel:
One
On Thu, Apr 04, 2024 at 08:11:42PM +0200, Leon Fauster via devel wrote:
>
> One approach that would be at least bring some light into "weak"
> (non technical layer) components (albeit not sure how feasible it is),
> could be:
>
> - Checking the resources of a packaged project.
>Resources in
On Thu, Apr 4, 2024 at 8:00 PM Arnie T via devel
wrote:
>
> Hello Kevin,
>
> > I'm hopeful some things will come out of this as it's a chance for us to
> > look at our processes and improve them.
>
> I'm glad that's happening. It seems to me that improving those processes
> would be Distro
Am 04.04.24 um 19:23 schrieb Kevin Fenzi:
On Thu, Apr 04, 2024 at 01:26:14PM +, Arnie T via devel wrote:
Hi,
I just installed Fedora on 2 of my PCs a couple of weeks ago. One version of
Fedora 39 release and one of Fedora 40 to see where things are going.
I learned about this XZ-hack
Hello Kevin,
> I'm hopeful some things will come out of this as it's a chance for us to
> look at our processes and improve them.
I'm glad that's happening. It seems to me that improving those processes would
be Distro decisions. Which I keep understanding don't really exist. At least
not
Hi Guinevere,
> TL;DR: as with most security issues, end users should update their systems.
>
> I think you may be caught in some news exaggeration. Don't get me wrong, this
> hack was a huge thing, but it was discovered early enough that most (i'd
> guess almost all) fedora users wont' have to
On Thu, Apr 04, 2024 at 05:04:20PM +, Arnie T via devel wrote:
> Hi Stephen,
>
> Thanks for the explanation.
>
> I just caught up with the article at the New York Times,
>
> Did One Guy Just Stop a Huge Cyberattack?
>
On 4/4/24 14:04, Arnie T via devel wrote:
Hi Stephen,
Thanks for the explanation.
I just caught up with the article at the New York Times,
Did One Guy Just Stop a Huge Cyberattack?
https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html
And the comic that looks like it
On Thu, Apr 04, 2024 at 01:26:14PM +, Arnie T via devel wrote:
> Hi,
>
> I just installed Fedora on 2 of my PCs a couple of weeks ago. One version of
> Fedora 39 release and one of Fedora 40 to see where things are going.
>
> I learned about this XZ-hack from Ars Technica & The Economist.
Hi Stephen,
Thanks for the explanation.
I just caught up with the article at the New York Times,
Did One Guy Just Stop a Huge Cyberattack?
https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html
And the comic that looks like it fits the problem I'm most noticing here!
Once upon a time, Simon Farnsworth said:
> Fedora made the same switch back in Fedora 31, and thus doesn't need to do
> anything about package compression right now.
About this... I was looking at RPMs and found there are a couple of
packages that override _binary_payload in the SPEC to use xz:
On Thursday, 4 April 2024 17:20:25 BST Arnie T via devel wrote:
> Hello Stephen,
>
> > How a decision to drop xz for some other compression library for software
> > would be a fairly slow process. First a person who is willing to do the
> > work would come up with a proposal on why it should be
On Thu, 4 Apr 2024 at 12:21, Arnie T via devel <
devel@lists.fedoraproject.org> wrote:
> Hello Stephen,
>
> How a decision to drop xz for some other compression library for software
> would be a fairly slow process. First a person who is willing to do the
> work would come up with a proposal on
Hello Stephen,
> How a decision to drop xz for some other compression library for software
> would be a fairly slow process. First a person who is willing to do the work
> would come up with a proposal on why it should be done and how it could be
> done. They would be expected to also test to
On Thu, 4 Apr 2024 at 11:22, Arnie T via devel <
devel@lists.fedoraproject.org> wrote:
>
> Hi,
>
> > There's no such thing as a "distro decision" on this one, as was
> > explained in the thread already.
>
> I'm sure the 'explanation' is all clear to you and the other Developers.
>
> I'm also sure
Hi,
> There's no such thing as a "distro decision" on this one, as was
> explained in the thread already.
I'm sure the 'explanation' is all clear to you and the other Developers.
I'm also sure that it's not all that clear to non-Developers.
If the explanation was clear and obvious to me, here
On Thu, Apr 04, 2024 at 02:40:08PM +, Arnie T via devel wrote:
> Hello Rich,
>
> > There's also the issue that liblzma is widely used and offers specific
> > features which zstd does not[1].
> >
> > [1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379
>
> Is that about
Hello Rich,
> There's also the issue that liblzma is widely used and offers specific
> features which zstd does not[1].
>
> [1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379
Is that about this?
https://github.com/facebook/zstd/tree/dev/contrib/seekable_format
From a
On Thu, Apr 04, 2024 at 01:45:45PM -, Daniel Alley wrote:
> As long as there are existing xz-compressed files in the wild,
> Fedora will need to support consuming them - as long as there is
> software that expects xz compression, Fedora will need to support
> creating them. It's not going to
Hi,
> See also an upstream GNU discussion on whether more GNU packages
> should start providing zstd, or even lzip, tarballs in addition to xz:
> https://lists.gnu.org/archive/html/bug-standards/2024-04/msg00032.html
I'm sure not going to tell any developers here something they don't know! But
Hi Daniel,
>> All that being said, there are plenty of bits of software that could start
>> using zstd by default and it would probably make sense to do so.
I know this isn't the best test but just looking at
locate xz | grep xz$ | grep kernel.*xz$ | wc -l
13206
ISTM there's a log of .xz
On Thu, Apr 04, 2024 at 01:45:45PM -, Daniel Alley wrote:
> It's not possible to simply substitute one for another universally, there's
> no "Fedora default", it's something that would need to be handled on a
> package-by-package basis.
>
> As long as there are existing xz-compressed files
Hi Steve,
>> Who's to say that one doesn't have the same basic issue? Same with any other
>> project in FOSS for that matter.
That's the idea I was trying to make. There are no guarantees are there? But
you can minimize the social problems.
The 'basic issue' I see is the "one or two"
It's not possible to simply substitute one for another universally, there's no
"Fedora default", it's something that would need to be handled on a
package-by-package basis.
As long as there are existing xz-compressed files in the wild, Fedora will need
to support consuming them - as long as
I have definitely not read 75% of the comments and articles about the xz
issues but I understand the general reason why this happened.
Issue here is, let's say we do switch to an alternative, whatever it is.
Who's to say that one doesn't have the same basic issue? Same with any
other project in
Hi,
I just installed Fedora on 2 of my PCs a couple of weeks ago. One version of
Fedora 39 release and one of Fedora 40 to see where things are going.
I learned about this XZ-hack from Ars Technica & The Economist.
I got to the Fedora Magazine article and wasn't really clear on that.
So I
28 matches
Mail list logo
