From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
qemu-devel <qemu-devel@nongnu.org>,
"Eldon Stegall" <eldon-qemu@eldondev.com>,
michael.roth@amd.com, "Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: Moving QEMU downloads to GitLab Releases?
Date: Fri, 1 Oct 2021 09:52:20 +0100 [thread overview]
Message-ID: <YVbMROzMahQmaRt5@redhat.com> (raw)
In-Reply-To: <YVa0p4rZDh3teOwC@stefanha-x1.localdomain>
On Fri, Oct 01, 2021 at 08:11:35AM +0100, Stefan Hajnoczi wrote:
> We need to keep the security of QEMU releases in mind. Mike Roth
> signs and publishes releases. Whoever facilitates or hosts the files
> should not be able to modify the files after Mike has blessed them. One
> way to do this is to keep hosting the .sig files on download.qemu.org
> and to redirect the actual tarballs to a file hosting provider. A way to
> securely publish files without hosting anything on qemu.org would be
> even better though (maybe it's enough to publish signatures on the
> static GitLab Pages website).
If someone modifies the download files, then when you verify the sig
it will be detected. It doesn't matter whether the sig is on the same
host or not, because if someone modifies the sig too, then it will
still fail validation. The important thing is that the user has got
the right public key to verify with.
IOW, hosting the .sig separately is not required. We need to ensure
that our public key, however, is published & discoverable in a
trustworthy place that is separate from the download server. We fail
at that today because www.qemu.org and download.qemu.org are the
same server.
So it will be beneficial if the download site is split off from
the public website, compared to our current setup.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2021-10-01 8:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-30 13:40 Moving QEMU downloads to GitLab Releases? Stefan Hajnoczi
2021-09-30 14:28 ` Stefan Hajnoczi
2021-09-30 15:57 ` Eldon Stegall
2021-10-01 7:11 ` Stefan Hajnoczi
2021-10-01 8:52 ` Daniel P. Berrangé [this message]
2021-10-04 8:53 ` Stefan Hajnoczi
2021-10-11 15:00 ` Anthony Liguori
2021-10-01 7:24 ` Thomas Huth
2021-10-01 10:34 ` Gerd Hoffmann
2021-10-01 12:50 ` Philippe Mathieu-Daudé
2021-10-01 7:39 ` Philippe Mathieu-Daudé
2021-10-04 9:01 ` Stefan Hajnoczi
2021-10-04 19:34 ` Michael Roth
2021-10-05 13:29 ` Stefan Hajnoczi
2021-10-11 7:21 ` Gerd Hoffmann
2021-10-11 10:58 ` Stefan Hajnoczi
2021-10-11 14:28 ` Warner Losh
2021-10-11 15:46 ` Stefan Hajnoczi
2021-10-11 16:27 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YVbMROzMahQmaRt5@redhat.com \
--to=berrange@redhat.com \
--cc=eldon-qemu@eldondev.com \
--cc=f4bug@amsat.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).