ACMEv2 beta (v0.2.1) now available

[hlandau]

ACMEv2 support has now been merged into master and a beta is available as release v0.2.1. You will need to build this yourself as release automation is being renovated.

This removes and replaces support for ACMEv1. Support for in-place upgrades using existing state directories (/var/lib/acme) is experimental; if you want to try this, just install the new binary and run it. Please make a backup of /var/lib/acme first. Or of course you can start with a fresh state directory.

The repository has moved to hlandau/acmetool from hlandau/acme. This should redirect automatically.

Please report issues on the issue tracker.

[holdenger]

@hlandau Hello, and a big thank you for this. When do you expect release of binaries?

[ewenmcneill]

For anyone else trying to build this from source to test it out, it looks like it'll require golang version 1.9 or higher for the math/bits dependency. So, eg, go version go1.7.4 linux/amd64 in Debian Stretch (9) is too old to build the package (at least automatically). Debian Buster (10) seems to have a new enough go version (go version go1.11.6 linux/amd64) , and that's been backported to Debian Stretch so that's what I ended up using to build (I still have some Debian Stretch systems I need acmetool to run on, and at least by default go builds dynamically linked binaries).

I think the resulting binary is correctly built to be acmetool with ACME API v2, but I've not yet been able to confirm that definitively (it does look like, eg, the right Go dependencies were downloaded; this is building from master which appears to be the latest branch; it looks like acmev2 and dev are behind master at this point, and that the v2 beta support has been merged into master.)

Ewen

vagrant@acmetool-stretch:~$ sudo /bin/sh -c 'echo deb http://deb.debian.org/debian stretch-backports main >/etc/apt/sources.list.d/debian-backports.list'
vagrant@acmetool-stretch:~$ sudo apt-get update
[...]
vagrant@acmetool-stretch:~$ LANG=C sudo apt-get -t stretch-backports install golang-1.11
[...]
vagrant@acmetool-stretch:~$ PATH="/usr/lib/go-1.11/bin:$PATH"
vagrant@acmetool-stretch:~$ go version
go version go1.11.5 linux/amd64
vagrant@acmetool-stretch:~$ echo $GOPATH
/home/vagrant/go
vagrant@acmetool-stretch:~$ cat /etc/debian_version 
9.11
vagrant@acmetool-stretch:~$ git clone https://github.com/hlandau/acmetool.git
Cloning into 'acmetool'...
remote: Enumerating objects: 2797, done.
remote: Total 2797 (delta 0), reused 0 (delta 0), pack-reused 2797
Receiving objects: 100% (2797/2797), 1.07 MiB | 326.00 KiB/s, done.
Resolving deltas: 100% (1736/1736), done.
vagrant@acmetool-stretch:~$ cd acmetool/
vagrant@acmetool-stretch:~/acmetool$ make
	[RELOCATE]	  
	[GO-GET]	  git.devever.net/hlandau/acmetool
	[DIRS]	  
	[DIRS]	  
	[GO-INSTALL]	  git.devever.net/hlandau/acmetool
vagrant@acmetool-stretch:~/acmetool$ sudo env "PATH=$PATH" make install
	[RELOCATE]	  
	[DIRS]	  
	[GO-INSTALL]	  git.devever.net/hlandau/acmetool
	[INSTALL]	  git.devever.net/hlandau/acmetool
vagrant@acmetool-stretch:~/acmetool$ which acmetool
/usr/local/bin/acmetool
vagrant@acmetool-stretch:~/acmetool$ acmetool --version
go version go1.11.5 linux/amd64 gc cgo=true
build unknown
vagrant@acmetool-stretch:~/acmetool$ file `which acmetool`
/usr/local/bin/acmetool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=cc11c0004457975445ab3cc366b2bfc42d448229, not stripped
vagrant@acmetool-stretch:~/acmetool$ ldd `which acmetool`
	linux-vdso.so.1 (0x00007ffc6e7ee000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f3eda0a7000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3ed9e8a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3ed9aeb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3eda2ad000)
