Rebuild & complete the CLI about buttercup-cli

[perry-mitchell]

Hi @deltaskelta! Thanks for the interest.

There's a rework branch but I never really got going with it. Unfortunately it probably needs scrapping and redoing. On top of that we need to decide how it should be used. I would hope that would support some items that the other apps support:

• ArchiveManager for managing which vaults are available
  • Stores configs in some kind of storage (would be a file in this case) - encryption not necessary as master password is required to use any of these
• Unlocking and locking vaults
  • Controls for a vault are available once unlocked
  • Maybe some way to background the app? Would be useful for interacting with other programs
• Adding/Editing/Removing entries and groups

I'd be interested to hear your opinion on this process based upon your experience with gopass!

Yes, that error is due to the core being too far out of date.

[jeffwillette]

Just as an update. This is and I will be working on this in my spare time. I'll first design the API and make sure it is agreeable and then I'll try to implement it.

Would you prefer me to have a long running pull request that I push commits to, or should I work on everything in my own fork?

[jeffwillette]

• ArchiveManager, could it be as simple as letting the user control a config file with the archive locations?

• Unlocking of Vaults, I picture it working like sudo and gopass where it will prompt you for a password once and then let you operate for a period of time before asking for it again. (I think sudo is like 15 minutes but it could be made longer or shorter)

  • can you explain what you mean by background the app?

[perry-mitchell]

ArchiveManager, could it be as simple as letting the user control a config file with the archive locations?

Yes! I think it could default to a file in ~/.config or the user's AppData folder, but a CLI arg to specify this would be good to have. The ArchiveManager's config can just be serialized and parsed to and from said file.

I picture it working like sudo and gopass where it will prompt you for a password once and then let you operate for a period of time before asking for it again. (I think sudo is like 15 minutes but it could be made longer or shorter)

can you explain what you mean by background the app?

This is all the same thing for me actually. Once unlocked, the app needs to remain "open" so that authentication isn't repeated every command. The app has to be in the background for this to work so that the vault contents are kept in memory. We can't store the master pass or any unencrypted content anywhere so in-memory is the only way I can see it working.

[jeffwillette]

Ok I think I am getting a better handle on it now.

Dropbox and the other cloud providers seem to have headless versions to run on servers which is good. This means that the CLI can get around the whole OAuth process by leaving it up to the user to supply a cloud accessible archive file.

I checked out the desktop and Android app to make sure that this would be consistent and I came across something odd. The desktop app has the ability to use a local archive file so one would be free to use their own scheme or use one of the cloud providers.

The Android app, however, only allows the user to select one of the cloud providers and there is no option to do something custom. I foresee CLI users being much more likely to want to use a custom scheme like a local Google Drive folder that gets synced, or a code repo, etc.

Is there any plan to offer custom schemes for the Android app?

[perry-mitchell]

Dropbox and the other cloud providers seem to have headless versions to run on servers which is good. This means that the CLI can get around the whole OAuth process by leaving it up to the user to supply a cloud accessible archive file.

This is difficult because Dropbox requires a token, which is collected by signing in within the browser. We should probably stick to local files only for the first release.

Is there any plan to offer custom schemes for the Android app?

Yes, via buttercup/buttercup-mobile#32.

I think if we aim to get something simple out for the first version, we'd be in a better place to add more complex features as a second step. Local files only.. 😊

[jeffwillette]

Yeah thats what I was getting at, it would be the users responsibility to provide a file location from any means.

Would you be opposed to having this written in typescript?

[perry-mitchell]

On a fundamental level neither of us have anything against writing projects in typescript; this remains a broader question for the whole Buttercup suite. We haven’t yet felt that’s it’s necessary to write Typescript in any Bcup project, and it also raises questions about the amount of contributions we’d get on JS vs TS. Besides that I can definitely see it being useful as bcup has a lot of strong type cases. Maybe in the future we’ll encompass it but right now I think JS is fine 😊

[perry-mitchell]

A PR could be really cool if that works for you, but I'm happy with whatever you choose. It'd be amazing if you could help get this app going!