Bug list current GPA

[Miguel Coca]

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

On Thu, Nov 28, 2002 at 11:53:27 +0100, Markus Gerwinski wrote:
> Miguel Coca wrote:
> > 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.
>=20
> Where should I download this, if I don't yet have it installed?

Just pass the --enable-external-hkp flag to gpg's configure and recompile.

> > LDAP servers should work (unless you don't have the ldap plugin compile=
d).
>=20
> There is quite a bunch of libldap* files on my machine... On what way sho=
uld
> GPA use them?

The LDAP plugin is a program called gpgkeys_ldap. By default it's installed
in /usr/local/libexec/gnupg/, and it's compiled if you have the openldap
developtment files installed when you compile GnuPG.

GPA calls that program directly instead of going through GnuPG to contact
the servers. There should be gpgkeys_* programs for every available
protocol, and since they all work the same way, GPA will work with all of
them.

> > >  * 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.
>=20
> Could you take this one into the TODO?

Ok.

> > >  * Signatures: GPA doesn't display any key signatures.
> > Right. GPGME will support them Real Soon Now, and then we'll add suppor=
t to
> > GPA.
>=20
> Who's working on it in GPGME?

Marcus Brinkmann. Last I knew, a few days ago, he was working on what the
programming interface should be.

> > Anyway, this is fixed in my working version too :-)
>=20
> I'm looking forward to testing. ;-)

I'll see if I can give the last touches and commit tonight. As it is a large
change, I want to test if properly before going public :-)

> > > File Manager:
> > >  - File/Check: OK; however, keys generated with an 1.0.x version of G=
PG are
> > >    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).
>=20
> Aah, so only "ultimately trusted" keys are shown as valid? Then it's clea=
r.

Validity is what used to be called "Key trust". We only consider valid keys
that are either ultimately of fully trusted. Since a signature by a
non-valid key is not really trusted, we complain about it. Maybe there is a
clearer (short) name for a good signature from an untrusted key?

> > >  - File/Encrypt: OK, but you're _not_ added to the recipients by defa=
ult.
> > >    (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?
>=20
> When I originally wrote that dialog, there was a checkbox: "Add sender ke=
y to
> recipients by default?" Usually, it was checked as "true".

I don't remember removing such a checkbox. Maybe we should add it again.

> > > 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 makin=
g a
> > backup of it? Is there really any case where you are interested in havi=
ng
> > 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.
>=20
> I see... apparently, there have been some changes. In GPA 0.5.0, the
> "export secret key" function did the same thing as the "backup" function
> does now. Okay.

Not really. The old backup functions created two files, one with the secret
key and one with the public one. The new one creates just one file, with
both keys. That way you can just import that file and you have everything
you need to use the key.

I reasoned that the average user would assume that if you have the secret
key, you have the public one too, so it didn't make much sense to bother
having two files.

If you just need a copy of your public key, you can export it on it's own.

> > > Furthermore, the "status" column and all signature columns have been =
removed
> > > 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 remov=
e 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.
>=20
> Okay... so it is on the TODO?

It is now :-)

> > 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 :-)
>=20
> To be honest, at that time I only added them because otherwise the list
> would have looked too empty. ;-)  Anyway, I think a column "Signed" would
> make sense, just to see at a glance whether this file is signed or not.

Well, if we ever recover the status column, you'll have that information
there.

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

--9amGYk9869ThD9tj
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE95i/9jE3Htif8PKgRAoM1AJsHRlIq8K1NMdgy5gJSWhJHwTV9xQCdGlL/
NGODmLLK4XyWNNcYSk6ShVo=
=v4Np
-----END PGP SIGNATURE-----

--9amGYk9869ThD9tj--