On Sat, 2024-03-30 at 16:41 -0700, Kevin Fenzi wrote:
> On Sat, Mar 30, 2024 at 11:12:02PM +0100, Sandro wrote:
> >
> > From what I understood, F40 Beta, the official Beta release, available from
> > the website as of March 26, has updates-testing disabled by default. That
>
> Nope.
>
> > was c
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 list
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
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: https://pagure.io/fe
On 31-03-2024 00:41, Kevin Fenzi wrote:
On Sat, Mar 30, 2024 at 11:12:02PM +0100, Sandro wrote:
From what I understood, F40 Beta, the official Beta release, available from
the website as of March 26, has updates-testing disabled by default. That
Nope.
was confirmed by several people in #de
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 imp
OLD: Fedora-Rawhide-20240330.n.0
NEW: Fedora-Rawhide-20240331.n.0
= SUMMARY =
Added images:3
Dropped images: 4
Added packages: 2
Dropped packages:0
Upgraded packages: 30
Downgraded packages: 0
Size of added packages: 3.92 MiB
Size of dropped packages:0 B
Kevin Fenzi wrote:
> Branched enables updates-testing... so if you installed f40 anytime, you
> will have it enabled and if you then applied updates it would be in them
Yet another thing I always said was a bad idea, and this incident proves it.
This would have been filtered before reaching most
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 for
Otto Liljalaakso wrote:
> 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 happeni
On Sun, Mar 31, 2024 at 6:50 AM Kevin Kofler via devel
wrote:
>
> Kevin Fenzi wrote:
> > Branched enables updates-testing... so if you installed f40 anytime, you
> > will have it enabled and if you then applied updates it would be in them
>
> Yet another thing I always said was a bad idea, and thi
Kevin Kofler via devel kirjoitti 31.3.2024 klo 14.14:
Otto Liljalaakso wrote:
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
retir
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 b
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 ab
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: those
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 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 i
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 is
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 an
On Sun, 31 Mar 2024 at 13:55, Christopher Klooz wrote:
[..]
BTW all that scandal with xz backdoor.
Looks like if fedora spec file would be using not
Source0:
https://github.com/tukaani-project/%{name}/releases/download/v%{version}/%{name}-%{version}.tar.gz
but
Source0:
https://github.com/tukaan
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
a
OLD: Fedora-40-20240330.n.0
NEW: Fedora-40-20240331.n.0
= SUMMARY =
Added images:1
Dropped images: 2
Added packages: 58
Dropped packages:0
Upgraded packages: 163
Downgraded packages: 0
Size of added packages: 6.80 MiB
Size of dropped packages:0 B
Size of
On Sun, Mar 31 2024 at 12:55:23 PM +00:00:00, Christopher Klooz
wrote:
In case someone from the Fedora Magazine is in the devel mailing list
and reads this:
I'm really frustrated with our communication regarding this issue. Does
anybody know who can fix this?
If we don't know who can fix Fe
On Sun, Mar 31 2024 at 07:15:42 AM -04:00:00, Neal Gompa
wrote:
Well, an easy solution is to make it so "dnf update" is coerced to
"dnf distro-sync" for development releases. Then it doesn't matter. We
could make that happen for Fedora 41 with the DNF 5 transition
(there's already code to make t
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 the
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
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 suck
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 a
On 31/03/2024 16.56, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 12:55:23 PM +00:00:00, Christopher Klooz
wrote:
In case someone from the Fedora Magazine is in the devel mailing list and reads
this:
I'm really frustrated with our communication regarding this issue. Does anybody
know wh
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 don
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 code
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 "import
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 mec
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 attack.
Neal Gompa wrote:
> Well, an easy solution is to make it so "dnf update" is coerced to
> "dnf distro-sync" for development releases.
That would not have helped containing this vulnerability. Keeping updates-
testing disabled by default would have.
Kevin Kofler
--
_
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, 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
stric
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 i
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).
* Dele
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication regarding this issue.
Does anybody know who can fix this?
The Fedora Magazine article has been fixed (thanks!).
--
___
devel mailing
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication regarding this issue. Does anybody
know who can fix this?
The Fedora Magazine article has been fixed (thanks!).
"*Fedora Linux
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication regarding this issue. Does anybody
know who can fix this?
The Fedora Magazine art
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 unacc
On 31-03-2024 20:54, Christopher Klooz wrote:
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication regarding this issue.
Does anybody kno
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 a
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 enabled
Am 31.03.24 um 21:33 schrieb Sandro:
On 31-03-2024 20:54, Christopher Klooz wrote:
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:
I'm really frustrated with our communication r
Just to be clear, as I was getting ready to put 40 Beta on a test
machine, this has been fixed. I do the install and run updates and the
compromised version of xz is never installed?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
On 31/03/2024 22.30, Leon Fauster via devel wrote:
Am 31.03.24 um 21:33 schrieb Sandro:
On 31-03-2024 20:54, Christopher Klooz wrote:
On 31/03/2024 20.52, Christopher Klooz wrote:
On 31/03/2024 20.21, Michael Catanzaro wrote:
On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
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).
> While
On Sun, Mar 31, 2024 at 03:52:12PM -0500, Alex Thomas wrote:
> Just to be clear, as I was getting ready to put 40 Beta on a test
> machine, this has been fixed. I do the install and run updates and the
> compromised version of xz is never installed?
Correct.
kevin
signature.asc
Description: PGP
On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:
>
> Not sure, if it was already mentioned -> containers. I had here a toolbox
> environment with F40. That I had not in my first actions
> on the screen. The last state had 5.6.0-3 installed but not sure
> if the previous rele
On Sun, Mar 31, 2024 at 08:55:37PM +, Christopher Klooz wrote:
> The repo files should be the same on Fedora containers, so if the container
> is F40 and the testing repo is enabled, it might have installed the malicious
> build.
Right, if it was dnf updated during the time that the bad upda
On 31/03/2024 23.11, Kevin Fenzi wrote:
On Sun, Mar 31, 2024 at 08:55:37PM +, Christopher Klooz wrote:
The repo files should be the same on Fedora containers, so if the container is
F40 and the testing repo is enabled, it might have installed the malicious
build.
Right, if it was dnf upda
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 t
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
pas
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 to
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 l
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 A
# Fedora Quality Assurance Meeting
# Date: 2024-04-01
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location:
https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
Greetings testers! It's meeting time again, and once again we'
# F40 Blocker Review meeting
# Date: 2024-04-01
# Time: 16:00 UTC
# Location:
https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
Hi folks! It's time for another blocker review meeting. We have 3
proposed blockers for Final.
Here is a handy link w
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 d
+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 S
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 Su
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 lan
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
66 matches
Mail list logo
