share-secrets-safely
Windows support?
Since both rust and gpg run on Windows, what obstacles are there to sy running on Windows, too?
Hi @ohbadiah , thanks for asking publicly.
There is indeed no technical reason, just me hesitating from setting up circleCI for windows workers, and jumping to all the hoops to make it work with the GPGME bindings. They add a lot of complexity, unfortunately.
Maybe it's not as hard as I think, after all I didn't try it. As I don't need it for windows myself, I don't see me making the attempt either.
Does that answer your question? Would you like to see this go forward?
Thanks and cheers, Sebastian
Thanks for the quick response. I'm almost interested enough to offer to give it a shot myself, but I think I'd better not bite that off.
I'm a little new to Rust, and realizing that Windows compatibility is limited by C/C++ compatibility on Windows. Since that doesn't "just work," it seems like neither does Rust.
@moritzheiber By popular demand, I will be working on this eventually. Let's see when I actually find time, but it's on my agenda now and it's what I will be doing next.
First goal: get it to compile in a VM and upload the binaries to get people started. Second on the list is to automate that with circle-ci and get it to upload binaries to github-pages automatically.
@Byron-TW This is where I love Rust for having cargo. I'll probably bite my own ass for this but .. this should be fairly simple. Let me know if you need any testers, our team would be happy to oblige.
Thanks!
Just FYI: I am postponing this task until I have my new computer. It should make working on this so much more comfortable due to reduced cycle times.
@byron do you have an estimate as to when that’s going to be? I might be able to .. „expedite“ the delivery ;)
I just know it’s on 'the list' of machines to be ordered and D. is on it personally :). Of course I could try to get things done on my current machine, but ... it really is no fun anymore :(. ‘Expedite’ if you must ;).
Here is my progress so far...
First I installed a parallels VM with all tools required... that took a while :D
Now I try to build the CLI (and later 'libgpg-error'), which displays this issue:
A tiny bit of digging reveals this surprising comment of the maintainer of gpgme-rs who states that windows is not currently supported.
I will reach out to him now to see if I can help. An alternative approach would be to migrate to sequoia, which is early in development and which doesn't seem to have any signs of windows support just yet.
I think the only hope for using GPG on Windows right now is gpg4win. Without it none of the regular tooling would/should work. Gopass at least starts supporting encryption with it, so I'd say that could be your next move, alongside git-bash or WSL.
btw, https://gitlab.com/sequoia-pgp/sequoia now says its low-level API is feature complete .. maybe it's worth taking another look at?
Thanks! I took a look at the sequoia examples and believe that the reading of public keys would already work. Looking deeper into it, it seems that crypto is supported, too.
Even though I would still have to verify it's actually doing the same thing and, generally, works. The sample programs should allow that: https://gitlab.com/sequoia-pgp/sequoia/tree/master/openpgp/examples .
Maybe Windows just moved into the realm of the possible.
I will be evaluating Sequoia to learn if it can indeed be leading the way towards windows support. All the following tasks are to be evaluated on windows, and possibly on OSX just to be sure. I assume the authors are working on linux.
Sequoia as GPG replacement? No :(.
Looks like it is not going to happen due to nettle, which is very much at home anywhere non-windows.
Under these circumstances it might be easier trying to get GPGME to compile on windows.
Tasks
- [ ] Prerequisite: figure out if
nettleis supposed to run on windows - [ ] Build sequoia on windows
- Despite my fix, the
nettledependency seems to assume running on a unix system.
- Despite my fix, the
- [ ] encrypt with private GPG key using one of the example programs
- [ ] decrypt ...
- [ ] sign a key ...
Here is a screenshot of the failure.
Looks like it is not going to happen due to nettle, which is very much at home anywhere non-windows.
Thanks for looking into this. We (the Sequoia dev team) haven't looked at Windows support yet, but it is planned. If nettle doesn't work on Windows, we will either fix it so that it does, or use a different crypto library on Windows. Our initial release is planned for the end of November. After that we will concentrate on making Sequoia work on Windows, Android and iOS, in that order. So, Windows support should be in place at the beginning of 2019.
encrypt with private GPG key using one of the example programs decrypt
FWIW, you don't need a private key to encrypt (but you do need it for signing).
If you do 'gpg --export-secret-key > KEYID.pgp', then you can use it with Sequoia. But, Sequoia does not use 'gpg-agent'. We briefly considered it to quickly bootstrap support for asymmetric encryption in Sequoia, but it turned out to be more work than we thought, so we just directly implemented the asymmetric crypto in Sequoia. We may still implement support for interacting with 'gpg-agent', but it is currently a low-priority item.
sign a key ...
If you mean certify a third-party key, then it is possible using Sequoia, but not very convenient. I've opened an issue:
https://gitlab.com/sequoia-pgp/sequoia/issues/117
@nwalfield Thanks a lot for your involvement and your insights! It's very much appreciated! As sheesy is rather stable, it would probably even be feasible to start porting it over to Sequoia right now, under the assumption that windows support will one day be available for free.
About encryption: amazing, I always thought the private key is always required, and for that matter Sequoia would already be working here as all public keys are known. The decryption is another matter though, as the private keys are kept in the GPG keychain for many. The other kind of user will not have a permanent GPG key and just create one for the project. These folks would certainly be fine pointing sheesy - powered by sequoia to some keyfile to use. The others might rely on a Yubikey (or similar), which is when decryption can't be done anymore as no physical keyfile exists.
Another way to introduce Sequoia into this project might be to add symmetric encryption as option, essentially allowing people to share a password for accessing all secrets. This would be my preferred choice right now, as it definitely adds value right away, and should be relatively simple to implement. There could even be a version of sheesy that drops asymmetric crypto completely to get the windows version out fast.
Thanks a bunch for caring about the usability of sequoia so much as to create an issue right away. This gives me the feeling replacing GPG with sequoia will actually work out in the end, even though it's certainly nothing that will come quickly and easily.
My dream is to have a single, zero-dependency binary that can do everything, working without GPG or the gpg-daemon being present on the host system. Just put in your Yubikey, and you are ready to go on any machine.
About encryption: amazing, I always thought the private key is always required
Think about it this way: when you want to send me an encrypted message, you don't need my private key. If you did, that would defeat the purpose of the whole system :).
Oh, absolutely! I understood that one doesn't even need your own private key. Is that indeed the case?
On Mon, Oct 15, 2018 at 9:15 AM nwalfield [email protected] wrote:
About encryption: amazing, I always thought the private key is always required
Think about it this way: when you want to send me an encrypted message, you don't need my private key. If you did, that would defeat the purpose of the whole system :).
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/share-secrets-safely/cli/issues/12#issuecomment-429733660, or mute the thread https://github.com/notifications/unsubscribe-auth/AOd3mh_acvgGfjFgPqbwQ560kTfcopUkks5ulDYggaJpZM4UKyJT .
The decryption is another matter though, as the private keys are kept in the GPG keychain for many. The other kind of user will not have a permanent GPG key and just create one for the project. These folks would certainly be fine pointing sheesy - powered by sequoia to some keyfile to use. The others might rely on a Yubikey (or similar), which is when decryption can't be done anymore as no physical keyfile exists.
- Using gpg-agent to access the key is possible, but it is not implemented and currently low priority for us.
- Exporting the private key from gpg is possible right now, but requires some support from sheesy to make the UX smooth.
- Having sheesy manage its own private key is possible right now (this is a prerequisite for item 2).
- Smartcard support for Sequoia is planned for 2019. We'd get smartcard support for free if we supported 'gpg-agent'. But, see item 1.
Another way to introduce Sequoia into this project might be to add symmetric encryption as option, essentially allowing people to share a password for accessing all secrets. This would be my preferred choice right now, as it definitely adds value right away, and should be relatively simple to implement. There could even be a version of sheesy that drops asymmetric crypto completely to get the windows version out fast.
This should be possible right now.
P.S. If you do start integrating Sequoia support, feel free to ask on #sequoia on freenode for help.
Oh, absolutely! I understood that one doesn't even need your own private key. Is that indeed the case?
You don't need your own private key to encrypt to yourself. You need your own private key if you want to sign the message. In OpenPGP, encryption and signing and separate operations, and it is possible to do one without also doing the other.
Sequoia can now use Windows CNG on Windows. See https://sequoia-pgp.org/blog/2020/08/21/202008-sequoia-0.19.0/ and https://gitlab.com/sequoia-pgp/sequoia#cryptography .
This looks like Sequoia would now be viable on Windows by allowing to skip nettle entirely.
For share-secrets-safely this would probably mean a major version jump as pgp keychains are seemingly not supported by sequoia. Thus one would need a place for private keys to be read from, which is otherwise transparently handled by gpgme. The latter also supports hardware keys, but that probably wouldn't matter much in a world where pgp keychains aren't supported anyway and people create new keys to use this tool.
This sounds like quite some work which admittedly I won't be doing anytime soon.
Sequoia has first class support for PGP Keyrings, but I guess you mean Sequoia doesn't have a replacement for the whole of ~/.gnupg. That's true.
After we release 1.0 (any time now), finishing the public key store, and developing on the private key store are two of our top priorities. The private key store will have a device driver like architecture so that it is possible to plug-in different private key backends including gpg-agent. In fact, it is already possible to talk to gpg-agent from Sequoia, it is just a bit inconvenient. I'll report back when these components are in place.
Thanks for the clarification, that's great news!
To me it sounds like once the keystore system is in place, it should be able to use gpg keystores (?) as well as gpg-agent backed keys, so all features that this CLI needs are supported.
This intrigues me, so I will probably be back to make the switch and finally ditch the (so far pretty decent) gpg-me dependency.
Even though off-topic, and even though I sound like 'need gpg support all the time', I truly hope that sequoia will take a different route and improve on the keychain as well as how it is managed. Thus far I have been burned regularly by GPG especially in conjunction with Yubikeys, and really, really would like an ~~alternative~~ replacement. If that means I redo my keychain, that's a small price to pay.
To clarify: sequoia's public keystore will (probably) not use the gpg public keyring, but sequoia's private key store will be able to use secret key material managed by gpg agent.