@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
@pmatilai pushed 1 commit.
32893a5e18347b124c405ba216e4ee89b90088f8 Drop subkey support from the internal
OpenPGP parser
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2281/files/954a11e05e5faaeb943aff9c4fe0d4dff3ed624f..32893a5e18347b124c405ba216e4ee89b90088f8
You
@pmatilai pushed 1 commit.
954a11e05e5faaeb943aff9c4fe0d4dff3ed624f Drop subkey support from the internal
OpenPGP parser
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2281/files/8ea3dd3ea6410a08e25a1a7ebb2f6456f744a506..954a11e05e5faaeb943aff9c4fe0d4dff3ed624f
You
@pmatilai pushed 1 commit.
8ea3dd3ea6410a08e25a1a7ebb2f6456f744a506 Drop subkey support from the internal
OpenPGP parser
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2281/files/ca7503427569aa0bf304c28d60e84649237feaed..8ea3dd3ea6410a08e25a1a7ebb2f6456f744a506
You
@nwalfield and @DemiMarie if you have time to check this over I'd appreciate.
I haven't gone through it all in any sort of detail, this is just a simple
chainsaw of the obvious subkey parts, there's probably more that we can
simplify.
--
Reply to this email directly or view it on GitHub:
The world of OpenPGP subkeys is scarily complicated and were failing at it
in too many ways to count. People who need the complexity of a full
implementation can use the Sequoia backend, meanwhile this tames the internal
parser back to something we may be able to support.
Fixes: #2278
You can
Merged #2279 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2279#event-7842521899
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
It's not a great example. But all we have for now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2280#issuecomment-1319817181
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2280 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2280#event-7842406498
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2280
-- Commit Summary --
* document example of dynamic spec
-- File Changes --
M docs/manual/dynamic_specs.md (3)
-- Patch Links --
Silence silly warnings from missing utilities whose location is generally
well-known, restore compile warnings to the level it was with autotools build.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2279
-- Commit Summary
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:
Closed #2097.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2097#event-7841427321
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Okay, adding an errno abuse hack (which I suggested, yes) to just one of our
backends, a backend that will be considered deprecated in 4.19 anyway... it
doesn't make sense really.
We'll need something that can apply to all our backends, and that something
needs to have a sane means of returning
As mentioned in
https://github.com/rpm-software-management/rpm/pull/1993#issuecomment-1319665652,
we can't pull the plug on the internal parser yet. But in order to keep the
patient (that is, ourselves) alive through this, we need to [saw off the bad
limb](#2278), now. As in, for 4.19.
--
Closed #1993.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1993#event-7841252094
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
After way too much procrastinating and indecision...
We wont be able to axe the internal parser in 4.19, dunno about 4.20. But
that's a long way off, and until then we need to support what we ship. To avoid
having to pile this complexity on and on and on to deal with subkey this and
subkey
18 matches
Mail list logo
