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
Based on the number of new crypto related issues folks are running into on
Fedora, maybe we should consider some emergency bandaid for better error
messages.
Such as simply a new pgpVerifySignature() variant which has an additional `char
**emsg` argument to return a message from the lower
Deleted unrelated discussion. The deleted comments are still viewable at
https://lists.rpm.org/pipermail/rpm-maint/2022-November/022244.html of course.
I'd much rather have just moved the comments to a new discussion but GH lacks
any sort of moderation tools.
So folks please: open a new
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
@nwalfield: That is fine. That said, please understand that v5 signatures need
to be changed to be unambiguous with v3 signatures, since v3 signatures cannot
be unconditionally rejected.
--
Reply to this email directly or view it on GitHub:
@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
@nwalfield: why are v3 signatures considered insecure? IIRC they are still
used to sign RPM packages.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2127#issuecomment-1320628908
You are receiving this because you are subscribed to
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 think we'll need to let the backend return an error messages instead of
trying to turn them into codes, eg Sequoia will know a thousand different
issues the internal parser (and we) never even heard of.
--
Reply to this email directly or view it on GitHub:
