[Bug 2253383] perl-DBD-Pg-3.18.0 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 CC|dev...@gunduz.org,  |
   |jples...@redhat.com,|
   |ka...@ucw.cz,   |
   |mspa...@redhat.com, |
   |prais...@redhat.com,|
   |rhug...@redhat.com, |
   |rstr...@redhat.com  |
 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=2253383
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d47bce8e4e   
chromium-119.0.6045.199-1.el8


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

java-latest-openjdk-portable-21.0.1.0.12-2.rolling.el8
root-6.30.02-1.el8
wsdd-0.7.1-1.el8

Details about builds:



 java-latest-openjdk-portable-21.0.1.0.12-2.rolling.el8 
(FEDORA-EPEL-2023-8ce17c621c)
 OpenJDK 21 Runtime Environment portable edition

Update Information:

updated to october CPU

ChangeLog:

* Wed Nov 22 2023 Jiri Vanek  - 1:21.0.1.0.12-2.rolling
- updated to OpenJDK 21.0.1 (2023-10-17)
- adjsuted generate_source_tarball
- removed icedtea_sync
- dropped standalone licenses
- added usntripped subpkg
- added docs subpkg
- adjsuted versions of bundled libraries
- build refactored to several solid methods following gnu_andrew
- removed no longer needed jdk8296108-tzdata2022f.patch, 
jdk8296715-cldr2022f.patch, 
rh1648644-java_access_bridge_privileged_security.patch
- added jdk8311630-s390_ffmapi.patch to support virtual threads on s390x
- aligned fips-21u-75ffdc48eda.patch (gnu_andrew)
- fixed '--without release' build-ability by moving docs and misc to if-release 
only
* Wed Sep 20 2023 Jiri Vanek  - 1:21.0.0.0.35-4.rolling
- removed %{1} from miscportablename
* Fri Sep 15 2023 Andrew Hughes  - 
1:21.0.0.0.35-3.rolling
- Update documentation (README.md, add missing JEP to release notes)
- Replace alt-java patch with a binary separate from the JDK
- Drop stale patches that are of little use any more:
- * nss.cfg has been disabled since early PKCS11 work and long superseded by 
FIPS work
- * No accessibility subpackage to warrant RH1648242 patch any more
- * No use of system libjpeg turbo to warrant RH649512 patch any more
- Replace RH1684077 pcsc-lite-libs patch with better JDK-8009550 fix being 
upstreamed
- Update generate_tarball.sh to sync with upstream vanilla script
- Change top_level_dir_name to use the VCS tag, matching new upstream release 
style tarball
- Use upstream release URL for OpenJDK source
- Port misc tarball from RHEL to house alt-java outside the JDK tree
- Port improved tarball creation and checking from RHEL so tarballs are verified
* Thu Sep 14 2023 Andrew Hughes  - 
1:21.0.0.0.35-2.rolling
- Bump buildjdkver now that java-21-openjdk is available in the buildroot
* Tue Aug  8 2023 Petra Alice Mikova  
1:21.0.0.0.35-1.rolling
- updated to jdk-21+35, which is no longer EA
* Tue Aug  8 2023 Petra Alice Mikova  
1:21.0.0.0.34-0.1.ea.rolling
- initial update to jdk21
- commented out fips patches
- updated to jdk21 ea
- updated patch 1001 - 
rh1648249-add_commented_out_nss_cfg_provider_to_java_security
- replace smoketests in staticlibs test, as the previous files used were 
removed by a patch in JDK
- require tzdata 2023c
- Update FIPS support to bring in latest changes
- * RH2048582: Support PKCS#12 keystores
- * RH2020290: Support TLS 1.3 in FIPS mode
- * Add nss.fips.cfg support to OpenJDK tree
- * RH2117972: Extend the support for NSS DBs (PKCS11) in FIPS mode
- * Remove forgotten dead code from RH2020290 and RH2104724
- * OJ1357: Fix issue on FIPS with a SecurityManager in place
- * RH2134669: Add missing attributes when registering services in FIPS mode.
- * test/jdk/sun/security/pkcs11/fips/VerifyMissingAttributes.java: fixed jtreg 
main class
- * RH1940064: Enable XML Signature provider in FIPS mode
- * Remove GCC minor versioning (JDK-8284772) to unbreak testing
- Drop local nss.fips.cfg.in handling now this is handled in the patched 
OpenJDK build




 root-6.30.02-1.el8 (FEDORA-EPEL-2023-5cf6b377b2)
 Numerical data analysis framework

Update Information:

ROOT 6.30.02

ChangeLog:

* Sat Dec  2 2023 Mattias Ellert  - 6.30.02-1
- Update to 6.30.02




 wsdd-0.7.1-1.el8 (FEDORA-EPEL-2023-e43ee1ef96)
 Web Services Dynamic Discovery host daemon

Update Information:

Latest upstream release. Includes https://src.fedoraproject.org/rpms/wsdd/pull-
request/1 .

ChangeLog:

* Fri Oct  6 2023 Ondrej Holy  - 0.7.1-1
- Update to 0.7.1.
* Sat Jul 22 2023 

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-46696cc30b   
chromium-119.0.6045.199-1.el7


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

wsdd-0.7.1-1.el7

Details about builds:



 wsdd-0.7.1-1.el7 (FEDORA-EPEL-2023-4e7c9d636e)
 Web Services Dynamic Discovery host daemon

Update Information:

Latest upstream release. Includes https://src.fedoraproject.org/rpms/wsdd/pull-
request/1 .

ChangeLog:

* Fri Oct  6 2023 Ondrej Holy  - 0.7.1-1
- Update to 0.7.1.
* Sat Jul 22 2023 Fedora Release Engineering  - 
0.7.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Sat Jan 21 2023 Fedora Release Engineering  - 
0.7.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Sat Jul 23 2022 Fedora Release Engineering  - 
0.7.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Sat Jan 22 2022 Fedora Release Engineering  - 
0.7.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild


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

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

[updates]

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-2537ccf8b5   
chromium-119.0.6045.199-1.el9
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-3d9a822df5   
rust-pore-0.1.8-5.el9


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

bluechi-0.6.0-1.el9
java-latest-openjdk-portable-21.0.1.0.12-2.rolling.el9
nickle-2.96-1.el9
python-google-auth-2.25.1-1.el9
root-6.30.02-1.el9
snakeyaml-1.33-1.el9
wsdd-0.7.1-1.el9

Details about builds:



 bluechi-0.6.0-1.el9 (FEDORA-EPEL-2023-73c4c9c7aa)
 A systemd service controller for multi-nodes environments

Update Information:

Version 0.6.0 includes the following changes and updates:  - Renamed bluechi to
bluechi-controller for binary, rpm and documentation  - Moved bluechi binaries
to /usr/libexec for auto-completion  - Added properties and signals for
connection status and disconnected timestamp to Agent's public API  - Removed
duplicate NodeConnectionStateChanged signal from bluechi-controller  - CLI
option for the version (-v) prints version and git commit hash for non-release
builds  - Extended BlueChi's public D-Bus API specification by inline-comments
- Added EmitsChangedSignal annotation to properties in BlueChi's public D-Bus
API specification  - Enhanced typed python bindings generator to use inline-
comments from specification  - Enhanced typed python bindings generator to
provide listener functions for property changed signals  - Fixes in the D-Bus
API description  - Improved error messages returned by D-Bus API  - Added static
code analysis from gcc and fixed detected issues  - Added a graceful node
shutdown in bluechi-controller  - Fixed a few smaller memory leaks  - Fixed bug
where configured manager address was overridden on connection failure  - Fixed
bug where removing a subscription was not prevented  - Fixed race condition
leading bluechi-proxy and bluechi-dep service to transition into failed state  -
Aligned and added API examples for Python, Go and Rust  - Changed the license
for python bindings to MIT-0

ChangeLog:

* Wed Nov 29 2023 Michael Engel  - 0.6.0-1
- Update to 0.6.0
- Rename bluechi package to controller




 java-latest-openjdk-portable-21.0.1.0.12-2.rolling.el9 
(FEDORA-EPEL-2023-a52c6ecf48)
 OpenJDK 21 Runtime Environment portable edition

Update Information:

updated to october CPU

ChangeLog:

