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

file info error on encrypted files #1051

Open
willbprog127 opened this issue Oct 21, 2024 · 4 comments
Open

file info error on encrypted files #1051

willbprog127 opened this issue Oct 21, 2024 · 4 comments
Labels

Comments

@willbprog127
Copy link

Greetings,

When issuing the following command for a client-encrypted file stored on b2:

./b2-linux file info b2://myCuteFunBucket/syncfiles/myCuteFunFileName

I get the following output:

UserWarning: bad request exception with an unknown `code`. message=None, code=None
ERROR: None (None)

The documentation at https://b2-command-line-tool.readthedocs.io/en/master/subcommands/file_info.html does not mention the need to use the SSE_C key, although I tried with this and it still produces the same error.

b2-linux account authorize was performed successfully before this.

Using file info on a non-encrypted file works as expected.

Using b2 command line tool version: 4.1.0. I also tried with b2v3-linux and I received the same error.

Thanks 👍

@ppolewicz
Copy link
Collaborator

Reproducible, though b2 file info works for non-encrypted files. Doesn't seem to be actually caused by the CLI, but something deeper. I called for help.

@willbprog127
Copy link
Author

though b2 file info works for non-encrypted files

Yes, this was mentioned above.

Doesn't seem to be actually caused by the CLI, but something deeper. I called for help.

Thank you 👍

@ppolewicz
Copy link
Collaborator

On the client we should catch the 400 and advise the user to either use b2id:// or to set the proper encryption environment variables or to use ls. The server knows the metadata of the object and could return it, but refuses to do so because the HTTP standard says it should return the exact same thing a GET request would get, except the body. Unfortunately the server cannot return the body with the error in case of a HEAD request, so it can be confusing to the user.

In a new version the CLI will assume that the 400 is caused by SSE-C encryption (either absence of the keys in the env variable, or mismatch) and will return a helpful message to the terminal.

@ppolewicz ppolewicz added the bug label Oct 24, 2024
@willbprog127
Copy link
Author

@ppolewicz Thanks for that.

When using file info I did set the proper environmental variables for SSE-C (which work fine for all other commands like upload and download), so not sure what else could be the issue. Will try with the new version when it comes out.

Thanks! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants