diff options
| -rw-r--r-- | website/bugs/handle-passphrase-locked-secret-keys.mdwn | 83 |
1 files changed, 83 insertions, 0 deletions
diff --git a/website/bugs/handle-passphrase-locked-secret-keys.mdwn b/website/bugs/handle-passphrase-locked-secret-keys.mdwn new file mode 100644 index 0000000..a61b5ba --- /dev/null +++ b/website/bugs/handle-passphrase-locked-secret-keys.mdwn @@ -0,0 +1,83 @@ +[[meta title="MonkeySphere needs to be able to cleanly export passphrase-locked secret keys from the GPG keyring"]] + +At the moment, the only tool we have to export passphrase-locked +secret keys from the GPG keyring is `gpg` itself (and `gpg2`, which +has roughly the same behavior). + +As a result, we have the `seckey2sshagent` hack, which is unfriendly +and awkward to use. + +Ideally, `openpgp2ssh` would be able to convert passphrase-locked +secret keys into clean subkeys. However, i've tried to do this via +GnuTLS, and that library is not ready for this. + +OpenCDK, which is the component of GnuTLS which reads OpenPGP-style +keys, cannot cope with encrypted secret key material. I have had +[some +success](http://lists.gnu.org/archive/html/gnutls-devel/2008-06/msg00092.html) +in getting GnuTLS's OpenCDK to accept the existence of encrypted +secret key packets, [i learned that OpenCDK as included in GnuTLS is +incapable of dealing with the encrypted packets +themselves](http://lists.gnu.org/archive/html/gnutls-devel/2008-07/msg00012.html). + + +Some possible resolutions: + +--------- + +If we can assume that the passphrase-encrypted key we want to use is +actually a subkey, and if we could fix GnuTLS to ignore the use of the +"gnu-dummy S2K" produced by `gpg --export-secret-subkeys` for the +primary key, then something like the following script should actually +work for reasonable values of `$KEYID`: + + TMPDIR=$(mktemp -d) + uname 077 + mkfifo "$TMPDIR/passphrase" + kname="MonkeySphere Key $KEYID" + mkfifo "$TMPDIR/$kname" + ssh-agent "Please enter the passphrase for MonkeySphere key $KEYID" >"$TMPDIR/passphrase" & + gpg --passphrase-fd 3 3<"$TMPDIR/passphrase" --export-options export-reset-subkey-passwd,export-minimal,no-export-attributes --export-secret-subkeys "$KEYID"\! | openpgp2ssh "$KEYID" > "$TMPDIR/$kname" + (cd "$TMPDIR" && ssh-add -c "$kname") + rm -rf "$TMPDIR" + +--------- + +Ben Laurie and Rachel Willmer's +[OpenPGPSDK](http://openpgp.nominet.org.uk) is a candidate: this is a +C-based library that intends to implement RFC 4880 functionality. + +We could potentially re-write `openpgp2ssh` using this library, and it +*should* be able to handle everything we need from the OpenPGP side +(though it might need to be re-linked to OpenSSL to handle PEM-encoded +exports. + +Concerns: + +* OpenPGPSDK is not in debian yet, and doesn't currently (2008-08-13) + build with gcc 4.2 or 4.3. + +* OpenPGPSDK uses the apache license and appears to link to OpenSSL, + which has a GPL-incompatible license. I think this would mean that + `openpgp2ssh` could not remain GPL (though the rest of the + monkeysphere could). + +--------- + +We could try to use perl. The last time i checked, the pure-perl +OpenPGP implementations all depended on Math::PARI, which [is not in +debian](http://bugs.debian.org/440527). The most likely candidate is +[Crypt::OpenPGP](http://search.cpan.org/~btrott/Crypt-OpenPGP), +despite [some +bugginess](http://cpanratings.perl.org/dist/Crypt-OpenPGP). + +Concerns: + +* the aforementioned buggy reviews + +* there's a lot of dependency chasing to get anything like this + available in debian. + +--------- + +Other alternatives? |