Re: Proven to be sickened
On Sun, Dec 10, 2023 at 5:39 PM Sérgio Basto wrote: > Maybe we should have a flag in the src.fp.o package for the maintainer > to request a PR before committing to have a window for review, or like > me, the maintainer would like to not be bothered with things that > proven package can do by itself . > > Another thing is some proven packager which wants force the move to > autothings , which I don't like use it, ATM, because in my opinion > still have many problems . I think there is a difference between changes that have a formal change proposal (I am thinking something like removing make from the buildroot, which required many packages to add a BR: make, and for which PP's did a lot of the work for some packages), for which packagers were given a sufficient period of time to make the change on their own, and "philosophical"/"syntactical sugar" changes, such as the current "autothings", for which there is not an approved change for all packages (FD: I would object to making the "autothings" mandatory). If a proven packager changes the syntactical sugar without agreement by the current packager via a PR they have exceeded their mandate, and should be (first) asked to revert and formally apologize, and if they repeat such, removed from the PP list (fool me once, shame on you, fool me twice shame on me). FTBFS issues are, admittedly, complicated, but such updates SHOULD be via a PR. If a PP wants to claim they cannot follow that process, they need to demonstrate that a particular packager is not responsive (there is a process for that) rather then just deciding themselves it is too much trouble. -- ___ 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] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a0fcd69d86 chromium-120.0.6099.71-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing borgbackup-1.2.7-1.el9 cpuid-20230614-2.el9 fakeroot-1.32.2-1.el9 nbtscan-1.7.2-1.el9 podman-tui-0.14.0-2.el9 python-registry-1.4-11.el9 rdiff-backup-2.2.6-3.el9 xwayland-run-0.0.2-2.el9 Details about builds: borgbackup-1.2.7-1.el9 (FEDORA-EPEL-2023-e33636de47) A deduplicating backup program with compression and authenticated encryption Update Information: latest stable upstream release ChangeLog: * Sun Dec 10 2023 Felix Schwarz - 1.2.7-1 - update to 1.2.7 cpuid-20230614-2.el9 (FEDORA-EPEL-2023-c5f7c77863) Dumps information about the CPU(s) Update Information: Add missing run-time requirement (fixes rhbz#2238868) ChangeLog: * Sun Dec 10 2023 Fabian Affolter - 20230614-2 - Add missing run-time requirement (fixes rhbz#2238868) References: [ 1 ] Bug #2238868 - perl-autodie required for cpuinfo2cpuid command https://bugzilla.redhat.com/show_bug.cgi?id=2238868 fakeroot-1.32.2-1.el9 (FEDORA-EPEL-2023-dbaa19fd1e) Gives a fake root environment Update Information: Update to 1.32.2 (#2248160) ChangeLog: * Mon Nov 6 2023 Fedora Release Monitoring - 1.32.2-1 - Update to 1.32.2 (#2248160) References: [ 1 ] Bug #2248160 - fakeroot-1.32.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=2248160 nbtscan-1.7.2-1.el9 (FEDORA-EPEL-2023-4afe2d9cc3) Tool to gather NetBIOS info from Windows networks Update Information: change to new github fork ChangeLog: * Sat Dec 9 2023 Michal Ambroz - 1.7.2-1 - change to new github fork - bump to latest release - fix the SPDX license * Thu Jul 20 2023 Fedora Release Engineering - 1.5.1-31 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Thu Jan 19 2023 Fedora Release Engineering - 1.5.1-30 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Thu Nov 24 2022 Florian Weimer - 1.5.1-29 - Port to C99 (#2148247) * Fri Jul 22 2022 Fedora Release Engineering - 1.5.1-28 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 20 2022 Fedora Release Engineering - 1.5.1-27 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild podman-tui-0.14.0-2.el9 (FEDORA-EPEL-2023-f9c9a69df5) Podman Terminal User Interface Update Information: podman-tui release 0.14.0 ChangeLog: * Sun Dec 10 2023 Navid Yaghoobi - 0.14.0-1 - release v0.14.0 python-registry-1.4-11.el9 (FEDORA-EPEL-2023-df514de581) Read access to Windows Registry files Update Information: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild ChangeLog: * Fri Jul 21 2023 Fedora Release Engineering - 1.4-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Tue Jun 13 2023 Python Maint - 1.4-10 - Rebuilt
Re: python packaging assistance sought for xgboost
Thanks for the assistance Miro. I've uploaded a local build log here: https://nathans.fedorapeople.org/xgboost/build.log AFAICS the python parts of the %install step seemed to have worked, but based on Sandro's pointer I can see many files are missing. cheers. -- Nathan -- ___ 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: python packaging assistance sought for xgboost
Thanks for the assistance Sandro! What I see is ... BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/[...] <- all manner of files from the C++ build/install, then ... BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12 BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages/xgboost-2.0.2.dist-info BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages/xgboost-2.0.2.dist-info/METADATA BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages/xgboost-2.0.2.dist-info/WHEEL BUILDROOT/xgboost-2.0.2-1.fc39.aarch64/usr/lib/python3.12/site-packages/xgboost-2.0.2.dist-info/INSTALLER But nothing that looks like actual python code has been installed. I'll followup with the build log shortly. cheers. -- Nathan -- ___ 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
Self Introduction: Rafel Amer
Hi, my name is Rafel Amer and I'm professor at the Technical University of Catalonia https:/www.upc.edu. I teach Maths and I use sagemath for my classes. After the sagemath package is orphandend, I would like to be a maintainer or co-maintainer this package. I have successfully build sagemath 10.1 packages for Fedora 38 in x86_64 and aarch64 architectures, so I think that I could maintain this package. I started using Linux in 1995 with Slackware and I have administered server with Debian and CentOS. At house and for my classes I use Fedora 28. Regards, Rafel Amer -- ___ 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: Proven to be sickened
On Thu, 2023-12-07 at 11:41 +0100, Michal Schorm wrote: > On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer > wrote: > > Asking individual maintainers for trivial changes does not scale. > > The > > alternative would be not to address FTBFS and other build issues, > > maybe > > file bugs, and rely on active maintainers instead. > > The alternative we want to achieve is: > (1) write useful commit messages, so the reasons and goal of the > proven package's commit would be clear > and > (2) give the maintainers the possibility to react. E.g. with a PR. > No one responded to the PR in a week? Force merge it with proven > packager rights. > TL;DR; Maybe we should have a flag in the src.fp.o package for the maintainer to request a PR before committing to have a window for review, or like me, the maintainer would like to not be bothered with things that proven package can do by itself . Another thing is some proven packager which wants force the move to autothings , which I don't like use it, ATM, because in my opinion still have many problems . > Even though I would want a longer time window and multiple iterations > of trying to contact the maintainer, > putting the PR up just for a week would make the current situation > considerably better than it is. > > I would expect the maintainers to only react on PRs in three general > ways: > (1) asking for more information = likely means you haven't explained > the commit or the problem well > that marks problem on your side > (2) rejecting the PR for a good reason = likely means there's a > problem with the implementation of your solution. > that marks problem on your side > (3) coming up with an alternative solution = likely means you haven't > thought of package specific approaches > You might find out the packager has a better idea how to solve the > problem in general. > Or you just collaborated nicely. > > Each way leads to a valuable end, I believe. > > There may be more ways to react (e.g. not react at all), but for now > let's assume they are not significant, as you'd end up anyway using > the proven packagers rights to force merge. > > Michal > > -- > > Michal Schorm > Software Engineer > Core Services - Databases Team > Red Hat > > -- > > On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer > wrote: > > > > * Kevin Kofler via devel: > > > > > Michael J Gruber wrote: > > > > I am sick of this. Really. I am so sick of this way of stomping > > > > on each > > > > others' feet. > > > > > > My pet peeve is provenpackagers or comaintainers who add unwanted > > > automagic (autorelease, autosetup, autochangelog) to my packages. > > > I do > > > not want any of that in my packages, it just makes my work harder > > > (or > > > in practice, just wastes my time for the revert that I am > > > inevitably > > > going to do). > > > > If the package does not contain any patches yet, it's not really > > possible to infer the maintainer intentions. %setup vs %autosetup > > doesn't matter much in that case, so it doesn't really tell us > > anything. > > Likewise if the package uses %autosetup, but without -p1, and there > > are > > no patches. Does the maintainer really prefer those awkarward -p- > > less > > patches? We don't know. > > > > Asking individual maintainers for trivial changes does not scale. > > The > > alternative would be not to address FTBFS and other build issues, > > maybe > > file bugs, and rely on active maintainers instead. But I don't > > think > > that can work for Fedora, practically speaking. Fedora lacks > > Debian's > > ban on forcing packagers to do certain work. In the past, FESCo > > has > > used that to order that certain packagers must keep carrying out > > certain > > work they do not want to do, but I think that only means anything > > if the > > victim packager is a Red Hatter on certain teams, I think. Others > > will > > just quit if they disagree. > > > > Thanks, > > Florian > > -- > > ___ > > 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 > -- > ___ > 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: >
Re: python packaging assistance sought for xgboost
On 08. 12. 23 7:22, Nathan Scott wrote:
Hi all,
I've recently been packaging xgboost for Fedora. It's a C++ project using
cmake, with a python module on the side (all in one source tarball):
https://nathans.fedorapeople.org/xgboost/
The dependent dmlc-core package is here:
https://nathans.fedorapeople.org/dmlc-core/
Everything is prepared and working from the C++ and shared library
perspectives, but I'm struggling with getting the python module to install
using latest Fedora python spec guidelines. Can anyone point out where I've
gone wrong? (looks like its during the final python step in the spec %install)
https://nathans.fedorapeople.org/xgboost/xgboost.spec+python shows my additions to add
the python sub-package and this is the error I now see (this is from the
"%pyproject_save_files xgboost" line right at the end of %install):
Traceback (most recent call last):
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 775, in
main(cli_args)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 730, in main
file_section, module_names = pyproject_save_files_and_modules(
^
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 720, in
pyproject_save_files_and_modules
generate_file_list(paths_dict, globs, include_auto)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 534, in
generate_file_list
raise ValueError(f"Globs did not match any module: {missed_text}")
ValueError: Globs did not match any module: xgboost
error: Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
Hello. As was already said, the error is that:
%pyproject_save_files xgboost
Finds no such Python modules.
If you could provide a full build log, it might indicate what Python modules
(if any) are actually installed.
Examining the wheels from https://pypi.org/project/xgboost/#files
xgboost-2.0.2-py3-none-manylinux2014_x86_64.whl
This one actually contains an xgboost Python module. That might indicate the
build step in %pyproject_wheel is somewhat broken. Without full logs, I cannot
say more.
--
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
On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote: > 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. I think this part alone is worthwhile in a general distro like Fedora, irrespective of any CIS requirements. Env vars can contain secret data and they are no longer readble by all users in process lists, so changing permissions on cron files fixes a real potential information leak. Also, it is hard to keep file and directory permissions changed from how they are packaged. The files will become exposed during package updates until some other script comes by and fixes them again. So it is worthwhile to fix this in the packaging. I agree that the correct middle ground is to fix the permissions, but leave the other parts about cron.allow/cron.deny alone. -- ___ 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: 20231210.n.0 changes
OLD: Fedora-Rawhide-20231209.n.0 NEW: Fedora-Rawhide-20231210.n.0 = SUMMARY = Added images:0 Dropped images: 4 Added packages: 1 Dropped packages:0 Upgraded packages: 112 Downgraded packages: 0 Size of added packages: 588.45 KiB Size of dropped packages:0 B Size of upgraded packages: 16.00 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 1.13 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20231209.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20231209.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20231209.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20231209.n.0.iso = ADDED PACKAGES = Package: ptl-2.3.3-1.20230707gitf892a93.fc40 Summary: Lightweight C++11 mutilthreading tasking system RPMs:ptl ptl-devel Size:588.45 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: bandit-1.7.6-1.fc40 Old package: bandit-1.7.5-4.fc39 Summary: A framework for performing security analysis of Python source code RPMs: bandit Size: 306.24 KiB Size change: 1.70 KiB Changelog: * Sat Dec 09 2023 Mikel Olasagasti Uranga - 1.7.6-1 - Update to 1.7.6 - Closes rhbz#2253734 Package: bodhi-client-8.0.0-1.fc40 Old package: bodhi-client-7.2.2-1.fc40 Summary: Bodhi client RPMs: bodhi-client Size: 89.71 KiB Size change: 401 B Changelog: * Sat Dec 09 2023 Mattia Verga - 8.0.0-1 - Update to 8.0.0 Package: bodhi-messages-8.0.0-1.fc40 Old package: bodhi-messages-7.2.2-1.fc40 Summary: JSON schema for messages sent by Bodhi RPMs: python3-bodhi-messages Size: 50.39 KiB Size change: 1.02 KiB Changelog: * Sat Dec 09 2023 Mattia Verga - 8.0.0-1 - Update to 8.0.0 Package: bodhi-server-8.0.0-1.fc40 Old package: bodhi-server-7.2.2-1.fc40 Summary: Bodhi server RPMs: bodhi-composer bodhi-server Size: 4.62 MiB Size change: -139.27 KiB Changelog: * Sat Dec 09 2023 Mattia Verga - 8.0.0-1 - Update to 8.0.0 Package: doctl-1.101.0-2.fc40 Old package: doctl-1.100.0-1.fc40 Summary: The official command line interface for the DigitalOcean API RPMs: doctl golang-github-digitalocean-doctl-devel Size: 25.39 MiB Size change: 63.84 KiB Changelog: * Sat Dec 09 2023 Mikel Olasagasti Uranga - Update to 1.101.0 - Closes rhbz#2253730 rhbz#2248265 Package: gnome-control-center-45.2-1.fc40 Old package: gnome-control-center-45.1-2.fc40 Summary: Utilities to configure the GNOME desktop RPMs: gnome-control-center gnome-control-center-filesystem Size: 26.90 MiB Size change: -26.44 KiB Changelog: * Sat Dec 09 2023 Kalev Lember - 45.2-1 - Update to 45.2 Package: golang-github-digitalocean-godo-1.107.0-1.fc40 Old package: golang-github-digitalocean-godo-1.105.0-1.fc40 Summary: DigitalOcean Go API client RPMs: golang-github-digitalocean-godo-devel Size: 173.43 KiB Size change: -824 B Changelog: * Sat Dec 09 2023 Mikel Olasagasti Uranga - 1.107.0-1 - Update to 1.107.0 - Closes rhbz#2248648 Package: guacamole-server-1.5.4-1.fc40 Old package: guacamole-server-1.5.3-1.fc39 Summary: Server-side native components that form the Guacamole proxy RPMs: guacd libguac libguac-client-kubernetes libguac-client-rdp libguac-client-ssh libguac-client-telnet libguac-client-vnc libguac-devel Size: 3.89 MiB Size change: 130.48 KiB Changelog: * Sat Dec 09 2023 Robert Scheck - 1.5.4-1 - Update to 1.5.4 (#2223510) Package: guestfs-tools-1.51.6-2.fc40 Old package: guestfs-tools-1.51.5-2.fc40 Summary: Tools to access and modify virtual machine disk images RPMs: guestfs-tools guestfs-tools-bash-completion guestfs-tools-man-pages-ja guestfs-tools-man-pages-uk virt-win-reg Size: 18.19 MiB Size change: -30.01 KiB Changelog: * Sat Dec 09 2023 Richard W.M. Jones - 1.51.6-2 - New development version 1.51.6 Package: java-1.8.0-openjdk-1:1.8.0.392.b08-5.fc40 Old package: java-1.8.0-openjdk-1:1.8.0.392.b08-4.fc40 Summary: OpenJDK 8 Runtime Environment RPMs: java-1.8.0-openjdk java-1.8.0-openjdk-demo java-1.8.0-openjdk-demo-fastdebug java-1.8.0-openjdk-demo-slowdebug java-1.8.0-openjdk-devel java-1.8.0-openjdk-devel-fastdebug java-1.8.0-openjdk-devel-slowdebug java-1.8.0-openjdk-fastdebug java-1.8.0-openjdk-headless java-1.8.0-openjdk-headless-fastdebug java-1.8.0-openjdk-headless-slowdebug java-1.8.0-openjdk-javadoc java-1.8.0-openjdk-javadoc-zip java-1.8.0-openjdk-openjfx java-1.8.0-openjdk-openjfx-devel java-1.8.0-openjdk-openjfx
Re: Change of cronie and crontabs CIS compliance
Generally, CIS Benchmarks are only prescriptive and getting near/total
compliance with the benchmark is mainly for those who have host
fleets under some SCAP compliance regime. Nonetheless, picking on the low
hanging fruit such as cron compliance isn't going to drastically improve
the security posture of the host, you still need to follow through with all
the other recommendations in the benchmark.
Also worth noting is that the CIS Benchmarks evolve along the latest
security practices/thinking and are subject to constant change, which may
not sit comfortably with a typical OS release whose selling point is ease
of providing more functionality, features and flexibility.
Hardening an OS usually has its place as a service finalisation activity
i.e. it occurs well after installation, and the CIS Benchmarks remain a
useful tool for doing this.
On Thu, 7 Dec 2023 at 00:21, Ondrej Pohorelsky wrote:
>
>
> 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
>
--
___
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] 2023-12-11 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-12-11 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org Greetings testers! It's time for the last QA meeting of the year! We're going to try moving back to Fedora Chat (Matrix) for this meeting, as the bot should be working there now. Remember, the IRC bridge is out of commission, so you'll really have to be on Matrix to join the meeting. You can log in with your Fedora account. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 40 check-in 3. Communications overhaul: Discourse and Matrix? 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
