Bug list current GPA

Miguel Coca e970095@zipi.fi.upm.es
Wed Nov 27 20:05:01 2002


--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 27, 2002 at 15:15:25 +0100, Markus Gerwinski wrote:
> Hi folks,

Hi Markus,

Thanks for the extensive testing!

> I did some tests on the current CVS release of GPA, together with GPGME 0=
.4.0
> and GPG 1.2.1. First question: Is this a "legal" constellation, or does it
> provocate version conflicts?

That's perfectly legal. Although, of course, both GPA and GPGME are
development versions.

> If this is a "legal" release: I found some bugs and would like to know if
> there's already someone working on. Here's the list:
>=20
> Keyring Editor:
>  * Keys/Change owner trust: Selecting "Ultimate" leads to a program crash.
>    All other trust degrees run fine.

Oops, sorry. I will fix it ASAP. I hadn't realized gpg asks an extra
question ("Do you really want to set this key to ultimate trust?") for
ultimate trust.

>  * Keys/Import keys:
>     - From file: OK
>     * From Server: Trying to import a key from one of the servers in the =
list
>       leads to an error message:
>         "There is no plugin available for the keyserver protocol you
>         specified."

Yes, for a release we should either advertise that you need to compile the
gpg HKP plugin, require gpg 1.4, or (most likely) remove HKP keyservers from
the default list.

LDAP servers should work (unless you don't have the ldap plugin compiled).
In gpg 1.2.1 HKP keyservers are supported directly in the gpg binary, unlike
ldap, which is supported by a plugin. In the future (or already in gpg 1.3),
both will be available in plugins, and GPA will be able to use both.

>       Trying to import from http://wwwkeys.de.pgp.net gives an error mess=
age:
>         ": File or directory not found".

Are you sure about that? I can't reproduce it. Maybe you forgot to check the
radio button next to "Receive from server"? (If you look at the TODO, you'll
see that checking the user input in that dialog is in my plans).

>  * Keys/Backup: If there's more than one secret key, you can't select one;
>    always the first one is backup'd.

Actually, it's the default key (not always the first one). You can work
around that by changing the default key for a while, but I agree that should
not be necessary.

>  * Signatures: GPA doesn't display any key signatures.

Right. GPGME will support them Real Soon Now, and then we'll add support to
GPA.

>  * Options/Keyserver: Isn't saved. After restarting, GPA doesn't remember=
 the
>    keyserver set during the last session.

Again, known problem. This has been fixed in my rebuild of the configuration
system, but I haven't committed it yet. I will do so as soon as I get
command line arguments working again.

>  * Options/Default key: No effect at all.

That's not quite right. The signal that changed the default key displayed in
the status bar was disable with the move to GTK+2 in 0.5, but internally GPA
keeps track of the change (at least, I think it does). Anyway, this is fixed
in my working version too :-)

> File Manager:
>  - File/Check: OK; however, keys generated with an 1.0.x version of GPG a=
re
>    presented as "NOT valid".

I can't check this. Would you mind to send me a test case? Maybe it's
because the keys really are not valid (i.e. not signed by a ultimately
trusted key).

>  - File/Encrypt: OK, but you're _not_ added to the recipients by default.
>    (If Theo Test encrypts for Markus Gerwinski, he's unable to decrypt the
>    file for himself afterwards.)

Well, that's the way it works for command line GnuPG, and I think that's the
way it was before. What's the general consensus on this? Should we encrypt
files for the default key too?

> I was also missing some features that had been in version 0.5.0, but
> aren't in the current version anymore. E.g., can anyone tell my what
> happened to the "Export secret keys" function and why?

What exactly is the difference between exporting a secret key and making a
backup of it? Is there really any case where you are interested in having
the secret key, but not the public one? Since we have a backup system, I
don't think it makes sense to have a "Export secret key" option.

> Furthermore, the "status" column and all signature columns have been remo=
ved
> from the "File Manager" table. Here again: What happened to them and why?

Status was not supported by GPGME, and I thought it was better to remove it
than to keep it empty. If this is ever supported by GPGME (and I gather this
is possible), I'd like to add it again. Then I could remove the hack I use
to guess whether a file is a detached siganture or not.

About the signatures columns... I don't know to which degree they were
really useful (i.e. If I'm checking the signature on a software package, I
don't care if it's got 10 valid signatures on it, I just want to know if
it's signed by it's maintainer). And, I was a bit lazy about porting the
whole stuff to GPGME, and just wanted something that worked :-)

Are they really important enough to try to bring them back?

Thanks a lot,
--=20
Miguel Coca                                         e970095@zipi.fi.upm.es
PGP Key 0x27FC3CA8                         http://zipi.fi.upm.es/~e970095/

--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE95Rb1jE3Htif8PKgRAnkXAJ9sp1zrDKdd/+SMHV1d9nninBbhYgCbBVgV
71lRjSggtK932bFsxT6EFBA=
=+VXY
-----END PGP SIGNATURE-----

--k1lZvvs/B4yU6o8G--