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

Read each identity file in a single pass #354

Closed

Conversation

kernelmethod
Copy link

@kernelmethod kernelmethod commented Nov 19, 2022

read_identities now performs a single pass over each identity file in order to read it. Besides being perhaps a bit more efficient by reducing the amount of I/O performed by rage, the main improvement that this allows is that it's now possible to pass in the key from another program or through some sort of keychain. For instance, it's now possible to pass in a key using process substitution, i.e.

rage -d -i <(...) encrypted_file.age

This also makes the behavior of rage a little more consistent with the reference implementation (which allows this behavior).

read_identities now performs a single pass over each identity file in
order to read it. Besides being perhaps a bit more efficient by reducing
the amount of I/O performed by rage, the main improvement that this
allows is that it's now possible to pass in the key from another program
or through some sort of keychain. For instance, it's now possible to
pass in a key using process substitution, i.e.

        rage -d -i <(...) encrypted_file.age

This also makes the behavior of rage a little more consistent with the
reference implementation (which allows this behavior).
@kernelmethod
Copy link
Author

It seems like the only downside of this (other than potentially being an abuse of the command-line interface) is that this would store the identity file entirely in-memory. As far as I know, though, there aren't many use cases where an identity file would be large enough to cause that to be a significant issue. Would be happy to be corrected, though.

@str4d
Copy link
Owner

str4d commented Jun 12, 2023

Given that all of the parsers are internally combinatorial, I think it would make more sense to rework this function to itself be a combinatorial parser around each alternative's inner parser. The existing parsers already cache the data in memory, but by only reading as we validate it against a supported parser, we don't run the risk of loading a giant unsupported file into memory.

@str4d
Copy link
Owner

str4d commented Feb 3, 2024

Replaced by #458.

@str4d str4d closed this Feb 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants