security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2025-07-02 22:46:30 +02:00
Code Activity

* options.h, g10.c (main), encode.c (write_pubkey_enc_from_list),

Browse source 
pkclist.c (algo_available), revoke.c (gen_revoke): Add --pgp8 mode.  This
is basically identical to --pgp7 in all ways except that signing subkeys,
v4 data sigs (including expiration), and SK comments are allowed.

* getkey.c (finish_lookup): Comment.

* main.h, keylist.c (reorder_keyblock), keyedit.c (keyedit_menu): Reorder
user ID display in the --edit-key menu to match that of the --list-keys
display.

* g10.c (add_notation_data): Fix initialization.
This commit is contained in:
David Shaw 2002-12-03 23:31:48 +00:00
parent 768ded7c03
commit e357092285
10 changed files with 74 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

38
g10/pkclist.c
View file

@ -1103,19 +1103,20 @@ build_pk_list( STRLIST rcpts, PK_LIST *ret_pk_list, unsigned use )
/* In pgp6 mode, disallow all ciphers except IDEA (1), 3DES (2), and
CAST5 (3), all hashes except MD5 (1), SHA1 (2), and RIPEMD160 (3),
and all compressions except none (0) and ZIP (1). pgp7 mode
expands the cipher list to include AES128 (7), AES192 (8), AES256
(9), and TWOFISH (10). For a true PGP key all of this is unneeded
as they are the only items present in the preferences subpacket,
but checking here covers the weird case of encrypting to a key that
had preferences from a different implementation which was then used
with PGP. I am not completely comfortable with this as the right
thing to do, as it slightly alters the list of what the user is
supposedly requesting. It is not against the RFC however, as the
preference chosen will never be one that the user didn't specify
somewhere ("The implementation may use any mechanism to pick an
algorithm in the intersection"), and PGP has no mechanism to fix
such a broken preference list, so I'm including it. -dms */
and all compressions except none (0) and ZIP (1). pgp7 and pgp8
mode expands the cipher list to include AES128 (7), AES192 (8),
AES256 (9), and TWOFISH (10). For a true PGP key all of this is
unneeded as they are the only items present in the preferences
subpacket, but checking here covers the weird case of encrypting to
a key that had preferences from a different implementation which
was then used with PGP. I am not completely comfortable with this
as the right thing to do, as it slightly alters the list of what
the user is supposedly requesting. It is not against the RFC
however, as the preference chosen will never be one that the user
didn't specify somewhere ("The implementation may use any mechanism
to pick an algorithm in the intersection"), and PGP has no
mechanism to fix such a broken preference list, so I'm including
it. -dms */
static int
algo_available( int preftype, int algo, void *hint )
@ -1124,8 +1125,9 @@ algo_available( int preftype, int algo, void *hint )
if( opt.pgp6 && ( algo != 1 && algo != 2 && algo != 3) )
return 0;
if( opt.pgp7 && (algo != 1 && algo != 2 && algo != 3 &&
algo != 7 && algo != 8 && algo != 9 && algo != 10) )
if( (opt.pgp7 || opt.pgp8)
&& (algo != 1 && algo != 2 && algo != 3
&& algo != 7 && algo != 8 && algo != 9 && algo != 10) )
return 0;
return algo && !check_cipher_algo( algo );
@ -1139,13 +1141,15 @@ algo_available( int preftype, int algo, void *hint )
if(bits && (bits != md_digest_length(algo)))
return 0;
if( (opt.pgp6 || opt.pgp7 ) && ( algo != 1 && algo != 2 && algo != 3) )
if( (opt.pgp6 || opt.pgp7 || opt.pgp8 )
&& ( algo != 1 && algo != 2 && algo != 3) )
return 0;
return algo && !check_digest_algo( algo );
}
else if( preftype == PREFTYPE_ZIP ) {
if ( ( opt.pgp6 || opt.pgp7 ) && ( algo !=0 && algo != 1) )
if ( ( opt.pgp6 || opt.pgp7 || opt.pgp8 )
&& ( algo !=0 && algo != 1) )
return 0;
return !check_compress_algo( algo );