Hello,
I'd like to propose to replace RPM's built-in PGP support with Sequoia.
Sequoia is an OpenPGP implementation written in Rust. We have released
Sequoia 1.5 earlier this week, which is the first version released under
the LGPL2+.
Our low-level crate, sequoia-openpgp, features an
Michael Schroeder writes:
> On Mon, Nov 01, 2021 at 04:37:21PM +0100, Justus Winter wrote:
>> Pointing to openssl or gcrypt doesn't really fly. gcrypt and openssl
>> (at least the interface that RPM uses) are providing mechanisms without
>> policy.
>
> Most dis
@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);
+
Michael Schroeder writes:
> On Mon, Oct 25, 2021 at 05:32:38PM +0200, Justus Winter wrote:
>> Michael Schroeder writes:
>>
>> > On 10/21/21 18:12, Justus Winter wrote:
>> >> First, I think replacing RPM's point solution with a general purpose
>>
Panu Matilainen writes:
> The missing big item on this laundry-list is bootstrapping. Rpm is
> needed very early on when bootstrapping a distro and people do not want
> to deal with something like Rust in there. Gcc learning Rust would/will
> change that somewhat of course, but gcc is not the
Michael Schroeder writes:
> On 10/21/21 18:12, Justus Winter wrote:
>> First, I think replacing RPM's point solution with a general purpose
>> implementation will improve correctness. Robust signature verification
>> requires canonicalization of the issuing certificate,
Neal Gompa writes:
> What about DNF? The DNF package manager also uses gpgme right now, and
> one of the larger problems we have right now is that we have no
> unified keyring between DNF and RPM, because RPM doesn't have an API
> to manipulate it. If we were to adopt Sequoia as an optional
>
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 i
Neal Gompa writes:
> On Thu, Oct 28, 2021 at 11:17 AM Justus Winter wrote:
>>
>> Panu Matilainen writes:
>>
>> >> https://tests.sequoia-pgp.org/rpmsop.html#Detached_Sign-Verify_roundtrip_with_key__Bob___MD5
>> >>
>> >> - accepts MD5
Panu Matilainen writes:
> On 10/25/21 18:06, Justus Winter wrote:
>> Panu Matilainen writes:
>>>> I have also skimmed RPM's code. From what I can tell, the relevant code
>>>> is in rpmio/{rpmpgp,rpmkeyring,digest}*, the public API uses the "rpm"
>
Justus Winter writes:
>>>>> Looking at the task for roughly an hour or so (so, take it with a grain
>>>>> of salt...), my strategy would be to decouple the current implementation
>>>>> by clearly defining the public API, then provide a drop-in repla
Justus Winter writes:
> Even though second preimage attacks on these two hash functions are
> still very expensive, the shattered paper demonstrates that hash
> collisions are enough to re-purpose an OpenPGP signature.
>
> https://shattered.io/
Sorry, I meant the SHA-1 is a
Panu Matilainen writes:
> On 11/1/21 14:07, Justus Winter wrote:
>> Neal Gompa writes:
>>
>>> On Thu, Oct 28, 2021 at 11:17 AM Justus Winter
>>> wrote:
>>>>
>>>> Panu Matilainen writes:
>>>>
>>>>>> https
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
@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:
15 matches
Mail list logo
