qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Stefan Weil" <sw@weilnetz.de>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Cc: Programmingkid <programmingkidx@gmail.com>,
	Rainer M?ller <raimue@macports.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts
Date: Wed, 4 Apr 2018 18:11:42 +0200	[thread overview]
Message-ID: <6171cf9f-6c76-33a7-9654-c6ed78dbe02f@redhat.com> (raw)
In-Reply-To: <b5f3cb9f-d40a-439a-34a4-58bba9ec0387@weilnetz.de>

On 04/04/2018 17:55, Stefan Weil wrote:
> Am 04.04.2018 um 16:58 schrieb Daniel P. Berrangé:
>> On Wed, Apr 04, 2018 at 04:45:48PM +0200, Paolo Bonzini wrote:
>>> On 04/04/2018 16:38, Daniel P. Berrangé wrote:
>>>> The source/quality of those binaries is completely opaque. We've no idea who
>>>> built them, nor what build options were used, nor what/where the corresponding
>>>> source is (required for GPL compliance), nor any checksum / signature to
>>>> validate the binary isn't compromised since build, etc, etc.
>>>>
>>>> Pointing users to those binaries makes it appear QEMU project is blessing
>>>> them, and so any issues with them directly reflect on QEMU's reputation.
>>>>
>>>> If we're going to link to binaries telling users to download them, we need
>>>> to be hosting them on qemu.org and have a clearly documented formal process
>>>> around building & distributing them.
>>>>
>>>> Since both Homebrew & Macports are providing formal bulds though, it looks
>>>> simpler to just entirely delegate the problem to them, as we do for Linux
>>>> where we delegate to distro vendors to build & distribute binaries.
>>>
>>> Note that, to some extent, the same issues do apply to Win32 binaries
>>> (in particular, they are distributed under http and there are no
>>> signatures).  However, the situation is better in that they are hosted
>>> on an identifiable person's website, and of course Windows doesn't have
>>> something akin to Homebrew and Macports so there is no alternative to
>>> volunteers building and hosting the binaries.
>>
>> It would be desirable & practical to address that for Win32, by building
>> the Win32 binaries at time of cutting the release, using the Mingw toolchain
>> via one of our formal Docker environments. Would need buy-in of our release
>> manager to accept the extra work for making releases though...
>>
>> Regards,
>> Daniel
> 
> That would be one possible way. A more automated way could use CI builds
> (for example on GitHub) to generate executables for Windows.
> 
> By the way: https://qemu.weilnetz.de provides https (maybe I should
> enforce it), it includes sha512, and I also sign the binaries with my
> key. You still have to trust me, Debian and Cygwin (which provides lots
> of libraries used for the build).

Cool!  I had noticed sha512, but it is not very useful without https
(except to verify bitflips).  Good news that you support https, we
should change the website to use https links instead.

Regarding signing, there is no GPG signature.  That's okay, but we
should document how to verify the installer signature from either Linux
or Windows.

Thanks,

Paolo

  parent reply	other threads:[~2018-04-04 16:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.35816.1522678020.27992.qemu-devel@nongnu.org>
2018-04-02 14:13 ` [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts Programmingkid
2018-04-04 11:15   ` Paolo Bonzini
2018-04-04 14:24     ` Programmingkid
2018-04-04 14:38       ` Daniel P. Berrangé
2018-04-04 14:45         ` Paolo Bonzini
2018-04-04 14:58           ` Daniel P. Berrangé
2018-04-04 15:55             ` Stefan Weil
2018-04-04 16:05               ` Programmingkid
2018-04-04 16:08                 ` Paolo Bonzini
2018-04-04 16:19                   ` Programmingkid
2018-04-04 17:23                     ` Paolo Bonzini
2018-04-04 16:11               ` Paolo Bonzini [this message]
2018-04-04 17:41                 ` Stefan Weil
2018-04-05  5:56                   ` Paolo Bonzini
2018-04-01 16:22 Rainer Müller
2018-04-02  2:22 ` Paolo Bonzini

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=6171cf9f-6c76-33a7-9654-c6ed78dbe02f@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=berrange@redhat.com \
    --cc=programmingkidx@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raimue@macports.org \
    --cc=sw@weilnetz.de \
    /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).