Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2021-01-22 Thread Panu Matilainen
This has drifted really far from the original topic which was addressed in 
commit ee5dd3ccb9fe084251f4c0195907a04a4bdc77e7, different parsers and whatnot 
are an entirely different matter.

-- 
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/issues/1306#issuecomment-765400620___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2021-01-22 Thread Panu Matilainen
Closed #1306.

-- 
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/issues/1306#event-4238581087___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2021-01-07 Thread Panu Matilainen
Hmm, using Lua for these kind of tasks is an interesting idea.

Lua is a kind of strange programming language coming from something else, but 
its spartan design is actually a thing of beauty if you spend sufficient time 
to "get it". It's also plenty fast as far as scripting languages go, I've seen 
quite extensive use in several projects and *that* was never an issue of any 
kind. Plus it has built in support for sandboxing and all.

Of course, there's unlikely any OpenPGP library for it, and we'd still need to 
expose the data through C APIs but... yeah, it's an interesting idea.

-- 
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/issues/1306#issuecomment-756034106___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2021-01-06 Thread KOLANICH
1. Lua is a terrible choice of a programming language IMHO (at least dealing 
with encodings in it used to be nightmare, though IDK how is it now). Some 
embedded JS engine may be better.
2. If to implement something in lua, one can ask why not to implement 
everything in lua? Replacing a C++ parser with Lua one opens a can of worms in 
the sense of thinking about which can and which cannot.
3. Kaitai Struct may be helpful if you wanna write a parser in lua (or in C++, 
JS, or Rust). Disclaimer: I'm involved into this project. Parsers generated by 
it are considered to be memory safe (in the sense they are gejerated 
au6omatically, not handcodedby humans, but I am not very sure in it since I 
don't remember any audit, I feel like integer overflows can be the main source 
of memory unsafety).


-- 
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/issues/1306#issuecomment-755709738___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2021-01-06 Thread Demi Marie Obenour
@Conan-Kudo good point on optional dependencies.

That said, if we are going to make Lua mandatory, could we use it for the PGP 
packet parser?  Lua is de-facto memory safe, so the risk of nasty security 
vulnerabilities is far lower, and performance should not matter for this 
application.  And since it is always available, we don’t need a fallback path.

-- 
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/issues/1306#issuecomment-755654843___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread ニール・ゴンパ
> > That probably provides no material benefit for us. IRIX, AIX, and other 
> > Unix-types are supported by community contributors. OS/2 support is 
> > maintained _mostly_ out of tree, but we don't need to make their lives 
> > considerably harder if we don't have to.
> 
> It wouldn’t be a regression, either.

It would, however, be a burden. Maintaining multiple codepaths for this stuff 
is complicated, and in practice, one gets untested. We're looking at making Lua 
mandatory, because in practice, RPM is used everywhere _with_ Lua enabled and 
there is basically no way for a Linux system to function without RPM using Lua.

Having an "optional" dependency that is sometimes used and sometimes not is 
worse, because now we _need_ to make parity for both. We are still on the hook 
for the internal PGP code, _and_ we're on the hook for the functioning 
dependency. That's pretty miserable for us. We have this problem with the 
database and crypto backends and we're trying to cut them down to a reasonable 
subset of options.

-- 
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/issues/1306#issuecomment-751405252___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread Demi Marie Obenour
> That probably provides no material benefit for us. IRIX, AIX, and other 
> Unix-types are supported by community contributors. OS/2 support is 
> maintained _mostly_ out of tree, but we don't need to make their lives 
> considerably harder if we don't have to.

It wouldn’t be a regression, either.

