Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 13, 2022 at 9:31 AM Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Neal Gompa wrote:
> > This is also the underlying reason why Red Hat has resisted
> > implementing signed repository metadata and enforcing it by default.
> > Of course this is a bit of a catch-22 as well, as there's no
> > motivation to find a solution because neither Fedora nor RHEL offer
> > signed repository metadata despite repeated calls for it over the past
> > decade.
>
> Is signed repository metadata not basically moot now that pretty much all
> the world has moved on from unencrypted HTTP to secure HTTPS?
>

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.

Also, a ton of Fedora mirrors still don't use HTTPS for various reasons.

> > Now, don't get me wrong: I'm personally extremely unhappy about having
> > to depend on the Sequoia stack for RPM PGP. I have a strong distaste
> > for the Rust community ecosystem these days, and I don't love the idea
> > of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
> > will be in place soon enough!).
>
> The dependency on LLVM is not even the worst issue in my eyes. LLVM is also
> used by other core projects, e.g., mesa, these days.
>
> The worst issue I see with Rust is the way libraries are "packaged", which
> just implies installing source code and recompiling that source code for
> every single application. (And as a result, the output obviously gets
> statically linked into the application, with all the drawbacks of static
> linking.) I consider a language with no usable shared library support to be
> entirely unpackageable and hence entirely useless.
>
> And then of course there is the issue that it is yet another language with
> yet another syntax (and an only partially C-like one, so the learning curve
> is unnecessarily high), yet another library ecosystem, etc. C has been the
> de facto lingua franca all this time, now we are back into a tower-of-babel
> scenario with tons of programming languages, which will necessarily bloat
> the core system over time.
>
> > So here we are, in a subpar situation created by bad tools because
> > nobody cares enough about security anyway.
>
> Sounds like a mess indeed.
>

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.



-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux