date:20240401


Matthew Miller,

Unit tests, even though in theory developer should mock dependencies to 
isolate their code to the maximum, in reality, it is not that clear cut. 
Therefore, those unit tests do serve to some extent as a validation that 
their code works with the system libraries and platforms present in the 
targeted configuration. I think it is valuable to run them during the 
rpm builds, and contribute upstream when they break.


On 4/1/24 14:11, Matthew Miller wrote:

On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:

Unit tests are something for upstream developers. They should NEVER be run
in a distribution build.


Even in the few little packages I'm still responsible for, I sometimes see
unit test failures. The developer ran the tests, but not on S390. Or, with a
different timezone database than current in Fedora. Or etc.



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


Chris,
The specific points of entry were evading the strength of open source: 
many skilled eyes. Therefore, there is value in programmatically 
enforcing that everything used as an input in a build must have been 
exposed to *normal opensource workflows*. It is a very simple principle, 
yet very powerful: let's flag everything that can evade review: 
basically, tar.gz must be equal in content to what it is browseable on 
the git repository, and also blobs must be flagged for additional 
analysis, because released tar.gz and blobs are not normally reviewed on 
a opensource workflow.


Those problems can be codified in a tool (which it is already done in a 
proof of concept to show that it is simple to do and possible), or the 
approach can be changed all together to something like source-git?


On 4/1/24 18:47, Chris Adams wrote:

Yeah.  This was clearly an attack targeted at Fedora and Debian; trying
to fix the specific point of entry is a losing battle, as at the end of
the day, Fedora will still be taking code from upstreams and
distributing it to systems far and wide.  The particular use of test
and autoconf files to try to hide the attack may be novel, but there are
other ways it could have been done.  If there's easy and minimal-impact
ways to help (which I haven't really seen suggested), that's good to
look at, but putting lots of effort into how tests are run or wholesale
changes to configuration seem to not be all that useful.

However, it's a good trigger to review Fedora's security approach in
general (like 2FA use).


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 2271173] perl-Business-ISBN-Data-20240323.001 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Business-ISBN-Data-202 |perl-Business-ISBN-Data-202
   |40323.001-1.fc41|40323.001-1.fc41
   ||perl-Business-ISBN-Data-202
   ||40323.001-1.fc40



--- Comment #5 from Fedora Update System  ---
FEDORA-2024-dbbcd62863 (perl-Business-ISBN-Data-20240323.001-1.fc40) has been
pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202271173%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-04-01 Thread Chris Adams

Once upon a time, Gabriel Somlo  said:
> IMHO, there's no good way to *programmatically* protect ourselves
> from a malicious upstream on which we depend. If their goal is to
> compromise us, they will work around whatever programmatic/technical
> measures we happen to have in place at the time they decide to launch
> their attack.

Yeah.  This was clearly an attack targeted at Fedora and Debian; trying
to fix the specific point of entry is a losing battle, as at the end of
the day, Fedora will still be taking code from upstreams and
distributing it to systems far and wide.  The particular use of test
and autoconf files to try to hide the attack may be novel, but there are
other ways it could have been done.  If there's easy and minimal-impact
ways to help (which I haven't really seen suggested), that's good to
look at, but putting lots of effort into how tests are run or wholesale
changes to configuration seem to not be all that useful.

However, it's a good trigger to review Fedora's security approach in
general (like 2FA use).

-- 
Chris Adams 
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-01 Thread Gabriel Somlo

> On Mon, Apr 1, 2024 at 17:11:46 -0400, Matthew Miller via devel wrote:
> On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:
> > Unit tests are something for upstream developers. They should NEVER be run 
> > in a distribution build.
> 
> Even in the few little packages I'm still responsible for, I sometimes see
> unit test failures. The developer ran the tests, but not on S390. Or, with a
> different timezone database than current in Fedora. Or etc.

IMHO, there's no good way to *programmatically* protect ourselves
from a malicious upstream on which we depend. If their goal is to
compromise us, they will work around whatever programmatic/technical
measures we happen to have in place at the time they decide to launch
their attack.

Any potential defense against this sort of thing will have to be
*social*, and/or *process* based. Packagers should get to know (as
best as possible) their upstream maintainers and developers -- by
reaching out over upstream's dev fora, by meeting up at events and
conferences, etc. Packagers should hopefully be familiar with the
human *and* technical situation of upstream, and have a chance to
notice when things go "weird".

Just another $0.02 from the peanut gallery...

Cheers,
--Gabriel
--
___
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 2272395] perl-IO-Compress-2.208 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-IO-Compress-2.208-1.fc
   ||41
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2024-04-01 23:51:21



--- Comment #2 from Fedora Update System  ---
FEDORA-2024-b9ddd82efc (perl-IO-Compress-2.208-1.fc41) has been pushed to the
Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272395%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

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

On Mon, 2024-04-01 at 23:37 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > > * 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.
> 
> Just running autoreconf would not. As I wrote: "DO NOT trust autoreconf, it 
> would NOT have done the right thing here." Deleting the file with an 
> explicit rm -f in %prep, and THEN running autoreconf would have regenerated 
> (reimported, actually, this comes from gnulib and is copied unchanged, but 
> in any case it would NOT have contained the malicious additions) the file.
> 
> That said, autoreconf needs fixing too, because -f is supposed to regenerate 
> all files that can be regenerated, which is not happening. But if you 
> explicitly delete the files before running autoreconf, then it has to 
> regenerate them no matter what.

Sure, but as others posted upthread, this still doesn't help much. To
do this you have to know what m4s are 'standard' and will actually be
regenerated, and which are custom and you can't wipe them. And then an
attacker could just slip in an extra custom one instead of modifying a
'standard' one.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-01 Thread Gary Buhrmaster

On Mon, Apr 1, 2024 at 9:17 PM Matthew Miller  wrote:
>
> On Mon, Apr 01, 2024 at 05:47:10PM +, Gary Buhrmaster wrote:
> > It does bring up a potential point that perhaps
> > Fedora should have an additional repo (let's
> > call it "emergency fixes") that is not community
> > mirrored (so any mirrors for load sharing
> > would be fully controlled by the project), with
> > a short refresh time, and containing only
> > packages that need to get out immediately.
> > If a critical fix needs to get out to the
> > community it could be (almost) immediately
> > available.  After a few days (when public
> > mirrors would be expected to have updated)
> > those packages could be removed (reducing
> > the load on this repo).  For the next time, of
> > course (and there will be a next time, there
> > is always a next time).
>
> https://pagure.io/releng/issue/5886
>
> (This was after Heartbleed, FWIW.)
>