-- 
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/issues/1306#issuecomment-751398828___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread ニール・ゴンパ
> > > > > > > > Yes, this is a known - or not so well known - limitation. As 
> > > > > > > > the signature check is basically done by hand it lack a lot of 
> > > > > > > > feature one would expect of GPG proper.
> > > > > > > 
> > > > > > > 
> > > > > > > Can we (as an option) use a third-party library, such as 
> > > > > > > [rpgp](/rpgp/rpgp)?
> > > > > > 
> > > > > > 
> > > > > > Rust is not acceptable due to its weak portability.
> > > > > 
> > > > > 
> > > > > Writing a full PGP packet parser in C is too risky, IMO. GPG itself 
> > > > > had a buffer overflow not too long ago. We can always detect at 
> > > > > compile-time if the Rust library is available, and fall back to the 
> > > > > built-in parser if it is not.
> > > > 
> > > > 
> > > > The issue is that RPM has to work on _everything_. RPM is used on 
> > > > Linux, Windows (!!!), OS/2 (!), AIX, IRIX, macOS, and so on. 
> > > > Several of these platforms cannot use Rust or will never get Rust ports.
> > > 
> > > 
> > > I had not thought of that. Does LLVM support all of those platforms? If 
> > > so, a `#[no_std]` build of rpgp (that is, one that doesn’t use the 
> > > standard library) should work on them.
> > 
> > 
> > It does not. Most of them will likely never receive an LLVM port, because 
> > they're not considered important enough to receive it, and GCC already 
> > exists. This is one of the unfortunate downsides to Rust being an 
> > underspecified language that cannot support multiple conforming 
> > implementations.
> 
> At the very least, we can use a Rust library on the platforms that support it 
> (most of the important ones) and use our built-in implementation on the 
> others. We should also consider dropping IRIX and probably OS/2 support, as 
> both have been discontinued.
> 

That probably provides no material benefit for us. IRIX, AIX, and other 
Unix-types are supported by community contributors. OS/2 support is maintained 
_mostly_ out of tree, but we don't need to make their lives considerably harder 
if we don't have to.

-- 
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/issues/1306#issuecomment-751387145___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread Demi Marie Obenour
> > > > > > > Yes, this is a known - or not so well known - limitation. As the 
> > > > > > > signature check is basically done by hand it lack a lot of 
> > > > > > > feature one would expect of GPG proper.
> > > > > > 
> > > > > > 
> > > > > > Can we (as an option) use a third-party library, such as 
> > > > > > [rpgp](/rpgp/rpgp)?
> > > > > 
> > > > > 
> > > > > Rust is not acceptable due to its weak portability.
> > > > 
> > > > 
> > > > Writing a full PGP packet parser in C is too risky, IMO. GPG itself had 
> > > > a buffer overflow not too long ago. We can always detect at 
> > > > compile-time if the Rust library is available, and fall back to the 
> > > > built-in parser if it is not.
> > > 
> > > 
> > > The issue is that RPM has to work on _everything_. RPM is used on Linux, 
> > > Windows (!!!), OS/2 (!), AIX, IRIX, macOS, and so on. Several of 
> > > these platforms cannot use Rust or will never get Rust ports.
> > 
> > 
> > I had not thought of that. Does LLVM support all of those platforms? If so, 
> > a `#[no_std]` build of rpgp (that is, one that doesn’t use the standard 
> > library) should work on them.
> 
> It does not. Most of them will likely never receive an LLVM port, because 
> they're not considered important enough to receive it, and GCC already 
> exists. This is one of the unfortunate downsides to Rust being an 
> underspecified language that cannot support multiple conforming 
> implementations.

At the very least, we can use a Rust library on the platforms that support it 
(most of the important ones) and use our built-in implementation on the others. 
 We should also consider dropping IRIX and probably OS/2 support, as both have 
been discontinued.

> > > > That said, there are C libraries that we can use instead, such as the 
> > > > one used by Thunderbird.
> > > 
> > > 
> > > I think good C libraries for GPG would actually be really helpful, since 
> > > we could use it throughout the RPM package management stack then. Relying 
> > > on GnuPG causes major issues, especially in containers and offline 
> > > provisioning cases.
> > 
> > 
> > We still need to be able to call an external GnuPG program for signing, 
> > since I doubt any of the libraries will get smartcard support.
> 
> Ugh, I always forget about smartcards...

Fortunately, signing is the least worrisome part of this.  It operates on 
trusted data and doesn’t involve parsing.