vagrant@acmetool-stretch:~/acmetool$ 

[SinOJosWeb]

What might the status be of v2. In June of 2020 we will stop allowing new domains to validate via ACMEv1 https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

I have been using ACMEv1 and have had no problems. I like being able to use the redirector. I see that v1 is available via Centos 7 package manager, though I compiled my self. Is there any intentions of providing a v2 binary for Centos 7. Even though there is some time until June 2020. Every time a certificate is added or renewed LetsEncrypt sends me an email reminding me that v1 on June 1 2020 will no longer be allowed.

There has been no activity for a month now. Has the project been put on hold. Should I start looking for something else. There is a long list of v2 releases on the LetsEncrypt website. Everyone else has already moved on to v2. https://letsencrypt.org/docs/client-options/

[mnalis]

@SinOJosWeb ACMEv2 in acmetool seems to be working just fine. I recently compiled latest master branch on Debian Buster (by instructions above for Stretch, just simpler as no backports needed at all), and replaced acmetool binary provided by standard debian package with that. It works just fine.
I've also requested ACMEv2-only wildcard certs using DNS hook (homemade for our custom setup for tinydns) and it also works just fine.

So I would say what remains is @hlandau make a release (or at least a release candidate!) soon, so we can go ask package maintainters to make new package (it all takes time!)

[defanator]

Was anyone able to build v0.2.1 on Ubuntu 16.04? Solution from @ewenmcneill does not work unfortunately, libpcap-dev (libpcap0.8-dev actually) on Ubuntu 16.04 does not contain required header (sys/capability.h).

[mnalis]

@defanator Don't know about Ubuntu, but on Debian package is libcap-dev (that is one relating to POSIX 1003.1e capabilities) and not libpcap-dev (which is one about packet capturing for tcpdump and friends).

[defanator]

@mnalis oh sorry, my bad! libcap-dev is the right one there as well. Thank you!

[defanator]

@hlandau v0.2.1 seems to work fine. Hope to expect binaries soon!

[pipiche38]

Any plan to provide a rpm based version for Fedora users ?
like what we have for the acmetool on https://copr.fedorainfracloud.org/coprs/hlandau/acmetool/

[SinOJosWeb]

I had no trouble compiling on Amazon AWS Linux 2 AMI.
I already had v1 installed via the package manager yum and enabled via systemd running in redirector mode.

Installed:
yum install golang libcap-devel

cloned git repository:
git clone https://github.com/hlandau/acmetool.git

enter ~/acmetool directory run "make" wait for it to finish:
systemctl stop acmetool-redirector.service
mv /var/lib/acme ~/acme-v1
mv /bin/acmetool ~/acmetool-v1
cd ~/acmetool/bin
cp acmetool /bin
systemctl start acmetool-redirector.service
acmetool quickstart
acmetool want domainname.com

I run haproxy did not have to change any settings. Rebooted and it works. Now simply wait to renew time, and hopefully it will renew without any errors.

[tomwaldnz]

On Amazon Linux 1 I get this error when trying to build. I'll just wait for the binary.

git config --global http.followRedirects true
git clone https://github.com/hlandau/acme
make
        [RELOCATE]
        [GO-GET]          git.devever.net/hlandau/acmetool
# gopkg.in/hlandau/svcutils.v1/caps
src/gopkg.in/hlandau/svcutils.v1/caps/caps-linuxc.go:9:10: fatal error: sys/capability.h: No such file or directory
 #include <sys/capability.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [.gotten] Error 2

[pipiche38]

seems same as hlandau/acme.t#1

[pipiche38]

I'm newbie on GO so probably I'm missing something:

Fedora 31
go version
go version go1.13.6 linux/amd64

 make
	[RELOCATE]
	[GO-GET]	  git.devever.net/hlandau/acmetool