I am glad to know "it's all good" :-(
--
___
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-04-01 Thread Kevin Kofler via devel

Adam Williamson wrote:
>> * 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.

Just running autoreconf would not. As I wrote: "DO NOT trust autoreconf, it 
would NOT have done the right thing here." Deleting the file with an 
explicit rm -f in %prep, and THEN running autoreconf would have regenerated 
(reimported, actually, this comes from gnulib and is copied unchanged, but 
in any case it would NOT have contained the malicious additions) the file.

That said, autoreconf needs fixing too, because -f is supposed to regenerate 
all files that can be regenerated, which is not happening. But if you 
explicitly delete the files before running autoreconf, then it has to 
regenerate them no matter what.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-01 Thread Jakub Jelinek

On Mon, Apr 01, 2024 at 01:36:48PM -0400, Peter Jones wrote:
> Unrelated to the idea that some packages are special in this way, it's
> probably worth writing some static analysis tools we could put into
> rpm-inspect to detect when (a) a binary grows new public keys it didn't
> have before, and (b) a shared object grows a new ifunc.  The latter is
> dramatically easier, of course, but both of those should be pretty rare
> events, so they're worth further inspection.

I don't see much difference between ifuncs and any other library
constructors from the exploit POV, at least with DT_BIND_NOW both is just
some extra code run during library initialization.  Sure, ifunc handlers
affect what ifunc target is later called whenever calling the ifunc
function, but harm can be done already when loading the library or the
library constructor could overwrite function pointers, vtable pointers or
just some data in the library to change its behavior later.
So, in addition to watching for new ifuncs (and more importantly, trying to
figure out if it is possible to statically prove the set of possible
functions it will resolve to and compare to the old set; and if it isn't
possible to statically figure out list of possible targets flag it for more
careful inspection) we should watch for additions of
__attribute__((constructor)) code or C++ namespace scope non-trivial ctors or
dynamic initializers of namespace scope variables.

Jakub
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-01 Thread Matthew Miller

On Mon, Apr 01, 2024 at 05:47:10PM +, Gary Buhrmaster wrote:
> It does bring up a potential point that perhaps
> Fedora should have an additional repo (let's
> call it "emergency fixes") that is not community
> mirrored (so any mirrors for load sharing
> would be fully controlled by the project), with
> a short refresh time, and containing only
> packages that need to get out immediately.
> If a critical fix needs to get out to the
> community it could be (almost) immediately
> available.  After a few days (when public
> mirrors would be expected to have updated)
> those packages could be removed (reducing
> the load on this repo).  For the next time, of
> course (and there will be a next time, there
> is always a next time).

https://pagure.io/releng/issue/5886

(This was after Heartbleed, FWIW.)




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

-- 
Matthew Miller

Fedora Project Leader
--
___
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-04-01 Thread Matthew Miller

On Sat, Mar 30, 2024 at 08:11:38PM +0100, Kevin Kofler via devel wrote:
> Unit tests are something for upstream developers. They should NEVER be run 
> in a distribution build.

Even in the few little packages I'm still responsible for, I sometimes see
unit test failures. The developer ran the tests, but not on S390. Or, with a
different timezone database than current in Fedora. Or etc.

-- 
Matthew Miller

Fedora Project Leader
--
___
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

Summary/Minutes from today's FESCo Meeting (2024-04-01)

2024-04-01 Thread Josh Stone

(sorry for the crazy links -- meetbot didn't grab the intended name)

Text Log:
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-01/fesco-chairs-conan-kudo-matrix-org-ngompa-fedora-im-nirik-matrix-scrye-com-humaton-fedora-im-zbyszek-fedora-im-sgallagh-fedora-im-jistone-fedora-im-dcantrell-fedora-im-mhayden-fedora-im-tstellar-fedora-im.2024-04-01-19.30.log.txt

HTML Log:
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-01/fesco-chairs-conan-kudo-matrix-org-ngompa-fedora-im-nirik-matrix-scrye-com-humaton-fedora-im-zbyszek-fedora-im-sgallagh-fedora-im-jistone-fedora-im-dcantrell-fedora-im-mhayden-fedora-im-tstellar-fedora-im.2024-04-01-19.30.log.html

Text Minutes:
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-01/fesco-chairs-conan-kudo-matrix-org-ngompa-fedora-im-nirik-matrix-scrye-com-humaton-fedora-im-zbyszek-fedora-im-sgallagh-fedora-im-jistone-fedora-im-dcantrell-fedora-im-mhayden-fedora-im-tstellar-fedora-im.2024-04-01-19.30.txt

HTML Minutes:
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-04-01/fesco-chairs-conan-kudo-matrix-org-ngompa-fedora-im-nirik-matrix-scrye-com-humaton-fedora-im-zbyszek-fedora-im-sgallagh-fedora-im-jistone-fedora-im-dcantrell-fedora-im-mhayden-fedora-im-tstellar-fedora-im.2024-04-01-19.30.html

* TOPIC: Init Process
* TOPIC: #3173 F40 Change Proposal Status: Incomplete Changes
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2252766
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258083
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258088
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258090
* LINK: https://pagure.io/releng/issue/12028
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2258084
* INFO: all F40 changes are either ON_QA now or apparently ready for
that
* TOPIC: Next week's chair
* ACTION: nirik will chair next meeting
* TOPIC: Open Floor

Meeting ended at 2024-04-01 19:59:29

Action items

* nirik will chair next meeting
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-01 Thread Michael Catanzaro

On Mon, Apr 1 2024 at 10:25:16 AM -07:00:00, Adam Williamson 
 wrote:

Oh, ISWYM. Well, I suppose yes, that does happen to be true. We could
communicate that if it's done very carefully and made really clear 
that

it's about the *time frame*, nothing to do with the repositories.


It's been brought to my attention that the Fedora Magazine article [1] 
has been updated yet again, and now it warns that the 5.6.0-3.fc40 
build was "tainted." This build is not affected by the backdoor because 
ifuncs were disabled.


I'm quite frustrated now. The message from Richard and other engineers 
has been very consistent. The bad builds are 5.6.0-1.fc40 and 
5.6.0-2.fc40. We have been saying as much since Friday. Please fix the 
article once again.


(There is no strong reason to believe 5.6.0 is otherwise worse than 
5.4.6, since both versions were released by the same attacker. It 
doesn't make sense to refer to the -3 build as "tainted.")


Michael

[1] https://fedoramagazine.org/cve-2024-3094-security-alert-f40-rawhide/

--
___
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: Outage alert: openQA result reporting (affects critical path gating), nightly page updating, candidate compose nominations

On Mon, 2024-04-01 at 08:53 -0700, Adam Williamson wrote:
> Hi folks! I just discovered this so I'm still investigating it, but
> wanted to give a quick heads-up.
> 
> It looks like the message consumers on openqa01 all broke on Saturday
> when a fedora-messaging update landed. This affects a lot of things,
> but by far the most important is that openQA test results are not
> getting reported to resultsdb. This will be causing all critpath
> updates to be stuck in gating.
> 
> I am going to investigate this urgently, of course, and as a stopgap I
> will manually trigger submission of all reports from the last couple of
> days shortly. Very sorry for the inconvenience.
> 
> Also affected: https://openqa.fedoraproject.org/nightlies.html and
> .json are not getting updated, validation test events are not being
> created, check-compose emails not being generated, possibly something
> else I've forgotten.

OK, I've found the cause of this: a 'modernization' of the fedora-
messaging spec caused the hashbang of /usr/bin/fedora-messaging to
change so it is run with `python3 -sP`, which causes python not to use
libraries from /usr/local/lib . This was a surprising and unexpected
change in a stable release update, and it may affect other folks too.
See https://bugzilla.redhat.com/show_bug.cgi?id=2272526 .

I'll work around this for now and wait to see what comes of the bug
report. The consumers will gradually catch up with all the stuff they
should have been doing for the last two days over the next little
while.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-01 Thread Sandro


On 01-04-2024 19:12, Adam Williamson wrote:

On Mon, 2024-04-01 at 09:32 -0500, Michael Catanzaro wrote:

On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz
 wrote:

"Fedora Linux 40 branched users (i.e. pre-Beta) likely received the
potentially vulnerable 5.6.0-2.fc40 build if the system updated
between March 2nd and March 6th. Fedora Linux 40 Beta users only
using stable repositories are NOT impacted. Fedora Linux 39 and 38
users are also NOT impacted."

  -> only pre-beta, not beta, affected
   -> F40 beta using stable NOT impacted (without challenging the
previously distributed assumption that testing is disabled by default)

That's still the same false information, isn't it?


It looks correct to me. The bug was fixed prior to the final release of
F40 beta,


This is not really correct, or at least at all relevant. The bug wasn't
in F40 Beta simply because the update never made it to 'stable'. Only
'stable' packages go into *composes*. However, saying that is not
really useful because anyone who *installed* Beta and then updated it
regularly may have got the vulnerable package. We should not say
anything to give people the impression that if they installed Beta,
they don't need to worry. That is not true or helpful.


  so describing it as "pre-beta" makes sense. And people who
used only the stable repos were indeed not affected. The article later
clarifies that updates-testing is enabled by default (although it would
be nicer to do this higher up rather than lower down the page).


For the same reason I think it's dangerous and not useful to try and
draw this distinction between notional "people who only use stable
repos" and people who use testing. Who would actually install F40 but
then manually turn updates-testing off? Very few people. I don't think
we should talk about this because it just confuses the issue. It would
be like saying a stable release security issue that appeared in a
stable update didn't affect people who turned off the updates repo.
Technically true, but people don't do that, why would we say it?


This boils down to the initial confusion as to when `updates-testing` is 
switched off. Both Justin and I thought it would be turned off again as 
soon as Beta is officially released.


If you take that confusion into account, making that distinction makes 
perfect sense. Unfortunately, it turned out to be the wrong assumption.



We should have a simple and clear message that covers the most common
and important case: if you installed Fedora 40 and updated regularly
during the vulnerable time frame, you very likely got the vulnerable
package and should take appropriate action. We should not confuse this
with unnecessary verbiage about stable and testing and pre-Beta and
post-Beta.


Agreed. I'm sure the text would have been different if the confusion 
(see above) hadn't happened.


OTOH, I also expect users, even inexperienced users, to bring some 
common sense. I oppose having to put "contents may be hot" on a coffee 
cup ...


-- Sandro
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-01 Thread Gary Buhrmaster

On Mon, Apr 1, 2024 at 5:27 PM Kevin Fenzi  wrote:

> Yes. The downgrade was pushed out on friday along with the f40 one.

Of course, your mirror may vary as to availability
(as I recall, in my particular case, my test VM
for rawhide did not get the update for a day
or so).

It does bring up a potential point that perhaps
Fedora should have an additional repo (let's
call it "emergency fixes") that is not community
mirrored (so any mirrors for load sharing
would be fully controlled by the project), with
a short refresh time, and containing only
packages that need to get out immediately.
If a critical fix needs to get out to the
community it could be (almost) immediately
available.  After a few days (when public
mirrors would be expected to have updated)
those packages could be removed (reducing
the load on this repo).  For the next time, of
course (and there will be a next time, there
is always a next time).
--
___
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-04-01 Thread Peter Jones

> (3) We should have a "security path", like "critical path".
> 
> sshd is linked to a lot of libraries:
> 
> /lib64/libaudit.so.1audit-libs
> /lib64/libc.so.6glibc
> /lib64/libcap-ng.so.0   libcap-ng
> /lib64/libcap.so.2  libcap
> /lib64/libcom_err.so.2  libcom_err
> /lib64/libcrypt.so.2libxcrypt
> /lib64/libcrypto.so.3   openssl-libs
> /lib64/libeconf.so.0libeconf
> /lib64/libgcc_s.so.1libgcc
> /lib64/libgssapi_krb5.so.2  krb5-libs
> /lib64/libk5crypto.so.3 krb5-libs
> /lib64/libkeyutils.so.1 keyutils-libs
> /lib64/libkrb5.so.3 krb5-libs
> /lib64/libkrb5support.so.0  krb5-libs
> /lib64/liblz4.so.1  lz4-libs
> /lib64/liblzma.so.5 xz-libs
> /lib64/libm.so.6glibc
> /lib64/libpam.so.0  pam-libs
> /lib64/libpcre2-8.so.0  pcre2
> /lib64/libresolv.so.2   glibc
> /lib64/libselinux.so.1  libselinux
> /lib64/libsystemd.so.0  systemd-libs
> /lib64/libz.so.1zlib / zlib-ng
> /lib64/libzstd.so.1 zstd
> 
> Should we have a higher level of attention to these packages?  We
> already have "critical path", but that's a broad category now.  These
> seem like they are "security path" packages, an intentionally small
> subset associated with very secure services which are enabled by
> default.

I agree, but that brings us to the question of what to do about them
that's special.

Unrelated to the idea that some packages are special in this way, it's
probably worth writing some static analysis tools we could put into
rpm-inspect to detect when (a) a binary grows new public keys it didn't
have before, and (b) a shared object grows a new ifunc.  The latter is
dramatically easier, of course, but both of those should be pretty rare
events, so they're worth further inspection.

Even if it's just RSA keys that we search for, that would add some
benefit, and that's pretty easy if nobody has tried to cover their
tracks: scan a binary for a big power of two sized odd number followed
by a small prime number, and then filtering that with a more rigorous
prime test on the first number will detect RSA keys and probably very
little else.  Might be worth grepping for "- BEGIN" as well.

Just some thoughts, I'm sure we'll all have many more where these come
from.

-- 
Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor



On 01/04/2024 19.27, Kevin Fenzi wrote:

On Mon, Apr 01, 2024 at 05:07:13PM +, Christopher Klooz wrote:

On 31/03/2024 23.08, Kevin Fenzi wrote:

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 release was also installed ...

You should pull the latest version and restart any containers you were
running.

kevin

I assume rawhide has been fixed, too? So that rawhide users also just need to 
follow the same instructions as F40? Or do they need to reinstall?

Yes. The downgrade was pushed out on friday along with the f40 one.


If possible, I would like to end the topic updates in Fedora Discussion 
tomorrow and suggest users that they can consider the issue solved once they 
conducted all suggested steps and thus stop following the topic anylonger, but 
for rawhide I still have the warning issued to not use it at this time. Is the 
rawhide issue still open?

No, it should have the same resolution as f40.

kevin

Thanks! I update it.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-01 Thread Kevin Fenzi

On Mon, Apr 01, 2024 at 05:07:13PM +, Christopher Klooz wrote:
> 
> On 31/03/2024 23.08, Kevin Fenzi wrote:
> > 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 release was also installed ...
> > You should pull the latest version and restart any containers you were
> > running.
> > 
> > kevin
> 
> I assume rawhide has been fixed, too? So that rawhide users also just need to 
> follow the same instructions as F40? Or do they need to reinstall?

Yes. The downgrade was pushed out on friday along with the f40 one. 

> If possible, I would like to end the topic updates in Fedora Discussion 
> tomorrow and suggest users that they can consider the issue solved once they 
> conducted all suggested steps and thus stop following the topic anylonger, 
> but for rawhide I still have the warning issued to not use it at this time. 
> Is the rawhide issue still open?

No, it should have the same resolution as f40.

kevin


signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Mon, 2024-04-01 at 12:16 -0500, Michael Catanzaro wrote:
> On Mon, Apr 1 2024 at 10:12:55 AM -07:00:00, Adam Williamson 
>  wrote:
> > This is not really correct, or at least at all relevant. The bug 
> > wasn't
> > in F40 Beta simply because the update never made it to 'stable'. Only
> > 'stable' packages go into *composes*. However, saying that is not
> > really useful because anyone who *installed* Beta and then updated it
> > regularly may have got the vulnerable package. We should not say
> > anything to give people the impression that if they installed Beta,
> > they don't need to worry. That is not true or helpful.
> 
> Thing is, the bug was fixed before Fedora 40 Beta was released. If you 
> installed the beta on or after the release date, you never got the 
> builds with ifuncs enabled. This is why it's correct to say that only 
> "pre-beta" builds were backdoored.

Oh, ISWYM. Well, I suppose yes, that does happen to be true. We could
communicate that if it's done very carefully and made really clear that
it's about the *time frame*, nothing to do with the repositories.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-01 Thread Michael Catanzaro

On Mon, Apr 1 2024 at 10:12:55 AM -07:00:00, Adam Williamson 
 wrote:
This is not really correct, or at least at all relevant. The bug 
wasn't

in F40 Beta simply because the update never made it to 'stable'. Only
'stable' packages go into *composes*. However, saying that is not
really useful because anyone who *installed* Beta and then updated it
regularly may have got the vulnerable package. We should not say
anything to give people the impression that if they installed Beta,
they don't need to worry. That is not true or helpful.


Thing is, the bug was fixed before Fedora 40 Beta was released. If you 
installed the beta on or after the release date, you never got the 
builds with ifuncs enabled. This is why it's correct to say that only 
"pre-beta" builds were backdoored.


Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

On Mon, 2024-04-01 at 09:32 -0500, Michael Catanzaro wrote:
> On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz 
>  wrote:
> > "Fedora Linux 40 branched users (i.e. pre-Beta) likely received the 
> > potentially vulnerable 5.6.0-2.fc40 build if the system updated 
> > between March 2nd and March 6th. Fedora Linux 40 Beta users only 
> > using stable repositories are NOT impacted. Fedora Linux 39 and 38 
> > users are also NOT impacted."
> > 
> >  -> only pre-beta, not beta, affected
> >   -> F40 beta using stable NOT impacted (without challenging the 
> > previously distributed assumption that testing is disabled by default)
> > 
> > That's still the same false information, isn't it?
> > 
> It looks correct to me. The bug was fixed prior to the final release of 
> F40 beta,

This is not really correct, or at least at all relevant. The bug wasn't
in F40 Beta simply because the update never made it to 'stable'. Only
'stable' packages go into *composes*. However, saying that is not
really useful because anyone who *installed* Beta and then updated it
regularly may have got the vulnerable package. We should not say
anything to give people the impression that if they installed Beta,
they don't need to worry. That is not true or helpful.

>  so describing it as "pre-beta" makes sense. And people who 
> used only the stable repos were indeed not affected. The article later 
> clarifies that updates-testing is enabled by default (although it would 
> be nicer to do this higher up rather than lower down the page).

For the same reason I think it's dangerous and not useful to try and
draw this distinction between notional "people who only use stable
repos" and people who use testing. Who would actually install F40 but
then manually turn updates-testing off? Very few people. I don't think
we should talk about this because it just confuses the issue. It would
be like saying a stable release security issue that appeared in a
stable update didn't affect people who turned off the updates repo.
Technically true, but people don't do that, why would we say it?

We should have a simple and clear message that covers the most common
and important case: if you installed Fedora 40 and updated regularly
during the vulnerable time frame, you very likely got the vulnerable
package and should take appropriate action. We should not confuse this
with unnecessary verbiage about stable and testing and pre-Beta and
post-Beta.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]

2024-04-01 Thread Gary Buhrmaster

On Mon, Apr 1, 2024 at 4:42 PM Adam Williamson
 wrote:

> I think we *are* part of a supply chain, regardless of any handwaving
> about The Open Source Model.

And, more importantly, the industry has agreed
to use the term supply chain.  Is the term
perhaps overloaded, or perhaps too
ill-defined/imprecise?  Sure.  But if one wants
to use a different term one would need to work
across the industry to change the term, and
that is not going to happen.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor



On 31/03/2024 23.08, Kevin Fenzi wrote:

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 release was also installed ...

You should pull the latest version and restart any containers you were
running.

kevin


I assume rawhide has been fixed, too? So that rawhide users also just need to 
follow the same instructions as F40? Or do they need to reinstall?

If possible, I would like to end the topic updates in Fedora Discussion 
tomorrow and suggest users that they can consider the issue solved once they 
conducted all suggested steps and thus stop following the topic anylonger, but 
for rawhide I still have the warning issued to not use it at this time. Is the 
rawhide issue still open?
--
___
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

Understood. However, at least for those unit tests run in the %check, it 
is going to be almost unfeasible, because of the variability of the way 
things are done in the different programming ecosystems. In Java, unit 
tests are nicely separated in a different folder (i.e., `src/test`), but 
in golang, it is mingled with the source code in `_test.go` files. In C, 
it depends on the programmers convention.


On 4/1/24 09:29, Adam Williamson wrote:

On Mon, 2024-04-01 at 05:58 -0700, Carlos Rodriguez-Fernandez wrote:

Test isolation is still assuming the attack comes in the test phase.


As I initially suggested it, it does not. My suggestion was that we
ensure the test code is not available to the prep / build / install
phases *at all*, and is only made available to the test phase.


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: xz backdoor

On 01/04/2024 16.32, Michael Catanzaro wrote:

On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz
wrote:

"Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially
vulnerable 5.6.0-2.fc40 build if the system updated between March 2nd and March 6th.
Fedora Linux 40 Beta users only using stable repositories are NOT impacted. Fedora Linux
39 and 38 users are also NOT impacted."

-> only pre-beta, not beta, affected
-> F40 beta using stable NOT impacted (without challenging the previously
distributed assumption that testing is disabled by default)

That's still the same false information, isn't it?

It looks correct to me. The bug was fixed prior to the final release of F40 beta, so
describing it as "pre-beta" makes sense. And people who used only the stable
repos were indeed not affected. The article later clarifies that updates-testing is
enabled by default (although it would be nicer to do this higher up rather than lower
down the page).

Interesting. I thought the below note about "testing = enabled by default" was already
mentioned before. I was only worried about the top section. The abstract decides if people keep
reading, and with the previously spread information, I had doubt that the sentence motivates people
to read further. So I assume the "stable repo not impacted" sentence suggests something
false given the previously established context (default = stable, not testing).

Concerning your argument that the bug was fixed prior to the beta release, I
answered on the Fedora Discussion topic [1] (to avoid duplication here) since I
am not sure if I understand what you mean (and what it implies for the majority
of users).

Btw, thanks for your elaborations and clarifications in the recent days ;)

[1]
https://discussion.fedoraproject.org/t/xz-lessons-learned-if-how-to-involve-fedora-magazine-in-cve-handling/111255/16
--
___
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

What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]

