date:20240331

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

2024-03-31 Thread Carlos Rodriguez-Fernandez


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 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 ALL unit tests in %prep (and then of course not trying to run
them later).


This comes with the huge cost that we no longer have any idea if many
things actually work in Fedora. There are much better options here,
such as ensuring the package build process *isolates* the test data
from the compile process without just *removing* it. but again, this is
getting far too tied up in the details of this *one* attack. it's the
"everyone has to take their shoes off at the airport forever" mistake:
just because the *last* attack involved a binary test file, does not
mean the *next* one will. This is also known as preparing for the last
war, in military strategy.


* Deleting ALL files automatically generated or imported by autotools in
%prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it would
NOT have done the right thing here. Delete the files, THEN run autoreconf.)


No. This would not have avoided the attack, because it would not have
regenerated the malicious file. We have already established that.


* NOT patching OpenSSH downstream to link it against libsystemd against
upstream's recommendation.


Again, this is far too tied to the specific attack. I'm not interested,
as I said, in Monday morning quarterbacking this specific attack. I'm
interested in the question of what are the most immediate and effective
ways Fedora can lower its likelihood to be directly targeted in a
supply chain attack *in future*. Not the last one.


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 quickly. Otherwise, we were busy trying to
get this update pushed stable as fast as possible, because rwmj wanted
that. If the compromise had happened to be caught a few days later, the
update would have been pushed stable anyway. Our gating and manual
testing processes are not designed to catch security issues, and
certainly do not reliably do that job. They did not in this case. So it
seems wrong, to me, to suggest we should rely on them to do it in
future. Thus I disagree that any possible security benefit gained by
doing this would outweigh the substantial disadvantage that we wouldn't
get testing of stuff promptly any more.


What WOULD NOT have stopped this attack: (any or all of:)
* 2FA. GitHub already enforces 2FA. It did NOT stop this attack.


Again. I'm not interested in what, with hindsight, might have stopped
the attack that already happened. We know for sure that weak
authentication processes absolutely are a giant flashing ATTACK HERE
neon sign for *future* attackers.


* Any stricter vetting of Fedora contributions. The attack was performed
upstream, NOT in Fedora.


See above.


* More distrust of new Fedora contributors. The offending upgrade was
imported by a TRUSTED Fedora contributor. The untrusted new person operated
upstream, NOT in Fedora.


See above again.


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-31 Thread Christoph Karl via devel


+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 SELinux, this might be via an `rpmbuild-test` binary that
  doesn't have rights to touch the output RPMs
6a. if the tests fail, destroy the RPMs and fail out, reproducing the
result today
6b. if the tests pass, move/copy the RPMs to the result location and
exit cleanly, reproducing the result today


Boils down to separate source and test code/phase

source code:
(hopefully not obfuscated to the point where no review is possible)
no binaries allowed, best possible review
needed to build
build phase: source to binary

test code:
binaries allowed
only needed to test
test phase: binary unmodified

Allowing a test file to modify the binary makes it a source file. ?

Christoph
--
___
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-31 Thread Scott Schmit

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 detect that it's happened and abort the build) would
> > allow upstream tests to be run without compromising the integrity of the
> > build itself.
> 
> Just to be clear here that wouldn't have been enough: it's not the test
> step that's modifying the binaries, the actual build step is modified in
> the right conditions to use data that looks like it belongs to a test
> (I've read the actual files aren't actually used in any test and just
> look like test data, I didn't check, it wouldn't be hard to make a test
> that uses them anyway)
> 
> So short of deleting all blobs e.g. all test data this wouldn't have
> been prevented, just not running tests isn't enough.

Ugh!  I'd missed that detail.

> In theory it'd be possible to build twice:
> - one normal build with test data, and run tests at the end
> - a second build without test data (and confirm we've got an identical
> binary, builds are reproducible right?!)

FWIW, I don't think you'd need to build twice:

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 SELinux, this might be via an `rpmbuild-test` binary that
 doesn't have rights to touch the output RPMs
