GPGME_No_Matching_Secret_Key error code missing

[Ingo Klöcker]

--Boundary-02=_/JtS+0idjaX0Hjb
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Wednesday 12 February 2003 20:35, Marcus Brinkmann wrote:
> On Wed, Feb 12, 2003 at 12:40:46PM +0100, Marc Mutz wrote:
> Content-Description: signed data
>
> > On Wednesday 12 February 2003 01:50, Marcus Brinkmann wrote:
> > <snip>
> >
> > > Please also see README-alpha.
> >
> > <snip>
> >
> > The point here is that _we_ (as KMail developers) didn't start
> > using gpgme for a production-quality system. The Aegypten project
> > introduced this.
>
> I don't know who the kmail developers are.

Me and Marc, for example. But we didn't have very much to do with the=20
Aegypten project. On the contrary Werner (yes, Werner Koch) was=20
involved in the Aegypten project. And obviously he thought that gpgme=20
was mature enough to be used for this project.

In fact, so far gpgme works very well for us. Kudos to the developers.

[snip]

> I am still waiting for more
> information on why Ingo sees No_Passphrase where I expect
> Decryption_Failed or Invalid_Key. I am also open to a discussion if a
> distinction between no passphrase and bad passphrase is useful.

I was wrong. If decryption is impossible due to lack of an appropriate=20
secret key then indeed Decryption_Failed is returned. No_Passphrase was=20
returned because no gpg-agent was running and therefore gpg couldn't=20
ask for the passphrase.

So what we need is:
1.) Missing_Key in addition to Decryption_Failed. Else we can't tell our=20
users why decryption failed. I guess there are more cases in which=20
Decryption_Failed is returned. As long as the reason for the failed=20
decryption is know a specific error code should be returned.=20
Decryption_Failed should only be returned if decryption failed due to=20
an unknown reason.
2.) Some error code which indicates that asking for the passphrase=20
failed/wasn't possible. Else the user will wonder why we tell him that=20
decryption failed because of no/wrong passphrase although he wasn't=20
asked to enter the passphrase.

The question whether there should be a No_Passphrase _and_ a=20
Bad_Passphrase error code is difficult to answer. If the user didn't=20
enter a passphrase then this probably indicates that he didn't want to=20
enter a passphrase. This means that No_Passphrase could be treated as=20
Canceled. So yes, I think it makes sense to have No_Passphrase _and_=20
Bad_Passphrase.

Before you ask the obvious question wrt what I wrote above: No, I don't=20
think that in case the user didn't enter a passphrase gpgme should=20
return Canceled. IMO you should leave the interpretation of the error=20
codes to the application programmers since in some cases it might make=20
sense to treat No_Passphrase the same way as Bad_Passphrase while in=20
other cases it might make sense to treat it as Canceled.

It's always better to have more error codes than actually necessary than=20
to have too few. If you have too few error codes then you can't simply=20
add a new error code resp. change an error code if you, all of the=20
sudden, need to do this because this will break all programs which rely=20
on the old error codes. OTOH programs can always treat several=20
different error codes the same way if they don't see the need to=20
differentiate between the errors these codes indicate.

Regards,
Ingo


--Boundary-02=_/JtS+0idjaX0Hjb
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+StJ/GnR+RTDgudgRAmp4AJ0d9TeOZiJrWG9f055ieq+Hji7/UgCcDA3U
SdFlJm42fhDVZrIFbagQWVA=
=HvU1
-----END PGP SIGNATURE-----

--Boundary-02=_/JtS+0idjaX0Hjb--