* Wed Nov 22 2023 Jiri Vanek  - 1:21.0.1.0.12-2.rolling
- updated to OpenJDK 21.0.1 (2023-10-17)
- adjsuted generate_source_tarball
- removed icedtea_sync
- dropped standalone licenses
- added usntripped subpkg
- added docs subpkg
- adjsuted versions of bundled libraries
- build refactored to several solid methods following gnu_andrew
- removed no longer needed jdk8296108-tzdata2022f.patch, 
jdk8296715-cldr2022f.patch, 
rh1648644-java_access_bridge_privileged_security.patch
- added jdk8311630-s390_ffmapi.patch to support virtual threads on s390x
- aligned fips-21u-75ffdc48eda.patch (gnu_andrew)
- fixed '--without release' build-ability by moving docs and misc to if-release 
only
* Wed Sep 20 2023 Jiri Vanek  - 1:21.0.0.0.35-4.rolling
- removed %{1} from miscportablename
* Fri Sep 15 2023 Andrew Hughes  - 
1:21.0.0.0.35-3.rolling
- Update documentation (README.md, add missing JEP to release notes)
- Replace alt-java patch with a binary separate from the JDK
- Drop stale patches that are of little use any more:
- * nss.cfg has been disabled since early PKCS11 work and long superseded by 
FIPS work
- * No accessibility subpackage to warrant RH1648242 patch any more
- * No use of system libjpeg turbo to warrant RH649512 patch any more
- Replace RH1684077 pcsc-lite-libs patch with better JDK-8009550 fix being 
upstreamed
- Update generate_tarball.sh to sync with upstream vanilla script
- Change top_level_dir_name to use the VCS tag, matching new upstream release 
style tarball
- Use upstream release URL for OpenJDK source
- Port misc tarball from RHEL to house alt-java outside the JDK tree
- Port improved tarball creation and checking from RHEL so tarballs are verified
* Thu Sep 14 2023 Andrew Hughes  - 
1:21.0.0.0.35-2.rolling
- Bump buildjdkver now that java-21-openjdk is available in the buildroot
* Tue Aug  8 2023 Petra Alice Mikova  
1:21.0.0.0.35-1.rolling
- updated to jdk-21+35, which is no longer EA
* Tue Aug  8 2023 Petra Alice Mikova  

[Bug 2253383] New: perl-DBD-Pg-3.18.0 is available

[bugzilla]

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

Bug ID: 2253383
   Summary: perl-DBD-Pg-3.18.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBD-Pg
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dev...@gunduz.org, jples...@redhat.com, ka...@ucw.cz,
mspa...@redhat.com,
perl-devel@lists.fedoraproject.org,
prais...@redhat.com, rhug...@redhat.com,
rstr...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 3.18.0
Upstream release that is considered latest: 3.18.0
Current version/release in rawhide: 3.17.0-2.fc40
URL: https://metacpan.org/dist/DBD-Pg/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2809/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-DBD-Pg


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253383%23c0
--
___
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: Review swaps for deps needed for conda update

[Orion Poplawski]

On 12/2/23 19:32, Orion Poplawski wrote:
I have a number of packages needing review that are required for the 
latest round of updates to the conda package manager:


https://bugzilla.redhat.com/buglist.cgi?bug_id=2025802_id_type=anddependson=tvp_id=13378412#

I'm particularly excited by libmamba and its micromamba 
package/executable as a faster/leaner replacement for conda itself.


Just for the record - Jerry James picked up the reviews.  Big shout out 
for that!


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



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: Update on the Modern C initiative

[Kevin Kofler via devel]

Florian Weimer wrote:
> Although the critical type size mismatch happens on 32-bit architectures
> and Windows only.  Problems like these are the reason why I don't think
> the Clang approach of restricting to incompatible-function-pointer-types
> only makes much sense.

Uhm, yeah, there are certainly cases where the complaint about mismatched 
pointer types is valid. But last I checked, the warning that is now being 
turned into an error also complained about "mismatches" where the types are 
actually exactly the same on the given architecture, such as int vs. long on 
32-bit (or 64-bit Windows), or long vs. long long on 64-bit LP64. And those 
"mismatches" can easily happen without being an actual issue, because, e.g., 
the program uses its own definition equivalent to something like size_t or 
ptrint_t (especially the latter, since it is non-C90 and hence considered 
non-standard by the large pool of software still targeting C90 only, but I 
have also seen a lot of custom size_t/ssize_t reinventions) and passes a 
pointer to that where a size_t * or ptrint_t * or such is expected. 

E.g., I have seen Java bindings doing something like:
jlong foo;
#if SIZEOF_SIZE_T == 8
  function_that_expects_an_ssize_t_pointer();
#else
  ssize_t temp = (ssize_t) foo;
  function_that_expects_an_ssize_t_pointer();
  foo = (jlong) temp;
#endif

Of course, the compiler has no way to know whether the code is doing 
something like this or just incorrectly assuming that 
sizeof(ssize_t)==sizeof(jlong) (i.e., 8) everywhere.

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

SoPlex and SCIP review swaps

[Jerry James]

Kevin Kofler noted about a year ago [1] that new versions of the solvers
SoPlex [2] and SCIP [3] were released under free software licenses.  Over the
last year, I've been working little by little on building them in a COPR [4]
and rebuilding various Fedora packages with SoPlex and SCIP support.  I
believe we have reached the point where we can start integrating this work
into Fedora.