6a. if the tests fail, destroy the RPMs and fail out, reproducing the
   result today
6b. if the tests pass, move/copy the RPMs to the result location and
   exit cleanly, reproducing the result today

A variation of this would order things as normal but capture hashes of
all the files before the tests start and check the hashes after they're
done.  As long as the hashes can't be changed in between, you can trust
that.

Another approach (perhaps more doable in mock, not so easy otherwise):
1. do the build as user1
2. do the tests as user2
3. if the tests pass, resume as user1 as today

Given that the build pollution came from loading data out of the tests,
the above might still be useful, but it's not sufficient to prevent a
recurrence. (Though if you can identify the test files, you could still
segregate them via similar means -- make them unreadable until you're
ready to run the tests.)

> But while we might be able to afford the computing cost, I'm not sure
> it's worth it -- this attack vector happened to use test data, but there
> are plenty of other ways of doing this, and even just identifying /
> removing test data in the first place is hard work for packagers (I
> guess we could try to detect binary files but there is no end to that
> either, and many builds would just break if we were to automatically
> remove tests...)

Another idea I've seen floated
 is to modify the
build tools (compilers, etc) to generate SBOM files that log every input
file used to produce a given output.  Then you have a record to audit to
see if stuff is pulled from weird places.  That said, that wouldn't help
either, because all the machinations were via shell commands that
aren't, strictly speaking, build tools.  (Except if the linker shows a
file as input that was never generated by a compiler…)

But we could adapt that idea -- couldn't we use strace(1)/ptrace(2) to
detect open calls to determine the inputs and outputs?  And we could
protect the resulting records from build/test tampering similarly to the
above.

And if the upstream makes it difficult to tell what's test vs not…I
think at this point we have this incident as precedent to help explain
why we'd prefer less convoluted builds, or at least some explanations.

I dunno how workable that is in practice, though.  Though a part of me
says that it all boils down to making the build process more transparent
than we've previously put up with.

Anyway, just putting that out there in case anyone thinks these are good
ideas (or brainstorming toward better ones).

> (Anyway, I also think tests bring more benefits than risks in our case)

And it also occurs to me that test failures could just as easily help
find a malicious change if some new feature we're adding to Fedora
breaks the tests unexpectedly and exposes it (or just something unique
about how we've configured things).

-- 
Scott Schmit

smime.p7s
Description: S/MIME cryptographic 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:

2024-04-01 @ 16:00 UTC - Fedora 40 Blocker Review Meeting

2024-03-31 Thread Adam Williamson

# 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 which should show you the meeting time
in your local time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+40+Blocker+review+meeting=20240401T16=1440=2

The meeting will be on Matrix. Click the link above to join in a web
client - you can authenticate with your FAS account - or use a
dedicated client of your choosing.

If you have time today, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F40 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good day and see you tomorrow!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
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

[Test-Announce] 2024-04-01 @ 15:00 UTC - Fedora Quality Meeting

2024-03-31 Thread Adam Williamson

# 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'll
be on Matrix.

Here is a handy link which should show you the meeting time
in your local time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting=20240401T15=1440=1

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 40 status and Final planning
3. xz compromise discussion
4. Test Day / community event status
5. Open floor
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
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-31 Thread Adam Williamson

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 ALL unit tests in %prep (and then of course not trying to run 
> them later).

This comes with the huge cost that we no longer have any idea if many
things actually work in Fedora. There are much better options here,
such as ensuring the package build process *isolates* the test data
from the compile process without just *removing* it. but again, this is
getting far too tied up in the details of this *one* attack. it's the
"everyone has to take their shoes off at the airport forever" mistake:
just because the *last* attack involved a binary test file, does not
mean the *next* one will. This is also known as preparing for the last
war, in military strategy.

> * Deleting ALL files automatically generated or imported by autotools in 
> %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it would 
> NOT have done the right thing here. Delete the files, THEN run autoreconf.)

