Re: mutt: Remove 'hit enter' prompt for GPGME initialization errors.

[Eike Rathke]

Hi,

On Sunday, 2015-07-05 13:40:43 -0700, Brendan Cully wrote:

> Older GPGMEs are missing CMS (S/MIME) support.  Don't force the poor
> users to hit enter every time they start mutt.

What is "older" exactly? And could we assume that anyone using a recent
mutt would not be using such "older" GPGME? Instead, wouldn't be
checking the GPGME version number and only suppressing the confirmation
if it is known to be "older" a more user friendly approach, so actually
wait for a key when the GPGME version is expected to support CMS but
does not?

Anyhow, this ...

>if (gpgme_engine_check_version (GPGME_PROTOCOL_OpenPGP) != 
> GPG_ERR_NO_ERROR)
>{
>  mutt_error (_("GPGME: OpenPGP protocol not available"));
> -if (mutt_any_key_to_continue (NULL) == -1)
> -  mutt_exit(1);

... removing also the OpenPGP check failure confirmation doesn't look
very appealing to me, the error message will just fly by and may get
unnoticed while GPGME is really expected to support OpenPGP.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: mutt-1.5.24_DJGPP-2.05

[Eike Rathke]

Hi peters.al,

On Sunday, 2016-02-28 10:43:49 +0100, peters.al wrote:

> working in DJGPP ?

Are you sure you want that?

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: 1.6.0 proposed schedule

[Eike Rathke]

Hi,

On Saturday, 2016-03-05 14:31:16 -0800, Kevin J. McCarthy wrote:

> If you haven't tried out hg tip in a while, now would be a good time to
> start testing it.

Fwiw, I'm using tip since a few months on my private machine and since
a few weeks also in daily work, one Maildir and ~3-5 IMAP servers, with
header cache, with gpg, without builtin smtp, and didn't encounter
a single problem. Just normal use though, nothing specifically fancy.
I didn't even encounter any of the problems for which fixes were
committed in the mean time so this message might be nil ;)

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: [PATCH 0 of 8] Change Mutt to use window structures for screen drawing

[Eike Rathke]

Hi Kevin,

On Tuesday, 2016-04-19 15:52:21 -0700, Kevin J. McCarthy wrote:

> On Tue, Apr 19, 2016 at 09:22:34PM +0100, Richard Russon wrote:
> > Can you put the changes into a public repo that people can fork?
> 
> Perhaps you could elaborate about what you're thinking about?

I think what Richard meant was, to do the changes in a branch of the
public mutt repository instead of your local patch queue so that anyone
can follow/participate/contribute.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: [PATCH] change M_* symbols to MUTT_*

[Eike Rathke]

Hi,

On Monday, 2016-05-09 10:13:53 -0700, Kevin J. McCarthy wrote:

> Unless there are any objections, I will push this along with the backout
> of 23334e967dd7 "Create a wrapper sys_socket.h to work around Solaris
> namespace issues." later today.

Fwiw, I'm writing this with tip including the patches applied, seems to work ;-)

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: [PATCH] Preserve pager position only for ops that redirect back to the same message.

[Eike Rathke]

Hi Kevin,

On Saturday, 2016-08-06 18:03:53 -0700, Kevin J. McCarthy wrote:

> Attached is the revised patch.  This version doesn't restrict the
> operations where the pager position is saved.  Instead, it just makes
> sure the position is cleared when we return to the index menu.

But this means that returning to the index and then viewing the same
message again will display it from top instead of the last position,
doesn't it? I actually find it a useful feature that the pager resumes
the same position I left the message in.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Preserve pager position only for ops that redirect back to the same message.

[Eike Rathke]

Hi Kevin,

On Saturday, 2016-08-13 07:32:57 -0700, Kevin J. McCarthy wrote:

> I can confirm the behavior, but I can not confirm any regression.
> Again, I am seeing the same behavior in 1.6.0, 1.5.24, and 1.5.23:
> toggling the headers does *not* go back to the top of the message.

Same here, tried with 1.5.23, does not go to top.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: index format locale bug

[Eike Rathke]

Hi Kevin,

On Monday, 2016-08-22 20:17:14 -0700, Kevin J. McCarthy wrote:

> Please everyone, don't be shy to let me know if you think this is a
> stupid change.

Well, I think removing the $locale variable was a stupid change ;-)
Whether to add $attribution_locale I don't really care, fine for me as
long as $locale is an alias for $attribution_locale. Also the change to
not switch back and forth the locale for LC_TIME is good. But making
$locale a) not work, and b) complain everytime a hook uses it is ugly
and unnecessary.

Since $locale always only worked in LC_TIME context and defaulted to 'C'
regardless of the users' environment, users who cared set it to their
locale, along with $date_format. Still accepting $locale would not
change anything for them. Users who not used $locale will experience
a change only if their environment is not 'C' or 'en_US' and
$date_format does not start with "!".

But forcing the pile of existing muttrc
reply-hook "~f '...'" 'set locale="..."; set attribution="..."'
to change is awkward, especially if the same configuration is used on
several machines of which some run mutt tip and some don't.

Please reconsider.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: index format locale bug

[Eike Rathke]

Hi,

On Tuesday, 2016-08-23 11:04:57 +0200, Eike Rathke wrote:

> Users who not used $locale will experience
> a change only if their environment is not 'C' or 'en_US' and
> $date_format does not start with "!".

Btw, apart from that, having a default
date_format="!%a, %b %d, %Y at %I:%M:%S%p %Z"
that embeds as many en-US specifics as possible was always stupid ;-)
Probably one of the first changes I did to the default configuration was
set date_format="%A, %Y-%m-%d %H:%M:%S %Z"
which, except the %A, can be used internationally.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: index format locale bug

[Eike Rathke]

Hi,

On Wednesday, 2016-08-24 08:51:01 -0700, Kevin J. McCarthy wrote:

> We've merely reduced the effect of the (proposed alias) $locale.  Other
> places it used to affect, such as the index dates, will now be
> controlled by the user's locale environment variables.  I suspect that
> most users who have customized $locale for the index dates won't notice
> any change.

That's why I was arguing to keep $locale, with the only place it having
a real effect is on attribution now it doesn't harm but keeps
compatibility with the most useful use of $locale in reply-hooks.
Actually I never thought of using it for index dates, but then I'm
running in en_US locale anyway and use the longer $date_format only with
%d in attribution, in $index_format I use %{!%b %d}

> I like the idea of just getting it done and over with, but sympathize
> with Eike, who has multiple environments.  Will deprecating and removing
> a $locale alias over one major release really make the problem worse?

For me the problem is solved with applying one mq patch to tip:

diff --git a/doc/manual.xml.head b/doc/manual.xml.head
--- a/doc/manual.xml.head
+++ b/doc/manual.xml.head
@@ -3624,7 +3624,7 @@
 
 Another typical use for this command is to change the values of the
 $attribution, $attribution_locale, and $locale, and $signature variables in order to change the
 language of the attributions and signatures based upon the recipients.
 
diff --git a/init.h b/init.h
--- a/init.h
+++ b/init.h
@@ -266,7 +266,7 @@
   ** in a reply.  For a full listing of defined \fCprintf(3)\fP-like sequences 
see
   ** the section on $$index_format.
   */
-  { "attribution_locale", DT_STR, R_NONE, UL &AttributionLocale, UL "" },
+  { "locale", DT_STR, R_NONE, UL &AttributionLocale, UL "" },
   /*
   ** .pp
   ** The locale used by \fCstrftime(3)\fP to format dates in the


However, the effort multiplies in case someone uses mutt-dev on several
machines, and the problem gets worse once the next version gets out and
is regulary updated with a package on a machine that does not use
mutt-dev but not others.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: index format locale bug

[Eike Rathke]

Hi,

On Tuesday, 2016-08-23 12:18:42 -0500, Derek Martin wrote:

> On Tue, Aug 23, 2016 at 11:04:57AM +0200, Eike Rathke wrote:
> > Well, I think removing the $locale variable was a stupid change ;-)
> > Whether to add $attribution_locale I don't really care, fine for me
> > as long as $locale is an alias for $attribution_locale. 
> 
> Aliases are bad.  They make the code needlessly more complex, and can
> lead to confusion when things don't quite work as expected.

Alias for the configuration I meant. If both are used the last one wins.
Simple.

> As I said
> originally, if we're keeping both, adding the new variable is worse
> than just leaving locale but fixing the bug.

Ok, stick with $locale then, even better.

> > Also the change to not switch back and forth the locale for LC_TIME
> > is good.  But making $locale a) not work, and b) complain everytime
> > a hook uses it is ugly and unnecessary.
> 
> With the new behavior, it's clear that the ONLY reason to set this is
> if you want to change the dates in your attributions.

But that's exactly how I use it and it is broken now, I can't use the
same configuration with different mutt versions.

> In every other
> case, you should (and now must) configure your operating system
> properly to get what you want.  This is The Right Thing™.  My only
> nitpick is the new variable name is too long. ;-)
> 
> The new setting is clearly unnecessary, except for the send-hook case.
> If you're already using it there,

Actually I use it with reply-hook to change attribution.

> it's a simple matter to:
> 
>   sed 's/locale/attribution_locale/g'

It is not. See above, different mutt versions.

> Or something similar.  This should take you all of about 10s to fix,
> permanently, so this argument is pretty bogus.

The solution is bogus and doesn't fit the problem.

> > Since $locale always only worked in LC_TIME context and defaulted to 'C'
> > regardless of the users' environment, users who cared set it to their
> > locale, 
> 
> But this is senseless.  Just set your locale properly at the OS level
> and the setting is superfluous.

Don't tell me, I didn't. I just wanted to point out that those users
likely will not notice a difference with the code change when keeping
the $locale variable.

> The average user should never even
> need to know this setting exists.  Most users will be able to (and
> should) remove it from their config entirely.
> 
> > But forcing the pile of existing muttrc reply-hook "~f '...'" 'set
> > locale="..."; set attribution="..."' to change is awkward,
> > especially if the same configuration is used on several machines of
> > which some run mutt tip and some don't.
> 
> This, by itself, is never a good reason to avoid making an otherwise
> justifiable change.  Old stuff breaks when you cross major milestones.

I'm using mutt since ~20 years. Config things broke rarely. Only
alternates and some. Renaming a configuration variable is not
a justified change in this case because keeping the name won't break
anything. The name may not exactly match the purpose the variable is
used for now, but it's used in almost the same context (modulo changes
to index dates that likey won't get much noticed).

> That's a fact of continued development.  If you don't want old stuff
> to break, don't run new code.

Haha. Very funny.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

[SPAM?] Re: index format locale bug

[Eike Rathke]

Hi Derek,

On Friday, 2016-08-26 17:46:09 -0500, Derek Martin wrote:

> On Fri, Aug 26, 2016 at 01:50:40AM +0200, Eike Rathke wrote:
> > Alias for the configuration I meant. If both are used the last one wins.
> > Simple.
> 
> Yes, I know what you meant.  Do you run Mutt because it is easy to
> configure (HA!) or because it is good software?

Both :-)  Yes, actually I find it easy to configure, once you got how
things work.

> Aliases should be avoided, unless there is a very, very compelling reason
> to create one.  And this isn't that.

Ok, your opinion, but I'm not buying that. IMHO there's no compelling
reason to not keep an alias for two releases and after that remove it.

> > I can't use the same configuration with different mutt versions.
> 
> I understand, but your objection is not reasonable.  Taken to
> extremes, this logic means that no change can ever modify config
> behavior, no matter how broken it may be.  Development must not be
> stunted by such an attitude.  Besides, it reaks of the mentality,
> "I want all the new functionality of new Mutt, but none of the
> responsibility of configuring it."  At the very least, I think it
> should strike you that that thought process is selfish.

*I* can deal with such configuration problems in one or the other way.
Calling me selfish because I'm thinking of other people who may run into
the same problem is a tad off the lane..

>   set my_muttvers=`mutt -version |head -n 1 |sed 's/^Mutt 
> 1.\([0-9]\+\).*$/1.\1/'`
>   source .muttrc-$my_muttvers

Neat idea.

> > I'm using mutt since ~20 years.  Config things broke rarely. 
> 
> Small wonder... between 2002 and 2015, Mutt only had TWO minor
> releases.  JUST THIS YEAR, we've had two.  And in those two, here is
> only just one more "breakage" of config, and so... still, only rarely.
> 
> Development has picked up again.  Things are changing.  Get used to
> it. =8^)

I'm glad development has picked up again.

> > > That's a fact of continued development.  If you don't want old stuff
> > > to break, don't run new code.
> > 
> > Haha. Very funny.
> 
> Hey... It's not a joke.  With any software, some old features get
> retired, some are improved, and configurations change accordingly.
> New features means new config.  Fixing old brokenness sometimes means
> old config breaks, and old features don't work.  Welcome to software.
> Technology changes quickly and you should be prepared to change with
> it.  Mutt has been fairly stagnant; I think you should see the recent
> increase in the rate of change as a good thing.

I do. Though I don't like the attitude that new stuff has to come along
with breaking old configuration, or an old configuration breaking the
behavior. If we did the same in LibreOffice with each release we'd get
angry bug reports all the way (we do anyway but..). Yes we sometimes let
break things intentionally as well, but only if keeping compatibility is
way out of maintainability.

Mutt certainly has the advantage of its users being more technically
savvy, so they usually can come up with some solution for their problem.
Like your mutt-version dependent config above.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

[PATCH] mx_check_mailbox: prevent dereferencing a null pointer

[Eike Rathke]

This happened when in an IMAP index view the underlying connection was
terminated, ctx->mx_ops was NULL and thus accessing ctx->mx_ops->check
segfaulted.


# HG changeset patch
# User Eike Rathke 
# Date 1474491061 -7200
#  Wed Sep 21 22:51:01 2016 +0200
# Node ID 0ac8ddd821764e6cbdebaea0f58bef3d9434040f
# Parent  c41562a8118b8db61d4828287c4158f43c652d2b
mx_check_mailbox: prevent dereferencing a null pointer

This happened when in an IMAP index view the underlying connection was
terminated, ctx->mx_ops was NULL and thus accessing ctx->mx_ops->check
segfaulted.

diff --git a/mx.c b/mx.c
--- a/mx.c
+++ b/mx.c
@@ -1299,6 +1299,12 @@
 return -1;
   }
 
+  if (!ctx->mx_ops)
+  {
+dprint (1, (debugfile, "mx_check_mailbox: null or invalid context mx_ops.\n"));
+return -1;
+  }
+
   return ctx->mx_ops->check (ctx, index_hint);
 }
 


signature.asc
Description: PGP signature

snprintf() results may get truncated

[Eike Rathke]

Hi,

This is nothing overly critical (not even in mutt_rmtree() if
a truncated string also represents an existing directory entry, as there
was a checked opendir(path) and all entries are to be removed, but
truncated will not be removed as intended, so..), just a heads-up that
some long paths may get truncated when concatenating into a buffer.
Places that do such concatenation using snprintf() should check the
return value and if greater or equal than size(...) it means the result
is truncated. Maybe path related destination buffers also shouldn't be
of _POSIX_PATH_MAX but PATH_MAX size instead.

Places where gcc 7.1.1 spew out warnings (there are more, but not
directly deducible from local buffer sizes):

browser.c: In function ‘examine_mailboxes’:
browser.c:524:34: warning: ‘/new’ directive output may be truncated writing 4 
bytes into a region of size between 1 and 256 [-Wformat-truncation=]
   snprintf (md, sizeof (md), "%s/new", tmp->path);
  ^~~~
browser.c:524:7: note: ‘snprintf’ output between 5 and 260 bytes into a 
destination of size 256
   snprintf (md, sizeof (md), "%s/new", tmp->path);
   ^~~
browser.c:527:34: warning: ‘/cur’ directive output may be truncated writing 4 
bytes into a region of size between 1 and 256 [-Wformat-truncation=]
   snprintf (md, sizeof (md), "%s/cur", tmp->path);
  ^~~~
browser.c:527:7: note: ‘snprintf’ output between 5 and 260 bytes into a 
destination of size 256
   snprintf (md, sizeof (md), "%s/cur", tmp->path);
   ^~~


buffy.c: In function ‘buffy_maildir_check_dir’:
buffy.c:324:34: warning: ‘snprintf’ output may be truncated before the last 
format character [-Wformat-truncation=]
   snprintf (path, sizeof (path), "%s/%s", mailbox->path, dir_name);
  ^~~
buffy.c:324:3: note: ‘snprintf’ output 2 or more bytes (assuming 257) into a 
destination of size 256
   snprintf (path, sizeof (path), "%s/%s", mailbox->path, dir_name);
   ^~~~
buffy.c:370:46: warning: ‘snprintf’ output may be truncated before the last 
format character [-Wformat-truncation=]
   snprintf(msgpath, sizeof(msgpath), "%s/%s", path, de->d_name);
  ^~~
buffy.c:370:11: note: ‘snprintf’ output 2 or more bytes (assuming 257) into a 
destination of size 256
   snprintf(msgpath, sizeof(msgpath), "%s/%s", path, de->d_name);
   ^


help.c: In function ‘pad’:
help.c:192:37: warning: ‘%d’ directive output may be truncated writing between 
1 and 11 bytes into a region of size 6 [-Wformat-truncation=]
 snprintf (fmt, sizeof(fmt), "%%-%ds", i - col);
 ^~
help.c:192:33: note: directive argument in the range [-1073741805, 2147483647]
 snprintf (fmt, sizeof(fmt), "%%-%ds", i - col);
 ^~~~
help.c:192:5: note: ‘snprintf’ output between 5 and 15 bytes into a destination 
of size 8
 snprintf (fmt, sizeof(fmt), "%%-%ds", i - col);
 ^~


mh.c: In function ‘_maildir_open_find_message’:
mh.c:2388:47: warning: ‘%s’ directive output may be truncated writing up to 255 
bytes into a region of size 254 [-Wformat-truncation=]
   snprintf (fname, sizeof (fname), "%s/%s/%s", folder, subfolder,
   ^~
mh.c:2388:7: note: ‘snprintf’ output 3 or more bytes (assuming 258) into a 
destination of size 256
   snprintf (fname, sizeof (fname), "%s/%s/%s", folder, subfolder,
   ^~~
   de->d_name);
   ~~~
mh.c: In function ‘maildir_parse_dir’:
mh.c:852:36: warning: ‘snprintf’ output may be truncated before the last format 
character [-Wformat-truncation=]
   snprintf (tmp, sizeof (tmp), "%s/%s", subdir, de->d_name);
^~~
mh.c:852:7: note: ‘snprintf’ output 2 or more bytes (assuming 257) into a 
destination of size 256
   snprintf (tmp, sizeof (tmp), "%s/%s", subdir, de->d_name);
   ^


lib.c: In function ‘mutt_rmtree’:
lib.c:600:34: warning: ‘snprintf’ output may be truncated before the last 
format character [-Wformat-truncation=]
 snprintf (cur, sizeof (cur), "%s/%s", path, de->d_name);
  ^~~
lib.c:600:5: note: ‘snprintf’ output 2 or more bytes (assuming 257) into a 
destination of size 256
 snprintf (cur, sizeof (cur), "%s/%s", path, de->d_name);
 ^~~


bcache.c: In function ‘mutt_bcache_put’:
bcache.c:139:39: warning: ‘%s’ directive output may be truncated writing up to 
4 bytes i

Re: snprintf() results may get truncated

[Eike Rathke]

Hi,

On Friday, 2017-09-15 13:02:25 -0500, Derek Martin wrote:

> On Fri, Sep 15, 2017 at 09:43:58AM -0700, Kevin J. McCarthy wrote:
> > On Fri, Sep 15, 2017 at 12:58:18AM +0200, Eike Rathke wrote:
> > > Maybe path related destination buffers also shouldn't be
> > > of _POSIX_PATH_MAX but PATH_MAX size instead.
> > 
> > It looks like Mutt uses _POSIX_PATH_MAX in the majority of cases with
> > just a sprinkle of PATH_MAX uses.  Is PATH_MAX generally larger?

*If* defined then PATH_MAX is *usually* larger than _POSIX_PATH_MAX
(which usually is defined to 256 including null char).
Though it still (for some file systems) does not represent the maximum
length a path specifier may actually have.
However, _POSIX_PATH_MAX is the maximum length a file name or directory
name is assumed to have, not the entire path.

> PATH_MAX is highly system dependent, and in many cases, also
> completely bogus.  Relying on it is often folly, but it's also often
> all you really can do.

True. Or just use an own destination buffer size of 64kB for (recursive)
concatenation ... a later stat() or open() would fail if too long.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: snprintf() results may get truncated

[Eike Rathke]

Hi Vincent,

On Monday, 2017-09-18 13:13:07 +0200, Vincent Lefevre wrote:

> > [... _POSIX_PATH_MAX ...]
> > (which usually is defined to 256 including null char).
> 
> And it must be 256 in the current POSIX version:
> 
>   {_POSIX_PATH_MAX}
> Minimum number the implementation will accept as the maximum
> number of bytes in a pathname.
> Value: 256

256 is the *minimum* value ist must have, it's listed under "Minimum
Values" that says "For each of these limits, a conforming implementation
shall provide a value at least this large or shall have no limit."

> > However, _POSIX_PATH_MAX is the maximum length a file name or directory
> > name is assumed to have, not the entire path.
> 
> This is not what the POSIX spec says (see above).

Hmm.. seems I mixed that up (or it is an implementation detail that
happens to be congruent).

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

PATH_MAX and POSIX (was: snprintf() results may get truncated)

[Eike Rathke]

Hi Vincent,

On Tuesday, 2017-09-19 12:18:34 +0200, Vincent Lefevre wrote:

> Now, I don't see much point in defining both _POSIX_PATH_MAX and
> PATH_MAX for similar meanings. POSIX is strange, sometimes. :)

Might be ;-) but in this case the important difference is

_POSIX_PATH_MAX
Minimum number the implementation will accept as the maximum number of
bytes in a pathname.

PATH_MAX
Maximum number of bytes the implementation will store as a pathname in
a user-supplied buffer of unspecified size, including the terminating
null character.

So an implementation must accept at least and may accept more than
_POSIX_PATH_MAX bytes in a path name, but it must not store more than
PATH_MAX bytes in a user-supplied buffer.

That POSIX for PATH_MAX *also* says "Minimum number the implementation
will accept as the maximum number of bytes in a pathname." may be
confusing on first sight, but note that PATH_MAX is listed under
"Pathname Variable Values", where "variable" is to be taken seriously.
Those values can be queried using pathconf() and fpathconf() and may
depend on the underlying file system. For example,

pathconf("/foo/bar", _PC_PATH_MAX)

queries the value for PATH_MAX in the context of /foo/bar

If a POSIX compliant implementation does not define a constant for one
of these variable values it means you *have* to query the correct value
from pathconf().

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: [PATCH] fix recipients when group replying with reply_self enabled

[Eike Rathke]

Hi,

On Friday, 2017-09-22 13:16:38 -0700, Kevin J. McCarthy wrote:

> So the question is if (g)roup reply with 'set reply_self; unset metoo'
> should disable the $nometoo behavior.  I think so, but please chime in!

Might make sense. But I'd not expect it. I'd rather not expect
$reply_self to affect group reply at all, only normal reply. So whether
myself is in the list of recipients in a group reply should depend only
on $metoo.

But maybe that's me, I find the behaviour of an unset $reply_self
logical and setting $reply_self rather odd..

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: mutt: Add $change_folder_next option to control mailbox suggesti...

[Eike Rathke]

Hi Brendan, Kevin, Simon,

On Saturday, 2017-11-11 15:50:11 -0800, Brendan Cully wrote:

> This patch brings back the original behaviour of change-folder, which
> some people find more useful.

Just want to say thank you, I really like this behaviour.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Switch to git and gitlab in progress

[Eike Rathke]

Hi Kevin,

On Sunday, 2017-12-10 19:37:38 -0800, Kevin J. McCarthy wrote:

> Sorry things have been so quiet.  I've been pretty busy on other stuff,
> but what time I have had available has been working on migrating Mutt to
> git.

Nice move, starred :-)

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: mutt deletes space characters in recipients address

[Eike Rathke]

Hi Lutz,

On Tuesday, 2017-12-19 13:44:09 +0100, Lutz Jankowski wrote:

> When entering a recipients address that contains a space character, mutt
> just deletes it. The behaviour is the same whether you sent the email in a
> single command from the terminal or use mutt's interface.
> 
> "jankowski+spa ce"@pre-sense.de
> is changed to
> jankowski+sp...@pre-sense.de
> Trying to escape the space with a backslash, just leaves the backslash
> there.

Like this? "jankowski+spa\ ce"@pre-sense.de

> Is this a bug or a feature?

White-space is not allowed in the local-part according to
https://tools.ietf.org/html/rfc5322#section-3.2.4 Quoted Strings
https://tools.ietf.org/html/rfc5322#section-4.1 Miscellaneous Obsolete Tokens
that in qtext or obs-qtext does not include %d32

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: mutt deletes space characters in recipients address

[Eike Rathke]

Hi,

On Tuesday, 2017-12-19 14:29:35 +0100, Eike Rathke wrote:

> White-space is not allowed in the local-part according to
> https://tools.ietf.org/html/rfc5322#section-3.2.4 Quoted Strings
> https://tools.ietf.org/html/rfc5322#section-4.1 Miscellaneous Obsolete Tokens
> that in qtext or obs-qtext does not include %d32

And I obviously overlooked

https://tools.ietf.org/html/rfc5322#section-3.2.1 Quoted characters

quoted-pair =   ("\" (VCHAR / WSP)) / obs-qp

That's insane.. and someone willingly using such address is asking for
trouble or a nitpicker and/or doesn't want to receive mails..

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Mailing list status

[Eike Rathke]

Hi Kevin,

On Monday, 2018-03-12 12:32:31 -0700, Kevin J. McCarthy wrote:

> The new mailing list server uses GNU mailman.  There are likely a few
> things that need to be tweeked.  Please let me know about any issues.

On the good side: there's now a
List-Id: 
header one can use to filter incoming mail, additionally to
List-Post: 

For who needs it, the old
Sender: owner-mutt-...@mutt.org
is now replaced by
Sender: Mutt-dev 


> Please let me offer a huge thank you to GBNet for donating their time
> and servers to Mutt for many, many years, and also express my
> appreciation to OSUOSL for working with me to transition to their
> hosting services.

Let me chime in, and thank you for taking care of this and all around Mutt.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

version number

[Eike Rathke]

Hi,

Building mutt from master, mutt -h (or -v) display the version as
currently

Mutt 1.9.4+96 (f6232a25) (2018-03-03)

That's somewhat unexpected and apparently in version.sh the distance
from latesttag isn't quite what was thought it would be..

Nothing important, just to mention.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Mailing list status

[Eike Rathke]

Hi Kevin,

On Sunday, 2018-03-18 12:22:11 -0700, Kevin J. McCarthy wrote:

> On Sun, Mar 18, 2018 at 07:44:57PM +0100, Moritz Barsnick wrote:
> > My bad. Because Stuart put me on Cc:, I only got the direct mail, and
> > not through the list. (I just reconfigured that @mailman... Stupid
> > preference. Was it that way before?)
> 
> I can change this to be off; but would appreciate if others would chime
> in before I do so.

I just changed it to receive copies..

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: why casting pointer in mutt_mem_free

[Eike Rathke]

Hi,

On Tuesday, 2018-03-27 12:30:13 -0500, Derek Martin wrote:

> > void mutt_mem_free(void *ptr)
> > {
> >   void **p = (void **) ptr;
> >   if (*p)
> >   {
> > free(*p);
> > *p = 0;
> 
> ...
> char *x = (char *)malloc(buffsz);
> /* do some stuff with x *
> ...
> mutt_mem_free(x);
> 
> /* later... */
> if (x) do_some_stuff();
> 
> This would likely crash, or at worst behave unexpectedly, because x
> was not set to NULL when mutt_mem_free() was called on it.