# git.devever.net/hlandau/acmetool/storageops
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:76:49: cannot use cl (type *"github.com/hlandau/acmeapi".RealmClient) as type *"gopkg.in/hlandau/acmeapi.v2".RealmClient in argument to solver.AssistedRegistration
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:437:48: cannot use cl (type *"github.com/hlandau/acmeapi".RealmClient) as type *"gopkg.in/hlandau/acmeapi.v2".RealmClient in argument to solver.AssistedRegistration
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:456:41: cannot use cl (type *"github.com/hlandau/acmeapi".RealmClient) as type *"gopkg.in/hlandau/acmeapi.v2".RealmClient in argument to solver.Order
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:456:58: cannot use &orderTpl (type *"github.com/hlandau/acmeapi".Order) as type *"gopkg.in/hlandau/acmeapi.v2".Order in argument to solver.Order
src/git.devever.net/hlandau/acmetool/storageops/reconcile.go:461:37: not enough arguments in call to r.store.ImportCertificate
	have (string)
	want (*storage.Account, string)
make: *** [Makefile:76: .gotten] Error 2

[slashr]

I've got the same (similar?) problem as @pipiche38

root@ip-172-31-12-130:/home/admin/acmetool# make
	[RELOCATE]
	[GO-GET]	  git.devever.net/hlandau/acmetool
package github.com/hlandau/acmetool/cli
	imports context: unrecognized import path "context"
package github.com/hlandau/acmetool/cli
	imports github.com/coreos/go-systemd/dbus
	imports github.com/godbus/dbus/v5
	imports github.com/godbus/dbus/v5
	imports github.com/godbus/dbus/v5: cannot find package "github.com/godbus/dbus/v5" in any of:
	/usr/lib/go/src/pkg/github.com/godbus/dbus/v5 (from $GOROOT)
	/home/admin/acmetool/src/github.com/godbus/dbus/v5 (from $GOPATH)
package github.com/hlandau/acmetool/cli
	imports github.com/coreos/go-systemd/dbus
	imports github.com/godbus/dbus/v5
	imports github.com/coreos/go-systemd/unit
	imports github.com/hlandau/goutils/os
	imports github.com/hlandau/xlog
	imports github.com/mattn/go-isatty
	imports golang.org/x/sys/unix
	imports math/bits: unrecognized import path "math/bits"
Makefile:76: recipe for target '.gotten' failed
make: *** [.gotten] Error 1

[ewenmcneill]

In #322 (comment) @tomwaldnz wrote:

On Amazon Linux 1 I get this error when trying to build. I'll just wait for the binary.

@tomwaldnz sys/capability.h is part of libcap; do you have that installed? (Not libpcap for packet capture, but libcap for Linux Capabilities). Eg, https://packages.ubuntu.com/search?searchon=contents&keywords=sys%2Fcapability.h&mode=exactfilename&suite=eoan&arch=any turns it up in libcap-dev on Ubuntu Linux.

It looks like Amazon Linux is based on a RPM distro, and searching through, eg, Packages in Amazon Linux 2018.3 it looks like libcap is provided by libcap-2.16 or similar (seems to be the same for Packages in Amazon Linux 2016.3 too).

Did you install libcap-2.16 before you started trying to go build acmetool?