No. This would not have avoided the attack, because it would not have
regenerated the malicious file. We have already established that.

> * NOT patching OpenSSH downstream to link it against libsystemd against 
> upstream's recommendation.

Again, this is far too tied to the specific attack. I'm not interested,
as I said, in Monday morning quarterbacking this specific attack. I'm
interested in the question of what are the most immediate and effective
ways Fedora can lower its likelihood to be directly targeted in a
supply chain attack *in future*. Not the last one.

> 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 quickly. Otherwise, we were busy trying to
get this update pushed stable as fast as possible, because rwmj wanted
that. If the compromise had happened to be caught a few days later, the
update would have been pushed stable anyway. Our gating and manual
testing processes are not designed to catch security issues, and
certainly do not reliably do that job. They did not in this case. So it
seems wrong, to me, to suggest we should rely on them to do it in
future. Thus I disagree that any possible security benefit gained by
doing this would outweigh the substantial disadvantage that we wouldn't
get testing of stuff promptly any more.
> 
> What WOULD NOT have stopped this attack: (any or all of:)
> * 2FA. GitHub already enforces 2FA. It did NOT stop this attack.

Again. I'm not interested in what, with hindsight, might have stopped
the attack that already happened. We know for sure that weak
authentication processes absolutely are a giant flashing ATTACK HERE
neon sign for *future* attackers.

> * Any stricter vetting of Fedora contributions. The attack was performed 
> upstream, NOT in Fedora.

See above.

> * More distrust of new Fedora contributors. The offending upgrade was 
> imported by a TRUSTED Fedora contributor. The untrusted new person operated 
> upstream, NOT in Fedora.

See above again.
-- 
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

[Bug 2268717] perl-Spreadsheet-XLSX-0.18 is available

2024-03-31 Thread bugzilla

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:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-aa863b2777

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2268717

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268717%23c10
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 7 updates-testing report

2024-03-31 Thread updates

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 have been pushed to Fedora EPEL 7 updates-testing

bitlbee-facebook-1.2.2-9.el7
perl-Spreadsheet-XLSX-0.18-1.el7

Details about builds:



 bitlbee-facebook-1.2.2-9.el7 (FEDORA-EPEL-2024-e4954e087d)
 Facebook protocol plugin for BitlBee

Update Information:

