I hate all those unofficial methods listed in documentations of every project, there should be massive banner screaming how it could be malicious and its not related to the project or completely removed - IMO.

Interesting, good to know. I am fine with adding big massive banners or removing them entirely.

Worst Entry trust to unrelated user

• copr

Trust in external Package infra, seems to be done with a bot out of our control

• Arch (Linux)
• Homebrew (Linux, macOS)
• Nix/NixOS (Linux, macOS)
• MacPorts (macOS)
• Scoop (Windows)

Updates from other people possible

• Chocolatey (Windows) (state unknown, code in repo)
• WinGet (Windows) (pr from our infra, merge not)

Fully Trusted

• GitHub CLI (Linux, macOS, Windows, FreeBSD)
• Releases

Which level of trust do like most?

We can always ask them to add a core maintainer or nektos-ci to feedstock repo. It will good for the visibility of Conda package and add trust factor.
ATM it is being built using the source release. With bots creating the pr. If nektos-ci is added to the repo we can also trigger pr with release workflow.

ATM it is being built using the source release

The problem here, source releases are not protected¹ and custom binaries² generated out of them can not be verified.

Back to an older topic: So what is the gain for immutable releases?, if we have so many packages that are vulnerable. A command like gh verify only works if every package contains our first party binaries. Any custom build is flagged as unknown.

We can always ask them to add a core maintainer or nektos-ci to feedstock repo

I do not have such ambitions and adding more people increases supply chain risks. Any person in the release flow could be tampered, from bot account to maintainer of any level is it from nektos, third party repo etc.

nektos/act has maintain problems, on the other hand given it's popularity/hype we might be an target to attacks and there are many possibilities even without stealing our tokens.