Re: dev.mutt.org going down for the weekend

[Brendan Cully]

It's back up.

On Friday, 09 June 2017 at 14:25, Brendan Cully wrote:
> The "data center" hosting dev.mutt.org is undergoing power maintenance
> over the weekend, so the VM will be going offline shortly. I'll bring
> it back up as soon as I can.
> 

Re: [Mutt] #3952: Commit cf90bf5989f3 has broken mutt's display when sending email.

[Mutt]

#3952: Commit cf90bf5989f3 has broken mutt's display when sending email.
-+--
  Reporter:  chdiza  |  Owner:  mutt-dev
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:
 Component:  user interface  |Version:
Resolution:  |   Keywords:
-+--

Comment (by kevin8t8):

 This was a bad effect from #3951.  I forgot about the visual effect for
 msmtp users, and I predict it will make many people unhappy.

 I will change the fix for #3951 to do a hard redraw instead.

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3950: Prune unusable keys from PGP key selection menu

[Mutt]

#3950: Prune unusable keys from PGP key selection menu
-+-
  Reporter:  madduck |  Owner:  mutt-dev
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:
 Component:  crypto  |Version:  1.8.0
Resolution:  |   Keywords:  pgp unusable key menu selection
 |  expired revoked gpg recipient
-+-

Comment (by kevin8t8):

 GPGME and classic-PGP did differ.  Classic-PGP would not prompt if a
 single strong (trusted) exact match was found.  GPGME was still prompting
 if other matches were found.

 I'll push a commit to make GPGME the same as classic-PGP.

 You may also find it useful to set {{{unset pgp_show_unusable}}}

 However, even with this change, mutt will continue prompting if none of
 the results are fully trusted.

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3951: mutt is superslow

[Mutt]

#3951: mutt is superslow
-+--
  Reporter:  ps  |  Owner:  mutt-dev
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:
 Component:  user interface  |Version:  1.8.3
Resolution:  |   Keywords:
-+--

Comment (by kevin8t8):

 Sorry, the server was down for the weekend.  Please let me know if any of
 those solutions worked for you.

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3951: mutt is superslow

[Mutt]

#3951: mutt is superslow
-+--
  Reporter:  ps  |  Owner:  mutt-dev
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:
 Component:  user interface  |Version:  1.8.3
Resolution:  |   Keywords:
-+--

Comment (by ps):

 You were right, putting $thorough_search back to false fixed my problem.
 Thanks!

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3951: mutt is superslow

[Mutt]

#3951: mutt is superslow
-+--
  Reporter:  ps  |  Owner:  mutt-dev
  Type:  defect  | Status:  closed
  Priority:  major   |  Milestone:
 Component:  user interface  |Version:  1.8.3
Resolution:  invalid |   Keywords:
-+--
Changes (by ps):

 * status:  new => closed
 * resolution:   => invalid


--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: corrupted attachments

[Derek Martin]

On Tue, Jun 06, 2017 at 02:03:34AM +0200, Andries E. Brouwer wrote:
> On Tue, Jun 06, 2017 at 09:15:23AM +1000, Cameron Simpson wrote:
> > On 05Jun2017 22:12, Andries E. Brouwer  wrote:
> >> A moment ago I sent 8 images as attachment with mutt.
> >> Three were garbled on arrival.
> > 
> > Just for some more context, did the files lack a useful file extension?
> 
> No mime-type was known. No mechanism using mime-types could work.

That can't be true.  You said you attached the files... they had to be
on disk and had to have names.  Even if your image format is
proprietary and lacks an official standard, you can manually set its
MIME type to application/octet-stream.  Mutt provides you the
ability to do this from the attachment menu.  You can edit
/etc/mime.types or your local mime.types and add a suitable
entry for your proprietary file types to avoid having to do it
manually.

> Using information when it is available is a separate discussion.
> In the present discussion one only has the file contents.

This also is not true.  When you asked Mutt to attach the file, you 
had to tell it the name of the file.  If you specified a bad filename
or didn't configure your mime types properly that's user error.