-- 
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/issues/1306#issuecomment-751385895___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread ニール・ゴンパ
> > @DemiMarie, is there any reason to use your lib instead of sequoia?
> 
> Sequoia is GPL; not sure if this is a problem. I have no affiliation with 
> rpgp; it is merely a Rust library I came across.

This is a problem, librpm is LGPL and we'd like to maintain that.

-- 
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/issues/1306#issuecomment-751381721___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread ニール・ゴンパ
> > > > > > Yes, this is a known - or not so well known - limitation. As the 
> > > > > > signature check is basically done by hand it lack a lot of feature 
> > > > > > one would expect of GPG proper.
> > > > > 
> > > > > 
> > > > > Can we (as an option) use a third-party library, such as 
> > > > > [rpgp](/rpgp/rpgp)?
> > > > 
> > > > 
> > > > Rust is not acceptable due to its weak portability.
> > > 
> > > 
> > > Writing a full PGP packet parser in C is too risky, IMO. GPG itself had a 
> > > buffer overflow not too long ago. We can always detect at compile-time if 
> > > the Rust library is available, and fall back to the built-in parser if it 
> > > is not.
> > 
> > 
> > The issue is that RPM has to work on _everything_. RPM is used on Linux, 
> > Windows (!!!), OS/2 (!), AIX, IRIX, macOS, and so on. Several of these 
> > platforms cannot use Rust or will never get Rust ports.
> 
> I had not thought of that. Does LLVM support all of those platforms? If so, a 
> `#[no_std]` build of rpgp (that is, one that doesn’t use the standard 
> library) should work on them.
> 

It does not. Most of them will likely never receive an LLVM port, because 
they're not considered important enough to receive it, and GCC already exists. 
This is one of the unfortunate downsides to Rust being an underspecified 
language that cannot support multiple conforming implementations.

> > > That said, there are C libraries that we can use instead, such as the one 
> > > used by Thunderbird.
> > 
> > 
> > I think good C libraries for GPG would actually be really helpful, since we 
> > could use it throughout the RPM package management stack then. Relying on 
> > GnuPG causes major issues, especially in containers and offline 
> > provisioning cases.
> 
> We still need to be able to call an external GnuPG program for signing, since 
> I doubt any of the libraries will get smartcard support.

Ugh, I always forget about smartcards...

-- 
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/issues/1306#issuecomment-751381675___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread Demi Marie Obenour
> > > > > Yes, this is a known - or not so well known - limitation. As the 
> > > > > signature check is basically done by hand it lack a lot of feature 
> > > > > one would expect of GPG proper.
> > > > 
> > > > 
> > > > Can we (as an option) use a third-party library, such as 
> > > > [rpgp](/rpgp/rpgp)?
> > > 
> > > 
> > > Rust is not acceptable due to its weak portability.
> > 
> > 
> > Writing a full PGP packet parser in C is too risky, IMO. GPG itself had a 
> > buffer overflow not too long ago. We can always detect at compile-time if 
> > the Rust library is available, and fall back to the built-in parser if it 
> > is not.
> 
> The issue is that RPM has to work on _everything_. RPM is used on Linux, 
> Windows (!!!), OS/2 (!), AIX, IRIX, macOS, and so on. Several of these 
> platforms cannot use Rust or will never get Rust ports.

I had not thought of that.  Does LLVM support all of those platforms?  If so, a 
`#[no_std]` build of rpgp (that is, one that doesn’t use the standard library) 
should work on them.

> > That said, there are C libraries that we can use instead, such as the one 
> > used by Thunderbird.
> 
> I think good C libraries for GPG would actually be really helpful, since we 
> could use it throughout the RPM package management stack then. Relying on 
> GnuPG causes major issues, especially in containers and offline provisioning 
> cases.

We still need to be able to call an external GnuPG program for signing, since I 
doubt any of the libraries will get smartcard support.

-- 
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/issues/1306#issuecomment-751379645___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread Demi Marie Obenour
> @DemiMarie, is there any reason to use your lib instead of sequoia?

