Re: [Rpm-maint] [rpm-software-management/rpm] RFE: allow clamping username and permissions for source RPMs (Issue #2604)
> it would be useful to clamp the ownership of the files to root:root--though > this will necessitate ensuring that the applications which work with RPM > input/output respect this clamping and change the permissions if a user > extracts or installs it. (Namely, we don't want a user to install an RPM with > files they cannot touch or see) Actually this is not an issue. A user cannot create files they cannot touch or see: if we do the proposed change, if running as root, the file is created owned by root, but anyway, for root the ownership and permission mask are ignored. If running as a user, they cannot create any files not owned by them. So please just store the files as `uid=0`, `gid=0`, `mask=-rwxrwxraw` or `drwxrwxrwx`. This way, the right thing will happen, i.e. file will always be owned by the user and the permission mask will be determined by the user's umask. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2604#issuecomment-1719746732 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> > None of this is inherently Linux specific, however to make it reasonably > > fast and efficient, you need something like OverlayFS which is currently > > only available on Linux (and [#2559 > > (comment)](https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921) > > on some BSDs through fuse-overlayfs but that's likely slower than a native > > kernel implementation). > > [FUSE exists on macOS too](https://osxfuse.github.io/), though I don't know > if `fuse-overlayfs` works with it. Oh, nice. Also, see: https://github.com/containers/fuse-overlayfs/issues/140 But again, not something I'm going to invest time into. Anyone interested, feel free to investigate and/or submit patches ;) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719487211 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> I will also point out there are openSUSE containers that use DNF too. Interesting, thanks for sharing. I don't think it changes anything discussed here so far, though :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719476441 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> None of this is inherently Linux specific, however to make it reasonably fast > and efficient, you need something like OverlayFS which is currently only > available on Linux (and > https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921 > on some BSDs through fuse-overlayfs but that's likely slower than a native > kernel implementation). [FUSE exists on macOS too](https://osxfuse.github.io/), though I don't know if `fuse-overlayfs` works with it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719473973 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
One more thing to add to the above: *This* ticket is about using OCI images for the test root creation, on Linux distributions. Any kind of non-Linux work would need to be tracked in a separate ticket. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719473050 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Standardize on OCI images for test-suite, even locally (Issue #2643)
> Keep in mind, we need a way to run it directly on the host, because all this > fanciness you're talking about doesn't exist on non-Linux platforms. In > particular, I would like to be able to run the test suite for RPM on macOS > still. In essence, what the test-suite needs is a filesystem tree that contains an installation of RPM to test and its runtime dependencies (i.e. a `make install` as root in a development VM would do just fine), and a way to quickly make writable copies (e.g. copy-on-write snapshots) of that tree. Then, a plain chroot into those snapshots could be used to isolate the individual tests. None of this is inherently Linux specific, however to make it reasonably fast and efficient, you need something like OverlayFS which is currently only available on Linux (and [reportedly](https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921) on some BSDs through fuse-overlayfs but that's likely slower than a native kernel implementation). And then, instead of chroot, we *want* to (and *do*) make use of containers in our tests, now that we've freed ourselves from fakechroot. They offer much more possibilities, including proper uid/gid mapping for file ownership testing, unsharing more than just the filesystem namespace, etc. One way to make the test-suite POSIX compatible would be to identify tests that *require* a proper container and disable those on platforms that don't have containers. There, chroot could be used instead. But I'm not sure if we really want to go in that direction. Even then, while chroot is available on most UNIX platforms, OverlayFS-like functionality is not, or varies greatly among the systems (APFS on macOS comes close perhaps) and would need special handling. This really is not something we (the core development team at Red Hat) have the resources and/or expertise to cover. We rely on the community to do this work. One thing that's *not* mandatory, though, is rootless operation. We can always just assume that the test-suite is run in a development/throwaway VM. That's one less thing to worry about when it comes to supporting non-Linux systems. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719466788 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
I'd really prefer that we merge the existing certificate with the new certificate. This is particularly important as gpg strips old self signatures when exporting certificates. One consequence of replacing an existing certificate with a new version is that existing packages may not verify any more, which is annoying. Another is that we may remove a revocation certificate, which is dangerous. If we don't need to order versions, then using the hash as the version seems reasonable. Is that correct? If we use the hash of the "blob," this may mean that we have version A installed, the user installs version B, and as a result C is installed. Is that okay? Using a hash also assumes a canonical form. OpenPGP certificates don't have a canonical form. Packets, for instance, can be reordered. Is that an issue? It occurs to me that for the internal backend, this isn't really a problem as the only thing that really matters is the primary key packet. So we can probably come up with a straightforward hack. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1719111070 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Provide a decent API for verifying package signatures (Issue #2041)
As per https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1719074225 : > trying to shoehorn the keys into something resembling a package has been a > major source of headache as long as it's been there. It's just difficult to > get rid of. Ideally this would all happen in some blackbox keyring and rpm > doesn't need to care. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1719093060 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
Also, the way the keys are handled as sort of packages, people probably wouldn't be too shocked if we just treated it as a simple upgrade (erase old, import new) based on timestamp, and not worry about any merging at all. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1719082148 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
Yup, trying to shoehorn the keys into something resembling a package has been a major source of headache as long as it's been there. It's just difficult to get rid of. Ideally this would all happen in some blackbox keyring and rpm doesn't need to care. As long as we're stuck with the gpg-pubkey "packages"... One possible, if crude, way to handle this could be turning the "version" field into a hash that's calculated from the contained keys to differentiate the "packages", so it can at least be imported. That should "work" with the internal backend too, at least for cases where an updated key contains a new subkey (such as is the case with Chrome I guess). Changing the way the "version" is calculated is going to break something of course, but something is going to break here no matter what we do. On a related note, there's a long-standing RFE to stop using the short id for the version because it can (quite easily) conflict. And no, we're not going to try to implement any merge thing in the internal backend, no way. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1719074225 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
Ok, thanks for the clarification. >From my perspective, there is no way to generate a version number for an >OpenPGP certificate. This is because an OpenPGP certificate is composed of >packets, and packets can be left out without making the certificate completely >invalid. This is exactly what `gpg` does when it exports a certificate, and >only exports the newest self signature for each component. For me that means >that whenever a user tries to install a certificate, `rpm` should >unconditionally try and merge it with the existing version. The openpgp >backend would also need to provide an interface to merge two versions of a >certificate. This will be trivial to implement in rpm-sequoia, but will be >very complicated to implement for the internal backend. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1718968485 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
This is as good as any, I just wanted to point out to the reporter that whatever and whenever happens here can only be a forward-going solution, Google will need to deal with their existing users by some other means. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1718941761 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [RFE] Provide install time alternative to `%{?_isa}` (#1344)
This is actually a subcase of #446, closing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1344#issuecomment-1718921839 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [RFE] Provide install time alternative to `%{?_isa}` (#1344)
Closed #1344 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1344#event-10368445792 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Move checks and package initialization after build (PR #2646)
This is the major part of what is needed for #1240 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2646#issuecomment-1718917225 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Adopt PKCS#11 support for fsverity signatures in rpmsign (#1786)
Closed #1786 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1786#event-10368279514 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Adopt PKCS#11 support for fsverity signatures in rpmsign (#1786)
The PR died of old age, presumably this can be closed too then. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1786#issuecomment-1718902209 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: allow clamping username and permissions for source RPMs (Issue #2604)
Indeed, storing the local user/group into src.rpm makes no sense whatsoever. It's an anachronism from the ancient days before Buildroot was a thing that has somehow survived all the way up to this date. We've made some effort to swipe the symptoms under the carpet (ie avoid pointless warnings when this happens) but might as well address the root cause instead. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2604#issuecomment-1718858338 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
@pmatilai, unfortunately, I think you're right. Where should we discuss how to implement the merge / update operation? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1718855631 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Choose a cmake-native versioning scheme for pre-releases (Issue #2477)
I think we already decided. What remains is documenting it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2477#issuecomment-1718851964 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Have priorities for file patterns (#1226)
Closed #1226 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1226#event-10367580769 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Have priorities for file patterns (#1226)
This needs to be considered as part of #329 rather than a separate item. Closing now that it's linked. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1226#issuecomment-1718821511 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
