devpod icon indicating copy to clipboard operation
devpod copied to clipboard
verified publisher icon loft-sh

RPM/DEB Package signatures

Open westurner opened this issue 2 years ago • 5 comments

Is your feature request related to a problem?

  • Users can install the latest deb/rpm package of devpod automatedly and securely (with apt and dnf checking GPG signatures on the pkgrepo of packages and the packages themselves)
  • devpod is not in the [distro] package repos
  • Devpod Desktop does autoupdate, but DEB/RPM have to be updated by hand from gh releases
    • https://github.com/loft-sh/devpod/releases/download/v0.3.7/latest.json does not mention the RPMs or DEBs

Which solution do you suggest?

Which alternative solutions exist?

  • Parse github releases for just the devpod package in a separate cron task
  • Build native packages with the distro builders using their repo building systems
    • Ubuntu: PPA
      • See the links in comments on the BespokeSynth issue
    • Fedora: Rawhide, COPR; TIL about Packit-as-a-service
      • https://packit.dev/docs/guide
        • https://github.com/marketplace/packit-as-a-service
    • [...]
    • https://github.com/rpm-software-management/tito https://github.com/rpm-software-management/tito#related-projects
      • https://www.google.com/search?q=open+build+service
  • https://github.com/BespokeSynth/BespokeSynth/issues/108#issuecomment-919890002
  • https://www.google.com/search?q=how+to+how+rpms+and+debs+on+github
    • "Using Github Actions to create Debian (DEB) and RedHat (RPM) Packages and Repositories" [for hosting w/ GitHub Pages but not Release attachments] https://jon.sprig.gs/blog/post/2835

Additional context

westurner avatar Sep 18 '23 06:09 westurner

Hi @westurner, thank you for opening the issue.

Users can install the latest deb/rpm package of devpod automatedly and securely (with apt and dnf checking GPG signatures on the pkgrepo of packages and the packages themselves) devpod is not in the [distro] package repos

sounds like a good addition to me, but I'm not really familiar with the rpm/deb landscape. Would you be open to contribute this with my support?

Devpod Desktop does autoupdate, but DEB/RPM have to be updated by hand from gh releases

That's a restriction by tauri at the moment as they don't support deb/rpm packages. We're building those in the CD pipeline for convencience but don't have strong support for it as of yet. Imo integrating it into the auto updater mechanism upstream would be more work than we're currently comfortable putting in. If there's strong enough community interest, we could look into it.

Generally I can only encourage you to contribute this, and we'll support you wherever we can

pascalbreuninger avatar Sep 18 '23 08:09 pascalbreuninger

Not sure when this'll be a priority. FWIu a more current way to handle packagesec is to implement SLSA, which

  • https://slsa.dev/
  • https://github.com/slsa-framework/slsa-verifier#what-is-slsa-verifier

https://github.com/slsa-framework/slsa-github-generator#what-is-slsa-github-generator

Just generating a repomd.xml from the RPM release URLs and hashes (with createrepo_c or createrepo) should be easy enough once the gh releases are parsed, or does the builder need to download every package in order to sign the repomd.xml?

Is it createrepo for RPM and aptly for DEB package repos?

Is there enough metadata about release assets in the gh api to not need to download and hash each package every time the repomd.xml file is regenerated? https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28

https://wiki.debian.org/DebianRepository/Setup

https://www.aptly.info/

On Mon, Sep 18, 2023, 4:46 AM Pascal Breuninger @.***> wrote:

Hi @westurner https://github.com/westurner, thank you for opening the issue.

Users can install the latest deb/rpm package of devpod automatedly and securely (with apt and dnf checking GPG signatures on the pkgrepo of packages and the packages themselves) devpod is not in the [distro] package repos

sounds like a good addition to me, but I'm not really familiar with the rpm/deb landscape. Would you be open to contribute this with my support?

Devpod Desktop does autoupdate, but DEB/RPM have to be updated by hand from gh releases

