> @mlschroe Sadly, Fedora doesn’t sign its metadata.
We don't need to as we use metalinks. In the metalink is the checksum(s) for
the valid repomd.xml file. If someone tampers with the repodata it will not
match and the client will go on to the next one. But thats likely offtopic for
this
There is a middle way how to deal with signatures: Append at the end of the
package. RPM should probably dictate a way how they should be separated. Then
one could just read the last few kB of the package and check for signatures
there without understanding the rpm format at all. You could also
@Conan-Kudo That is fantastic news!
--
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/1482#issuecomment-758096633___
Rpm-maint
@DemiMarie The first steps towards making it possible to do that are being done
now: https://pagure.io/koji/pull-request/2637
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe tell that to the Fedora infrastructure maintainers. They don’t sign
their metadata.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm will have to support the embedded signatures for just about forever more,
but there's no reason rpm couldn't support detached signatures as an
alternative, it's just a piece of OpenPGP data that could come from anywhere if
there was an API for it. But detached signatures aren't any magic
Fast and has a massive security margin. I believe the best known attacks are
on 3 rounds vs 12, and libsodium has a hyper-optimized SIMD implementation it
uses for Argon2.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Why Blake2b?
--
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/1482#issuecomment-757565558___
Rpm-maint mailing list
Some of the advantages of this approach:
- The initial hash covers the entire package, and does not need to be updated
when signatures are added or removed.
- Multiple signatures are automatically supported.
- Signatures are timestamped and can expire.
- Key fingerprints include the algorithm as
That’s understandable. Ideally, this blob would be as simple as possible; the
current signature blob is more complicated than necessary. What about a
Blake2b hash of the lead+header+payload, followed by a list of (length,
timestamp, expiration, Blake2b hash of (algorithm ID||public key), raw
10 matches
Mail list logo