It would ill-behave even earlier because mutt_mem_free() would
effectively call free(*x) thus attempting to free a memory block that
the content of the memory at x points to. Hopefully memory management
would terminate the process at that point.. but with chance it could be
interpreted as a valid memory block pointer and whatever may happen..

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Efail and Mutt

[Eike Rathke]

Hi,

On Monday, 2018-05-14 15:33:33 +0200, Vincent Lefevre wrote:

> And piping a decrypted mail to a browser (e.g. if there is no
> text/plain part, and an attacker can ensure that) is not safe.

There's nothing wrong with a ~/.mailcap entry similar to this:

text/html; /usr/bin/elinks -localhost 1 -no-connect 1 -force-html -dump '%s'; 
copiousoutput


  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: PGP decryption no longer works

[Eike Rathke]

Hi Vincent,

On Monday, 2018-06-25 16:39:19 -0400, Vincent Lefevre wrote:

> It seems that a recent change has broken PGP decryption:
> I now get a failure from gnupg. No issues with Mutt from
> Debian/unstable.

No problem here, using most recent master with gpgme on Debian stretch.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: PGP decryption no longer works

[Eike Rathke]

Hi Vincent,

On Tuesday, 2018-06-26 08:59:06 -0400, Vincent Lefevre wrote:

> On 2018-06-26 10:14:09 +0200, Eike Rathke wrote:
> > On Monday, 2018-06-25 16:39:19 -0400, Vincent Lefevre wrote:
> > 
> > > It seems that a recent change has broken PGP decryption:
> > > I now get a failure from gnupg. No issues with Mutt from
> > > Debian/unstable.
> > 
> > No problem here, using most recent master with gpgme on Debian stretch.
> 
> I'm not using gpgme, but it appears that Debian's default config
> uses it, so that may be the difference. In short, when gpgme is
> not used, PGP decryption got recently broken.

Still not here.. ;-)
I forced set crypt_use_gpgme=no in my muttrc and decrypt works, verified
that crypt-gpgme.c decrypt_part() is not called.

The gpg.rc pgp_decrypt_command I use is almost the same as distributed
with stretch, just the gpg command renamed to ggp2 (which I needed for
another machine) which nowadays is a symbolic link to /usr/bin/gpg
anyway.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Alignment attribute

[Eike Rathke]

Hi,

On Sunday, 2019-04-14 15:18:40 -0700, Kevin J. McCarthy wrote:

> On Sun, Apr 14, 2019 at 11:14:05PM +0200, Gero Treuner wrote:
> > Just drop that alignment?
> 
> No, let's leave it.

Interested I took a glance and yes it should be kept.

> > Considering that Mutt doesn't control alignment on other data structures
> > and there seem to be no issues: Probably it is valid to assume that
> > compilers as GCC automatically choose a suitable alignment.
> 
> Mutt isn't doing tricky things like this in other places, so there is
> probably a very good reason for the declaration.

The reason is that some processor architectures can't access words like
int or long on odd addresses and doing so would result in a violation.

Now there char buf[] is declared on the stack and without enforced
alignment would be allocated with a char alignment wherever the current
stack pointer happens to point at. Later char *ptr = buf is taken and
then casted

  const struct inotify_event *event = (const struct inotify_event *) ptr;

to further use it to access event->wd and event->mask. If these are not
properly aligned the program will crash.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Building master on Fedora fails

[Eike Rathke]

Hi,

I tried to build current master on Fedora F29 and that failed at two points:

One is the call

/usr/bin/docbook2texi --encoding=utf-8 \
--string-param output-file=mutt \
--string-param 'directory-category=Email-software' \
--string-param 'directory-description=Text based mail reader' \
manual.xml

for which /usr/bin/docbook2texi is a Jade Wrapper with

jw -f docbook -b texi "$@"

and that doesn't know the --string-param option.

I worked around the failure with a temporary

diff --git a/configure.ac b/configure.ac
index 102ddea2..8eb22d1e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1572,6 +1572,7 @@ if test "$DB2XTEXI" != "none"; then
   do_build_info=yes
fi
 fi
+do_build_info=no
 AM_CONDITIONAL(BUILD_INFO, test x$do_build_info = xyes)
 AC_SUBST(DB2XTEXI)
 AC_SUBST(MAKEINFO)


which of course is not a real solution, but I don't know any better now.


Second is a linkage failure of the mutt executable

/usr/bin/ld: crypt-gpgme.o: undefined reference to symbol 
'gpgrt_cmp_version@@GPG_ERROR_1.0'
/usr/bin/ld: //usr/lib64/libgpg-error.so.0: error adding symbols: DSO missing 
from command line

The problem is that a /usr/bin/gpgme-config --libs  only returns

-L/usr/lib64 -lgpgme

and excludes -lgpg-error because libgpg-error is a separate package and
has a separate /usr/bin/gpg-error-config

That can be remedied with

diff --git a/m4/gpgme.m4 b/m4/gpgme.m4
index 44bf43cb..2d0bfcc4 100644
--- a/m4/gpgme.m4
+++ b/m4/gpgme.m4
@@ -17,8 +17,10 @@ AC_DEFUN([_AM_PATH_GPGME_CONFIG],
  gpgme_config_prefix="$withval", gpgme_config_prefix="")
   if test "x$gpgme_config_prefix" != x ; then
   GPGME_CONFIG="$gpgme_config_prefix/bin/gpgme-config"
+  GPG_ERROR_CONFIG="$gpgme_config_prefix/bin/gpg-error-config"
   fi
   AC_PATH_PROG(GPGME_CONFIG, gpgme-config, no)
+  AC_PATH_PROG(GPG_ERROR_CONFIG, gpg-error-config, no)
 
   if test "$GPGME_CONFIG" != "no" ; then
 gpgme_version=`$GPGME_CONFIG --version`
@@ -86,6 +88,9 @@ AC_DEFUN([AM_PATH_GPGME],
   if test $ok = yes; then
 GPGME_CFLAGS=`$GPGME_CONFIG --cflags`
 GPGME_LIBS=`$GPGME_CONFIG --libs`
+if test "$GPG_ERROR_CONFIG" != "no" ; then
+  GPGME_LIBS="$GPGME_LIBS `$GPG_ERROR_CONFIG --libs`"
+fi
 AC_MSG_RESULT(yes)
 ifelse([$2], , :, [$2])
   else


Interestingly on Debian there are also the two packages but
/usr/bin/gpgme-config --libs includes -lgpg-error so it doesn't fail,
but there's also /usr/bin/gpg-error-config and listing -lgpg-error twice
if so doesn't harm.

I think the above patch should do for all platforms but I only build on
those two. Anyhow, I created a merge request of it at
https://gitlab.com/muttmua/mutt/merge_requests/46

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Building master on Fedora fails

[Eike Rathke]

Hi Kevin,

On Sunday, 2019-05-19 14:28:09 -0700, Kevin J. McCarthy wrote:
> On Sun, May 19, 2019 at 11:03:17PM +0200, Moritz Barsnick wrote:
> > Fedora packages the docbook2X version of docbook2texi as
> > db2x_docbook2texi (in package docbook2X). The binary it provides as
> > docbook2texi comes from RedHat's own docbook-tools:
> > http://sources.redhat.com/docbook-tools/
> > which are packaged as docbook-utils, sic.
> 
> That's helpful.  Perhaps I can look for db2x_docbook2texi first, then.
> However, if they don't have the docbook2texi package installed but have
> docbook-tools installed it will fail on invocation.
> 
> It looks like RedHat's docbook-tools is even older than docbook2x.  I'm not
> sure if docbook-tools is commonly installed.  Do either of you think
> this approach is feasible?

I haven't willingly installed docbook-utils, querying for dependencies
it's docbook-utils-pdf and gtk-doc that require it, of which only
gtk-doc can be responsible here. Which again might not be that rarely
installed..

For completeness, having tried your kevin/gpgme-build-fix with docbook2X
installed worked.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Building master on Fedora fails

[Eike Rathke]

Hi,

On Tuesday, 2019-05-21 10:34:01 +0200, Vincent Lefevre wrote:

> On 2019-05-20 12:50:41 -0700, Kevin J. McCarthy wrote:
> > On Mon, May 20, 2019 at 04:51:34PM +0200, Vincent Lefevre wrote:
> > > So, before looking at docbook2texi, it is necessary to look at
> > > docbook2x-texi.
> > 
> > Thanks Vincent, I wasn't aware the issue was also present on Debian. I've
> > just pushed a commit up to master hopefully addressing the issues.
> > 
> > The search order for program names is:
> >  [docbook2x-texi db2x_docbook2texi docbook2texi]
> 
> I can see that docbook2x-texi was already present, explaining
> why I didn't have any problem under Debian. Actually that was
> the original one, until you did a change in commit
> 128baa52e5ad912e3127926937934e1cb8d31c5f on 2019-02-23.

And I have none of them installed on my Debian machine, that explains as
well..

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Feedback on ticket 146 - $reverse_realname behavior

[Eike Rathke]

Hi Kevin,

On Saturday, 2019-06-08 14:20:49 -0700, Kevin J. McCarthy wrote:

> Right now, if a To address is missing the personal (name) part, the From
> will be filled in with $realname in the reply.
> 
> The ticket submitter expects that if the To address was missing a name, the
> reply From address should be the exact same: missing a name too.
> 
> I think it's a reasonable expectation, but would like to confirm that
> opinion with others before I merge the patch.

Problem is that both can be expected behaviour.
1) the sender didn't know or fill in the real name, but I would like an
   answer to have it; likely in everyday communication
2) the mail was sent to an address that on purpose doesn't have a name
   assigned, like a role account, it may even be it's read and answered
   by different persons

A solution IMHO is a quad-option asking the user whether to complete the
name when answering such mail. Even better might be two alternates
lists, with and without realname fill, but that somewhat sounds like
overkill.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Ticket 151 - strip leading '-' for mailcap sanitize

[Eike Rathke]

Hi Kevin,

On Friday, 2019-06-21 12:09:19 -0700, Kevin J. McCarthy wrote:

> Perhaps the "expected" behavior is putting '--' before the %s, but neither
> the sample mailcap or manual mention that.

Not all programs and tools support the '--' mechanism.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Ticket 151 - strip leading '-' for mailcap sanitize

[Eike Rathke]

Hi Kevin,

On Friday, 2019-06-21 12:20:28 -0700, Kevin J. McCarthy wrote:

> Just to be clear, the ticket is actually advocating for sanitizing the
> leading "-", into "_" as other unsafe characters are.  I further wonder if
> we should just remove "-" from the whitelist rather than adding a special
> case for it.

I would not like to have all '-' replaced by '_' in attachments
(specifically I personally use '-' instead of '_' except when I need
some differentiation). It may also complicate things if for some reason
the file name is mentioned or referenced elsewhere and not identical.

I'd rather much prefer to treat a leading '-' as a special case here.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Ticket 151 - strip leading '-' for mailcap sanitize

[Eike Rathke]

Hi Kevin,

On Friday, 2019-06-21 13:26:22 -0700, Kevin J. McCarthy wrote:

> On Fri, Jun 21, 2019 at 10:03:23PM +0200, Eike Rathke wrote:
> > I would not like to have all '-' replaced by '_' in attachments
> > (specifically I personally use '-' instead of '_' except when I need
> > some differentiation). It may also complicate things if for some reason
> > the file name is mentioned or referenced elsewhere and not identical.
> > 
> > I'd rather much prefer to treat a leading '-' as a special case here.
> 
> This is referring to filename sanitizing for mailcap invocation:
> mutt_sanitize_filename().  The change isn't preserved outside of the
> invocation, and isn't used to otherwise modify the filenames of attachments.
> 
> Does your concern still apply in those circumstances?

Ah ok I thought sanitizing was also used when saving attachments.
As was mentioned elsewhere prefixing './' might be best if it starts
with '-' and a path is not prepended (can that even happen?).

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: meaning of number of lines in the message (%l in index_format)

[Eike Rathke]

Hi,

On Monday, 2019-06-24 18:41:56 -0500, Derek Martin wrote:

> Or just remove it.  If it's not accurate (or even if it is) what value
> can it really provide?

