date:20240330

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

2024-03-30 Thread Germano Massullo


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

2024-03-30 Thread Sandro

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

2024-03-30 Thread Michel Lind

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

2024-03-30 Thread Ben Beasley

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

2024-03-30 Thread Chris Adams

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

2024-03-30 Thread Daniel Alley

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

2024-03-30 Thread Christopher Klooz

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

2024-03-30 Thread Daniel Alley

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

2024-03-30 Thread Otto Liljalaakso


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

2024-03-30 Thread Gordon Messmer


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

2024-03-30 Thread Stephen Smoogen

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

2024-03-30 Thread Carlos Rodriguez-Fernandez


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

2024-03-30 Thread Dmitry Belyavskiy

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

2024-03-30 Thread Artem S. Tashkinov via devel

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

2024-03-30 Thread Kilian Hanich via devel


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

2024-03-30 Thread Artem S. Tashkinov via devel

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

2024-03-30 Thread Germano Massullo


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

2024-03-30 Thread Sandro


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

2024-03-30 Thread Chris Adams

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

2024-03-30 Thread Dmitry Belyavskiy

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

2024-03-30 Thread Daniel Alley

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 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 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, 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

2024-03-30 Thread Stephen Smoogen

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

2024-03-30 Thread Artem S. Tashkinov via devel

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

2024-03-30 Thread Adam Williamson

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

2024-03-30 Thread Kilian Hanich via devel


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

2024-03-30 Thread Carlos Rodriguez-Fernandez

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

2024-03-30 Thread Miroslav Suchý


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

2024-03-30 Thread Todd Zullinger

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

2024-03-30 Thread Miroslav Suchý


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

2024-03-30 Thread Sam Varshavchik


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

2024-03-30 Thread Christopher Klooz


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

2024-03-30 Thread Gary Buhrmaster

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

2024-03-30 Thread Fedora Branched Report

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 bindings

Fedora rawhide compose report: 20240330.n.0 changes

2024-03-30 Thread Fedora Rawhide Report

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 Linux k

Re: Three steps we could take to make supply chain attacks a bit harder

2024-03-30 Thread Tim Landscheidt

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

2024-03-30 Thread Christopher Klooz


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

2024-03-30 Thread Chris Adams

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

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

2024-03-30 Thread Otto Liljalaakso


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

2024-03-30 Thread Dominique Martinet

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 ! ?

2024-03-30 Thread Cătălin George Feștilă

... 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

2024-03-30 Thread Simon de Vlieger

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 ! ?

2024-03-30 Thread Barry Scott



> 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

2024-03-30 Thread Marcin Juszkiewicz


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 ! ?

2024-03-30 Thread Cătălin George Feștilă

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