On Fri, Jun 11, 2021 at 11:17 AM Kevin Fenzi <kevin@scrye.com> wrote:
>
> On Fri, Jun 11, 2021 at 06:27:18AM -0400, Neal Gompa wrote:
> >
> > We do not, however, have GPG signatures on repository metadata. Which
>
> True.
>
> > means that we can't guarantee the repositories aren't tampered with.
>
> False.
>
> > This is especially problematic for people who use local mirrors or do
> > net installs.
>
> We could do more for local mirrors indeed.
>
> On Fri, Jun 11, 2021 at 01:48:50PM +0200, Björn Persson wrote:
> ...snip...
> >
> > As it is now, mirrors can't modify RPM packages without a key that the
> > clients have installed. Mirrors could however withhold security updates
> > so that clients remain vulnerable. Is that a thing that Rekor could
> > prevent?
>
> They cannot in the default, normal case where users use metalinks.
> (well, they could for 3 days or less, but then they cannot)
>
> > I believe Yum has a feature to verify signed repository metadata. I
> > don't know why it's not used. If that verification would be turned on,
> > are there any attacks that would still be possible then, that Rekor
> > could prevent?
>
> You mean dnf? :)
>
> It does, but it has... a number of issues.
>
> ...snip...
>
> On Fri, Jun 11, 2021 at 07:55:49AM -0400, Neal Gompa wrote:
> >
> > Fedora Infrastructure has stonewalled on signing our RPM repositories
> > for almost a decade. Reasons have ranged from "I don't like it" to
> > "It's useless because metalinks" to "RPM repository format should be
> > modified first". However, openSUSE signs their repositories and it
> > works fine there.
>
> I would like to strongly object to this being called 'stonewalling'
>
> You make it sound like there's a simple config switch we just need to
> turn on that we refuse to do. Thats completely 100% not the case.
>
> The reasons this is not enabled have in fact changed over the years, not
> because we 'made up a new reason', but because progress has been made
> and you can't instantly enable something before everything to enable
> that is in place.
>
> First the issue was that we were manually signing things. This meant in
> order to sign repodata we would need to have a releng person sitting
> there and signing away at the _end_ of pushes.
>
> Then, that was fixed by sigul, but then there were issues with other
> tools in the chain, like bodhi needs to be able to inject security
> update info into the repodata at the end of a compose, so you have to
> make sure it's signed after that, etc, etc. Those issues have all slowly
> moved forward over the years.
>
> Then, we actually did enable signed repodata a number of years ago for
> the cisco h264 repo. This exposed all kinds of dnf issues with signed
> repodata: The keystore it has is seperate from the rpmdb one, so it has
> to import things and get a 'ok' from the user again, it doesn't error
> correctly on non interactive cases, and in fact this blocked a fedora
> release a while back. So, we changed it to not use signed repodata.
>
> IN summary: I'm ok with enabling signed repodata when it is possible to
> do so and don't cause pain and suffering for our users. This has in fact
> always been my answer to this. It's not a priority for me personally
> because metalinks handle almost all the cases. The only things that
> would be improved by signed repodata are local mirrors that sync without
> checking for the mirror they sync from being up to date in
> mirrormanager. If you know of more cases, please share them.
>
I would like repos signed even if we don't enable it in the repo
definitions by default for now. That would make it possible for my Open
Build Service instance to validate Fedora content for package builds
(it can't use metalinks or mirrorlists, but it can check and validate
signed repodata). I asked CentOS years ago to do this for the same
reason, and they did it[1].
Also, not having it available has made it *very* hard to prioritize
getting the issues fixed in DNF. So being able to improve this is
predicated on the existence of signed metadata.
[1]: https://blog.centos.org/2018/07/improving-centos-package-delivery-security-with-signed-repository-metadata/
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hello,
There may be some confusion here, as Huzaifa is not proposing sigstore signs anything, he is proposing use of rekor, which although part of the overall sigstore project, can be run independently.
Rekor is a transparency log that stores signing manifests into a merkle tree, it uses the same back end technology as certificate transparency [0]
Rekor has what are termed 'types' that allow it to ingest custom schemas and hash those into the transparency log. For those that don't know, a transparency log is immutable / append only datastore that is publicly auditable. One of the types we have is an rpm type to ingest and store signing materials from an RPM package.
Why is this useful? You get a timestamped / tamper resistance record of all signing events. This is very useful for understanding the exact blast radius of a key compromise and monitoring for suspicious events. Most of the time you will not interact with the tlog, it would sit off to side hashing in entries, so it would make no changes to a maintainers working flow or not being in any build path where it could cause an outage. It's the sort of system most would not be aware of, unless something awful happens, and then it has a lot of value, as you have an immutable record of events.
Regards,
Luke