References:
[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GGGRTBI3ZQYXMNLTPAYCW5IT4FYNY6GX/
[2] https://soplex.zib.de/
[3] https://scipopt.org/
[4] https://copr.fedorainfracloud.org/coprs/jjames/SCIP/

I need reviews for the following new packages.  I am willing to swap reviews.
- asl: https://bugzilla.redhat.com/show_bug.cgi?id=2253354
- ccluster: https://bugzilla.redhat.com/show_bug.cgi?id=2253355
- lusol: https://bugzilla.redhat.com/show_bug.cgi?id=2253356
- pdqsort: https://bugzilla.redhat.com/show_bug.cgi?id=2253357
- zimpl: https://bugzilla.redhat.com/show_bug.cgi?id=2253358
- zstr: https://bugzilla.redhat.com/show_bug.cgi?id=2253359
- papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360
- soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361
- scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362
- coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363
- spasm: https://bugzilla.redhat.com/show_bug.cgi?id=2253364

I will shortly open pull requests for each of the following packages.  I wanted
to post this message first so that the PR text can include a reference to it.
- bliss
- coin-or-Alps
- coin-or-Bcp
- coin-or-Bcps
- coin-or-Blis
- coin-or-Bonmin
- coin-or-Cbc
- coin-or-Cgl
- coin-or-Clp
- coin-or-CoinMP
- coin-or-CoinUtils
- coin-or-Couenne
- coin-or-Dip
- coin-or-DyLP
- coin-or-FlopC++
- coin-or-lemon
- coin-or-Ipopt
- coin-or-OS
- coin-or-Osi
- coin-or-SYMPHONY
- freefem++
- gfan
- latte-integrale
- Macaulay2
- mp
- opencv
- openms
- polymake
- python-cyipopt
- python-pysingular
- qsopt-ex
- seqan
- seqan2
- seqan3
- Singular
- sympol
- TOPCOM

ASL vs. mp
--
Many of the coin-or packages currently BuildRequires mp-devel.  They really
only need the ASL part of mp.  Upstream has split the two projects into
separate git repositories; see the new asl package listed above.  This will
reduce the number of runtime dependencies for the coin-or packages.

Since the new asl package conflicts with the current mp package, the
introduction of asl, modification of mp, and rebuilding of affected coin-or
packages all need to be done at once.  Once all of the reviews are complete,
they will be built in a side tag.

i386 removal

Some of the new packages need some work to build correctly on i386.  Why
bother?  Let's not build for i386 in the first place.  That means, however,
that some of the packages that sit on top of them will need to be modified to
stop building for i386 as well.  That is the extent of the modifications to
some of these packages (e.g., freefem++).

Since opencv and openms are both still built for i386, the packages that they
depend on (including the new asl package) must also be built for i386 for now.
-- 
Jerry James
http://www.jamezone.org/
--
___
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

[EPEL-devel] Re: Proposed incompatible security update (again) for llhttp in EPEL9

[Troy Dawson]

On Tue, Nov 28, 2023 at 8:37 AM Ben Beasley  wrote:

> This email proposes upgrading the llhttp package in EPEL9 from 8.1.1 to
> 9.1.3, which would break the ABI and bump the SONAME version, under the
> EPEL Incompatible Upgrades Policy[1].
>
> The llhttp package is a C library (transpiled from TypeScript) that
> provides the low-level HTTP support for NodeJS and for python-aiohttp.
> Currently, only python-aiohttp depends on the llhttp package in EPEL9.
>
> Versions of python-aiohttp prior to 3.8.6[2] are affected by
> CVE-2023-47627[3][4], an HTTP request/response smuggling vulnerability
> rated 5.3 in CVSS v3 and rated Moderate by Red Hat. This was reported as
> RHBZ#2249825[5]. Since the flaw is only in the pure-Python parser, and
> we compile the llhttp-based parser, this affects only code using the
> AIOHTTP_NO_EXTENSIONS environment variable. Updating aiohttp from 3.8.5
> to 3.8.6 to fix that still requires updating llhttp from 8.x to 9.x.
> Additionally, according to the release notes this includes an
> llhttp-related security fix[6] with no assigned CVE, which provides
> added motivation to update.
>
> The ABI break in llhttp would only affect python-aiohttp. The
> python-aiohttp update itself is compatible (by upstream intent, and as
> already demonstrated in Rawhide and F39/F38); and a large list of
> packages that depend on python-aiohttp would benefit from the fix. The
> necessary rebuild would be conducted in a side tag.
>
> The same incompatible update was approved by FESCo for Fedora 38 and
> 39[7]. Furthermore, it appears that FESCo will approve a permanent
> exception for llhttp[8].
>
> The purpose of this email is to document and explain the proposed
> update, to begin the minimum one-week discussion period mandated by the
> EPEL Incompatible Upgrades Policy, and to request that the update be
> added to the agenda for an upcoming EPEL meeting.
>
> [1]
>
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
>
> [2] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6
>
> [3] https://access.redhat.com/security/cve/CVE-2023-47627
>
> [4]
> https://github.com/aio-libs/aiohttp/security/advisories/GHSA-gfw2-4jvh-wgfg
>
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=2249825
>
> [6] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6
>
> [7] https://pagure.io/fesco/issue/3106
>
> [8] https://pagure.io/fesco/issue/3115
>
>
This exception, as well as a permanent exception, was approved this week in
the EPEL Steering Committee meeting.

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

Re: Synching user database from Fedora IPA to pagure

[Pierre-Yves Chibon]

On Tue, Nov 28, 2023 at 10:13:35AM +, Mattia Verga via devel wrote:
> I'd like to start writing a script to synch users/groups from Fedora IPA 
> to pagure.io and src.fp.o: both pagure.io and src.fp.o logins are based 
> on Fedora accounts, but the Pagure user database is only updated when a 
> user login in Pagure.

I know this thread has been closed for a while and I'm pretty sure that info has
been passed onto the other place where this discussion evolved, but for the
posterity I'm adding it here as well:

pagure.io does not rely on groups from FAS, only src.fp.o does.
Groups in pagure.io are entirely managed within pagure.io, just the user account
are coming from FAS.
src.fp.p on the other hand is the opposite, all the groups are managed from FAS*
and membership is indeed synced upon login.

So now that it's here for the posterity, we can go back to what we were doing :)

Thanks,
Pierre




*well, an admin needs to create it on src.fp.o with the same name and then it'll
be added to the list of groups pagure asks upon login.
So if you want sig-foo, you create sig-foo in FAS and add its users there, then
you create sig-foo in src.fp.o and membership will sync over 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

Fedora CoreOS Meeting Minutes 2023-12-06

[Dusty Mabe]

Text Log: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2023-12-06/fedora-coreos-meeting.2023-12-06-16.31.log.txt
HTML Log: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2023-12-06/fedora-coreos-meeting.2023-12-06-16.31.log.html
Text Minutes: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2023-12-06/fedora-coreos-meeting.2023-12-06-16.31.txt
HTML Minutes: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2023-12-06/fedora-coreos-meeting.2023-12-06-16.31.html


=
# #meeting-1:fedoraproject.org: fedora_coreos_meeting
=

Meeting started by @dustymabe:matrix.org at 2023-12-06 16:31:49



Meeting summary
---
* TOPIC: roll call (@dustymabe:matrix.org, 16:31:59)
* TOPIC: Action items from last meeting (@dustymabe:matrix.org, 16:39:15)
* INFO: there were no action items from last meeting 
(@dustymabe:matrix.org, 16:39:30)
* TOPIC: fwupdmgr - UEFI ESP partition not detected or configured 
(@dustymabe:matrix.org, 16:40:41)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1623 
(@dustymabe:matrix.org, 16:40:53)
* INFO: this one needs more investigation and we're looking for a volunteer 
to dig in (@dustymabe:matrix.org, 16:50:08)
* TOPIC: iPXE Booting Raspberry Pi CM4s results in incorrect time and inablitiy 
to access ignition via HTTPS (@dustymabe:matrix.org, 16:52:00)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1624 
(@dustymabe:matrix.org, 16:52:08)
* AGREED: We don't think this issue is a high priority because there aren't 
many systems that we target that don't have an RTC. As mentioned there are 
systems with an RTC that is wrong, but in that case it's easy to remedy by 
setting the RTC to a correct value. We could improve by giving users an 
`ignition.config.checksum` option to go along with `ignition.config.url`, but 
it's still a workaround and probably not worth the effort. 
(@dustymabe:matrix.org, 17:10:26)
* TOPIC: FOSDEM 2024 (Brussels / 3 & 4 February 2024) (@dustymabe:matrix.org, 
17:10:58)
* TOPIC: FOSDEM 2024 (Brussels / 3 & 4 February 2024) (@dustymabe:matrix.org, 
17:11:11)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1621 
(@dustymabe:matrix.org, 17:11:27)
* TOPIC: Open Floor (@dustymabe:matrix.org, 17:13:36)
* INFO: Fedora 40 changes are starting to flow in - we'll start reviewing 
them soon! https://github.com/coreos/fedora-coreos-tracker/issues/1626 
(@dustymabe:matrix.org, 17:14:14)

Meeting ended at 2023-12-06 17:17:45

Action items


People Present (lines said)
---
* @dustymabe:matrix.org (70)
* @jlebon:fedora.im (17)
* @zodbot:fedora.im (5)
* @fifofonix:matrix.org (3)
* @meetbot:fedora.im (2)
* @marmijo:fedora.im (2)
* @jmarrero:matrix.org (2)
--
___
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: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

[Luca Boccassi]

> Gerd Hoffmann  this AFAIU means that we also need shim in the boot chain if we want to
> support these addons.

Only if you want to use certs in MOK to verify them, otherwise it's not 
necessary. The protocol is just LoadImage which every firmware also provides 
and checks against DB.
--
___
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: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

[Vitaly Kuznetsov]

Gerd Hoffmann  writes:

>   Hi,
>
>> Does that mean that the Linux EFI boot code knows how to call back to
>> shim to get the certificates instead of reading the firmware directly?
>
> No.  The linux efi stub doesn't need that.
>
> shim.efi does:
>
>   (a) Set efi variables, where the linux kernel can read the
>   certificates from.  This works the same way for both traditional
>   kernels and UKIs.
>
>   (b) provide an efi protocol for bootloaders, which can be called by grub
>   and systemd-boot to verify the signature for binaries they load
>   (typically the linux kernel, but could also be fwupd.efi).

Note, the protocol is also used by systemd-stub (the base for UKIs) to
verify cmdline addons, see

commit 05c9f9c2517c54b98d55f08f8afa67c79be861e8
Author: Luca Boccassi 
Date:   Fri May 12 00:55:58 2023 +0100

stub: allow loading and verifying cmdline addons

this AFAIU means that we also need shim in the boot chain if we want to
support these addons.

-- 
Vitaly
--
___
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: Obsoleting zlib in Fedora Rawhide

[Daniel Alley]

> Except that it's not 100% compatible, since all those packages aren't
> building/working with zlib-ng-compat.  At a minimum, you should be able
> to show that everything zlib-dependent successfully rebuilds with this,
> and since you've already identified some that don't, IMO they should be
> fixed *first*.

He didn't say the packages weren't working, he said the tests failed, typically 
because they hardcoded assumptions about the exact behavior of the compression 
library.  That's a different issue.

As a concrete example, a while back I wanted to add zlib-ng as a build time 
option to the createrepo_c package, and one such test failed because the 
zlib-ng gzip output was not identical to zlib gzip output, despite the fact 
that it *was* correct and decompresses correctly: 
https://github.com/rpm-software-management/createrepo_c/pull/339/commits/1f3549bfe6ea45e6fd099c0582893766061198c8

It so happened that within days there was another reporter who needed the same 
fix but for different reasons - because that test was broken on z390 where gzip 
compression is hardware-accelerated: 
https://github.com/rpm-software-management/createrepo_c/pull/336

So any tests that are breaking because they expected some exact gzipped output 
as opposed, were likely fragile anyway, and worked only because zlib has 
changed very little for a very long time - no new compression strategies, no 
adjustment of which strategies are used by which levels, etc.


--
___
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: Copr builds are stuck at package signing

[Miroslav Suchý]

Dne 06. 12. 23 v 12:52 František Šumšal napsal(a):

Hey,

Thanks to Packit I noticed that a lot of our jobs are running longer than usual, and a quick glance at the Copr task 
queue[0] tells me there's something fishy going on. I opened a couple of jobs[1][2][3] and all of

...
Looks like the last 20s sleep takes _way_ longer than 20s. Is this a known issue? 


Yes. Pavel, Jakub and Jirka was working on this most of today's date.

The culprit was that gpg key was not created for a project. We found that 'gpg2 --list-secret-keys` took 35 seconds to 
finish, but the client had a timeout 24 seconds. We solved it temporarily by spawning a beefier VM for sign server. Now 
gpg2 returns in 4 secs. It gives us time to look at how to solve it properly. In the meantime, your builds should build 
without a problem and the current queue is slowly processing.



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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2023-12-06.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

appmenu-qtorphan, rdieter  2 weeks ago
arora orphan   2 weeks ago
aspell-ar orphan   2 weeks ago
aspell-he orphan   2 weeks ago
bash-completion-extrasorphan   2 weeks ago
bettercap eclipseo, go-sig, orphan 2 weeks ago
bidiv orphan   2 weeks ago
byzanzorphan   2 weeks ago
cagibiorphan, rdieter, than2 weeks ago
clash go-sig, orphan   1 weeks ago
coin-or-lemon orphan, sagitter 2 weeks ago
cpptoml   orphan   2 weeks ago
cutterorphan   2 weeks ago
dictd mcepl, orphan2 weeks ago
dovecot-fts-xapianorphan   2 weeks ago
echo-artist   orphan   2 weeks ago
elementary-onboarding orphan   2 weeks ago
emacs-evilorphan   2 weeks ago
emacs-goto-chgorphan   2 weeks ago
emacs-undo-tree   orphan   2 weeks ago
fbf-mukti-fonts   orphan   2 weeks ago
fontopia  orphan   2 weeks ago
fwknopcrypto-team, jjelen, orphan  2 weeks ago
gball orphan   2 weeks ago
ghc-crypto-cipher-types   orphan   2 weeks ago
gnome-bluetooth3.34   orphan   0 weeks ago
gnome-video-arcadeorphan   2 weeks ago
gnudosorphan   2 weeks ago
golang-vbom-util  go-sig, orphan   2 weeks ago
golang-xorm   agerstmayr, go-sig, nathans, 2 weeks ago
  orphan
gosnake   orphan   2 weeks ago
groonga-normalizer-mysql  orphan   2 weeks ago
heat-cfntools orphan, zaneb2 weeks ago
heisenbug-backgrounds orphan   2 weeks ago
herqq orphan   2 weeks ago
ibus-bogo orphan   2 weeks ago
ibutils   dledford, honli, michich,2 weeks ago
  orphan
icaro orphan   2 weeks ago
kde-plasma-ihatethecashew orphan   2 weeks ago
kflickr   orphan   2 weeks ago
ktp-accounts-kcm  jgrulich, kde-sig, orphan,   2 weeks ago
  rdieter
ktp-approver  jgrulich, kde-sig, orphan,   2 weeks ago
  rdieter
ktp-auth-handler  jgrulich, kde-sig, orphan,   2 weeks ago
  rdieter
ktp-common-internals  jgrulich, kde-sig, orphan,   2 weeks ago
  rdieter
ktp-contact-list  jgrulich, kde-sig, orphan,   2 weeks 

[rpms/perl] PR #9: Add reverse test for perl-Devel-Cover

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl` that you are 
following:
``
Add reverse test for perl-Devel-Cover
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/9
--
___
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

[rpms/perl] PR #8: Add reverse test for perl-Devel-Cover

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: `perl` that 
you
are following.

Closed pull-request:

``
Add reverse test for perl-Devel-Cover
``

https://src.fedoraproject.org/rpms/perl/pull-request/8
--
___
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: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

[Gerd Hoffmann]

  Hi,

> Does that mean that the Linux EFI boot code knows how to call back to
> shim to get the certificates instead of reading the firmware directly?

No.  The linux efi stub doesn't need that.

shim.efi does:

  (a) Set efi variables, where the linux kernel can read the
  certificates from.  This works the same way for both traditional
  kernels and UKIs.

  (b) provide an efi protocol for bootloaders, which can be called by grub
  and systemd-boot to verify the signature for binaries they load
  (typically the linux kernel, but could also be fwupd.efi).

take care,
  Gerd
--
___
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

[rpms/perl] PR #8: Add reverse test for perl-Devel-Cover

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl` that you are 
following:
``
Add reverse test for perl-Devel-Cover
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/8
--
___
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

[rpms/perl] PR #7: Add reverse test for perl-Devel-Cover

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: `perl` that 
you
are following.

Closed pull-request:

``
Add reverse test for perl-Devel-Cover
``

https://src.fedoraproject.org/rpms/perl/pull-request/7
--
___
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: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé 
wrote:

> On Wed, Dec 06, 2023 at 11:16:44AM +0100, Ondrej Pohorelsky wrote:
> > Hi everyone,
> >
> > For F40 I would like to change file permissions of few files that are
> > provided by cronie and crontabs and swap deny list for allow list. I'm
> not
> > really sure if I should make a change proposal. I figured I'll send an
> > email first and see the feedback.
> >
> > The driving force of this change is feedback from RHEL customers, that
> they
> > would like to have cronie and crontabs CIS compliant out of the box.
> Which
> > means changing some of the file permissions and swapping `cron.deny` for
> > `cron.allow`. As it stands now, they have to run their own scripts or dnf
> > plugin (post-transaction-actions) to ensure that each update doesn't
> > overwrite the file permissions they manually set.
>
> This CIS compliance problem is not something that is limited to cron. Their
> list of hardening steps covers a wide variety of software. IOW, even if
> cron
> were changed, presuambly such customers will need need their own scripts /
> dnf plugin to fix all the other apps listed in the CIS compliance guide.
>
> IOW, I feel like the real question here is whether the distro *as a whole*,
> not cron, wants/needs to be CIS compliant out of the box, or whether it
> should be explicitly an admin deployment task to enable compliance via a
> plugin / script.
>
>
I'm doing this only in the scope of cronie and crontabs. Basically reacting
on a few customers tickets that would welcome this change,
which I wouldn't like to introduce downstream.

On a distro level, this really doesn't make sense. Especially for Fedora.
For RHEL? Maybe, I don't know. I'm definitely not the right person
to answer this question.

> `cron.d` permission change (755 → 700)
> > `cron.hourly` permission change (755 → 700)
> >
> > *crontabs* changes:
> > `crontab` permission change (644 → 600)
> > `cron.{hourly,daily,weekly,monthly}` permission change (755 → 700)
>
> The main effect of the permissions change on these files is that non-root
> users can't see any env variables set against the commands scheduled to
> run.
> The actual command lines are still all visible in the proces listing when
> the command runs.
>
>

Which I think shouldn't be a problem if we don't use cron.allow default, as
I wrote in my previous mail.

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

--
___
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: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 1:02 PM Daniel P. Berrangé 
wrote:

> On Wed, Dec 06, 2023 at 11:53:26AM +, Tom Hughes via devel wrote:
> > On 06/12/2023 11:08, Ondrej Pohorelsky wrote:
> >
> > > The only difference is that if you have populated the cron.deny list,
> > > after update it gets saved as .rpmsave and cron.allow is created.
> > > If the cron.deny is blank, it will get replaced.
> > > Also, if you had cron.allow populated before, it will stay this way and
> > > blank cron.allow.rpmnew is created.
> >
> > Surely there is one more change though?
> >
> > Namely that users who could previously run crontab to create
> > cron jobs can no longer do so unless they have been added to
> > the cron.allow file.
> >
> > That seems like a breaking change to me?
>
> Yes, making cron unusable out of the box for non-root users feels like
> an pretty major regression in behaviour.
>


Yes, you are right. Thank you for noticing this. I've focused on the file
permissions and completely overlooked this.

I think we can leave cron.deny approach as the Fedora default and change
the file permissions to be CIS compliant.
As, the real pain point that customers stated isn't the creation of
cron.allow, but file permissions that change after each update.
IMO, this can be a good middle ground.

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

--
___
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: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

[Neal Gompa]

On Wed, Dec 6, 2023 at 5:15 AM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > What is the point of using shim in this path? We're not having UKIs
> > signed by Microsoft, and unless the Linux kernel knows how to call
> > shim for certificates, I don't see how this is supposed to be useful
> > for the Microsoft->Fedora->OS boot chain.
>
> Booting without shim.efi would work only if you enroll the fedora secure
> boot CA in your firmware's security database.  That is not the default,
> and not all virtualization environments offer the option to do that.
>
> So, on a typical setup with the microsoft keys enrolled the firmware
> wouldn't load the UKI, exactly because it is not signed by microsoft.
> shim.efi is needed for everything signed with the fedora keys, be it
> grub.efi, fwupd.efi, traditional kernels or UKIs.
>
> Also note that fallback.efi (comes with shim and runs in case there is
> no UEFI boot configuration) will create only uefi boot entries including
> shim in the boot path, so there is no easy way to exclude shim.
>
> Ideally we would have shim.efi signed with both microsoft and fedora
> keys.  In that case the firmware -> shim.efi -> fedora-signed.efi boot
> path would work in both cases (fedora keys / microsoft keys enrolled).
>

Does that mean that the Linux EFI boot code knows how to call back to
shim to get the certificates instead of reading the firmware directly?
Because without that, shim is kind of pointless. Shim returns the
certificates from firmware plus the embedded distribution one
(Fedora's in this case) when it's asked for them.




--
真実はいつも一つ！/ 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: Obsoleting zlib in Fedora Rawhide

[Tulio Magno Quites Machado Filho]

Yaakov Selkowitz  writes:

> Except that it's not 100% compatible, since all those packages aren't
> building/working with zlib-ng-compat.  At a minimum, you should be able
> to show that everything zlib-dependent successfully rebuilds with this,

I'm afraid I was not clear enough.
Packages built with zlib continue to work after replacing zlib with
zlib-ng-compat.

However, a small list of packages have tests that were written without
considering that one day we would have many different implementations of
zlib.
These tests need to be modified. In some cases, I believe they should be
disabled as they aim to test the zlib implementation instead of testing
their own code.

With that said, I haven't identified a compatibility issue with zlib-ng
yet. If you have, please let me know.

-- 
Tulio Magno
--
___
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: Change of cronie and crontabs CIS compliance

[Nikos Mavrogiannopoulos]

On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé  wrote:
>
> On Wed, Dec 06, 2023 at 11:16:44AM +0100, Ondrej Pohorelsky wrote:
> > Hi everyone,
> >
> > For F40 I would like to change file permissions of few files that are
> > provided by cronie and crontabs and swap deny list for allow list. I'm not
> > really sure if I should make a change proposal. I figured I'll send an
> > email first and see the feedback.
> >
> > The driving force of this change is feedback from RHEL customers, that they
> > would like to have cronie and crontabs CIS compliant out of the box. Which
> > means changing some of the file permissions and swapping `cron.deny` for
> > `cron.allow`. As it stands now, they have to run their own scripts or dnf
> > plugin (post-transaction-actions) to ensure that each update doesn't
> > overwrite the file permissions they manually set.
>
> This CIS compliance problem is not something that is limited to cron. Their
> list of hardening steps covers a wide variety of software. IOW, even if cron
> were changed, presuambly such customers will need need their own scripts /
> dnf plugin to fix all the other apps listed in the CIS compliance guide.
>
> IOW, I feel like the real question here is whether the distro *as a whole*,
> not cron, wants/needs to be CIS compliant out of the box, or whether it
> should be explicitly an admin deployment task to enable compliance via a
> plugin / script.
>
> I understand some organizations have no choice in whether or not they
> comply with the CIS guidance - its mandated for many. At the same time
> though some of the recommendations, including those for cron, are verging
> on snakeoil / extreme paranoia, and as such are dubious to impose on
> every users of the distro by default.

I think you set the right question there. With the cybersecurity
regulatory trend on EU and US, almost all organizations need to comply
with a secure configuration / hardening scheme like CIS. The main
reason is that if you want to follow any respectable security path
that puts the org on the due care set, you need to ensure that your
systems are configured securely, meaning no more options than the
necessary are enabled on the system. The CIS benchmarks provide that.

Now applying the benchmark can be pretty complex as some of the rules
CIS prohibits are required by some organizations because they run
(e.g.) on the cloud that requires it, but others on a different
environment do not. The question you set is, to the point and useful.
Even if the default installation doesn't follow CIS closely, but
provides a better balance of usability and security based on the CIS
guidelines, it will add value to Fedora derivatives -both by reducing
the default attack surface and by making the more advanced hardening
easier-.

Regards,
Nikos
--
___
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

Next Wednesday: Opening up the Python Maint Fedora Bugs Triage

[Miro Hrončok]

Hello Pythonistas.

Every other Wednesday at 14:00 Europe/Prague the Red Hat Python Maint team has 
a meeting at https://meet.google.com/xuj-jswy-hat


The next meeting is in a week.

We go trough the open Fedora Bugzillas, PRs etc. assigned to our members.

https://fedoraproject.org/wiki/User:Python-maint

We've been doing this for a while and recently we decided to open this meeting 
for other Python SIG members and interested parties.


I've added the meeting to Fedora calendar:

https://calendar.fedoraproject.org/SIGs/2023/12/11/#m10669

You are welcome to join us next week. I'll send a reminder.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

On Wed, Dec 06, 2023 at 11:16:44AM +0100, Ondrej Pohorelsky wrote:
> Hi everyone,
> 
> For F40 I would like to change file permissions of few files that are
> provided by cronie and crontabs and swap deny list for allow list. I'm not
> really sure if I should make a change proposal. I figured I'll send an
> email first and see the feedback.
> 
> The driving force of this change is feedback from RHEL customers, that they
> would like to have cronie and crontabs CIS compliant out of the box. Which
> means changing some of the file permissions and swapping `cron.deny` for
> `cron.allow`. As it stands now, they have to run their own scripts or dnf
> plugin (post-transaction-actions) to ensure that each update doesn't
> overwrite the file permissions they manually set.

This CIS compliance problem is not something that is limited to cron. Their
list of hardening steps covers a wide variety of software. IOW, even if cron
were changed, presuambly such customers will need need their own scripts /
dnf plugin to fix all the other apps listed in the CIS compliance guide.

IOW, I feel like the real question here is whether the distro *as a whole*,
not cron, wants/needs to be CIS compliant out of the box, or whether it
should be explicitly an admin deployment task to enable compliance via a
plugin / script.

I understand some organizations have no choice in whether or not they
comply with the CIS guidance - its mandated for many. At the same time
though some of the recommendations, including those for cron, are verging
on snakeoil / extreme paranoia, and as such are dubious to impose on
every users of the distro by default.

> I would like these changes for F40, as this is going to be a branching
> point for next RHEL and I would like to go with upstream first approach.
> 
> *cronie* changes:
> `cron.allow` replaces `cron.deny`  (file permission 600)

I don't see a functional need to create cron.allow by default
to avoid "dnf update" problems.

An admin who wants to deny non-root access to crontab can create
this cron.allow file, even if cron.deny already exists & continues
to exist, and cron.allow will take priority over cron.deny. There's
no need to actally delete cron.deny, if I'm reading the docs right:

[quote 'man crontab']
   Scheduling  cron jobs with crontab can be allowed or disal‐
   lowed for different  users.   For  this  purpose,  use  the
   cron.allow and cron.deny files.  If the cron.allow file ex‐
   ists,  a  user  must  be  listed in it to be allowed to use
   crontab.  If the cron.allow file does  not  exist  but  the
   cron.deny  file  does exist, then a user must not be listed
   in the cron.deny file in order to use crontab.  If  neither
   of  these  files exist, then only the super user is allowed
   to use crontab.
[/quote]

IMHO, the CIS mandate to delete cron.deny looks dubious, and the
stated "dnf update" problem does not exist, and so does not justify
the behaviour regression for Fedora users of switching to a 'deny all'
policy by default.

> `cron.d` permission change (755 → 700)
> `cron.hourly` permission change (755 → 700)
> 
> *crontabs* changes:
> `crontab` permission change (644 → 600)
> `cron.{hourly,daily,weekly,monthly}` permission change (755 → 700)

The main effect of the permissions change on these files is that non-root
users can't see any env variables set against the commands scheduled to run.
The actual command lines are still all visible in the proces listing when
the command runs.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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: Change of cronie and crontabs CIS compliance

[Stephen Smoogen]

On Wed, 6 Dec 2023 at 06:49, Ondrej Pohorelsky  wrote:

>
>
> On Wed, Dec 6, 2023 at 12:39 PM Fabio Valentini 
> wrote:
>
>> On Wed, Dec 6, 2023 at 11:17 AM Ondrej Pohorelsky 
>> wrote:
>> >
>> > Hi everyone,
>> >
>> > For F40 I would like to change file permissions of few files that are
>> provided by cronie and crontabs and swap deny list for allow list. I'm not
>> really sure if I should make a change proposal. I figured I'll send an
>> email first and see the feedback.
>> >
>> > The driving force of this change is feedback from RHEL customers, that
>> they would like to have cronie and crontabs CIS compliant out of the box.
>> Which means changing some of the file permissions and swapping `cron.deny`
>> for `cron.allow`. As it stands now, they have to run their own scripts or
>> dnf plugin (post-transaction-actions) to ensure that each update doesn't
>> overwrite the file permissions they manually set.
>>
>> Just out of curiosity - what does CIS even stand for?
>> The linked Red Hat docs don't expand the acronym, and googling for it
>> obviously yields results for something entirely different
>>
>
> Basically, it is a Center for Internet Security (CIS) benchmark that some
> companies use as a reference to limit configuration-based security
> vulnerabilities.
> I'm not really sure, but I think some governments require that their
> systems are compliant.
>
>

This standard is used in various Universities, local governments,
hospitals, financial organizations, and can be required in some cases for
PCI compliance (if your acreditor likes that kind of thing). Basically it
is one of the major standards like the US DOD STIG
https://en.wikipedia.org/wiki/Security_Technical_Implementation_Guide  /
https://ncp.nist.gov/repository

Like any standard, there are things which are good and some which are 'that
is a choice you could make, but...'



> You can look at CIS wikipedia page for more info:
>
> https://en.wikipedia.org/wiki/Center_for_Internet_Security#CIS_Controls_and_CIS_Benchmarks
>
> --
>
> Ondřej Pohořelský
>
> Software Engineer
>
> Red Hat 
>
> opoho...@redhat.com
> 
> --
> ___
> 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: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

On Wed, Dec 06, 2023 at 11:53:26AM +, Tom Hughes via devel wrote:
> On 06/12/2023 11:08, Ondrej Pohorelsky wrote:
> 
> > The only difference is that if you have populated the cron.deny list,
> > after update it gets saved as .rpmsave and cron.allow is created.
> > If the cron.deny is blank, it will get replaced.
> > Also, if you had cron.allow populated before, it will stay this way and
> > blank cron.allow.rpmnew is created.
> 
> Surely there is one more change though?
> 
> Namely that users who could previously run crontab to create
> cron jobs can no longer do so unless they have been added to
> the cron.allow file.
> 
> That seems like a breaking change to me?

Yes, making cron unusable out of the box for non-root users feels like
an pretty major regression in behaviour.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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: Change of cronie and crontabs CIS compliance

[Tom Hughes via devel]

On 06/12/2023 11:08, Ondrej Pohorelsky wrote:

The only difference is that if you have populated the cron.deny list, 
after update it gets saved as .rpmsave and cron.allow is created.

If the cron.deny is blank, it will get replaced.
Also, if you had cron.allow populated before, it will stay this way and 
blank cron.allow.rpmnew is created.


Surely there is one more change though?

Namely that users who could previously run crontab to create
cron jobs can no longer do so unless they have been added to
the cron.allow file.

That seems like a breaking change to me?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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

Copr builds are stuck at package signing

[František Šumšal]

Hey,

Thanks to Packit I noticed that a lot of our jobs are running longer than 
usual, and a quick glance at the Copr task queue[0] tells me there's something 
fishy going on. I opened a couple of jobs[1][2][3] and all of them seem to be 
stuck in the same step - signing the build RPMs:

builder-live.log:
RPMResults finished

backend.log:
[2023-12-05 16:22:41,769][  INFO][PID:2234386] Calling '/bin/sign -u 
rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org -p' (attempt #2)
[2023-12-05 16:22:43,127][WARNING][PID:2234386] Command '/bin/sign -u 
rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org -p' failed with: 
unknown key: rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org
[2023-12-05 16:22:43,129][WARNING][PID:2234386] Going to sleep 20s and re-try.
[2023-12-05 16:23:03,130][  INFO][PID:2234386] Calling '/bin/sign -u 
rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org -p' (attempt #3)
[2023-12-05 16:23:04,949][WARNING][PID:2234386] Command '/bin/sign -u 
rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org -p' failed with: 
unknown key: rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org
[2023-12-05 16:23:04,950][WARNING][PID:2234386] Going to sleep 20s and re-try.

Looks like the last 20s sleep takes _way_ longer than 20s. Is this a known 
issue?

[0] https://copr.fedorainfracloud.org/status/running/
[1] 
https://copr.fedorainfracloud.org/coprs/packit/cockpit-project-cockpit-19698/build/6726609/
[2] 
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/CI-libdnf5-pr1008/build/6726763/
[3] 
https://copr.fedorainfracloud.org/coprs/eliasofwaffle/gnome-shell-patched/build/6727378/
--
___
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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2023-12-06.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

appmenu-qtorphan, rdieter  2 weeks ago
arora orphan   2 weeks ago
aspell-ar orphan   2 weeks ago
aspell-he orphan   2 weeks ago
bash-completion-extrasorphan   2 weeks ago
bettercap eclipseo, go-sig, orphan 2 weeks ago
bidiv orphan   2 weeks ago
byzanzorphan   2 weeks ago
cagibiorphan, rdieter, than2 weeks ago
clash go-sig, orphan   1 weeks ago
coin-or-lemon orphan, sagitter 2 weeks ago
cpptoml   orphan   2 weeks ago
cutterorphan   2 weeks ago
dictd mcepl, orphan2 weeks ago
dovecot-fts-xapianorphan   2 weeks ago
echo-artist   orphan   2 weeks ago
elementary-onboarding orphan   2 weeks ago
emacs-evilorphan   2 weeks ago
emacs-goto-chgorphan   2 weeks ago
emacs-undo-tree   orphan   2 weeks ago
fbf-mukti-fonts   orphan   2 weeks ago
fontopia  orphan   2 weeks ago
fwknopcrypto-team, jjelen, orphan  2 weeks ago
gball orphan   2 weeks ago
ghc-crypto-cipher-types   orphan   2 weeks ago
gnome-bluetooth3.34   orphan   0 weeks ago
gnome-video-arcadeorphan   2 weeks ago
gnudosorphan   2 weeks ago
golang-vbom-util  go-sig, orphan   2 weeks ago
golang-xorm   agerstmayr, go-sig, nathans, 2 weeks ago
  orphan
gosnake   orphan   2 weeks ago
groonga-normalizer-mysql  orphan   2 weeks ago
heat-cfntools orphan, zaneb2 weeks ago
heisenbug-backgrounds orphan   2 weeks ago
herqq orphan   2 weeks ago
ibus-bogo orphan   2 weeks ago
ibutils   dledford, honli, michich,2 weeks ago
  orphan
icaro orphan   2 weeks ago
kde-plasma-ihatethecashew orphan   2 weeks ago
kflickr   orphan   2 weeks ago
ktp-accounts-kcm  jgrulich, kde-sig, orphan,   2 weeks ago
  rdieter
ktp-approver  jgrulich, kde-sig, orphan,   2 weeks ago
  rdieter
ktp-auth-handler  jgrulich, kde-sig, orphan,   2 weeks ago
  rdieter
ktp-common-internals  jgrulich, kde-sig, orphan,   2 weeks ago
  rdieter
ktp-contact-list  jgrulich, kde-sig, orphan,   2 weeks 

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 12:39 PM Fabio Valentini 
wrote:

> On Wed, Dec 6, 2023 at 11:17 AM Ondrej Pohorelsky 
> wrote:
> >
> > Hi everyone,
> >
> > For F40 I would like to change file permissions of few files that are
> provided by cronie and crontabs and swap deny list for allow list. I'm not
> really sure if I should make a change proposal. I figured I'll send an
> email first and see the feedback.
> >
> > The driving force of this change is feedback from RHEL customers, that
> they would like to have cronie and crontabs CIS compliant out of the box.
> Which means changing some of the file permissions and swapping `cron.deny`
> for `cron.allow`. As it stands now, they have to run their own scripts or
> dnf plugin (post-transaction-actions) to ensure that each update doesn't
> overwrite the file permissions they manually set.
>
> Just out of curiosity - what does CIS even stand for?
> The linked Red Hat docs don't expand the acronym, and googling for it
> obviously yields results for something entirely different
>

Basically, it is a Center for Internet Security (CIS) benchmark that some
companies use as a reference to limit configuration-based security
vulnerabilities.
I'm not really sure, but I think some governments require that their
systems are compliant.

You can look at CIS wikipedia page for more info:
https://en.wikipedia.org/wiki/Center_for_Internet_Security#CIS_Controls_and_CIS_Benchmarks

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

--
___
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: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

On Wed, Dec 06, 2023 at 12:39:02PM +0100, Fabio Valentini wrote:
> On Wed, Dec 6, 2023 at 11:17 AM Ondrej Pohorelsky  wrote:
> >
> > Hi everyone,
> >
> > For F40 I would like to change file permissions of few files that are 
> > provided by cronie and crontabs and swap deny list for allow list. I'm not 
> > really sure if I should make a change proposal. I figured I'll send an 
> > email first and see the feedback.
> >
> > The driving force of this change is feedback from RHEL customers, that they 
> > would like to have cronie and crontabs CIS compliant out of the box. Which 
> > means changing some of the file permissions and swapping `cron.deny` for 
> > `cron.allow`. As it stands now, they have to run their own scripts or dnf 
> > plugin (post-transaction-actions) to ensure that each update doesn't 
> > overwrite the file permissions they manually set.
> 
> Just out of curiosity - what does CIS even stand for?
> The linked Red Hat docs don't expand the acronym, and googling for it
> obviously yields results for something entirely different

It'll be referring to

  https://www.cisecurity.org/benchmark/red_hat_linux

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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 2154738] [abrt] slic3r: stl_add_facet(): perl killed by SIGABRT

[bugzilla]

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

Aoife Moloney  changed:

   What|Removed |Added

 Resolution|--- |EOL
 Status|NEW |CLOSED
Last Closed||2023-12-06 11:45:25



--- Comment #12 from Aoife Moloney  ---
Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora
Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202154738%23c12
--
___
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: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 12:32 PM Michael J Gruber 
wrote:

>
> Thanks, that sounds like the typical things to expect during an upgrade.
> We typically don't even have release notes mentioning this, but it would be
> nice, since it's even a "plus" for F40 (compliance, hardening).
>
> Does that mean making a change proposal? Sorry, I haven't done this before

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

--
___
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: Change of cronie and crontabs CIS compliance

[Fabio Valentini]

On Wed, Dec 6, 2023 at 11:17 AM Ondrej Pohorelsky  wrote:
>
> Hi everyone,
>
> For F40 I would like to change file permissions of few files that are 
> provided by cronie and crontabs and swap deny list for allow list. I'm not 
> really sure if I should make a change proposal. I figured I'll send an email 
> first and see the feedback.
>
> The driving force of this change is feedback from RHEL customers, that they 
> would like to have cronie and crontabs CIS compliant out of the box. Which 
> means changing some of the file permissions and swapping `cron.deny` for 
> `cron.allow`. As it stands now, they have to run their own scripts or dnf 
> plugin (post-transaction-actions) to ensure that each update doesn't 
> overwrite the file permissions they manually set.

Just out of curiosity - what does CIS even stand for?
The linked Red Hat docs don't expand the acronym, and googling for it
obviously yields results for something entirely different

Fabio
--
___
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: 20231206.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20231205.n.1
NEW: Fedora-Rawhide-20231206.n.0

= SUMMARY =
Added images:2
Dropped images:  7
Added packages:  3
Dropped packages:18
Upgraded packages:   67
Downgraded packages: 0

Size of added packages:  5.42 MiB
Size of dropped packages:3.50 MiB
Size of upgraded packages:   4.52 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Workstation live-osbuild aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20231206.n.0.aarch64.iso
Image: Workstation live-osbuild x86_64
Path: 
Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20231206.n.0.x86_64.iso

= DROPPED IMAGES =
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231205.n.1.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20231205.n.1.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20231205.n.1.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20231205.n.1.iso
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20231205.n.1.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20231205.n.1.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20231205.n.1.iso

= ADDED PACKAGES =
Package: intel-media-driver-free-23.4.2-1.fc40
Summary: The Intel Media Driver for VAAPI
RPMs:libigfxcmrt libigfxcmrt-devel libva-intel-media-driver
Size:5.27 MiB

Package: python-menuinst-2.0.0-1.fc40
Summary: Cross platform menu item installation
RPMs:python3-menuinst
Size:124.95 KiB

Package: rust-serde-untagged-0.1.1-1.fc40
Summary: Serde Visitor implementation for deserializing untagged enums
RPMs:rust-serde-untagged+default-devel rust-serde-untagged-devel
Size:30.31 KiB


= DROPPED PACKAGES =
Package: golang-sr-rockorager-tcell-term-0.9.0-3.fc39
Summary: An embeddable terminal widget for tcell
RPMs:golang-sr-rockorager-tcell-term-devel
Size:47.54 KiB

Package: golang-storj-common-0-0.8.20220717gite2f0836.fc37
Summary: Storj common packages
RPMs:golang-storj-common-devel
Size:502.70 KiB

Package: perl-Fennec-2.018-17.fc39
Summary: A tester's toolbox, and best friend
RPMs:perl-Fennec
Size:82.01 KiB

Package: pg_repack-1.4.8-4.fc39
Summary: Reorganize tables in PostgreSQL databases without any locks
RPMs:pg_repack
Size:376.36 KiB

Package: pgaudit-1.7.0-5.fc39
Summary: PostgreSQL Audit Extension
RPMs:pgaudit
Size:116.47 KiB

Package: php-kolab-net-ldap3-1.1.4-5.fc39
Summary: Advanced functionality for accessing LDAP directories
RPMs:php-kolab-net-ldap3
Size:40.99 KiB

Package: php-pear-Date-Holidays-0.21.8-20.fc39
Summary: Driver based class to calculate holidays
RPMs:php-pear-Date-Holidays
Size:54.98 KiB

Package: php-pear-Date-Holidays-USA-0.1.1-29.fc39
Summary: Driver based class to calculate holidays in USA
RPMs:php-pear-Date-Holidays-USA
Size:13.88 KiB

Package: php-pear-HTTP-OAuth-0.3.2-16.fc39
Summary: Implementation of the OAuth spec
RPMs:php-pear-HTTP-OAuth
Size:77.98 KiB

Package: php-pear-HTTP-Request2-2.5.1-5.fc39
Summary: Provides an easy way to perform HTTP requests
RPMs:php-pear-HTTP-Request2
Size:136.85 KiB

Package: php-pear-Net-DNS2-1.5.0-7.fc39
Summary: PHP Resolver library used to communicate with a DNS server
RPMs:php-pear-Net-DNS2
Size:99.15 KiB

Package: php-pear-Net-LDAP2-2.2.0-16.fc39
Summary: Object oriented interface for searching and manipulating LDAP-entries
RPMs:php-pear-Net-LDAP2
Size:101.26 KiB

Package: php-pear-Net-URL2-2.2.1-15.fc39
Summary: Class for parsing and handling URL
RPMs:php-pear-Net-URL2
Size:26.89 KiB

Package: php-pear-Text-Password-1.2.1-16.fc39
Summary: Creating passwords with PHP
RPMs:php-pear-Text-Password
Size:14.27 KiB

Package: php-pear-XML-Serializer-0.21.0-15.fc39
Summary: Swiss-army knife for reading and writing XML files
RPMs:php-pear-XML-Serializer
Size:56.03 KiB

Package: postgres-decoderbufs-1.9.7-3.Final.fc39
Summary: PostgreSQL Protocol Buffers logical decoder plugin
RPMs:postgres-decoderbufs
Size:97.06 KiB

Package: python-pyvhacd-0.0.2-2.fc40
Summary: Python bindings for V-HACD
RPMs:python3-pyvhacd
Size:563.42 KiB

Package: sqljet-1.1.10-27.fc39
Summary: Pure Java SQLite
RPMs:sqljet sqljet-javadoc
Size:1.15 MiB


= UPGRADED PACKAGES =
Package:  anaconda-40.13-1.fc40
Old package:  anaconda-40.11-1.fc40
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps

Re: Change of cronie and crontabs CIS compliance

[Michael J Gruber]

Am Mi., 6. Dez. 2023 um 12:09 Uhr schrieb Ondrej Pohorelsky <
opoho...@redhat.com>:

>
>
> On Wed, Dec 6, 2023 at 11:26 AM Michael J Gruber 
> wrote:
>
>> Hi there,
>>
>> what is the impact of these changes:
>> - Do default installs work the same way as before?
>> - Do existing setups (crontabs) keep working?
>>
>> If yes then I'd consider the permission changes to be fixes, or at least
>> standard packaging changes.
>>
>> What is is the policy for existing cron.allow/cron.deny, i.e. what would
>> `rpmconf -a` tell me?
>>
>>
> The default installs work same as before.
> Existing crontabs keep working as usual.
>
> The only difference is that if you have populated the cron.deny list,
> after update it gets saved as .rpmsave and cron.allow is created.
> If the cron.deny is blank, it will get replaced.
> Also, if you had cron.allow populated before, it will stay this way and
> blank cron.allow.rpmnew is created.
>
>
Thanks, that sounds like the typical things to expect during an upgrade. We
typically don't even have release notes mentioning this, but it would be
nice, since it's even a "plus" for F40 (compliance, hardening).

Cheers
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

[rpms/perl-Sub-Override] PR #1: 0.10 bump; Package tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Sub-Override` that 
you are following.

Merged pull-request:

``
0.10 bump; Package tests
``

https://src.fedoraproject.org/rpms/perl-Sub-Override/pull-request/1
--
___
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: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 11:26 AM Michael J Gruber 
wrote:

> Hi there,
>
> what is the impact of these changes:
> - Do default installs work the same way as before?
> - Do existing setups (crontabs) keep working?
>
> If yes then I'd consider the permission changes to be fixes, or at least
> standard packaging changes.
>
> What is is the policy for existing cron.allow/cron.deny, i.e. what would
> `rpmconf -a` tell me?
>
>
The default installs work same as before.
Existing crontabs keep working as usual.

The only difference is that if you have populated the cron.deny list, after
update it gets saved as .rpmsave and cron.allow is created.
If the cron.deny is blank, it will get replaced.
Also, if you had cron.allow populated before, it will stay this way and
blank cron.allow.rpmnew is created.

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

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

[rpms/perl-Sub-Override] PR #1: 0.10 bump; Package tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Sub-Override` 
that you are following:
``
0.10 bump; Package tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sub-Override/pull-request/1
--
___
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: Change of cronie and crontabs CIS compliance

[Michael J Gruber]

Am Mi., 6. Dez. 2023 um 11:17 Uhr schrieb Ondrej Pohorelsky <
opoho...@redhat.com>:

> Hi everyone,
>
> For F40 I would like to change file permissions of few files that are
> provided by cronie and crontabs and swap deny list for allow list. I'm not
> really sure if I should make a change proposal. I figured I'll send an
> email first and see the feedback.
>
> The driving force of this change is feedback from RHEL customers, that
> they would like to have cronie and crontabs CIS compliant out of the box.
> Which means changing some of the file permissions and swapping `cron.deny`
> for `cron.allow`. As it stands now, they have to run their own scripts or
> dnf plugin (post-transaction-actions) to ensure that each update doesn't
> overwrite the file permissions they manually set.
>
> I would like these changes for F40, as this is going to be a branching
> point for next RHEL and I would like to go with upstream first approach.
>
> *cronie* changes:
> `cron.allow` replaces `cron.deny`  (file permission 600)
> `cron.d` permission change (755 → 700)
> `cron.hourly` permission change (755 → 700)
>
> *crontabs* changes:
> `crontab` permission change (644 → 600)
> `cron.{hourly,daily,weekly,monthly}` permission change (755 → 700)
>
> Reference for these changes:
> static.open-scap.org/ssg-guides/ssg-rhel9-guide-cis.html
>
> PR:
> https://src.fedoraproject.org/rpms/cronie/pull-request/12
> https://src.fedoraproject.org/rpms/crontabs/pull-request/6
>
> Let me know what you think.
> Cheers,
> --
>
Hi there,

what is the impact of these changes:
- Do default installs work the same way as before?
- Do existing setups (crontabs) keep working?

If yes then I'd consider the permission changes to be fixes, or at least
standard packaging changes.

What is is the policy for existing cron.allow/cron.deny, i.e. what would
`rpmconf -a` tell me?

Cheers
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

Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

Hi everyone,

For F40 I would like to change file permissions of few files that are
provided by cronie and crontabs and swap deny list for allow list. I'm not
really sure if I should make a change proposal. I figured I'll send an
email first and see the feedback.

The driving force of this change is feedback from RHEL customers, that they
would like to have cronie and crontabs CIS compliant out of the box. Which
means changing some of the file permissions and swapping `cron.deny` for
`cron.allow`. As it stands now, they have to run their own scripts or dnf
plugin (post-transaction-actions) to ensure that each update doesn't
overwrite the file permissions they manually set.

I would like these changes for F40, as this is going to be a branching
point for next RHEL and I would like to go with upstream first approach.

*cronie* changes:
`cron.allow` replaces `cron.deny`  (file permission 600)
`cron.d` permission change (755 → 700)
`cron.hourly` permission change (755 → 700)

*crontabs* changes:
`crontab` permission change (644 → 600)
`cron.{hourly,daily,weekly,monthly}` permission change (755 → 700)

Reference for these changes:
static.open-scap.org/ssg-guides/ssg-rhel9-guide-cis.html

PR:
https://src.fedoraproject.org/rpms/cronie/pull-request/12
https://src.fedoraproject.org/rpms/crontabs/pull-request/6

Let me know what you think.
Cheers,
-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

--
___
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: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

[Gerd Hoffmann]

  Hi,
 
> What is the point of using shim in this path? We're not having UKIs
> signed by Microsoft, and unless the Linux kernel knows how to call
> shim for certificates, I don't see how this is supposed to be useful
> for the Microsoft->Fedora->OS boot chain.

Booting without shim.efi would work only if you enroll the fedora secure
boot CA in your firmware's security database.  That is not the default,
and not all virtualization environments offer the option to do that.

So, on a typical setup with the microsoft keys enrolled the firmware
wouldn't load the UKI, exactly because it is not signed by microsoft.
shim.efi is needed for everything signed with the fedora keys, be it
grub.efi, fwupd.efi, traditional kernels or UKIs.

Also note that fallback.efi (comes with shim and runs in case there is
no UEFI boot configuration) will create only uefi boot entries including
shim in the boot path, so there is no easy way to exclude shim.

Ideally we would have shim.efi signed with both microsoft and fedora
keys.  In that case the firmware -> shim.efi -> fedora-signed.efi boot
path would work in both cases (fedora keys / microsoft keys enrolled).

take care,
  Gerd
--
___
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: Obsoleting zlib in Fedora Rawhide

[Miro Hrončok]

On 06. 12. 23 0:09, Yaakov Selkowitz wrote:

Except that it's not 100% compatible, since all those packages aren't
building/working with zlib-ng-compat.  At a minimum, you should be able
to show that everything zlib-dependent successfully rebuilds with this,
and since you've already identified some that don't, IMO they should be
fixed*first*.


I agree in principle.

However, this is not a way we treat other updates/changes in Fedora.

Every year, we let a new GCC version be tossed into rawhide and we deal with 
possibly hundreds of FTBFS packages later.


Every week, we let maintainers update their packages while breaking runtime 
dependencies and we deal with the breakages later.


This zlib thing seems like a minor thing compared to the two above.

(And it certainly does not need a side tag and a mini mass rebuild.)

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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 2252999] F38FailsToInstall: perl-PAR-Packer

[bugzilla]

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

Fedora Fails To Install  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |CLOSED
Last Closed||2023-12-06 09:46:53



--- Comment #1 from Fedora Fails To Install  ---
Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

All subpackages of a package against which this bug was filled are now
installable or removed from Fedora 38.

Thanks for taking care of it!


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202252999%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: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

[Gerd Hoffmann]

On Tue, Dec 05, 2023 at 03:01:04PM -0600, Chris Adams wrote:
> Once upon a time, Aoife Moloney  said:
> > * UKIs need this to find the root filesystem without root=... on the
> > kernel command line.
> 
> How does this work in system with more than one Linux install?  Or any
> more-complicated disk setup (e.g. SW RAID)?  Does this also lock users
> out from ALL kernel command-line options?

Using UKIs is optional, if they don't work for your use case just
continue using traditional kernels.  Our main focus is virtualization
use cases and cloud images, where you usually have a simple disk setup.

Independent from that work is being done (mostly in systemd) to allow
configure the command line for UKIs in a secure way.  New in systemd
v254 are addon images which can extend the command line.  See "man
systemd-stub" for details.

take care,
  Gerd
--
___
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

[rpms/perl] PR #7: Add reverse test for perl-Devel-Cover

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl` that you are 
following:
``
Add reverse test for perl-Devel-Cover
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/7
--
___
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

Non-responsive maintainer check for Samuel P (survient)

[Ondřej Holý]

Hi,

this email is part of the non-responsive maintainer policy for the wsdd
package:
https://bugzilla.redhat.com/show_bug.cgi?id=2253133

It would be nice to update the package to the latest upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=2175523

I proposed a pull request for it two months ago but it remains unnoticed:
https://src.fedoraproject.org/rpms/wsdd/pull-request/1

The last activity by the maintainer on the package was in 2021:
https://src.fedoraproject.org/rpms/wsdd/c/5d6fcc9443ecb7a41c965df2fe562f277843ac8b

There is no activity recorded for the past year:
https://src.fedoraproject.org/user/survient

Does anyone know how to contact the maintainer?

Regards

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

[Test-Announce] Fedora 40 Rawhide 20231206.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 40 Rawhide 20231206.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20231130.n.0: anaconda-40.11-1.fc40.src, 20231206.n.0: 
anaconda-40.13-1.fc40.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/40

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231206.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231206.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231206.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231206.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231206.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231206.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_40_Rawhide_20231206.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

[Daniel P . Berrangé]

On Tue, Dec 05, 2023 at 04:14:00PM -0500, Neal Gompa wrote:
> On Tue, Dec 5, 2023 at 3:47 PM Aoife Moloney  wrote:
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > Improve support for unified kernels in Fedora.
> >
> > == Owner ==
> > * Name: [[User:kraxel| Gerd Hoffmann]]
> > * Email: kra...@redhat.com
> >
> > * Name: [[User:vittyvk| Vitaly Kuznetsov]]
> > * Email: vkuzn...@redhat.com
> >
> >
> > == Detailed Description ==
> > See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 
> > goals.
> >
> >  Phase 2 goals 
> >
> > * Add support for booting UKIs directly.
> > ** Boot path is shim.efi -> UKI, without any boot loader (grub,
> > sd-boot) involved.
> > ** The UEFI boot configuration will get an entry for each kernel installed.
> > ** Newly installed kernels are configured to be booted once (via BootNext).
> > ** Successful boot of the system will make the kernel update permanent
> > (update BootOrder).
> > * Enable UKIs for aarch64.
> > ** Should be just flipping the switch, dependencies such as kernel
> > zboot support are merged.
> > * Add a UEFI-only cloud image variant which uses UKIs.
> > ** Also suitable for being used in confidential VMs.
> > ** Cover both x86_64 and aarch64.
> >
> 
> What is the point of using shim in this path? We're not having UKIs
> signed by Microsoft, and unless the Linux kernel knows how to call
> shim for certificates, I don't see how this is supposed to be useful
> for the Microsoft->Fedora->OS boot chain.

The VM UEFI firmware almost always only has the Microsoft certs
installed. Thus the only thing it can boot is shim, which is
signed by Microsoft. The boot configuration tells shim to boot
the desired UKI, signed by Fedora, instead of its compiled
default of booting grub.

The only way you could do away with shim is to install the Fedora
certs in UEFI directly, which isn't something most public clouds
or other VM mgmt  tools support well (if at all).

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
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