feat: add net deploy mirror and gpg verification mirror

[Neko-vecter]

This PR allow Moonraker net-deploy / webui can use mirror.

It also verify gpg key on mirror server

Add gpg key to moonraker.

Important

it only requires when use mirror. if not use mirror it will behave same as before.

• add into keychain/owner/project.asc
• it will use this key to verify the download zip file with .zip.asc
• example mainsail.zip / mainsail.zip.asc
• if key not able verify. it will fail to update.
  • mirror issue. release file damage
  • you config wrong endpoint (mainsail release file to fluidd?)
• add release file limit. it only find project.zip example mainsail.zip

Config example

[update_manager mainsail]
type: web
channel: stable
repo: mainsail-crew/mainsail # this will let moonraker find keychain file.
path: ~/mainsail

# mirror option
enable_mirror: True # enable mirror
mirror_url: https://url/mirrors/mainsail-release/ # config base url
mirror_latest_template: LatestRelease/release  # config release file location
mirror_tag_template: {tag}/release # config tag version release file location

it will show below info if you enable and set mirror.

Tip

if you want setup a mirror at home.
Neko-vecter/moonraker-mirror-toolkit

Keychain Directory Structure

keychain
  - owner1 # like mainsail-crew
    - repo1.asc # like mainsail.asc
    - repo2.asc

  - owner2 # like fluidd
    - repo1.asc # like fluidd.asc
    - repo2.asc

Relate issue for add GPG to release

mainsail-crew/mainsail#2559
fluidd-core/fluidd#1893

-Neko.vecter

[Arksine]

Thanks. Unfortunately this continues to expose the the same security vulnerability. An attacker with access to an instance could take an existing validated installation, change the mirror, then update to version with a malicious payload.

There are ways to add support for "mirrors" outside of configuration options and I have began implementation. That said I have other items prioritized at the moment so I can't give a specific timeline as to when I will complete it and merge it.

One interim option would be to create a simple local GitHub API compatible server that is an intermediary between Moonraker and your mirror, then configure your router to redirect api.github.com DNS requests to this server.

[Neko-vecter]

Thanks for reply.

I understand the issue you mentioned. I'm looking into how to sign files and add a GPG key to the server.
it maybe require mainsail/fluidd release with gpg key. Then mirror server just mirror this key.

The public key can be install during installation. (Integration with KIAUH is required)

OR inside moonraker

example

• mainsail.zip - release file
• mainsail.zip.asc - gpg verify file

then use command below to verify.

gpg --verify mainsail.zip.asc mainsail.zip

-Neko.vecter

[Neko-vecter]

Keychain Directory Structure

keychain
  - owner1 # like mainsail-crew
    - repo1.asc # like mainsail.asc
    - repo2.asc

  - owner2 # like fluidd
    - repo1.asc # like fluidd.asc
    - repo2.asc

-Neko.vecter

[Neko-vecter]

Update 2026 / 06 / 26

GPG support is done

it will require maintainer at upstream to submit there public key to moonraker repo. under keychain/owner/repo.asc

Important

it only requires when use mirror. if not use mirror it will behave same as before.

Relate issue for add gpg to release
mainsail-crew/mainsail#2559
fluidd-core/fluidd#1893

what next?

move moonraker mirror config to /etc/moonraker/mirror.conf

-Neko.vecter

[MOVIBALE]

打卡喵

[Digerster]

I'd like to request a feature addition. As a beginner to 3D printing and Klipper, I found the installation process extremely tedious and difficult.

[sjqlwy]

A very useful feature PR

[Neko-vecter]

Update 2026 / 06 / 27

Add GPG Signature in workflow to mainsail

Relate PR
mainsail-crew/mainsail#2560

relate issue can be benefit
#1083
#470

-Neko.vecter

[lk8716047]

hello

[bigtreetech]

Thanks. Unfortunately this continues to expose the the same security vulnerability. An attacker with access to an instance could take an existing validated installation, change the mirror, then update to version with a malicious payload.

There are ways to add support for "mirrors" outside of configuration options and I have began implementation. That said I have other items prioritized at the moment so I can't give a specific timeline as to when I will complete it and merge it.

One interim option would be to create a simple local GitHub API compatible server that is an intermediary between Moonraker and your mirror, then configure your router to redirect api.github.com DNS requests to this server.

Hi Eric,

Is this really true though? With GPG protection the attacker would need access to the filesystem and not just the config. Provided the public key is embedded within the actual moonraker installation and not the config then an attacker could point the mirror to whatever drivel they want and it would always fail signing checks. For them to actually install a malicious instance they would need filesystem so that they can swap out the public key. If they have that then they have no reason to worry about an installation from a mirror, they already have all of the access privilege that they need.

Luke.

[Arksine]

Is this really true though? With GPG protection the attacker would need access to the filesystem and not just the config

That comment was made before signature validation was proposed. It is true that signed zip files would mitigate the issue. I'm not opposed to adding support for signature validation, as its real use is to help mitigate potential security issues outside of Moonraker's control such as MITM attacks. However it needs to be added under the following conditions:

1. It should be in its own PR, separate from any attempt to implement mirrors.
2. It should be optional, only performed when public keys are available for the particuar extension.
3. Validation should occur on downloads regardless of whether or not they come from a mirror
4. We need to work with front end and extension developers on the best way to implement this feature. We can't simply implement something and demand they support it. They should have the opportunity to provide feedback before such a feature is merged.
5. There can't be any blocking code in the validation (this PR uses the subprocess module directly rather than Moonraker's shell_command component, which was written to execute processes asynchronously).

Also, while GPG signature validation could be a solution for for the types supported by net_deploy.py, it isn't a solution for python types that are built from GitHub source. Those would still need mirror support, and we wouldn't want to provide the ability to modify those mirrors via the config. Thus we are back to square one.

Finally, I would just like to reiterate that I already have much of the work done to support GitHub mirrors. Since this work is done on my end, and I intend to merge it when it is ready, I won't likely merge PRs that add support for mirrors unless I am convinced it is superior to my own implementation.

[meteyou]

I have no problem signing the Mainsail release zip-file.

The only condition from our side is that there's actually a mechanism in Moonraker that consumes and verifies the signature. We'd rather not ship .asc files that no client validates...

So once the verification side is defined and where the public key is anchored, we will implement/merge it in the Mainsail release workflow. Just let me know the expected scheme and we'll wire up signing in our release workflow accordingly.

[Neko-vecter]

Following up on adding mirror and gpg support for moonraker

1. For mirror support: Since moonraker has a plan and already working on mirror support, that sounds great. I will hold off for now and wait until mirror implementation.
2. For GPG verification: I will also wait until mirror implementation is complete. If this patch is no longer needed by then, I'm completely fine with closing this PR.