Cleanup missing directories in RPM database
Hi, as a follow-up to my attempt to clean up missing directories in RPM database, the following questions arose: Who should own the directories for "non-standard" icon sizes? Is there a defined set of standard sizes? Please see also BZ#2284088: How should this be solved? Thank you for any support. Best Regards, Christoph Karl -- ___ 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: Files missing in RPM database
Hi!
Am 01.05.24 um 19:58 schrieb Jens-Ulrik Petersen:
On Thu, May 2, 2024 at 1:21 AM Christoph Karl via devel <
devel@lists.fedoraproject.org> wrote:
I tried to find out which files on my upgraded fc40 installation are not
installed via dnf/rpm.
The list is surprisingly long.
Perhaps you could upload the list to fedorapeople or somewhere?
Maybe also the script you used?
find /usr/ -exec /usr/bin/bash -c 'rpm -qf -- "$1" >/dev/null 2>&1 ||
echo "$1"' find_sh {} \;
The list itself strongly depends how long your are already upgrading
fedora and which packages you have installed.
--
___
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
Files missing in RPM database
Hi! I tried to find out which files on my upgraded fc40 installation are not installed via dnf/rpm. The list is surprisingly long. Main reasons are symlinks and directories not defined in the spec file. A quick check shows that this is also the case with a fresh installation. I see three reason for having this clean: *) Knowing which files comes from installations outside dnf/rpm. Maybe this is security related? *) Making some kind of clever backup (list of RPMs and only additional/changed files) *) Removal or Upgrade of RPMs/distribution should not left files behind. Should this be (slowly) cleaned up or do I see this too strict? PS.: Two of my packages had this also. :) Best regards Christoph -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Switching XZ for ZSTD?
Hi! +1 The sequence must be: measure -> think -> act. Not: act (in panic) -> think (oh, that ist not the correct way, or even worse: oh, this is the way the attacker wants us to go.) measure (we have a weakness) Best regards Christoph Am 04.04.24 um 20:11 schrieb Leon Fauster via devel: One approach that would be at least bring some light into "weak" (non technical layer) components (albeit not sure how feasible it is), could be: - Checking the resources of a packaged project. Resources in terms of man or firm power that backup the project - Contribution activity of people - General activity of the project - Transparency of the workflow / tools and that for all projects that the distribution includes. Why? This would allow to plan internal review activities (or processes) more effectively. They would be directed to the "weak" components with higher priority (recurrent, actions). Like the current process for checking the license (SPDX) of a project, it could also collect such metrics right away. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
+1 Am 01.04.24 um 06:31 schrieb Scott Schmit: One approach: 1. do the build 2. do the install 3. generate the RPMs 4. quarantine the RPMs so they're safe from modification - I believe this could be done via SELinux policy - there are probably other mechanisms 5. run the tests - for SELinux, this might be via an `rpmbuild-test` binary that doesn't have rights to touch the output RPMs 6a. if the tests fail, destroy the RPMs and fail out, reproducing the result today 6b. if the tests pass, move/copy the RPMs to the result location and exit cleanly, reproducing the result today Boils down to separate source and test code/phase source code: (hopefully not obfuscated to the point where no review is possible) no binaries allowed, best possible review needed to build build phase: source to binary test code: binaries allowed only needed to test test phase: binary unmodified Allowing a test file to modify the binary makes it a source file. ? Christoph -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
