Rewrite the tool from scratch with nicer name (a8c-secrets) and CLI API (v1)
#29
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
+ cargo fmt the code
- `update` -> `encrypt` - `apply` -> `decrypt`
For better code organization
- Replace unwrap_or_default() with proper error handling for YAML parsing - Fail explicitly with descriptive error messages when YAML is invalid - Prevent silent failures that could mask security-critical file corruption
- Add validation to detect when ~/.mobile-secrets is in detached HEAD state - Extract duplicated validation logic into private helper function - Provide clear error message with instructions to fix the issue - Prevent cryptic failures when repository is not on a proper branch - Apply fix to both get_mobile_secrets_head_sha1 and check_mobile_secrets_up_to_date functions
- Improve error messages to be more descriptive and actionable - Add context and suggestions to simple error messages - Use consistent formatting with multi-line messages for complex errors
- Replace to_string_lossy() with to_str() and proper error handling - Add validation for UTF-8 characters in filenames - Provide clear error messages when filenames contain invalid UTF-8 - Prevent potential panics when processing files with non-UTF-8 names
- Add validate_source_path function to paths.rs module - Validate source paths are relative to ~/.mobile-secrets (not absolute) - Prevent path traversal attacks by blocking '..' in source paths - Check that source files exist and are actually files (not directories) - Integrate validation into encrypt command - Keep existing detailed error messages for file operations
- Add tracing and tracing-subscriber dependencies for structured logging - Add --verbose/-v global flag to CLI for debug-level logging - Initialize logging with appropriate level based on verbose flag - Add debug and info logging throughout commands - Log command start/completion and key operations - Provide better debugging capabilities for troubleshooting
In preparation for unit tests needing to bypass interactive prompt
- Around Config/SecretFileEntry structs - Around constants
Especially now allow the various implementations to take the repo to operate on as a parameter, so that in real world use case we'd still inject the `current_dir()` to those calls, but during tests we can inject a `tempdir()` to isolate the tests to temp directories and avoid having them pollute the current folder they're run from or interact with each others.
AliSoftware
changed the title
a8c-secrets) and CLI API (v1)
Author
|
cc @wzieba as you wanted to take a look at the code 🙂 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See: AINFRA-882
What?
This is a brand new implementation of a
a8c-secretstool I vibe-coded with Claude and Cursor some time agoWhy?
The goal of this fresh implementation was to provide a better and more intelligible name and API for the tool (given how confusing the API of
configurewithconfigure apply/configure updateis and have been confusing most of us many times).How?
This implementation still relies on the
~/.mobile-secretsrepo as a backing store though, so the high-level concepts and ways of working are still very similar to the originalconfigure, with the key differences being:a8c-secretsa8c-secrets setup,a8c-secrets decrypt,a8c-secrets encrypt.a8c-secrets/instead of.configure-files.configureJSON file is now replaced by a.a8c-secrets/config.yamlfile (which is now inside the.a8c-secrets/directory instead of being a sibling like.configurevs.configure-files/files were).a8c-secrets/config.yamlfile is intended to be manually edited when ones wants to add/remove/change the list and locations of secret files needing to be encrypted/decrypted—as opposed to howconfigurehad complex dedicated subcommands likeconfigure_add/configure_updatethat added to the confusion.What's Next
Idea 1:
a8c-secretstool without needing a~/.mobile-secretsrepoAfter discussing about the topic of secret files in our repos at our Prague team meetup, we settled with the idea that the future tool we want to replace
configureshould actually even change the way it's working internally to not rely on the~/.mobile-secretsrepo at all anymore (and instead always encrypt/decrypt files using the shared symmetric encryption key of that repo, that devs could have set up as an env var on their machines to decrypt files locally just like CI already does)That would completely eliminate the need for having a separate
~/.mobile-secretsrepo (which also has the drawback of containing all the secrets of all the repos, instead of only the secrets of repos a given dev is supposed to have access to) and simplify the way to use such tool even more.Idea 2: Use existing tool instead of re-inventing the wheel
Since that discussion though, I pondered that we probably were not the first ones to have this need, and that there sure could already exist similar tools in the wild.
A quick search led me to
transcryptfor example, which seems to be a very interesting candidate, especially as it would make the encryption/decryption totally transparent (using git filters to encrypt the files on commit/push and decrypt them on the fly on checkout). To be continued.