1. 18 Jan, 2018 9 commits
  2. 16 Jan, 2018 6 commits
  3. 15 Jan, 2018 2 commits
  4. 14 Jan, 2018 1 commit
  5. 13 Jan, 2018 4 commits
  6. 12 Jan, 2018 2 commits
  7. 11 Jan, 2018 3 commits
    • Merge branch 'stable' · 4fa32548
      Kevin J. McCarthy authored
    • Add missing setup calls when resuming encrypted drafts. · 667a4710
      Calls to get the passphrase were missing for app/pgp and app/smime.
      App/smime was also missing a call to crypt_smime_getkeys().
      If a failure occurs, report it back, rather than just continuing.
      Otherwise, postponed messages could be completely lost.
      Kevin J. McCarthy authored
    • Create pgp and s/mime default and sign_as key vars. (see #3983) · db252e61
      The $postpone_encrypt and $(pgp/smime)_self_encrypt configuration
      variables have created a somewhat messier situation for users.  Many
      of them now have to specify their keys across multiple configuration
      (Trac) Ticket #3983 had a reasonable request: "if my encrypt and
      signing keys are the same, why can't I just specify my key once in my
      The problem currently is that $smime_default_key and $pgp_sign_as are
      both used to specify signing keys, and are set by the "sign (a)s"
      security menu choice.  So we can't store encryption keys there because
      some users have separate sign-only capability keys.
      Create $pgp_default_key to store the default encryption key.  Change
      signing to use $pgp_default_key, unless overridden by $pgp_sign_as.
      The pgp "sign (a)s" will continue setting $pgp_sign_as.
      Create $smime_sign_as.  Change signing to use $smime_default_key
      unless overridden by $smime_sign_as.  Change s/mime "sign (a)s" menu
      to set $smime_sign_as instead.
      Change $postpone_encrypt and $(pgp/smime)_self_encrypt to use
      $(pgp/smime)_default_key by default.
      Mark $(pgp/smime)_self_encrypt_as deprecated.  They are now aliases
      for the $(pgp/smime)_default_key config vars.
      Change $(pgp/smime)_self_encrypt default to set.
      The intent is that most users now need only set
      $(pgp/smime)_default_key.  If they have a sign-only key, or have
      separate signing and encryption keys, they can put that in
      $(pgp/smime)_sign_as.  This also enables to default self_encrypt on
      and solve a very common request.
      Thanks to Michele Marcionelli and Vincent Lefèvre for gently pushing
      me towards a solution.
      Kevin J. McCarthy authored
  8. 09 Jan, 2018 2 commits
  9. 08 Jan, 2018 2 commits
  10. 07 Jan, 2018 3 commits
  11. 06 Jan, 2018 2 commits
    • Change imap literal counts to parse and store unsigned ints. · 8fcf8eda
      IMAP literals are of type number.  Change imap_get_literal_count() to
      use mutt_atoui() instead of atoi().  Change the return type variables
      used to store the count to type unsigned int.
      It's doubtful this was a real issue, but as long as we're cleaning up
      incorrect atoi() usage, we should fix this too.
      Kevin J. McCarthy authored
    • Fix improper signed int conversion of IMAP uid and msn values. · b8190ef3
      Several places in the imap code, when parsing "number" and "nz-number"
      values from the IMAP data, use atoi() and strtol().  This is
      incorrect, and can result in failures when a uid value happens to be
      larger than 2^31.
      Create a helper function, mutt_atoui() and use that instead.  One
      place was using strtol() and relying on the endptr parameter, and so
      was changed to use strtoul() instead.
      Thanks to Paul Saunders for the bug report and original patch, which
      this commit is based on.
      Kevin J. McCarthy authored
  12. 04 Jan, 2018 1 commit
  13. 31 Dec, 2017 1 commit
    • Disable message security if the backend is not available. · 561e106c
      Gitlab issue #3 exposed an awkward corner case: if mutt is configured
      without PGP or S/MIME, and with GPGME, but $crypt_use_gpgme is unset.
      In this case, no backend will be available, but WithCrypto will be set
      That will allow various config vars to enable encryption or signing,
      even though there will be no backend available to perform them.  The
      message security flag might then be set, but when the user hits send,
      will end up back at the compose menu due to the error.
      The pgp or smime menu might not even be available to clear the
      security setting!
      Add a check in send.c before the compose menu is invoked, and give a
      warning message for the menu ops inside the compose menu.
      I believe this should prevent the issue.  However this is a corner
      case combined with user misconfiguration, so I don't believe is worth
      a large effort to completely eradicate.
      Kevin J. McCarthy authored
  14. 29 Dec, 2017 1 commit
  15. 28 Dec, 2017 1 commit