On 10/13/22 17:31, Neal Gompa wrote:
On Thu, Oct 13, 2022 at 9:58 AM Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Neal Gompa wrote:
No, because when you do things like mirror repositories (especially
for private mirrors), that signature is the only way to verify the
integrity. HTTPS is only transport encryption from a particular
connection.
HTTPS protects against a MITM on the connection introducing invalid
repository contents, which I would assume to be the biggest threat here. But
sure, it by design does not guarantee that the data on the remote end is
valid to begin with.
Also, a ton of Fedora mirrors still don't use HTTPS for various reasons.
I would say that those mirrors ought to be kicked out of the mirror list
immediately.
With Let's Encrypt having been available for years, there is really no
excuse for not offering HTTPS. Assuming you own a domain name (which I
assume to already be the case for all mirrors), setting up HTTPS with Let's
Encrypt does not cost you a dime. Even if you are a commercial entity.
I'm not going to get into this too much, but suffice to say, it's not
universally accessible as a CA. And using Let's Encrypt for private
mirrors is sufficiently painful that I wouldn't recommend it.
Well, it might still be worthwhile to split out RPM's OpenPGP
implementation into its own project and allow people to contribute to
it. The worst that can happen is that nothing changes.
If that implementation is really as awfully broken as Panu is saying, I do
not think that that would be of much use, unfortunately.
There have been attempts to fix things, but Panu doesn't feel
qualified to review the changes. That doesn't mean someone else who
would be willing to do so couldn't. But because of... reasons, as long
as it's in the RPM codebase, it's unlikely someone else will be
trusted enough to do those reviews.
This misses the point by a mile.
Parsing OpenPGP is not rpm's "core business", by any stretch of
imagination. As such, I refuse to let it take up any significant portion
of rpm development resources.
The parser has been largely dormant in the codebase for like 20 years,
except for a couple of cleanup rounds when people have pointed out
random flaws and vulnerabilities. Last year when people started to
really look into it, it's become obvious that the effort to fix & review
it all is just nowhere near justifiable.
Consider this the RPM burning platform memo if you like ;)
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
