Re: DNF5-5.0.1 has a stable API
On Thu, Jul 20, 2023 at 5:46 AM Miroslav Suchý wrote: > Dne 20. 07. 23 v 10:08 Peter Robinson napsal(a): > > > So everything has to be rewritten across the entire ecosystem to > > work with it? Wow, who thinks that's a good idea? It took the > > ecosystem long enough to migrate from the yum "API" to dnf and now > > they have to do that all over again? > > "Only dead projects has stable API" > > Me. The yum to dnf transition was supposed to be the “the old API was so horribly broken that we had no choice but to throw it away and design a new API completely from scratch” event. Every software project gets one of those (1). Demand another, and users / downstream developers will (rightly) question why the project’s developers weren’t competent to ensure their first API rewrite didn’t preclude the necessity of any others. A flippant retort is not an appropriate way to handle this criticism. (1) https://www.youtube.com/watch?v=JcLztkzy3d4 ___ 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: F39 Change Proposal: LibuserDeprecation (System Wide)
On Thu, Jun 22, 2023 at 12:33 PM Aoife Moloney wrote: > The main benefit is to decrease the maintenance and packaging work > on library that does not bring much value while the functionality is > provided by another components. On most (all?) Linux distributions, Puppet relies on libuser in order to manage group membership as an attribute of a group (1), because historically the shadow-utils package could not. There are folks who use Puppet to manage Fedora systems, and pulling the libuser package will break the ability of Puppet to manage group membership on Fedora. Background: libuser provides the ability to intuitively manage local group membership as an attribute of the group, instead of attributes of users. To add a user to a group: lgroupmod -M someuser somegroup To remove a user from a group: lgroupmod -m someuser somegroup For shadow-utils, adding can be achieved with: groupmod -a -U someuser somegroup But groupmod has no ability to remove a user from a group. Historically, before shadow-utils 4.10, the only way to remove a user from a group was to use: usermod -G groupset someuser …where groupset was the set of all supplementary groups for the user but with somegroup removed. This was racy and error-prone. For shadow-utils 4.10 or later, usermod has a new -r option, so it is possible to construct an equivalent: usermod -r -G somegroup someuser While this is a vast improvement, I would argue this option was added to the wrong utility: groupmod should have the ability to remove a user from a group, the same as lgroupmod. It’s also fairly new (RHEL9 still has shadow-utils 4.9, for example). I don’t disagree with the reasons for wanting to drop libuser; I just wish that… * the shadow-utils package could provide the equivalent functionality in a more intuitive way, and… * this change could be pushed to at least Fedora 40, to provide more time for downstream consumers of libuser to move away from it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Encode-Detect] PR #1: Remove old cruft
ralston commented on the pull-request: `Remove old cruft` that you are following: `` Yes; merged. Thanks. (I typically clean up the spec file whenever I rebase to the latest version of a package, but there hasn't been a new version of this perl module in… well, forever, basically.) `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Encode-Detect/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
[rpms/perl-Encode-Detect] PR #1: Remove old cruft
ralston merged a pull-request against the project: `perl-Encode-Detect` that you are following. Merged pull-request: `` Remove old cruft `` https://src.fedoraproject.org/rpms/perl-Encode-Detect/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
abysmal performance using btrfs for VM storage (was Re: BTRFS vs LVM for VM storage)
On 2011-03-02 at 13:49-05 Josef Bacik jo...@toxicpanda.com wrote: How is BTRFS's performance when used to store VMs (presumably they are stored as files)? Good, but the problem is the default behavior of virt manager is to use fsync for everything, you have to manually go in and set the Cache to None so it will use O_DIRECT Doing this will make the Windows XP virtio driver BSOD, though: http://lists.fedoraproject.org/pipermail/devel/2011-March/149271.html and then it's just as fast as anything else. Alas, my experience is that btrfs performance when used to store VM disk images is abysmal to the point of being unusable: https://bugzilla.redhat.com/show_bug.cgi?id=689127 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On 2011-02-26 at 17:33-05 Lyos Gemini Norezel lyos.gemininore...@gmail.com wrote: On 02/23/2011 06:38 PM, James Ralston wrote: Separate LVM logical volumes can help mitigate consumption-based DoS attacks. For example: if /tmp and /var/tmp are separate LVM logical volumes, then a runaway/malicious process cannot fill up the entire filesystem merely by filling up /tmp or /var/tmp. For the sake of brevity... I already understand the encrypted volumes argument... but I still fail to see why /tmp, /var/tmp/, /opt, /usr, etc need to have their own partitions. I mentioned one: any filesystem tree that grants regular users write access should have some way to prevent DoS attacks. Making that subdirectory tree a separate filesystem is one way to do it. Another reason to isolate user-writable subdirectory trees to separate filesystems is to make certain types of security attacks more difficult (by removing the ability of a regular user to create a hard link to a file). The more complex a system is... the more likely it is to fail. Generally speaking, yes. But sometimes the benefits provided by the increased complexity are worth the (negligible in this case, IMHO) increase in risk. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On 2011-02-23 at 23:32-06 Michael Cronenworth m...@cchtml.com wrote: On 02/23/2011 05:38 PM, James Ralston wrote: None of these issues is a dealbreaker, but they *are* losses of functionality versus what LVM offers. LVM isn't going anywhere. It just won't be the default during a fresh installation, which you would still be free to override by using an LVM again if you wished. But I *don't* wish to discard btrfs and continue to use LVM. What I want to do is *replace* my use of LVM with btrfs. But to do that, I need to either figure out how to make btrfs do the things I currently do with LVM, or I need to figure out how to change the things I do to better leverage the capabilities of btrfs. I'm open to the former, the latter, or some combination of both. But right now, I've been unable to find enough information about btrfs to do either. A third thing that's important to me (which others have already mentioned): disks for virtual guests. With LVM, I simply lvcreate a new volume, and then when I create a new guest with virt-manager, I tell it to use the block device for the LVM logical volume. This avoids having a filesystem layer between the virtual guest and the LVM block device, which I've assumed (but have not actually tested) is a performance win. But in the btrfs is your entire disk model, it seems that my only option is to create a big file on the filesystem, and tell virt-manager to use that as the guest's disk. Even if I create the big file efficiently (i.e., with fallocate(2)), how much of a performance hit will I take by having the guest's disk I/O go through the btrfs filesystem layer, versus the LVM layer? A little? A lot? None at all, because it'll actually be a performance win? I have no idea. And furthermore, I don't know if there's a better way to do it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On 2011-02-24 at 16:02-05 Josef Bacik jo...@toxicpanda.com wrote: I think that if I could get a large base to test for F15 that we could squash most/all of the problems that crop up from that to be in great shape for default in F16. I think you'd increase your chances of getting lots of testers for F15+btrfs if there were documentation that explained how to take certain LVM configurations/actions and translate them into btrfs best practices. For examples, see my other follow-ups in this thread... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for BTRFS in Fedora
On 2011-02-22 at 14:51-05 Josef Bacik jo...@toxicpanda.com wrote: Fedora 16 ships without LVM as the volume manager and instead use BTRFS's built in volume management, again just for the default. I don't think btrfs subvolumes are capable of replacing LVM functionality quite yet. Here are two usage cases that I care about: 1. Separate LVM logical volumes can help mitigate consumption-based DoS attacks. For example: if /tmp and /var/tmp are separate LVM logical volumes, then a runaway/malicious process cannot fill up the entire filesystem merely by filling up /tmp or /var/tmp. In contrast, although the btrfs wiki mentions the ability to set a quota on subvolumes at creation time, I don't think anything in btrfs-progs implements that. Plus, even if there were a way to set it, I don't see that anything reports it. 2. Separate LVM logical volumes permit easier installs. Primarily because I've never trusted the upgrade process, but also for other reasons, I always perform a full install to upgrade from one version of Fedora to the next. With LVM logical volumes, this process is trivial: I do a custom partition layout, and tell anaconda to format the /boot, /, /tmp, /usr, /var, and /var/cache logical volumes, and leave all the other logical volumes in the system (e.g., /home, /var/log) alone. I can't do this with one big btrfs filesystem with subvolumes. What I would have to do is first boot the installer in rescue mode, then run a bunch of find /subvolume -xdev commands to delete all the data on the subvolumes that I wanted to reformat. Then I'd have to re-run the installer and tell it to use the / btrfs filesystem as-is, without formatting. None of these issues is a dealbreaker, but they *are* losses of functionality versus what LVM offers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 2010-12-08 at 21:00+00 Richard W.M. Jones rjo...@redhat.com wrote: To the original poster: even a VM isn't a completely robust way of preventing root escalations. This is a certainly true. If an attacker manages to gain control of a VM guest, he can attempt to attack the VM host. (In fact, depending on the attack, escalated privileges on the VM guest may not even be necessary.) But this is simply another instance of the generic problem of security vulnerabilities providing an avenue for privilege escalation, which isn't a problem that is unique to VMs. If the developers are all in your organization, how about using a cluestick-based method to prevent them doing this? Because a security solution that trusts users not to deliberately or accidentally acquire access that they aren't [administratively] permitted to have is no solution. It would be no different than hanging a sign on the front door of my house that said, even though my door is unlocked, since stealing is wrong, I trust that no one will rob me. Furthermore, intelligent users would also refuse such an arrangement, because if the server that provides mock is rooted, the prime suspects would immediately be the mock users who did not otherwise have root privileges on the box. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 2010-12-10 at 14:02+00 Daniel P Berrange berra...@redhat.com wrote: I'm not familiar with what attacks you can do on mocks' chroot setup offhand http://fedoraproject.org/wiki/Projects/Mock describes an easy one: $ /usr/bin/mock --init -r fedora-10-i386 $ /usr/bin/mock --shell -r fedora-10-i386 mock-chroot chmod u+s bin/bash $ /var/lib/mock/fedora-10-i386/root/bin/bash -p # cat /etc/shadow but perhaps it is possible to avoid them by also leveraging some of the new kernel container features which allow you to build stronger virtual root, without going to the extreme of a full VM. There are two challenges here. First, you must be able to prevent the root user from breaking out of the chroot jail. But second, you must also prevent unprivileged users outside of the chroot jail from being able to interact with things inside the chroot jail in a manner that they can use to escalate their privileges. Setting up a setuid bash shell within the chroot jail and then invoking it via a normal user outside of the jail is the obvious example, but there are undoubtedly other avenues of attack that must be defended. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
hosted reproducible package building with multiple developers?
Riddle me this. We want to provide a server for developers within our organization to build RPM packages for use within our organization. These are our requirements: 1. The developers must not be able to leverage the package build process to obtain root access on the server. 2. If a package has a build dependency that is not explicitly specified, the build must fail. 3. If two developers are building packages simultaneously, their builds must not conflict. The only way satisfy requirements #2 and #3 is to use a chroot'ed build environment. mock(1) uses a chroot'ed build environment, but mock fails requirement #1, as anyone in the mock group can trivially root the box. I think that koji would satisfy all three requirements, because koji uses mock to build, but doesn't allow developers to interface with mock directly. But setting up a koji infrastructure seems like a highly non-trivial task. Is there really no way to meet all three of these requirements without going the full-blown koji route? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hosted reproducible package building with multiple developers?
On 2010-12-08 at 13:07-05 seth vidal skvi...@fedoraproject.org wrote: the mock chroots that koji uses could still be rooted by someone who can submit their own build-requirement-providing packages. Well, we vet all packages our developers submit before releasing them to our repositories, so we would catch a developer submitting (e.g.) a suid-bash-shell-1.0.0-1.el5.x86_64.rpm package. Does koji provide a mechanism for the submitter to specify his own yum repositories for mock to use? in order to protect the builders they must be: 1. disposable 2. in a vm or possibly both. Well, the ultimate protection would be to use this procedure for each build: 1. Instantiate VMs for all architectures specified by the build, via cloning known good build VMs. 2. Use koji to build on each VM. 3. Destroy each VM that was instantiated. But that's some *serious* overhead. Plus, I'm not sure that we could automate steps #1 and #3, which would be a dealbreaker. Honestly, given current trends, it might be that before too much longer, the best solution might be to simply give each developer his own VM for each OS/architecture he wants to build for, and tell him to use mock directly. Before each build, he snapshots the VM, and after each build, he reverts to the snapshot (discarding whatever changes the build process made to the system)... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
