gmane.mail.mutt.devel

Re: [Mutt] #3642: Missing header when building against S-Lang

Mutt — 2013-05-03T19:03:40

#3642: Missing header when building against S-Lang
--------------------------+----------------------
  Reporter:  baskerville  |      Owner:  mutt-dev
      Type:  defect       |     Status:  new
  Priority:  major        |  Milestone:
 Component:  build        |    Version:
Resolution:               |   Keywords:
--------------------------+----------------------
Changes (by baskerville):

 * owner:  brendan => mutt-dev
 * component:  IMAP => build

[Mutt] #3642: Missing header when building against S-Lang

Mutt — 2013-05-03T18:41:21

#3642: Missing header when building against S-Lang
-------------------------+---------------------
 Reporter:  baskerville  |      Owner:  brendan
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  IMAP         |    Version:
 Keywords:               |
-------------------------+---------------------
 The following:

 {{{
 ./prepare \
     --prefix=/usr \
     --sysconfdir=/etc \
     --enable-gpgme \
     --enable-hcache \
     --with-slang=/usr \
     --with-regex \
     --with-idn
 make
 }}}

 yields

 {{{
 crypt-gpgme.c: In function ‘init_common’:
 crypt-gpgme.c:4369:15: error: ‘true’ undeclared (first use in this
 function)
      has_run = true;
 }}}

 The following patch ''solves'' the problem:
 {{{
 diff -r d498f0e91914 crypt-gpgme.c
 --- a/crypt-gpgme.c     Mon Mar 04 04:14:43 2013 +0000
 +++ b/crypt-gpgme.c     Sat Mar 23 11:58:04 2013 +0100
 < at >< at > -39,6 +39,7 < at >< at >
  #include <sys/wait.h>
  #include <string.h>
  #include <stdlib.h>
 +#include <stdbool.h>

Re: the mutt development vacuum

Kevin J. McCarthy — 2013-04-29T17:42:07

Hurray!  Congratulations (and thank you) Vincent!

-Kevin

Re: the mutt development vacuum

Brendan Cully — 2013-04-29T17:08:54

Some good news on this front: Vincent Lefevre, whom I'm sure everyone
here knows well, has agreed to become a committer!

Re: [PATCH 4 of 3] Update documentation when cycling

Kevin J. McCarthy — 2013-04-28T19:15:03

Adding a patch to the series with a documentation update.  Also uploaded
to the ticket.

-Kevin

Re: [PATCH 3 of 3] Save the scratch buffer when scrolling through history. (closes #3082)

Kevin J. McCarthy — 2013-04-28T01:00:05

Sorry, another small fix.

mutt_history_save_scratch() should use h->last instead of h->cur
(which _mutt_enter_string() is verifying are equal, but still).

Revised patch attached and uploaded to trac.

-Kevin

Re: [PATCH 1 of 3] Increase the size of the history array by 1. (see #3082)

Kevin J. McCarthy — 2013-04-27T23:13:57

As soon as I sent the patch, I realized I forgot to fix the
re-allocation loop with OldSize in init_history().

Corrected patch attached, and uploaded to trac too.

-Kevin

[PATCH 1 of 3] Increase the size of the history array by 1. (see #3082)

Kevin J. McCarthy — 2013-04-27T22:48:24

This gives a place to store the stratch buffer while preserving the
size of history.  The scratch buffer will be stored at h->last.


 history.c |  10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

[PATCH 3 of 3] Save the scratch buffer when scrolling through history. (closes #3082)

Kevin J. McCarthy — 2013-04-27T22:48:26

This solution only preserves the current input for the scratch buffer
(the initial location in history when they first start editing).

If the user scrolls through history and starts editing a previous entry,
their edits will not be preserved if they continue scrolling through
history and back.


 enter.c   |  10 ++++++++++
 history.c |  31 ++++++++++++++++++++++++++++---
 history.h |   2 ++
 3 files changed, 40 insertions(+), 3 deletions(-)

[PATCH 2 of 3] Reset history state after exiting mutt_enter_string (see #3082)

Kevin J. McCarthy — 2013-04-27T22:48:25

This makes it so that the "scratch buffer" entry is used by default, and
allows mutt to preserve what the user types if they go through history
and back.


 enter.c   |   1 +
 history.c |  10 ++++++++++
 history.h |   1 +
 3 files changed, 12 insertions(+), 0 deletions(-)

[PATCH 0 of 3] Ticket #3082 preserve current input in history when cycling

Kevin J. McCarthy — 2013-04-27T22:48:23

I'm attaching a 3-part patch that is one possible solution to this. It
creates an extra slot in the History ring for a scratch buffer (at
h->last). If you are editing inside that buffer, it is preserved when
you scroll up/down through the history. Editing while in other places in
history are *not* preserved with this patch.

I thought about creating a scratch history array instead, and trying to
preserve all edits in a temporary history array until done. But that
seemed a lot more complexity and work for a smaller usage case. Of
course if other people think that's important I'll be glad to work on
that alternative.

Another behavior change worth noting with this patch: the position
in history is now reset to the scratch buffer after each input
entry. Before, the position would be stay wherever it was - you didn't
restart at the "bottom" each time.

 history.c |  10 +++++-----
 enter.c   |   1 +
 history.c |  10 ++++++++++
 history.h |   1 +
 enter.c   |  10 ++++++++++
 history.c |  31 +++++++++++++++++++++++

Re: [Mutt] #3082: current input not preserved in history when cycling

Mutt — 2013-04-27T22:43:43

#3082: current input not preserved in history when cycling
---------------------+----------------------
  Reporter:  Ulrich  |      Owner:  kevin8t8
      Type:  defect  |     Status:  assigned
  Priority:  major   |  Milestone:
 Component:  mutt    |    Version:
Resolution:          |   Keywords:
---------------------+----------------------
Changes (by kevin8t8):

 * cc: kevin< at >… (added)
 * owner:  mutt-dev => kevin8t8
 * status:  new => assigned


Comment:

 I'm attaching a 3-part patch that is one possible solution to this.  It
 creates an extra slot in the History ring for a scratch buffer (at
 h->last).  If you are editing inside that buffer, it is preserved when you
 scroll up/down through the history.  Editing while in other places in
 history are *not* preserved with this patch.

 I thought about creating a scratch history array instead, and trying to
 preserve all edits in a temporary history array until done.  But that
 seemed a lot more complexity and work for a smaller usage case.  Of course
 if

Re: [Mutt] #3638: Compilation errors for 1.6

David Laight — 2013-04-26T21:50:20

NFSv2 has more problems than you might imagine.

Open with O_CREAT|O_EXCL can fail EEXIST even when the file didn't
exist and no other systems are involved. All it takes is for the
response to be timed out - the retry fails because the original
request created the file.
I hit that problem doing 'cp -r' and getting mkdir failing EEXIST,
in my case caused by the target taking a long time to respond due
to flash erases (and the initiator assuming constant RTT).

In general, NFSv2 has the following properties:
1) If you export part of a filesystem, you export all of it.
2) If you give anyone read access you give everyone read access.
3) If you give anyone write access you give everyone write access.
Most of that is because the permission checks are done by the
mount protocol - and then assume the client obeys the rules.
(2) Requires a file handle be generated - this used to be very easy!

David

Re: [Mutt] #3638: Compilation errors for 1.6

Will Fiveash — 2013-04-26T20:53:48

In regards to Solaris and /dev/random, read
https://blogs.oracle.com/yenduri/entry/dev_random_in_solaris.  Solaris 8
is very old news.  As an aside, I know that Solaris 11 provides
mkstemp(), mkstemps() and tmpfile() any of which I'd like to see used by
mutt.  Perhaps use of one of these functions by mutt could be #ifdef'ed
depending on whether configure finds it supported on the platform it's
run on?

Re: [Mutt] #3638: Compilation errors for 1.6

Derek Martin — 2013-04-26T20:16:27

Sorry, yes, you're correct.  It's not just Linux... it's basically
every major Unix variant in production today, though
implementations vary.  Also:

  http://en.wikipedia.org/wiki//dev/random

    In 2004, Landon Curt Noll, Simon Cooper, and Mel Pleasant
    tested a variety of random number generators, including the
    /dev/random implementations in FreeBSD 5.2.1, Linux 2.4.21-20,
    Solaris 8 patch 108528-18, and Mac OS X 10.3.5.[7] They
    indicated that none of these /dev/random implementations were
    cryptographically secure because their outputs had uniformity
    flaws.

So, using the microsecond-resolution system clock is probably as
good, if not better.

Like I said, this is an annoyingly hard problem.

Re: [Mutt] #3638: Compilation errors for 1.6

Ian Collier — 2013-04-26T19:57:45

On systems with a Linux kernel, /dev/urandom does not block but produces
lower entropy pseudorandom numbers instead.  The /dev/random device
does block, and is used when full entropy is essential.

imc

Re: [Mutt] #3638: Compilation errors for 1.6

Derek Martin — 2013-04-26T19:17:49

That's right, but this is why your TEMP_DIR shouldn't ever be on NFS.
Or at least, when NFS is NFS < v3.


The spec guarantees nothing; but in practice implementations are
better than that.

The reality is, if you care about security, you're not using an older
system, you're not using NFSv2, and none of these issues affect you.
If that's not the case, it's really your fault (and your problem).

Again, it comes down to what platforms are (or should be) considered
supported for Mutt.


Nothing.


No, but you can't link() a file that doesn't already exist, so you
need to have opened the file securely in the first place.  The
discussion regarding the O_EXCL race in the man page describes how
link() can be used safely to create a *LOCK FILE*; it is not adequate
for opening a secure temporary file.  The assumption is that in your
lock file construct, the contents of the lock file are not
interesting.  With a temporary file, they are.  


The hardware clock is sufficient... when it is.  In other words, on
systems

Re: Adding "closes #" to changeset

Brendan Cully — 2013-04-26T18:04:31

yes, that sounds good. You can add (see #nnn) to preparatory patches
if you're inclined. That generates a link from the ticket to the
commit but doesn't change the ticket status.

Sorry I haven't gotten to your other patches this week, I'll try to
reserve some time this weekend for it if no other dev jumps on
them. Thanks again for your work.

Re: [Mutt] #3638: Compilation errors for 1.6

Ian Collier — 2013-04-26T17:52:55

I'm reading this discussion with interest, more for my own academic
curiosity than anything practical.  As I understand it (and would
welcome corrections if I'm wrong)...

 - Mutt uses mktemp to help compute a unique filename, then opens the
   file with O_CREAT|O_EXCL.
 - The alternative is to use mktemps to open a file with whatever
   guarantees the OS gives you, then use link to give the file a
   name that has the desired suffix.

The attacks that mktemp has to defend against are:

 - content attacks, where the attacker wants you to open a file that
   they've created;
 - symlink attacks, where the attacker wants you to follow a symlink
   and thus open a file in an unsafe location, and
 - DOS attacks, where the attacker wants to prevent you from opening
   a tempfile by creating it before you do.

Opening the file with O_CREAT|O_EXCL is a solid defense against the
first two attacks in almost all common cases except when the temp
filesystem is mounted over NFSv2.  Using sufficient randomness with
a lar

Re: [Mutt] #3638: Compilation errors for 1.6

Derek Martin — 2013-04-26T15:31:46

Well then you don't have a clue.  Let me spell it out for you:

Script started on Fri 26 Apr 2013 10:08:08 AM CDT
$ ls -l /var/spool/mail
total 0
-rw------- 1 ddm mail 0 Apr 26 10:04 ddm
$ sudo useradd test1
$ sudo useradd test2
$ sudo useradd attacker
$ telnet mail.mydomain.SANITIZED 25
Trying SANITIZED_IP...
Connected to mail.mydomain.SANITIZED.
Escape character is '^]'.
220 SANITIZED ESMTP Sendmail 8.13.8/8.13.8; Fri, 26 Apr 2013 10:09:04 -0500
ehlo pizzashack.org
250-SANITIZED Hello SANITIZED [SANITIZED_IP], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
mail from: attacker
553 5.5.4 attacker... Domain name required for sender address attacker
mail from: attacker< at >somewhere.com
250 2.1.0 attacker< at >somewhere.com... Sender ok
rcpt to: test1
250 2.1.5 test1... Recipient ok
rcpt to: test2
250 2.1.5 test2... Recipient ok
rcpt to: attacker
250 2.1.5 attacker... Recipient ok
data
354 Enter mail, end with "." on a line by itself
From: me< at >my

Re: [Mutt] #3638: Compilation errors for 1.6

Vincent Lefevre — 2013-04-26T11:49:10

Wrong. This is not what I can see. Well, if I send the same mail
to 2 addresses different due to aliasing, the IDs are the same,
but if I use 2 addresses <local< at >domain> and <local+foo< at >domain>,
the IDs of the latest Received are different:

Received: from localhost (localhost [127.0.0.1])
        by jabiru.ens-lyon.fr (Postfix) with ESMTP id A681BA3AE3
        for <xxx+foo< at >vinc17.net>; Fri, 26 Apr 2013 13:19:24 +0200
        (CEST)

Received: from localhost (localhost [127.0.0.1])
        by jabiru.ens-lyon.fr (Postfix) with ESMTP id A9C99A3AFE
        for <xxx< at >vinc17.net>; Fri, 26 Apr 2013 13:19:24 +0200 (CEST)


I'm not sure that the same SMTP transactions can be used (at least the
latest ones in the chain): different users may have different antispam
rules at the site level...

The behavior may depend on the site. But at least on some sites, it
could be regarded as a source of random, even if the attacker has
mail access on the same site. So, there's no reason to reject this
method, unless there's a 100%