AUR package

[omnigenous]

https://aur.archlinux.org/

[CyberDudeJ]

Honestly I'd kill for an AUR package of this

[dhth]

While I work on publishing an AUR package for omm, would getting linux binaries directly from a release suffice for now? Something like this:

# choose a gzipped tarball based on your architecture
curl -s -L -o omm.tar.gz https://github.com/dhth/omm/releases/download/v0.2.2/omm_0.2.2_linux_amd64.tar.gz
tar -xvzf omm.tar.gz
# move omm to a location on your $PATH
omm

[dimatematik]

I've published one and ready to maintain it

Could you please provide instructions on how to verify tarball signatures? I see that cosign is used, but the public key (cosign.pub) is in .gitignore

[dhth]

@dimatematik Thanks a lot for publishing it :)

I've added cosign.pub to the release assets. The tarballs (or any other files in the release, eg. checksum files) can be verified using:

cosign verify-blob --key cosign.pub --signature omm_0.4.1_linux_amd64.tar.gz.sig omm_0.4.1_linux_amd64.tar.gz

Since I am new to AUR packages, I have a question: The AUR package lists go as a dependency. Since I'm already publishing linux binaries, would it be easier to point the source directly to a precompiled binary (eg. the way it's done here), and remove the dependency?

[omnigenous]

The AUR package lists go as a dependency. Since I'm already publishing linux binaries, would it be easier to point the source directly to a precompiled binary (eg. the way it's done here), and remove the dependency?

I'm no expert either but I think that how it works:

• package: Latest version
• package-git: Latest git commit
• package-bin: Latest version binary

[dimatematik]

Thanks for clarifying the verification process!

The use of -bin packages is a matter of debate (discussion example). Since the AUR is completely untrusted (maintainer == anyone), end users should verify that the binary was compiled by the original author of the code. As a maintainer, I am advised to validate the binary (as stated in the Arch package guidelines), but the end user cannot be sure of my honesty. The only way to verify whether a binary was provided by the code's author is through cryptographic verification. Currently makepkg natively only supports PGP keys, so checking with cosign will require the "cosign" dependency. Personally, I don't think there is a problem with the "go" dependency. The AUR is designed to store build instructions. -bin packages are typically used for heavy projects (like browsers) and proprietary software.

[dhth]

@dimatematik Makes sense. A non bin package with dependencies sounds good, then.

Side note: I added more details on verifying the authenticity of release assets here.

[dimatematik]

Well, someone published the -bin package) I think the issue can be marked as resolved