Re: [Rpm-maint] [rpm-software-management/rpm] Update OCaml requires/provides to ignore cmxs (PR #1814)
#913 was merged into 4.16 and 4.17. I think this fix should be backported to these branches. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1814#issuecomment-953019967___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Update OCaml requires/provides to ignore cmxs (PR #1814)
OCaml cmxs files are static libraries, which can be loaded at runtime via the Dynlink module. They apparently do not provide any useful runtime dependency information to be stored into the packages Provides/Requires list. Therefore just skip them. Adjust attr, remove extension and ELF magic Adjust ocamldeps, do nothing with cmxs files. Fixes: a6fe37c39b39acbcbd014dd1e6d5653ff84254a1 Signed-off-by: Olaf Hering o...@aepfle.de You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1814 -- Commit Summary -- * https://github.com/rpm-software-management/rpm/pull/1814/commits/5b8742b2aa25c98ad587abb85e4a73e30615399c;>Update OCaml requires/provides to ignore cmxs -- File Changes -- M fileattrs/ocaml.attr (4) M scripts/ocamldeps.sh (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1814.patch https://github.com/rpm-software-management/rpm/pull/1814.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1814 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Justus/openpgp fixes (PR #1813)
@teythoon commented on this pull request.
> @@ -503,6 +500,9 @@ static int pgpPrtSubType(const uint8_t *h, size_t hlen,
> pgpSigType sigtype,
case PGPSUBTYPE_REVOKE_REASON:
case PGPSUBTYPE_FEATURES:
case PGPSUBTYPE_EMBEDDED_SIG:
+ pgpPrtHex("", p+1, plen-1);
+ break;
+ case PGPSUBTYPE_NOTATION:
The difference is that you made an conscious decision to ignore a subpacket
like the features subpacket, whereas you did not make a conscious decision to
ignore the notation with the name "something-import...@example.org".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1813#discussion_r737562867___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Justus/openpgp fixes (PR #1813)
@DemiMarie commented on this pull request.
> @@ -503,6 +500,9 @@ static int pgpPrtSubType(const uint8_t *h, size_t hlen,
> pgpSigType sigtype,
case PGPSUBTYPE_REVOKE_REASON:
case PGPSUBTYPE_FEATURES:
case PGPSUBTYPE_EMBEDDED_SIG:
+ pgpPrtHex("", p+1, plen-1);
+ break;
+ case PGPSUBTYPE_NOTATION:
PGPSUBTYPE_NOTATION is definitely not recognized unless the notation name is
recognized.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1813#discussion_r737527899___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Justus/openpgp fixes (PR #1813)
@pmatilai commented on this pull request.
> @@ -503,6 +500,9 @@ static int pgpPrtSubType(const uint8_t *h, size_t hlen,
> pgpSigType sigtype,
case PGPSUBTYPE_REVOKE_REASON:
case PGPSUBTYPE_FEATURES:
case PGPSUBTYPE_EMBEDDED_SIG:
+ pgpPrtHex("", p+1, plen-1);
+ break;
+ case PGPSUBTYPE_NOTATION:
I fail to see how notations are any different from all the other stuff in the
above that we don't handle. I mean, if "recognizing" is a matter of being in a
switch-case then PGPSUBTYPE_NOTATION is just as "recognized" as, say,
PGPSUBTYPE_REVOKE_KEY. And if not, then most of these should be in the "not
recognized" category, which is basically what my "implemented" flag did.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1813#pullrequestreview-790700598___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Justus/openpgp fixes (PR #1813)
@teythoon pushed 1 commit. 1780fbe2286b309f8bdc24728731f2e28603 Fix handling of signature notations -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1813/files/d70ee8e68871281664d8b0edfbdc511ad6947fcf..1780fbe2286b309f8bdc24728731f2e28603 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Justus/openpgp fixes (PR #1813)
@mlschroe commented on this pull request. > @@ -422,8 +422,6 @@ static int pgpVerifySigEDDSA(pgpDigAlg pgpkey, pgpDigAlg > pgpsig, uint8_t *hash, return rc; if (pgpkey->curve != PGPCURVE_ED25519) return rc; -if (hash_algo != PGPHASHALGO_SHA256) - return rc; I think the check was from a time where we used a different way to set up the sexp, and we just forgot to remove it. Thanks for spotting this. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1813#pullrequestreview-790417240___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Axe defunct Lua rex extension (PR #1797)
Merged #1797 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1797#event-5526192081___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Axe defunct Lua rex extension (PR #1797)
Very well then :coffin: (how come the emojis are always missing just the thing I want: scythe, grim reaper, chainsaw... it's not that much to ask is it?) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1797#issuecomment-952737001___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Axe defunct Lua rex extension (PR #1797)
No objections from my side. Take it out into the back garden and end its suffering... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1797#issuecomment-952729339___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Justus/openpgp fixes (PR #1813)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1813 -- Commit Summary -- * https://github.com/rpm-software-management/rpm/pull/1813/commits/5d7965a23779321ba2e8820e1859507f03e0e152;>Fix signature subpacket type handling * https://github.com/rpm-software-management/rpm/pull/1813/commits/7c261daabb14299c53e5f6ad966ece6d9e398f4a;>Fix handling of critical signature subpackets * https://github.com/rpm-software-management/rpm/pull/1813/commits/0d83d29ba824e4f2d8ef7f3073327d5f2253f7c0;>Fix hashlen overflow * https://github.com/rpm-software-management/rpm/pull/1813/commits/73a3eddbb22f559f6e1ecd85331b6f28e9045ef2;>Fix typo * https://github.com/rpm-software-management/rpm/pull/1813/commits/d70ee8e68871281664d8b0edfbdc511ad6947fcf;>Fix Ed25519 signature verification using libgcrypt -- File Changes -- M rpmio/digest.h (2) M rpmio/digest_libgcrypt.c (2) M rpmio/rpmkeyring.h (2) M rpmio/rpmpgp.c (11) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1813.patch https://github.com/rpm-software-management/rpm/pull/1813.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1813 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Axe defunct Lua rex extension (PR #1797)
@mlschroe - thoughts, opinions? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1797#issuecomment-952690200___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use lua_replace instead of lua_rotate (PR #1811)
Yeah these details were forgotten so many times that I seem to have learned something from it :laughing: Thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1811#issuecomment-952689357___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use lua_replace instead of lua_rotate (PR #1811)
Merged #1811 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1811#event-5525871712___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Porting RPM to Sequoia PGP
Justus Winter writes: > Panu Matilainen writes: > >> Decoupling the implementation from the API would be beneficial to rpm in >> any case because >> a) it'd also enable implementing support for other libraries as well (eg >> RNP which is much closer in language family) and as long as the internal >> implementation is preserved, bootstrapping with minimal dependencies. >> b) doing so tends to have a positive impact on codebase >> c) having someone experienced with OpenPGP do it, the resulting API may >> even make some sense... >> >> So while I'm not at all eager to gain a Rust dependency and there'll be >> somewhat more (not less) code to maintain, but as per the plan above I >> think this sounds like a net positive for us. Always assuming somebody >> is willing to do the work that is. > > Great. I'll give it a try and will likely come back with questions in > the process. To get familiar with the code and interface, I wrote a SOP implementation on top of RPM's OpenPGP implementation. https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-03.html It only verifies signatures, of course. Nevertheless, I was then able to plug it into our interoperability test suite, and it turned up interesting results. See below. In the process, I had to fix a few issues in the implementation to get it to a point where it was able to verify a signature made by Sequoia PGP using a key created by Sequoia. https://github.com/rpm-software-management/rpm/pull/1813 It seems to me that it is not only a point solution to verify signatures, but it has been written around the material that GnuPG creates rather than being a first-principles implementation. That is unfortunate for a number of reasons. First, it leads to a rather brittle implementation. Second, it prevents users of RPM from transitioning to a different PGP implementation. Finally, it even prevents GnuPG from ever evolving. Regarding the interface, I was surprised how low-level it was. Not only is that hard to use, but it also leaks implementation and OpenPGP details to the call sites. Ideally, there should be one function that given a set of certificates, a signature, and the data should return whether the data could be authenticated. Plus a couple of functions for diagnostics and miscellaneous stuff. If I were to add a second backend, I'd first rework the interface to be considerably more high-level. Here are the interoperability test suite results. Note that many tests simply fail for rpmsop because it doesn't do encryption: https://tests.sequoia-pgp.org/rpmsop.html These are my notes interpreting the results. !!! marks security problems: https://tests.sequoia-pgp.org/rpmsop.html#Detached_signature_with_Subpackets - issuer fingerprint handling would be nice - signatures with multiple issuers not well supported - invalid signatures with missing or unhashed creation time are considered valid - signatures with future creation time are considered valid https://tests.sequoia-pgp.org/rpmsop.html#Detached_signatures__Linebreak_normalization - text mode line ending normalization is broken (or not implemented) https://tests.sequoia-pgp.org/rpmsop.html#Detached_signatures_with_unknown_packets - unknown signature versions should be ignored https://tests.sequoia-pgp.org/rpmsop.html#Detached_Sign-Verify_roundtrip_with_key__Bob___MD5 - accepts MD5 signatures !!! https://tests.sequoia-pgp.org/rpmsop.html#Signature_over_the_shattered_collision - accepts SHA1 signatures !!! https://tests.sequoia-pgp.org/rpmsop.html#Primary_key_binding_signatures - accepts signing-capable subkeys without primary key binding signature !!! https://tests.sequoia-pgp.org/rpmsop.html#Key_Flags_Composition - accepts signatures made by encryption subkeys !!! https://tests.sequoia-pgp.org/rpmsop.html#Temporary_validity - pays no attention to timestamps and relations between cert and signature !!! https://tests.sequoia-pgp.org/rpmsop.html#Marker_Packet - marker packets must be ignored https://tests.sequoia-pgp.org/rpmsop.html#Mangled_ASCII_Armored_Signatures - ASCII armor parser is very brittle The tests don't reflect that, but I saw that ECDSA is not supported. AIUI that means that in FIPS mode, only RSA signatures can be used. I also looked at the fix for CVE-2021-3521. It adds code that does what I'd call partial certificate canonicalization. There are some crucial steps missing, like reasoning about key metadata (at least keyflags) and checking primary key binding signatures. Also, the code rejects some conforming certificates, like certs with an encryption-capable, non-RSA subkey followed by an signing-capable subkey. I'm also worried that the test vectors added in that commit are somewhat misleading, at least the names don't match exactly what is in them: CVE-2021-3521-badbind.asc: Sounds like it has a bad binding signature, but infact the binding signature is missing. CVE-2021-3521-nosubsig.asc: Sounds like the subkey binding