On Mon, 2024-04-01 at 12:27 -0400, Neal Gompa wrote:
> > 
> > ii) the fact that this attack reinforces the painful truth that
> > sophisticated attackers *are* extremely interested in attacking the
> > supply chain of which we form a significant component
> 
> Can we please reframe it for what it actually is? This is an attack on
> open source communities. "Supply chain" implies a lot of things that
> simply don't exist in open source development. Almost the entirety of
> the sophistication of the attack was social engineering, not technical
> engineering. There *are* technical things to improve, for sure, but
> let's not try to make it sound like it's a wholly technical thing that
> can be solved with technical solutions exclusively. There are people
> and community problems that need addressing too.

This feels like a derail, so splitting it into a separate subthread.

Honestly, I don't see how the first part of your paragraph relates to
the second. I agree with a lot of the second part, but not the first.

I think we *are* part of a supply chain, regardless of any handwaving
about The Open Source Model. If you are part of producing stuff that
people use to do Real Life Stuff, you are part of a supply chain. You
might want to disclaim various responsibilities for various reasons,
but you still are. If you don't want to be part of a supply chain, stop
supplying stuff. I get the argument that there's a difference between
putting a plank over a stream with a CROSS AT YOUR OWN RISK sign and
charging people to cross your toll bridge, but there are *also* some
similarities.

