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

See ChangeLog: Thu Jan 13 19:31:58 CET 2000 Werner Koch

Browse source
This commit is contained in:
Werner Koch 2000-01-13 18:27:50 +00:00
parent f1a2395f08
commit e8164f20ab
32 changed files with 524 additions and 400 deletions
Download patch file Download diff file Expand all files Collapse all files

7
g10/ChangeLog
View file

@ -1,3 +1,10 @@
Thu Jan 13 19:31:58 CET 2000 Werner Koch <wk@gnupg.de>
* armor.c (is_armored): Check for 1-pass-sig packets. Reported by
David Hallinan <hallinan@rtd.com>.
(armor_filter): Replaced one LF by the LF macro. Reported by
Wolfgang Redtenbacher.
Wed Jan 5 11:51:17 CET 2000 Werner Koch <wk@gnupg.de>
* g10.c (main): Reset new global flag opt.pgp2_workarounds

3
g10/armor.c
View file

@ -167,6 +167,7 @@ is_armored( const byte *buf )
switch( pkttype ) {
case PKT_MARKER:
case PKT_SYMKEY_ENC:
case PKT_ONEPASS_SIG:
case PKT_PUBLIC_KEY:
case PKT_SECRET_KEY:
case PKT_PUBKEY_ENC:
@ -1020,7 +1021,7 @@ armor_filter( void *opaque, int control,
iobuf_put(a, c);
c = bintoasc[radbuf[2]&077];
iobuf_put(a, c);
iobuf_put(a, '\n');
iobuf_writestr(a, LF );
/* and the the trailer */
if( afx->what >= DIM(tail_strings) )
log_bug("afx->what=%d", afx->what);

6
g10/trustdb.c
View file

@ -1405,7 +1405,7 @@ make_uid_records( KBNODE keyblock, ulong lid, u32 *keyid, u32 *min_expire,
/* the next test is really bad because we should modify
* out modification timestamps only if we really have a change.
* But becuase we are deleting the uid records first it is somewhat
* But because we are deleting the uid records first it is somewhat
* difficult to track those changes. fixme */
if( !( u->r.uid.uidflags & UIDF_VALID )
|| ( u->r.uid.uidflags & UIDF_REVOKED ) )
@ -2085,8 +2085,8 @@ verify_key( int max_depth, TRUSTREC *drec, const char *namehash,
if( namehash && tree->n.k.validity != TRUST_ULTIMATE ) {
/* find the matching user id.
* We don't do this here if the key is ultimately trusted; in
* this case there will be no lits od user IDs and frankly
* it doe not make sense to compare by the name if we do
* this case there will be no lids for the user IDs and frankly
* it does not make sense to compare by the name if we do
* have the secret key.
* fixme: the way we handle this is too inefficient */
TN ur;