summaryrefslogtreecommitdiffstats
path: root/ssl/s23_srvr.c
diff options
context:
space:
mode:
authorBodo Möller <bodo@openssl.org>2001-10-24 19:03:22 +0000
committerBodo Möller <bodo@openssl.org>2001-10-24 19:03:22 +0000
commit979689aa5cfa100ccbc1f25064e9398be4b7b05c (patch)
tree363dad35cdaaba2b61eb34898433e4fb0495bcde /ssl/s23_srvr.c
parenta3faebd1041576a59bffe01bbd2c68495870ec5e (diff)
Fix SSL handshake functions and SSL_clear() such that SSL_clear()
never resets s->method to s->ctx->method when called from within one of the SSL handshake functions.
Diffstat (limited to 'ssl/s23_srvr.c')
-rw-r--r--ssl/s23_srvr.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/ssl/s23_srvr.c b/ssl/s23_srvr.c
index 8c41e1ff01..fe8bd33ce7 100644
--- a/ssl/s23_srvr.c
+++ b/ssl/s23_srvr.c
@@ -165,8 +165,8 @@ int ssl23_accept(SSL *s)
else if (s->ctx->info_callback != NULL)
cb=s->ctx->info_callback;
- if (!SSL_in_init(s) || SSL_in_before(s)) SSL_clear(s);
s->in_handshake++;
+ if (!SSL_in_init(s) || SSL_in_before(s)) SSL_clear(s);
for (;;)
{
ing.Doc */ .highlight .s2 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Double */ .highlight .se { color: #0044dd; background-color: #fff0f0 } /* Literal.String.Escape */ .highlight .sh { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Heredoc */ .highlight .si { color: #3333bb; background-color: #fff0f0 } /* Literal.String.Interpol */ .highlight .sx { color: #22bb22; background-color: #f0fff0 } /* Literal.String.Other */ .highlight .sr { color: #008800; background-color: #fff0ff } /* Literal.String.Regex */ .highlight .s1 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Single */ .highlight .ss { color: #aa6600; background-color: #fff0f0 } /* Literal.String.Symbol */ .highlight .bp { color: #003388 } /* Name.Builtin.Pseudo */ .highlight .fm { color: #0066bb; font-weight: bold } /* Name.Function.Magic */ .highlight .vc { color: #336699 } /* Name.Variable.Class */ .highlight .vg { color: #dd7700 } /* Name.Variable.Global */ .highlight .vi { color: #3333bb } /* Name.Variable.Instance */ .highlight .vm { color: #336699 } /* Name.Variable.Magic */ .highlight .il { color: #0000DD; font-weight: bold } /* Literal.Number.Integer.Long */
Problems are listed in approximate order of priority.

- Re-visit nametemplate support.  Currently, we use
  symbolic links in our temporary directory for this. When
  using /tmp, this may have security implementations and
  introduce race conditions.


- Fix the "unexpected EXPUNGE" IMAP bug.

- Ask IMAP servers for hierarchy separators. (-> Brandon's
  note from Aug 18)

- Apply proper quoting when sending imap "ASTRING"s.  (->
  John Prevost wrote something on this on Aug 19).

  
- In the "attachment" menu, assume this:

	1 [text/plain, 7bit, 1.1K]           <no description>
	2 [message/rfc822, 7bit, 6.1K]       A test message
	3 [text/plain, 7bit, 0.1K]           |-><no description>
	4 [message/rfc822, base64, 2.5K]     |-><no description>
	5 [message/rfc822, base64, 2.7K]     `-><no description>

  (please note the "message/rfc822" attachments encoded as
  Base64; that's illegal, but Sun's Mailtool sends that
  kind of messages); then go to, say, attachment "4",
  delete it, and go to the main menu; you won't be able to
  quit the mailbox (ok, 'x' works, but 'q' doesn't).

  The problem here lies in the fact that mutt uses mailbox
  handling functions to access message/rfc822 type
  attachments.  We'd need to perform an additional
  decoding step before using these functions to fix this
  bug.

  Please note that mutt's just assuming RFC-compliant mail
  here.  Fixing this stuff may become a PITA.



- mailbox resync code for mh and maildir mailboxes.  This
  will most probably help to fix the following problems:

  In maildir folders, the cursor will jump to an
  unpredictible message when new mail arrives.

  When accessing maildir folders with two mutts in
  parallel, messages which have been marked read (and thus
  moved to the cur/ subdirectory) by one of the mutts
  can't be read from the other one.



- BODY struct should probably have a pointer to its
  corresponding HEADER struct.  this is needed for
  mh/maildir mailboxes so the correct pathname can be
  found.  Or perhaps all we need is a .hdr member of the
  STATE struct so that all of the MIME handlers can look
  up the corresponding HEADERs if need be?

- option to not include attachments in replies

- handle message/external-body in some fashion

- handle message/partial reconstruction

- not possible to view the header of a single part message
  which contains something that requires a mailcap entry
  to view