Can the `op` CLI tool be compiled statically?

hairyhenderson

Hi!

I'm noticing that op is dynamically linked:

$ file op
op: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=6PMb5e52TMhuZNI_2ccD/e0_bUmkGp2msOj5d2-ol/WCzv-nuSBmRQmhzAopOv/9h0_bphpnoZre2vD5JoA, stripped
$ ldd op
        /lib64/ld-linux-x86-64.so.2 (0x7fdd46527000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fdd46527000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fdd46527000)

This isn't necessarily a problem, but when running op from systems that don't use glibc (like Alpine Linux, commonly used inside Docker containers), this is a pain.

I know it's written in Go, and so making this a static binary should (in theory!) be possible.

Is there anything stopping the op tool from being static?

Thanks,
-Dave

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

graham_1P

Hi @hairyhenderson

You are correct, our current releases are dynamically linked.

We currently have no plans to provide a statically linked version of op. While we can compile op to be statically linked, due to the low demand for such a version and the support overhead that would come with it, it is not on our development roadmap.

That being said, we appreciate question and feedback; this is valuable as it informs us what we should put on the future roadmap.

hairyhenderson

Hi @graham_1P, thanks for responding!

due to the low demand for such a version

Please consider this at least 1 unit of increased demand :wink:

Also, to be clear, what I'm suggesting is not that you provide both a dynamic and a static binary, I'm suggesting only providing a static binary.

and the support overhead that would come with it

Can you elaborate on this? If anything static binaries should lower your support overhead as you'd avoid depending on specific dynamic libraries being available...

Making the change shouldn't be much more complicated than setting CGO_ENABLED=0 when you go build.

Right now, we're having to package glibc with an Alpine-based Docker image in order to be able to use op in some scripts. It's not the end of the world, but it's extra complexity that we otherwise wouldn't need if the binary was simply static.

Thanks for the consideration!

graham_1P

@hairyhenderson

The support overhead I was referring to was in the case of having to support multiple versions of the same software, each compiled in a different way.

Interesting thought to completely swap over to static binaries. I'll chat with the team and get back to you. Your use case is compelling.

graham_1P

@hairyhenderson

We have been having a bit of chat around releasing statically compiled versions, and its an interesting idea we may pursue into the future. We can see a variety of benefits and drawbacks to each of a dynamically compiled binary and a statically compiled binary.

But that is just a discussion at this point. If we do go that route, it would require a good amount of build validation to ensure stability.
Therefore in the short term I can say it is not on our development horizon.