I agree that the social engineering aspects of this attack were very
significant (though I disagree that was "almost the entirety of the
sophistication" - the technical elements were also pretty
sophisticated). But I don't see why that leads to bikeshedding about
whether this is a "supply chain" attack or not. Why is a "social
engineering attack" not a supply chain attack, but a "technical attack"
is?
-- 
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

Schedule for Monday's FESCo Meeting (2024-04-01)

2024-04-01 Thread Josh Stone

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org
on Matrix.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2024-04-01 19:30 UTC'

Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

None

= Followups =

#3173 F40 Change Proposal Status: Incomplete Changes
https://pagure.io/fesco/issue/3173

= New business =

None

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

On Mon, 2024-04-01 at 05:58 -0700, Carlos Rodriguez-Fernandez wrote:
> Test isolation is still assuming the attack comes in the test phase.

As I initially suggested it, it does not. My suggestion was that we
ensure the test code is not available to the prep / build / install
phases *at all*, and is only made available to the test phase.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-01 Thread Neal Gompa

On Mon, Apr 1, 2024 at 12:22 PM Adam Williamson
 wrote:
>
> On Mon, 2024-04-01 at 10:56 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote:
> > > Adam Williamson wrote:
> > > > Maybe this needs to go on the growing pile of reasons why the
> > > > traditional Linux model *does* need to go away. Maybe Fedora, with its
> > > > foundation of First, should be kind of at the forefront of making that
> > > > happen.
> > >
> > > Switching to a container-based model is just going to introduce more
> > > different library versions (in the worst case, one per container) with a
> > > higher probability that one of them is compromised.
> >
> > Our traditional distro model is not perfect — far from it — and we
> > certainly try to improve it. But I agree with Kevin that in _this
> > particular case_, the other models have smaller chances of catching
> > the issue.
> >
> > Here the upstream was compromised, so 2FA, upstream signatures, and any
> > other checks don't help at all.
>
> Yes, to be clear, my "this" was not "the specific technical details of
> this attack". It was more:
>
> i) the factors I listed in my email about just how many people are
> trusted to build 'Fedora', when 'Fedora' is essentially a collection of
> arbitrary scripts executed as root
>
> ii) the fact that this attack reinforces the painful truth that
> sophisticated attackers *are* extremely interested in attacking the
> supply chain of which we form a significant component

Can we please reframe it for what it actually is? This is an attack on
open source communities. "Supply chain" implies a lot of things that
simply don't exist in open source development. Almost the entirety of
the sophistication of the attack was social engineering, not technical
engineering. There *are* technical things to improve, for sure, but
let's not try to make it sound like it's a wholly technical thing that
can be solved with technical solutions exclusively. There are people
and community problems that need addressing too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

On Mon, 2024-04-01 at 10:56 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote:
> > Adam Williamson wrote:
> > > Maybe this needs to go on the growing pile of reasons why the
> > > traditional Linux model *does* need to go away. Maybe Fedora, with its
> > > foundation of First, should be kind of at the forefront of making that
> > > happen.
> > 
> > Switching to a container-based model is just going to introduce more 
> > different library versions (in the worst case, one per container) with a 
> > higher probability that one of them is compromised.
> 
> Our traditional distro model is not perfect — far from it — and we
> certainly try to improve it. But I agree with Kevin that in _this
> particular case_, the other models have smaller chances of catching
> the issue.
> 
> Here the upstream was compromised, so 2FA, upstream signatures, and any
> other checks don't help at all.

Yes, to be clear, my "this" was not "the specific technical details of
this attack". It was more:

i) the factors I listed in my email about just how many people are
trusted to build 'Fedora', when 'Fedora' is essentially a collection of
arbitrary scripts executed as root

