mutt: Corrected comment.

[Brendan Cully]

changeset: 6874:b22c5d0e299d
user:  Vincent Lefevre 
date:  Tue Nov 22 03:48:10 2016 +0100
link:  http://dev.mutt.org/hg/mutt/rev/b22c5d0e299d

Corrected comment.

diffs (12 lines):

diff -r 65f180f2904f -r b22c5d0e299d mutt_ssl.c
--- a/mutt_ssl.cMon Nov 21 18:03:20 2016 -0800
+++ b/mutt_ssl.cTue Nov 22 03:48:10 2016 +0100
@@ -969,7 +969,7 @@
 #ifdef DEBUG
   char buf[STRING];
 
-  /* Note that X509_NAME_online will NULL-terminate buf, even when it
+  /* Note that X509_NAME_oneline will null-terminate buf, even when it
* has to truncate the data. */
   dprint (1, (debugfile, "ssl_check_certificate: checking cert %s\n",
   X509_NAME_oneline (X509_get_subject_name (data->cert),

Re: NULL vs NUL (changeset: 6873:65f180f2904f)

[Kevin J. McCarthy]

On Tue, Nov 22, 2016 at 03:47:37AM +0100, Vincent Lefevre wrote:
> In C, the byte 0 is called the "null character". NUL is definitely
> wrong in this context, as C may be based on a character set other
> than ASCII or EBCDIC, while the null character is charset independent.

Thanks Claus and Vincent, for the interesting discussion and the
commit-fix.  Something was telling me NULL was incorrect, when I typed
it.  Now I know what to use in the future!

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Legal values for a message-id, and references header

[Vincent Lefevre]

On 2016-11-20 18:51:25 +1100, Cameron Simpson wrote:
> On 19Nov2016 19:58, Kevin J. McCarthy  wrote:
> > On Sun, Nov 20, 2016 at 10:08:13AM +1100, Cameron Simpson wrote:
> > > On 19Nov2016 13:13, Kevin J. McCarthy  wrote:
> > > > Should mutt be rfc-2047 encoding/decoding the references
> > > > header?
> > > 
> > > No. RFC2047 tokens need to be whitespace delimited from the surrounding
> > > text.  No whitespace is permitted inside the "<" and ">" markers which
> > > enclose a message-id:
> > 
> > Thank you for your detailed analysis, Cameron.  I will take a deeper
> > look at this soon.  Another piece of information is that they sent a
> > reply through the Fastmail web interface, which sent this:
> > 
> >  References: =?utf-8?Q?=3C201611170549=2EQ3WT?=
> >=?utf-8?Q?foMB=C3=83=C2=BEngguang=2Ewu=40i?=
> >=?utf-8?Q?ntel=2Ecom=3E=20=3C1479410?= =?utf-8?Q?777-6702-1-git-sen?=
> >=?utf-8?Q?d-email-manuel=2Esch?= =?utf-8?Q?oelling=40gmx=2Ede=3E?=
> > 
> >  
> > 
> > If this is legal, then mutt needs to be decoding the References before
> > trying to parse out the ids, because I believe it will just choke on
> > this.
> 
> Wow. I would have thought that was illegal.

That's clearly illegal. MIME has been designed so that the main
features should still work with software that doesn't support MIME
(said otherwise, software that only needs to work with addresses
and Message-ID's does not need to support MIME).

> Regarding the discussion below, the TL;DR is that I think that if it is
> feasible mutt should decode these, but write _unencoded_ versions of these
> headers and any headers derived from them. In particular, is it easy to make
> mutt's header ingestion code go "stict parse, but if that fails decode with
> RFC2047 and try a second time"? Probably on a specific header basis.

I don't think that Mutt should even try to support these. This could
lead to various problems. First, what to do with characters that are
illegal (e.g. non-ASCII) in a Message-ID...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

NULL vs NUL (changeset: 6873:65f180f2904f)

[Claus Assmann]

On Mon, Nov 21, 2016, Brendan Cully wrote:
> changeset: 6873:65f180f2904f

> X509_NAME_oneline() always NULL-terminates the string, even when it

Isn't the common terminology:
NULL: NULL pointer
NUL: '\0'
?

> +  /* Note that X509_NAME_online will NULL-terminate buf, even when it
  ^e   ^
->

> +  /* Note that X509_NAME_oneline will NUL-terminate buf, even when it

mutt: Revert db13010a2e8d but add a comment. (see #3870)

[Brendan Cully]

changeset: 6873:65f180f2904f
user:  Kevin McCarthy 
date:  Mon Nov 21 18:03:20 2016 -0800
link:  http://dev.mutt.org/hg/mutt/rev/65f180f2904f

Revert db13010a2e8d but add a comment. (see #3870)

X509_NAME_oneline() always NULL-terminates the string, even when it
has to truncate the data to fit in buf.

diffs (26 lines):

diff -r db13010a2e8d -r 65f180f2904f mutt_ssl.c
--- a/mutt_ssl.cMon Nov 21 23:10:47 2016 +0100
+++ b/mutt_ssl.cMon Nov 21 18:03:20 2016 -0800
@@ -969,10 +969,11 @@
 #ifdef DEBUG
   char buf[STRING];
 
-  buf[STRING - 1] = '\0';
+  /* Note that X509_NAME_online will NULL-terminate buf, even when it
+   * has to truncate the data. */
   dprint (1, (debugfile, "ssl_check_certificate: checking cert %s\n",
   X509_NAME_oneline (X509_get_subject_name (data->cert),
- buf, sizeof (buf) - 1)));
+ buf, sizeof (buf;
 #endif
 
   if ((preauthrc = ssl_check_preauth (data->cert, conn->account.host)) > 0)
@@ -992,7 +993,7 @@
 
 dprint (1, (debugfile, "ssl_check_certificate: checking cert chain entry 
%s\n",
 X509_NAME_oneline (X509_get_subject_name (cert),
-   buf, sizeof (buf) - 1)));
+   buf, sizeof (buf;
 
 /* if the certificate validates or is manually accepted, then add it to
  * the trusted set and recheck the peer certificate */

[Mutt] #3899: mutt_ssl's interactive_check_cert() has several issues

[Mutt]

#3899: mutt_ssl's interactive_check_cert() has several issues
--+--
 Reporter:  kevin8t8  |  Owner:  mutt-dev
 Type:  defect| Status:  new
 Priority:  major |  Milestone:
Component:  crypto|Version:
 Keywords:|
--+--
 It is calling X509_NAME_oneline() with a fixed sized buffer.

 It is using strstr to tokenize the parts of the certificate name.  The
 problem with this approach is described in
 https://langui.sh/2016/01/29/x509-name-oneline/

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3870: openssl 1.1

[Mutt]

#3870: openssl 1.1
--+--
  Reporter:  tamo |  Owner:  mutt-dev
  Type:  task | Status:  closed
  Priority:  trivial  |  Milestone:
 Component:  build|Version:  1.7.0
Resolution:  fixed|   Keywords:  ssl
--+--

Comment (by Kevin McCarthy ):

 In [changeset:"65f180f2904f0511268d7d3f1c6e4b7ebe93d300"
 6873:65f180f2904f]:
 {{{
 #!CommitTicketReference repository=""
 revision="65f180f2904f0511268d7d3f1c6e4b7ebe93d300"
 Revert db13010a2e8d but add a comment. (see #3870)

 X509_NAME_oneline() always NULL-terminates the string, even when it
 has to truncate the data to fit in buf.
 }}}

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: mutt fails to cross build from source

[Derek Martin]

On Tue, Nov 15, 2016 at 01:29:15PM +, Andras Salamon wrote:
> The versions of Perl shipped with MacOS 10.10 to 10.12 have Digest::MD5;
> the Ruby and Python versions don't seem to include an MD5 module.  

I can't speak for Ruby, but Python should definitely have one.  Older
Python (like 2.4 and older) has md5, and newer python has hashlib,
which supports every hash variant I've ever heard of, and a few I
haven't.  ;-)

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpUSVVB3jJLD.pgp
Description: PGP signature

Re: [Mutt] #3870: openssl 1.1

[Mutt]

#3870: openssl 1.1
--+--
  Reporter:  tamo |  Owner:  mutt-dev
  Type:  task | Status:  closed
  Priority:  trivial  |  Milestone:
 Component:  build|Version:  1.7.0
Resolution:  fixed|   Keywords:  ssl
--+--

Comment (by kevin8t8):

 Thanks Vincent.  Just to note, I looked in the openssl source (for
 versions v1.1, 1.0.2, and 1.0.1) before making this change.
 {{{X509_NAME_oneline}}} decrements the buflen parameter by one internally
 (to leave space for the null-terminator), and does null-terminate the
 buffer even in the event the length is not long enough.

 I also noted the "strongly discouraged" label, but I agree this isn't
 critical for debugging.

 Unfortunately, we are also using this function in our
 interactive_check_cert() function, so there might be an issue there.

 Also, the 1.0.2 and 1.0.1 versions used {{{OPENSSL_free}}} internally for
 freeing the return value (inside crypto/asn1/x_x509.c}.

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3870: openssl 1.1

[Mutt]

#3870: openssl 1.1
--+--
  Reporter:  tamo |  Owner:  mutt-dev
  Type:  task | Status:  closed
  Priority:  trivial  |  Milestone:
 Component:  build|Version:  1.7.0
Resolution:  fixed|   Keywords:  ssl
--+--

Comment (by vinc17):

 The {{{X509_NAME_oneline}}} documentation is ambiguous: it does not say
 that its output is null-terminated if the number of characters reaches the
 buffer size, and according to https://langui.sh/2016/01/29/x509-name-
 oneline/ it isn't in such a case. I've fixed the code in
 r6872:db13010a2e8d.

 To avoid the truncation, it is also possible to ask the library to do the
 allocation by providing a null pointer, but it is not clear how to free
 the memory ({{{free}}} or {{{OPENSSL_free}}}?), and anyway, a truncation
 is acceptable in a debugging message. Ditto for the fact that the use of
 {{{X509_NAME_oneline}}} is "strongly discouraged".

--
Ticket URL: 
Mutt 
The Mutt mail user agent

mutt: Make sure that the output of X509_NAME_oneline is null-ter...

[Brendan Cully]

changeset: 6872:db13010a2e8d
user:  Vincent Lefevre 
date:  Mon Nov 21 23:10:47 2016 +0100
link:  http://dev.mutt.org/hg/mutt/rev/db13010a2e8d

Make sure that the output of X509_NAME_oneline is null-terminated.

diffs (24 lines):

diff -r c770d2fa615b -r db13010a2e8d mutt_ssl.c
--- a/mutt_ssl.cSun Nov 20 16:19:18 2016 -0800
+++ b/mutt_ssl.cMon Nov 21 23:10:47 2016 +0100
@@ -969,9 +969,10 @@
 #ifdef DEBUG
   char buf[STRING];
 
+  buf[STRING - 1] = '\0';
   dprint (1, (debugfile, "ssl_check_certificate: checking cert %s\n",
   X509_NAME_oneline (X509_get_subject_name (data->cert),
- buf, sizeof (buf;
+ buf, sizeof (buf) - 1)));
 #endif
 
   if ((preauthrc = ssl_check_preauth (data->cert, conn->account.host)) > 0)
@@ -991,7 +992,7 @@
 
 dprint (1, (debugfile, "ssl_check_certificate: checking cert chain entry 
%s\n",
 X509_NAME_oneline (X509_get_subject_name (cert),
-   buf, sizeof (buf;
+   buf, sizeof (buf) - 1)));
 
 /* if the certificate validates or is manually accepted, then add it to
  * the trusted set and recheck the peer certificate */