Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
I've added a commit to illustrate a slightly different approach. Code quality and error handling need more work, and there are no new tests, but I'd like to ignore that for the moment and discuss only whether this approach is worth developing further. This change adds another file to packages that provide ELF shared objects, and that file contains their version. By default, the version is that of the RPM package, but package maintainers could override the macro so that the maintainers of alternate library implementations can coordinate an ABI version between packages whose version does not match. This would also support a gradual rollout. Worst-case, it's still possible that any given package might not have enhanced "requires" information until two mass rebuilds were done, but the macros can be enabled at the same time and enhanced information will be added as it becomes available. One of the SUSE list members mentioned that they want to continue to be able to use LEAP packages as dependencies, and I think this approach addresses that concern. The trade-off is the proliferation of small hidden text files in the lib directories. Briefly, for example, the libnghttp2 package currently includes: ``` lrwxrwxrwx. 1 root root 21 Oct 10 17:00 /usr/lib64/libnghttp2.so.14 -> libnghttp2.so.14.24.3* ``` The previous version of this PR would read the version "14.24.3" from that symlink and change one of the capabilities the package provides from `libnghttp2.so.14()(64bit)` to `libnghttp2.so.14()(64bit) = 14.24.3` This version of the PR would add a file, `/usr/lib64/.elf-version/libnghttp2.so.14`, which contained a single line reading "1.55.1", which is the version of the package that provides it. It will change one of the capabilities the package provides from `libnghttp2.so.14()(64bit)` to `libnghttp2.so.14()(64bit) = 1.55.1`. This was the source of the version that I'd originally proposed, and has the advantage that it also addresses the ~ 7% of libraries that end in ".so.0.0.0". -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2008581075 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] Enhance requires with version information from the build root. (PR #2372)
@gordonmessmer pushed 1 commit. 9cb6fc8272970b074e77076369f88a5cacb5c13a Rather than read the version for an ELF shared object directly -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372/files/3c412b8d2b85112316033bf87746cdfa29542c4d..9cb6fc8272970b074e77076369f88a5cacb5c13a 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] Add support for bare `%package` (Discussion #2959)
I wish you could elaborate more. From your answer, I am not able to deduce 1. If you like / not like the idea if you were free from current implementation 2. What it would take to change the implementation 3. If there are any hopes or not -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8841037 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] Add support for bare `%package` (Discussion #2959)
The main package preamble has to come first, the rest of the spec parser is built on top of that assumption. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8839919 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] Allow building rpm without OpenPGP support (PR #2984)
Couple of simple tests added, a whole lot tests skipped when dummy pgp used. The INSTALL docs hopefully a little saner now :laughing: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2006967300 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] Allow building rpm without OpenPGP support (PR #2984)
@pmatilai commented on this pull request.
> +return PGPARMOR_NONE;
+}
+
+int pgpPubKeyCertLen(const uint8_t *pkts, size_t pktslen, size_t *certlen)
+{
+return -1;
+}
+
+char * pgpArmorWrap(int atype, const unsigned char * s, size_t ns)
+{
+return NULL;
+}
+
+rpmRC pgpPubKeyLint(const uint8_t *pkts, size_t pktslen, char **explanation)
+{
+*explanation = NULL;
Unfortunately this too happens too late for rpm cli users to see it, because
the loop in doImport() already fails in the pgpParsePkts() step :-/ But, the
message could help *someone* at least.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#discussion_r1530207856
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] Allow building rpm without OpenPGP support (PR #2984)
@pmatilai pushed 1 commit. 6ede5d3ed8081ddcece6a44176ed38863c848e3f Allow building rpm without OpenPGP support -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984/files/2286b6001d2e3bb09e6efa8a0a02bb0ccdd34880..6ede5d3ed8081ddcece6a44176ed38863c848e3f 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] Allow building rpm without OpenPGP support (PR #2984)
@pmatilai pushed 1 commit. 2286b6001d2e3bb09e6efa8a0a02bb0ccdd34880 Allow building rpm without OpenPGP support -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984/files/2a5c0131cc24c803695bd48bff3742446f90a98a..2286b6001d2e3bb09e6efa8a0a02bb0ccdd34880 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] Allow building rpm without OpenPGP support (PR #2984)
This will also need some further tweaks to skip the relevant tests. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2006802381 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] Allow building rpm without OpenPGP support (PR #2984)
@pmatilai commented on this pull request. > @@ -27,8 +27,8 @@ The source for the file utility + library is available from ftp://ftp.astron.com/pub/file/ You will need a cryptographic library to support digests and It gets tricky here because now those two are separated in some of the options. What a crazy tangle :smile: But yeah the language here needs some more love. I also realized the "Use of rpm-sequoia..." paragraph looks odd where it is now - I just moved it a bit earlier without other changes but that doesn't quite cut it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#discussion_r1530083502 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] Allow building rpm without OpenPGP support (PR #2984)
All good points, thanks for the review! As for `pgpVerifySignature[2]()`, I considered returning NOKEY for a softer impact, but the gotcha is that the sanity check in rpmsinfoInit() causes things to fail long before you get to call verify. So while adding a "not at home" lint will of course not hurt anything, chances are nobody actually gets to see it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2006676382 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] Allow building rpm without OpenPGP support (PR #2984)
@nwalfield commented on this pull request.
Looks good to me!
> @@ -38,9 +38,17 @@ in Sequoia. Some other Sequoia advantages include being
> implemented in a
memory-safe language, configurable policy and user-relevant error messages.
For more information, see https://sequoia-pgp.org/
-If using the deprecated internal parser (-DWITH_INTERNAL_OPENPGP=ON),
-the default is libgcrypt, but alternatively OpenSSL can be used by
-additionally specifying -DWITH_OPENSSL=ON.
+However, for bootstrapping purposes it may be desireable to avoid the
+Rust dependency from rpm-sequoia. When building with -DWITH_SEQUOIA=OFF,
+rpm is built with OpenPGP support disabled. That means, you cannot
+sign packages, verify signatures or import keys, but you otherwise
+you can build (and install) packages normally. In this mode, libgcrypt
I think you mean: s/you//
> @@ -38,9 +38,17 @@ in Sequoia. Some other Sequoia advantages include being
> implemented in a
memory-safe language, configurable policy and user-relevant error messages.
For more information, see https://sequoia-pgp.org/
-If using the deprecated internal parser (-DWITH_INTERNAL_OPENPGP=ON),
-the default is libgcrypt, but alternatively OpenSSL can be used by
-additionally specifying -DWITH_OPENSSL=ON.
+However, for bootstrapping purposes it may be desireable to avoid the
+Rust dependency from rpm-sequoia. When building with -DWITH_SEQUOIA=OFF,
+rpm is built with OpenPGP support disabled. That means, you cannot
+sign packages, verify signatures or import keys, but you otherwise
+you can build (and install) packages normally. In this mode, libgcrypt
+is used for crypthographic hash calculations by default, but alternatively
+OpenSSL can be selected by specifying -DWITH_OPENSSL=ON.
+
+Finally, the deprecated internal OpenPGP parser can be enabled with
+-DWITH_INTERNAL_OPENPGP=ON, which libgcrypt/OpenSSL depending on
This is confusing. Perhaps: s/depending/depends/ ? But, I'm not sure.
> @@ -27,8 +27,8 @@ The source for the file utility + library is available from
ftp://ftp.astron.com/pub/file/
You will need a cryptographic library to support digests and
Perhaps: s/cryptographic library/OpenPGP implementation/
> +uint32_t pgpDigParamsCreationTime(pgpDigParams digp)
+{
+return -1;
+}
+
+int pgpPrtParams(const uint8_t * pkts, size_t pktlen, unsigned int pkttype,
+pgpDigParams * ret)
+{
+return -1;
+}
+
+int pgpPrtParams2(const uint8_t * pkts, size_t pktlen, unsigned int pkttype,
+ pgpDigParams * ret, char **lints)
+{
+if (lints)
+*lints = NULL;
Perhaps it makes sense to add a lint saying: "RPM was compiled without OpenPGP
support"
> + pgpDigParams mainkey, pgpDigParams **subkeys,
+ int *subkeysCount)
+{
+return -1;
+}
+
+rpmRC pgpVerifySignature(pgpDigParams key, pgpDigParams sig, DIGEST_CTX
hashctx)
+{
+return RPMRC_NOTFOUND;
+
+}
+
+rpmRC pgpVerifySignature2(pgpDigParams key, pgpDigParams sig, DIGEST_CTX
hashctx, char **lints)
+{
+if (lints)
+*lints = NULL;
Likewise here, one could add a lint saying: "RPM was compiled without OpenPGP
support"
> +return PGPARMOR_NONE;
+}
+
+int pgpPubKeyCertLen(const uint8_t *pkts, size_t pktslen, size_t *certlen)
+{
+return -1;
+}
+
+char * pgpArmorWrap(int atype, const unsigned char * s, size_t ns)
+{
+return NULL;
+}
+
+rpmRC pgpPubKeyLint(const uint8_t *pkts, size_t pktslen, char **explanation)
+{
+*explanation = NULL;
And a lint here might be helpful for users to understand why the operation
fails.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#pullrequestreview-1945700783
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] Allow building rpm without OpenPGP support (PR #2984)
As per the commit message, the intent is to follow-up this with a patch to split the rpmpgp_legacy directory off the rpm main repo entirely, at which point #2414 is achieved while letting others to maintain the code if they so wish. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2006544030 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] Remove the internal OpenPGP parser (Issue #2414)
https://github.com/rpm-software-management/rpm/pull/2984 implements the dummy PGP option. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2006529326 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
[Rpm-maint] [rpm-software-management/rpm] Allow building rpm without OpenPGP support (PR #2984)
For bootstrapping purposes, having rpm depend on Rust is painful, but directing people to unmaintained crypto code as an alternative is hair-raising. As a middle ground, let rpm be built without OpenPGP support at all, which at least gives you a functional rpm and rpm-build even if you cant sign or verify signatures. Achieving this is a moderately complex dance which cant meaningfully be split into multiple commits because everything is interconnected: Add a new WITH_SEQUOIA option to control use of Sequoia, on by default. When Sequoia is disabled, default to a newly added dummy PGP implementation instead which just returns error on everything. And finally, if the older WITH_INTERNAL_OPENPGP is enabled, use the old PGP implementation. As the intent is to cut out rpmpgp_legacy to a separate repository, sanity requires that we also split the openssl/libgcrypt code at the digest/signature fault line. Its not ideal, but the alternative of having unused crypto code on which an external component depends on is just not sustainable. This way, the signature side of things is quite neatly cut off with the PGP stuff. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2984 -- Commit Summary -- * Allow building rpm without OpenPGP support -- File Changes -- M CMakeLists.txt (2) M INSTALL (18) M rpmio/CMakeLists.txt (21) A rpmio/digest_libgcrypt.c (136) A rpmio/digest_openssl.c (171) A rpmio/rpmpgp_dummy.c (114) M rpmio/rpmpgp_legacy/CMakeLists.txt (10) M rpmio/rpmpgp_legacy/digest_libgcrypt.c (109) M rpmio/rpmpgp_legacy/digest_openssl.c (138) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2984.patch https://github.com/rpm-software-management/rpm/pull/2984.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove the internal OpenPGP parser (Issue #2414)
Finally managed to convince myself that it should be feasible (with reasonable amount of work) to have a "nopgp" build option by adding a dummy implementation of the internal PGP interface that just returns -ENOTHOME for everything, and allow choosing between libgcrypt and openssl for the hash functionality using existing code. That way there's a minimal bootstrap option capable of building legitimate rpm packages, without making people choose between Rust or unmaintained security code with known holes. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2006257627 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] rpmsign --delsign leaves behind 0 padding (Issue #2965)
Just FWIW, there's now an in-tree tool for looking at low-level package structure: https://github.com/rpm-software-management/rpm/blob/master/tools/rpmdump.c -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2965#issuecomment-2005946927 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
