Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI always defaults to unecrypted json #5194

Closed
1 task
ajorgensen opened this issue Apr 10, 2023 · 2 comments · Fixed by #5197
Closed
1 task

CLI always defaults to unecrypted json #5194

ajorgensen opened this issue Apr 10, 2023 · 2 comments · Fixed by #5197
Labels
bug cli CLI Application

Comments

@ajorgensen
Copy link
Contributor

Steps To Reproduce

  1. bw export --output /tmp/test --format asdfasgas; cat /tmp/test
  2. See there is no error from the cli and the output is unencrypted

Expected Result

I expect the CLI to return an error saying that the format is invalid. Always defaulting to an unencrypted json blob seems like it could have some consequences. For example, this came up when I put in --format json_encrypted rather than --format encrypted_json. I was surprised when I opened the json blob to see my data unecrypted.

Actual Result

CLI always defaults to raw unecrypted json even if the format provided is giberish.

Screenshots or Videos

No response

Additional Context

No response

Operating System

macOS

Operating System Version

No response

Shell

Zsh

Build Version

2023.3.0

Issue Tracking Info

  • I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
@ajorgensen ajorgensen added bug cli CLI Application labels Apr 10, 2023
ajorgensen added a commit to ajorgensen/bitwarden-clients that referenced this issue Apr 11, 2023
Issue bitwarden#5194: bitwarden#5194

The cli previously would take any value for the export format and
default to unencrypted json if it wasn't a supported format. This
behavior is a little dangerous because if for instance typed
"json_encrypted" instead of "encrypted_json" and naively saved the file
you might be surprised to learn the payload was not actually encrypted
even though the command completed successfully.

This change adds a guard clause when converting the string value passed
in via `--format` into the type `ExportFormat` to ensure that the format
provided is one of the supported types.
@TroyBW
Copy link

TroyBW commented Apr 13, 2023

Hi there,

Thank you for your report!

I was able to reproduce this issue, and I have flagged this to our engineering team. We have also noted the PR you have submitted.

If you wish to add any further information/screenshots/recordings etc., please feel free to do so at any time - our engineering team will be happy to review these.

Thanks once again!

@ajorgensen
Copy link
Contributor Author

No worries at all. Please feel free to reach out if you need any more information or have any alterations you'd like me to make to the PR.

@djsmith85 djsmith85 linked a pull request Apr 13, 2023 that will close this issue
djsmith85 pushed a commit that referenced this issue Apr 17, 2023
* Fail on unsupported export format

Issue #5194: #5194

The cli previously would take any value for the export format and
default to unencrypted json if it wasn't a supported format. This
behavior is a little dangerous because if for instance typed
"json_encrypted" instead of "encrypted_json" and naively saved the file
you might be surprised to learn the payload was not actually encrypted
even though the command completed successfully.

This change adds a guard clause when converting the string value passed
in via `--format` into the type `ExportFormat` to ensure that the format
provided is one of the supported types.

* Move isSupportedExportFormat to private method
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug cli CLI Application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants