<<< Date Index >>>     <<< Thread Index >>>

Re: smime_keys: bug or me ???



On Sat, Jan 10, 2004 at 04:25:20PM -0600, Michael D Schleif wrote:
> OK, I am successfully reading and writing s/mime signed messages, and
> successfully encrypting and decrypting s/mime messages.
> 
> Most everything appears to behave as expected, except two (2) things:
> 
> [1] I get an odd error on verify; but, I think that doc/smime-notes.txt
> answers this with ``purpose fields of a certificate do not get verified
> yet'':
> 
>    # /usr/lib/mutt/smime_keys verify 0da0f5fe.0
>    ==> about to verify certificate of mds@xxxxxxxxxxx
>    /home/mds/.smime/certificates/0da0f5fe.0: /CN=Thawte Freemail \
>       Member/emailAddress=mds@xxxxxxxxxxx
>    error 26 at 0 depth lookup:unsupported certificate purpose
>    OK

I never encountered this particular error. But then, I never had to
verify Thawte certificates... Can you send us the certificate chain?
(If you didn't change the S/MIME related config variables copied from
contrib/smime.rc then sending a signed message should be sufficient.)

Perhaps it is possible to tweak the OpenSSL configuration to accept
this extension.

> [2] smime_keys stumbles badly at `list':
> 
>    # /usr/lib/mutt/smime_keys.ORIG list
>    0da0f5fe.0: Issued for: mds@xxxxxxxxxxx "thawte-personal" (Trusted)
>    Use of uninitialized value in string eq at /usr/lib/mutt/smime_keys.ORIG \
>       line 961, <F> line 1.
>    unable to load certificate
>    13958:error:0906D06C:PEM routines:PEM_read_bio:no start \
>       line:pem_lib.c:632:Expecting: TRUSTED CERTIFICATE
>    '/usr/bin/openssl x509 -subject -issuer -dates -noout -in \
>       /tmp/smime/cert_tmp.list -inform PEM' returned 256 at i\
>       /usr/lib/mutt/smime_keys.ORIG line 320, <F> line 1.
> 
> 
> Partly, this is due to smime_keys _not_ following the function template
> that it sets _twice_:
> 
>    # grep -n 'newfile *(' /usr/lib/mutt/smime_keys.ORIG | grep -v ','
>    29:sub newfile ($;$$);
>    735:    my $newindex = newfile("$path/.index.tmp");
>    952:sub newfile ($;$$) {
>    958:            $tmpdir = newfile("$tmpdir/smime");
> 
> 
> However, even with this:
> 
>    # diff -u /usr/lib/mutt/smime_keys.ORIG /usr/lib/mutt/smime_keys
>    +++ /usr/lib/mutt/smime_keys    2004-01-10 15:58:46.000000000 -0600
>    @@ -953,6 +953,8 @@
>            # returns a file name which does not exist for tmp file creation
>            my $filename = shift;
>            my $option = shift;
>    +       defined $option
>    +               or $option = "";
>            if (! $tmpdir and $option eq "temp") {
>                    $tmpdir = mutt_Q 'tmpdir';
>                    $tmpdir = newfile("$tmpdir/smime");

I already reported this minor bug on mutt-dev and submitted a
patch. Unfortunately, it was not commited to CVS, don't ask me why. 

The missing check for undefined $option causes a warning from the Perl
interpreter but has nothing to do with the failure of smime_keys list.

> I still get these errors:
> 
>    # /usr/lib/mutt/smime_keys list
>    0da0f5fe.0: Issued for: mds@xxxxxxxxxxx "thawte-personal" (Trusted)
     ^^^^^^^^^^^(1)
>    unable to load certificate
>    18868:error:0906D06C:PEM routines:PEM_read_bio:no start \
>       line:pem_lib.c:632:Expecting: TRUSTED CERTIFICATE
>    '/usr/bin/openssl x509 -subject -issuer -dates -noout -in \
>       /tmp/smime/cert_tmp.list -inform PEM' returned 256 at
        ^^^^^^^^^^^^^^^^^^^^^^^^(2)
>       /usr/lib/mutt/smime_keys line 320, <F> line 1.
> 
> 
> What do you think?


I am surprised - if I look at my copy of smime_keys then I don't
understand how you can get this error message. The output marked
(1) is the value of $fields[1]; the output marked (2) is the value of
$certfile, set to "$certificates_path/$fields[1]". Therefore, (2)
should be similar to $HOME/.smime/certificates/0da0f5fe.0. You can't
blame openssl for failing if it is given the wrong file...

I don't get any errors with "smime_keys list", but the line number
reported in the error message above does not match with my smime_keys,
either. I attached my copy - perhaps a diff shows the reason for your
problem. 

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Attachment: smime_keys.cludwig.gz
Description: application/gunzip