ii) the fact that this attack reinforces the painful truth that
sophisticated attackers *are* extremely interested in attacking the
supply chain of which we form a significant component
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-01 Thread Scott Schmit

On Mon, Apr 01, 2024 at 02:23:19PM -, François Rigault wrote:
> > Those blobs were not in systemd,
> 
> that was not my point, nevertheless putting it this way: nobody knows.
> 
> For the example about compression methods you could generate your binary 
> using a piece of code, that can be reviewed (maybe using a fixed seed as 
> inspired by
> https://git.rootprojects.org/root/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89
>  btw!). If you want to test systemd against a broken journal then can't you 
> commit a valid journal (that can be reviewed) and some code that generates a 
> corrupted one?
> 
> The obfuscated C code is a different problem - at least it can be 
> reviewed/audited and the maintainer can ask to simplify it.
> 
> My point is that everything should get reviewed before merge. I would hope 
> that, as a lesson learnt from this attack, no unreviewed "corrupted binary" 
> exist anymore in any project, since really, nobody knows what they actually 
> contain.

Or (if production of the binary is expensive or can be fiddly), commit
the binary but include a script to generate it that can be run by others
to check that the included binary is legit.

Call it "Reproducible Tests" to go along with reproducible builds.

Cryptography has the same concept now, learning from the Dual EC DBRG
backdoor: https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number

So "nothing-up-my-sleeve scripts" could be another moniker.

-- 
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: 
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-04-01 Thread Miroslav Suchý


Dne 01. 04. 24 v 3:16 dop. Kilian Hanich via devel napsal(a):

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. 


Can you point me to such case, please? Just being curious.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Outage alert: openQA result reporting (affects critical path gating), nightly page updating, candidate compose nominations

On Mon, 2024-04-01 at 08:53 -0700, Adam Williamson wrote:
> as a stopgap I
> will manually trigger submission of all reports from the last couple of
> days shortly.

correction: I won't do this right away, as there would be a flood of
duplicate reports if I did then fix the consumers. If I can't fix the
consumers relatively soon I'll bite that bullet and do it, though.
-- 
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

Outage alert: openQA result reporting (affects critical path gating), nightly page updating, candidate compose nominations

Hi folks! I just discovered this so I'm still investigating it, but
wanted to give a quick heads-up.

It looks like the message consumers on openqa01 all broke on Saturday
when a fedora-messaging update landed. This affects a lot of things,
but by far the most important is that openQA test results are not
getting reported to resultsdb. This will be causing all critpath
updates to be stuck in gating.

I am going to investigate this urgently, of course, and as a stopgap I
will manually trigger submission of all reports from the last couple of
days shortly. Very sorry for the inconvenience.

Also affected: https://openqa.fedoraproject.org/nightlies.html and
.json are not getting updated, validation test events are not being
created, check-compose emails not being generated, possibly something
else I've forgotten.
-- 
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

Fedora 40 compose report: 20240401.n.0 changes

2024-04-01 Thread Fedora Branched Report

OLD: Fedora-40-20240331.n.0
NEW: Fedora-40-20240401.n.0

= SUMMARY =
Added images:3
Dropped images:  0
Added packages:  4
Dropped packages:0
Upgraded packages:   82
Downgraded packages: 0

Size of added packages:  4.82 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.27 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -5.79 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-40-20240401.n.0.iso
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240401.n.0.ociarchive
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240401.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: crun-vm-0.1.3-2.fc40
Summary: An OCI Runtime that runs VM images
RPMs:crun-vm
Size:4.44 MiB

Package: rust-fs4-0.8.1-1.fc40
Summary: No libc, pure Rust cross-platform file locks
RPMs:rust-fs4+async-std-devel rust-fs4+async-trait-devel 
rust-fs4+default-devel rust-fs4+sync-devel rust-fs4+tokio-devel rust-fs4-devel
Size:68.44 KiB

Package: rust-tree-sitter0.20-0.20.10-1.fc40
Summary: Rust bindings to the Tree-sitter parsing library
RPMs:rust-tree-sitter0.20+default-devel 
rust-tree-sitter0.20+lazy_static-devel rust-tree-sitter0.20-devel
Size:142.26 KiB

Package: rust-wasmparser-0.201.0-1.fc40
Summary: Simple event-driven library for parsing WebAssembly binary files
RPMs:rust-wasmparser+default-devel rust-wasmparser-devel
Size:177.00 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  arc-kde-20220908-9.fc40
Old package:  arc-kde-20220908-6.fc40
Summary:  Port of the popular GTK theme Arc for the Plasma 5 desktop
RPMs: arc-kde arc-kde-decorations arc-kde-konsole arc-kde-konversation 
arc-kde-kvantum arc-kde-wallpapers arc-kde-yakuake
Size: 31.73 MiB
Size change:  677 B
Changelog:
  * Tue Mar 26 2024 Arthur Bols  - 20220908-7
  - Patch for plasma 6 support

  * Tue Mar 26 2024 Arthur Bols  - 20220908-8
  - Add missing arc-kde-plasma-6-support.patch

  * Tue Mar 26 2024 Arthur Bols  - 20220908-9
  - Update plasma 6 patch


Package:  bird-2.15.1-1.fc40
Old package:  bird-2.15-1.fc40
Summary:  BIRD Internet Routing Daemon
RPMs: bird bird-doc
Size: 3.14 MiB
Size change:  1.36 KiB
Changelog:
  * Sat Mar 23 2024 Robert Scheck  - 2.15.1-1
  - Upgrade to 2.15.1 (#2270927)


Package:  deepin-qt5integration-5.6.11-6.fc40
Old package:  deepin-qt5integration-5.6.11-5.fc40
Summary:  Qt platform theme integration plugins for DDE
RPMs: deepin-qt5integration
Size: 1.84 MiB
Size change:  4.39 KiB
Changelog:
  * Fri Mar 15 2024 Jan Grulich  - 5.6.11-6
  - Rebuild (qt5)


Package:  deepin-qt5platform-plugins-5.6.12-6.fc40
Old package:  deepin-qt5platform-plugins-5.6.12-5.fc40
Summary:  Qt platform integration plugins for Deepin Desktop Environment
RPMs: deepin-qt5platform-plugins
Size: 1.36 MiB
Size change:  609 B
Changelog:
  * Fri Mar 15 2024 Jan Grulich  - 5.6.12-6
  - Rebuild (qt5)


Package:  doctest-2.4.11-1.fc40
Old package:  doctest-2.4.9-7.fc40
Summary:  Feature-rich header-only C++ testing framework
RPMs: doctest-devel
Size: 449.99 KiB
Size change:  26.78 KiB
Changelog:
  * Sat Mar 23 2024 Nick Black  - 2.4.11-1
  - drop patch for 2.4.9; merged upstream


Package:  dwayland-5.25.0-5.fc40
Old package:  dwayland-5.25.0-4.fc40
Summary:  Qt-style Client and Server library wrapper for the Wayland 
libraries
RPMs: dwayland dwayland-devel
Size: 4.01 MiB
Size change:  956 B
Changelog:
  * Mon Mar 18 2024 topazus  - 5.25.0-5
  - rebuild qt5


Package:  eccodes-2.34.1-2.fc40
Old package:  eccodes-2.33.0-3.fc40
Summary:  WMO data format decoding and encoding
RPMs: eccodes eccodes-data eccodes-devel eccodes-doc
Size: 12.68 MiB
Size change:  300.81 KiB
Changelog:
  * Tue Feb 27 2024 Jos de Kloe  - 2.34.1-1
  - Update to 2.34.1

  * Mon Mar 04 2024 Jos de Kloe  - 2.34.1-2
  - Require openjpeg2-devel >= 2.5.2 (needed to build for f40)


Package:  emacs-company-mode-0.10.2-1.fc40
Old package:  emacs-company-mode-0.10.1-3.fc40
Summary:  Modular in-buffer completion framework for Emacs
RPMs: emacs-company-mode
Size: 142.80 KiB
Size change:  197 B
Changelog:
  * Sat Mar 23 2024 Jerry James  - 0.10.2-1
  - Version 0.10.2


Package:  fcitx-qt5-1.2.6-20.fc40
Old package:  fcitx-qt5-1.2.6-19.fc40
Summary:  Fcitx IM module for Qt5
RPMs: fcitx-qt5 fcitx-qt5-devel
Size: 1.07 MiB
Size change:  306 B
Changelog:
  * Fri Mar 15 2024 Jan Grulich  - 1.2.6-20
  - Rebuild (qt5)


Package:  fcitx5-qt-5.1.5-2.fc40
Old package:  fcitx5-qt-5.1.5-1.fc40
Summary:  Qt library and IM module for fcitx5
RPMs: fcitx5-qt fcitx5-qt-devel fcitx5

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

Definitely this attack leveraged places where eyes don't look:
distributed tar.gz and blobs.

I put the PoC to flag those two in github[1]

Example output:

$ ./rpmseclint tests/rpmseclint-test.spec
-Diff-
~ test.txt
+ additional.txt
+ blob.txt.gz
-Blobs
application/gzip blob.txt.gz

Now, against the PoC itself, the diff part can be totally avoided by
using generated tars. Not all projects are in github, but those that
do... The other way is by using source-git?

Regarding the blobs part, ... an attack could still manage to fool
`file` with a crafted binary. However, that would still increase the
attack complexity.

[1] https://github.com/carlosrodfern/rpmseclint

On 3/31/24 19:02, Carlos Rodriguez-Fernandez wrote:

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.1 audit-libs
/lib64/libc.so.6 glibc
/lib64/libcap-ng.so.0 libcap-ng
/lib64/libcap.so.2 libcap
/lib64/libcom_err.so.2 libcom_err
/lib64/libcrypt.so.2 libxcrypt
/lib64/libcrypto.so.3 openssl-libs
/lib64/libeconf.so.0 libeconf
/lib64/libgcc_s.so.1 libgcc
/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.6 glibc
/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.1 zlib / 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

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


I created a discussion issue for this idea:

https://github.com/rpm-software-management/rpm/discussions/3009

I think it worth pursuing further.

On 4/1/24 04:46, Neal Gompa wrote:

On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek
 wrote:


On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote:

On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:

Adam,

Is there a way already to achieve test isolation during the rpm build?


Nothing systematic that I'm aware of, no. It would be tricky because
there is no one universal Standard Test System (not even within a
single language ecosystem, let alone across all of them). Currently
you'd have to design something unique, if you wanted to implement this
for your package.


If we wanted to pursue that, I'd suggest the following:
remount $RPM_BUILD_ROOT read-only for the %check phase
(or maybe overmount it with a writable overlayfs that is thrown
away after %check finishes, and warn if any modifications were made.)
%check is executed after %install, so everything should be in place
before %check, and %check may be skipped, so no modifications to
installed files should be done in %check.

Considering possible implemention details, machinectl has 'bind' and
'bind --read-only' that might be useful here. But mock uses
systemd-nspawn in a way that does register the container with machined.
So maybe it'd be more reasonable to just execute a mount command directly
from mock.

This is independent of the test system and does not require splitting
of the test sources.



Another thing to consider is making RPM unshare each build phase like
it can for scriptlets now at install time[1].

Sandboxing and limiting in rpmbuild itself like we can with rpm can
also help with this. I believe moss[2]' boulder tool does this.

[1]: https://github.com/rpm-software-management/rpm/pull/2666
[2]: https://github.com/serpent-os/moss/tree/main/boulder




--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


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: xz backdoor

2024-04-01 Thread Michael Catanzaro

On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz 
 wrote:
"Fedora Linux 40 branched users (i.e. pre-Beta) likely received the 
potentially vulnerable 5.6.0-2.fc40 build if the system updated 
between March 2nd and March 6th. Fedora Linux 40 Beta users only 
using stable repositories are NOT impacted. Fedora Linux 39 and 38 
users are also NOT impacted."


 -> only pre-beta, not beta, affected
  -> F40 beta using stable NOT impacted (without challenging the 
previously distributed assumption that testing is disabled by default)


That's still the same false information, isn't it?

It looks correct to me. The bug was fixed prior to the final release of 
F40 beta, so describing it as "pre-beta" makes sense. And people who 
used only the stable repos were indeed not affected. The article later 
clarifies that updates-testing is enabled by default (although it would 
be nicer to do this higher up rather than lower down the page).


--
___
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-04-01 Thread François Rigault

> Those blobs were not in systemd,

that was not my point, nevertheless putting it this way: nobody knows.

For the example about compression methods you could generate your binary using 
a piece of code, that can be reviewed (maybe using a fixed seed as inspired by
https://git.rootprojects.org/root/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89
 btw!). If you want to test systemd against a broken journal then can't you 
commit a valid journal (that can be reviewed) and some code that generates a 
corrupted one?

The obfuscated C code is a different problem - at least it can be 
reviewed/audited and the maintainer can ask to simplify it.

My point is that everything should get reviewed before merge. I would hope 
that, as a lesson learnt from this attack, no unreviewed "corrupted binary" 
exist anymore in any project, since really, nobody knows what they actually 
contain.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20240401.n.0 changes

2024-04-01 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20240331.n.0
NEW: Fedora-Rawhide-20240401.n.0

= SUMMARY =
Added images:3
Dropped images:  1
Added packages:  1
Dropped packages:0
Upgraded packages:   17
Downgraded packages: 0

Size of added packages:  68.66 KiB
Size of dropped packages:0 B
Size of upgraded packages:   7.32 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   120.04 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server_KVM qcow2 ppc64le
Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20240401.n.0.ppc64le.qcow2
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20240401.n.0.iso
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-Rawhide.20240401.n.0.ociarchive

= DROPPED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240331.n.0.iso

= ADDED PACKAGES =
Package: rust-rustls-pki-types-1.4.1-1.fc41
Summary: Shared types for the rustls PKI ecosystem
RPMs:rust-rustls-pki-types+alloc-devel rust-rustls-pki-types+default-devel 
rust-rustls-pki-types+std-devel rust-rustls-pki-types+web-devel 
rust-rustls-pki-types-devel
Size:68.66 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  SuperLU-6.0.1-4.fc41
Old package:  SuperLU-6.0.1-3.fc40
Summary:  Subroutines to solve sparse linear systems
RPMs: SuperLU SuperLU-devel SuperLU-doc
Size: 2.00 MiB
Size change:  -2.34 KiB
Changelog:
  * Sun Mar 31 2024 Antonio Trande  - 6.0.1-4
  - Rebuild against Flexiblas on EPEL9 (rhbz#2257325)


Package:  amarok-2.9.71^git20240330.7ec45dd-1.fc41
Old package:  amarok-2.9.71^git20231231.387c30d-3.fc40
Summary:  Media player
RPMs: amarok amarok-doc amarok-libs amarok-utils
Size: 49.15 MiB
Size change:  -197.55 KiB
Changelog:
  * Sun Mar 31 2024 Marc Deop i Argem??  - 
2.9.71^git20240330.7ec45dd-1
  - Update to snapshot 7ec45dddb109fd391b900dad8705dacd4088a3c3


Package:  assimp-5.3.1-1.fc41
Old package:  assimp-5.2.5-4.fc40
Summary:  Library to import various 3D model formats into applications
RPMs: assimp assimp-devel assimp-doc python3-assimp
Size: 13.00 MiB
Size change:  13.82 KiB
Changelog:
  * Sun Mar 31 2024 Rich Mattes  - 5.3.1-1
  - Update to release 5.3.1
  - Resolves: rhbz#2256587


Package:  dotnet6.0-6.0.128-1.fc41
Old package:  dotnet6.0-6.0.127-2.fc41
Summary:  .NET Runtime and SDK
RPMs: aspnetcore-runtime-6.0 aspnetcore-targeting-pack-6.0 dotnet 
dotnet-apphost-pack-6.0 dotnet-hostfxr-6.0 dotnet-runtime-6.0 dotnet-sdk-6.0 
dotnet-sdk-6.0-source-built-artifacts dotnet-targeting-pack-6.0 
dotnet-templates-6.0
Size: 7.23 GiB
Size change:  124.50 MiB
Changelog:
  * Wed Mar 27 2024 Omair Majid  - 6.0.128-1
  - Update to .NET SDK 6.0.128 and Runtime 6.0.28


Package:  goverlay-1.1.1-1.fc41
Old package:  goverlay-0.9-7.fc40
Summary:  Project that aims to create a Graphical UI to help manage Linux 
overlays
RPMs: goverlay
Size: 8.44 MiB
Size change:  -5.20 MiB
Changelog:
  * Sun Mar 31 2024 Artem Polishchuk  - 0.9-8
  - license: Convert to SPDX

  * Sun Mar 31 2024 Artem Polishchuk  - 0.9-9
  - build: Add Packit config

  * Sun Mar 31 2024 Artem Polishchuk  - 1.0-1
  - chore: Update to 1.0

  * Sun Mar 31 2024 Artem Polishchuk  - 1.0-2
  - build: lazarus-lcl-qt5 only for >=f39

  * Sun Mar 31 2024 Artem Polishchuk  - 1.1.1-1
  - build: Update to 1.1.1


Package:  libayatana-appindicator-0.5.93-5.fc41
Old package:  libayatana-appindicator-0.5.93-4.fc41
Summary:  Ayatana Application Indicators
RPMs: libayatana-appindicator-gtk2 libayatana-appindicator-gtk2-devel 
libayatana-appindicator-gtk2-sharp libayatana-appindicator-gtk2-sharp-devel 
libayatana-appindicator-gtk3 libayatana-appindicator-gtk3-devel 
libayatana-appindicator-gtk3-sharp libayatana-appindicator-gtk3-sharp-devel
Size: 1.17 MiB
Size change:  3.78 KiB
Changelog:
  * Sun Mar 31 2024 Yaakov Selkowitz  - 0.5.93-5
  - Fix flatpak build


Package:  mingw-zstd-1.5.6-1.fc41
Old package:  mingw-zstd-1.5.5-4.fc40
Summary:  MinGW Windows zstd library
RPMs: mingw32-zstd mingw64-zstd
Size: 925.54 KiB
Size change:  3.16 KiB
Changelog:
  * Sun Mar 31 2024 Sandro Mani  - 1.5.6-1
  - Update to 1.5.6


Package:  perl-Catalyst-Manual-1:5.9013-1.fc41
Old package:  perl-Catalyst-Manual-1:5.9012-1.fc40
Summary:  Catalyst web framework manual
RPMs: perl-Catalyst-Manual
Size: 376.37 KiB
Size change:  90 B
Changelog:
  * Sun Mar 31 2024 Emmanuel Seyman  - 1:5.9013-1
  - Update to 5.9013


Package:  perl-DBD-Firebird-1.34-10.fc41
Old package:  perl-DBD-Firebird-1.34-8.fc39
Summary:  Firebird interface for perl
RPMs: perl-DBD-Firebird
Size: 458.11 KiB
Size change:  -2.95 KiB
Changelog:
  * Sun Jan 21 2024 Fedora Release Engineering  - 
1.3

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



Test isolation is still assuming the attack comes in the test phase. The 
attack can come in the `make`, or in the `make install` too. That's why 
the idea of other techniques being discussed are still valid, but 
perhaps not abstracted out enough for a wider defense.


However, the test isolation concept is a good defense. Once the build 
artifacts is generated, the integrity of the build artifacts must be 
ensured during any post build phase. Some tests do expect to be executed 
right after the build, when the build artifacts are still in specific 
directories within the source root, so that's why I was thinking of 
something more like at the file system level (e.g., a snapshot that it 
is then restored, or something like that).


On 3/31/24 23:20, Adam Williamson wrote:

On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:

Adam,

Is there a way already to achieve test isolation during the rpm build?


Nothing systematic that I'm aware of, no. It would be tricky because
there is no one universal Standard Test System (not even within a
single language ecosystem, let alone across all of them). Currently
you'd have to design something unique, if you wanted to implement this
for your package.

I suppose one approach would be to split the sources-required-for-build
and the test suite into Source0 and Source1 (respectively) and only
extract Source0 during %prep. Don't extract Source1 until %check (i.e.
after %build and %install are already done). I'm just spitballing,
though, haven't checked if this is really practical.

Of course, another approach is to really do what Kevin suggests and not
ship the test suite in the package source at all, but instead run the
tests via Fedora CI, and configure the package to be gated on that CI
check (so it wouldn't go to stable without the tests passing). But
that's rather a different approach (and would still require 'custom'
work to cut the tests out of the source, or at least delete them before
running the build).

And I still think at this point we are falling into the trap of
thinking too specifically about an attack vector which just *happens*
to be the one chosen in *this specific instance*. It's still
worthwhile, on some level, for someone to think about that kind of
hardening, of course. I am just not convinced it is the most useful
thing Fedora could be doing right now in the general area of "supply
chain hardening".


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: xz backdoor

On 31/03/2024 21.33, Sandro wrote:

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
know who can fix this?

The Fedora Magazine article has been fixed (thanks!).

"*Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially
vulnerable /5.6.0-2.fc40/ build
if the system updated
between March 2nd and March 6th*. Fedora Linux 40 Beta users only using stable repositories are
NOT impacted. Fedora Linux 39 and 38 users are also NOT impacted."

-> only pre-beta, not beta, affected
-> F40 beta using stable NOT impacted (without challenging the previously
distributed assumption that testing is disabled by default)

That's still the same false information, isn't it?

Justin just has shown up in discourse. I suggested to get in touch with you,
Adam or Kevin since he seemed to be convinced the article is fine as it is.
When I refresh the article, it still seems to be unchanged. Is the update you
mean already online Michael?

I clarified what's wrong with Justin in a DM on Matrix. He was on the same garden path as I was
regarding "Beta release" vs. "Final release".

There will be another update to the article.

-- Sandro
--

Given the issues we had in the recent days in the communications between Fedora
Magazine, a discussion if and/or how to use it in CVE handling has evolved in
Fedora Discussions. I have just moved this into a dedicated topic, in case you
want to add your perspectives:
https://discussion.fedoraproject.org/t/xz-lessons-learned-if-how-to-involve-fedora-magazine-in-cve-handling/111255
--
___
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-04-01 Thread Sam Varshavchik


Christoph Erhardt writes:


I strongly oppose this suggestion. While it would have prevented this
particular backdoor as a side-effect, the primary effect of going without  
unit

tests would be an outsize hole in Fedora's QA.


There have been several suggestions here for ways that this specific attempt  
from succeeding.


Any one of them will be very useful as long as it is guaranteed that all  
backdoor/supply chain attacks in the future are attempted in the exact same  
technical way.




pgpWXQfPOVO6k.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-01 Thread Stephen Smoogen

On Mon, 1 Apr 2024 at 04:47, François Rigault 
wrote:

> To echo
>
> > To trust code, it needs to be reviewed.
> > If the code is reviewed, and the build system is sane, [..]
>
> I deduce from your response that the binary tests committed in systemd
> were not reviewed neither by co-maintainers nor by downstream package
> maintainers.
>
>
Are we talking about the blobs which contained the malware? Those blobs
were not in systemd, they were in the compression library. You are going to
see weird blobs in any compression library because compression needs to
test how it does against different data types.. especially binary data
because you need to see if you improved or worsened the compression with a
change. The places you are going to see binary data which may not make any
'sense' are: compression, anything graphics related, sound and general
archiving tools. You will find actually 'binaries' in various parts of any
compilation set because you may be linking or 'embedding' it into code that
will run something else.

But that is just where you are just sticking plain binary data. You can
uuencode, base64 or many other things and put it into regular code in
places where you might need to run some stuff. They went after ssh most
likely because the main target was internet based attacks. However they
could have gone a slightly different path and used dnf/apt (rpm/dpkg) as
the target application and placed additional scripts to open systems up
somewhere. This could be done with a nice bit of C code which usually does
one thing but for what would look like legitimate reasons does something
else after a certain date or code sequence. Anyone who has tried to read
through an obfuscated C contest entry can see where this is going.



> I understand that the build system used by systemd makes it much less
> probable that some binary blob used in a test obfuscates something that
> could be used for other purposes outside the test; still, wouldn't you
> agree it would be a good practice to make sure everyone is able to review
> everything in the source code repository?
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-01 Thread Neal Gompa

On Mon, Apr 1, 2024 at 7:38 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote:
> > On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:
> > > Adam,
> > >
> > > Is there a way already to achieve test isolation during the rpm build?
> >
> > Nothing systematic that I'm aware of, no. It would be tricky because
> > there is no one universal Standard Test System (not even within a
> > single language ecosystem, let alone across all of them). Currently
> > you'd have to design something unique, if you wanted to implement this
> > for your package.
>
> If we wanted to pursue that, I'd suggest the following:
> remount $RPM_BUILD_ROOT read-only for the %check phase
> (or maybe overmount it with a writable overlayfs that is thrown
> away after %check finishes, and warn if any modifications were made.)
> %check is executed after %install, so everything should be in place
> before %check, and %check may be skipped, so no modifications to
> installed files should be done in %check.
>
> Considering possible implemention details, machinectl has 'bind' and
> 'bind --read-only' that might be useful here. But mock uses
> systemd-nspawn in a way that does register the container with machined.
> So maybe it'd be more reasonable to just execute a mount command directly
> from mock.
>
> This is independent of the test system and does not require splitting
> of the test sources.
>

Another thing to consider is making RPM unshare each build phase like
it can for scriptlets now at install time[1].

Sandboxing and limiting in rpmbuild itself like we can with rpm can
also help with this. I believe moss[2]' boulder tool does this.

[1]: https://github.com/rpm-software-management/rpm/pull/2666
[2]: https://github.com/serpent-os/moss/tree/main/boulder




--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2272395] perl-IO-Compress-2.208 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2024-b9ddd82efc (perl-IO-Compress-2.208-1.fc41) has been submitted as an
update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-b9ddd82efc


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272395%23c1
--
___
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

