qemu-devel
[Top][All Lists]
Advanced

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

Re: Moving QEMU downloads to GitLab Releases?


From: Stefan Hajnoczi
Subject: Re: Moving QEMU downloads to GitLab Releases?
Date: Mon, 4 Oct 2021 10:01:22 +0100

On Fri, Oct 01, 2021 at 09:39:13AM +0200, Philippe Mathieu-Daudé wrote:
> On 9/30/21 15:40, Stefan Hajnoczi wrote:
> > Hi Mike,
> > QEMU downloads are currently hosted on qemu.org's Apache web server.
> > Paolo and I were discussing ways to reduce qemu.org network traffic to
> > save money and eventually turn off the qemu.org server since there is no
> > full-time sysadmin for it. I'd like to discuss moving QEMU downloads to
> > GitLab Releases.
> > 
> > Since you create and sign QEMU releases I wanted to see what you think
> > about the idea. GitLab Releases has two ways of creating release assets:
> > archiving a git tree and attaching arbitrary binaries. The
> > scripts/make-release script fetches submodules and generates version
> > files, so it may be necessary to treat QEMU tarballs as arbitrary
> > binaries instead of simply letting GitLab create git tree archives:
> > https://docs.gitlab.com/ee/user/project/releases/#use-a-generic-package-for-attaching-binaries
> > 
> > Releases can be uploaded via the GitLab API from your local machine or
> > deployed as a GitLab CI job. Uploading from your local machine would be
> > the closest to the current workflow.
> > 
> > In the long term we could have a CI job that automatically publishes
> > QEMU releases when a new qemu.git tag is pushed. The release process
> > could be fully automated so that manual steps are no longer necessary,
> > although we'd have to trust GitLab with QEMU GPG signing keys.
> 
> Before having to trust a SaaS for GPG signing, could this work?
> 
> - make-release script should produce a reproducible tarball in a
>   gitlab job, along with a file containing the tarball hash.
> 
> - Mike (or whoever is responsible of releases) keeps doing a local
>   manual build
> 
> - Mike checks the local hash matches the Gitlab artifact hash
> 
> - Mike signs its local build/hash and uses the GitLab API to upload
>   that .sig to job artifacts
> 
> - we can have an extra manual job that checks the tarball.sig
>   (hash and pubkey) and on success deploys updating the download
>   page, adding the new release

I wonder what Mike sees as the way forward.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]