(According to hlandau/acme.t#1 mentioned at #322 (comment) above, this is in the README, but it's just mentioned in the text before the example on how to build, rather than as an obvious "install this first" step.... :-) )

Ewen

[sjamaan]

A binary in the package repos would be great, especially if you see how many people are having trouble compiling it.

[jwkohnen]

For folks who come here by Google search etc and have trouble building this binary: Go modules solve all build issues because @equinox0815 already went through the trouble for us to pin down dependency version that actually work. See #326

A small recipe for Debian based systems, off the top of my head, assuming you already checkout this repository:

sudo apt install libcap-dev
git remote add equinox0815 https://github.com/equinox0815/acmetool.git
git fetch --all
git checkout -b equinox0815/acmetool equinox0815/acmetool
go diff origin/master   # check if you're happy with the changes
go build
sudo dpkg-divert --add --rename /usr/bin/acmetool
sudo cp acmetool /usr/bin/acmetool

Don't ever try to run the Makefile, it will ruin your day.

[jwkohnen]

@hlandau please please merge in #326. <3

[k3a]

You may also try the old way of getting Go software (run outside any go module):

go get -u github.com/hlandau/acme/cmd/acmetool

That should produce the binary based on master branch.

[lightdot]

Just a heads up, builds just fine with mock on CentOS 8 with #326 included.

Build dependencies are simply golang, git and libcap. All in all, a really simple and straightforward .spec is all acmetool needs.

[Mrten]

other then upgrading go, no.

[SinOJosWeb]

Since my last post Feb 1 2020 acme v2 has been working flawlessly. All renews have completed, no interaction has been necessary.

[Amunak]

So ... the only thing really needed is for @hlandau to make an official release and (hopefully) have maintainers update their packages?

[samm-git]

@Amunak in fact nothing prevents maintainers to use published release now (this is exactly what i did as a FreeBSD maintainer)

[mnalis]

@Amunak Debian also built new packages upon receiving bug report; so you probably just need to contact your distribution package managers and indicate that they should upgrade the packages...

[Amunak]

@mnalis I do actually have debian on the server where I need v2, but it's only in Bullseye/testing as of now. Do you know if v2 will be backported to Buster, or do I have to experiment with backports/testing?

[jwkohnen]

If you don't want to compile yourself, but just want to download a binary from a trusted source, you can unpack the acmetool binary from debian testing directly:

joh@xanos:/tmp$ mkdir /tmp/acmetool
joh@xanos:/tmp$ cd /tmp/acmetool
joh@xanos:/tmp/acmetool$ wget https://ftp.debian.org/debian/pool/main/a/acmetool/acmetool_0.2.1-2_amd64.deb
joh@xanos:/tmp/acmetool$ ar x acmetool_0.2.1-2_amd64.deb
joh@xanos:/tmp/acmetool$ tar xaf data.tar.xz
joh@xanos:/tmp/acmetool$ file ./usr/bin/acmetool
./usr/bin/acmetool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a44542c06f02b077f39bd2b912dd8186f5356fc5, for GNU/Linux 3.2.0, stripped
joh@xanos:/tmp/acmetool$ ldd ./usr/bin/acmetool
	linux-vdso.so.1 (0x00007ffe0b07f000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f37e6e36000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f37e6c19000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f37e686d000)
	libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f37e6668000)
	/lib64/ld-linux-x86-64.so.2 (0x000055fe675d4000)
joh@xanos:/tmp/acmetool$ ./usr/bin/acmetool --version
go version go1.13.8 linux/amd64 gc cgo=true
acmetool Debian version 0.2.1-2

Go binaries are semi-statically built. They should work on any Linux system that uses glibc.

If you copy that file to /usr/bin/ on Debian remember to use dpkg-divert as in my comment above to protect your copy from being overwritten by the package manager.

Edit: changed URL to https. Note you'll get a certificate error that the hostname is www.debian.org instead of ftp.debian.org.

[samm-git]

@Amunak just use deb built for testing on any other debian. It works

[KeepBotting]

Thanks, 0.2.1 works nicely for ACMEv2 when running acmetool, no further action needed

[sjamaan]

It's June now, and still no official release. I find this really frustrating; many people reporting that the application obviously is working, yet @hlandau is MIA.

One of the reason I'm using acmetool and not one of a gazillion other ACME clients is that binaries are available for many platforms. Even if a release was made now it would take upstream package maintainers a while before updating it.

[dol]

@sjamaan Don't blame @hlandau for not releasing a binary version. There are already built versions out there. E.g https://launchpad.net/ubuntu/+source/acmetool/0.2.1-1/+build/18755756/+files/acmetool_0.2.1-1_amd64.deb taken from https://launchpad.net/ubuntu/+source/acmetool/0.2.1-1/+build/18755756
Just download it and extract the acmetool binary.

[sjamaan]

I need CentOS (and also plain Debian) packages, not Ubuntu ones. But making it an official release instead of a beta version would definitely signal to package maintainers that it's stable and can be put in a package.

[snabb]

@sjamaan If you extract the acmetool binary from that Ubuntu package, you can use it as it is on CentOS and Debian. It is the nature of binaries produced by Go compiler that they don't really care about the Linux distribution in use. They work on any distribution as long as the processor architecture is the same and there is some libc and Linux system calls available.

[Amunak]

Debian has packages, but they're in testing. You can simply download the .deb from the website and install it with dpkg -i.

Though I still find it kind of unacceptable to just abandon a project like this. My migration to v2 personally wasn't really great; the fact that you have to create a new account is less than ideal, and the DNS-01 verification hook I had to write for my provider is working less reliably than it did in v1.

[KeepBotting]

"Abandon" is a bit of a stretch imo -- the project maintainer has already added the required support for ACMEv2 in order to keep the tool viable.

"Migration" to ACMEv2 is entirely dependent on the user's particular setup and has little to do with acmetool itself. I have not created an account anywhere or used DNS hooks and everything is working fine.

A GitHub release for 0.2.1 has existed since October. The presence of a tagged release should satisfy package maintainers/build systems, and allow distribution packages to update.

Binaries on GitHub would be nice, but users should really be getting their binaries from their distribution. It is not the project maintainer's responsibility to compile software for you.

[tomwaldnz]

I built acmetool on Amazon Linux a couple of days ago. Not sure why but the version isn't showing - any tips? If anyone wants this version I can make it available to download for a couple of days.

 ./acmetool --version
go version go1.13.4 linux/amd64 gc cgo=true
build unknown

[jwkohnen]

Having version information of the main module in the binary is a hard problem in Go at the moment: golang/go#29228

The author of acmetool has "solved" that in a ... unique way: https://github.com/hlandau/acmetool/blob/master/Makefile#L42 ... but as I've mentioned above, rather stay away from running make. It may ruin you day.

[tomwaldnz]

Having version information of the main module in the binary is a hard problem in Go at the moment: golang/go#29228

The author of acmetool has "solved" that in a ... unique way: https://github.com/hlandau/acmetool/blob/master/Makefile#L42 ... but as I've mentioned above, rather stay away from running make. It may ruin you day.

Update - I worked it out from this thread.

make USE_BUILDINFO=1

Unfortunately version information isn't included. Here's version info from v0.0.67

git github.com/hlandau/acme 221ea15246f0bbcf254b350bee272d43a1820285 v0.0.67

Here's what it is when we checkout from master

git github.com/hlandau/acmetool 13ec97e4f1cd8bc1b17a70443c46f6075c9e9fac heads/master

I did try checking out from a tag and doing a build but that didn't help. Anyone know how to get the acmetool version into the "acmetool --version" output?

git clone https://github.com/hlandau/acmetool.git --branch v0.2.1

[Amunak]

"Abandon" is a bit of a stretch imo -- the project maintainer has already added the required support for ACMEv2 in order to keep the tool viable.

The author hasn't touched the project or replied for at least half a year. Considering how many people already tested v2 and said it's more or less fine, the least they could do would be marking the release as stable and providing binaries with the release (and perhaps closing this issue). It's literally like 20 clicks here on Github if they just download one of the binaries that others already compiled.

"Migration" to ACMEv2 is entirely dependent on the user's particular setup and has little to do with acmetool itself. I have not created an account anywhere or used DNS hooks and everything is working fine.

When you use the ACME API AcmeTool creates an account for you with LetsEncrypt. This is transparent for the most part, but it has some consequences. When you delete your v1 account folder you lose that account and create a new one. It's not a big deal (I hope) but it doesn't feel like the "correct" way to do things.

Not being able to just tell AcmeTool to use the new API from now on is just stupid - there should be a clear and easy migration path.

A GitHub release for 0.2.1 has existed since October. The presence of a tagged release should satisfy package maintainers/build systems, and allow distribution packages to update.

Right, the minimum I'm asking for is promoting that tag into a full release.

Binaries on GitHub would be nice, but users should really be getting their binaries from their distribution. It is not the project maintainer's responsibility to compile software for you.

I mean, sure. It's "only" a "nice to have". But especially when the compiled thing is a single binary file it's not too hard to make a simple release with binaries.

---

Alternatively the author should just say fuck it, I don't want to work on this anymore, please someone fork it and work on it. That's a commendable approach, and I would totally understand it. It's not easy to maintain public projects for free. But silence for months is really, really bad.

[CL-Jeremy]

It's literally like 20 clicks here on Github if they just download one of the binaries that others already compiled.

From the author:

[...] You will need to build this yourself as release automation is being renovated.

So that's probably the bigger issue here. No pull requests can be merged unless CI is fixed. No binaries can be built, either.

I've been working on a allowing a head build using Homebrew for macOS. It's been building just fine, even on Linux (with the insertion of a single line: depends_on "libcap after line 19). The pull request has just been submitted: Homebrew/homebrew-core#55762. It will be also be merged to Linuxbrew once it gets approved on both sides. For now please download the formula file and add that line, then it could be built as per need.

I also built two bottles (binary packages), one for OS X 10.10 and one for macOS 10.15. Both could be used interchangeably on either of them as well as all versions in between. Currently the installation of head bottles is buggy: after running brew install --force-bottle <file_path>, the following warning will show up:

Warning: Bottle installation failed: building from source.

Press Ctrl+C to terminate the process here and run the following:

brew link acmetool && brew postinstall acmetool

And acmetool is ready for use.

Downloads:
acmetool--HEAD-13ec97e.catalina.bottle.tar.gz (Go 1.14.3)
acmetool--HEAD-13ec97e.yosemite.bottle.tar.gz (Go 1.12.17)

There is also an option to enable --devel build for beta versions, though it's rarely used. Bottles can then be maintained using version tags at a regular basis. I'll see what I can do if anybody happens to be interested.

Note that Homebrew packages need to be installed to the prefix it is built for, so these binaries require the default Homebrew prefix being at /usr/local, otherwise they will need to be built from source. The benefit with Homebrew/Linuxbrew: no root is needed as long as the infrastructure is properly configured.

[tomwaldnz]

I have built acmetool 0.2.1 on Amazon Linux with Go 1.13.4. I think it should work on any Linux machine, but I don't know for sure and I'm offering no support.

It will be available on (link removed) for a few days, after which I'll delete it and won't upload it again. If it gets too much traffic I'll take it down.

[SinOJosWeb]

I get that some of you are a bit frustrated due to having to compile acmetool your self. While others have taken compiling acmetool in stride. I develop with Gentoo Linux which is a compiled flavor of Linux. Been at the CLI since 1981, been compiling Linux since 1995.

Personally I would rather compile code myself. For a number of reasons.

1. If you have reviewed the code you are compiling, you know exactly what the binary will contain.
2. Trusting binaries that has been compiled by someone else is problematic.
   a. They could have added a patch that provides them with a backdoor access or phones home
   with data.
3. When you compile code, you can compile specifically for your processor/architecture flags and or
   flags used with other software that it interacts with.
4. You can produce your own build script to build it exactly how you want to build it.
5. Compiling acmetool with GO is a trivial matter.
6. Compiling acmetool is much faster & easier than writing your own tool to deal with getting certs.
7. Nothing is stopping anyone from forking many of the letsencrypt tools for getting certs.
8. Nothing is stopping anyone from writing their own letsencrypt tool for getting certs.
9. acmetool has been working just fine in production with no issues, nothing needs to be done.
10. Dev's are infamous for ignoring how other people think things should be done. See # 8

I know most of you use binary OS's. Therefore you are more dependent upon your package manager which is focused on binary installations. Yet you still have the choice to self compile. Most binary OS's are not setup very good for compiling, or what I should clarify, is package managing for self compiled code.

With Gentoo besides having the normal package manager Portage. That handles compiling flags and all the code/packages that there are existing ebuilds for. There is also an Overlay/Layman system that allows for producing your own and or community produced ebuilds for packages outside of the normal package repository. Great for testing purposes, if you want something outside what is normally provided.

If you are running a binary flavor of Linux, if your really want acmetool available via your package manager as a binary install. Every Linux flavor has a method for adding packages that are not already available. I suggest you look into how your Linux flavor allows for adding new packages to the repository. Then become it's package manager.

Most available packages in all Linux flavors are not maintained by the code developer. Some dev's do maintain binary installs for various Linux flavors, but most do not. The complexity of knowing how every single Linux flavor is structured, is simply to tedious & time consuming, also many regularly change. Most dev's leave it to the various Linux flavor package managers to produce binary installs for their flavor. Package manager's are intimate users of their Linux flavor, they are better positioned for competently building binary installs for their specific flavor.

As for Apple products they have their own tools for compiling code. But you can also run Gentoo Portage and take advantage of Gentoo tools, think it might still be supported in one manner or another. Can also install Gentoo as your primary OS on apple hardware, and or dual boot.

Windblows, no help for the lot of you. Purchase a $20 or up ssd and install Linux. Then you can boot to either installed on each others respective drive. No worry of cross contamination or loss of data during install. If you want a binary Linux I suggest Alpine, which was originally build from Gentoo, but is now independent. For the best for development, Gentoo. Both Gentoo & Alpine are systemd free, they both use Openrc, or you can use Runit or almost any other system init. There are many reasons why you do not want to run systemd, but this is not the place for that discussion.

With Gentoo you will learn a lot about Linux & have the most flexibility, also have access to documentation & forums to self educate. If you really want to learn Linux like those of us back in the cave days. LFS, Linux From Scratch is only instructions, no package manager, every piece of code must be hand compiled, with self set compilation flags, and self handled dependencies and their respective flags. Gentoo with it's Portage package manager makes flag handling & dependency handling easy. Gentoo is essentially LFS on steroids.

Rather than expecting something to be built for you. You are much better off taking the time to learn how to be self sufficient while increasing your knowledge & experience base. Being dependent upon a binary OS is severely limited. Open your world up to the other 99% & expand out to the rest of the universe. There is much to be said about Self Reliance.

[oleg-fiksel]

I've built pipeline for building a version with ACMEv2 for all possible platforms.
I hope we will get a release and this will not be needed.
Just in case anyone needs the binary: https://gitlab.com/olegfiksel/acmetool/-/jobs/615458084/artifacts/browse/target/

[tomwaldnz]

I've built pipeline for building a version with ACMEv2 for all possible platforms.
I hope we will get a release and this will not be needed.
Just in case anyone needs the binary: https://gitlab.com/olegfiksel/acmetool/-/jobs/615458084/artifacts/browse/target/

404 page not found - perhaps you could confirm / edit your post to update the link?

[oleg-fiksel]

I've built pipeline for building a version with ACMEv2 for all possible platforms.
I hope we will get a release and this will not be needed.
Just in case anyone needs the binary: https://gitlab.com/olegfiksel/acmetool/-/jobs/615458084/artifacts/browse/target/

404 page not found - perhaps you could confirm / edit your post to update the link?

Try again please. I forgot to make repository public. 😉

[CL-Jeremy]

Homebrew/Linuxbrew tap is ready: https://github.com/CL-Jeremy/homebrew-acmetool-v2
Enjoy!

[Fyne5]

Tested on Rocky Linux 8.9 and OK

yum install -y git make tar unzip curl wget

wget https://go.dev/dl/go1.21.5.linux-amd64.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.21.5.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

git clone https://github.com/hlandau/acmetool.git
cd acmetool/
go env -w GO111MODULE=auto
make
make install

which acmetool

acmetool --version