Purifyng gnuPG 1.0.2

[Filippo Portera]

Hello folks,
here at RIPE NCC - Amsterdam we're evaluating gnuPG as the new standard 
for public key authentication of our new database.
So, while working on a gnuPG 1.0.1 C API I've ran Purify (a dynamic
memory
supervisor, that also does checks on uninitialized memory reads and
bound
checks, from Rational Software) on a SunOS system:

SunOS xxx 5.7 xxxxxxxxx sun4u sparc SUNW,Ultra-60

and here there are some interesting results abtained with gnuPG 1.0.2.

Compiling just with -g I noticed some memory leaks.

Example, for 'gpg -h':
 
>   Finished  gpg                  (   0 errors, 29 leaked bytes)
>      Purify instrumented gpg (pid 9052 at Mon Jul 24 17:31:33 2000)
>      Command-line: ./gpg -h 
>      Current file descriptors in use: 6
>      Memory leaked: 29 bytes (3.81%); potentially leaked: 0 bytes (0%)
>         MLK: 29 bytes leaked in 2 blocks
>         This memory was allocated from:
>               malloc         [rtlib.o]
>               m_alloc        [memory.c:404]
>                      p[4+EXTRA_ALIGN+n] = MAGIC_END_BYTE;
>                     return p+EXTRA_ALIGN+4;
>                    #else
>               =>     if( !(p = malloc( n )) )
>                          out_of_core(n,0);
>                      return p;
>                    #endif
>               m_strdup       [memory.c:589]
>                  FNAME(strdup)( const char *a FNAMEPRT )
>                  {
>                      size_t n = strlen(a);
>               =>     char *p = FNAME(alloc)(n+1 FNAMEARG);
>                      strcpy(p, a);
>                      return p;
>                  }
>              optfile_parse  [argparse.c:320]
>                                      char *p;
>                                      if( !buffer ) {
>                                          keyword[i] = 0;
>               =>                         buffer = m_strdup(keyword);
>                                      }
>                                     else 
>                                         buffer[i] = 0;
>               main           [g10.c:708]
>               _start         [crt1.o]
>         Block of 16 bytes at 0x233860
>        Block of 13 bytes at 0x2339c8
>         Purify Heap Analysis (combining suppressed and unsuppressed blocks)
>                                 Blocks        Bytes
>                       Leaked          2           29
>           Potentially Leaked          0            0
>                       In-Use         16          732
>           ----------------------------------------
>            Total Allocated         18          761
>      Program exited with status code 0.
>

This is not a big deal, since only 29 byes are leaked and gpg run only
once.
But perhaps this URMs are something to worry about:

>      Purify instrumented gpg (pid 25529 at Tue Jul 25 15:02:51 2000)
>      Command-line: ./gpg --no-options --quiet --yes --dearmor -o ./pubring.gpg \
>      UMR: Uninitialized memory read
>      This is occurring while in:
>            armor_filter   [armor.c:782]
>              armor_filter( void *opaque, int control,
>                            IOBUF a, byte *buf, size_t *ret_len)
>               {
>            =>     size_t size = *ret_len;
>                   armor_filter_context_t *afx = opaque;
>                   int rc=0, i, c;
>                   byte radbuf[3];
>            underflow      [iobuf.c:991]
>                           size_t dummy_len;
>               
>                           /* and tell the filter to free itself */
>            =>             if( (rc = a->filter(a->filter_ov, IOBUFCTRL_FREE,
>			                      a->chain,
>                                              NULL, &dummy_len)) )
 >                              log_error("IOBUFCTRL_FREE failed: %s\n",
>	 			g10_errstr(rc) );
>                           if( a->filter_ov && a->filter_ov_owner ) {
>            iobuf_readbyte [iobuf.c:1101]
>            dearmor_file   [dearmor.c:67]
>            main           [g10.c:1333]
>            _start         [crt1.o]
>      Reading 4 bytes from 0xffbef7f4 on the stack.
>      Address 0xffbef7f4 is local variable "b" in function underflow.

Variable dummy_len is not initialized.
Hope this could help.
Regards,
				Filippo