Even if it isn't accurate it gives me a rough idea about the size of the
message (usually after viewed already which calculates the value),
specifically if attachments are involved. It helps when sorting by
message size, which I sometimes used to delete the largest attachments
that aren't of interest (anymore) and only take up disk space.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Autocrypt

[Eike Rathke]

Hi Kevin,

The new Autocrypt feature seems to work :-)
Tried with/without overriding conventional PGP encryption and vice
versa. Great work, thanks!

One caveat: when enabling autocrypt=yes and starting mutt the first time
one must ensure to not have some key push in the config, otherwise that
interferes with the prompt about setting up the autocrypt directory.
BTDT..

Questions remaining: it may be possible to use an already existing RSA
key imported from the GnuPG keyring. At least I've seen such Autocrypt
keys even with two accounts on them. Does Mutt Autocrypt support that?

On the other hand, would it make sense to do so? Or are there advantages
on having separate keys per account? Apart from they can be revoked or
changed individually.

Thanks again!

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt

[Eike Rathke]

Hi Kevin,

On Wednesday, 2019-08-07 17:40:06 -0700, Kevin J. McCarthy wrote:

> > One caveat: when enabling autocrypt=yes and starting mutt the first time
> > one must ensure to not have some key push in the config, otherwise that
> > interferes with the prompt about setting up the autocrypt directory.
> > BTDT..
> 
> Whoops - there's one right there.  I'll fix that in the next couple days.

I confirm it works now.

> > Questions remaining: it may be possible to use an already existing RSA
> > key imported from the GnuPG keyring. At least I've seen such Autocrypt
> > keys even with two accounts on them. Does Mutt Autocrypt support that?
> 
> Yes, today I pushed up the ability to select a key during account creation.
> It's rather fresh but I think works okay.

Tried that and did (s)elect existing GPG key, but got "No secret key
found". Didn't dig deeper.

> I also added $autocrypt_reply to turn off the "forced autocrypt" mode when
> replying.  If the same key is used in both web-of-trust and autocrypt, it
> may be more convenient to choose yourself when replying rather than have
> autocrypt force itself on you each time.

Makes sense. Though with several accounts some (which don't have a WoT
key assigned) may be preferred using autocrypt_reply and others not, so
probably a sender address hook (reply-hook) would be appropriate. Would
that work?

Btw, how about passphrases for autocrypt keys? Recommendation is to not
have such or not ask it for every mail, but I'd not use a regular key
without passphrase for autocrypt. Is the usual PGP passphrase handling
(including timeout) also applied to autocrypt keys? Maybe I'll find some
time over the weekend to play around with things.. until then I ask
stupid questions ;-)

The docs say that "header cached messages are not re-scanned for
Autocrypt headers", however, my gut feeling is that mailboxes not yet
scanned are scanned when opening them the first time after autocrypt was
initialized, even if header caching is on. At least I experienced
a quite slow scanning for larger mailboxes in such first visits. If so,
this can be a problem for large IMAP boxes, but was already slow enough
for large local boxes.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt

[Eike Rathke]

Hi Kevin,

On Thursday, 2019-08-08 15:58:07 -0700, Kevin J. McCarthy wrote:

> On Fri, Aug 09, 2019 at 12:36:37AM +0200, Eike Rathke wrote:
> > > Yes, today I pushed up the ability to select a key during account 
> > > creation.
> > > It's rather fresh but I think works okay.
> > 
> > Tried that and did (s)elect existing GPG key, but got "No secret key
> > found". Didn't dig deeper.
> 
> It's selecting a key from the keyring in $autocrypt_dir.

But that's just after it created the $autocrypt_dir so there's nothing
to select from.. I would had expected it offers to select from the
general gnupg keyring.


> > The docs say that "header cached messages are not re-scanned for
> > Autocrypt headers", however, my gut feeling is that mailboxes not yet
> > scanned are scanned when opening them the first time after autocrypt was
> > initialized, even if header caching is on.
> 
> This is likely because the changes to Mutt data structures (to add the
> autocrypt fields) invalidated the header cache.  I didn't mention it in the
> docs because that would make the issue more confusing.

I'll plan for two mugs of coffee when I throw this against IMAP with
folders of 6-8 messages.. :-P

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt

[Eike Rathke]

Hi Kevin,

On Friday, 2019-08-09 14:31:55 -0700, Kevin J. McCarthy wrote:

> On Fri, Aug 09, 2019 at 11:14:06PM +0200, Eike Rathke wrote:
> > > It's selecting a key from the keyring in $autocrypt_dir.
> > 
> > But that's just after it created the $autocrypt_dir so there's nothing
> > to select from.. I would had expected it offers to select from the
> > general gnupg keyring.
> 
> The "first run" account creation process can take place even if
> $autocrypt_dir already exists.  Account creation also can take place from
> the .  This feature is to allow using the same key
> across multiple accounts, or to use a key that *you* have imported yourself.

Tried that and it works. The minimal public key of multiple UIDs written
as autocrypt keydata in my case is 15kB, quite large as mail overhead.
I guess there's no way to reduce that somehow? Command line gnupg has
filter options like

  gpg --export --export-options export-minimal --export-filter 
keep-uid="mbox=f...@example.com" 0xKEYID

which ends up with 3kB Ascii-armored per uid.


> I've updated the documentation at
> <https://muttmua.gitlab.io/mutt/manual-dev.html#autocryptdoc> to make this
> specific, and added a section "Alternative Key and Keyring Strategies" to
> discuss the ways and caveats of sharing keys or keyrings.

Nice, thanks.


> > > [... header cache invalidation ...]
> > I'll plan for two mugs of coffee when I throw this against IMAP with
> > folders of 6-8 messages.. :-P
> 
> Are you seeing horrific performance specifically because of the autocrypt
> header scanning, or just in general due to having to rebuild the header
> cache?

Just due to rebuilding the header cache once without explicitly
switching it off for an autocrypt scan.

> While there will be *some* slowdown due to Autocrypt, it shouldn't
> be that noticeable.

I didn't notice a negative impact on regular mail use.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt

[Eike Rathke]

Hi Kevin,

On Sunday, 2019-08-11 13:44:53 -0700, Kevin J. McCarthy wrote:

> On Sun, Aug 11, 2019 at 10:24:42PM +0200, Eike Rathke wrote:
> > The minimal public key of multiple UIDs written as autocrypt keydata in
> > my case is 15kB, quite large as mail overhead.  I guess there's no way
> > to reduce that somehow?
> 
> Ouch, that's pretty excessive.  When generating the Base64 keydata for the
> header, Mutt uses gpgme_op_export_keys() with the GPGME_EXPORT_MODE_MINIMAL
> flag.  I don't think there's much more Mutt can do as the keydata is
> supposed to have the uid field.
> 
> > Command line gnupg has filter options like
> > 
> >  gpg --export --export-options export-minimal --export-filter 
> > keep-uid="mbox=f...@example.com" 0xKEYID
> > 
> > which ends up with 3kB Ascii-armored per uid.
> 
> It might be worth doing this when copying over and trimming down the uid
> list as much as possible.

Tried (then it needs to be done with --export-secret-keys not --export,
of course..) with 6 of 12 uids but that didn't change anything. I think
the size is merely due to the rsa4096 used on that key.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt

[Eike Rathke]

Hi Kevin,

On Monday, 2019-08-12 09:07:49 -0700, Kevin J. McCarthy wrote:

> On Mon, Aug 12, 2019 at 11:57:14AM +0200, Eike Rathke wrote:
> > Tried (then it needs to be done with --export-secret-keys not --export,
> > of course..) with 6 of 12 uids but that didn't change anything. I think
> > the size is merely due to the rsa4096 used on that key.
> 
> How many lines is the Autocrypt header, again?  I've seen other rsa4096 keys
> where the header is around 45 lines.  GPGME_EXPORT_MODE_MINIMAL should be
> removing all extraneous signatures, so there is no reason for it to be much
> bigger than that.

So, this is completely odd and appears to be some bug. I verified that
gpg --homedir ~/.mutt/autocrypt -K  (and -k as well) both list 6 mbox
addresses. The Autocrypt header of a mail written from such address is
203 lines, 15585 bytes with folding, I piped it through

  formail -cxAutocrypt: | sed -e 's/.*keydata=//;s/[ \t]//g' | base64 -d | gpg 
--homedir testdir --import

and then  gpg --homedir testdir -k   lists the 12 (!) addresses of the
original key. It seems that the Autocrypt header content for an existing
key is pulled from the original keyring and not the ~/.mutt/autocrypt
keyring.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: pkg-config usage for sqlite3

[Eike Rathke]

Hi Kevin,

On Monday, 2019-08-12 10:51:56 -0700, Kevin J. McCarthy wrote:

> > why would supplying a non-standard search path to pkg-config files be
> > any more problematic than a non-standard path to the library itself?
> 
> By all means, please enlighten me.  My understanding from starting to
> research the issue is that the user needs to set up nonstandard paths in
> PKG_CONFIG_PATH instead of passing them to the configure --with-sqlite3
> flag.

That is correct.

> However, I'm all ears.  If this is a non-issue please say so.

If a user installed a package in a non-standard location s/he should be
able to specify its pkg-config path in PKG_CONFIG_PATH as well.

> I'd be
> delighted to punt this to PKG_CHECK_MODULES.  In that case, should we just
> ignore anything passed to --with-sqlite3=?

Yes. Or rather, if "no" then do not check for it, and break if
--enable-autocrypt was specified as well.

PKG_CHECK_MODULES generates code to output a message if the .pc file
wasn't found and to adjust PKG_CONFIG_PATH or how things can be
overridden by setting ..._CFLAGS and ..._LIBS variables.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt

[Eike Rathke]

Hi Kevin,

On Monday, 2019-08-12 16:13:16 -0700, Kevin J. McCarthy wrote:

> On Tue, Aug 13, 2019 at 12:56:37AM +0200, Eike Rathke wrote:
> > and then  gpg --homedir testdir -k   lists the 12 (!) addresses of the
> > original key. It seems that the Autocrypt header content for an existing
> > key is pulled from the original keyring and not the ~/.mutt/autocrypt
> > keyring.
> 
> The base64 keydata is stored in the sqlite3 database once the account is
> created.  Updating the key in gpg subsequent to that won't have an effect on
> the keydata.
> 
> Make sure to remove the account (via ) and recreate it
> if you modify or re-import the key.

ARGHL.. that's it!
Then the header is half the size.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt

[Eike Rathke]

Hi Kevin,

On Monday, 2019-08-12 17:38:16 -0700, Kevin J. McCarthy wrote:

> On the plus side, it actually gives you some flexibility if you wanted to
> take advantage of it.  You could create a different base64 export of the
> same keyid, each with a single uid, and store it right in the database with
> some work.  That would massively trim the size of your Autocrypt header down
> while still being able to use the same keyid for each.

Nice aspect, I'll try that (another day).

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt

[Eike Rathke]

Hi,

On Tuesday, 2019-08-13 02:59:28 +0200, Eike Rathke wrote:

> On Monday, 2019-08-12 17:38:16 -0700, Kevin J. McCarthy wrote:
> 
> > On the plus side, it actually gives you some flexibility if you wanted to
> > take advantage of it.  You could create a different base64 export of the
> > same keyid, each with a single uid, and store it right in the database with
> > some work.  That would massively trim the size of your Autocrypt header down
> > while still being able to use the same keyid for each.
> 
> Nice aspect, I'll try that (another day).

That indeed works and cuts keydata to 2940 bytes or such. At the second
try after I realized that the base64 data needs to be unwrapped, so

  gpg  --export --export-options export-minimal --export-filter 
keep-uid="mbox=$x" 0xKEYID | base64 --wrap=0

Thanks
  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Autocrypt and encrypted/signed mail from a key in pubring

[Eike Rathke]

Hi,

For an encrypted and signed mail for which the key is both in the
regular pubring and in the autocrypt pubring (and autocrypt.db), the
signature apparently is verified using the autocrypt keyring, at least
I get

| WARNING: We have NO indication whether the key belongs to the person named as 
shown above

although I do have that key signed in the regular keyring.

The same even for mails I wrote and encrypted and signed it says this
for my own key's signature, but not for mails I only signed and did not
encrypt. This also for older mails before Mutt added the Autocrypt
header, so presence of the header seems not to be related.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt and encrypted/signed mail from a key in pubring

[Eike Rathke]

Hi,

On Tuesday, 2019-08-20 15:42:13 -0700, Kevin J. McCarthy wrote:

> On Sun, Aug 18, 2019 at 03:29:50PM -0700, Kevin J. McCarthy wrote:
> > Another choice would be to point $autocrypt_dir at ~/.gnupg (you can
> > copy the autocrypt.db file over to save yourself having to recreate
> > accounts).  However, this will then cause Autocrypt header keys to be
> > imported into ~/.gnupg.  If that's okay with you, this will give you Web
> > of Trust signature messages instead.
> 
> After thinking it over for a few days, I've updated the manual to recommend
> pointing $autocrypt_dir to ~/.gnupg if you want to use your existing key.  I
> recommend you do so too if you still want to share the same key.

I don't want the automatically scanned autocrypt keys populate my
regular keyring. I think the better solution at least for me is to sync
the autocrypt pubring from the regular pubring.

Thanks for wrapping your head around this topic :-)

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Autocrypt and encrypted/signed mail from a key in pubring

[Eike Rathke]

Hi,

On Thursday, 2019-08-22 22:11:41 +0200, Eike Rathke wrote:

> I don't want the automatically scanned autocrypt keys populate my
> regular keyring. I think the better solution at least for me is to sync
> the autocrypt pubring from the regular pubring.

