Re: Moving QEMU downloads to GitLab Releases?

[Philippe Mathieu-Daudé]

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

Regards,

Phil.