Ferripaste: a command-line Rustypaste client

[dbohdan]

I have been using Rustypaste since 2023 and gradually built a command-line client for it. I have just open-sourced the client: dbohdan/ferripaste. While Ferripaste started as a shell script, the current version is written in Python and developed with uv in mind.

Ferripaste has a CLI with BSD-style short options and uses TOML for configuration. It can either load the authorization token directly from the config file or run a command like pass to get it. Ferripaste generates its own unique filenames by appending a timestamp before the file extension. It verifies the creation of uploads that aren't one-shot.

[tessus]

Interesting. May I ask why you wrote it? Didn't you like the rustypaste-cli which is also written in Rust (the binary is also called rpaste)?

[dbohdan]

Oh, I forgot the rustypaste-cli binary was called rpaste. This is a command name conflict as well as confusing. I have renamed my "rpaste" to "Ferripaste" in response.

I should definitely do a better job explaining why my client exists. I have rewritten the project readme from the perspective of how it is different from rustypaste-cli.

At the time I deployed Rustypaste, I wanted three things that weren't in rustypaste-cli:

1. High priority: integration with pass. I wanted the CLI client to ask the password manager for the token. I have since switched to a different password manager but continue to use this feature.
2. Medium priority: a <stem>.<timestamp>.<ext> file naming scheme. I wanted a different unique file suffix than what Rustypaste offered, one based on the current time rather than random. I find this useful when going through my uploads.
3. Low priority: one-shot URLs. It looks like rustypaste-cli got one-shot uploads soon after I started work on my client.

I have also just added a new piece of functionality: removing Exif metadata when sharing photos.

[tessus]

Ah, I see. Makes sense, although I am a bit fuzzy on requirement 1. Most utilities, e.g. hub, gh, have the credentials in text files. Security wise asking for the token every time is certainly not a bad idea, but taxing. That's why ssh and gpg use agents to cache creds. But I know that this is subjective and thus my opinion is moot. (Personally I am not against it.)

As for the second requirement, this is something that could have been also added to rustypaste server and cli. It might not even be a bad idea to still do so. But I can't speak for orhun.
On the other side, you could still use rpaste -l (pipe to jq) or rpaste -lp (pipe to sort) to sort files based on the upload date. Showing the upload date has been added in 0.15.1.
This might make the requirement for this specific naming scheme obsolete. But using a TS instead of a random value is not a bad idea. (Could be confusing though, should you disable duplicate_files.)

It's great that you wrote your client. Maybe @orhun is ok with adding it to the README.

[dbohdan]

Security wise asking for the token every time is certainly not a bad idea, but taxing. That's why ssh and gpg use agents to cache creds.

Oh yeah, I agree. It would be too taxing if you had to enter the passphrase every time. pass is based on GPG, so it can use gpg-agent. This means you only have to unlock the password store once per session. Since I wrote Ferripaste, I have switched from pass to my own password manager pago, which also implements an agent.

As for the second requirement, this is something that could have been also added to rustypaste server and cli. It might not even be a bad idea to still do so.

It might be something a fraction of Rustypaste users will choose if it is made available. However, I am fine with it only being implemented client-side in my client. The biggest feature of this client for me besides what is listed is that I can customize it however I like. :-)

It's great that you wrote your client.

Thanks.