Bug list current GPA
Markus Gerwinski
markus@gerwinski.de
Thu Nov 28 11:58:02 2002
--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Miguel Coca wrote:
> Thanks for the extensive testing!
You're welcome. :-)
> > * 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.
Where should I download this, if I don't yet have it installed?
> LDAP servers should work (unless you don't have the ldap plugin compiled).
There is quite a bunch of libldap* files on my machine... On what way should
GPA use them?
> > Trying to import from http://wwwkeys.de.pgp.net gives an error message:
> > ": 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).
Yes, it seems that was it.
> > * 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.
Could you take this one into the TODO?
> > * Signatures: GPA doesn't display any key signatures.
> Right. GPGME will support them Real Soon Now, and then we'll add support to
> GPA.
Who's working on it in GPGME?
> > * 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).
It doesn't. E.g. when signing a file, always the same key is offered as "default",
regardless of which one was set. When encrypting [Testing again] ... hm, there
seems to be another error: One of my self-created secret keys has ownertrust
"unknown" and isn't offered to me at all. Strange.
> Anyway, this is fixed in my working version too :-)
I'm looking forward to testing. ;-)
> > File Manager:
> > - File/Check: OK; however, keys generated with an 1.0.x version of GPG 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).
Aah, so only "ultimately trusted" keys are shown as valid? Then it's clear.
> > - 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?
When I originally wrote that dialog, there was a checkbox: "Add sender key to
recipients by default?" Usually, it was checked as "true". We _can_ leave it
out, but I think, the average user will be confused if he isn't able to decode
his own files again. (At least there should be some kind of warning: "You
won't be able to decode this file yourself. Do you really want that?" -- of
course with a checkbox "Don't show this warning again" or something.)
> > 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.
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.
> > 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 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.
Okay... so it is on the TODO?
> 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 :-)
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.
Best,
Markus
--gBBFr7Ir9EOA20Yy
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE95fWm6Sp5Kx1roGARAjudAJkBacbQXhHrK/hWwEHxf5oY4gqIDwCgnbSH
CO/MkC16blxQRJ47YwhGHjc=
=f5fh
-----END PGP SIGNATURE-----
--gBBFr7Ir9EOA20Yy--