-
Notifications
You must be signed in to change notification settings - Fork 35
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
Support for UserDefinedFileAttributeView #47
Comments
On OS X, this is blocked by JDK-8030048 which doesn't seem like it's going to be resolved soon. We might need a different way of storing xattr. |
We can now start implementing this using JDK 17 early access builds. 🎉 |
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If the underlying file system supports it, we should allow retrieval of a
UserDefinedFileAttributeView
.Maximum xattr name length on macOS is 127 chars (255 on Linux, unknown on Windows). Subtracting the prefix, we have 118 usable chars to store a base64-encoded value or in other words: 87 bytes. If we subtract a 16 byte IV, we can store up to 71 cleartext bytes.
Therefore we need to decide, if this is sufficient or whether we want a deterministic scheme (SIV) and then hash the name, which slows down listing but essentially allows any length. We need to collect some data to decide this.
One further advantage of using SIV (+hash), is the ability to cache names and thus speed up xattr listings and decryption independent of the dir. This comes with the disadvantage, that xattr names repeat across different dirs, leaking some information.
Content encryption should be the same as for file contents.
The text was updated successfully, but these errors were encountered: