- memo doesn't need to be built (its a shell script)
- once keeps output cache in a running daemon. By contrast, memo stores content under /tmp with whatever the best compression available is (it prefers zstd). There's trade-offs in that. More pareto-optimal from the security front may be to have a sort of session key and to compress-then-encrypt files on disk.
__MatrixMan__ 2 hours ago [-]
I dream of applications that expose sufficient metadata about their outputs such that the OS can know if rerunning is necessary without me needing to specify.
Nixos does this for builds, but I've not seen it generalized to arbitrary processes.
xuhu 4 hours ago [-]
I wish this worked without prefixing the commands with "once". Especially if I ran a command with verbose output and afterwards decided I wanted to grep something from it. Terminals have the output in their scrollback buffer and maybe it's just a matter of writing an "output" command that lets me run:
$ cmake ..
$ output | grep "libssl version"
ctippett 2 hours ago [-]
You could probably achieve something like that using Fish shell and their fish_preexec and fish_postexec event hooks.
Edit: Nope, looks like you can't. You only get the invoked command and no output.
stirfish 1 hours ago [-]
Could you use preexec + tee?
giancarlostoro 2 hours ago [-]
> The typical use case: reading secrets from 1Password without approving every single read with your fingerprint.
Uh I dont know about that one chief.
alex0ptr 2 hours ago [-]
Yes - but I'm out of ideas. How else support long running agents without leaving secrets in files or by default exposed in the environment. That way I get notified the first time before they ask for credentials.
That looks pretty cool - even supports caching. Will take a deeper look. Thx
giancarlostoro 1 hours ago [-]
The same agents that could potentially leak your secrets? I would rather not give a hacker a cached session that unlocks the keys to the kingdom.
I'll take security by inconvenience over building what becomes the primary reason for a security incident.
alex0ptr 1 hours ago [-]
If I already approved it once I already have to assume it could have been leaked. The cache doesn't change much about it if the agent / tenant is asking for something it already has.
devmor 41 minutes ago [-]
Don't give secrets to agents at all that you don't plan on revoking immediately after.
If you have allowed an agent to access any kind of credential, you should assume it is no longer private.
newadays 38 minutes ago [-]
Congratulations. What is Word Error Rate? We have a few use cases for something like that at newcare.app
stingraycharles 4 hours ago [-]
Seems well-designed, but what’s the use case? I’m trying to think of them but my creativity is failing me.
adregan 3 hours ago [-]
I have a small fish function that does something similar. It saves output to a file in XDG_CACHE_HOME. I wouldn’t use it for sensitive items like passwords or tokens in the examples, but I do use it for scripts that need to fetch some data from the network.
For example, I have a script for automating the creation of PRs which fetches the available labels for a repo from github and presents them with fzf multi select. I store the labels with a TTL of a week so that I don’t have to fetch them every time and the script compares the file’s age against the desired TTL to invalidate.
I find it useful for augmenting other programs, but I’m not typically using it on the cli directly.
frizlab 4 hours ago [-]
From the example in the Readme, I guess retrieving a token from an API, using a secret fetched from a secure vault that requests a password or TouchID validation.
Not sure if there could be other interesting uses. I can’t think of one anyways.
alex0ptr 2 hours ago [-]
Yes, exactly. This is especially frustrating when I leave an agent running for a long time and it gets stuck on my build scripts because it's waiting for my approval.
I just want to avoid leaving my credentials and secrets on the filesystem.
EDIT: I use a lot of direnv / mise. So reloading credentials with different values is common.
whilenot-dev 4 hours ago [-]
I have the same question, especially since any CLI output can be stored explicitly in some variable or temp file. What's the advantage of storing the output implicitly?
alex0ptr 2 hours ago [-]
I don't want to store them in a file since I don't trust my agents with that data. Instead, the daemon secures the values using/under an HMAC key, making them virtually impossible to guess.
baquero 6 hours ago [-]
Do you have CLI calls that you want to cache? Here you go!
singularityisne 1 hours ago [-]
[flagged]
Rendered at 15:31:03 GMT+0000 (Coordinated Universal Time) with Vercel.
It was discussed in https://news.ycombinator.com/item?id=45670052 and others chimed in with their own (like bkt(1) and up(1)).
The main differences I see:
Nixos does this for builds, but I've not seen it generalized to arbitrary processes.
Edit: Nope, looks like you can't. You only get the invoked command and no output.
Uh I dont know about that one chief.
I'll take security by inconvenience over building what becomes the primary reason for a security incident.
If you have allowed an agent to access any kind of credential, you should assume it is no longer private.
For example, I have a script for automating the creation of PRs which fetches the available labels for a repo from github and presents them with fzf multi select. I store the labels with a TTL of a week so that I don’t have to fetch them every time and the script compares the file’s age against the desired TTL to invalidate.
I find it useful for augmenting other programs, but I’m not typically using it on the cli directly.
Not sure if there could be other interesting uses. I can’t think of one anyways.
I just want to avoid leaving my credentials and secrets on the filesystem.
EDIT: I use a lot of direnv / mise. So reloading credentials with different values is common.