On Mon, Mar 27, 2023 at 11:40:05AM +0200, Fabio Valentini wrote:
On Mon, Mar 27, 2023 at 11:23 AM Kamil Paral
<kparal(a)redhat.com> wrote:
>
> On Sat, Mar 25, 2023 at 8:20 AM Neal H. Walfield <neal(a)walfield.org> wrote:
>>
>> Panu wrote
https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 :
>>
>> > To me the key points here are
>> > 1) there's a lot of obsolete/broken crypto out there
>> > 2) we need better error messages
>> >
>> > Properly dealing with 2) needs an API redesign, but we'll try to work
out some sort of bandaid solution.
>>
>> Are better diagnostics sufficient from your point of view, or are you
>> looking for a different solution?
>
>
> I think my question in
https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c125
wasn't really answered, or at least I don't understand the implications.
*putting on both my FESCo and rpm-sequoia package maintainer hats*
The issue which was voted on for blocker status by FESCo ("In order to
unblock, RPM must accept SHA-1 hashes and DSA keys for Fedora 38
(...)") has been resolved.
As far as I can tell, the anydesk case is different. It's not a
problem caused by the new crypto policy - the packages don't use a
SHA-1 signature - but happens because the Sequoia PGP implementation
is stricter about checking signatures for sanity / validity.
If I understand correctly, the packages are signed with a key that
fails validation, so I'm inclined to say "this is not our problem"
(and it also looks like this is an issue that's specific to this
third-party package vendor, in contrast to the original SHA-1 / DSA
issue which affected repositories that are officially endorsed by
Fedora Workstation).
I agree. The scope of the issue is fairly narrow, and the underlying
issue is an invalid signature made by the anydesk maintainers.
We also have a simple command that users can use to work around
the issue.
The way that this is handled by rpm/dnf can be improved, but
we shouldn't block the release on this, and we should also track
this in #2170878, it is long enough already.
Zbyszek