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
# 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
# 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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
--- Comment #10 from Fedora Update System ---
FEDORA-EPEL-2024-aa863b2777 has been pushed to the Fedora EPEL 7 testing
repository.
You can provide feedback for this update here:
The following Fedora EPEL 7 Security updates need testing:
Age URL
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-15cde9f00b
chromium-123.0.6312.58-1.el7
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-07e8f5f1f0
libopenmpt-0.7.6-1.el7
The following builds
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
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
--- Comment #9 from Fedora Update System ---
FEDORA-EPEL-2024-3b841f3e4c has been pushed to the Fedora EPEL 9 testing
repository.
You can provide feedback for this update here:
The following Fedora EPEL 9 Security updates need testing:
Age URL
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-5e764f8789
opensmtpd-7.4.0p1-1.el9
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-24aceec24b
chromium-123.0.6312.58-1.el9
3
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
--- Comment #8 from Fedora Update System ---
FEDORA-EPEL-2024-6794536e9f has been pushed to the Fedora EPEL 8 testing
repository.
You can provide feedback for this update here:
The following Fedora EPEL 8 Security updates need testing:
Age URL
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-fc233c6d2e
chromium-123.0.6312.58-1.el8
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0ced8d6066
tinyxml-2.6.2-28.el8
2
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
--- Comment #7 from Fedora Update System ---
FEDORA-2024-217b7b1eb8 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
https://bugzilla.redhat.com/show_bug.cgi?id=2259535
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #3 from
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
--- Comment #6 from Fedora Update System ---
FEDORA-2024-d7e72afdf7 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #5 from
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
https://bugzilla.redhat.com/show_bug.cgi?id=2259535
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
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
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
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
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:
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 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
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2272408
Bug ID: 2272408
Summary: perl-PDL-2.086 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-PDL
Keywords: FutureFeature, Triaged
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
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
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
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
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
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
>
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
--
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
https://bugzilla.redhat.com/show_bug.cgi?id=2272395
Bug ID: 2272395
Summary: perl-IO-Compress-2.208 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-IO-Compress
Keywords: FutureFeature, Triaged
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 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
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 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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
--- Comment #2 from Fedora Update System ---
FEDORA-2024-217b7b1eb8 (perl-Spreadsheet-XLSX-0.18-1.fc38) has been submitted
as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-217b7b1eb8
--
You are receiving this
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
Fedora Update System changed:
What|Removed |Added
Status|NEW |MODIFIED
--- Comment #1 from
https://bugzilla.redhat.com/show_bug.cgi?id=2268717
--- Comment #4 from Fedora Update System ---
FEDORA-EPEL-2024-aa863b2777 (perl-Spreadsheet-XLSX-0.18-1.el7) has been
submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-aa863b2777
--
You are
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 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://bugzilla.redhat.com/show_bug.cgi?id=2257627
Robert Scheck changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
https://bugzilla.redhat.com/show_bug.cgi?id=2257628
Robert Scheck changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
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
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
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
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
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
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
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
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
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2271131
Emmanuel Seyman changed:
What|Removed |Added
Resolution|--- |RAWHIDE
Status|NEW
https://bugzilla.redhat.com/show_bug.cgi?id=2271882
Emmanuel Seyman changed:
What|Removed |Added
Resolution|--- |RAWHIDE
Status|NEW
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
84 matches
Mail list logo
