"1Password can't save or fill in sudolikeaboss."

[fivesixzero]

After doing a round of updating on my dev system recently I'm seeing this when trying to invoke sudolikeaboss:

I've done cleanup around slab by removing, reinstalling 0.21 from brew, and also dropping in the binary from sudolikeaboss_0.3.0-beta1_darwin_amd64.zip in issue #29.

No dice. Same behavior every time I trigger slab via hotkey.

OS version: 10.12.6 Chrome version: 59.0.3071.115 iTerm2 version: 3.1.beta.5 1Password version: 6.8 (680015) from AgileBits store 1Password Chrome extension version: 4.6.7.90

The environment's pretty clean and I've got sudo to change things if needed. The only real contender for active interference would be the presence of Sophos Central Endpoint (v9.6.3, engine 3.68.0, threat data 5.41) antivirus but its logs are clean of any indications of interference. Normally the real-time monitoring gets quite verbose when it decides to get all up in my grill.

[fivesixzero]

Ahh, did another remove/reinstall cycle and this time sudolikeboss register did what it should do. Everything's working again. :)

It looks like https://github.com/ravenac95/sudolikeaboss/issues/29#issuecomment-278988719 from @squarecandy has like the most concise rundown on how to get it done quickly.

Hope this helps anyone else who runs into this in the future. edit: Still a problem. See below. :(

I wish I had more time to dive into the items brought up in #41 and elsewhere. But like Ravenac95, I've been busy. life is hard. 🤷‍♂️

Speaking of @ravenac95 - thanks immensely for this little utility. Its at the core of most of my workflows, fun and otherwise, and its saved me innumerable hassles over the last few years.

[fivesixzero]

FYI: The problem popped back up again but I don't think it was slab's fault. Looks like something with Chrome's native messaging and a directory lacking parents. Or something.

https://support.1password.com/kb/201707/

[lrosenstein]

My experience has been that the dialog pops up if 1P is locked at the time sudolikeaboss is run.

[cmbuckley]

@ravenac95 I would suggest that this issue be reopened, or I can create a similar one if preferred. The issue is still present in 0.2.1 and 0.3.0-beta1, but only when 1Password is locked. Prior to 1Password 6.8, the 1Password Mini unlock screen was correctly presented in this case.

[fivesixzero]

Reopening since this does look like a regression of sorts, per @cmbuckley's comments.

I've been able to replicate identical behavior.

Expected:

When 1Password is locked and slab is invoked, the 1Password Mini unlock screen appears and allows unlocking.

Current Behavior:

When 1Password is locked and slab is invoked, the error message mentioned in the original report appears. This can be worked around by opening 1Password and unlocking it directly.

[DanFreed]

I can confirm this behavior as well. slab works fine as long as the main 1Password app is unlocked. Once the lock times out, slab shows the error instead of 1Password mini unlock screen.

I've already run the registration process.

I think this started with 1Password 6.8.

$ sudolikeaboss -v sudolikeaboss version 0.3.0-beta1

[Ralnoc]

This is definitely tied to 1Password 6.8 and relates to the work they are doing for the new messaging system. They have an eventual plan to remove websocket support, at which point this will stop working.

In my spare time I've started looking at the code to migrate it over to the chrome messaging system as was suggested in issue #29 . However I have extremely limited time between family and work so I have no idea when anything will come of it. The best case scenario is that @ravenac95 will be able to get into working on migrating this over.

[meastes]

Looks like an update was released today to the 1Password app (6.8.1) that completely breaks slab. The checkbox for code signing has been completely removed.

[Lingnik]

:point_up: Ditto. Instructions here https://github.com/ravenac95/sudolikeaboss/issues/29#issuecomment-278988719 also do not resolve this on 6.8.1 with iTerm 3.0.15 and sudolikeaboss 0.3.0-beta1.

[guiagaing]

Got the same issues . I am so dependent on sudolikeaboss now for my day2day. Is there any solution around ?

[thorhs]

Same here, thankfully I haven't updated to 6.8.1 yet, but when that happens my life will become harder.

Is there anything I can do to help implement this? I have intermediate experience with Go, if that helps.

[m4rkw]

NOPASSWD: ALL is probably the sensible workaround for now, since if someone has access to your local account getting root is never going to be difficult.

[eugene-chow]

If you unwittingly upgraded to 6.8.1 (like me), downgrading to 6.8 can be done by installing the pkg at this link. The download path is intuitive. Just get the download URL from the official page and change the pkg version to the one you desire.

[GitHubGreg]

Thanks for the link, good temporary solution.

[ChristinWhite]

So is this actually fixable or are we out of luck now?

[nigelm]

It is fixable, but it needs someone with the appropriate skillsets (golang, reasonable familiarity with protocol implementation, some crypto) and more importantly some available time to do the work.

What needs doing is a re-implementation of the communications channel back to 1Password, which has previously used Websockets (which 1Password has deprecated as of 6.8.1) to use Chrome Native Messaging.

The guys at 1Password - the contact appears to be @rudyrichter - have some documentation available for this - see comments within issue #29 .

It looks like @brycekahle has some work in place at https://github.com/brycekahle/sudolikeaboss but I do not think he has (started) integrating the Native Messaging support, so that code works with 1Password 6.8.0 as its latest release, and will fail with 6.8.1 onwards.

As ever the problem is that these things are done in people's spare time - and for example I am going to be very short of available time until the new year (and I am an absolutely newbie at golang).

[brycekahle]

It looks like @brycekahle has some work in place at brycekahle/sudolikeaboss but I do not think he has (started) integrating the Native Messaging support, so that code works with 1Password 6.8.0 as its latest release, and will fail with 6.8.1 onwards.

Correct. I'm awaiting contact from AgileBits on how to add Native Messaging support. They indicated that code signing may be necessary among other things.

[meastes]

Looks like the CLI they announced yesterday is another possible option for integrating with 1Password. This would allow us to bypass the need to codesign.

https://support.1password.com/command-line-getting-started/

[rudyrichter]

@meastes,

something to be aware of is that the CLI only works with 1Password.com accounts.

[ChristinWhite]

I briefly chatted with one of the AgileBits devs on FB and while it wasn't official, it sounds likely that code signing will continue to be required. He did recommend the CLI though for hosted accounts and said that they use it for some of their own tools.

[csawyerYumaed]

@rudyrichter can you connect @brycekahle with the documents he needs on how to add Native Messaging support? Bonus, just make them publicly available here!

[DanFreed]

I know that it isn't a fix for sudolikeaboss, but while we await that fix I posted a script that uses GPG and the pass utility to provide a similar experience as sudoliekaboss and 1Password.

Its not perfect, but it seems to work well enough for the moment. You can get it here: https://github.com/DanFreed/passprompt.

[brycekahle]

FYI I fixed this issue when you are using 1Password 6.8 (not 6.8.1 😭 ). The fix is available in my fork version 0.3.1.

[SanderAtom]

Any ETA on a fix for this? It's 6.8.2 by now, should I downgrade to 6.8 ?

[bwoodruff]

Ben from AgileBits here. We've posted a response for this request on our discussion forums:

https://discussions.agilebits.com/discussion/comment/394873/#Comment_394873

[fivesixzero]

@bwoodruff Thanks for sharing. I'm looking forward to seeing what you guys can come up with to help with non-traditional utilities like this. There are a lot of us that live in terminals and, for quite some time at least, 1Password worked great to store secrets with slab helping us get them out of 1PW with a quick hotkey in our terminal env.

That's the real problem I hope can be solved. I'm not tied to slab as the solution. But we all just want to slam a hotkey, auth with 1PW (if needed), then paste an item from 1PW that's tagged for that hotkey (or quickly type in a search in a popup for the one we really need).

[bwoodruff]

You're welcome. I totally get it. Our ops folks tend to live in terminals as well, so we definitely understand the utility that slab brings. We appreciate the efforts of 3rd party developers such as @brycekahle to offer additional functionality on top of the 1Password platform.

[Ralnoc]

@bwoodruff - If we wanted to work on a solution in another programming language (unfortunately I am not proficient in Go) where would we go to read up on the API to communicate with the local 1Password application using the chrome native messaging process? And the requirements it has for implementation? (Like the fact that the communication has to be signed)

As much as I would love to work towards a solution with slab, I also would like a solution that works sooner, rather than later.

[csawyerYumaed]

@Ralnoc It's a no go, because 1Password > 6.8 requires anything that talks to it to be signed (currently) and 1Password has just declared(see the forum https://discussions.agilebits.com/discussion/comment/394873/#Comment_394873 ) they refuse to sign anything 3rd-party, including slab. So they won't sign your stuff either.

[bwoodruff]

Right. This isn’t a slab problem. It isn’t as if slab is doing something wrong, and another developer could do it right. We just aren’t going to allow native messaging communications from additional apps. We are looking to build a solution that would allow utilities like slab to interface with 1Password, but it isn’t going to be an immediately available offering. The best I can offer for the immediate future would be to downgrade to 1Password 6.8.0.

[csawyerYumaed]

@bwoodruff the other solution is just allow your 'op' tool to talk to the local 1password process and do native messaging. That would solve 99.99% of our issues with your 'op' tool, and there are already wrappers that do iTerm2 coprocess tie-in, and are trivial to write. Especially since you have committed to continue to support local vaults, it seems silly that 'op' won't also support this.

[bwoodruff]

That is a big “just.”

[peacetara]

Hi Everyone. I've written a replacement for sudolikeaboss that should work with 1Password > 6.8.0, by talking directly to the SQLite data file It's not ideal, as then I require your Master Password, and that's not the best move security wise, but in light of the recent decisions by 1Password, I do not see many other choices. Luckily everything stays local so that's a win.

Code repo here: https://github.com/peacetara/slab and the current python implementation and instructions are here: https://github.com/peacetara/slab/blob/master/src/python/README.md

[bwoodruff]

Caveat emptor: AgileBits cannot ever recommend entering your 1Password Master Password into anything other than 1Password. We have no reason to believe malicious intent with utilities that work with the 1Password database, but we also have not verified the code to be able to say that isn’t the case.

That said, we love that people create utilities to interact with 1Password. It is one of the reasons why our data format is open.

If a utility is going to directly access 1Password data we would suggest interacting with OPVault files, which can be created by setting up Folder Sync, instead of the SQLite database. Some of the reasons for that being that OPVault is a well documented format, and is less likely to change. The SQLite database is intended to be more flexible to change. The downside of that is that OPVault files cannot be automatically synced for 1Password membership accounts (you’d need to create a separate standalone vault, copy your membership data to it periodically, and then use Folder Sync to save an OPVault to disk).

Thanks for your efforts here, @peacetara.

[peacetara]

Absolutely this code is in no way meant to be endorsed by AgileBits @bwoodruff. I'd love an AgileBits solution to this problem, but you've backed us(me at least) into a corner as it were, with > 6.8.0.

I have no intentions of moving this off of the SQlite DB, but you are correct your Sqlite format is 100% undocumented, but it tends to follow the OPVault format for the most part, so it's not overly complicated. Hopefully you will document it at some point, since you say you have an open data format.

[m4rkw]

@peacetara doesn't storing the master password in a file readable by your local user kind of undermine your security significantly and perhaps also unnecessarily? If you're doing that would it not be safer to just store a dictionary of the passwords you actually need to use with sudo in a flat file rather than the keys to (I'm guessing..) everything in your life?

[peacetara]

@m4rkw Well, perhaps. It's not required to store it in a file, but it definitely makes life easier. If an attacker gets to run processes on your local machine (like to say read the file), they can also read memory, and all is lost, regardless... assuming your 1password application is unlocked(and let's face it, most of us keep it unlocked) while using the computer.

The file is only 1 option, you can also put it in an ENV variable SLAB_PASSWORD and you could put that variable down to only be within the coprocess(instead of your entire shell) -- I haven't tested this, but I don't see why it would not work.

You could also just put the file there while running iTerm2 and actively doing things, and have your logout remove the file (say by putting the file on a ramdisk, or put it in /tmp, so it will auto-get erased, on shutdown, etc) you can set SLAB_PWPATH to point to whatever you want.

Ideally we would just do what sudolikeaboss does and poke @ 1password directly, but AgileBits has now made that impossible, so we are forced to get creative.

The above options are just sort of scratching the surface. Again, it depends a lot on your threats. If you have better suggestions, I'm all ears, and I happily accept pull requests.

[m4rkw]

@peacetara i guess you could implement a locking mechanism similar to how 1P works. cache the master key in memory and expire it after a period of time. for bonus points cache it in a daemon running as a different user so the main user can't scrape it from memory but can request passwords from it when it's in an unlocked state.

[peacetara]

@m4rkw running as a diff. user would not solve reading memory issues, if you have local box, you get everything, but it would raise the attack surface and make it harder.. but I imagine it would be a nightmare in install/setup costs. We could have a little daemon that stores the master and overview decryption keys and has basically zero footprint otherwise. that would be a good idea.. something like what gpg-agent does.

[jabofh]

@peacetara You could also consider using the MacOS keychain to keep the password... You would have to system() out to use it, I suppose:

eroux@Fafnir$ security find-generic-password -a 'slab' -w
no, this is not really my very funky password!
eroux@Fafnir$ 

This way you can query it every time you need it, but still make it (mostly) the OS's problem to safeguard it.

Ref: Keychain Access From Shell Edit: Cleaner Syntax

[Ralnoc]

@bwoodruff Out of curiosity, is there a scenario where someone could work with AgileBits to make a command line tool that replaced the features of slab? I think everyone here would agree that they would have no issue with using a tool that is ultimately owned by Agilebits as long as the end use behavior replicated that of slab (i.e. Talks to the local 1Password application using Chrome Native Messaging to trigger it to inject the password into the terminal.)

I would personally be willing to look into a solution for this and hand over my code to AgileBits, if I thought it was something they would be willing to discuss.

[Ralnoc]

@peacetara In addition to the comments above, what you have written doesn't seem all that different from AgileBits' 'op' command line tool. The only difference being that it accesses the local vault files instead of talking to their remote store. Is that correct?

[petertwise]

Read this comment from @brenty here: https://discussions.agilebits.com/discussion/comment/394491/#Comment_394491

Unfortunately, it sounds like they are all in for their encrypted/hosted solution and the CLI tool they already have as the way forward and they believe that this is as secure or more secure than a local only situation. So I don't think it's about getting permission/access to someone's existing code for slab/sudolikeaboss/etc. I think it's that they already built the tool that they want to promote and they don't want to maintain another one.

Bummer.

[peacetara]

@Ralnoc basically yes. It opens the 1Password SQLite database file directly. See how it works on this document: https://github.com/peacetara/slab/blob/master/src/python/README.md

[Ralnoc]

@squarecandy From what I read, the thing I'm trying to solve, and in theory slab solved, actually fits the scenario that @brenty was suggesting in that post. I personally do not use local vaults. I'm using the online ones. I'm looking at a solution that effectively implements what the chrome extension does, only in a terminal window.

Something that registers securely with the local application, and then uses the approved methods of communication to get the proper password using the 1Password popups to inject them into the terminal.

To say that is not a viable implementation seems like it is in conflict to the existence of the Chrome/FireFox plugins. It seems to me that as long as it functions in an approved way, and they can ultimately control the code for it, it should fall into the same category.

I can completely understand AgileBits being uncomfortable with the idea of a tool like this being out there that they don't ultimately control. Because it could, potentially, contain malicious code that could compromise the integrity of your password vault. But if they owned and controlled the code, that seems to mitigate the issue.