>> 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" developers, some that nobody knows in person, vis-à-vis "many" developers on a big project.
For me it's most important when the project is on a Distro critical- or security-path.
Cheers!
On Thursday, April 4th, 2024 at 9:41 AM, Steve Cossette <farchord@xxxxxxxxx> wrote:
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 FOSS for that matter.I'd say keep using XZ if the maintainers are quick to fix issues and quick to respond to the community's issues, this one for example. Everyone does mistakes. It's fine as long as we learn from them.On Thu, Apr 4, 2024 at 9:26 AM Arnie T via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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.
I got to the Fedora Magazine article and wasn't really clear on that.
So I followed the discussion to this thread in this Development mailing list.
I read a lot of it but _still_ can't 100% figure out what the final solution is going to be.
I have a question about that.
I'm for sure OK that a responsibly developed FOSS project can contribute value and should be welcomed.
ISTM that if a package is used on critical-path or security-path by default in a Distro it needs a higher bar.
IIUC from this thread and online discussions about XZ & alternatives that
1] Lack of committer 'Real' identity confidence and verification is a problem.
2] Undetected differences source + packaging in repo vs tarballs are unchecked.
3] Under-resourced development creates risk; 'Many eyes' bench depth in development is needed.
4] XZ has a single, unsupported committer.
5] ZSTD is developed & used at Facebook.
6] ZSTD matches or outperforms XZ and most other compression in most metrics.
7] ZSTD is already used for default compression by Distros.
I get that there's never going to be 100% perfect solution.
But wouldnt' switching Fedora from using XZ to ZSTD by default fix a lot of the uncertainty around at least this current issue?
Is that being considered in Fedora?
Or is the focus trying to fix XZ to continue to use it?
Thanks for any help to understand all this :-)
Cheers!
Arnie
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