On Sun, Mar 31, 2024 at 11:20:17PM -0700, Adam Williamson wrote:
> On Sun, 2024-03-31 at 22:13 -0700, Carlos Rodriguez-Fernandez wrote:
> > Adam,
> > 
> > Is there a way already to achieve test isolation during the rpm build?
> 
> Nothing systematic that I'm aware of, no. It would be tricky because
> there is no one universal Standard Test System (not even within a
> single language ecosystem, let alone across all of them). Currently
> you'd have to design something unique, if you wanted to implement this
> for your package.

If we wanted to pursue that, I'd suggest the following:
remount $RPM_BUILD_ROOT read-only for the %check phase
(or maybe overmount it with a writable overlayfs that is thrown
away after %check finishes, and warn if any modifications were made.)
%check is executed after %install, so everything should be in place
before %check, and %check may be skipped, so no modifications to
installed files should be done in %check.

Considering possible implemention details, machinectl has 'bind' and
'bind --read-only' that might be useful here. But mock uses
systemd-nspawn in a way that does register the container with machined.
So maybe it'd be more reasonable to just execute a mount command directly
from mock.

This is independent of the test system and does not require splitting
of the test sources.

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

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

Yep.

And since we're talking about xz, note that a second malicious issue has
beend found: [1] is a revert of [2] which sabotages CMakeLists.txt
to always disable Landlock sandbox.

