On 11/3/21 14:33, Panu Matilainen wrote:
On 11/3/21 14:26, Panu Matilainen wrote:
On 11/1/21 17:37, Justus Winter wrote:
[...]
But, not every individual program decides to incorporate an OpenPGP
implementation. Most defer this kind of policy to some library that
takes care of sunsetting
On 11/1/21 17:37, Justus Winter wrote:
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:
On Tue, Nov 02, 2021 at 03:47:52PM +0100, Justus Winter wrote:
> My point is the following. If RPM relies on policies enforced by the
> underlying crypto libraries, such as FIPS, and there is no additional
> mechanism in RPM, then RPM is unfortunately not following best practices
> when it comes
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 distros have patches that make the
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 distros have patches that make the crypto libraries read
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://tests.sequoia-pgp.org/rpmsop.html#Detached_Sign-Verify_roundtrip_with_key__Bob___MD5
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 replacement
> for that API that can be enabled
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"
prefix, "pgp"-prefixed functions and types
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"
prefix, "pgp"-prefixed functions and types are hardly used outside of
the PGP
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://tests.sequoia-pgp.org/rpmsop.html#Detached_Sign-Verify_roundtrip_with_key__Bob___MD5
- accepts MD5 signatures !!!
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 Shambles paper.
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 signatures !!!
>> >>
>> >>
On 10/28/21 18:17, Justus Winter wrote:
Panu Matilainen writes:
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
On Thu, Oct 28, 2021 at 05:17:33PM +0200, Justus Winter wrote:
> In my opinion, these signatures should be rejected by RPM. If working
> with nineties material is really a thing, the user should explicitly
> opt-into these unsafe algorithms.
Right. The way we usually do it in rpm is to make it
On Mon, Oct 25, 2021 at 10:42 AM Justus Winter wrote:
>
> 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
>
On 10/27/21 14:41, Justus Winter wrote:
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
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
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
>> >> implementation will improve correctness.
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
> >> implementation will improve correctness. Robust signature verification
> >>
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, which is tricky
>> [0],
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
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
>
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, which is tricky
> [0], [1], [2].
Wait, those links don't
On 10/21/21 18:12, Justus Winter wrote:
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
On Thu, Oct 21, 2021 at 11:19 AM Justus Winter wrote:
>
> 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
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
26 matches
Mail list logo
