security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2025-01-10 13:04:23 +01:00
Code Activity

See ChangeLog: Mon May 1 17:08:14 CEST 2000 Werner Koch

Browse Source
This commit is contained in:
Werner Koch 2000-05-01 15:01:42 +00:00
parent 9409147179
commit f24734987b
5 changed files with 27 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
TODO
View File

@ -1,4 +1,6 @@
* g10/trustdb.c (make_sig_records): fix the fixme.
* at least an option to prefer DSA keys over RSA when selecting the key to
use. Depending on creation time would be nice too. I think this is
already done for the subkeys - check it.

7
doc/FAQ
View File

@ -398,4 +398,11 @@
revoke all the subkeys installed on that machine and install new
subkeys.
Q: In the edit meu the trust values is not displayed correctly after
signing uids - why?
A: This happens because the some informations are stored immediately
in the trustdb, but the actual trust calculation can be done after
the save command. This is a not easy to fix design bug which will be
addressed in GnuPG 1.1

5
g10/ChangeLog
View File

@ -1,3 +1,8 @@
Mon May 1 17:08:14 CEST 2000 Werner Koch <wk@openit.de>
* trustdb.c (propagate_validity): Fixed the bug that only one uid
gets fully trusted even when all are signed by an ultimate key.
Mon May 1 15:38:04 CEST 2000 Werner Koch <wk@openit.de>
* getkey.c (key_byname): Always returned a defined context. Fixed

5
g10/keyedit.c
View File

@ -783,6 +783,11 @@ keyedit_menu( const char *username, STRLIST locusr, STRLIST commands,
if( !sign_uids( keyblock, locusr, &modified, cmd == cmdLSIGN )
&& sign_mode )
goto do_cmd_save;
/* Actually we should do a update_trust_record() here so that
* the trust gets displayed correctly. however this is not possible
* because we would have to save the keyblock first - something
* we don't want to do without an explicit save command.
*/
break;
case cmdDEBUG:

10
g10/trustdb.c
View File

@ -1243,6 +1243,12 @@ make_sig_records( KBNODE keyblock, KBNODE uidnode,
siglid = find_or_create_lid( sig );
/* smash dups */
/* FIXME: Here we have a problem:
* We can't distinguish between a certification and a certification
* revocation without looking at class of the signature - we have
* to see how we can store the sigclass in the sigrecord..
* Argg- I hope I can get rid of this ugly trustdb ASAP.
*/
for( s2 = s; s2 ; s2 = s2->next ) {
for(i=0; i < sigidx; i++ ) {
if( s2->r.sig.sig[i].lid == siglid )
@ -2014,10 +2020,10 @@ propagate_validity( TN root, TN node, int (*add_fnc)(ulong), unsigned *retflgs )
}
/* loop over all user ids */
for( ur=node->list; ur && max_validity < TRUST_FULLY; ur = ur->next ) {
for( ur=node->list; ur && max_validity <= TRUST_FULLY; ur = ur->next ) {
assert( ur->is_uid );
/* loop over all signators */
for(kr=ur->list; kr && max_validity < TRUST_FULLY; kr = kr->next ) {
for(kr=ur->list; kr && max_validity <= TRUST_FULLY; kr = kr->next ) {
if( propagate_validity( root, kr, add_fnc, retflgs ) )
return -1; /* quit */
if( kr->n.k.validity == TRUST_ULTIMATE ) {