Clearly, the only reasonable solution is to delete all the CMake cruft ;)

[1] 
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00
[2] 
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

On Mon, Apr 01, 2024 at 08:46:39AM -, François Rigault wrote:
> To echo
> 
> > To trust code, it needs to be reviewed. 
> > If the code is reviewed, and the build system is sane, [..]
> 

> I deduce from your response that the binary tests committed in
> systemd were not reviewed neither by co-maintainers nor by
> downstream package maintainers.

Yes, some of those blobs are treated as opaque.

> I understand that the build system used by systemd makes it much
> less probable that some binary blob used in a test obfuscates
> something that could be used for other purposes outside the test;
> still, wouldn't you agree it would be a good practice to make sure
> everyone is able to review everything in the source code repository?

It's a trade-off. We can include a useful test case (e.g. a journal
file that causes journalctl to busyloop or crash), to verify that the
issue was fixed and that we don't regress, or we can reject the file
and forego the test.

With a reasonable build system, it's fairly easy to figure out how
the file is used, and I think it's entirely reasonable to review _that_.

OTOH, figuring out what effect that file would have if (hypothetically)
used as input to a different tool or whether it might embed some code
which might be extracted somehow is hard. But I really think that the
risk is low. Also, consider that systemd has 2500 .c and .h files with
875k lines… It's not like you can review that in a weekend.

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2272395] perl-IO-Compress-2.208 is available

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

Paul Howarth  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
   Assignee|jples...@redhat.com |p...@city-fan.org
 Status|NEW |ASSIGNED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272395
--
___
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

On Sun, Mar 31, 2024 at 07:54:08PM +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > Maybe this needs to go on the growing pile of reasons why the
> > traditional Linux model *does* need to go away. Maybe Fedora, with its
> > foundation of First, should be kind of at the forefront of making that
> > happen.
> 
> Switching to a container-based model is just going to introduce more 
> different library versions (in the worst case, one per container) with a 
> higher probability that one of them is compromised.

Our traditional distro model is not perfect — far from it — and we
certainly try to improve it. But I agree with Kevin that in _this
particular case_, the other models have smaller chances of catching
the issue.

Here the upstream was compromised, so 2FA, upstream signatures, and any
other checks don't help at all.

But in our "traditional model" we have one version of the dependency
used for everbody, so there is a strong incentive to review and
improve this one particular version. The packaging process is also
very open: it is absolutely routine for people to change packagaging
for packages owned by other maintainers.

The newfangled models are much more about picking particular versions
of dependencies and duplicating them in multiple projects. This makes
some things easier, and makes things more independent, but I think
it'd make the xz bug less likely to be caught. If sshd was packaged as
a container or a flatpak, and I saw that it takes .8 instead of .1
seconds to log in, I certainly wouldn't spend the time to figure out
why. I'd assume that the authors did something strange and move on to
my own things.

We talk a lot about the "new ways", but software must still come from
somewhere, and the dependencies need to be maintained… Changing the
delivery format is not going to magically makes this unnecessary.

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-01 Thread François Rigault

To echo

> To trust code, it needs to be reviewed. 
> If the code is reviewed, and the build system is sane, [..]

I deduce from your response that the binary tests committed in systemd were not 
reviewed neither by co-maintainers nor by downstream package maintainers.

I understand that the build system used by systemd makes it much less probable 
that some binary blob used in a test obfuscates something that could be used 
for other purposes outside the test; still, wouldn't you agree it would be a 
good practice to make sure everyone is able to review everything in the source 
code repository?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

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

Having thought this over a bit, I think I should moderate my position
here and make it a bit more nuanced.

It occurs to me - maybe you don't agree, but this is how it looks to me
- that, ironically, you and I usually argue the exact *opposite* side
of this case, no? I argue in *favor* of somewhat-arbitrary delays to
packages appearing in 'stable', and you argue *against* them. :D

So, I don't think I can in full conscience justify being so
categorical. So let me put more emphasis on the "difference between
security and quality" aspect here.

Let's look at the *intent* of the existing policies, here. Practically
speaking, what our policies *achieve* is that for stable releases,
updates-testing acts to *guard Fedora users' systems*. That is its
function there. That's why it is not enabled by default, and we ask
only people who want to contribute to testing to enable it, and
understand that they are "taking a bullet for quality" by doing so. The
idea is that by preventing updates reaching 'ordinary' users' systems
before our testers have at least had an opportunity to try the packages
out, we will catch at least some quality issues and prevent ordinary
users from being affected by them.

The process is specifically designed to achieve this. We have automated
*quality* checks on packages in updates-testing (but almost nothing in
the way of automated *security* checks). We have a whole process geared
towards getting testers to test out the packages and report their
findings - in *quality* terms. This is, to me, a job it's reasonable to
ask a fairly broad range of folks to help with. It works reasonably
well. We have done a reasonable job of implementing a process that lets
a person without really specific training install a test update,
experience a problem in it, and communicate that they encountered that
problem in such a way that we are able to prevent the package reaching
a wider swathe of users. It's not *perfect*, but it does provide some
demonstrable value. Similarly on the automated testing side, both
Fedora CI and openQA provide useful gating of some packages. It is by
no means comprehensive, but it *is* useful. We catch bugs and prevent
them reaching regular users. We don't catch *all* bugs, but we can
reasonably claim to be purposefully and intentionally catching a
reasonable number with this system.

OK, that's for stable releases. What about development releases? It's
key to realize that for development releases, the process looks very
similar, but just that one change - updates-testing defaulting to off -
*changes its entire purpose*, and this is by intent. For development
releases, the purpose of updates-testing is **NOT** to protect
'ordinary users'. It is to protect **the Fedora development process**.

We don't really intend for there to *be* "ordinary users" of Fedora
development releases. We make it fairly clear that, by using a
development release, you are taking yourself out of the "regular user"
category and putting yourself in the "tester / developer" category. We
do not feel such an obligation to provide users of development releases
with quality-tested code. On the contrary, to a degree, they are
supposed to be *helping* with the process of quality testing for the
ultimate goal of making the *final* release good for "ordinary users".
So if you're a user of a development release, we do not really feel an
obligation to provide the same "safety net" for you that updates-
testing provides for "regular users" of stable releases.

Instead, the point of updates-testing in development releases is to let
us prevent breakages in *the process of building the distribution*. We
expect *all* users of development releases to help with this by
flagging up when they see breakage, so we can prevent broken packages
appearing in the buildroot or the compose process. *That* is why we
have updates-testing for development releases.

So...to return to the initial question, ultimately my argument is that
it doesn't make much sense to try and use the existing

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