search

phar-io / gnupg

A thin wrapper around the gnupg binary, mimicking the pecl/gnupg api
https://phar.io
Other
8 stars 2 forks source link

Define new interfaces for version 2 #4

Open jaapio opened 3 years ago

jaapio commented 3 years ago

I tried to keep the interface as small as possible. There are 2 main use-cases for this library. As discussed we keep downloading keys out of the scope of this library. When I was thinking about the interface design I think there is no need to have support to read keys from files. The only location where we need files is in the CliWrapper because the gng executable needs this. The pecl implementation can just use strings to import keys. So there is no need to support files from this library perspective.

Rather than implementing all kinds of response objects, I think we can better throw exceptions in case actions are failing.

Verify signed messages.

It is required to first import a key to a keyring to be able to verify any messages.

I defined 2 methods to import keys because I wanted to have different outputs. The PublicKey class is inspired by the definition of a public key in phive. We could think about the need for a more specialized method PublicKey::getInfo but I think for now there is no real use case for this message rather than be able to print some information?

The SecretKey import is basically the same idea as I had for the PublicKey This will be the only way to create a SecretKey object which is needed to sign a message.

Sign messages

I think we can add this feature later. There is no use-case implemented that requires this in phive.

Some sources to think about: https://github.com/paragonie/hidden-string/blob/master/src/HiddenString.php which might help to prevent leaks of secret information via serialization etc.

Looking forward to your response :-)

jaapio commented 3 years ago

I'm back to this issue today, I'm rethinking my approach to this because I just looked at the existing code and tried to model that more properly with some information I got from the gpg tools on my laptop.

Maybe it is better to create a better model of what happens in the real world of gpg. And see how we can adapt the existing PHP extension to fit in. I do personally think that we might want to make the gpg pecl extension optional because the CLI tool can provide us more functionality and better feedback. What would be the use-case to use gnugpg from pecl if you have the command-line tool installed?

theseer commented 3 years ago

Maybe it is better to create a better model of what happens in the real world of gpg. And see how we can adapt the existing PHP extension to fit in. I do personally think that we might want to make the gpg pecl extension optional because the CLI tool can provide us more functionality and better feedback. What would be the use-case to use gnugpg from pecl if you have the command-line tool installed?

We can probably simply stop supporting the extension as I agree with the notion that its limitations are holding us back while not providing any benefits.

So, let's just model an API that just works (tm) and makes it easy to use. We do not exactly have to focus on the gpg process details per se if we can abstract those away - if I make sense ;)

jaapio commented 3 years ago

I spend most hours today searching for a good output document for the verification action of GPG. I think I found one: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob_plain;f=doc/DETAILS

The verify method has been improved now. It will return a Signature object which represents the output of a verified signature. When the signature has a valid status the SignatureInfo will be attached. Which contains more information about when the signature was created.

SignatureData is an abstraction to make this library work without the need to access files.

I did just look at the GnuGPG output and only included the stuff that was needed from my point of view. In theory, this part could be supported using the PHP extension. Maybe some information will require an extra call.