Test whether BitlBee can load plugin during startup (#2272092)

ChangeLog:

* Sun Mar 31 2024 Robert Scheck  1.2.2-9
- Test whether BitlBee can load plugin during startup (#2272092)
* Tue Jan 23 2024 Fedora Release Engineering  - 
1.2.2-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
1.2.2-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Wed Jul 19 2023 Fedora Release Engineering  - 
1.2.2-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Wed Jan 18 2023 Fedora Release Engineering  - 
1.2.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Wed Jul 20 2022 Fedora Release Engineering  - 
1.2.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jan 19 2022 Fedora Release Engineering  - 
1.2.2-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Wed Jul 21 2021 Fedora Release Engineering  - 
1.2.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

References:

  [ 1 ] Bug #2272092 - facebook.so plugin fails to load: undefined symbol: 
SET_INVALID
https://bugzilla.redhat.com/show_bug.cgi?id=2272092




 perl-Spreadsheet-XLSX-0.18-1.el7 (FEDORA-EPEL-2024-aa863b2777)
 Perl extension for reading Microsoft Excel 2007 files

Update Information:

Spreadsheet::XLSX 0.18
Fix RT #117166: unformatted date values can no longer be retrieved

ChangeLog:

* Sun Mar 31 2024 Robert Scheck  0.18-1
- Upgrade to 0.18 (#2268717)
* Thu Jan 25 2024 Fedora Release Engineering  - 0.17-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Sun Jan 21 2024 Fedora Release Engineering  - 0.17-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jul 21 2023 Fedora Release Engineering  - 0.17-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Fri Jan 20 2023 Fedora Release Engineering  - 0.17-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Fri Jul 22 2022 Fedora Release Engineering  - 0.17-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jun  1 2022 Jitka Plesnikova  - 0.17-3
- Perl 5.36 rebuild
* Fri Jan 21 2022 Fedora Release Engineering  - 0.17-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #2268717 - perl-Spreadsheet-XLSX-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268717


--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-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-31 Thread Carlos Rodriguez-Fernandez

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 latter, where you want to find diff between tars and git
repo content, someone may say "let's just use the github API to pull the
tar", but not all projects use github, or have that feature. So, I still
think there is value in these tools.

I started working on a PoC personal minitool named rpmseclint that
utilizes the "VCS" tag to pull the git repo, and the tar, and compares
and flags things for further review. Right now, I'm just focused on
blobs, and files/directories differences. The intention is to use it at
least right before a rebase. I'm just planning to personally use it to
get a "feel" for it (and help myself), but open to anyone wanting to
explore this idea.

In general, I think the idea of codifying security practices expertise
in tools to assist maintainers with detection and analysis has great
value; even if it is not enforcing anything at the moment. The
maintainer could then explicitly add found problems to an "ignore" list
after the analysis, and explain the "why" in the git commit body
message, and perpetuate the reasoning in the git history of the
downstream project. There is already a lot of best practices codified in
the gating pipelines, and I have found them extremely useful myself.

Regards,
Carlos R.F.

On 3/30/24 02:37, 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 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.

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

[Bug 2268717] perl-Spreadsheet-XLSX-0.18 is available

2024-03-31 Thread bugzilla

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:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-3b841f3e4c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2268717

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268717%23c9
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 9 updates-testing report

2024-03-31 Thread updates

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://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-e2cad98fb0   
tinyxml-2.6.2-28.el9
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-8526776b15   
libopenmpt-0.7.6-1.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

bitlbee-facebook-1.2.2-9.el9
perl-Spreadsheet-XLSX-0.18-1.el9
proftpd-1.3.8b-3.el9

Details about builds:



 bitlbee-facebook-1.2.2-9.el9 (FEDORA-EPEL-2024-4de1ad4f9f)
 Facebook protocol plugin for BitlBee

Update Information:

Test whether BitlBee can load plugin during startup (#2272092)

ChangeLog:

* Sun Mar 31 2024 Robert Scheck  1.2.2-9
- Test whether BitlBee can load plugin during startup (#2272092)
* Tue Jan 23 2024 Fedora Release Engineering  - 
1.2.2-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
1.2.2-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Wed Jul 19 2023 Fedora Release Engineering  - 
1.2.2-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild

References:

  [ 1 ] Bug #2272092 - facebook.so plugin fails to load: undefined symbol: 
SET_INVALID
https://bugzilla.redhat.com/show_bug.cgi?id=2272092




 perl-Spreadsheet-XLSX-0.18-1.el9 (FEDORA-EPEL-2024-3b841f3e4c)
 Perl extension for reading Microsoft Excel 2007 files

Update Information:

Spreadsheet::XLSX 0.18
Fix RT #117166: unformatted date values can no longer be retrieved

ChangeLog:

* Sun Mar 31 2024 Robert Scheck  0.18-1
- Upgrade to 0.18 (#2268717)
* Thu Jan 25 2024 Fedora Release Engineering  - 0.17-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Sun Jan 21 2024 Fedora Release Engineering  - 0.17-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jul 21 2023 Fedora Release Engineering  - 0.17-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Fri Jan 20 2023 Fedora Release Engineering  - 0.17-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Fri Jul 22 2022 Fedora Release Engineering  - 0.17-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jun  1 2022 Jitka Plesnikova  - 0.17-3
- Perl 5.36 rebuild

References:

  [ 1 ] Bug #2268717 - perl-Spreadsheet-XLSX-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268717




 proftpd-1.3.8b-3.el9 (FEDORA-EPEL-2024-2141e40509)
 Flexible, stable and highly-configurable FTP server

Update Information:

This updates adds mod_proxy in its own sub-package, proftpd-proxy.

ChangeLog:

* Sun Mar 31 2024 Paul Howarth  - 1.3.8b-3
- Add 'proxy' sub-package with unbundled mod_proxy (rhbz#2272051)
- Update fsio.c: if mkdir fails with EEXIST, also clear the cache (GH#1677)

References:

  [ 1 ] Bug #2272051 - please include proftpd-mod_proxy (and a small bugfix)
https://bugzilla.redhat.com/show_bug.cgi?id=2272051


--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2268717] perl-Spreadsheet-XLSX-0.18 is available

2024-03-31 Thread bugzilla

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:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-6794536e9f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2268717

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268717%23c8
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 8 updates-testing report

2024-03-31 Thread updates

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://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-acb47e6aea   
libopenmpt-0.7.6-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

bitlbee-facebook-1.2.2-9.el8
perl-Spreadsheet-XLSX-0.18-1.el8

Details about builds:



 bitlbee-facebook-1.2.2-9.el8 (FEDORA-EPEL-2024-451c3e8714)
 Facebook protocol plugin for BitlBee

Update Information:

Test whether BitlBee can load plugin during startup (#2272092)

ChangeLog:

* Sun Mar 31 2024 Robert Scheck  1.2.2-9
- Test whether BitlBee can load plugin during startup (#2272092)
* Tue Jan 23 2024 Fedora Release Engineering  - 
1.2.2-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
1.2.2-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Wed Jul 19 2023 Fedora Release Engineering  - 
1.2.2-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Wed Jan 18 2023 Fedora Release Engineering  - 
1.2.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Wed Jul 20 2022 Fedora Release Engineering  - 
1.2.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jan 19 2022 Fedora Release Engineering  - 
1.2.2-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Wed Jul 21 2021 Fedora Release Engineering  - 
1.2.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

References:

  [ 1 ] Bug #2272092 - facebook.so plugin fails to load: undefined symbol: 
SET_INVALID
https://bugzilla.redhat.com/show_bug.cgi?id=2272092




 perl-Spreadsheet-XLSX-0.18-1.el8 (FEDORA-EPEL-2024-6794536e9f)
 Perl extension for reading Microsoft Excel 2007 files

Update Information:

Spreadsheet::XLSX 0.18
Fix RT #117166: unformatted date values can no longer be retrieved

ChangeLog:

* Sun Mar 31 2024 Robert Scheck  0.18-1
- Upgrade to 0.18 (#2268717)
* Thu Jan 25 2024 Fedora Release Engineering  - 0.17-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Sun Jan 21 2024 Fedora Release Engineering  - 0.17-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jul 21 2023 Fedora Release Engineering  - 0.17-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Fri Jan 20 2023 Fedora Release Engineering  - 0.17-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Fri Jul 22 2022 Fedora Release Engineering  - 0.17-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jun  1 2022 Jitka Plesnikova  - 0.17-3
- Perl 5.36 rebuild
* Fri Jan 21 2022 Fedora Release Engineering  - 0.17-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #2268717 - perl-Spreadsheet-XLSX-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268717


--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2268717] perl-Spreadsheet-XLSX-0.18 is available

2024-03-31 Thread bugzilla

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 --refresh
--advisory=FEDORA-2024-217b7b1eb8`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-217b7b1eb8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2268717

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268717%23c7
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2259535] perl-DBD-Firebird-1.34-8.fc40 FTBFS: Firebird.xs:1277:13: error: passing argument 1 of ‘isc_event_block’ from incompatible pointer type

2024-03-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2259535

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2024-63c25e6f16 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 --refresh
--advisory=FEDORA-2024-63c25e6f16`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-63c25e6f16

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259535

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259535%23c3
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2268717] perl-Spreadsheet-XLSX-0.18 is available

2024-03-31 Thread bugzilla

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 --refresh
--advisory=FEDORA-2024-d7e72afdf7`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7e72afdf7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2268717

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268717%23c6
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2268717] perl-Spreadsheet-XLSX-0.18 is available

2024-03-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2268717

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2024-a63af372e9 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-a63af372e9`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-a63af372e9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2268717

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268717%23c5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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-31 Thread Kilian Hanich via devel


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 run
them later).

While it’s technically correct that deleting tests would have disrupted this
specific attack, a policy of deleting and and never running upstream test
code would have prevented me from finding and helping upstreams fix dozens
and dozens of bugs due to accidentally faulty assumptions that turned out to
be violated on different architectures, in different system environments, or
with various allegedly-compatible dependency versions. There are even GCC
bugs (miscompilations, not only failures to compile) that were discovered
and fixed only because packages I maintain were running upstream unit and
integration tests. Frankly, “testing the packages we ship, as built in our
distribution, is actually bad” seems like a pretty strange and extreme
conclusion to draw from all of this.


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 to be run without compromising the integrity of the
build itself.


It would prevent the attack from being hidden in the tests, but not in
any other part of the build.

Also, I have seen build setups which encode the status of tests in the
eventual binary and as such info page or integrated bug report
generators. Often because some distros sometimes turned them off or
ships software even with failed tests and thus pushing that headache to
upstream.


Regards

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-31 Thread Kilian Hanich via devel


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
passwords and try them on other accounts that belong to the same person. Since 
two
factors are generally unique per login situation they can't be stuffed in the 
same way.

Of course there are many things two factor does not protect against.



2FA in a lot of cases is just access to a different account (e.g. email
or even SMS) and these normally aren't unique. Sure, there are other
ways like FIDO2, but these are not necessarily used (or liked, quite
frankly I know a lot of people who would loose them on a monthly basis,
but still are quite smart about other stuff).

This can also lead to a pretty interesting "circle" of 2FA where for
example email a is the 2FA address for email b and email b is the 2FA
address for email a. If it's the only option it can also lead to a
chicken and egg problem for young people who want to create e.g. their
first email account. But this paragraph is besides the point.

So, sure, 2FA would prevent people from just trying out leaked
passwords. But an attack like this would not be a "spray and pray"
attack, but it would be a targeted one. This means that the acceptable
effort from the attacker would be quite a bit higher.

2FA would prevent script kiddies and "spray and pray"-style attacks from
being successful. But more? Doubtful.


Regards

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-31 Thread Dominique Martinet

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 to be run without compromising the integrity of the
> build itself.

Just to be clear here that wouldn't have been enough: it's not the test
step that's modifying the binaries, the actual build step is modified in
the right conditions to use data that looks like it belongs to a test
(I've read the actual files aren't actually used in any test and just
look like test data, I didn't check, it wouldn't be hard to make a test
that uses them anyway)

So short of deleting all blobs e.g. all test data this wouldn't have
been prevented, just not running tests isn't enough.

In theory it'd be possible to build twice:
- one normal build with test data, and run tests at the end
- a second build without test data (and confirm we've got an identical
binary, builds are reproducible right?!)

But while we might be able to afford the computing cost, I'm not sure
it's worth it -- this attack vector happened to use test data, but there
are plenty of other ways of doing this, and even just identifying /
removing test data in the first place is hard work for packagers (I
guess we could try to detect binary files but there is no end to that
either, and many builds would just break if we were to automatically
remove tests...)


(Anyway, I also think tests bring more benefits than risks in our case)
-- 
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

[Bug 2259535] perl-DBD-Firebird-1.34-8.fc40 FTBFS: Firebird.xs:1277:13: error: passing argument 1 of ‘isc_event_block’ from incompatible pointer type

2024-03-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2259535

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2024-63c25e6f16 (perl-DBD-Firebird-1.34-10.fc40) has been submitted as
an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-63c25e6f16


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259535

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259535%23c2
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

84 matches

Mail list logo