Neat tool. I could see myself using this for some low-risk things that I currently store in plaintext. Some thoughts…
- The github page doesn't give me a good sense of how it works / what it looks like to use. You list supported commands, but there's no indication of what running them spits out. I'd suggest including the output of commands. For example, I wondered if I would be prompted for multiple lines of text or if I would be expected to input something in a key=val pair, etc. I would usually write off something unclear like this, but I was curious and downloaded the binary to find out. (Answer for others: multiple prompts for text input.)
- Initializing an environment asked me to set a password but didn't test the password for typos. If I had a mistake in my password, I wouldn't know it and everything that I committed would become irretrievable.
- In ~90 sec of testing, I see that my lockify env directory was created in the directory where I fired the binary. I don't see a config file in the first level of the repo and I didn't go hunting, nor did I test the behavior under varied conditions. Why wasn't it stored at the root of my home dir? Will lockify remember the path to the env file(s) after I change dirs and call it again? How do I specify a path that matches my expectations regardless of where I am within the filesystem when I call the tool? It's really unclear what behavior to expect and it shouldn't be up to me to figure it out.
- When I ran the command to retrieve a key, I wasn't asked for my env password. Why not? What's the value of using this tool if anyone can just walk up to my workstation and output my secrets without getting challenged? And what are the conditions that would change the result? When will it need a password and when will it not? Again, not my job to figure out how the tool behaves for me to decide if it's right for me.
As I mentioned, I could see myself using this once it's a bit more mature. I hope you're not discouraged by this feedback. It's really easy to make assumptions and not imagine a stranger's workflow. Congrats on shipping and good luck!
Thank you — this is incredibly helpful feedback, and I really appreciate you taking the time to actually install and test it.
You’re absolutely right about the README. Right now it’s too abstract and assumes context that a first-time user doesn’t have. I’ll add concrete examples with command output and input flow so it’s clear what to expect before installing anything.
Good catch on the password confirmation during init — that’s a real footgun. I agree it should prompt twice and fail early if there’s a mismatch. I’ll fix that.
The storage/location behavior is also on me. At the moment it defaults to the current working directory, which clearly isn’t intuitive or well-documented. I need to make this explicit and likely move toward a config file + deterministic path (or a required --path), so behavior is predictable regardless of where the command is run.
On the password prompt: lockify currently relies on the OS keyring to cache the passphrase after first entry for local dev convenience, which is why you weren’t prompted again. I agree this needs to be much clearer, configurable, and better documented — including when the tool will and won’t prompt, and what security tradeoffs that implies.
This is exactly the kind of “stranger workflow” feedback I was hoping for. I’m still early in the project, and comments like this are what will make it usable. Thanks again, and I’m glad to hear you might revisit it once it matures.
Neat tool. I could see myself using this for some low-risk things that I currently store in plaintext. Some thoughts…
- The github page doesn't give me a good sense of how it works / what it looks like to use. You list supported commands, but there's no indication of what running them spits out. I'd suggest including the output of commands. For example, I wondered if I would be prompted for multiple lines of text or if I would be expected to input something in a key=val pair, etc. I would usually write off something unclear like this, but I was curious and downloaded the binary to find out. (Answer for others: multiple prompts for text input.)
- Initializing an environment asked me to set a password but didn't test the password for typos. If I had a mistake in my password, I wouldn't know it and everything that I committed would become irretrievable.
- In ~90 sec of testing, I see that my lockify env directory was created in the directory where I fired the binary. I don't see a config file in the first level of the repo and I didn't go hunting, nor did I test the behavior under varied conditions. Why wasn't it stored at the root of my home dir? Will lockify remember the path to the env file(s) after I change dirs and call it again? How do I specify a path that matches my expectations regardless of where I am within the filesystem when I call the tool? It's really unclear what behavior to expect and it shouldn't be up to me to figure it out.
- When I ran the command to retrieve a key, I wasn't asked for my env password. Why not? What's the value of using this tool if anyone can just walk up to my workstation and output my secrets without getting challenged? And what are the conditions that would change the result? When will it need a password and when will it not? Again, not my job to figure out how the tool behaves for me to decide if it's right for me.
As I mentioned, I could see myself using this once it's a bit more mature. I hope you're not discouraged by this feedback. It's really easy to make assumptions and not imagine a stranger's workflow. Congrats on shipping and good luck!
Thank you — this is incredibly helpful feedback, and I really appreciate you taking the time to actually install and test it. You’re absolutely right about the README. Right now it’s too abstract and assumes context that a first-time user doesn’t have. I’ll add concrete examples with command output and input flow so it’s clear what to expect before installing anything. Good catch on the password confirmation during init — that’s a real footgun. I agree it should prompt twice and fail early if there’s a mismatch. I’ll fix that. The storage/location behavior is also on me. At the moment it defaults to the current working directory, which clearly isn’t intuitive or well-documented. I need to make this explicit and likely move toward a config file + deterministic path (or a required --path), so behavior is predictable regardless of where the command is run. On the password prompt: lockify currently relies on the OS keyring to cache the passphrase after first entry for local dev convenience, which is why you weren’t prompted again. I agree this needs to be much clearer, configurable, and better documented — including when the tool will and won’t prompt, and what security tradeoffs that implies. This is exactly the kind of “stranger workflow” feedback I was hoping for. I’m still early in the project, and comments like this are what will make it usable. Thanks again, and I’m glad to hear you might revisit it once it matures.