1Password CLI is fussy about TTYs

gnachman2

I upgraded from 2.0 to 2.5 of the CLI this week and it broke the iTerm2 integration. The issue seems to be that the CLI really cares about whether stdin is a tty or not.

These commands fail to open a biometric auth window when stdin is not a TTY and simply seem to hang:

• op user get --me
• op item create --category=login--title="whatever" --tags="whatever" --generate-password --format=json username="whatever"

While this command doesn't work at all when stdin is a TTY:

• op item get --format=json --no-color -

For some reason I don't understand, I can't reproduce this from a regular shell (.e.g, op user get --me < /dev/null does show an auth window) but when my Cocoa app forks & execs op user get --me with a pipe for file descriptor 0 it does hang, while giving it the slave side of a pseudoterminal doesn't hang.

Is this intentional? I'm a little worried that I may have missed some cases where the TTYness of fd 0 is wrong. It would be nice if op didn't care so much about this.

If there's a good reason for requiring a TTY in general, it would be nice if if providing a TTY didn't break anything. I don't see a good reason why op item get --format=json --no-color - should fail with a TTY, and the error it gives is not great:

[ERROR] 2022/07/06 23:28:40 "-" isn't an item. Specify the item with its UUID, name, or domain.

Thanks!

---

1Password Version: 8.8.0
Extension Version: Not Provided
OS Version: macOS 12.4
Browser:_ Not Provided

Horia.Culea_1P

Hey @gnachman2 , I are sorry for the late reply.

First of all, thank you for all the feedback! From the looks of it, I see that the majority of the commands where the "tty"-ness seems to be an issue are those which accept piped input.

We have added a change, a few releases back, that allows piped input to be specified without an argument placeholder (-) and we have noticed that in some environments where the CLI is called programatically, it seems that it mistakenly detects piped input, where in fact there is nothing piped into it.

We have not yet added this on our short roadmap, although it is something that we want to prioritise, since it impedes the integration between the CLI and tools where this bug is apparent.

That being said, I would expect a command such as op item get --format=json --no-color - to fail, regardless of whether a tty is present or not, since the dash signals that input would be piped into the command, when in fact, there is nothing piped. Is there anything that I am misunderstanding here?

We'll make sure to update you when any developments around this are made, and, in the meantime, don't hesitate to leave us any additional feedback that you may have. Looking forward to hearing from you!

Best,
Horia

gnachman2

That being said, I would expect a command such as op item get --format=json --no-color - to fail, regardless of whether a tty is present or not, since the dash signals that input would be piped into the command, when in fact, there is nothing piped. Is there anything that I am misunderstanding here?

My app is a little unusual in that it's invoking the CLI not from an interactive shell but with fork+exec (or forkpty+exec) because my app provides a UI that uses the CLI as its backing data source. That aside, it's convenient to copy-paste into the CLI during development, and the TTY requirement adds an extra hurdle.

Thank you!

mickael

I encounter a similar or related issue with the python wrapper I developed around op cli.

This wrapper helps to create various normative things: server account / database account / ssh keys / website accounts.

Now all op item create commands I call fails silently while returning a 0 return code.

You can have a look at how I call op cli from my python script here: https://github.com/mickaelperrin/onepassword-tools/blob/653649eb851c54b6638ba9d339bd12112ee7b33f/onepassword_tools/lib/OnePasswordUtils.py#L168

 e = os.environ.copy()
        p = subprocess.Popen('op ' + cmd,
                             bufsize=0,
                             close_fds=True,
                             env=e,
                             shell=True,
                             stdin=subprocess.PIPE,
                             stdout=subprocess.PIPE,
                             stderr=subprocess.PIPE
                             )
        try:
            out, err = self._communicate(p, inputstr=inputstr)
        except subprocess.CalledProcessError:
            out = ''
            err = ''
        rc = p.returncode
        return rc, out.decode('utf-8'), err.decode('utf-8')

For example, the cmd item create --no-color --format json --template /var/folders/t0/4z0_cwt538d4qkkvnpb81_6m0000gn/T/tmpvo18gwde --title="USER test ON test.fr" -
returned an empty string for err, out and rc is 0.

@Horia.Culea_1P Can I return back to an old version of op-cli while this issue is resolved ? In which version that change was introduced ?

mickael

It looks like, I didn't update update op cli since I upgraded my script for 2.0.0.

I tried every release back to 2.0.0 and only 2.0.0 was functional.

Indeed, between 2.0.1 and 2.3.1, my script fail with the error: "Cannot create an item from template and stdin at the same time"

After 2.4.0, this is the same problem I reported in my last post.

Horia.Culea_1P

Hey @mickael , thank you for reaching out to us. We are aware of this problem, and hope to be able to prioritise it sometime in our next development cycles.

In the meantime, the problem that you describe can be circumvented by making use of the piping functionality of op item create. Rewriting your command to something like:

cat /var/folders/t0/4z0_cwt538d4qkkvnpb81_6m0000gn/T/tmpvo18gwde | op item create --no-color --format json --title="USER test ON test.fr" 

should do the trick. Let us know if this helps, and otherwise we can try to find other solutions, before we're able to roll out a stable fix.

Thanks!

Best,
Horia

mickael

@Horia.Culea_1P Thanks ! I get it working indeed with 2.6.0 by piping the content of the file.

Horia.Culea_1P

Great to see this worked. We'll keep updated when this bug gets tackled.
Let us know if we can help with anything else, in the meantime.

Best,
Horia

Horia.Culea_1P

Hey @mickael ,

We just released CLI 2.6.2, which we expect to solve this issue. Let us know if that works for you!
https://app-updates.agilebits.com/product_history/CLI2#v2060201

Best,
Horia