On 2014-09-03 10:33 PM, Jeff Janes wrote:
> On Wed, Sep 3, 2014 at 12:43 PM, Marko Tiikkaja <marko@joh.to> wrote:
>> Right. This patch only adds support for signing data when encrypting it
>> at the same time. There's no support for detached signatures, nor is there
>> support for anything other than signatures of encrypted data. I should
>> have been more clear on that in my initial email. :-(
>>
>>
> OK, thanks. How hard do you think it would to allow NULL (or empty
> string?) passwords to gpg_sym_signatures and gpg_sym_decrypt_verify to
> accommodate this?
To sign without encrypting? I think those should really be a different
set of functions altogether. But this patch is already humongous (on my
standards, at least), so I think that should be done separately.
> I think docs section F.25.3 needs to be re-titled and expanded to reflect
> signatures as well as encryption, and an explanation added about signatures
> only being processed on encrypted data if that restriction can't be removed.
I don't have an objection to that. I fully acknowledge that the
documentation doesn't state the limitations of signing should this patch
be applied.
> I've switched to using a signed plus symmetrically encrypted message for
> testing.
>
> One surprising thing so far is that the 3rd argument to
> gpg_sym_decrypt_verify must be dearmored. I thought it would detect and
> dearmor automatically.
I can't see that as an improvement to be honest.
> Once I wrap it in dearmor, I get the ERROR: No signature matching the key
> id present in the message
>
> The public key block I am giving it is for the keyid that is reported
> by pgp_sym_signatures, so I don't know what the problem might be.
Have you tried with the debug=1 option? (It's undocumented, but it was
like that before this patch and I didn't touch it).
> When I get more time, I'll look at your examples from the regression tests
> to see if I can figure it out.
Thanks! I'm happy to help if you run into any trouble!
.marko