Re: Smime problem when smime_ask_for_key is called in smime_findKeys
On Sun, Feb 20, 2005 at 16:40:34 +0900, Tamotsu Takahashi wrote:
> On Sat, Feb 19, 2005 at 01:59:56PM +0100, Udo Schweigert wrote:
> > A change to smime.c introduced with mutt-1.5.7 causes smime en/decryption to
> > fail under circumstances which need a call to smime_ask_for_key. This is
> > the case if no default smime key has been specified or a recipient's key
> > can't be figured out.
>
> FYI: The change was from this discussion:
> http://marc.theaimsgroup.com/?l=mutt-dev&m=109916937716984&w=2
> (MARC: msg 'Re: Various potential buffer overflows and format string bugs')
>
> ChangeLog:
> 2004-10-30 21:59:00 Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
> (roessler)
> * smime.c: Fix bad code in smime_get_field_from_db.
Ah, I see. Thanks for pointing that out. In that discussion Thomas Roessler
wrote:
> Basically, smime_get_field_from_db was doing quite a bit of
> reallocating and other stuff just to append a newline to the string stored in
> key, but that newline was only needed in a single place (where it could be
> added much easier), and the length of key was naturally limited by the length
> of a single field.
>
> (Note that I don't have S/MIME installed here, so this is untested. Please
> report back whether the change breaks anything.)
As I wrote in my first posting this breaks smime in certain cases. An
other option would be to change smime_ask_for_key() to not append a newline:
--- smime.c.orig Sat Feb 19 13:49:51 2005
+++ smime.c Sun Feb 20 08:58:35 2005
@@ -464,8 +464,8 @@
}
}
if (hash) {
- fname = safe_malloc(14); /* Hash + '.' + Suffix + \n + \0 */
- sprintf(fname, "%.8x.%i\n", Table[cur].hash, Table[cur].suffix);
+ fname = safe_malloc(13); /* Hash + '.' + Suffix + \0 */
+ sprintf(fname, "%.8x.%i", Table[cur].hash, Table[cur].suffix);
}
else fname = NULL;
Best regards
--
Udo Schweigert, Siemens AG | Voice : +49 89 636 42170
CT IC CERT, Siemens CERT | Fax : +49 89 636 41166
D-81730 Muenchen / Germany | email : udo.schweigert@xxxxxxxxxxx