That's a restriction by tauri https://tauri.app/v1/guides/distribution/updater at the moment as they don't support deb/rpm packages. We're building those in the CD pipeline for convencience but don't have strong support for it as of yet. Imo integrating it into the auto updater mechanism upstream would be more work than we're currently comfortable putting in. If there's strong enough community interest, we could look into it.

Generally I can only encourage you to contribute this, and we'll support you wherever we can

— Reply to this email directly, view it on GitHub https://github.com/loft-sh/devpod/issues/698#issuecomment-1722990388, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMNS5IK3O43YP4JBYGMX3X3ADAHANCNFSM6AAAAAA44GTH64 . You are receiving this because you were mentioned.Message ID: @.***>

westurner avatar Sep 18 '23 12:09 westurner

Hi @westurner

Yes for now deb/rpm are lower prio I personally would give priority to one of the universal packages (appimage/flatpak) in order to reduce our maintenance burden, as setting up repos and whatnot is not in scope

89luca89 avatar Sep 19 '23 07:09 89luca89

Flatpak

  • https://docs.flatpak.org/en/latest/first-build.html#add-a-manifest
  • https://docs.flatpak.org/en/latest/manifests.html
  • https://github.com/flatpak/flatpak-github-actions #building-for-multiple-cpu-architectures
  • https://flatpak-testing.readthedocs.io/en/latest/distributing-applications.html#gpg-signatures

    Note that it is necessary to become root in order to update a remote that does not have GPG verification enabled.

  • https://slsa.dev/blog/2023/08/bring-your-own-builder-github
    • https://github.com/flatpak/flatpak-github-actions/blob/0a7e6df021640fac36d460232f9d5dc68821e702/flatpak-builder/index.js#L204

conda-forge

  • https://github.com/conda-forge/conda-feedstock#about-conda-forge
  • https://conda-forge.org/docs/maintainer/adding_pkgs.html#step-by-step-instructions
  • https://github.com/conda-forge/go-feedstock/blob/main/recipe/meta.yaml
  • https://github.com/conda-forge/sphinxcontrib-golangdomain-feedstock/blob/main/recipe/meta.yaml s/Ruby/Golang/
  • https://github.com/conda-forge/go-task-feedstock/blob/main/recipe/meta.yaml
  • https://github.com/conda/conda-content-trust

github actions + slsa:

  • https://slsa.dev/blog
  • "General Availability of SLSA 3 Go native builder for GitHub Actions" https://slsa.dev/blog/2022/06/slsa-github-workflows

On Tue, Sep 19, 2023 at 3:05 AM Luca Di Maio @.***> wrote:

Hi @westurner https://github.com/westurner

Yes for now deb/rpm are lower prio I personally would give priority to one of the universal packages (appimage/flatpak) in order to reduce our maintenance burden, as setting up repos and whatnot is not in scope

— Reply to this email directly, view it on GitHub https://github.com/loft-sh/devpod/issues/698#issuecomment-1724942380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMNS6YD2XQR7OGKVMEJC3X3E74BANCNFSM6AAAAAA44GTH64 . You are receiving this because you were mentioned.Message ID: @.***>

westurner avatar Sep 19 '23 10:09 westurner

Actually, because devpod must have the system (and not the rootless?) DOCKER_SOCKET, devpod+podman[+k8s] could really be in a VM. One way to manage local VMs is with a Vagrantfile:

  • https://github.com/containers/podman-tui/blob/main/Vagrantfile
  • https://github.com/brancz/vagrant-golang/blob/master/Vagrantfile

Rootless podman / docker instead of or in addition to a VM is probably advisable? Is that a separate issue or an issue of how the RPM package should/could work by default?

  • "about act_runner run in rootless docker" (which now just works fwiu) https://gitea.com/gitea/act_runner/issues/170
  • https://github.com/go-gitea/gitea/issues/24438
  • https://news.ycombinator.com/item?id=36408748

westurner avatar Sep 20 '23 17:09 westurner