Comments (5)
skeeto
commented on May 29, 2024
That path isn't hardcoded in the application. It's taken from the
APPDATA environment variable, as documented in the README. Just set this
variable to your thumb drive (say, F:\) before running Enchive.
set APPDATA=F:\
enchive keygen
You could probably wrap this in a batch script or something to make it
more convenient. Another option is to explicitly use the --pubkey (-p)
and --seckey (-s) options. For example (secret key is not needed for
archival):
enchive -p F:\enchive.pub archive myfile.txt
If you *really* want to customize Enchive to your needs, you could
always modify how it determines this path in your own build:
https://github.com/skeeto/enchive/blob/2723203a685effd215b6824d108830360f320973/src/enchive.c#L313
from enchive.
sergeevabc
commented on May 29, 2024
Thank you for letting me know about how to overcome this little inconvenience, Christopher.
from enchive.
sergeevabc
commented on May 29, 2024
From time to time I do my best to give your app another chance, but it is still perceived as unfriendly due to nuances like saving generated keyfiles to anywhere but not the current folder without even informing user where to look for. And command set APPDATA=F:\ is always forgotten. And being a mere Windows user, I am not able to modify sources either. Let’s see another approach, Christopher:
$ ssh-keygen.exe -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/abc/.ssh/id_ed25519): test
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in test.
Your public key has been saved in test.pub.
The key fingerprint is (SHA256):
$ dir.com *.* /b
ssh-keygen.exe
test
test.pubSome other annoying nuances are:
- app version is not displayed in general and requires additional call with
--version - no information on where to look for updates, i.e. a link to this repository
- no progress indicator (see triops for example)
--helpbrings nothing new: no mention of--deriveand--edit, no examples- errors are vague:
secret key version mismatch -- expected 3, got 48, what is 3 and 48 - verbs are vague: archive & extract do encrypt & decrypt, there is no compression involved
- nouns are vague: secret key passphrase is a restore keypair phrase, but what is passphrase
$ enchive.exe -p test.pub -s test.sec keygen --derive
secret key passphrase:
secret key passphrase (repeat):
passphrase (empty for none):from enchive.
nico202
commented on May 29, 2024
Hi, trying to answer:
- Why is it a problem to call enchive --version?
- If you cloned the repository to build it, you should know where you downloaded it
- Ok
- man enchive
- ok
- I find them to be more intuitive. The program is called enchive because of encrypt + archive. The aim is to store the file (encrypted) for ourselves, so the main aim is to archive (in a secure way)
- you get secret key passphrase because you are using the --derive option, so you should know what it is, right?
from enchive.
skeeto
commented on May 29, 2024
ssh-keygen is actually a perfect example of why Enchive works the way it
does. Just like Enchive, ssh-keygen by default puts the files in
specific location (~/.ssh/) with an option to override this path. It's
also, for essentially the same reason, generally not useful to override
the default since in typical usage it's most convenient for that
location to be implicit. The only practical difference between Enchive
is that ssh-keygen interactively asks for the override, and Enchive
requires passing the override as command line arguments (-p, --pubkey,
-s, --seckey).
For your use case you can get exactly the behavior you want with a
simple batch script, which is what I suggested last year. Create a file
named, say, "enc.bat" and put it in your PATH. The contents should be:
enchive --pubkey key.pub --seckey key.sec %*
Then instead of running it as "enchive" you run it as "enc". It will
then always use keys in the current directory, never under APPDATA.
enc keygen
enc archive -d 2017-tax-report.pdf
To answer your other comments:
app version is not displayed in general and requires additional call
with --version
This is exactly how I want it. Programs that print a banner on every
invocation are incredibly annoying — yes, I'm talking about you, most
GNU projects as well as Visual Studio build tools — so I will never do
this. It's especially inappropriate for scriptable tools like Enchive.
no information on where to look for updates, i.e. a link to this
repository
This is listed in the man page. Of course that's not so useful on
Windows which lacks such basic functionality, but you can always read
the online version of the man page:
https://skeeto.github.com/enchive/
This is kept up to date with the most recent release.
no progress indicator
Enchive is first and foremost a unix-style utility. That means doing
just one thing well, and that doesn't include progress bars. The popular
tool on unix-likes for adding a progress bar to nearly anything is "pv"
(pipe viewer):
enchive archive < big-secret.tar | pv > big-secret.tar.enchive
Two problems on Windows is 1) there's no Windows version of pv and 2)
Enchive doesn't currently support piping data on Windows anyway. Enchive
doesn't set stdin/stdout to binary, and Microsoft's own UCRT is (was?)
broken when it comes to pipes. There's a link to a bug report in README.
I've been burned badly enough that I simply *do not trust* Microsoft's
UCRT with pipes with data that's even remotely important.
--help brings nothing new: no mention of --derive and --edit, no
examples
All in the man page. In earlier versions there was a "help" subcommand
to bring up this documentation, but I eventually wrote a formal man page
and didn't want documentation in two different places.
errors are vague: secret key version mismatch -- expected 3, got 48,
what is 3 and 48
Fair enough. Though the only thing I'd change is to add a hint like
"invalid or corrupted key file." I prefer error messages that are
informational, even if enigmatic, rather than opaque. It's good for
search engine queries and it's good for bug reports. The more common
errors already do have better messages, and your particular example is
an uncommon sort of error: You either have actual file system corruption
or you've manually picked a secret key file (-s, --seckey) that isn't
actually a key.
verbs are vague: archive & extract do encrypt & decrypt, there is no
compression involved
As @nico202 noted, these were chosen very deliberately to reflect
Enchive's intended usage, and they're certainly not going to change at
this point since it's part of the interface. "Encrypt" suggests a
possibility of sharing encrypted files with another person, but
"archive" hints that the data is intended only for yourself (to go into
your personal archives).
Like I showed above, you could always script around Enchive to create
whatever verbs you like better, or even put them in a different
language. I've deliberately made Enchive script-friendly for exactly
these sorts of purposes.
nouns are vague: secret key passphrase is a restore keypair phrase,
but what is passphrase
That's a good point about the prompt. I've clarified in the passphrase
prompts which passphrase is being requested and discussed (3b1127a).
Note that the term "protection passphrase" is specifically borrowed from
GnuPG's own terminology, and so I expect typical users to already be
familiar with the concept. Neither OpenSSH nor GnuPG have a concept of a
"secret key passphrase" (which is part of the reason why Enchive exists)
so that's a new-ish term.
Also, thanks for following up on this, @nico202. Until you replied I
hadn't realized sergeevabc had edited in a bunch more comments. I handle
most of this stuff entirely by email, and it only delivers the original
version.
from enchive.
Related Issues (20)
- Emacs interface(a la epg)? HOT 5
- enchive-mode: load files in the right mode HOT 4
- Feature request: secure delete HOT 2
- global buffer overflow HOT 1
- encrypt then mac HOT 12
- round filesize up HOT 1
- lineage of KDF HOT 3
- Encrypt-then-MAC HOT 1
- usage of urandom HOT 2
- extract to stdout HOT 4
- First 32 secret key bytes are always same HOT 6
- Why is inserted Emacs' buffer read-only, and should it be? HOT 5
- Add warning about safety in README
- execution speed on openbsd 7.3 HOT 3
- Detected memory leak during archive and extract operations HOT 2
- Being added to nixpkgs HOT 2
- enchive won't archive big files HOT 5
- feature: AES NI HOT 2
- The enchive default extension is a distinguishing mark HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from enchive.