Sequoia is GPL; not sure if this is a problem.  I have no affiliation with 
rpgp; it is merely a Rust library I came across.


-- 
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/issues/1306#issuecomment-751378910___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread ニール・ゴンパ
> > > > Yes, this is a known - or not so well known - limitation. As the 
> > > > signature check is basically done by hand it lack a lot of feature one 
> > > > would expect of GPG proper.
> > > 
> > > 
> > > Can we (as an option) use a third-party library, such as 
> > > [rpgp](/rpgp/rpgp)?
> > 
> > 
> > Rust is not acceptable due to its weak portability.
> 
> Writing a full PGP packet parser in C is too risky, IMO. GPG itself had a 
> buffer overflow not too long ago. We can always detect at compile-time if the 
> Rust library is available, and fall back to the built-in parser if it is not.

The issue is that RPM has to work on _everything_. RPM is used on Linux, 
Windows (!!!), OS/2 (!), AIX, IRIX, macOS, and so on. Several of these 
platforms cannot use Rust or will never get Rust ports.

> That said, there are C libraries that we can use instead, such as the one 
> used by Thunderbird.

I think good C libraries for GPG would actually be really helpful, since we 
could use it throughout the RPM package management stack then. Relying on GnuPG 
causes major issues, especially in containers and offline provisioning cases.

-- 
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/issues/1306#issuecomment-751335604___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread KOLANICH
@DemiMari, is there any reason to use your lib instead of sequoia?

>We can always detect at compile-time if the Rust library is available, and 
>fall back to the built-in parser if it is not.

In runtime. By creating an abstraction layer, detecting the available libs and 
then prioritizing more secure OpenPGP impls over less secure. I have something 
like that for python (but curently it doesn't prioritize).

-- 
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/issues/1306#issuecomment-751317806___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread Demi Marie Obenour
> > > Yes, this is a known - or not so well known - limitation. As the 
> > > signature check is basically done by hand it lack a lot of feature one 
> > > would expect of GPG proper.
> > 
> > 
> > Can we (as an option) use a third-party library, such as [rpgp](/rpgp/rpgp)?
> 
> Rust is not acceptable due to its weak portability.

Writing a full PGP packet parser in C is too risky, IMO.  GPG itself had a 
buffer overflow not too long ago.  We can always detect at compile-time if the 
Rust library is available, and fall back to the built-in parser if it is not.

-- 
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/issues/1306#issuecomment-751317064___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-26 Thread Demi Marie Obenour
That said, there are C libraries that we can use instead, such as the one used 
by Thunderbird.

-- 
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/issues/1306#issuecomment-751317090___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-25 Thread ニール・ゴンパ
> > Yes, this is a known - or not so well known - limitation. As the signature 
> > check is basically done by hand it lack a lot of feature one would expect 
> > of GPG proper.
> 
> Can we (as an option) use a third-party library, such as [rpgp](/rpgp/rpgp)?

Rust is not acceptable due to its weak portability.

-- 
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/issues/1306#issuecomment-751311089___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-12-24 Thread Demi Marie Obenour
> Yes, this is a known - or not so well known - limitation. As the signature 
> check is basically done by hand it lack a lot of feature one would expect of 
> GPG proper.

Can we (as an option) use a third-party library, such as [rpgp](/rpgp/rpgp)?

-- 
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/issues/1306#issuecomment-751159363___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-07-10 Thread Michael Schroeder
I guess it can't deal with the ECDSA and EdDSA signatures.

-- 
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/issues/1306#issuecomment-656772125___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-07-10 Thread KOLANICH
Supporting signatures (being able to read and process them) and non breaking in 
their presence, by just ignoring them, are very different things.

-- 
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/issues/1306#issuecomment-656706547___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-07-10 Thread Florian Festi
Yes, this is a known - or not so well known - limitation. As the signature 
check is basically done by hand it lack a lot of feature one would expect of 
GPG proper.

-- 
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/issues/1306#issuecomment-656698903___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint