Subject: Bug in pine_send() (malloc'ed buffer is too small)

From: Steinar Haug <[email-masked]>
Date: Sun, 28 Mar 1993 16:18:22 +0200 (MET DST)

When I started up pine today, it bombed out on me when I tried to compose a
message. (Actually "bombed out" is too strong: It caught a SEGV signal, and
gave me a nice descriptive error message.)

I spent some time tracking it down, and this is what I found. In pine/send.c,
in routine pine_send(), a buffer of 40 characters is malloc'ed, and then
rfc822_date() is called to put a properly formatted date field into this
buffer. However, the date field that I got today looks like this:

	Sun, 28 Mar 1993 16:00:54 +0200 (MET DST)

This field is 41 characters long, not including the terminating NULL.  The
reason it has not occurred earlier is probably that we switched to Daylight
Savings Time here in Norway last night.

By the way, it's not obvious to me that this date field conforms to RFC 822.
The problem is in the timezone specification. The way I read it, you should
have either a numeric zone specification or an alphanumeric one but not both.
Comments?

I made the following simple fix to pine_send():
----------------------------------------------------------------------
*** send.c.orig	Mon Aug 31 23:48:27 1992
--- send.c	Sun Mar 28 16:08:53 1993
***************
*** 441,447 ****
  
      /*----- Fill in a few general parts of the envelope ----*/
      if(outgoing->date == NULL)
!       outgoing->date = fs_get(40); /* Date's always 30 or so */
      rfc822_date(outgoing->date);
  
      if(outgoing->subject == NULL) {
--- 441,447 ----
  
      /*----- Fill in a few general parts of the envelope ----*/
      if(outgoing->date == NULL)
!       outgoing->date = fs_get(50); /* Date's up to 42 characters */
      rfc822_date(outgoing->date);
  
      if(outgoing->subject == NULL) {
----------------------------------------------------------------------

Steinar Haug, system/networks administrator
SINTEF RUNIT, University of Trondheim, NORWAY
Email: [email-masked], [email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Sun, 28 Mar 1993 13:47:33 -0800 (PST)

Steinar -

     Thank you very much for your Pine bug report.  I expect that it will be
fixed in the forthcoming new release of Pine.

     The date format used by Pine is legal according to RFC-822.  The timezone
is in parenthesis, making it a comment.  The timezone that a parser sees is
the numeric one.

     We used numeric timezones because RFC-822 only permits the two synonyms
for Coordinated Universal time (UT and GMT), four of the timezones used in the
Americas and their summer time equivalents (EST/EDT, CST/CDT, MST/MDT,
PST/PDT), and the single-letter military timezones (although RFC-822 documents
them incorrectly; A is +1000 and N is -1000).  [Although charges of ``US-
centricism'' have been made, note that not even all the US timezones are
covered!]  Since some areas use non-integral hour offsets from UT, not even
the military time zone names are adequate for world-wide usage.

     Since many people find symbolic timezones more friendly, and because
there are no restrictions on what appears in a comment, we put the local
symbolic timezone, when known, in a comment.  Thus our friends in Japan can
see ``JST'', while in Korea (who are in the same timezone) they see ``KST'',
and of course you can use ``MET DST''.

     You are quite right that it is a bug that Pine assume that the local
timezone string is no more than 5 characters long.  The fs_get of only 40
bytes was most likely due to an excessive effort to save memory (something
that has become quite important with the DOS port!).  It would probably be
better to allocate something like 64 bytes to be safe.

     Thank you again for your interest in Pine.

-- Mark --

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 28 Mar 1993 22:18:10 -0500 (EST)

Hi,
  I think that time zone format is coming from your system some how, not
necessarily generated by Pine. The code that generates that date is in
c-client/os-xxx.c and varies from machine to machine (depends on what port
of Pine you compiled, nxt, ult, sun....) so it would be good if you could
check out what's happening on your machine. 

LL

---

From: Mark Crispin <[email-masked]>
Date: Sun, 28 Mar 1993 19:33:18 -0800 (PST)

> check out what's happening on your machine.

The format of the date, including the timezone information, is generated by
the routine rfc822_date() in c-client's os_xxx.c file.

The symbolic timezone string comes from the system, and ``MET DST'' is a
perfectly reasonable of central European summer time.  So this bug is in our
court, not Steinar's.  Fortunately, this one is easy to fix!

I've seen some pretty funky time formats in other regions of the world that
have surprised our software at times, so it's going to we get informed of any
such problems that come up.