security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2024-12-24 10:39:57 +01:00
Code Activity

* keyserver.c (keyserver_refresh): --refresh-keys implies --merge-only so

Browse Source 
as not to import keys with keyids that match the ones being refreshed.
Noted by Florian Weimer.
This commit is contained in:
David Shaw 2002-05-05 12:45:54 +00:00
parent d89cf26621
commit ab59f621d6
2 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
g10/ChangeLog
View File

@ -1,3 +1,9 @@
2002-05-05 David Shaw <dshaw@jabberwocky.com>
* keyserver.c (keyserver_refresh): --refresh-keys implies
--merge-only so as not to import keys with keyids that match the
ones being refreshed. Noted by Florian Weimer.
2002-05-04 Stefan Bellon <sbellon@sbellon.de> 2002-05-04 Stefan Bellon <sbellon@sbellon.de>
* free-packet.c (copy_public_key): Don't call m_alloc(0), therefore * free-packet.c (copy_public_key): Don't call m_alloc(0), therefore

5
g10/keyserver.c
View File

@ -838,6 +838,11 @@ keyserver_refresh(STRLIST users)
int rc,count,fakev3=0; int rc,count,fakev3=0;
KEYDB_SEARCH_DESC *desc; KEYDB_SEARCH_DESC *desc;
/* We switch merge_only on during a refresh, as 'refresh' should
never import new keys, even if their keyids match. Is it worth
preserving the old merge_only value here? */
opt.merge_only=1;
/* If refresh_add_fake_v3_keyids is on and it's a HKP or MAILTO /* If refresh_add_fake_v3_keyids is on and it's a HKP or MAILTO
scheme, then enable fake v3 keyid generation. */ scheme, then enable fake v3 keyid generation. */
if(opt.keyserver_options.refresh_add_fake_v3_keyids && if(opt.keyserver_options.refresh_add_fake_v3_keyids &&