Created attachment 281955 [details] [review]
Add CAN_CERTIFY and CAN_AUTHENTICATE flags

Created attachment 281957 [details] [review]
Generate "Certificate" and "Authenticate" names for the new flags

I'm not sure if there should be equivalent code in seahorse_gpgme_key_realize(), to set the SEAHORSE_FLAG_CAN_XXX from the gpgme_key's own flags.  If so, that function has this:

		if (self->pv->pubkey->can_encrypt)
			flags |= SEAHORSE_FLAG_CAN_ENCRYPT;
		if (self->pv->seckey && self->pv->pubkey->can_sign)
			flags |= SEAHORSE_FLAG_CAN_SIGN;

Should I just use the self->pv->pubkey->can_XXX flags?  Why does the second one there check for self->pv->seckey?  (Does that mean, *you* can use this key to sign because you have the secret key - and the can_encrypt case doesn't check for the secret key because you just need *their* public key?)

(In reply to comment #3)
> I'm not sure if there should be equivalent code in
> seahorse_gpgme_key_realize(), to set the SEAHORSE_FLAG_CAN_XXX from the
> gpgme_key's own flags.  If so, that function has this:
> 
>         if (self->pv->pubkey->can_encrypt)
>             flags |= SEAHORSE_FLAG_CAN_ENCRYPT;
>         if (self->pv->seckey && self->pv->pubkey->can_sign)
>             flags |= SEAHORSE_FLAG_CAN_SIGN;
> 
> Should I just use the self->pv->pubkey->can_XXX flags? 

I think that until we have a need for those flags in the SeahorsePgpKey, we can not propagate them for now.

> Why does the second one
> there check for self->pv->seckey?  (Does that mean, *you* can use this key to
> sign because you have the secret key - and the can_encrypt case doesn't check
> for the secret key because you just need *their* public key?)

I think we used this for filtering keys that show up in a drop down selector. I think I remember a situation where GPGME marked keys as can_sign even without a secret key. It would have been good to add a comment here :S

Thanks. Merged with a couple formatting tweaks.