Re: xz backdoor
> >>> 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 correct, since none of the xz-5.6.x > >> packages ever made it to F40 stable. The furthest they've got was > >> updates-testing, which is not enabled in the official Beta releases. The updates-testing repo isn't used in the Beta compose but it is enabled by default so if someone took the beta and then applied updates they would have automatically got the compromised package, there's nuance there. > >> However, if you installed F40 before Beta was released, then > >> updates-testing is enabled and users may have installed the vulnerable > >> package with a simple `sudo dnf upgrade`. The same would be the case if they installed Beta. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 Magazine > article was still being worked on. I am pretty sure I said the opposite... nirik: 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 nirik: yes, we disable updates-testing by default right before release. I guess that could have been read as right before beta release, but thats not the case or what I meant. ;) It's before _Final_ release that we disable updates-testing. It's enabled by default from when we branch the release off until the time right before release when we switch it (usually with a freeze break/blocker bug) > It's the RC composes that are made after branching and before Beta is > declared GO, that have updates-testing enabled by default. I was one of the > persons raising that point. I'm less certain wrt upgrades in the period > between branching and Beta release. I think the confusion here is "Beta Release" vs "Final release". We enable updates-testing at branching time all the way until right before "Final release". :) > If that is incorrect and Beta shipped with updates-testing enabled, > deliberately or by accident, then I stand corrected. Yes, it did/does. :) The logic is that most people who install betas or pre-releases want to help test updates. If for some reason they don't, they can disable it, but the default option is on. > > It is obviously still an issue that is evolving and what seems clear now > > might prove different later. But so far I tend to leave the discussion > > topic as it is and ensure that F40 users expect being compromised and > > get informed to act correspondingly with the suggested actions. However, > > I already added a point how users can check if they have a malicious > > build. > > I agree. Once the levees broke, news was traveling fast and, for some, panic > may have set in, not helping in determining what information is accurate. > > Advise to err on the side of caution, check your system and upgrade if > unsure, is certainly what I would tell anyone. Even distros (Arch, Gentoo) > where it turned out the payload wasn't injected, acted out of an abundance > of caution, put out advisories and updates for their users. > > What's written on Discussion looks to be covering the broad spectrum. Maybe > the Fedora Magazine article could link to that post for further > clarification. Yeah, still lots to know about this... kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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-dev/crev > https://github.com/crev-dev/cargo-crev > https://mozilla.github.io/cargo-vet/ > > That is, individuals and organizations can publish the results of their code > audits publicly in a standardized format, tied to a package artifact, and a > downstream consumer could denote which individuals and organizations they > trust to perform said audits. > > It's technically possible and not an entirely ridiculous idea, it's just > economically challenging. How do you find enough people willing and able to > audit a package (including e.g. autotools build scripts), in multiple, to the > level of scrutiny that would be required to catch something like this. I think such cross-checks already happen in practice. When distro packages are updated, maintainers will do _some_ review. We can't force them to full reviews every time, and it wouldn't even make sense, but we can be certain that if anything malicious is found, notifications too the other distros will go out immediately. Or to put in a different way: if distribution publishes a package, we implicitly know that they did the review of that package in that version to the level they consider acceptable. We if asked them to make an additional signature, it wouldn't add much. As a maintainer, the level of review I do for updates varies a lot: for some upstreams I'll do a patch-by-patch review and maybe use diffoscope to see what changed in the internals, for some upstreams I'll scan the NEWS file, and for other upstreams I'll not even do that, if I know what is hapenning in the project and I trust the quality and integrity. If there was a "task force" auditing packages, I think it should apply some variant of that rule: focus on packages which are a) important, b) have few maintainers, c) have lots of ugly internals, d) raise suspicion for whatever other reason. This would probably yield better results then trying to apply the same level of scrutiny accross the board. -- That said, one useful variant of the auditing proposal would be to check that different distributions actually have the same source tarballs, for the same versions of the same packages. This is something that could scripted and occasionally executed. It'd be very suspicious if it turned out that the "upstream tarball" differs in Fedora or Arch or Debian or Suse or any other distro. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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. I updated ~3 days ago from F39 to F40 and I got *-testing repositories enabled -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 want, > because you can just invoke a shell script or any other external command). > CMake is completely extensible with a complete programming language (it is > Turing-complete if and only if you use recursive functions; if you avoid > FUNCTION or at least recursive ones, then it is guaranteed to always > terminate and still usually expressive enough, but Turing-completeness > through recursion is there if you really need it). Pretty much every build system is Turing-complete, and pretty much every build system allows scripts to be called. Upstreams can do crazy stuff with any build system too. I think Meson hits the sweet spot where simple projects can be expressed in very few very readable lines. And common configuration tests that need to be done are still very readable. The handling of dependencies and options is very declarative. (Meson is also evolving, in early versions it was less so.) It'd be interesting to see some real statistics, e.g. over all Fedora packages, but in my experience, CMake projects tend to have many more files with lots of lines. > > clarity, and brevity. > > That is very much in the eye of the beholder, and it also depends on whether > you use modern CMake or legacy constructs that are often overly verbose. True ;) In _my_ eye, it's prettier. I guess we'll not achieve consensus. One particular issue I have with CMake as a downstream maintainer is it's often very hard to override linking or compilation options or when the project is using one of the cmake find scripts that gets something wrong… It's possible that those projects are "doing cmake wrong", but it seems that CMake makes it easy to do things wrong. > > I doesn't make sense to consider switching to CMake at this point. > > CMake being what the whole Qt and KDE community uses nowadays (even Qt > itself switched to it with Qt 6), it very much makes sense to switch to > CMake now more than ever. Right, but if one doesn't work on Qt, then this argument doesn't do much. [snip] > > One thing which is happening, mostly for unrelated reasons, it that > > systemd code is being changed to use dlopen() for various libraries which > > are usually not needed at runtime. The primary motivation for this is to > > omit such libraries from the initrd. But this also helps with overlinking. > > > > In systemd git main, libsystemd is only linked to libc, libcap, > > and libgcrypt + libgpg-error. A pull request to convert that that last > > pair to dlopen is under review. > > That helps somewhat (it would have prevented this backdoor from working), > but it also makes things even less transparent: How do we know whether some > random sd_foobarify() function or some random foobard linked against > libsystemd will (always or ever (and when?)) end up dlopening liblzma or > not? > > Distribution packagers tend to dislike dlopen due to the hidden dependencies > it introduces. This is true. It'd be great if the compilers and linkers supported a "weak dependency" model, where we'd use the normal call syntax and things would be the same as with a normal shared library link, but if that library is not found, the program would still load and run. Then we could still autogenerate those dependencies on optional libraries, but using Recommends instead of Requires. Right now the dependency handling needs to be handled manually, which is error-prone and annoying. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 the official linkedin post of Fedora (I already asked to correct it). I believe that statement is correct, since none of the xz-5.6.x packages ever made it to F40 stable. The furthest they've got was updates-testing, which is not enabled in the official Beta releases. However, if you installed F40 before Beta was released, then updates-testing is enabled and users may have installed the vulnerable package with a simple `sudo dnf upgrade`. I admit the wording could be clearer in that opting in to updates-testing might have been done on your behalf simply by installing F40 sometime between branching and the Beta release. Some users might not be aware of that. It may also help providing some simple instructions on how users can check if they have any of the vulnerable versions installed in the article itself. I see a comment to that extent. So, the situation around F40 is somewhat murky since a lot of factors come into play, but the statement that 5.6.x never made to F40 stable is correct[1] and therefore users not having updates-testing enabled could not have installed 5.6.x without expressly enabling it. [1] https://bodhi.fedoraproject.org/updates/?search=xz-5.6 I don't think this is right. Adam Williamson and Michael Catanzaro already confirmed that F40 has testing enabled by default because it is pre-release. It was also confirmed that some packages could have been installed on F40 variants (see also the points of Michael and Richard here in the devel mailing list). Michael and Adam also wrote some references in the Fedora Discussion topic [1] about this. 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. It's the RC composes that are made after branching and before Beta is declared GO, that have updates-testing enabled by default. I was one of the persons raising that point. I'm less certain wrt upgrades in the period between branching and Beta release. If that is incorrect and Beta shipped with updates-testing enabled, deliberately or by accident, then I stand corrected. It is obviously still an issue that is evolving and what seems clear now might prove different later. But so far I tend to leave the discussion topic as it is and ensure that F40 users expect being compromised and get informed to act correspondingly with the suggested actions. However, I already added a point how users can check if they have a malicious build. I agree. Once the levees broke, news was traveling fast and, for some, panic may have set in, not helping in determining what information is accurate. Advise to err on the side of caution, check your system and upgrade if unsure, is certainly what I would tell anyone. Even distros (Arch, Gentoo) where it turned out the payload wasn't injected, acted out of an abundance of caution, put out advisories and updates for their users. What's written on Discussion looks to be covering the broad spectrum. Maybe the Fedora Magazine article could link to that post for further clarification. [1] https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683/36 -- Sandro -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 current compiler+library+app combo is), so unit tests > should always be run when available in the Fedora environment. > Don't forget architectures. One of the reasons I use to justify getting my company's open source projects in distributions like Fedora and Debian is to surface issues when compiling against various compiler+library+app combo as you noted but as importantly, architecture specific issues. Preserving the build artifacts so they can't be tampered with during the test run is probably worthwhile though. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 not be opened if you do not use > an API that needs liblzma. But it makes it even harder to tell whether > liblzma will end up being loaded or not. > > > Long ago (I think like ~10 years ago), libsystemd was actually several > > separate smaller libraries. Perhaps we could consider asking upstream > > to switch back to that model? > > +1 This comes up occasionally, and the main reason to not do this is that systemd code has a lot of helpers that are used across a lot of the codebase and we end up with recursive calls between many of the different "components". So if tried to split things, we'd either need to remove a lot of polish, or copy code, or have the shared code duplicated. Some of those split-out libraries would probably end up embedding almost all of some of the other ones. libsystemd now consists of 12 parts (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path, sd-resolve) and it'd be a lot of work to untangle, and the overall footprint would likely grow. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning python-jose because it is unmaintained upstream
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 python-jose and orphan the python-jose package with the expectation that it will be retired for F41. As an unmaintained security library, I do *not* recommend picking it up and keeping it in Fedora – although I did not feel strongly enough to choose immediate retirement over orphaning. One package, python-social-auth-core[4], still depends on python-jose. However, this dependency is removed upstream in social-auth-core release 4.5.0[5], so I recommend that the maintainers of that package update it[6] rather than keeping python-jose around. [1] https://src.fedoraproject.org/rpms/python-jose [2] https://github.com/mpdavis/python-jose/issues/332 [3] https://github.com/mpdavis/python-jose/issues/340 [4] https://src.fedoraproject.org/rpms/python-social-auth-core [5] https://github.com/python-social-auth/social-core/blob/4.5.3/CHANGELOG.md#450---2023-10-31 [6] https://bugzilla.redhat.com/show_bug.cgi?id=2178870 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 when available in the Fedora environment. -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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/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 slow down the build (e.g., compare glibc build times without > > and > > with tests) and every so often break it because the test, not the > > software, > > is broken. And a claimed "test file" is what allowed the payload to be > > snuck > > in here. > > > > It's a terrible idea. Sorry. Yes, it's a terrible idea. Also it doesn't solve anything. Because if you can inject code into the tarball to inject code into the tests, then you can also inject code into the output binaries, but you can also inject it into configuration tests. Our official policy is to run tests during build, because that helps to catch many silly mistakes and miscompilations. If we stop doing that, we'll close one avanue of attack, leaving a few ~equivalent avanues of attack open which share the characteristic that if one is accessible to the attacker, most likely all are. > > Unit tests are something for upstream developers. They should NEVER be run > > in a distribution build. > > > > The first thesis is completely wrong. Having, say, a 30+ downstream patches > and declining to run upstream tests is the most effective way to break a > gazillion use-cases. > > But the fuzzing tests look quite dangerous to me here and now. No one can > review a corpse of binary files :( Meh, the primary purpose of such tests is to stress the code under sanitizers. Those test cases are not added randomly, they are added by upstream developers when they solve an issue. To construct an attack, somebody would need to construct a sample that does not trigger any failures with sanitizers, but actually causes a misbehaviour allowing taking control of execution. Then this control would need to be used to modify the build artifacts (because presumably doing something in the sandboxed build environment is not particularly interesting), and _then_ the attacker would need to convince the maintainers to commit the sample. This is all theoretically possible, but pretty hard to pull off. Again, I think that the important aspect is reviewability, not some simple rule about the format of files. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 are a mix of > > text, mojibake, and actual binary protocol samples. For example, dhcp > > input packets, dns packets. There are also other ~binary test files, > > for example corrupted journal files. > > > > The tests are defined via meson.build, so those files are "referred to > > in the build tools", and would not be allowed by the above definition. > > But if we dropped those, we'd lose very valuable testing of the codebase. > > On the other hand, "test files" are exactly how the payload of this backdoor > was disguised! So a policy that deletes all binary test files or even all > test files altogether would have prevented this backdoor. Well, if we made a rule that "binary" files are not allowed, the attacker would e.g. commit some minified bash that generates whatever output is needed. The real problem was the complex and unreadable build system that made it easy to embed _multiple_ obfuscated components for the attack. To trust code, it needs to be reviewed. And if the code is reviewed, and the build system is sane, it's usually fairly easy to say "oh, this is a sample and the only way it's used is as input to a fuzzer binary", or "this sample is used as input to a unit test", etc. A policy against binary files would hinder this particular implementation of the attack, but the attacker had full control of the repo, so they would be able to arrange the attack around such a policy without too much trouble. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 already asked to correct it). I believe that statement is correct, since none of the xz-5.6.x packages ever made it to F40 stable. The furthest they've got was updates-testing, which is not enabled in the official Beta releases. However, if you installed F40 before Beta was released, then updates-testing is enabled and users may have installed the vulnerable package with a simple `sudo dnf upgrade`. I admit the wording could be clearer in that opting in to updates-testing might have been done on your behalf simply by installing F40 sometime between branching and the Beta release. Some users might not be aware of that. It may also help providing some simple instructions on how users can check if they have any of the vulnerable versions installed in the article itself. I see a comment to that extent. So, the situation around F40 is somewhat murky since a lot of factors come into play, but the statement that 5.6.x never made to F40 stable is correct[1] and therefore users not having updates-testing enabled could not have installed 5.6.x without expressly enabling it. [1] https://bodhi.fedoraproject.org/updates/?search=xz-5.6 I don't think this is right. Adam Williamson and Michael Catanzaro already confirmed that F40 has testing enabled by default because it is pre-release. It was also confirmed that some packages could have been installed on F40 variants (see also the points of Michael and Richard here in the devel mailing list). Michael and Adam also wrote some references in the Fedora Discussion topic [1] about this. It is obviously still an issue that is evolving and what seems clear now might prove different later. But so far I tend to leave the discussion topic as it is and ensure that F40 users expect being compromised and get informed to act correspondingly with the suggested actions. However, I already added a point how users can check if they have a malicious build. [1] https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683/36 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 bad idea. Downstream .pc files are a nuisance. I agree, I never suggested doing this downstream. This kind of thing needs to happen upstream so that other upstreams can start depending on it. A pkgconf file is very simple to add, it's the kind of a thing that can be provided as a pull request by an external contributor, in particular a downstream maintainer. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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/cargo-vet/ That is, individuals and organizations can publish the results of their code audits publicly in a standardized format, tied to a package artifact, and a downstream consumer could denote which individuals and organizations they trust to perform said audits. It's technically possible and not an entirely ridiculous idea, it's just economically challenging. How do you find enough people willing and able to audit a package (including e.g. autotools build scripts), in multiple, to the level of scrutiny that would be required to catch something like this. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Obsoleted packages in F40
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 the end mention adding the package to https://src.fedoraproject.org/rpms/fedora-obsolete-packages I do not think the "Completely Removing a Package" section is meant for the cases you mention. The only example given in that section is licensing issues, i.e. a situation where Fedora was actually not even allowed to distribute the package, either because of the license conditions, or because of Fedora's own bylaws. On the other hand, you do not have to refer to that section if you want to remind packages about fedora-obsolete-packages. Right before there is "Obsoleting Packages", which asks to consider obsoleting for every retirement. In attempt to make it more clear that obsoleting should be considered every time a package is retired, I submitted a pull request for Package Maintainer Docs [1]. [1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/152 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 "sd_notify" (https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch), which raises a couple of questions. The first one that comes to mind is: Is the increased attack surface incurred by linking to these additional libraries worth the value provided by calling "sd_notify", or should that patch be dropped to improve sshd security? The second is: Is libsystemd too large? I could very easily be misreading it, but it looks like at least some of src/libsystemd/sd-journal is used by journald, including the compression bits. Do those really belong in libsystemd? If they need to be shared components, could the journald components be split out to reduce the size of libsystemd? (That is, to avoid linking to the compression libs?) Moving on to a broader topic: The write up describing the back door indicates that the malicious xz library "changes the value of rsa_public_decr...@plt to point to its own code." So the back door has pointed one of the symbols that should point to a page mapped to OpenSSL's libcrypto.so.3 to a page mapped to liblzma.so.5, instead. Would it be possible to audit the value of a process's symbols at runtime to look for this kind of shenanigans? Could this type of auditing be added to functional tests or rpminspect? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 will of course voice their NO as soon as they see it. > Back to the topic. > > Then you have to painstakingly scour the web for distros already using > this package and check whether their have the same version with a hash. > Then you download the package and verify the hash and pray to God the > distro has at least given a cursory look to this package, so it's actually > safe to install. > > I guess I'm not coming from @fedora.org or @redhat.com, so my proposal is > "anti-freedom". > > No. You are taking one comment from a person who is known to yell at everyone and doesn't work for Red Hat as 'being an official comment'. Most everyone on this list does not speak for Fedora at all. This is the part of the proposal that I was trying to bring up earlier that needs work: 1. There is NO one who speaks for most distributions. There is a group of many people with many different opinions who speak for a part of a distribution. They work together as best they can, but they are all going to have differing opinions and any proposal has to understand that changing 400 people's minds (for the number of active devs in Fedora) takes time. 2. Red Hat sponsors Fedora but doesn't control what Fedora does. There are many developers who are paid by Red Hat but only work on Fedora in their spare time so Red Hat may 'influence' but can not command what they do. Debian and Arch are even further along the anarchy meter for who gets to decide what happens where. 3. Getting distros to work together is hard. People choose their distros like they choose their sports teams. When they see another distro doing something, their first reaction is to do the opposite. This is why it takes a long time to get changes done and it takes a lot of people time to make it happen. > Sorry for wasting your time. You have not even provided the very basic > counter-arguments why my proposal makes no sense. > > It isn't a waste of time, but I see this response with a lot of good proposals which get any criticism. You are going to get criticism, you are going to get people yelling about stupid things in any proposal you make. People don't change their minds quickly and there is a lot of meat-space circuitry to try and make sure it isn't easy. To get a proposal through, people need to be able to understand that most of the time the first thing they are going to get is NO. Some of it is because people have a lot going on in life and they need space and time to see something for what its worth. Other times they have seen a lot of empty proposals and are trying to see if the person making it is going to actually do something about it or not. > RedHat absolutely can start this initiative. You have all the means and > resources, and I'm not talking about something super complex or expensive. > For all I know, it could be the most basic website running on top of SQLite > which costing the company $50 a month to run. > > And of course, without this website, distros will continue to valiantly > include upstream packages and get royally screwed and screw their poor > users because a ton of your maintainers have neither the time/resources, > nor qualifications to check whether the code you happily push to users is > malware free. > > I guess we'll have to have a few more accidents like this before someone > will come up with a similar solution only not coming from me personally, > because I'm a no one and just rending the air. > > Sorry for intervening, > Artem > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 repo that has not been reviewed, without an audit trail implicit in the git history, and without a clear non-repudiateable authorship. Ignoring them and regenerating them is a step forward. I bet the JT user would not have been able to put the attack in the git source code without Lasse seeing it, or other developers, or tools eventually seeing it, sooner than if it had been obfuscated in the "release" downloads (as it was). Regarding the multiple eyes, that is not the goal, but the goal is multiple *skilled* eyes. At the end of the day, this is not about building a bullet-proof system since that's unrealistic, but a system that makes it very hard by setting up tools and processes that mitigate the risk significantly. Regards, Carlos. On 3/30/24 12:43, Artem S. Tashkinov via devel wrote: And of course, would be great to employ all the methods OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 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 so often break it because the test, not the > software, > is broken. And a claimed "test file" is what allowed the payload to be > snuck > in here. > It's a terrible idea. Sorry. > Unit tests are something for upstream developers. They should NEVER be run > in a distribution build. > The first thesis is completely wrong. Having, say, a 30+ downstream patches and declining to run upstream tests is the most effective way to break a gazillion use-cases. But the fuzzing tests look quite dangerous to me here and now. No one can review a corpse of binary files :( -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 the included code even if it's autoconf-cruft free. AFAIK, the bad code discovered in XZ was on its way to the GIT repo, could have been included in a slightly different way and if not for the wonderful discovery by the Microsoft software engineer of all people, we'd be dealing with a whole much more terrible outcome. The source code must be vetted. In a perfect world, considering the entire source code is available, an API calls map for each release could be built/extracted, so that whenever a new version is published by the upstream, a new map for the new release could easily show at least all the new API calls that the project now uses to easily discover whether new features correspond to what the project maintainer published in their changelog. Probably another "anti-freedom" proposal. And of course, would be great to employ all the methods of automated software verification, like static analysis, sandboxing, fuzzying, etc. I'm just dreaming. Let's pretend this incident is entirely about autoconf stuff, and not about a software project being hijacked by hostile actors. And of course, you're absolutely sure this hasn't already happened in other widely used projects and will never happen again. Again, sorry for intervening. I just freaked out when I realized my Linux box might have been compromised after almost believing in the persistent myth of "multiple eyes" (five?) scanning open source software for malware. It's not been the case, the entire proposal that we are discussing here is not talking about it either. I'm confused. Regards, Artem -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 so often break it because the test, not the software, is broken. And a claimed "test file" is what allowed the payload to be snuck in here. Unit tests are something for upstream developers. They should NEVER be run in a distribution build. As a developer I need to say: If your build also runs your tests implicitly even if you just want to make a normal build of your software, your build setup is broken. That should just not happen. But "rm -rf test" or something like that may not be possible. Quite some projects (or just straight up languages) these days have their tests in the same file as the code they test. Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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, versions and their hashes, signed by at least two independent parties (people or orgs, doesn't matter), that's it. Who's going to populate this website, is up to people to decide. > This is just fundamentally not how Free Software works. Fundamentally I don't understand your comment at all. The proposal of mine is not there to limit anyone's freedom, it's to provide guarantees that certain packages have been vetted (checked and verified to be malware free), and you are safe to use it. Actually it's a huge stinking problem for a **ton** of open source users who want to install certain packages that their distros don't have. It's especially relevant for Fedora given it's a basically a precursor of RedHat and it cannot contain a ton of packages related to software patents. As a result of it, BTW, your users blindly trust RPMFusion. A seemingly absolutely shady website with no official ties to RedHat, which guarantees neither that the packages it builds are malware free, nor that there are any actual people responsible for them. If there are RPMFusion maintainers here, I'm not here to insult you, I'm just relaying the status quo. RPMFusion does not look legit. I stopped using it over a decade ago because I simply cannot understand why I should trust it. If RedHat denies anything patent related, there's zero legal obligations for RedHat if someone starts spreading malware via it. That sucks. Back to the topic. Then you have to painstakingly scour the web for distros already using this package and check whether their have the same version with a hash. Then you download the package and verify the hash and pray to God the distro has at least given a cursory look to this package, so it's actually safe to install. I guess I'm not coming from @fedora.org or @redhat.com, so my proposal is "anti-freedom". Sorry for wasting your time. You have not even provided the very basic counter-arguments why my proposal makes no sense. RedHat absolutely can start this initiative. You have all the means and resources, and I'm not talking about something super complex or expensive. For all I know, it could be the most basic website running on top of SQLite which costing the company $50 a month to run. And of course, without this website, distros will continue to valiantly include upstream packages and get royally screwed and screw their poor users because a ton of your maintainers have neither the time/resources, nor qualifications to check whether the code you happily push to users is malware free. I guess we'll have to have a few more accidents like this before someone will come up with a similar solution only not coming from me personally, because I'm a no one and just rending the air. Sorry for intervening, Artem -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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: 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 slow down the build (e.g., compare glibc build times without and with tests) and every so often break it because the test, not the software, is broken. And a claimed "test file" is what allowed the payload to be snuck in here. Unit tests are something for upstream developers. They should NEVER be run in a distribution build. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 that statement is correct, since none of the xz-5.6.x packages ever made it to F40 stable. The furthest they've got was updates-testing, which is not enabled in the official Beta releases. However, if you installed F40 before Beta was released, then updates-testing is enabled and users may have installed the vulnerable package with a simple `sudo dnf upgrade`. I admit the wording could be clearer in that opting in to updates-testing might have been done on your behalf simply by installing F40 sometime between branching and the Beta release. Some users might not be aware of that. It may also help providing some simple instructions on how users can check if they have any of the vulnerable versions installed in the article itself. I see a comment to that extent. So, the situation around F40 is somewhat murky since a lot of factors come into play, but the statement that 5.6.x never made to F40 stable is correct[1] and therefore users not having updates-testing enabled could not have installed 5.6.x without expressly enabling it. [1] https://bodhi.fedoraproject.org/updates/?search=xz-5.6 -- Sandro -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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, as there are several that can generate slightly different output at the same level but with other different options (such as multiple threads). I think it's probably more reasonable to say the compressed file should pass a test by the compressor (e.g. gzip -t) and the uncompressed data should match. -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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, dhcp > input packets, dns packets. There are also other ~binary test files, > for example corrupted journal files. > > The tests are defined via meson.build, so those files are "referred to > in the build tools", and would not be allowed by the above definition. > But if we dropped those, we'd lose very valuable testing of the codebase. On the other hand, "test files" are exactly how the payload of this backdoor was disguised! So a policy that deletes all binary test files or even all test files altogether would have prevented this backdoor. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 way > possible. > > Two things that came to mind I shared in another channel: > * no binary blobs in the upstream, or no blob referred to in the source > built, or referred to in the build tools 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, dhcp input packets, dns packets. There are also other ~binary test files, for example corrupted journal files. The tests are defined via meson.build, so those files are "referred to in the build tools", and would not be allowed by the above definition. But if we dropped those, we'd lose very valuable testing of the codebase. > * diffoscope should show no difference except file stats between the tar.gz > being pulled by the spec, and the source brought with a git clone. 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. > Both things could be automated with tools. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 because of this innocuous-looking patch: > > https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch > which is what ultimately allowed this to happen. This drags in libsystemd > for sd_notify, and libsystemd is linked to way too much stuff including > liblzma. Either we need a split libsdnotify that contains only sd_notify, > or > we should just stop using sd_notify at all. It increases the attack > surface > of daemons a lot just to allow the service to be "Type=notify" rather than > one of the other available approaches. Arch Linux is also systemd-based > nowadays, but still does not link OpenSSH against libsystemd. We have an upstream-adjusted version of this patch, see https://bugzilla.mindrot.org/show_bug.cgi?id=2641 I'm OK to bring the updated version of this script to Fedora as soon as it is finalized. -- Dmitry Belyavskiy -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 because people may use > different compressors and compression settings) and their hashes must be > digitally signed or have the appropriate PGP signatures from the trusted > parties. > > Some parties must be assigned trust to be able to push new packages to > this repository. Each push must be verified by at least two independent > parties, let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't > matter. The representatives of these parties must be people whose > whereabouts are known to confirm who they physically are. No nicknames > allowed. This is just fundamentally not how Free Software works. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 > supported by some utilities and not by others, and I see some code such as > [0] that doesn't account for it) > > I'm sure having all of those different options available is nice in some > context or another, but how unrealistic would it be to pare that back to a > few slightly more opinionated and consistent choices? Bzip2 for instance > isn't particularly good on *any* metric, are there legacy / ecosystem reasons > that are sufficiently important for libsystemd to be dragging it around? > libsystemd linking 4 different compression libraries does seem a bit > excessive (if it can be helped). > > [0] > https://github.com/systemd/systemd/blob/3799fa803efb04cdd1f1b239c6c64803fe85d13a/src/import/importctl.c#L493 libsystemd is linked to compression libraries primarly because those compressors are options for journald files, and we generally want to mainain the property that all journal files from the past, as well as journal files from other systems, can be read by later journal code. (bzip2 is an exception here. It is only used by systemd-importd and related tools, so libsystemd was never linked to it, IIRC.) In recent systemd versions, dlopen is used for various compression libraries and other libraries, so they'll be opportunistically loaded if needed, effectively making those dependencies optional at runtime. Conversions to use dlopen require a bit of boilerplate code and make the code less readable, so we only would to them if there was a reason. Usually, this reason was size and/or the dependency tree. Compression libraries are very small and have no dependencies, so it wasn't considered important to use dlopen for them. But now that there's a new motivation, as mentioned elsewhere in the thread, we'll load pretty much all dependencies of libsystemd via dlopen. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 organization (even if > only informal), with a set of experienced > developers, and sufficiently funded to continue > support of the package, and has a good security > reporting and response process in place. What if, as in the case of SELinux, said "large-ish organization" is exactly the kind of organization one would expect to plant a backdoor like this? Also, a "large-ish organization" can be secretly contacted by the intelligence agencies of the country it resides in and tasked to implement secret backdoors for them. It has happened with large proprietary software providers, so why could it not happen with a large organization developing Free Software? Projects done by a "large-ish organization" are NOT immune to this kind of attack. It would just be executed differently, not as a hostile takeover by one "motivated new maintainer" as for an individual hobbyist project like xz. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 software on Fedora, they will end up relying on those .pc files, thinking they are a supported way to link that library, then only after releasing the code, finding out that those .pc files do not exist upstream or in any other distribution (or worse, other distributions may have their own, incompatible, downstream .pc file for the same library). I have already been in that situation as a developer. It just sucked. If a library does not support pkg-config upstream, you MUST NOT use pkg- config to find it. It is not portable. So shipping such a downstream .pc file advertises a false interface to developers. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 pkgconf invocation. Find*.cmake scripts for many common libraries are actually shipped with CMake itself. More and more libraries even ship their own *Config.cmake which makes a Find*.cmake script entirely unnecessary. For less common libraries, you are probably better off simply using the CMake pkg-config integration, which exists. Assuming of course that that library ships a .pc file to begin with, otherwise, pkg-config is not going to help you. (And when I write "pkg-config", I mean either the original pkg- config or pkgconf, the build system should not need to care about the difference.) The reason CMake upstream recommends against using pkg-config directly, and instead to use it at most as a source of hints for CMake's find_* commands (e.g., find_library) in a Find*.cmake script, is that using pkg-config on Windows is often frowned upon. So typically, the way it works is that someone first writes a Find*.cmake that finds the library in the standard paths using find_library, then extends it to invoke pkg-config using the CMake pkg-config integration under "if (UNIX)" and to add the result as a path hint to the already written find_library call. > And of course nobody has time to look into those scripts, making it > easy to smuggle something through there. You are right that bundled Find*.cmake scripts are a problem. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 tooling is there for developers and users to dig into it. Well, to be fair, I have also seen (more than once!) arcane stuff being done in CMake, with almost a whole new build system being built on top of CMake (tons of custom macros implementing things such as bundled libraries, before CMake had native support for that), which was not particularly easy to understand either. If you use CMake the way it was intended, a CMakeLists.txt is a lot more readable than even a configure.ac and Makefile.am, let alone the generated blobs autoconf spits out based on those. But there is potential for abuse, too. That said, I do not believe completely banning custom functions and macros as Meson does is a workable solution. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 specific, and creating a > loop out of every call like Meson's FAQ recommends > (https://mesonbuild.com/FAQ.html#why-doesnt-meson-have-user-defined-functionsmacros) > would create one heck of spagetthi code. Yes, that is exactly what makes Meson all hardcoded and not extensible. If you need to do anything that the Meson developers did not think of, you end up having to work around the build system (using external commands, or a Meson file generator that preprocesses macros, or some other ugly hack) instead of with the build system or just having to switch to a better build system (such as CMake ;-) ). Using loops instead of functions or macros also misses one important point: the function or macro can be shared between projects and even eventually upstreamed to the build system (both of which happen regularly in the CMake world). By the way, CMake allows defining both macros and actual functions, and macros are what you want to use in most cases. The main reason functions were introduced is to allow recursion (which is a two-edged sword because it makes the language Turing-complete with all its implications). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 harder to tell whether liblzma will end up being loaded or not. > Long ago (I think like ~10 years ago), libsystemd was actually several > separate smaller libraries. Perhaps we could consider asking upstream > to switch back to that model? +1 Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 as [0] that doesn't account for it) I'm sure having all of those different options available is nice in some context or another, but how unrealistic would it be to pare that back to a few slightly more opinionated and consistent choices? Bzip2 for instance isn't particularly good on *any* metric, are there legacy / ecosystem reasons that are sufficiently important for libsystemd to be dragging it around? libsystemd linking 4 different compression libraries does seem a bit excessive (if it can be helped). [0] https://github.com/systemd/systemd/blob/3799fa803efb04cdd1f1b239c6c64803fe85d13a/src/import/importctl.c#L493 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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). CMake is completely extensible with a complete programming language (it is Turing-complete if and only if you use recursive functions; if you avoid FUNCTION or at least recursive ones, then it is guaranteed to always terminate and still usually expressive enough, but Turing-completeness through recursion is there if you really need it). > clarity, and brevity. That is very much in the eye of the beholder, and it also depends on whether you use modern CMake or legacy constructs that are often overly verbose. Meson does not have so much legacy stuff simply because 1. it is much newer (which also means it is less mature) and 2. it cares less about backwards compatibility (which is not a good thing, backwards compatibility is essential if you want to avoid upstreams bundling old copies of build tools). > I doesn't make sense to consider switching to CMake at this point. CMake being what the whole Qt and KDE community uses nowadays (even Qt itself switched to it with Qt 6), it very much makes sense to switch to CMake now more than ever. The main reason Meson is a thing at all (and not just one person's little- known project as it initially was) is that GNOME did not want to use the same build tool KDE was already using (even though they had the exact same issues with autotools). > I don't think a separate library would be particularly useful. > sd_notify() as used by sshd just writes a static string to a unix > socket. This can be implemented in ~10 lines of C, including error > handling. Copy&paste is exactly what we do not want here. (It can easily be done wrong, either accidentally or deliberately, introducing security issues, and any security issue discovered in the copied&pasted code has to be fixed in all the copies.) If daemons are likely to need only one function (sd_notify), then a library containing only that one function is exactly what is needed, no matter how small it is. > If that is the _only_ thing needed from libsystemd, then open-coding it > is a good option. I guess it'd make sense for systemd to provide a header > file that provides a reference documentation as an inline function. That is an option which is better than copy&paste, but it still means that all users will need to be rebuilt if a bug in that header file is fixed (as for a static library, but unlike a shared library). > One thing which is happening, mostly for unrelated reasons, it that > systemd code is being changed to use dlopen() for various libraries which > are usually not needed at runtime. The primary motivation for this is to > omit such libraries from the initrd. But this also helps with overlinking. > > In systemd git main, libsystemd is only linked to libc, libcap, > and libgcrypt + libgpg-error. A pull request to convert that that last > pair to dlopen is under review. That helps somewhat (it would have prevented this backdoor from working), but it also makes things even less transparent: How do we know whether some random sd_foobarify() function or some random foobard linked against libsystemd will (always or ever (and when?)) end up dlopening liblzma or not? Distribution packagers tend to dislike dlopen due to the hidden dependencies it introduces. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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/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 because people may use > different compressors and compression settings) and their hashes must be > digitally signed or have the appropriate PGP signatures from the trusted > parties. > > Some parties must be assigned trust to be able to push new packages to > this repository. Each push must be verified by at least two independent > parties, let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't matter. > The representatives of these parties must be people whose whereabouts are > known to confirm who they physically are. No nicknames allowed. > > This website must also have/allow a revocation mechanism for situations > like this. > > Now Fedora/Arch/Debian/Ubuntu/whatever distros can build packages knowing > they are safe to use. > > If that's the wrong place to come up with this proposal, please forward it > to the people who are responsible for making such decisions. I'm not > willing to dig through the dirt to understand how the Fedora project works, > who is responsible for what, and what are the appropriate communication > channels. If you care, you'll simply forward my message. Thanks a lot. > > There is no one who makes such decisions for any of the distros. Most of the distributions make decisions by consensus of hundreds of individuals who read a list and come to the conclusion that they are 'going to dig through the dirt' to make something happen or not. For changes like what you propose, you need groups of people to work for years to get all the agreements in place, get the various tooling adapted, and work out all the personalities involved. It will usually start with an email like this, and then various disagreements about how it will never work, and then some group of people to actually try to get something like it to work somewhere. At which point, the next round of 'well did you think about..' problems arrive and either the people are able to fix them or the idea gets shelved until later. > Best regards, > Artem > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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/IBM/FSF/Ubuntu and all the big players behind Open Source/Linux but I want to raise a very important issue. There's near zero accountability for the tens of thousands of packages included in Linux distros, often by maintainers who have no resources, qualifications or even know any programming languages to spot the "bad" code and raise an alarm. Upstream packages are pushed into Linux distros without considerationand that's it. That's all completely unacceptable on multiple levels. Security is a joke as a result of this considering the infamous "Jia Tan" who was almost the sole maintainer of XZ for over two years. 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/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 because people may use different compressors and compression settings) and their hashes must be digitally signed or have the appropriate PGP signatures from the trusted parties. Some parties must be assigned trust to be able to push new packages to this repository. Each push must be verified by at least two independent parties, let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't matter. The representatives of these parties must be people whose whereabouts are known to confirm who they physically are. No nicknames allowed. This website must also have/allow a revocation mechanism for situations like this. Now Fedora/Arch/Debian/Ubuntu/whatever distros can build packages knowing they are safe to use. If that's the wrong place to come up with this proposal, please forward it to the people who are responsible for making such decisions. I'm not willing to dig through the dirt to understand how the Fedora project works, who is responsible for what, and what are the appropriate communication channels. If you care, you'll simply forward my message. Thanks a lot. Best regards, Artem -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 in there, maybe the window manager, and no further. I wrote a mail about this a while ago. The problem is really that the "critical path" concept has changed somewhat over time, and gotten a bit overloaded. The original idea of critical path was to require special testing attention for it. Back in Ye Earlie Days, critpath packages had all kinds of special rules around them, including requiring +2 or +3 (it's a long time ago, I forget) from "proven testers" (remember those?) *Most* of that has now gone. The only significant of critpath for manual testing in the current update policy is that critpath packages have a longer minimum wait in updates-testing (14 days vs. 7 days, at least after a certain point in the release cycle). They do not have higher karma requirements (at least, not by policy; Bodhi doesn't actually implement the policy correctly ATM, but I'm fixing that). The karma minima defined in the updates policy are currently identical at all points in the cycle for critpath and non-critpath updates. The "proven testers" concept was put on ice long ago. The primary 'meaning' of critpath these days is that it triggers openQA testing, and critpath updates are gated on openQA testing. I set things up this way really just because it was convenient, and as is the way of things, now it's kinda baked in. We probably want to look at separating out the concepts a bit. It's certainly technically possible, it just requires some work. The 'releng.py' script that "generates the critical path" is really just a comps-informed depsolver that spits out JSON. It could generate all kinds of groups besides "critical path" groups. We'd just have to wire them up to *mean*...whatever we want them to mean. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 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 specific, and creating a loop out of every call like Meson's FAQ recommends (https://mesonbuild.com/FAQ.html#why-doesnt-meson-have-user-defined-functionsmacros) would create one heck of spagetthi code. So yeah, there are edge cases where I would recommend CMake over Meson purely without looking at the rest of the ecosystem. Another is ofc that a quite big chunk of the C and C++ ecosystem uses CMake and integration between build systems kinda sucks (but the CMake developers try to work on making it better by working together with other projects). But I don't think this is the right place to talk about which build system to switch to FOR OTHER PROJECTS. (But if we are at it, ever looked at Zig as a buildsystem for a C or C++ project? I know some companies which do this at this point.) Sincerely Kilian Hanich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 binary blobs in the upstream, or no blob referred to in the source built, or referred to in the build tools * diffoscope should show no difference except file stats between the tar.gz being pulled by the spec, and the source brought with a git clone. Both things could be automated with tools. On 3/30/24 08:58, Miroslav Suchý wrote: 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 "security path", like "critical path". Generally good idea. But several packages that JiaT75 GH-starred were: * doxygen - when you infect this, you have open path to 700 Fedora packages, including gcc. * squashfs-tools - when you infect this, you have open path to all images (just example, not sure if our toolchain use this or -ng version). So the security patch should be much wider. OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 > > > 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 pkgconf invocation. > > > > > > > > And of course nobody has time to look into those scripts, making it > > > > easy to smuggle something through there. > > > > > > It's still better than Autotools, though. If a project doesn't want to > > > switch to Meson for whatever reason, then CMake is a reasonable > > > alternative. > > > > > > I agree that CMake is not as good as Meson, and that CMake find modules > > > are > > > inferior to pkg-config. > > > > But then we shouldn't describe them as equivalent alternatives ;) > > If we say "switch to a modern build systemd, e.g. cmake or meson", > > people will randomly choose on or the other and since the whole CMake > > ecosystem is built around find modules, we'll end with a bazillion of > > those. > > > > Instead we should say: "Use meson. If you can't for some reason, consider > > CMake, but come talk to us first." > > > > Meson's own module instability and lack of extensibility make it > unsuitable for a wide range of projects, especially complex ones. The > lack of stability in Meson itself is so bad that Meson upgrades break > GNOME, libvirt, and others. And the lack of extensibility is an > anti-feature. It means that Meson cannot scale to the infinite world > of project needs because everything has to be bent around it or hacks > need to be written in the projects to work around its weaknesses. > > No way would I personally recommend it. I'm not going to go as far as > to recommend one explicitly over the other from a distribution > perspective, but personally I would never choose Meson anymore. Also we haven't found the meson lead developer to be very open to fixing an obvious bug that affects Fedora/RISC-V, even after providing and carefully testing a patch for it. It wasn't encouraging. Rich. > > > > -- > 真実はいつも一つ!/ Always, there's only one truth! > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 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 will be fun) > > > > > > > > CMake! :-) > > > > Meson outclasses CMake in functionality, clarity, and brevity. > > I doesn't make sense to consider switching to CMake at this point. > > Which is the better build system doesn't much matter here, as they all > let you run shell scripts so source level backdoors could be inserted > in all of them. > > The big difference they all have over autoconf is that they don't > usually distribute a giant obfuscated (basically binary) shell script. > > We can fix autoconf now by running autoreconf and we don't need to > boil the ocean to do so. > > > > > This drags in libsystemd > > > > for sd_notify, and libsystemd is linked to way too much stuff including > > > > liblzma. Either we need a split libsdnotify that contains only > > > > sd_notify, or > > > > we should just stop using sd_notify at all. It increases the attack > > > > surface > > > > of daemons a lot just to allow the service to be "Type=notify" rather > > > > than > > > > one of the other available approaches. Arch Linux is also systemd-based > > > > nowadays, but still does not link OpenSSH against libsystemd. > > > > > > > > > > This is related to philosophical differences between Arch and Fedora. > > > > > > That said, it probably makes sense for sd_notify to be its own library > > > instead of being part of libsystemd. I'm sure systemd upstream will > > > consider it now. :) > > > > I don't think a separate library would be particularly useful. > > sd_notify() as used by sshd just writes a static string to a unix > > socket. This can be implemented in ~10 lines of C, including error handling. > > > > If that is the _only_ thing needed from libsystemd, then open-coding it > > is a good option. I guess it'd make sense for systemd to provide a header > > file that provides a reference documentation as an inline function. > > I think systemd should do this, just so we have one implementation, > and not loads of buggy ones. > > > One thing which is happening, mostly for unrelated reasons, it that > > systemd code is being changed to use dlopen() for various libraries which > > are usually not needed at runtime. The primary motivation for this is to > > omit such libraries from the initrd. But this also helps with overlinking. > > > > In systemd git main, libsystemd is only linked to libc, libcap, > > and libgcrypt + libgpg-error. A pull request to convert that that last > > pair to dlopen is under review. > > Also a good change, thanks. > 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. Long ago (I think like ~10 years ago), libsystemd was actually several separate smaller libraries. Perhaps we could consider asking upstream to switch back to that model? -- 真実はいつも一つ!/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 > > > > meson or another new shiny, and saner, build system, but getting > > > > upstreams > > > > to agree will be fun) > > > > > > CMake! :-) > > Meson outclasses CMake in functionality, clarity, and brevity. > I doesn't make sense to consider switching to CMake at this point. Which is the better build system doesn't much matter here, as they all let you run shell scripts so source level backdoors could be inserted in all of them. The big difference they all have over autoconf is that they don't usually distribute a giant obfuscated (basically binary) shell script. We can fix autoconf now by running autoreconf and we don't need to boil the ocean to do so. > > > This drags in libsystemd > > > for sd_notify, and libsystemd is linked to way too much stuff including > > > liblzma. Either we need a split libsdnotify that contains only sd_notify, > > > or > > > we should just stop using sd_notify at all. It increases the attack > > > surface > > > of daemons a lot just to allow the service to be "Type=notify" rather than > > > one of the other available approaches. Arch Linux is also systemd-based > > > nowadays, but still does not link OpenSSH against libsystemd. > > > > > > > This is related to philosophical differences between Arch and Fedora. > > > > That said, it probably makes sense for sd_notify to be its own library > > instead of being part of libsystemd. I'm sure systemd upstream will > > consider it now. :) > > I don't think a separate library would be particularly useful. > sd_notify() as used by sshd just writes a static string to a unix > socket. This can be implemented in ~10 lines of C, including error handling. > > If that is the _only_ thing needed from libsystemd, then open-coding it > is a good option. I guess it'd make sense for systemd to provide a header > file that provides a reference documentation as an inline function. I think systemd should do this, just so we have one implementation, and not loads of buggy ones. > One thing which is happening, mostly for unrelated reasons, it that > systemd code is being changed to use dlopen() for various libraries which > are usually not needed at runtime. The primary motivation for this is to > omit such libraries from the initrd. But this also helps with overlinking. > > In systemd git main, libsystemd is only linked to libc, libcap, > and libgcrypt + libgpg-error. A pull request to convert that that last > pair to dlopen is under review. Also a good change, thanks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 "security path", like "critical path". Generally good idea. But several packages that JiaT75 GH-starred were: * doxygen - when you infect this, you have open path to 700 Fedora packages, including gcc. * squashfs-tools - when you infect this, you have open path to all images (just example, not sure if our toolchain use this or -ng version). So the security patch should be much wider. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 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 pkgconf invocation. > > > > > > And of course nobody has time to look into those scripts, making it > > > easy to smuggle something through there. > > > > It's still better than Autotools, though. If a project doesn't want to > > switch to Meson for whatever reason, then CMake is a reasonable alternative. > > > > I agree that CMake is not as good as Meson, and that CMake find modules are > > inferior to pkg-config. > > But then we shouldn't describe them as equivalent alternatives ;) > If we say "switch to a modern build systemd, e.g. cmake or meson", > people will randomly choose on or the other and since the whole CMake > ecosystem is built around find modules, we'll end with a bazillion of > those. > > Instead we should say: "Use meson. If you can't for some reason, consider > CMake, but come talk to us first." > Meson's own module instability and lack of extensibility make it unsuitable for a wide range of projects, especially complex ones. The lack of stability in Meson itself is so bad that Meson upgrades break GNOME, libvirt, and others. And the lack of extensibility is an anti-feature. It means that Meson cannot scale to the infinite world of project needs because everything has to be bent around it or hacks need to be written in the projects to work around its weaknesses. No way would I personally recommend it. I'm not going to go as far as to recommend one explicitly over the other from a distribution perspective, but personally I would never choose Meson anymore. -- 真実はいつも一つ!/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 patch: > https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch > which is what ultimately allowed this to happen. This drags in libsystemd > for sd_notify, and libsystemd is linked to way too much stuff including > liblzma. Either we need a split libsdnotify that contains only sd_notify, or > we should just stop using sd_notify at all. Upstream openssh-portable has a proposed patch which simply implements the sdnotify protocol directly. That would provide the benefits with none of the over-linking risk. https://bugzilla.mindrot.org/show_bug.cgi?id=2641#c13 It could use some review from distro folks familiar with sshd systemd integration. (The wider point about splitting the sdnotify functionality is still quite useful, to avoid everyone re-implementing the same thing and possibly adding bugs in _that_ process.) -- Todd signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 > this attack. > Only because that person didn't think to check it in and tag it. They very well could have since they had direct commit access. -- 真実はいつも一つ!/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 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 force the malicious > > > attacker to commit their code to version control, making it slightly > > > harder to hide the attack. > > > > Using a signed tarball is ideally better than a git tag (it's an extra > > level of author attestation)... but where both are available, it'd be > > nice to have a way to denote in the spec file that there are two URLs > > for the source. In this case, if both URLs were listed and something > > could be run to automatically fetch and compare them, the attack code > > would have been flagged. > > Tarball production should be reproducible. Then the maintainer can > both make a signature locally and make it public, and users can download > the auto-generated tarball. > > In fact, github tarball generation is stable. A few years ago they tried > to improve the compression method (i.e. .tar would be still identical, > but .tar.gz would be different), and after a huge outcry this was reverted. > They still haven't officially said that it's stable, but let's hope that > it never changes, at least not without a suitable advance warning. I used the following to check all 193 github tarballs provided for systemd (those are autogenerated): git clone --bare https://github.com/systemd/systemd dir=systemd.git tags=$(git --git-dir=$dir tag|rg '^v\d+(\.\d+)?$'|sed 's/^v//'|sort -g) for v in $tags; do echo $v if [[ v =~ . ]]; then wget https://github.com/systemd/systemd-stable/archive/v$v/systemd-$v.tar.gz git --git-dir=$dir archive v$v --prefix=systemd-stable-$v/ | gzip >systemd-$v.local.tar.gz else wget https://github.com/systemd/systemd/archive/v$v/systemd-$v.tar.gz git --git-dir=$dir archive v$v --prefix=systemd-$v/ | gzip >systemd-$v.local.tar.gz fi cmp systemd-$v.local.tar.gz systemd-$v.tar.gz || break rm systemd-$v.local.tar.gz systemd-$v.tar.gz echo done Fortunately, they all match ;) Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 projects > > using CMake to come with a whole directory of badly written detection > > scripts that each replace a single-line pkgconf invocation. > > > > And of course nobody has time to look into those scripts, making it > > easy to smuggle something through there. > > It's still better than Autotools, though. If a project doesn't want to > switch to Meson for whatever reason, then CMake is a reasonable alternative. > > I agree that CMake is not as good as Meson, and that CMake find modules are > inferior to pkg-config. But then we shouldn't describe them as equivalent alternatives ;) If we say "switch to a modern build systemd, e.g. cmake or meson", people will randomly choose on or the other and since the whole CMake ecosystem is built around find modules, we'll end with a bazillion of those. Instead we should say: "Use meson. If you can't for some reason, consider CMake, but come talk to us first." > The CMake developers are working on replacing find > modules with CPS [1] which is intended to be a replacement for pkg-config > that will work better on non-Linux platforms, where pkg-config is not always > adequate. It looks like that work has maybe stalled? but if successful that > would fix the problem with find modules. > > [1] https://cps-org.github.io/cps/overview.html Ack. But from our point of view, this wouldn't be great. We already have pkgconf files for almost everything and CPS files for nothing… 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. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 shipped artifacts with their "make dist" equivalents and publishing the results. There are several versions of autoconf, automake, and libtool in wide use. There are also many libraries that ship autotools macros for inclusion in code that builds against those libraries. Those macros don't change very often, but they do change. You will need to match the version for everything in the build environment in order to meaningfully compare autotools-generated shellcode. pgp6JJOFBLwYC.pgp Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 and switch to using git > > tags directly instead. That would at least force the malicious > > attacker to commit their code to version control, making it slightly > > harder to hide the attack. > > Using a signed tarball is ideally better than a git tag (it's an extra > level of author attestation)... but where both are available, it'd be > nice to have a way to denote in the spec file that there are two URLs > for the source. In this case, if both URLs were listed and something > could be run to automatically fetch and compare them, the attack code > would have been flagged. Tarball production should be reproducible. Then the maintainer can both make a signature locally and make it public, and users can download the auto-generated tarball. In fact, github tarball generation is stable. A few years ago they tried to improve the compression method (i.e. .tar would be still identical, but .tar.gz would be different), and after a huge outcry this was reverted. They still haven't officially said that it's stable, but let's hope that it never changes, at least not without a suitable advance warning. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 fix the blog post. This is still an evolving situation; apologies for the confusion as we sort this out. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/ [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/ Then we must have had some communication snafu regarding the Fedora Magazine article, because multiple people including myself flagged the incorrect statement there before the article was published. Hopefully we can get one this fixed, too. Michael Thanks for clarifying. I have already deleted the Fedora Magazine link from the related Fedora Discussion topic [1] earlier, and now updated the rest. I re-add the magazine article when it was fixed, I pinged Justin already some hours ago, hopefully it gets updated soon. [1] https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 scripts that each replace a single-line pkgconf invocation. And of course nobody has time to look into those scripts, making it easy to smuggle something through there. It's still better than Autotools, though. If a project doesn't want to switch to Meson for whatever reason, then CMake is a reasonable alternative. I agree that CMake is not as good as Meson, and that CMake find modules are inferior to pkg-config. The CMake developers are working on replacing find modules with CPS [1] which is intended to be a replacement for pkg-config that will work better on non-Linux platforms, where pkg-config is not always adequate. It looks like that work has maybe stalled? but if successful that would fix the problem with find modules. [1] https://cps-org.github.io/cps/overview.html -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 are looking). That does not mean we should not try to minimize the likelihood of future such attacks. > (3) We should have a "security path", like "critical path". > . > > 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 > default. > Obligatory xkcd: https://xkcd.com/2347/ 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 organization (even if only informal), with a set of experienced developers, and sufficiently funded to continue support of the package, and has a good security reporting and response process in place. xz would not seem to meet that vague hand waving criteria, and so it should either be replaced with something else (if possible) or get it (or in this case, likely its new team) resourced to its level of importance in the ecosystem. I expect, with a critical eye, other such projects will be identified. The response to Heartbleed was (among other things), resourcing OpenSSL. If a decision is made that xz needs to stay as part of the critical chain, it needs to be resourced too (although, as others have suggested, removing xz from that chain may be a better choice). -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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, 2024 at 01:38:45PM +, Tim Landscheidt wrote: > Kevin Kofler wrote: > > 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 Fedora to finally > > realize that that exception has always been a bad idea. > CMIIW, but it would not have made any difference as the > source code had been shipped as part of the tar ball and > auto(re)conf would have happily integrated it into the next > build. I suspect that a modification to CMakeLists.txt and > its includes would not have been detected either; even a > daring, but obvious change in the 3+ lines of source > itself might have gone unnoticed. 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 pkgconf invocation. And of course nobody has time to look into those scripts, making it easy to smuggle something through there. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 situation; apologies for the confusion as we sort this out. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/ [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/ Then we must have had some communication snafu regarding the Fedora Magazine article, because multiple people including myself flagged the incorrect statement there before the article was published. Hopefully we can get one this fixed, too. Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 will be fun) > > > > CMake! :-) Meson outclasses CMake in functionality, clarity, and brevity. I doesn't make sense to consider switching to CMake at this point. > > This drags in libsystemd > > for sd_notify, and libsystemd is linked to way too much stuff including > > liblzma. Either we need a split libsdnotify that contains only sd_notify, or > > we should just stop using sd_notify at all. It increases the attack surface > > of daemons a lot just to allow the service to be "Type=notify" rather than > > one of the other available approaches. Arch Linux is also systemd-based > > nowadays, but still does not link OpenSSH against libsystemd. > > > > This is related to philosophical differences between Arch and Fedora. > > That said, it probably makes sense for sd_notify to be its own library > instead of being part of libsystemd. I'm sure systemd upstream will > consider it now. :) I don't think a separate library would be particularly useful. sd_notify() as used by sshd just writes a static string to a unix socket. This can be implemented in ~10 lines of C, including error handling. If that is the _only_ thing needed from libsystemd, then open-coding it is a good option. I guess it'd make sense for systemd to provide a header file that provides a reference documentation as an inline function. One thing which is happening, mostly for unrelated reasons, it that systemd code is being changed to use dlopen() for various libraries which are usually not needed at runtime. The primary motivation for this is to omit such libraries from the initrd. But this also helps with overlinking. In systemd git main, libsystemd is only linked to libc, libcap, and libgcrypt + libgpg-error. A pull request to convert that that last pair to dlopen is under review. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 40 compose report: 20240330.n.0 changes
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 upgraded packages: 654.41 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -1.82 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-40-20240330.n.0.iso = DROPPED IMAGES = Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-40-20240329.n.1.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240329.n.1.iso = ADDED PACKAGES = Package: python-cmap-0.2.0-1.fc40 Summary: Scientific colormaps for python, without dependencies RPMs:python3-cmap Size:1.16 MiB Package: python-pyconify-0.1.6-1.fc40 Summary: Iconify for Python - universal icon framework RPMs:python3-pyconify Size:44.75 KiB Package: python-pytest-qt-4.4.0-2.fc40 Summary: pytest support for PyQt and PySide applications RPMs:python3-pytest-qt Size:98.50 KiB Package: python-pyuca-1.2-1.fc40 Summary: Python implementation of the Unicode Collation Algorithm RPMs:python3-pyuca Size:610.83 KiB Package: python-superqt-0.6.2-1.fc40 Summary: Missing widgets and components for PyQt/PySide RPMs:python3-superqt python3-superqt+pyqt6 Size:223.47 KiB Package: rust-serial_test2-2.0.0-1.fc40 Summary: Allows for the creation of serialised Rust tests RPMs:rust-serial_test2+async-devel rust-serial_test2+default-devel rust-serial_test2+file_locks-devel rust-serial_test2+fslock-devel rust-serial_test2+futures-devel rust-serial_test2+log-devel rust-serial_test2+logging-devel rust-serial_test2-devel Size:67.77 KiB Package: rust-serial_test_derive2-2.0.0-1.fc40 Summary: Helper crate for serial_test RPMs:rust-serial_test_derive2+async-devel rust-serial_test_derive2+default-devel rust-serial_test_derive2-devel Size:27.91 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: firecracker-1.7.0-1.fc40 Old package: firecracker-1.6.0-6.fc40 Summary: Secure and fast microVMs for serverless computing RPMs: firecracker Size: 4.89 MiB Size change: -250.76 KiB Changelog: * Mon Mar 18 2024 David Michael - 1.7.0-1 - Update to the 1.7.0 release. Package: go-rpm-macros-3.5.0-1.fc40 Old package: go-rpm-macros-3.4.0-2.fc40 Summary: Build-stage rpm automation for Go packages RPMs: go-filesystem go-rpm-macros go-rpm-templates go-srpm-macros Size: 289.02 KiB Size change: 3.36 KiB Changelog: * Fri Mar 01 2024 Maxwell G - 3.5.0-1 - Update to 3.5.0. Package: python-spyder-kernels-1:3.0.0~b4-1.20240308gitv3.0.0b4.fc40 Old package: python-spyder-kernels-1:3.0.0~b2-4.20230923gitv3.0.0b2.fc40 Summary: Jupyter kernels for Spyder's console RPMs: python3-spyder-kernels Size: 176.74 KiB Size change: -1.23 KiB Changelog: * Fri Mar 08 2024 Sandro - 1:3.0.0~b4-1 - Update to 3.0.0b4 Package: rust-1.77.0-1.fc40 Old package: rust-1.76.0-1.fc40 Summary: The Rust Programming Language RPMs: cargo clippy rust rust-analyzer rust-debugger-common rust-doc rust-gdb rust-lldb rust-src rust-std-static rust-std-static-i686-pc-windows-gnu rust-std-static-wasm32-unknown-unknown rust-std-static-wasm32-wasi rust-std-static-x86_64-pc-windows-gnu rust-std-static-x86_64-unknown-none rust-std-static-x86_64-unknown-uefi rustfmt Size: 617.82 MiB Size change: -752.12 KiB Changelog: * Thu Mar 21 2024 Nikita Popov - 1.77.0-1 - Update to 1.77.0 Package: rust-devicemapper-0.34.2-1.fc40 Old package: rust-devicemapper-0.34.1-2.fc40 Summary: Library for using Linux device mapper RPMs: rust-devicemapper+default-devel rust-devicemapper-devel Size: 82.09 KiB Size change: 128 B Changelog: * Tue Mar 26 2024 Bryan Gurney - 0.34.2-1 - Update to version 0.34.2 Package: rust-devicemapper-sys-0.3.0-1.fc40 Old package: rust-devicemapper-sys-0.2.0-2.fc40 Summary: Low level bindings for devicemapper RPMs: rust-devicemapper-sys+default-devel rust-devicemapper-sys-devel Size: 24.27 KiB Size change: 148 B Changelog: * Tue Mar 26 2024 Bryan Gurney - 0.3.0-1 - Update to version 0.3.0 Package: rust-libblkid-rs-0.3.2-1.fc40 Old package: rust-libblkid-rs-0.3.1-2.fc40 Summary: High level bindings for libblkid RPMs: rust-libblkid-rs+default-devel rust-libblkid-rs+deprecated-devel rust-libblkid-rs-devel Size: 49.74 KiB Size change: 236 B Changelog: * Tue Mar 26 2024 Bryan Gurney - 0.3.2-1 - Update to 0.3.2 Package: rust-libblkid-rs-sys-0.3.0-1.fc40 Old package: rust-libblkid-rs-sys-0.2.0-2.fc40 Summary: Low level bin
Fedora rawhide compose report: 20240330.n.0 changes
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 of upgraded packages: 1.67 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 106.34 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20240330.n.0.iso Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20240330.n.0.iso = DROPPED IMAGES = Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20240329.n.1.x86_64.vagrant-libvirt.box Image: Kinoite ociarchive ppc64le Path: Kinoite/ppc64le/images/Fedora-Kinoite-Rawhide.20240329.n.1.ociarchive Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20240329.n.1.x86_64.vagrant-virtualbox.box Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240329.n.1.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: c-ares-1.28.0-1.fc41 Old package: c-ares-1.25.0-3.fc40 Summary: A library that performs asynchronous DNS operations RPMs: c-ares c-ares-devel Size: 1.53 MiB Size change: 25.52 KiB Changelog: * Fri Mar 29 2024 Tom Callaway - 1.28.0-1 - update to 1.28.0 Package: cocoalib-0.99850-1.fc41 Old package: cocoalib-0.99818-4.fc40 Summary: C++ library for computations in commutative algebra RPMs: cocoalib cocoalib-devel cocoalib-doc Size: 8.59 MiB Size change: 219.37 KiB Changelog: * Fri Mar 29 2024 Jerry James - 0.99850-1 - Version 0.99850 Package: cvc5-1.1.2-2.fc41 Old package: cvc5-1.1.2-1.fc41 Summary: Automatic theorem prover for SMT problems RPMs: cvc5 cvc5-devel cvc5-java cvc5-libs python3-cvc5 Size: 25.39 MiB Size change: -108.06 KiB Changelog: * Fri Mar 29 2024 Jerry James - 1.1.2-2 - Rebuild for cocoalib 0.99850 Package: dnf-4.19.2-1.fc41 Old package: dnf-4.19.0-1.fc40 Summary: Package manager RPMs: dnf dnf-automatic dnf-data python3-dnf yum Size: 1.19 MiB Size change: -4.69 KiB Changelog: * Thu Mar 28 2024 Evan Goode - 4.19.1-1 - Update to 4.19.1 - Add required `.readthedocs.yaml`, `conf.py` and set `sphinx_rtd_theme` - Drop dnf obsoletion temporarily - doc: Update FAQ entry on filelists - build: Adapt to changes in Fedora packaging of bash-completion - Support RPMTRANS_FLAG_DEPLOOPS - Add all candidates for reinstall to solver - Fix handling installonly packages reasons - Remove confusing sentence from documentation - Remove "leaf" word from documentation - Update documentation of history userinstalled command - Onboard packit tests - doc: Makecache with timer tries only one mirror - ELN: Don't obsolete DNF with DNF5 yet - bash-completion: Complete dnf command only if we own it - bash-completion: Prepare ownerships for dnf5 switch * Fri Mar 29 2024 Evan Goode - 4.19.2-1 - Update to 4.19.2 - Bump libdnf requirement to 0.73.1 Package: giac-1.9.0.91-3.fc41 Old package: giac-1.9.0.91-2.fc40 Summary: Computer Algebra System, Symbolic calculus, Geometry RPMs: giac giac-devel giac-doc giac-xcas pgiac Size: 157.73 MiB Size change: -388.81 KiB Changelog: * Fri Mar 29 2024 Jerry James - 1.9.0.91-3 - Rebuild for cocoalib 0.99850 Package: gnome-shell-frippery-46.0-1.fc41 Old package: gnome-shell-frippery-45.1-3.fc40 Summary: Extensions to provide a user experience more like that of GNOME 2 RPMs: gnome-shell-extension-frippery-applications-menu gnome-shell-extension-frippery-bottom-panel gnome-shell-extension-frippery-move-clock gnome-shell-extension-frippery-panel-favorites Size: 287.23 KiB Size change: 94 B Changelog: * Fri Mar 29 2024 Davide Cavalca - 46.0-1 - Update to 46.0; Fixes: RHBZ#2272024 Package: google-api-python-client-2:2.124.0-1.fc41 Old package: google-api-python-client-2:2.123.0-1.fc41 Summary: Google APIs Client Library for Python RPMs: python3-google-api-client Size: 4.76 MiB Size change: 30 B Changelog: * Fri Mar 29 2024 Packit - 2:2.124.0-1 - [packit] 2.124.0 upstream release - Resolves: rhbz#2272163 Package: iwd-2.17-1.fc41 Old package: iwd-2.16-1.fc41 Summary: Wireless daemon for Linux RPMs: iwd Size: 2.46 MiB Size change: -3.93 KiB Changelog: * Sat Mar 30 2024 Peter Robinson - 2.17-1 - Ypdate to 2.17 Package: kernel-6.9.0-0.rc1.20240329git317c7bc0ef03.20.fc41 Old package: kernel-6.9.0-0.rc1.20240327git7033999ecd7b.18.fc41 Summary: The Li
Re: Three steps we could take to make supply chain attacks a bit harder
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 for Fedora to finally > realize that that exception has always been a bad idea. > […] CMIIW, but it would not have made any difference as the source code had been shipped as part of the tar ball and auto(re)conf would have happily integrated it into the next build. I suspect that a modification to CMakeLists.txt and its includes would not have been detected either; even a daring, but obvious change in the 3+ lines of source itself might have gone unnoticed. 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 shipped artifacts with their "make dist" equivalents and publishing the results. Tim -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 for years, and it > saddens me that something like this had to happen for Fedora to finally > realize that that exception has always been a bad idea. > > > That said, this is being tracked by the Packaging Committee: > > https://pagure.io/packaging-committee/issue/1350 > > Finally, thanks! (But you filed that only now after this incident, see > above. Still, thanks that you are bringing this up now!) > > > Yes, we should scrutinize things like this. Though I will note that we > > didn't actually suffer an attack through this venue with library code, > > just the build scripts. Generally, people do not pay attention to > > build scripts, and that was how this slipped by for so long. But even > > so, Autotools is particularly difficult to understand and I don't > > think we would have ordinarily caught it anyway. > > I definitely agree there, build scripts are indeed an attractive target for > backdoor authors, and autotools is indeed a big part of the problem. > > The whole architecture of autotools was designed for a situation that is > mostly obsolete these days: people running some proprietary Unix with some > buggy implementation of a Bourne-like shell and no centralized build tools > who want to just untar a tarball and build it with only what they already > have installed (the buggy shell). Hence all this concept of shipping > prebuilt obfuscated shell blobs full of workarounds for bugs in ancient > shell implementations. Nowadays, people are either running GNU/Linux, where > centralized build tools such as CMake or Meson are readily installable from > the repository (and where most builds are done by distributions, for whom it > is just a matter of adding, e.g., "BuildRequires: cmake"), or Microsoft > Windows, where an environment that can run autotools scripts (e.g., MSYS2) > is NOT part of the system and actually as hard or harder to install than > something like CMake. So, nowadays, pregenerating shell scripts is a > completely outdated and unhelpful way of working. > 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 tooling is there for developers and users to dig into it. > > That said, I agree that pretty much every display manager and > > compositor for every Fedora variant should be critpath'd. > > Well, where we disagree is that I actually want to see LESS stuff in > critpath, not more. It cannot be scrutinized well enough because there is > just too much stuff in it. E.g., at times, we had MySQL/MariaDB in critpath > because Akonadi required it. (Nowadays, Akonadi actually recommends using > SQLite instead.) That just does not make sense. > I didn't say every single one we package, just the ones shipped in deliverables. I think it's worth making sure those are on the critpath. -- 真実はいつも一つ!/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 Fedora to finally realize that that exception has always been a bad idea. > That said, this is being tracked by the Packaging Committee: > https://pagure.io/packaging-committee/issue/1350 Finally, thanks! (But you filed that only now after this incident, see above. Still, thanks that you are bringing this up now!) > Yes, we should scrutinize things like this. Though I will note that we > didn't actually suffer an attack through this venue with library code, > just the build scripts. Generally, people do not pay attention to > build scripts, and that was how this slipped by for so long. But even > so, Autotools is particularly difficult to understand and I don't > think we would have ordinarily caught it anyway. I definitely agree there, build scripts are indeed an attractive target for backdoor authors, and autotools is indeed a big part of the problem. The whole architecture of autotools was designed for a situation that is mostly obsolete these days: people running some proprietary Unix with some buggy implementation of a Bourne-like shell and no centralized build tools who want to just untar a tarball and build it with only what they already have installed (the buggy shell). Hence all this concept of shipping prebuilt obfuscated shell blobs full of workarounds for bugs in ancient shell implementations. Nowadays, people are either running GNU/Linux, where centralized build tools such as CMake or Meson are readily installable from the repository (and where most builds are done by distributions, for whom it is just a matter of adding, e.g., "BuildRequires: cmake"), or Microsoft Windows, where an environment that can run autotools scripts (e.g., MSYS2) is NOT part of the system and actually as hard or harder to install than something like CMake. So, nowadays, pregenerating shell scripts is a completely outdated and unhelpful way of working. > That said, I agree that pretty much every display manager and > compositor for every Fedora variant should be critpath'd. Well, where we disagree is that I actually want to see LESS stuff in critpath, not more. It cannot be scrutinized well enough because there is just too much stuff in it. E.g., at times, we had MySQL/MariaDB in critpath because Akonadi required it. (Nowadays, Akonadi actually recommends using SQLite instead.) That just does not make sense. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 bodhi updates. 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. Thanks, Michael Confusion is increasing a little among different channels, and it would be nice if the RH blog post and the Red Hat CVE page would be updated, and maybe clarified: According to Adam Williamson, F40 is likely to have installed the packages because testing is enabled by default in pre-release. If I got Rich right, the malicious code is likely to be broken on F40, but F40 users still should update to be sure. At the moment several "versions" and "assumptions" are rising that try to somehow make sense of the different publications (e.g., header of RH article "F41 and rawhide" -> headline in content "F40 and rawhide"). 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). Creating some clarification and unify our information provision can help to get rid of the current interpretations between "F40 - just don't care" and "F40 - the end of the world is coming" (sorry for the dramatization ;). I think one or two sentences in the RH blog post + RH CVE page should be fine to clarify, to avoid further confusion and to re-unify knowledge towards the facts, of course the same for the Fedora Magazine article but that's already underway. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 force the malicious > attacker to commit their code to version control, making it slightly > harder to hide the attack. Using a signed tarball is ideally better than a git tag (it's an extra level of author attestation)... but where both are available, it'd be nice to have a way to denote in the spec file that there are two URLs for the source. In this case, if both URLs were listed and something could be run to automatically fetch and compare them, the attack code would have been flagged. Just because something is public in a git tag doesn't mean somebody else reviewed it and caught an attack (after all, in this case, part of it was committed to git and at least one other maintainer didn't notice anything odd). -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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-to-host.m4 serial 30 > > But the one in the system (as of f39) is only 'serial 1'. > > > > Artificially lowering the serial back to 0 in the file and running > > `autoreconf -fi` again properly reinstall the one from the system over > > it, but anything higher will keep it... > > > > So if we want to go this route, we should remove the full m4 dir, but > > unfortunately I've seen quite a few projects that depend on non-standard > > m4 scripts so we'll need to fix these as we go... > > Well, it all depends on whether those m4 scripts are really source code or > whether they are autoimported from somewhere like gnulib. True source code > needs to be retained, anything that can be autoimported should be > autoimported at build time. (And upstreams should stop using imported > copylibs to begin with, but that is a different story.) > > > (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 will be fun) > > CMake! :-) > Funnily enough, xz can also be built with CMake. :) I don't know whether the CMake scripts are complete enough to switch to yet, but we should consider doing it. > >> (2) We should discourage gnulib as much as possible. > >> [...] > >> In the xz case it was a gnulib-derived script which was modified to do > >> 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 real one this > > morning and I would be hard pressed to say if either is backdoored just > > looking at either version... Admitedly it was 3AM when I looked at it, > > but I don't think it's just a late hour problem) > > That is exactly the problem with autotools code, almost nobody understands > what the heck it does, almost everybody just copies and pastes somebody > else's snippet hoping it does not do bad things. And gnulib is a > particularly ugly piece of the puzzle. > > > 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 patch: > https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch > which is what ultimately allowed this to happen. This drags in libsystemd > for sd_notify, and libsystemd is linked to way too much stuff including > liblzma. Either we need a split libsdnotify that contains only sd_notify, or > we should just stop using sd_notify at all. It increases the attack surface > of daemons a lot just to allow the service to be "Type=notify" rather than > one of the other available approaches. Arch Linux is also systemd-based > nowadays, but still does not link OpenSSH against libsystemd. > This is related to philosophical differences between Arch and Fedora. That said, it probably makes sense for sd_notify to be its own library instead of being part of libsystemd. I'm sure systemd upstream will consider it now. :) -- 真実はいつも一つ!/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 real one this > morning and I would be hard pressed to say if either is backdoored just > looking at either version... Admitedly it was 3AM when I looked at it, > but I don't think it's just a late hour problem) Right! Definitely not a 3am problem :-/ > > (3) We should have a "security path", like "critical path". ... > Before making each of these safer we should make sshd not link with so > many things in the first place. > On oss-security, Solar Designer made a lot of good points about it > (around here: https://www.openwall.com/lists/oss-security/2024/03/29/27 > , but the full thread is interesting) Agreed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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, generated shell script > > in an upstream './configure' looking for back doors. > > > > For most projects, just running "autoreconf -fiv" is enough. > > > > Yes, there are some projects that depend on a specific or old version > > of autoconf. We should fix those. But that doesn't need to delay us > > from using autoreconf on many projects today. > > I have always said that. We do not allow other prebuilt binary blobs and > require rebuilding everything from source. I do not see how the obfuscated > autogenerated shell scripts from the autotools are any different. Sadly, I > was ignored. Now you folks (Fedora) see where this leads. Told You So. > This is not helpful in the slightest and the tone is not appreciated at all. That said, this is being tracked by the Packaging Committee: https://pagure.io/packaging-committee/issue/1350 > > 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. > > Looks like autoreconf does not work as advertised. With -f, it is supposed > to regenerate all files that it knows how to regenerate. It clearly does not > do what it is supposed to and ought to be fixed. > > > (2) We should discourage gnulib as much as possible. > > > > In libvirt we took the decision a few years ago to remove gnulib. > > It's extremely convoluted and almost no one understands how it really > > works. It's written in obscure m4 macros and shell script. > > > > It's also not necessary for Linux since gnulib is mainly about > > porting to non-Linux platforms. There are better ways to do this. > > > > In the xz case it was a gnulib-derived script which was modified to do > > 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). > > There too, I agree completely. Also because gnulib is a "copylib", which is > a very broken concept. A true library would not be subject to this kind of > "take the file from the copylib and inject bad code into it" attack. > Yes, we should scrutinize things like this. Though I will note that we didn't actually suffer an attack through this venue with library code, just the build scripts. Generally, people do not pay attention to build scripts, and that was how this slipped by for so long. But even so, Autotools is particularly difficult to understand and I don't think we would have ordinarily caught it anyway. > > (3) We should have a "security path", like "critical path". > > > > sshd is linked to a lot of libraries: > > > > /lib64/libaudit.so.1audit-libs > > /lib64/libc.so.6glibc > > /lib64/libcap-ng.so.0 libcap-ng > > /lib64/libcap.so.2 libcap > > /lib64/libcom_err.so.2 libcom_err > > /lib64/libcrypt.so.2libxcrypt > > /lib64/libcrypto.so.3 openssl-libs > > /lib64/libeconf.so.0libeconf > > /lib64/libgcc_s.so.1libgcc > > /lib64/libgssapi_krb5.so.2 krb5-libs > > /lib64/libk5crypto.so.3 krb5-libs > > /lib64/libkeyutils.so.1 keyutils-libs > > /lib64/libkrb5.so.3 krb5-libs > > /lib64/libkrb5support.so.0 krb5-libs > > /lib64/liblz4.so.1 lz4-libs > > /lib64/liblzma.so.5 xz-libs > > /lib64/libm.so.6glibc > > /lib64/libpam.so.0 pam-libs > > /lib64/libpcre2-8.so.0 pcre2 > > /lib64/libresolv.so.2 glibc > > /lib64/libselinux.so.1 libselinux > > /lib64/libsystemd.so.0 systemd-libs > > /lib64/libz.so.1zlib / zlib-ng > > /lib64/libzstd.so.1 zstd > > > > 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 > > default. > > 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 in there, maybe the window manager, and no further. > I don't know if the security path package list would help any, since we still have no one to do security work. That said, I agree that pretty much every display manager and compositor for every Fedora variant should be critpath'd. -- 真実はいつも一つ!/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Co
Re: Three steps we could take to make supply chain attacks a bit harder
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 'serial 1'. > > Artificially lowering the serial back to 0 in the file and running > `autoreconf -fi` again properly reinstall the one from the system over > it, but anything higher will keep it... > > So if we want to go this route, we should remove the full m4 dir, but > unfortunately I've seen quite a few projects that depend on non-standard > m4 scripts so we'll need to fix these as we go... Well, it all depends on whether those m4 scripts are really source code or whether they are autoimported from somewhere like gnulib. True source code needs to be retained, anything that can be autoimported should be autoimported at build time. (And upstreams should stop using imported copylibs to begin with, but that is a different story.) > (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 will be fun) CMake! :-) >> (2) We should discourage gnulib as much as possible. >> [...] >> In the xz case it was a gnulib-derived script which was modified to do >> 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 real one this > morning and I would be hard pressed to say if either is backdoored just > looking at either version... Admitedly it was 3AM when I looked at it, > but I don't think it's just a late hour problem) That is exactly the problem with autotools code, almost nobody understands what the heck it does, almost everybody just copies and pastes somebody else's snippet hoping it does not do bad things. And gnulib is a particularly ugly piece of the puzzle. > 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 patch: https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch which is what ultimately allowed this to happen. This drags in libsystemd for sd_notify, and libsystemd is linked to way too much stuff including liblzma. Either we need a split libsdnotify that contains only sd_notify, or we should just stop using sd_notify at all. It increases the attack surface of daemons a lot just to allow the service to be "Type=notify" rather than one of the other available approaches. Arch Linux is also systemd-based nowadays, but still does not link OpenSSH against libsystemd. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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. > > For most projects, just running "autoreconf -fiv" is enough. > > Yes, there are some projects that depend on a specific or old version > of autoconf. We should fix those. But that doesn't need to delay us > from using autoreconf on many projects today. I have always said that. We do not allow other prebuilt binary blobs and require rebuilding everything from source. I do not see how the obfuscated autogenerated shell scripts from the autotools are any different. Sadly, I was ignored. Now you folks (Fedora) see where this leads. Told You So. > 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. Looks like autoreconf does not work as advertised. With -f, it is supposed to regenerate all files that it knows how to regenerate. It clearly does not do what it is supposed to and ought to be fixed. > (2) We should discourage gnulib as much as possible. > > In libvirt we took the decision a few years ago to remove gnulib. > It's extremely convoluted and almost no one understands how it really > works. It's written in obscure m4 macros and shell script. > > It's also not necessary for Linux since gnulib is mainly about > porting to non-Linux platforms. There are better ways to do this. > > In the xz case it was a gnulib-derived script which was modified to do > 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). There too, I agree completely. Also because gnulib is a "copylib", which is a very broken concept. A true library would not be subject to this kind of "take the file from the copylib and inject bad code into it" attack. > (3) We should have a "security path", like "critical path". > > sshd is linked to a lot of libraries: > > /lib64/libaudit.so.1audit-libs > /lib64/libc.so.6glibc > /lib64/libcap-ng.so.0 libcap-ng > /lib64/libcap.so.2 libcap > /lib64/libcom_err.so.2 libcom_err > /lib64/libcrypt.so.2libxcrypt > /lib64/libcrypto.so.3 openssl-libs > /lib64/libeconf.so.0libeconf > /lib64/libgcc_s.so.1libgcc > /lib64/libgssapi_krb5.so.2 krb5-libs > /lib64/libk5crypto.so.3 krb5-libs > /lib64/libkeyutils.so.1 keyutils-libs > /lib64/libkrb5.so.3 krb5-libs > /lib64/libkrb5support.so.0 krb5-libs > /lib64/liblz4.so.1 lz4-libs > /lib64/liblzma.so.5 xz-libs > /lib64/libm.so.6glibc > /lib64/libpam.so.0 pam-libs > /lib64/libpcre2-8.so.0 pcre2 > /lib64/libresolv.so.2 glibc > /lib64/libselinux.so.1 libselinux > /lib64/libsystemd.so.0 systemd-libs > /lib64/libz.so.1zlib / zlib-ng > /lib64/libzstd.so.1 zstd > > 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 > default. 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 in there, maybe the window manager, and no further. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Obsoleted packages in F40
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 that were removed intentionally. See the list at the end of my email. 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 the end mention adding the package to https://src.fedoraproject.org/rpms/fedora-obsolete-packages I do not think the "Completely Removing a Package" section is meant for the cases you mention. The only example given in that section is licensing issues, i.e. a situation where Fedora was actually not even allowed to distribute the package, either because of the license conditions, or because of Fedora's own bylaws. On the other hand, you do not have to refer to that section if you want to remind packages about fedora-obsolete-packages. Right before there is "Obsoleting Packages", which asks to consider obsoleting for every retirement. The point of fedora-obsolete-packages is to remove packages that actually BREAK things when they remain installed. Otherwise, the best thing to do is to NOT obsolete those packages. Users might still rely on them. E.g., they might have locally built software that depends on the dropped compatibility libraries. Forcefully obsoleting those will break the locally installed software. I have wondered at this approach even since I discovered that Fedora actually handles retired packages on distro upgrade like this. In today's always-connected IT environment full of malicious actors and threats, I consider it a basic principle to only have software that is kept up-to-date by *somebody*. For stuff I built and/or installed by myself, I take that responsibility myself, and suffer the consequences when I fail to deliver. But if distribution stops providing upgrades to a package, I would expect it be removed automatically. So, I would actually much prefer if package retirement automatically added the package to fedora-obsolete-packages. Perhaps there are special cases where that would not be a good idea - if there are some, `fedpkg retire` could have a flag to prevent that from happening. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 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 'serial 1'. Artificially lowering the serial back to 0 in the file and running `autoreconf -fi` again properly reinstall the one from the system over it, but anything higher will keep it... So if we want to go this route, we should remove the full m4 dir, but unfortunately I've seen quite a few projects that depend on non-standard m4 scripts so we'll need to fix these as we go... (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 will be fun) > (2) We should discourage gnulib as much as possible. > [...] > In the xz case it was a gnulib-derived script which was modified to do > 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 real one this morning and I would be hard pressed to say if either is backdoored just looking at either version... Admitedly it was 3AM when I looked at it, but I don't think it's just a late hour problem) > (3) We should have a "security path", like "critical path". > > sshd is linked to a lot of libraries: > > /lib64/libaudit.so.1audit-libs > /lib64/libc.so.6glibc > /lib64/libcap-ng.so.0 libcap-ng > /lib64/libcap.so.2 libcap > /lib64/libcom_err.so.2 libcom_err > /lib64/libcrypt.so.2libxcrypt > /lib64/libcrypto.so.3 openssl-libs > /lib64/libeconf.so.0libeconf > /lib64/libgcc_s.so.1libgcc > /lib64/libgssapi_krb5.so.2 krb5-libs > /lib64/libk5crypto.so.3 krb5-libs > /lib64/libkeyutils.so.1 keyutils-libs > /lib64/libkrb5.so.3 krb5-libs > /lib64/libkrb5support.so.0 krb5-libs > /lib64/liblz4.so.1 lz4-libs > /lib64/liblzma.so.5 xz-libs > /lib64/libm.so.6glibc > /lib64/libpam.so.0 pam-libs > /lib64/libpcre2-8.so.0 pcre2 > /lib64/libresolv.so.2 glibc > /lib64/libselinux.so.1 libselinux > /lib64/libsystemd.so.0 systemd-libs > /lib64/libz.so.1zlib / zlib-ng > /lib64/libzstd.so.1 zstd > > 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 > default. Before making each of these safer we should make sshd not link with so many things in the first place. On oss-security, Solar Designer made a lot of good points about it (around here: https://www.openwall.com/lists/oss-security/2024/03/29/27 , but the full thread is interesting) But that's specific to sshd, and this problem could happen with any network-facing service: I guess sshd is a juciy target because it runs as root (whereas backdooring e.g. nginx would run as www user and not be as interesting), but in practice that could be bad enough. (hm, well, your point about 'enabled by default' strikes home though - we definitely could pay more attention to these first) -- Dominique Martinet | Asmadeus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bad error on console / shell ... any idea ! ?
... 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:23 UTC 2024 x86_64 GNU/Linux -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 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 force the malicious attacker to commit their code to version control, making it slightly harder to hide the attack. Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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 > default. It sounds like a good plan to put certain dependencies on a critical path. Perhaps anything that is used by packages included in the various editions of Fedora that allow for remote access (even if disabled by default) could fall under that path? We could also try to ensure that packages do not contain any binary blobs and instead require generation scripts for those that we can run ourselves. Regards, Simon -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bad error on console / shell ... any idea ! ?
> 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 not found > terminate called after throwing an instance of 'std::invalid_argument' > what(): stoi I hear that this is a known issue with dnf5 at the moment. Just to check, you are aware that dnf5 is still being developed? Barry -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
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' looking for back doors. For most projects, just running "autoreconf -fiv" is enough. Yes, there are some projects that depend on a specific or old version of autoconf. We should fix those. But that doesn't need to delay us from using autoreconf on many projects today. 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. There were also projects where configure script was generated long time ago and then edited by hand. Usually because no one in project knew m4. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
bad error on console / shell ... any idea ! ?
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_ref: command not found terminate called after throwing an instance of 'std::invalid_argument' what(): stoi This Ctrl + c key's is working ... [root@fedora mythcat]# dnf5 search sc^C I used : [root@fedora mythcat]# uname -a Linux fedora 6.9.0-0.rc1.20240327git7033999ecd7b.18.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 27 17:29:23 UTC 2024 x86_64 GNU/Linux I saw many changes from the last kernel change : [mythcat@fedora ~]$ dmesg dmesg: read kernel buffer failed: Operation not permitted The sudo su ... dmesg works, I blank with xx and _ [ 1759.140985] b43-phy0: Loading OpenSource firmware version 410.31754 [ 1759.141004] b43-phy0: Hardware crypto acceleration not supported by firmware [ 1760.372002] b43-phy0: Loading OpenSource firmware version 410.31754 [ 1760.372025] b43-phy0: Hardware crypto acceleration not supported by firmware [ 1760.595133] wlan0: WMM/QoS not supported, limiting to legacy [ 1760.595145] wlan0: determined local STA to be legacy, BW limited to 20 MHz [ 1760.595210] wlan0: determined AP to be legacy [ 1760.595216] wlan0: connecting with legacy mode, max bandwidth 20 MHz [ 1760.610936] wlan0: authenticate with __ (local address=xx) [ 1760.610949] wlan0: send auth to__ (try 1/3) [ 1760.612806] wlan0: ___denied authentication (status 1) [ 1771.594129] wlan0: WMM/QoS not supported, limiting to legacy [ 1771.594142] wlan0: determined local STA to be legacy, BW limited to 20 MHz [ 1771.594211] wlan0: determined AP __ to be legacy [ 1771.594217] wlan0: connecting with legacy mode, max bandwidth 20 MHz [ 1771.605277] wlan0: authenticate with xx:xx:xx:xx:xx:xx (local address=xxx) [ 1771.605290] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) [ 1771.607584] wlan0: 38:43:7d:66:d6:4c denied authentication (status 1) [ 1786.138125] b43-phy0: Loading OpenSource firmware version 410.31754 [ 1786.138146] b43-phy0: Hardware crypto acceleration not supported by firmware -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Three steps we could take to make supply chain attacks a bit harder
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, generated shell script in an upstream './configure' looking for back doors. For most projects, just running "autoreconf -fiv" is enough. Yes, there are some projects that depend on a specific or old version of autoconf. We should fix those. But that doesn't need to delay us from using autoreconf on many projects today. 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. (2) We should discourage gnulib as much as possible. In libvirt we took the decision a few years ago to remove gnulib. It's extremely convoluted and almost no one understands how it really works. It's written in obscure m4 macros and shell script. It's also not necessary for Linux since gnulib is mainly about porting to non-Linux platforms. There are better ways to do this. In the xz case it was a gnulib-derived script which was modified to do 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). (3) We should have a "security path", like "critical path". sshd is linked to a lot of libraries: /lib64/libaudit.so.1audit-libs /lib64/libc.so.6glibc /lib64/libcap-ng.so.0 libcap-ng /lib64/libcap.so.2 libcap /lib64/libcom_err.so.2 libcom_err /lib64/libcrypt.so.2libxcrypt /lib64/libcrypto.so.3 openssl-libs /lib64/libeconf.so.0libeconf /lib64/libgcc_s.so.1libgcc /lib64/libgssapi_krb5.so.2 krb5-libs /lib64/libk5crypto.so.3 krb5-libs /lib64/libkeyutils.so.1 keyutils-libs /lib64/libkrb5.so.3 krb5-libs /lib64/libkrb5support.so.0 krb5-libs /lib64/liblz4.so.1 lz4-libs /lib64/liblzma.so.5 xz-libs /lib64/libm.so.6glibc /lib64/libpam.so.0 pam-libs /lib64/libpcre2-8.so.0 pcre2 /lib64/libresolv.so.2 glibc /lib64/libselinux.so.1 libselinux /lib64/libsystemd.so.0 systemd-libs /lib64/libz.so.1zlib / zlib-ng /lib64/libzstd.so.1 zstd 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 default. These are just my thoughts on a Saturday morning. Feedback welcome of course. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 > distributions by the culprit. I have to say that this is not unusual. I myself have even sent messages to other maintainers encouraging them to package or update projects that I've written. A keen upstream maintainer wanting to help or encourage downstream packagers is normally welcome. This is the one case and only case that someone turned out to be malicious (that we know about). They abused our trust. > Are they a contributor to any other software in the distribution? I > think anything they might have touched has to be considered suspect. Yes I agree that anything else touched by this "person" should be considered very suspect. > Either (a) their systems have been completely compromised or (b) they > did this intentionally. Neither is good. The back door is intentional for sure. We don't know the details of if this is an account take-over or a "long con" and what the background to all this is, but I'm sure people are looking into that. > > (2) We got reports later of a valgrind test failure. I also saw it > > myself in my own projects that use liblzma. We notified Jia Tan of > > this. > > Why does libsystemd pull in libzma (as well as liblz4 and libzstd, > because we need three compression libraries in one place)? That seems > to be a broad amount of extra code, for a library that's in a number of > network-listening services is just linked for socket activation. This is a very real issue. Got another email coming up in a bit about this. > Also, while it appears there's more than one developer with Github > commit access (one other made commits since the initial "bad" commit), > it would seem they aren't doing reviews, so not sure how much xz/liblzma > can be trusted to be linked into a whole lot of key programs. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: xz backdoor
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 to the wrong article. I meant to link to [1] which says > that "At this time the Fedora Linux 40 builds have not been shown to be > compromised. We believe the malicious code injection did not take > effect in these builds." But this statement contradicts my findings > above, and you just replied "yes" to those, implying that my > understanding is correct. So I guess either this blog post is wrong and > needs to be updated, or you're wrong about me being right. Er, correct? > :) FWIW, I wrote that text, modified from a slightly different version in the earlier draft that was briefly published, and based on my best understanding at the time (which was that *no* build that reached F40 actually had a working version of the exploit). If Richard says the exploit potentially worked in 5.6.0-2, then F40 potentially *was* vulnerable for some time, because 5.6.0-2 reached updates-testing. You can use `dnf history info xz` to check if you ever had the vulnerable version installed. I'll see if we can get the post tweaked again; it will be hard to word it with the appropriate level of accuracy and urgency and still be readable, but I'll try... Oh, and we can't easily fix the URL of the blog post, apparently, because CMSes suck. It seems we're more less stuck with the "41" in that. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue