On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote:
> On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:
> > Adam,
> >
> > Is there a way already to achieve test isolation during the rpm build?
>
> Nothing systematic that I'm aware of, no. It would be tricky
On Mon, Apr 01, 2024 at 09:06:16AM +0900, Dominique Martinet wrote:
> Scott Schmit wrote on Sun, Mar 31, 2024 at 05:02:44PM -0400:
> > Deleting the tests makes no sense to me either, but it seems like a
> > mechanism that ensures the test code can't change the build outputs (or
> > a mechanism to
On Mon, Apr 01, 2024 at 08:46:39AM -, François Rigault wrote:
> To echo
>
> > To trust code, it needs to be reviewed.
> > If the code is reviewed, and the build system is sane, [..]
>
> I deduce from your response that the binary tests committed in
> systemd were not reviewed neither by
On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > Maybe this needs to go on the growing pile of reasons why the
> > traditional Linux model *does* need to go away. Maybe Fedora, with its
> > foundation of First, should be kind of at the forefront
To echo
> To trust code, it needs to be reviewed.
> If the code is reviewed, and the build system is sane, [..]
I deduce from your response that the binary tests committed in systemd were not
reviewed neither by co-maintainers nor by downstream package maintainers.
I understand that the build
On Sun, 2024-03-31 at 20:27 -0700, Adam Williamson wrote:
>
> > What WOULD have greatly reduced the impact of this attack:
> > * NOT enabling updates-testing by default for Branched releases.
>
> This would only have helped by coincidence - the coincidence that the
> compromise was discovered so
On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:
> Adam,
>
> Is there a way already to achieve test isolation during the rpm build?
Nothing systematic that I'm aware of, no. It would be tricky because
there is no one universal Standard Test System (not even within a
single
Adam,
Is there a way already to achieve test isolation during the rpm build?
Beside doing something ad-hoc with git init or some file system feature,
I was wondering if there is something already available and standardized.
Regards,
Carlos R.F.
On 3/31/24 20:27, Adam Williamson wrote:
On
+1
Am 01.04.24 um 06:31 schrieb Scott Schmit:
One approach:
1. do the build
2. do the install
3. generate the RPMs
4. quarantine the RPMs so they're safe from modification
- I believe this could be done via SELinux policy
- there are probably other mechanisms
5. run the tests
- for
On Mon, Apr 01, 2024 at 09:06:16AM +0900, Dominique Martinet wrote:
> Scott Schmit wrote on Sun, Mar 31, 2024 at 05:02:44PM -0400:
> > Deleting the tests makes no sense to me either, but it seems like a
> > mechanism that ensures the test code can't change the build outputs (or
> > a mechanism to
On Sun, 2024-03-31 at 20:12 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > I would argue there's a danger of getting too tied up in very specific
> > technical details of this attack.
>
> But the fact is:
>
> What WOULD have stopped this attack: (one or more of:)
> * Deleting
Regarding downstream defense, prohibiting blobs or differences between
tars and git repos may be overkill or difficult at this moment, but a
tool to assist maintainers in the identification and analysis of these
situations where attacks may be hidden into can be very helpful.
Regarding the
Am 31.03.24 um 23:02 schrieb Scott Schmit:
On Sun, Mar 31, 2024 at 04:09:36PM -0400, Ben Beasley wrote:
On 3/31/24 2:12 PM, Kevin Kofler via devel wrote:
But the fact is:
What WOULD have stopped this attack: (one or more of:)
* Deleting ALL unit tests in %prep (and then of course not trying
Am 31.03.24 um 21:19 schrieb Simon de Vlieger:
I don't quite agree with you. Two factor authentication whether an actual second
factor device or not does prevent credential stuffing which is a common attack
method that is easy to perform. It is when people take databases of previously
leaked
Scott Schmit wrote on Sun, Mar 31, 2024 at 05:02:44PM -0400:
> Deleting the tests makes no sense to me either, but it seems like a
> mechanism that ensures the test code can't change the build outputs (or
> a mechanism to detect that it's happened and abort the build) would
> allow upstream tests
On Sun, Mar 31, 2024 at 04:09:36PM -0400, Ben Beasley wrote:
> On 3/31/24 2:12 PM, Kevin Kofler via devel wrote:
> > But the fact is:
> >
> > What WOULD have stopped this attack: (one or more of:)
> > * Deleting ALL unit tests in %prep (and then of course not trying to run
> > them later).
>
On Sun, Mar 31, 2024 at 5:35 PM Kevin Kofler via devel
wrote:
>
> Adam Williamson wrote:
> > Do we require 2FA for provenpackager yet?
>
> No. I am a provenpackager and do not have 2FA enabled (nor do I want it to
> be).
Whenever 2FA comes up, the requirement
for provenpackages to have it
On 3/31/24 2:12 PM, Kevin Kofler via devel wrote:
But the fact is:
What WOULD have stopped this attack: (one or more of:)
* Deleting ALL unit tests in %prep (and then of course not trying to run
them later).
While it’s technically correct that deleting tests would have disrupted
this specific
Hi Kevin,
On Sun, Mar 31, 2024, at 7:31 PM, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
>> Do we require 2FA for provenpackager yet?
>
> No. I am a provenpackager and do not have 2FA enabled (nor do I want it to
> be).
>
>> People would say, justifiably so, that it was absolutely
Adam Williamson wrote:
> I would argue there's a danger of getting too tied up in very specific
> technical details of this attack.
But the fact is:
What WOULD have stopped this attack: (one or more of:)
* Deleting ALL unit tests in %prep (and then of course not trying to run
them later).
*
Adam Williamson wrote:
> Maybe this needs to go on the growing pile of reasons why the
> traditional Linux model *does* need to go away. Maybe Fedora, with its
> foundation of First, should be kind of at the forefront of making that
> happen.
Switching to a container-based model is just going to
On Sun, 31 Mar 2024, Neal Gompa wrote:
On Sun, Mar 31, 2024 at 7:36 AM Arthur Bols wrote:
On 31/03/2024 13:03, Kevin Kofler via devel wrote:
This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for
contributors for a while, starting with "important" projects, then getting
Adam Williamson wrote:
> Do we require 2FA for provenpackager yet?
No. I am a provenpackager and do not have 2FA enabled (nor do I want it to
be).
> People would say, justifiably so, that it was absolutely unacceptable for
> us to be allowing single-factor authentication for contributors to a
>
On Sun, Mar 31, 2024 at 09:39:43AM -0700, Kevin Fenzi wrote:
> On Sun, Mar 31, 2024 at 09:12:30AM -0700, Adam Williamson wrote:
> > Thanks Arthur, yes, that was *exactly* the point.
> >
> > I would argue there's a danger of getting too tied up in very specific
> > technical details of this
On Sun, Mar 31, 2024 at 09:12:30AM -0700, Adam Williamson wrote:
> Thanks Arthur, yes, that was *exactly* the point.
>
> I would argue there's a danger of getting too tied up in very specific
> technical details of this attack. Yes, it's reasonable to think of ways
> to mitigate those specific
On Sun, 2024-03-31 at 07:42 -0400, Neal Gompa wrote:
> On Sun, Mar 31, 2024 at 7:36 AM Arthur Bols wrote:
> >
> > On 31/03/2024 13:03, Kevin Kofler via devel wrote:
> >
> > This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for
> > contributors for a while, starting with
On Sun, 2024-03-31 at 13:28 +0100, Daniel P. Berrangé wrote:
> >
> > 3. We have no mechanism to flag when J. Random Packager adds
> > "Supplements: glibc" to their random leaf node package. As a reminder,
> > *we are a project that allows 1,601 minimally-vetted people to deliver
> > arbitrary
On Sun, 2024-03-31 at 13:35 +0200, Arthur Bols wrote:
> On 31/03/2024 13:03, Kevin Kofler via devel wrote:
> > This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for
> > contributors for a while, starting with "important" projects, then getting
> > stricter and stricter. It has
On Sun, 2024-03-31 at 13:03 +0200, Kevin Kofler via devel wrote:
>
> > 2. Our process for vetting packagers is, let's face it, from a security
> > perspective almost *comically* patchy. There are 140 sponsors in the
> > packager FAS group. Any one of those people - or someone who
> > compromises
On Sun, Mar 31, 2024 at 07:42:24AM -0400, Neal Gompa wrote:
>
> At this point, I'm used to MFA for stuff (and I use a password manager
> that handles 2FA OTPs too), but the Fedora implementation of MFA is
> uniquely bad because we have to do a lot in the terminal, and our MFA
> implementation
BTW, adding comments to myself, the signed commits and their
verification takes care of problems 2FA doesn't. First, ensure
authorship information (2FA doesn't leave a mark in the commit), and
protects the integrity of the downstream source: the build can ensure
that the checked out downstream
Going in that same route, if 2FA becomes mandatory, then we have a
stronger defense of the GPG public key in the user profile. The attacker
would need not only the credentials, but the 2FA device to change the
public GPG.
That then makes one step further possible: enforce commit signing on
On Sun, Mar 31, 2024 at 8:58 AM Adam Williamson
wrote:
> 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still
> don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE
> COMPULSORY 2FA FOR FEDORA PACKAGERS*.
What is the status of the FIDO2 implementation in the
On Sat, Mar 30, 2024 at 09:37:44AM +, Richard W.M. Jones wrote:
> 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
On Sun, Mar 31, 2024 at 01:58:21AM -0700, Adam Williamson wrote:
> On Sat, 2024-03-30 at 09:37 +, Richard W.M. Jones wrote:
> > I'm not pretending these will solve everything, but they should make
> > attacks a little harder in future.
>
> I don't disagree with Richard's list. However...more
On 31/03/2024 13:42, Neal Gompa wrote:
At this point, I'm used to MFA for stuff (and I use a password manager
that handles 2FA OTPs too), but the Fedora implementation of MFA is
uniquely bad because we have to do a lot in the terminal, and our MFA
implementation sucks for terminal usage.
If MFA
On Sun, Mar 31, 2024 at 09:07:21AM -, François Rigault wrote:
> hi Zbyszek,
> how did you review the corrupted journal files committed in systemd? Can you
> know for certain that they do not contain any backdoor or anything illegal or
> unlicensed?
The licensing and legal side is easy:
On Sun, Mar 31, 2024 at 7:36 AM Arthur Bols wrote:
>
> On 31/03/2024 13:03, Kevin Kofler via devel wrote:
>
> This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for
> contributors for a while, starting with "important" projects, then getting
> stricter and stricter. It has done
On 31/03/2024 13:03, Kevin Kofler via devel wrote:
This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for
contributors for a while, starting with "important" projects, then getting
stricter and stricter. It has done absolutely nothing to stop this attack.
How could it, when the
Adam Williamson wrote:
> 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still
> don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE
> COMPULSORY 2FA FOR FEDORA PACKAGERS*.
This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for
contributors
On 31/03/2024 10:58, Adam Williamson wrote:
1. We *still don't have compulsory 2FA for Fedora packagers*. We *still
don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE
COMPULSORY 2FA FOR FEDORA PACKAGERS*.
This finally motivated me to enable 2fa for my Fedora acount...
An
Dne 31. 03. 24 v 10:58 dop. Adam Williamson napsal(a):
1. Westill don't have compulsory 2FA for Fedora packagers. We *still
don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE
COMPULSORY 2FA FOR FEDORA PACKAGERS*.
Fair enough.
Let's do something about it:
hi Zbyszek,
how did you review the corrupted journal files committed in systemd? Can you
know for certain that they do not contain any backdoor or anything illegal or
unlicensed?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
On Sat, 2024-03-30 at 09:37 +, Richard W.M. Jones wrote:
> I'm not pretending these will solve everything, but they should make
> attacks a little harder in future.
I don't disagree with Richard's list. However...more in regards to some
of the grandiose ideas in later posts than Richard's
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.
>
>
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
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
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
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
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
> > >
> > >
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
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
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
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
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
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
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
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
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
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
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,
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
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,
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,
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
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
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
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
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
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
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
>
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
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
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
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
>
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
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
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
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
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
> > >
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
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
> > > >
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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:
> > #
101 - 200 of 208 matches
Mail list logo