Just to acknowledge that this method works.

  gpg --export --export-options export-clean | gpg --homedir 
$HOME/.mutt/autocrypt --import --import-options keep-ownertrust

Or, if keep-ownertrust was not specified, afterwards use

  gpg --export-ownertrust | gpg --homedir $HOME/.mutt/autocrypt 
--import-ownertrust

The signatures of encrypted and signed mails of trusted keys present in
autocrypt then are verified as trusted.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: botched display - mutt or ncurses bug?

[Eike Rathke]

Hi,

On Thursday, 2019-11-07 21:40:00 +0100, Oswald Buddenhagen wrote:

> anyone else seen such a thing?

Never. Running Mutt master built on Debian buster and Fedora 29 in Gnome
terminal.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Background editing

[Eike Rathke]

Hi Kevin,

On Sunday, 2020-03-01 12:36:23 -0800, Kevin J. McCarthy wrote:

> manual: 

Seems to work. Nice feature!

What is a bit confusing is that when editing simultaneous messages of
the same thread then the background_format displays entries of the same
kind (apart from PID) as the subject is identical. It would be nice if
for replies the Message-Id of the replied-to messsage could be added to
background_format so that could be looked up if in doubt.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Background editing

[Eike Rathke]

Hi Kevin,

On Sunday, 2020-03-01 18:10:51 -0800, Kevin J. McCarthy wrote:

> I added %i to the list of expandos for $background_format.

Nice, thanks.

> Although I didn't add it to the default value, I'm quite open to suggestions
> for a good default.

I currently have "%5p %10S %s ; To: %r ; ID:%i"

May be too verbose or wide for some.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Background editing

[Eike Rathke]

Hi,

On Sunday, 2020-02-23 13:32:05 -0800, Kevin J. McCarthy wrote:

> On Mon, Feb 17, 2020 at 10:03:19AM -0800, Kevin J. McCarthy wrote:

Odd enough, I didn't receive that parent message. Anyway..

To conveniently switch between graphics and terminal editor I have the
following in muttrc

source '~/.mutt/detectgui.sh|'

and detectgui.sh contains

#!/bin/sh
if [ -n "$MUTT_USE_GVIM" -a -n "$DISPLAY" ]; then
echo 'set editor="gvim -f"'
echo 'set background_edit=yes'
else
echo 'set editor=vim'
fi


So exporting MUTT_USE_GVIM=yes (or anything) in the shell invoking mutt
switches to the background editing feature. Maybe that helps some to
test it.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Background editing

[Eike Rathke]

Hi Kevin,

On Thursday, 2020-04-09 20:33:23 -0700, Kevin J. McCarthy wrote:

> On Tue, Mar 03, 2020 at 09:11:37PM +0100, Eike Rathke wrote:
> > To conveniently switch between graphics and terminal editor I have the
> > following in muttrc
> > 
> > source '~/.mutt/detectgui.sh|'
> > [...]
> > So exporting MUTT_USE_GVIM=yes (or anything) in the shell invoking mutt
> > switches to the background editing feature. Maybe that helps some to
> > test it.
> 
> Replying to Aaron reminded me that you had sent a useful script too. Sorry
> for dropping the ball on replies!
> 
> As I said with Aaron, the same goes here.  If you'd like to contribute this,
> or a current iteration of it, please just let me know.  I'll bundle them
> into a background-edit group.

Yes of course, fine with me. Attached is the latest version that also
sizes and positions the gvim window.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


detectgui.sh
Description: Bourne shell script


signature.asc
Description: PGP signature

Re: Background editing

[Eike Rathke]

Hi Kevin,

On Saturday, 2020-04-18 12:56:20 -0700, Kevin J. McCarthy wrote:

> Are you okay with me adding the same license as the rest of Mutt (GPL 2+) to
> the header?

Yes of course.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: mutt 1.14.0 released

[Eike Rathke]

Hi Kevin,

On Sunday, 2020-05-03 07:02:56 -0700, Kevin J. McCarthy wrote:

> I'm always glad to hear from long-time users, especially
> when they are still happy with the new releases. :)

Oh yes, I continuously am, always on a quite recent master build :-)

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

[PATCH] allow short and long key ID user input in any pgp_long_ids mode for pgp_*

[Eike Rathke]

# HG changeset patch
# User Eike Rathke 
# Date 1421599541 -3600
# Node ID 5c6115fba7ac1efbe1f475b6e3bbe1898f3472bf
# Parent  cc790394468778ced239dc4d3245199cf3bd551e
allow short and long key ID user input in any pgp_long_ids mode for pgp_*

The following did not work, e.g. when leaving a key list, and at the "Sign as"
or "Encrypt to" prompt attempting to enter a key ID:
* set pgp_long_ids=no
  * enter a long key ID, with or without leading 0x
* set pgp_long_ids=yes
  * enter a short key ID without leading 0x

Specifically entering a long key ID should always be possible as evil32.com
has shown.

This also cleans up the logic used to determine the matching condition, which
was quite convoluted.. it even slightly speeds up the loop as less string
operations are involved in the inner condition.

This only changes how the result obtained from the pgp_* command line
interface is filtered.

diff --git a/pgp.c b/pgp.c
--- a/pgp.c
+++ b/pgp.c
@@ -117,11 +117,32 @@
   return 1;
 }
 
-char *pgp_keyid(pgp_key_t k)
+static pgp_key_t *_pgp_parent(pgp_key_t k)
 {
   if((k->flags & KEYFLAG_SUBKEY) && k->parent && option(OPTPGPIGNORESUB))
 k = k->parent;
 
+  return k;
+}
+
+char *pgp_long_keyid(pgp_key_t k)
+{
+  k = _pgp_parent(k);
+
+  return k->keyid;
+}
+
+char *pgp_short_keyid(pgp_key_t k)
+{
+  k = _pgp_parent(k);
+
+  return k->keyid + 8;
+}
+
+char *pgp_keyid(pgp_key_t k)
+{
+  k = _pgp_parent(k);
+
   return _pgp_keyid(k);
 }
 
diff --git a/pgp.h b/pgp.h
--- a/pgp.h
+++ b/pgp.h
@@ -35,6 +35,8 @@
 
 char *_pgp_keyid (pgp_key_t);
 char *pgp_keyid (pgp_key_t);
+char *pgp_short_keyid (pgp_key_t);
+char *pgp_long_keyid (pgp_key_t);
 
 
 int mutt_check_pgp (HEADER * h);
diff --git a/pgpkey.c b/pgpkey.c
--- a/pgpkey.c
+++ b/pgpkey.c
@@ -932,6 +932,7 @@
   pgp_uid_t *a;
   short match;
   size_t l;
+  const char *ps, *pl;
 
   if ((l = mutt_strlen (p)) && p[l-1] == '!')
 p[l-1] = 0;
@@ -945,6 +946,19 @@
   if (!keys)
 goto out;
 
+  /* User input may be short or long key ID, independent of OPTPGPLONGIDS.
+   * pgp_key_t->keyid should always contain a long key ID without 0x.
+   * Strip leading "0x" before loops so it doesn't have to be done over and
+   * over again, and prepare pl and ps to simplify logic in the loop's inner
+   * condition.
+   */
+  pl = (!mutt_strncasecmp (p, "0x", 2) ? p + 2 : p);
+  ps = (mutt_strlen (pl) == 16 ? pl + 8 : pl);
+
+  /* If ps != pl it means a long ID (or name of 16 characters) was given, do
+   * not attempt to match short IDs then. Also, it is unnecessary to try to
+   * match pl against long IDs if ps == pl as pl could not be a long ID. */
+
   for (k = keys; k; k = kn)
   {
 kn = k->next;
@@ -956,11 +970,10 @@
 for (a = k->address; a; a = a->next)
 {
   dprint (5, (debugfile, "pgp_getkeybystr: matching \"%s\" against key %s, \"%s\": ",
-		  p, pgp_keyid (k), NONULL (a->addr)));
-  if (!*p || mutt_strcasecmp (p, pgp_keyid (k)) == 0 ||
-	  (!mutt_strncasecmp (p, "0x", 2) && !mutt_strcasecmp (p + 2, pgp_keyid (k))) ||
-	  (option (OPTPGPLONGIDS) && !mutt_strncasecmp (p, "0x", 2) &&
-	   !mutt_strcasecmp (p + 2, k->keyid + 8)) ||
+  p, pgp_long_keyid (k), NONULL (a->addr)));
+  if (!*p ||
+  (ps != pl && mutt_strcasecmp (pl, pgp_long_keyid (k)) == 0) ||
+  (ps == pl && mutt_strcasecmp (ps, pgp_short_keyid (k)) == 0) ||
 	  mutt_stristr (a->addr, p))
   {
 	dprint (5, (debugfile, "match.\n"));


signature.asc
Description: Digital signature

[PATCH] allow short and long key ID user input in any pgp_long_ids mode for crypt_*

[Eike Rathke]

# HG changeset patch
# User Eike Rathke 
# Date 1421599842 -3600
# Node ID ed00f80073ea372e995fc8d4611991a2e2e08672
# Parent  5c6115fba7ac1efbe1f475b6e3bbe1898f3472bf
allow short and long key ID user input in any pgp_long_ids mode for crypt_*

The following did not work, e.g. when leaving a key list, and at the "Sign as"
or "Encrypt to" prompt attempting to enter a key ID:
* set pgp_long_ids=no
  * enter a long key ID, with or without leading 0x
* set pgp_long_ids=yes
  * enter a short key ID without leading 0x

Specifically entering a long key ID should always be possible as evil32.com
has shown.

This also cleans up the logic used to determine the matching condition, which
was quite convoluted.. it even slightly speeds up the loop as less string
operations are involved in the inner condition.

This only changes how the result obtained from the crypt_* gpgme interface is
filtered.

diff --git a/crypt-gpgme.c b/crypt-gpgme.c
--- a/crypt-gpgme.c
+++ b/crypt-gpgme.c
@@ -179,6 +179,34 @@
   return s;
 }
 
+/* Return the long keyID for the key K. */
+static const char *crypt_long_keyid (crypt_key_t *k)
+{
+  const char *s = "";
+
+  if (k->kobj && k->kobj->subkeys)
+{
+  s = k->kobj->subkeys->keyid;
+}
+
+  return s;
+}
+
+/* Return the short keyID for the key K. */
+static const char *crypt_short_keyid (crypt_key_t *k)
+{
+  const char *s = "";
+
+  if (k->kobj && k->kobj->subkeys)
+{
+  s = k->kobj->subkeys->keyid;
+  if (strlen (s) == 16)
+s += 8;
+}
+
+  return s;
+}
+
 /* Return the hexstring fingerprint from the key K. */
 static const char *crypt_fpr (crypt_key_t *k)
 {
@@ -4130,6 +4158,7 @@
   crypt_key_t *matches = NULL;
   crypt_key_t **matches_endp = &matches;
   crypt_key_t *k;
+  const char *ps, *pl;
 
   mutt_message (_("Looking for keys matching \"%s\"..."), p);
 
@@ -4141,6 +4170,19 @@
 
   if (!keys)
 return NULL;
+
+  /* User input may be short or long key ID, independent of OPTPGPLONGIDS.
+   * crypt_key_t->keyid should always contain a long key ID without 0x.
+   * Strip leading "0x" before loops so it doesn't have to be done over and
+   * over again, and prepare pl and ps to simplify logic in the loop's inner
+   * condition.
+   */
+  pl = (!mutt_strncasecmp (p, "0x", 2) ? p + 2 : p);
+  ps = (mutt_strlen (pl) == 16 ? pl + 8 : pl);
+
+  /* If ps != pl it means a long ID (or name of 16 characters) was given, do
+   * not attempt to match short IDs then. Also, it is unnecessary to try to
+   * match pl against long IDs if ps == pl as pl could not be a long ID. */
   
   for (k = keys; k; k = k->next)
 {
@@ -4148,15 +4190,11 @@
 continue;
 
   dprint (5, (debugfile, "crypt_getkeybystr: matching \"%s\" against "
-  "key %s, \"%s\": ",  p, crypt_keyid (k), k->uid));
+  "key %s, \"%s\": ",  p, crypt_long_keyid (k), k->uid));
 
   if (!*p
-  || !mutt_strcasecmp (p, crypt_keyid (k))
-  || (!mutt_strncasecmp (p, "0x", 2)
-  && !mutt_strcasecmp (p + 2, crypt_keyid (k)))
-  || (option (OPTPGPLONGIDS)
-  && !mutt_strncasecmp (p, "0x", 2) 
-  && !mutt_strcasecmp (p + 2, crypt_keyid (k) + 8))
+  || (ps != pl && mutt_strcasecmp (pl, crypt_long_keyid (k)) == 0)
+  || (ps == pl && mutt_strcasecmp (ps, crypt_short_keyid (k)) == 0)
   || mutt_stristr (k->uid, p))
 {
   crypt_key_t *tmp;


signature.asc
Description: Digital signature

Re: [PATCH] allow short and long key ID user input in any pgp_long_ids mode for pgp_*

[Eike Rathke]

Hi Kevin,

On Sunday, 2015-01-18 13:29:12 -0800, Kevin J. McCarthy wrote:

> > +static pgp_key_t *_pgp_parent(pgp_key_t k)
> 
> This should be
>static pgp_key_t _pgp_parent(pgp_key_t k)

Oops, yes, of course.
Attached is an amended patch.

> Otherwise, I think this patch looks good.  If there are no comments in a
> few days, I will push this.

Thanks
  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/
# HG changeset patch
# User Eike Rathke 
# Date 1421599541 -3600
# Node ID aa1783ebf072af28d136308d360758fcf93137d3
# Parent  cc790394468778ced239dc4d3245199cf3bd551e
allow short and long key ID user input in any pgp_long_ids mode for pgp_*

The following did not work, e.g. when leaving a key list, and at the "Sign as"
or "Encrypt to" prompt attempting to enter a key ID:
* set pgp_long_ids=no
  * enter a long key ID, with or without leading 0x
* set pgp_long_ids=yes
  * enter a short key ID without leading 0x

Specifically entering a long key ID should always be possible as evil32.com
has shown.

This also cleans up the logic used to determine the matching condition, which
was quite convoluted.. it even slightly speeds up the loop as less string
operations are involved in the inner condition.

This only changes how the result obtained from the pgp_* command line
interface is filtered.

diff --git a/pgp.c b/pgp.c
--- a/pgp.c
+++ b/pgp.c
@@ -117,11 +117,32 @@
   return 1;
 }
 
-char *pgp_keyid(pgp_key_t k)
+static pgp_key_t _pgp_parent(pgp_key_t k)
 {
   if((k->flags & KEYFLAG_SUBKEY) && k->parent && option(OPTPGPIGNORESUB))
 k = k->parent;
 
+  return k;
+}
+
+char *pgp_long_keyid(pgp_key_t k)
+{
+  k = _pgp_parent(k);
+
+  return k->keyid;
+}
+
+char *pgp_short_keyid(pgp_key_t k)
+{
+  k = _pgp_parent(k);
+
+  return k->keyid + 8;
+}
+
+char *pgp_keyid(pgp_key_t k)
+{
+  k = _pgp_parent(k);
+
   return _pgp_keyid(k);
 }
 
diff --git a/pgp.h b/pgp.h
--- a/pgp.h
+++ b/pgp.h
@@ -35,6 +35,8 @@
 
 char *_pgp_keyid (pgp_key_t);
 char *pgp_keyid (pgp_key_t);
+char *pgp_short_keyid (pgp_key_t);
+char *pgp_long_keyid (pgp_key_t);
 
 
 int mutt_check_pgp (HEADER * h);
diff --git a/pgpkey.c b/pgpkey.c
--- a/pgpkey.c
+++ b/pgpkey.c
@@ -932,6 +932,7 @@
   pgp_uid_t *a;
   short match;
   size_t l;
+  const char *ps, *pl;
 
   if ((l = mutt_strlen (p)) && p[l-1] == '!')
 p[l-1] = 0;
@@ -945,6 +946,19 @@
   if (!keys)
 goto out;
 
+  /* User input may be short or long key ID, independent of OPTPGPLONGIDS.
+   * pgp_key_t->keyid should always contain a long key ID without 0x.
+   * Strip leading "0x" before loops so it doesn't have to be done over and
+   * over again, and prepare pl and ps to simplify logic in the loop's inner
+   * condition.
+   */
+  pl = (!mutt_strncasecmp (p, "0x", 2) ? p + 2 : p);
+  ps = (mutt_strlen (pl) == 16 ? pl + 8 : pl);
+
+  /* If ps != pl it means a long ID (or name of 16 characters) was given, do
+   * not attempt to match short IDs then. Also, it is unnecessary to try to
+   * match pl against long IDs if ps == pl as pl could not be a long ID. */
+
   for (k = keys; k; k = kn)
   {
 kn = k->next;
@@ -956,11 +970,10 @@
 for (a = k->address; a; a = a->next)
 {
   dprint (5, (debugfile, "pgp_getkeybystr: matching \"%s\" against key %s, \"%s\": ",
-		  p, pgp_keyid (k), NONULL (a->addr)));
-  if (!*p || mutt_strcasecmp (p, pgp_keyid (k)) == 0 ||
-	  (!mutt_strncasecmp (p, "0x", 2) && !mutt_strcasecmp (p + 2, pgp_keyid (k))) ||
-	  (option (OPTPGPLONGIDS) && !mutt_strncasecmp (p, "0x", 2) &&
-	   !mutt_strcasecmp (p + 2, k->keyid + 8)) ||
+  p, pgp_long_keyid (k), NONULL (a->addr)));
+  if (!*p ||
+  (ps != pl && mutt_strcasecmp (pl, pgp_long_keyid (k)) == 0) ||
+  (ps == pl && mutt_strcasecmp (ps, pgp_short_keyid (k)) == 0) ||
 	  mutt_stristr (a->addr, p))
   {
 	dprint (5, (debugfile, "match.\n"));


signature.asc
Description: Digital signature

[PATCH] HEAD is dead, remove wrong instruction from doc/devel-notes.txt

[Eike Rathke]

# HG changeset patch
# User Eike Rathke 
# Date 1421831657 -3600
# Node ID 5d7345b4c516c733a84eb559f04cc553cdcab7fd
# Parent  6e5a62946141f41b9c7c6b1d60f0e348279cc2c3
HEAD is dead, remove wrong instruction from doc/devel-notes.txt

Branch HEAD was closed over a year ago. If one was following the instruction
to update -C HEAD you'd end up with an empty source tree and had to checkout
the default branch again.

diff --git a/doc/devel-notes.txt b/doc/devel-notes.txt
--- a/doc/devel-notes.txt
+++ b/doc/devel-notes.txt
@@ -129,12 +129,6 @@
 
   $ hg clone http://dev.mutt.org/hg/mutt/ mutt
 
-As a result of CVS-to-Mercurial conversion, you need to do:
-
-  $ hg update -C HEAD
-
-in the cloned directory.
-
 Once you've checked out a copy of the source, or changed your
 automake version, you'll need to run the script called './prepare' that
 is in the root directory.  The script does all the automake/autoconf


signature.asc
Description: Digital signature

[PATCH 0 of 2] Allow pgp fingerprint user input (part of #3695)

[Eike Rathke]

Hi,

These patches probably don't qualify to close #3695, but at least
a fingerprint is accepted as user input and fingerprints of keys are
displayed. For both the pgp_list_pubring_command and
pgp_list_secring_command need to contain the --with-fingerprint option,
or have with-fingerprint in ~/.gnupg/gpg.conf

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: Digital signature

[PATCH 1 of 2] Allow fingerprint user input in pgp_getkeybystr() (part of #3695)

[Eike Rathke]

# HG changeset patch
# User Eike Rathke 
# Date 1423687117 -3600
# Node ID 01f6559e4bb51bfe86e9f48812480bd4d57adc03
# Parent  385d7434c9d6f44c732fd12fc76d543f9d5d7233
Allow fingerprint user input in pgp_getkeybystr() (part of #3695)

Accept and check input of a fingerprint and find the matching key.

Also, along with the addresses an entry with the fingerprint (without any
spaces) is now displayed for each key in the list of matches.

Note that for both to work, match against and display of fingerprint, the
pgp_list_pubring_command and pgp_list_secring_command need to contain the
--with-fingerprint option, or have with-fingerprint in ~/.gnupg/gpg.conf

diff --git a/crypt.c b/crypt.c
--- a/crypt.c
+++ b/crypt.c
@@ -900,3 +900,81 @@
 }
 
 
+/* Obtain pointers to fingerprint or short or long key ID, if any.
+ * See mutt_crypt.h for details.
+ */
+const char* crypt_get_fingerprint_or_id (char *p, const char **pphint,
+const char **ppl, const char **pps)
+{
+  const char *ps, *pl, *phint;
+  char *pfcopy, *pf, *s1, *s2;
+  char c;
+  int isid;
+
+  /* User input may be partial name, fingerprint or short or long key ID,
+   * independent of OPTPGPLONGIDS.
+   * Fingerprint without spaces is 40 hex digits (SHA-1) or 32 hex digits (MD5).
+   * Strip leading "0x" for key ID detection and prepare pl and ps to indicate
+   * if an ID was found and to simplify logic in the key loop's inner
+   * condition of the caller. */
+
+  pf = mutt_skip_whitespace (p);
+  if (!mutt_strncasecmp (pf, "0x", 2))
+pf += 2;
+
+  /* Check if a fingerprint is given, must be hex digits only, blanks
+   * separating groups of 4 hex digits are allowed. Also pre-check for ID. */
+  isid = 2; /* unknown */
+  s1 = s2 = pf;
+  do
+  {
+c = *(s2++);
+if (('0' <= c && c <= '9') || ('A' <= c && c <= 'F') || ('a' <= c && c <= 'f'))
+{
+  ++s1; /* hex digit */
+  if (isid == 2)
+isid = 1;   /* it is an ID so far */
+}
+else if (c)
+{
+  isid = 0; /* not an ID */
+  if (c == ' ' && (((s1 - pf) % 4) == 0))
+;   /* skip blank before or after 4 hex digits */
+  else
+break;  /* any other character or position */
+}
+  } while (c);
+
+  /* If at end of input, check for correct fingerprint length and copy if. */
+  pfcopy = (!c && (((s1 - pf) == 40) || ((s1 - pf) == 32)) ? safe_strdup (pf) : NULL);
+
+  if (pfcopy)
+  {
+/* Use pfcopy to strip all spaces from fingerprint and as hint. */
+s1 = s2 = pfcopy;
+do
+{
+  *(s1++) = *(s2 = mutt_skip_whitespace (s2));
+} while (*(s2++));
+
+phint = pfcopy;
+ps = pl = NULL;
+  }
+  else
+  {
+phint = p;
+ps = pl = NULL;
+if (isid == 1)
+{
+  if (mutt_strlen (pf) == 16)
+pl = pf;/* long key ID */
+  else if (mutt_strlen (pf) == 8)
+ps = pf;/* short key ID */
+}
+  }
+
+  *pphint = phint;
+  *ppl = pl;
+  *pps = ps;
+  return pfcopy;
+}
diff --git a/gnupgparse.c b/gnupgparse.c
--- a/gnupgparse.c
+++ b/gnupgparse.c
@@ -164,6 +164,11 @@
 	  *is_subkey = 1;
 	else if (!mutt_strcmp (p, "uid"))
 	  is_uid = 1;
+	else if (!mutt_strcmp (p, "fpr"))
+{
+  is_uid = 1;
+  flags |= KEYFLAG_FINGERPRINT;
+}
 	else
 	  return NULL;
 
diff --git a/mutt_crypt.h b/mutt_crypt.h
--- a/mutt_crypt.h
+++ b/mutt_crypt.h
@@ -86,6 +86,7 @@
 #define KEYFLAG_CRITICAL 		(1 << 12)
 #define KEYFLAG_PREFER_ENCRYPTION 	(1 << 13)
 #define KEYFLAG_PREFER_SIGNING 		(1 << 14)
+#define KEYFLAG_FINGERPRINT		(1 << 15)
 
 #define KEYFLAG_CANTUSE (KEYFLAG_DISABLED|KEYFLAG_REVOKED|KEYFLAG_EXPIRED)
 #define KEYFLAG_RESTRICTIONS (KEYFLAG_CANTUSE|KEYFLAG_CRITICAL)
@@ -153,6 +154,16 @@
TEMPFILE.  */
 int crypt_write_signed(BODY *a, STATE *s, const char *tempf);
 
+/* Obtain pointers to fingerprint or short or long key ID, if any.
+   Return:  Copy of fingerprint, if any, stripped of all spaces, else NULL.
+Must be FREE'd by caller.
+   *pphint  Start of string to be passed to pgp_add_string_to_hints() or 
+crypt_add_string_to_hints().
+   *ppl Start of long key ID if detected, else NULL.
+   *pps Start of short key ID if detected, else NULL. */
+const char* crypt_get_fingerprint_or_id (char *p, const char **pphint,
+const char **ppl, const char **pps);
+
 
 
 /*-- cryptglue.c --*/
diff --git a/pgpkey.c b/pgpkey.c
--- a/pgpkey.c
+++ b/pgpkey.c
@@ -932,29 +932,22 @@
   pgp_uid_t *a;
   short match;
   size_t l;
-  const char *ps, *pl;
+  const char *ps, *pl, *pfcopy, *phint;
 
   if ((l = mutt_strlen (p)) && p[l-1] == '!')
 p[l-1] = 0;
 
+  pfcopy = crypt_get_fingerprint_or_id (p, &phint, &pl, &ps);
+
   mutt_message (_("Lookin

[PATCH 2 of 2] Allow fingerprint user input in crypt_getkeybystr() (part of #3695)

[Eike Rathke]

# HG changeset patch
# User Eike Rathke 
# Date 1423687143 -3600
# Node ID 659e014a1bfba9e75155a6df1223e8a7d1d7008f
# Parent  01f6559e4bb51bfe86e9f48812480bd4d57adc03
Allow fingerprint user input in crypt_getkeybystr() (part of #3695)

diff --git a/crypt-gpgme.c b/crypt-gpgme.c
--- a/crypt-gpgme.c
+++ b/crypt-gpgme.c
@@ -4188,32 +4188,24 @@
   crypt_key_t *matches = NULL;
   crypt_key_t **matches_endp = &matches;
   crypt_key_t *k;
-  const char *ps, *pl;
+  const char *ps, *pl, *pfcopy, *phint;
+
+  pfcopy = crypt_get_fingerprint_or_id (p, &phint, &pl, &ps);
 
   mutt_message (_("Looking for keys matching \"%s\"..."), p);
 
   *forced_valid = 0;
 
-  hints = crypt_add_string_to_hints (hints, p);
+  hints = crypt_add_string_to_hints (hints, phint);
   keys = get_candidates (hints, app, (abilities & KEYFLAG_CANSIGN));
   mutt_free_list (&hints);
 
   if (!keys)
+  {
+FREE (&pfcopy);
 return NULL;
-
-  /* User input may be short or long key ID, independent of OPTPGPLONGIDS.
-   * crypt_key_t->keyid should always contain a long key ID without 0x.
-   * Strip leading "0x" before loops so it doesn't have to be done over and
-   * over again, and prepare pl and ps to simplify logic in the loop's inner
-   * condition.
-   */
-  pl = (!mutt_strncasecmp (p, "0x", 2) ? p + 2 : p);
-  ps = (mutt_strlen (pl) == 16 ? pl + 8 : pl);
-
-  /* If ps != pl it means a long ID (or name of 16 characters) was given, do
-   * not attempt to match short IDs then. Also, it is unnecessary to try to
-   * match pl against long IDs if ps == pl as pl could not be a long ID. */
-  
+  }
+
   for (k = keys; k; k = k->next)
 {
   if (abilities && !(k->flags & abilities))
@@ -4222,9 +4214,17 @@
   dprint (5, (debugfile, "crypt_getkeybystr: matching \"%s\" against "
   "key %s, \"%s\": ",  p, crypt_long_keyid (k), k->uid));
 
+  /* If pfcopy != NULL it means a fingerprint was given, do not attempt to
+   * match long or short IDs then.
+   * If pl != NULL it means a long ID was given, do not attempt to match
+   * short IDs then.
+   * If ps != NULL it means a short ID was given.
+   */
   if (!*p
-  || (ps != pl && mutt_strcasecmp (pl, crypt_long_keyid (k)) == 0)
-  || (ps == pl && mutt_strcasecmp (ps, crypt_short_keyid (k)) == 0)
+  || (pfcopy && mutt_strcasecmp (pfcopy, crypt_fpr (k)) == 0)
+  || (!pfcopy
+&& ((pl && mutt_strcasecmp (pl, crypt_long_keyid (k)) == 0)
+  || (ps && !pl && mutt_strcasecmp (ps, crypt_short_keyid (k)) == 0)))
   || mutt_stristr (k->uid, p))
 {
   crypt_key_t *tmp;
@@ -4236,6 +4236,7 @@
 }
 }
   
+  FREE (&pfcopy);
   crypt_free_key (&keys);
   
   if (matches)


signature.asc
Description: Digital signature

Re: [PATCH 0 of 2] Allow pgp fingerprint user input (part of #3695)

[Eike Rathke]

Hi Kevin,

On Wednesday, 2015-02-11 19:57:18 -0800, Kevin J. McCarthy wrote:

> First, just a general note.  If you add (see #3695) to the top of
> a patch, the commit will be associated with the ticket automatically.

Mentioning the number like in (part of #3695) does not? Ok, I'll use
'see' then.

> For the pgp_getkeybystr() patch, I'd really like to have the fingerprint
> stored in the pgp_key_t structure, rather than in one of the address
> records.

But then the fingerprint wouldn't be displayed in the list, or would it?
The nice side effect currently is, that the fingerprints of all matching
keys are displayed, regardless whether a fingerprint was queried or not.
I suggest to leave that to a follow-up change once displaying
fingerprints is implemented properly.

> However, if the eventual goal is to
> switch the interface to show fingerprints, it would be better to have it
> in the pgp_key_t struct.

Makes sense in the long term.

> (As an aside, another problem with the current implementation is
> that trust values aren't present in the pgp_uid_t record for the
> fingerprint.)

Maybe that could be inherited from the primary uid.

> > For both the pgp_list_pubring_command and pgp_list_secring_command
> > need to contain the --with-fingerprint option, or have
> > with-fingerprint in ~/.gnupg/gpg.conf
> 
> It would be good to include modifications to contrib/gpg.rc inside the
> patchset.

Yeah, I'll do.

> I would also suggest adding the '--with-fingerprint' option
> twice, so that subkeys also get a fingerprint record.  (Which would of
> course only be used if OPTPGPIGNORESUB was unset)

Can do as well.


> In both of the "getkeybystr" modifications, I'd like to see the comparison
> kept more simple:
> 
> > diff --git a/pgpkey.c b/pgpkey.c
> 
> >  if (!*p ||
> > -(ps != pl && mutt_strcasecmp (pl, pgp_long_keyid (k)) == 0) ||
> > -(ps == pl && mutt_strcasecmp (ps, pgp_short_keyid (k)) == 0))
> > +(!pfcopy &&
> > + ((pl && mutt_strcasecmp (pl, pgp_long_keyid (k)) == 0) ||
> > +  (ps && !pl && mutt_strcasecmp (ps, pgp_short_keyid (k)) == 0
> 
> Since pfcopy, pl, and ps are all mutually exclusive, it would be clearer
> just to have:
> if (!*p ||
> (pfcopy && mutt_strcasecmp (pfcopy, k->fingerprint) == 0) ||
> (pl && mutt_strcasecmp (pl, pgp_long_keyid (k)) == 0) ||
> (ps && mutt_strcasecmp (ps, pgp_short_keyid (k)) == 0))

But that would mean to rely on an implementation detail of
crypt_get_fingerprint_or_id(). As is, implementation could be changed to
assign pointers to all possible valid IDs found and the comparison here
would still work correctly. If we simplify it, adding a contract to
crypt_get_fingerprint_or_id(), at least in its description, would be
necessary/helpful for the next dev.

> > diff --git a/crypt-gpgme.c b/crypt-gpgme.c

Same.


> > diff --git a/crypt.c b/crypt.c
> > +  /* Check if a fingerprint is given, must be hex digits only, blanks
> > +   * separating groups of 4 hex digits are allowed. Also pre-check for ID. 
> > */
> > +  isid = 2; /* unknown */
> > +  s1 = s2 = pf;
> > +  do
> > +  {
> > +c = *(s2++);
> > +if (('0' <= c && c <= '9') || ('A' <= c && c <= 'F') || ('a' <= c && c 
> > <= 'f'))
> > +{
> > +  ++s1; /* hex digit */
> > +  if (isid == 2)
> > +isid = 1;   /* it is an ID so far */
> > +}
> 
> You can ignore this comment, as it's your patch and mutt already has
> plenty of code more complicated than this ;-).  But wouldn't it be
> clearer just to rename "s1" to something like "hex_digit_count" and
> start it at 0?  Having variables like s1, s2, and pf made me have to
> stare at this code longer than I should to make sure I understood it.

It's simple ;)  s1 is the first, left pointer to copy to; s2 is the
second, right pointer to copy from. But I can change it to whatever you
wish if you want ;-)

> I'm a little uncomfortable with the code just assuming anything with
> modulo-4 spaces and a correct length is a fingerprint.

It doesn't, but you already found that out in the mean time ;-)

> It's an edge case, but if we want to remove the spaces, I would be more
> comfortable if we made sure all the characters were hex-digits, and
> return a LIST with both the original and de-spaced versions as hints.

Hmm.. given that only grouped hex digits of the correct length are
stripped of spaces, I think this is not necessary (anymore)?

> I did notice gpg will return the correct result if I search using
> the fingerprint with spaces in it.  Perhaps we could return the
> "with-spaces" version as the hint, or just remove hint as a parameter
> and just use "p" in the getkeybystr functions?

With spaces works with gpg command line, I'm not sure how gpgme would
handle that, I didn't try. Passing the stripped fingerprint works in all
cases.

I'll come up with amended patches later.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private commu

Re: [PATCH 0 of 2] Allow pgp fingerprint user input (part of #3695)

[Eike Rathke]

Hi Kevin,

On Friday, 2015-02-13 18:53:17 -0800, Kevin J. McCarthy wrote:

> If you are okay with my modifications to your patches, I'll push these
> after some more testing and giving others a chance to review them.

Yes, sure, makes sense. I didn't test the new series though.

Thanks
  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: Digital signature

Re: [PATCH 0 of 2] Allow pgp fingerprint user input (part of #3695)

[Eike Rathke]

Hi Kevin,

On Friday, 2015-02-13 18:53:17 -0800, Kevin J. McCarthy wrote:

> If you are okay with my modifications to your patches, I'll push these
> after some more testing and giving others a chance to review them.

I tried now, works fine.

If you didn't push yet, attached is a slightly modified version of my
resulting patch that changes the (s1-pf) use to a hexdigits counter and
adds a comment about the exlusive return pointers to the
crypt_get_fingerprint_or_id() declaration.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/
# HG changeset patch
# User Eike Rathke 
# Date 1423687117 -3600
# Node ID f0b0e80f5e36671bf36e283b3c7680f6202b2dbc
# Parent  6213c21607b79b1faab74ce39573c17a08011fb8
Allow fingerprint user input for key selection. (see #3695)

Accept and check input of a fingerprint and find the matching key.

Note that for both to work, match against and display of fingerprint, the
pgp_list_pubring_command and pgp_list_secring_command need to contain the
--with-fingerprint option, or have with-fingerprint in ~/.gnupg/gpg.conf.

diff --git a/crypt-gpgme.c b/crypt-gpgme.c
--- a/crypt-gpgme.c
+++ b/crypt-gpgme.c
@@ -4188,32 +4188,23 @@
   crypt_key_t *matches = NULL;
   crypt_key_t **matches_endp = &matches;
   crypt_key_t *k;
-  const char *ps, *pl;
+  const char *ps, *pl, *pfcopy, *phint;
 
   mutt_message (_("Looking for keys matching \"%s\"..."), p);
 
   *forced_valid = 0;
 
-  hints = crypt_add_string_to_hints (hints, p);
+  pfcopy = crypt_get_fingerprint_or_id (p, &phint, &pl, &ps);
+  hints = crypt_add_string_to_hints (hints, phint);
   keys = get_candidates (hints, app, (abilities & KEYFLAG_CANSIGN));
   mutt_free_list (&hints);
 
   if (!keys)
+  {
+FREE (&pfcopy);
 return NULL;
-
-  /* User input may be short or long key ID, independent of OPTPGPLONGIDS.
-   * crypt_key_t->keyid should always contain a long key ID without 0x.
-   * Strip leading "0x" before loops so it doesn't have to be done over and
-   * over again, and prepare pl and ps to simplify logic in the loop's inner
-   * condition.
-   */
-  pl = (!mutt_strncasecmp (p, "0x", 2) ? p + 2 : p);
-  ps = (mutt_strlen (pl) == 16 ? pl + 8 : pl);
-
-  /* If ps != pl it means a long ID (or name of 16 characters) was given, do
-   * not attempt to match short IDs then. Also, it is unnecessary to try to
-   * match pl against long IDs if ps == pl as pl could not be a long ID. */
-  
+  }
+
   for (k = keys; k; k = k->next)
 {
   if (abilities && !(k->flags & abilities))
@@ -4223,8 +4214,9 @@
   "key %s, \"%s\": ",  p, crypt_long_keyid (k), k->uid));
 
   if (!*p
-  || (ps != pl && mutt_strcasecmp (pl, crypt_long_keyid (k)) == 0)
-  || (ps == pl && mutt_strcasecmp (ps, crypt_short_keyid (k)) == 0)
+  || (pfcopy && mutt_strcasecmp (pfcopy, crypt_fpr (k)) == 0)
+  || (pl && mutt_strcasecmp (pl, crypt_long_keyid (k)) == 0)
+  || (ps && mutt_strcasecmp (ps, crypt_short_keyid (k)) == 0)
   || mutt_stristr (k->uid, p))
 {
   crypt_key_t *tmp;
@@ -4236,6 +4228,7 @@
 }
 }
   
+  FREE (&pfcopy);
   crypt_free_key (&keys);
   
   if (matches)
diff --git a/crypt.c b/crypt.c
--- a/crypt.c
+++ b/crypt.c
@@ -900,3 +900,83 @@
 }
 
 
+/* Obtain pointers to fingerprint or short or long key ID, if any.
+ * See mutt_crypt.h for details.
+ */
+const char* crypt_get_fingerprint_or_id (char *p, const char **pphint,
+const char **ppl, const char **pps)
+{
+  const char *ps, *pl, *phint;
+  char *pfcopy, *pf, *s1, *s2;
+  char c;
+  int isid;
+  size_t hexdigits;
+
+  /* User input may be partial name, fingerprint or short or long key ID,
+   * independent of OPTPGPLONGIDS.
+   * Fingerprint without spaces is 40 hex digits (SHA-1) or 32 hex digits (MD5).
+   * Strip leading "0x" for key ID detection and prepare pl and ps to indicate
+   * if an ID was found and to simplify logic in the key loop's inner
+   * condition of the caller. */
+
+  pf = mutt_skip_whitespace (p);
+  if (!mutt_strncasecmp (pf, "0x", 2))
+pf += 2;
+
+  /* Check if a fingerprint is given, must be hex digits only, blanks
+   * separating groups of 4 hex digits are allowed. Also pre-check for ID. */
+  isid = 2; /* unknown */
+  hexdigits = 0;
+  s1 = pf;
+  do
+  {
+c = *(s1++);
+if (('0' <= c && c <= '9') || ('A' <= c && c <= 'F') || ('a' <= c &&

Re: GPG public key not shown

[Eike Rathke]

Hi Heinz,

On Friday, 2015-03-27 19:39:06 +0100, Heinz Diehl wrote:

> > The key doesn't appear to be usable for encryption: it only has the sign
> > and certify capabilities set (the last field on the pub line).
> 
> Why would somebody want to upload a key which isn't suitable for encryption?

Because s/he uses it to sign things and certify keys and wants others to
be able to obtain the key and verify signatures?

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: Digital signature

Re: [PATCH] Allow multiple crypt-hooks with the same regexp. (closes #3727)

[Eike Rathke]

Hi Kevin,

On Saturday, 2015-04-04 11:41:12 -0700, Kevin J. McCarthy wrote:

> This is an updated version of the multiple-crypt-hook patch for
> consideration.  The patch looks big, but a large portion of it is just
> indentation changes: if you review it ignoring whitespace it's clearer
> what's going on.

IMHO it is much preferrable if such actions were split into two separate
patches, one for the cosmetic change and another one for the functional
changes.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: Digital signature

Re: [PATCH] Allow multiple crypt-hooks with the same regexp. (closes #3727)

[Eike Rathke]

Hi Kevin,

On Sunday, 2015-04-05 00:17:57 +0200, Eike Rathke wrote:

> > indentation changes: if you review it ignoring whitespace it's clearer
> > what's going on.
> 
> IMHO it is much preferrable if such actions were split into two separate
> patches, one for the cosmetic change and another one for the functional
> changes.

Sorry, I misinterpreted what you wrote, the indentation changes are due
to scope level changes. My bad.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: Digital signature

Re: [PATCH] Allow multiple crypt-hooks with the same regexp. (closes #3727)

[Eike Rathke]

Hi Kevin,

On Saturday, 2015-04-04 11:41:12 -0700, Kevin J. McCarthy wrote:

> So this version keeps track of when a key has been selected for an
> address and adds this:
>  else if (r == M_NO)
>  {
>if (key_selected || (crypt_hook->next != NULL))
>{
>  crypt_hook = crypt_hook->next;
>  continue;
>}
>  }
> So key selection with the original address will only take place for the
> last crypt-hook and only if a key hasn't been selected yet.

I think that behavior should be mentioned in the docs.

There's anyhow always some confusion with hooks and overriding and which
one wins in what order ;)

> This patch has a fairly specific use case, but I don't think it's too
> intrusive.  One side effect is that crypt-hooks for a regexp can't be
> changed, only appended to.  There may be a few cases where a person had
> multiple crypt-hooks and were counting on the ordering somehow, and now
> they have multiple prompts instead of just the first matching one.

When having multiple IDs for the same regex I would had assumed the last
matching won instead of the first.. as with most other hooks.


> --- a/doc/muttrc.man.head
> +++ b/doc/muttrc.man.head
> -\fBcrypt-hook\fP \fIpattern\fP \fIkey-id\fP
> +\fBcrypt-hook\fP \fIregexp\fP \fIkey-id\fP

This one makes me think.. was an expression such as

crypt-hook '~C ^account@example\.org$' '0x...'

a valid pattern, will it be a valid regexp? I guess not, for both?
Because the entire regexp (previously pattern) string is taken as
recipient expression?

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: Digital signature

Re: http://dev.mutt.org/trac/ticket/3638

[Eike Rathke]

Hi acefael,

On Saturday, 2015-05-02 13:32:23 +0100, acefael wrote:

> what do you think about the attached patch

Why send the mail twice? Anyway..

> [...]
> +"Many others not mentioned here contributed code, fixes," ,
> +"and suggestions." };
>  
> -  puts (_(Copyright));
> +  {
> +int csize = sizeof(Copyright)/sizeof(Copyright[0]);
> +int i;
> +for( i = 0 ; i < csize ; ++i ) {
> +  puts (_(Copyright[i]));
> +}
> +  }

What you may not be aware of, the _() underscore function is a special
function for the gettext() translation process. AFAIK it does not work
with array elements this way (someone correct me if I'm wrong). My
suggestion is, as the actual copyright information and names are not to
be translated, hold them in an array like you introduced, but do not use
_() on the elements, and only for the final sentence "Many others..."
use a separate variable and use that in _().

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: [PATCH] Change hardcoded subject of replies

[Eike Rathke]

Hi,

On Friday, 2020-07-24 13:01:39 -0500, Derek Martin wrote:

> On Fri, Jul 24, 2020 at 06:56:38AM +0200, Claus Assmann wrote:
> > "Re:" is a standard that should not be translated.
> 
> Except some languages don't use it.

Rather "some MUAs don't use it in some languages" and those MUAs are
broken, IMHO..

https://tools.ietf.org/html/rfc5322#section-3.6.5
3.6.5.  Informational Fields
| The "Subject:" field is the most common and contains a short string
| identifying the topic of the message.  When used in a reply, the field
| body MAY start with the string "Re: " (an abbreviation of the Latin "in
| re", meaning "in the matter of") followed by the contents of the
| "Subject:" field body of the original message.  If this is done, only
| one instance of the literal string "Re: " ought to be used since use of
| other strings or more than one instance can lead to undesirable
| consequences.

I think we all have seen the mess of "Re: Aw: AW: Re^2: ..."

Which is why I have
set reply_regexp="^((re([[^][0-9]+])? ?|aw|antwort|antw|fwd|fw):[ \t]*)+"

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: [PATCH] Change hardcoded subject of replies

[Eike Rathke]

Hi Kevin,

On Thursday, 2020-07-23 09:44:18 -0700, Kevin J. McCarthy wrote:

> > -env->subject = safe_strdup ("Re: your mail");
> > +env->subject = safe_strdup ("Re:");
> 
> I agree the default is weird, but I'd like to give time for others to chime
> in about this first.  I'll wait a week to see if anyone has a problem with
> this change.

A sole "Re:" is equally spammy, I've seen enough spam trying to hit with
just that.

"Re: your mail without subject from -MM-DD"
could do.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: [PATCH] Change hardcoded subject of replies

[Eike Rathke]

Hi,

On Friday, 2020-07-24 13:01:03 -0500, Derek Martin wrote:

> I think some other mailers default to something like
> "Re: (no subject)" which seems more suitable to me.

I agree.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Taking a break for a bit

[Eike Rathke]

Hi Kevin,

On Tuesday, 2020-07-28 13:12:24 -0700, Kevin J. McCarthy wrote:

> Thank you all!

Just to thank YOU instead for gaining expertise and bringing Mutt
forward all the last years and making it catch up on important features
and squeezing bugs.

I know that building community (above the submit patch -> review/commit
level) is hard, and it's even harder for such a (now niche?) program
that nevertheless addresses / is made for and used by the most
technically inclined people who are too busy or with whatever (rightful)
excuse to contribute steadily (including myself). It's certainly not
your fault and nothing about not being "good at bringing people onto the
team". You did so much for Mutt to make it suck even lesser :-)

Take your time to recharge batteries.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: S/MIME question

[Eike Rathke]

Hi isdtor,

On Saturday, 2020-09-12 09:32:35 +0100, isdtor wrote:

> Basically, what I want to achieve is that the locally saved copy of an 
> encrypted email is readable by and encrypted to me. By default, this is not 
> the case, and the saved copy is encrypted to the recipient only. This is due 
> to smime_default_key="".

Works (or at least did months ago, don't use S/SMIME regularly) for me
with

set smime_default_key=0xABCDEF12
set smime_self_encrypt=yes

where 0xABCDEF12 is the ID of
gpgsm -K youremailaddress


> The next step is to export my own cert with gpgsm and create the openssl hash,

Erm.. export? what for? to create the hash? How? Maybe that's the wrong
step. Just use the ID.

> then set smime_default_key to the same. With this setting, I can no longer 
> send encrypted mail at all, the error message is:
> 
>  error encrypting data: No public key?

And can you use gpgsm --encrypt to encrypt to that key respectively
using the hash you generated?

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: message_id_format

[Eike Rathke]

Hi Kevin,

Thanks for that anyway, which hopefully ends the "search for the holy
grail of msgid" now and forever :P

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Loosening mailcap filename sanitization to allow unicode filenames

[Eike Rathke]

Hi Kevin,

On Tuesday, 2021-04-27 10:17:29 -0700, Kevin J. McCarthy wrote:

> What if we added an allow_8bit parameter to the function, that also passed
> through bytes with the 8th bit set?  I'd keep this set off in all other
> invocations except the mailcap invocations.

Allowing *all* 8-bit may be ill advised. I'd disallow at least resulting
U+0080 to U+009F Unicode control characters (C1 control codes). Also
exclude the non-characters U+FFFE and U+. But, what text encoding
are we actually talking about? 8bit suggests UTF-8 encoding or
ISO-8859-... code pages (not assuming EBCDIC ;P). I don't see that
mutt_buffer_sanitize_filename() or its calling contexts have any notion
about text encoding. Assuming UTF-8 (as path names are supposed to be),
check for valid sequences?

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: [PATCH] Add skip_quoted_context option

[Eike Rathke]

Hi Kevin,

On Monday, 2021-06-14 05:49:50 -0700, Kevin J. McCarthy wrote:

> Thank you for your feedback Jim and Aaron.  It sounds like this would be a
> good feature, then.  :-)

I'm just chiming in to agree :-)

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: $reply_prefix

[Eike Rathke]

Hi,

On Friday, 2022-01-14 14:36:13 +0300, Jean Louis wrote:

> > > It MAY, and it MAY NOT. There is no strict rule to it.
> > 
> > Indeed, it doesn't say "MAY NOT", so that "Re: " is not forbidden.
> > But this does not mean that other prefixes are allowed.
> 
> Quite contrary, my understanding is that it implies that anything is
> allowed in the Subject: line. That is foundation of basic freedom for
> people to choose how their subject line should or would be.
> 
> Better file bug report on that RFC because what kind of standard it
> is when it just provides vague instructions with "MAY". It was
> capitalized with intention for people to understand that "MAY" implies
> "OR MAY NOT".

Suggested reading:
https://datatracker.ietf.org/doc/html/rfc2119
specifically
https://datatracker.ietf.org/doc/html/rfc2119#section-5

> The point and conclusion is all written in the RFC, this mutt settings
> is just fine. It may be there and may be not. RFC says it.

https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.5
| When used in a reply, the field body MAY start with the
| string "Re: " (an abbreviation of the Latin "in re", meaning "in the
| matter of") followed by the contents of the "Subject:" field body of
| the original message.

A "Re: " in a reply is optional. It does not say that anything else may
prefix the original Subject.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Upcoming freeze for 2.2.0 and maintainer update

[Eike Rathke]

Hi Kevin,

On Sunday, 2022-01-23 09:47:57 -0800, Kevin J. McCarthy wrote:

> Thank you all for your support, and to the development team for giving me
> the maintainership opportunity.

I can't thank you enough for keeping mutt being the mailer that sucks less!

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: IMAP connection closed while Getting mailbox UIDVALIDITY

[Eike Rathke]

Hi Andrej,

On Monday, 2023-04-17 15:26:19 +0200, Andrej Mikus wrote:

> [2023-04-17 09:23:48] 4< * OK [UIDVALIDITY 63817286416513] UIDs valid
> 
> Is the number returned by server too big? Thunderbird has no issues.

Might be. In imap/imap.c imap_open_mailbox() the UIDVALIDITY is scanned
as mutt_atoui() calling mutt_atoul() calling strtoul(). Even if on
a 64-bit system that may succeed with unsigned long (on 32-bit hopefully
would bail out with ERANGE already there), the conversion to unsigned
int in mutt_atoui() may fail if that is uint32_t.

> Is it worth to try more recent version I would have to compile?

Current (and mutt-2-2-10-rel fwiw) has a cleaner handling for trailing
characters (as the number is parsed from "63817286416513] UIDs
valid" but I didn't immediately spot a weakness in that old 1.13.2
version.

Anyway always worth a try. There's a much better handling of many things
compared to that outdated legacy version you have..

> Or would it need a new issue reported at
> https://gitlab.com/muttmua/mutt/-/issues

If the latest release doesn't succeed either then yes.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: What is a Message-id?

[Eike Rathke]

Hi,

On Wednesday, 2023-05-24 21:34:08 +0100, Ian Collier wrote:

> On Wed, May 24, 2023 at 07:54:32PM +0200, Ludolf Holzheid wrote:
> > From RFC 5322: "The message identifier (msg-id) syntax is a limited
> > version of the addr-spec construct enclosed in the
> > angle bracket characters, "<" and ">"."
> 
> > That is, the less-than and greater-than signs _are_ part of the
> > message id and are required for standard compliance.
> 
> OK, but at the bottom of section 3.6.4 of the same RFC:
> 
>Semantically, the angle bracket characters are not part of the
>msg-id; the msg-id is what is contained between the two angle bracket
>characters.

*Semantically*
MUAs don't interpret semantics of header fields.

> (That is in slight contradiction to the syntax diagram which clearly
> makes the angle brackets part of the definition of "msg-id".)

Whatever the brain semantically might mingle there, it's not an excuse
to omit the angle brackets. The syntax requires them to be present and
3.6.4 is clear on that:

msg-id  =   [CFWS] "<" id-left "@" id-right ">" [CFWS]


  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature

Re: Message security; protected header fields

[Eike Rathke]

Hi,

On Thursday, 2024-05-09 19:15:59 -0400, Derek Martin wrote:

> Probably fine for preventing casual eavesdropping, but for genuinely
> sensitive applications, should not be considered good enough, unless
> I'm missing some important detail...

If you can't trust but need to, then verify. The fingerprint over
a trusted channel. This has been part of PGP since the beginning.

  Eike

-- 
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/


signature.asc
Description: PGP signature