I'm not opposed to using libmagic for this, but I actually think the
heueristic code should be removed entirely from Mutt.  Message bodies
should be assumed to be text, and attachments are assumed to be NOT
text, by virtue of them not being message bodies.  Their types should
be determined via the standard MIME mechanisms.  If those mechanisms
fail--for whatever reason--assume application/octet-stream and move
on.  That guarantees the file will arrive unmolested and obviates the
need for some mostly pointless code in Mutt to try to guess what the
user was thinking.

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



pgpQskmuUh8WN.pgp
Description: PGP signature

Re: [Mutt] #3950: Prune unusable keys from PGP key selection menu

[Mutt]

#3950: Prune unusable keys from PGP key selection menu
-+-
  Reporter:  madduck |  Owner:  mutt-dev
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:
 Component:  crypto  |Version:  1.8.0
Resolution:  |   Keywords:  pgp unusable key menu selection
 |  expired revoked gpg recipient
-+-

Comment (by madduck):

 {{{
 also sprach Mutt  [2017-06-09 19:05 +0200]:

 I've tried this, but it had no effect.

 Meanwhile, I also found and unset $pgp_show_unusable and indeed,
 unusable keys are now no longer shown. However, the menu still pops
 up even if only one key is left after the pruning. I don't think it
 needs to do that.
 }}}

--
Ticket URL: 
Mutt 
The Mutt mail user agent

mutt: Make GPGME key selection behavior the same as classic-PGP....

[Brendan Cully]

changeset: 7084:26cbf2cac701
user:  Kevin McCarthy 
date:  Mon Jun 12 17:57:05 2017 -0700
link:  http://dev.mutt.org/hg/mutt/rev/26cbf2cac701

Make GPGME key selection behavior the same as classic-PGP. (see #3950)

Classic-PGP key selection auto-selected a match if there was a single
strong, valid, address-match result, even if there were other weak
matches.

GPGME was prompting in the same situation, if there were other weak
matches.

Change GPGME to match the classic behavior, as this is more useful and
matches the manual description.

diffs (82 lines):

diff -r dd0208f13983 -r 26cbf2cac701 crypt-gpgme.c
--- a/crypt-gpgme.c Fri Jun 09 11:31:06 2017 -0700
+++ b/crypt-gpgme.c Mon Jun 12 17:57:05 2017 -0700
@@ -4154,14 +4154,9 @@
   ADDRESS *r, *p;
   LIST *hints = NULL;
 
-  int weak= 0;
-  int invalid = 0;
-  int addr_match = 0;
   int multi   = 0;
   int this_key_has_strong;
   int this_key_has_addr_match;
-  int this_key_has_weak;
-  int this_key_has_invalid;
   int match;
 
   crypt_key_t *keys, *k;
@@ -4201,8 +4196,6 @@
   continue;
 }
 
-  this_key_has_weak= 0;/* weak but valid match   */
-  this_key_has_invalid = 0;   /* invalid match  */
   this_key_has_strong  = 0;/* strong and valid match */
   this_key_has_addr_match = 0;
   match= 0;   /* any match   */
@@ -4216,9 +4209,8 @@
   {
 match = 1;
 
-if (validity & CRYPT_KV_VALID)
-{
-  if (validity & CRYPT_KV_ADDR)
+if ((validity & CRYPT_KV_VALID) &&
+(validity & CRYPT_KV_ADDR))
   {
 if (validity & CRYPT_KV_STRONGID)
 {
@@ -4230,11 +4222,6 @@
 else
   this_key_has_addr_match = 1;
   }
-  else
-this_key_has_weak = 1;
-}
-else
-  this_key_has_invalid = 1;
   }
 }
   rfc822_free_address (&r);
@@ -4249,14 +4236,7 @@
   if (this_key_has_strong)
 the_strong_valid_key = tmp;
   else if (this_key_has_addr_match)
-  {
-addr_match = 1;
 a_valid_addrmatch_key = tmp;
-  }
-  else if (this_key_has_invalid)
-invalid = 1;
-  else if (this_key_has_weak)
-weak = 1;
 }
 }
   
@@ -4273,13 +4253,10 @@
   else
 k = NULL;
 }
-  else if (the_strong_valid_key && !multi && !weak && !addr_match
-  && !(invalid && option (OPTPGPSHOWUNUSABLE)))
+  else if (the_strong_valid_key && !multi)
 {  
   /* 
-   * There was precisely one strong match on a valid ID, there
-   * were no valid keys with weak matches, and we aren't
-   * interested in seeing invalid keys.
+   * There was precisely one strong match on a valid ID.
* 
* Proceed without asking the user.
*/

mutt: Force hard redraw after $sendmail instead of calling mutt_...

[Brendan Cully]

changeset: 7085:0e3730ed2c3c
user:  Kevin McCarthy 
date:  Mon Jun 12 18:29:48 2017 -0700
link:  http://dev.mutt.org/hg/mutt/rev/0e3730ed2c3c

Force hard redraw after $sendmail instead of calling mutt_endwin. (closes 
#3952) (see #3948)

Adding a mutt_endwin() seemed like a clean solution to allowing
ncurses pinentry for $sendmail, but it leaves other users watching a
blank screen.  This change is extremely likely to generate a large
number of complaints and bug reports.  So instead, force a hard
refresh afterwards.

diffs (18 lines):

diff -r 26cbf2cac701 -r 0e3730ed2c3c sendlib.c
--- a/sendlib.c Mon Jun 12 17:57:05 2017 -0700
+++ b/sendlib.c Mon Jun 12 18:29:48 2017 -0700
@@ -2446,7 +2446,13 @@
 
   args[argslen++] = NULL;
 
-  mutt_endwin (NULL);
+  /* Some user's $sendmail command uses gpg for password decryption,
+   * and is set up to prompt using ncurses pinentry.  If we
+   * mutt_endwin() it leaves other users staring at a blank screen.
+   * So instead, just force a hard redraw on the next refresh. */
+  if (!option (OPTNOCURSES))
+mutt_need_hard_redraw ();
+
   if ((i = send_msg (path, args, msg, option(OPTNOCURSES) ? NULL : &childout)) 
!= (EX_OK & 0xff))
   {
 if (i != S_BKG)

Re: [Mutt] #3948: Please add a hook called just before sendmail invocation

[Mutt]

#3948: Please add a hook called just before sendmail invocation
--+--
  Reporter:  tpikonen |  Owner:  mutt-dev
  Type:  enhancement  | Status:  closed
  Priority:  minor|  Milestone:
 Component:  mutt |Version:
Resolution:  fixed|   Keywords:
--+--

Comment (by Kevin McCarthy ):

 In [changeset:"0e3730ed2c3cef32f18402b8725e2bbc4eb367ae"
 7085:0e3730ed2c3c]:
 {{{
 #!CommitTicketReference repository=""
 revision="0e3730ed2c3cef32f18402b8725e2bbc4eb367ae"
 Force hard redraw after $sendmail instead of calling mutt_endwin. (closes
 #3952) (see #3948)

 Adding a mutt_endwin() seemed like a clean solution to allowing
 ncurses pinentry for $sendmail, but it leaves other users watching a
 blank screen.  This change is extremely likely to generate a large
 number of complaints and bug reports.  So instead, force a hard
 refresh afterwards.
 }}}

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3952: Commit cf90bf5989f3 has broken mutt's display when sending email.

[Mutt]

#3952: Commit cf90bf5989f3 has broken mutt's display when sending email.
-+--
  Reporter:  chdiza  |  Owner:  mutt-dev
  Type:  defect  | Status:  closed
  Priority:  major   |  Milestone:
 Component:  user interface  |Version:
Resolution:  fixed   |   Keywords:
-+--
Changes (by Kevin McCarthy ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"0e3730ed2c3cef32f18402b8725e2bbc4eb367ae"
 7085:0e3730ed2c3c]:
 {{{
 #!CommitTicketReference repository=""
 revision="0e3730ed2c3cef32f18402b8725e2bbc4eb367ae"
 Force hard redraw after $sendmail instead of calling mutt_endwin. (closes
 #3952) (see #3948)

 Adding a mutt_endwin() seemed like a clean solution to allowing
 ncurses pinentry for $sendmail, but it leaves other users watching a
 blank screen.  This change is extremely likely to generate a large
 number of complaints and bug reports.  So instead, force a hard
 refresh afterwards.
 }}}

--
Ticket URL: 
Mutt 
The Mutt mail user agent