Ok, thanks for the clarification.
>From my perspective, there is no way to generate a version number for an
>OpenPGP certificate. This is because an OpenPGP certificate is composed of
>packets, and packets can be left out without making the certificate completely
>invalid. This is exactly
@pmatilai, unfortunately, I think you're right. Where should we discuss how to
implement the merge / update operation?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1718855631
You are receiving this because you are
I'd really prefer that we merge the existing certificate with the new
certificate. This is particularly important as gpg strips old self signatures
when exporting certificates. One consequence of replacing an existing
certificate with a new version is that existing packages may not verify
As per
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1719074225
:
> trying to shoehorn the keys into something resembling a package has been a
> major source of headache as long as it's been there. It's just difficult to
> get rid of. Ideally this would all happen in
Make it easy to implement `rpmkeys --list-keys` and `rpmkeys --delete-keys`.
https://github.com/rpm-software-management/rpm/issues/2404#issuecomment-1766034780
--
Reply to this email directly or view it on GitHub:
A couple of thoughts:
- In non-interactive environments, the secret key material should probably
not be made available to the build infrastructure. That means exactly
something like gpg-agent (a daemon that provides a smartcard like interface) is
needed.
- How does rpm figure out what key
I think we need to introduce a new interface.
`rpmkeys` imports keys using [the `doImport`
function](https://github.com/rpm-software-management/rpm/blob/1c98b67911e19a5f92c7fa4492aaa1000a06edad/lib/rpmchecksig.c#L27).
That function looks for ASCII armor blocks, and the uses
It should be possible to import binary certificates, see
https://github.com/rpm-software-management/rpm/issues/2689
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1746177298
You are receiving this because you are
That behavior was inherited from the internal backend. I don't see a reason
not to support raw (not ASCII armored) certificates. We have to make sure
embedded null characters are correctly handled, though. (I need to check the
API).
--
Reply to this email directly or view it on GitHub:
>From the user POV, ideally one wouldn't even need the manual import (think
>something like auto-generated host-specific key on first boot), but that's
>likely too much of a sacrifice from other perspectives.
But only root should have access to that key. That's why I was thinking
> Oh, and part of the this "automation vision" here would be automatically
> generating that "local builds" key so that a person just wanting to build and
> install rpms for their own use basically doesn't need to learn the damnest
> thing about PGP as the first thing. And not finger-memorize
No worries. I figured that after I looked at it, but then I had already looked
at it :D
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2716#issuecomment-1759253541
You are receiving this because you are subscribed to this thread.
I reviewed the change and it looks reasonable to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2716#issuecomment-1759201594
You are receiving this because you are subscribed to this thread.
Message ID:
You've removed types from the public API. Are you sure that is okay?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2717#issuecomment-1759452972
You are receiving this because you are subscribed to this thread.
Message ID:
I support adding an interface for a backend to identify itself. This is useful
for debugging, as you point out.
I'm not so excited about users of librpm changing their behavior based on the
backend's name. If we want to support that (and I'm not convinced that we do),
I'd rather introduce
That sounds good to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2556#issuecomment-1770538607
You are receiving this because you are subscribed to this thread.
Message ID: ___
@pmatilai: I'm not an expert on OpenSSL. [We were recently contacted by the
RedHat Crypto Team](https://gitlab.com/sequoia-pgp/sequoia/-/issues/1054) (cc:
@simo5, @sahanaprasad07) about a similar change, and they offered to help with
the porting and review. I suspect they'll be willing to
If we add new functions to the API, as suggested recently [in this
issue](https://github.com/rpm-software-management/rpm/issues/2689), then the
internal implementation will need to be updated. This will require a versioning
scheme for the API, I think, which would complicate maintenance.
Looks good, thanks for adding this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2346#issuecomment-1697215650
You are receiving this because you are subscribed to this thread.
Message ID:
Hi Florian,
On Tue, 10 May 2022 12:04:52 +0200,
Florian Weimer wrote:
> * Neal H. Walfield:
>
> > There are two major constraints. Because rpm's OpenPGP API is public,
> > it must be preserved until the next soname bump. And, the OpenPGP
> > backend should be pluggabl
Hi libtool devs,
Historically, rpm has included its own OpenPGP implementation. This
implementation is incomplete and buggy, and the maintainers of rpm
have decided that they would like to use a different OpenPGP
implementation.
There are two major constraints. Because rpm's OpenPGP API is
On Tue, 10 May 2022 12:48:23 +0200,
Florian Weimer wrote:
> * Neal H. Walfield:
> > On Tue, 10 May 2022 12:04:52 +0200,
> > Florian Weimer wrote:
> >> * Neal H. Walfield:
> >>
> >> > There are two major constraints. Because rpm's OpenPGP API is publi
(FWIW, I believe the internal OpenPGP implementation is still the default for
4.18.)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2097#issuecomment-1259270356
You are receiving this because you are subscribed to this thread.
Message
Thanks for the clarification.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2097#issuecomment-1259277822
You are receiving this because you are subscribed to this thread.
Message ID: ___
As I understand, 4.19 will have an soname bump so it should be possible to
rework the API (and remove the old API). Or, if that is not sufficient, what
are your concerns?
--
Reply to this email directly or view it on GitHub:
In `pgpPrtParams`, [`rpm-sequoia` checks that there is exactly one signature
packet](https://github.com/rpm-software-management/rpm-sequoia/blob/main/src/lib.rs#L951).
Can you please provide a reproducer for this bug.
--
Reply to this email directly or view it on GitHub:
Can you explain what you are trying to accomplish. Is your claim that an rpm
signature should be exactly one signature package and a literal data packet?
Out of curiosity, how are multiple signatures handled in rpm?
--
Reply to this email directly or view it on GitHub:
FWIW, this appears to be a non-issue for the Sequoia backend:
```
$ LD_LIBRARY_PATH=/tmp/rpm-sequoia/release ./rpmkeys --import
/tmp/bug2124457.asc
$ echo $?
0
```
--
Reply to this email directly or view it on GitHub:
Using v4 OpenPGP keys requires the use of SHA-1. SHA-1 is used to compute the
fingerprint. This is actually safe as the security of the fingerprint relies
on second pre-image resistance (finding a second message with the same hash),
not collision resistance (finding two messages with the same
I also can't reproduce this for the internal backend:
```
$ git describe
rpm-4.18.0-rc1-11-gcef75b3ed
$ ./rpmkeys --import /tmp/bug2124457.asc
$ echo $?
0
```
--
Reply to this email directly or view it on GitHub:
I tested using the Sequoia backend and all of the OpenPGP-related tests pass.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2194#issuecomment-1251889237
You are receiving this because you are subscribed to this thread.
Message ID:
I've just release v1.0 of rpm-sequoia, which includes functionality that 4.18
requires.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2194#issuecomment-1251900217
You are receiving this because you are subscribed to this thread.
Indeed, I think there are worse bugs in the internal parser (e.g., [not being
able to deal with some
subpackets](https://github.com/rpm-software-management/rpm/pull/1813)).
Nevertheless, if we want RPM to deal with such malformed certificates, perhaps
it makes sense to add a unit test, which
The signature for those interested:
```
-BEGIN PGP ARMORED FILE-
wsBcBAABCAAQBQJjwYhxCRAREg9HFOVtyAAA9lAIAEB7pOPwvCex4hzyGq/nDmcn
sm38Ad/cVvUeUwgsM3zzsd4Ft1VBboy0gpldAYx0kwX4Cj2qI/KMpQ6R2DLirhD9
M0G8l9whgX7pMZwnXNqB398eMsphMH2yKInpLoXFTuTffYK9u9ZYc6M9RGXyXZk0
I extracted the signature and looked at it:
```
$ sq packet dump --hex /tmp/blob.pgp
Unknown or Unsupported Packet, new CTB, 3 header bytes + 284 bytes
Tag: Signature Packet
Error: Malformed MPI: leading bit is not set: expected bit 8 to be set in
100 (40)
c2
Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2351#issuecomment-1382232836
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
This issue might be related:
https://github.com/community/community/discussions/27607
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2351#issuecomment-1382254196
You are receiving this because you are subscribed to this thread.
Good point. Where would be a good place to document this?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2346#issuecomment-1379994771
You are receiving this because you are subscribed to this thread.
Message ID:
I think it makes sense to make a list before writing a text. Here's what I've
thought of so far:
- Sequoia reads the crypto policy from
"/etc/crypto-policies/back-ends/sequoia.config;" the internal parser relies on
the crypto backend to do that (OpenSSL does; libgcrypt doesn't)
- Sequoia
This is related to https://pagure.io/fedora-docs/release-notes/issue/892 , I
think.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2346#issuecomment-1380096594
You are receiving this because you are subscribed to this thread.
Message
The basic pattern in Rust is code + description. This allows the caller, in
the rare cases that it needs to, to distinguish different error scenarios,
while also providing details to the end user about what went wrong. In fact,
it is possible to add more information to an error: each caller
I tried building rpm (rpm-4.17.0-alpha-687-g37b963fa5) on a relatively fresh
Fedora 36 machine. I did:
```
[neal@fedora-36 ~]$ git clone g...@github.com:rpm-software-management/rpm.git
Cloning into 'rpm'...
remote: Enumerating objects: 138209, done.
remote: Counting objects: 100% (117/117),
due *to* their
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/commit/32893a5e18347b124c405ba216e4ee89b90088f8#r90855888
You are receiving this because you are subscribed to this thread.
Message ID:
This fails on the sequoia backend:
```
# -*- compilation -*-
281. rpmsigdig.at:605: testing rpmkeys type confusion ...
/rpmsigdig.at:606:
if ! [ -d testing/ ]; then
cp -aP "${RPMTEST}" .
chmod -R u+w testing/
mkdir -p testing/build
ln -s
@nwalfield approved this pull request.
Looks good.
> @@ -168,6 +169,12 @@ static rpmtd makeSigTag(Header sigh, int ishdr, uint8_t
> *pkt, size_t pktlen)
break;
}
+ver = pgpDigParamsVersion(sigp);
+if (ver < 4) {
+ rpmlog(RPMLOG_WARNING, _("Deprecated PGP signature
This (and the other tests) can be changed to AT_CHECK. According to [the
documentation](https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Writing-Testsuites.html)
> The difference between AT_CHECK and AT_CHECK_UNQUOTED is that only the latter
> performs shell variable
I still haven't wrapped my head around the internal pgp parser, so I did not
thoroughly review `pgpPrtParams`. Perhaps @DemiMarie can look at the changes
to that function. Otherwise, I have no issues with this commit.
--
Reply to this email directly or view it on GitHub:
@nwalfield approved this pull request.
Looks good!
```
[neal@fedora-36 _build]$ git describe
rpm-4.17.0-alpha-688-g9f3d9aa8c
[neal@fedora-36 _build]$ make check
...
263: rpmkeys -K verifylevel ok
266: rpmkeys -Kv 1ok
265: rpmkeys -K verifylevel
@nwalfield commented on this pull request.
> @@ -740,9 +770,44 @@ runroot rpmkeys -Kv /tmp/${pkg}
],
[])
AT_CLEANUP
+
+# --
+# Test pre-built corrupted package verification (corrupted header)
Great addition!
--
Reply to this email directly or view it on GitHub:
This appears to work for me, now. Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2269#issuecomment-1328877534
You are receiving this because you are subscribed to this thread.
Message ID:
@dkg explains why v3 signatures are problematic [in this
issue](https://bugzilla.redhat.com/show_bug.cgi?id=2141686#c24):
> The upcoming cryptographic refresh of the OpenPGP standard explicitly says
> that clients MUST NOT generate v3 signatures but MAY verify them. However,
> v3 signatures
I don't think this unrelated issue is the right place to have this discussion.
But, there is an issue pertain exactly to the point that you make:
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130 . If you think that
something is missing, please add it over there so it seen by the relevant
executing
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/commit/55d9f24e6b02d72f2358a5d7cb7ca16127ae7fb7#r91037824
You are receiving this because you are subscribed to this thread.
Message ID:
___
is set up*.* *Y*ou
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/commit/55d9f24e6b02d72f2358a5d7cb7ca16127ae7fb7#r91037856
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai: Yup. My comment was more directed towards @davide125: it would be
good to confirm that this is the bug that I think it is.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2351#issuecomment-1384030140
You are receiving this
@teythoon pointed out that GnuPG does not generate New format CTBs, so this was
likely not generated by GnuPG. This is typical behavior for gocrypt, which is
[documented as not being
Someone looked at this threat and privately asked me to forward their
suggestions:
- rpm-sequoia and sequoia are written in a safe systems programming language
(Rust)
- A focus of Sequoia's development process is on testing, so rpm-sequoia and
sequoia probably have more formal (unit,
> I was hoping this could be reported to go crypto and possibly fix, as reading
> the comment in code felt more like "This break the RFC, but happens to work,
> so let's do it.", but then I stumble on
> [golang/go#44226](https://github.com/golang/go/issues/44226) which deprecates
> go-crypto.
> I was hoping this could be reported to go crypto and possibly fix, as reading
> the comment in code felt more like "This break the RFC, but happens to work,
> so let's do it.", but then I stumble on
> [golang/go#44226](https://github.com/golang/go/issues/44226) which deprecates
> go-crypto.
I get further, but I still get a complaint about lua.h being missing:
```
[ 40%] Building C object lib/CMakeFiles/librpm.dir/rpmscript.c.o
/tmp/rpm/rpm/lib/rpmscript.c:7:10: fatal error: 'lua.h' file not found
#include
^~~
1 error generated.
make[2]: ***
That solves the lua problem for me. make check now fails:
```
...
Built target populate_testing
Built target librpmio
Scanning dependencies of target rpmpgppubkeyfingerprint
Building C object
tests/CMakeFiles/rpmpgppubkeyfingerprint.dir/rpmpgppubkeyfingerprint.c.o
Linking C executable
Note: I'm testing with 40d66336a243093d6d67d1203f511d3831ecbc7a
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2262#issuecomment-1302188743
You are receiving this because you are subscribed to this thread.
Message ID:
I'm splitting [this
comment](https://github.com/rpm-software-management/rpm/issues/2258#issuecomment-1301807221)
into a separate issue.
```
$ make check VERBOSE=1
/usr/bin/cmake -S/home/us/neal/work/pep/rpm -B/home/us/neal/work/pep/rpm/_build
--check-build-system CMakeFiles/Makefile.cmake 0
Thanks for the productive collaboration!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2274#issuecomment-130910
You are receiving this because you are subscribed to this thread.
Message ID:
The rpm test suite (apparently) doesn't have any test vectors that include v3
OpenPGP signatures. This is unfortunate as they are apparently widely used in
the rpm ecosystem. Let's add a test that verifies a v3 signature made by a v4
key, and another test that verifies the digest of a v3
I realize @pmatilai is aware of these, but I wanted to document them.
```
$ git describe
rpm-4.17.0-alpha-659-g40d66336a
$ make check VERBOSE=1
...
## --- ##
## rpm 4.18.90 test suite. ##
## --- ##
1: Running tests for malformed OpenPGP packagesok
I'm trying to build HEAD (5049fc701561b258b722b3400460d8828ce9e64e) with the
sequoia backend, but I'm having trouble.
I documented how I build rpm with the autoconf build system
[here](https://github.com/rpm-software-management/rpm-sequoia#building). In
short:
```
$ mkdir /tmp/rpm
$ cd
While investigating [this
issue](https://github.com/rpm-software-management/rpm-sequoia/issues/20), I
tried to build `rpm` as follows:
```
$ cmake -DENABLE_PYTHON=OFF ..
...
-- Checking for module 'lua'
-- Found lua, version 5.4.2
...
-- Configuring done
-- Generating done
-- Build files have
I tried and got the exactly same result as above. FWIW, I ran the following:
```
$ mkdir _build
$ cd _build
$ cmake -DENABLE_PYTHON=OFF ..
$ make
$ make check
```
--
Reply to this email directly or view it on GitHub:
I'm on Debian bullseye.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2262#issuecomment-1303170504
You are receiving this because you are subscribed to this thread.
Message ID: ___
Here's the complete build log:
[typescript.txt](https://github.com/rpm-software-management/rpm/files/9936918/typescript.txt)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2262#issuecomment-1303176964
You are receiving this because
Thanks for looking into this and thanks for the advice. FWIW, using the
autoconf version all of the OpenPGP-related tests passed on Debian.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2262#issuecomment-1303194782
You are receiving
Closed #2262 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2262#event-7739745611
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
`git reset --hard` plus `git clean -fxd` worked, thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2262#issuecomment-1303272499
You are receiving this because you are subscribed to this thread.
Message ID:
That did the trick, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2269#issuecomment-1308900314
You are receiving this because you are subscribed to this thread.
Message ID: ___
When running the test suite (rpm-4.17.0-alpha-674-ge8e2a121b) using the sequoia
backend, I see the following failure:
```
$ make check
...
281: rpmkeys type confusion FAILED (rpmsigdig.at:631)
...
ERROR: 472 tests were run,
6 failed (5 expected failures).
75 tests were
The test is much too strict. Using the Sequoia backend, this fails as follows:
```
$ ./rpmkeys --import ./tests/testing/data/keys/type-confusion.asc
warning: Certificate 4344591E1964C5FC:
Policy rejects subkey 185E6146F00650F8: No binding signature at time
2022-11-09T15:08:19Z
```
--
Reply
This issue would have been caught if the Sequoia backend were tested in CI.
As per
https://github.com/rpm-software-management/rpm/issues/2065#issuecomment-123774:
> what I'm currently thinking is that once the dust settles a bit, we'll just
> switch the Sequoia to be the default on CI
The `rpmkeys type confusion` test was added in ec13083f46a1e to check that the
internal OpenPGP parser rejects a certificate with an invalid component. The
Sequoia backend happily accepts the certificate and ignores the invalid
component, which causes the test to fail. Mark the test as
With #2274 and
https://github.com/rpm-software-management/rpm/issues/2269#issuecomment-1308825583,
the test is correctly skipped and all of the other tests pass:
```
471 tests behaved as expected.
76 tests were skipped.
Built target check
```
--
Reply to this email directly or view it on
No worries.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2066#issuecomment-1313848972
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
signed:
$ git verify-tag v1.3.0
gpg: Signature made Mon Mar 06 16:54:07 2023 +01:00
gpg:using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield " [ultimate]
gpg: "Neal H. W
I checked the change. It looks good to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2437#issuecomment-1473354634
You are receiving this because you are subscribed to this thread.
Message ID:
@mlschroe : Do you mind sharing your motivation. Does OpenSUSE plan to stick
with the internal OpenPGP implementation?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1474051989
You are receiving this because you are
Thanks for the explanation.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-1476740667
You are receiving this because you are subscribed to this thread.
Message ID: ___
That sounds good.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2127#issuecomment-1482648489
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
@nwalfield commented on this pull request.
> @@ -276,7 +276,18 @@ rpmRC rpmKeyringVerifySig(rpmKeyring keyring,
> pgpDigParams sig, DIGEST_CTX ctx)
pgpkey = key->pgpkey;
/* We call verify even if key not found for a signature sanity check */
- rc =
Add a new function, pgpVerifySignature2. pgpVerifySignature2 is like
pgpVerifySignature, but optionally returns a descriptive error message (in the
case of failure) or a lint (in the case of success).
This requires rpm-sequoia 1.4 or later.
See
Thanks for testing, panu. One thing (and sorry for hijacking this issue), we
decided to have [a dedicated configuration for
rpm-sequoia](https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129#note_1297002360),
which enables 1024 bit DSA and SHA-1. I'm going to add that
OpenPGP (sometimes just abbreviated as PGP, the first OpenPGP implementation
before there was OpenPGP) is an IETF standard. gpg is an implementation of the
OpenPGP standard. Sometimes people call OpenPGP certificates and keys GPG
certificates and keys, because GPG is a well-known
I'll adjust the patch, thanks for the feedback.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2402#issuecomment-1450059606
You are receiving this because you are subscribed to this thread.
Message ID:
@panu: Please take a look at
https://github.com/rpm-software-management/rpm-sequoia/pull/31 and let me know
what you think. In particular, `rpm-sequoia` emits warnings on `stderr`. Is
that reasonable? If not, how should we communicate this to the user.
--
Reply to this email directly or
I added
https://github.com/rpm-software-management/rpm-sequoia/commit/9fd8f7de9e1cf98ff11ec246189488696ca714ea
, which returns `NOTTRUSTED` when a signature verifies using legacy crypto,
but not using the configured policy. I'm not going to make a release until rpm
adopts this. Let me know
Are there scripts out there that parse this output? If so, they will almost
certainly break. Perhaps it would be better to do:
```
warning: google-chrome-stable_current_x86_64.rpm: Header V4 DSA/SHA1 Signature,
key ID 7fac5991, fingerprint: 6A51BBABBA3D5467B6171221809A8D7CEB10B464: NOKEY
```
To be clear: this change returns a different error code *and* prints something
on stderr.
I think the diagnostics would show up when the user directly invokes `rpm`,
which is what the reporter did
[here](https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c0) . I think you
are right that in
See https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c15 for details.
`rpm-sequoia` could easily try to validate a signature using two different
policies
([here](https://github.com/rpm-software-management/rpm-sequoia/blob/main/src/lib.rs#L574)):
the system policy and a legacy policy. If
@davide125 : Thanks for following up and confirming that this was not a bug in
rpm or rpm-sequoia.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2351#issuecomment-1449489387
You are receiving this because you are subscribed to this
@nwalfield pushed 1 commit.
b74ad98bbc773bd0a031788d18e659b62160e570 Add pgpVerifySignature2
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2453/files/5498d2b2b84b66d36978aa6cdeccdc543d2d46e8..b74ad98bbc773bd0a031788d18e659b62160e570
You are receiving this because
This is basically done. (CI is failing, because rpm-sequoia 1.4 is not yet
available.) @pmatilai if you are happy, I'll release rpm-sequoia 1.4.
Otherwise, I'm happy to iterate some more.
--
Reply to this email directly or view it on GitHub:
Here's the documentation for
[pgpParsePkts](https://github.com/rpm-software-management/rpm/blob/457bd287cf84323209e8daebe843c25054f1808e/include/rpm/rpmpgp.h#L1034):
```
/** \ingroup rpmpgp
* Parse armored OpenPGP packets from memory.
* @param armor armored OpenPGP packet string
*
1 - 100 of 151 matches
Mail list logo
