1. 04 Mar, 2021 15 commits
  2. 12 Feb, 2021 1 commit
    • paz's avatar
      Change way to block passphrase interaction · 0b7c3a9f
      paz authored
      This changes the way we block gpg from asking interactively for a
      passphrase, ever. It's also a less hacky way to force this. This works
      with gpg-2.0.26+gpgme-1.5.1, gpg-2.1.18+gpgme-1.8.0,
      gpg-2.2.27+gpgme-1.14.0, and gpg-2.2.27+gpgme-1.15.1, which makes me
      optimistic that it's universally working.
      
      The previous solution brought problems for some platforms and specific
      combinations of gnupg with gpgme (resulting in "GPGME::Error no such
      file or directory").
      0b7c3a9f
  3. 11 Feb, 2021 1 commit
  4. 07 Feb, 2021 1 commit
  5. 02 Feb, 2021 3 commits
  6. 01 Feb, 2021 1 commit
    • ng's avatar
      fix #484 - add test cases for list emails · bc4c89e4
      ng authored
      Since we fixed the global regexp for email addresses in #483 list
      names with spaces are already not anymore possible.
      Adding some test case for potential regressions.
      bc4c89e4
  7. 19 Jan, 2021 1 commit
  8. 13 Jun, 2020 1 commit
  9. 12 Jun, 2020 1 commit
    • georg's avatar
      specs: fix errors on IPv6-only machines · 6a114316
      georg authored
      Do not rely on '127.0.0.1', but on 'localhost'.
      
      dirmngr receives some extra care, so it's able to cope with it.
      
      gpgconf --kill might hang indefinitely, therefore, rely on pkill.
      
      Relax the expected output of gpg if refreshing keys without a keyserver
      being available, as gpg might report various errors in such a situation.
      
      The dependency on dirmngr will be dropped soon, anyway, so I deem this
      acceptable as a workaround, for now.
      
      Closes #472
      6a114316
  10. 09 Jun, 2020 2 commits
  11. 19 May, 2020 1 commit
  12. 04 May, 2020 1 commit
  13. 15 Apr, 2020 2 commits
  14. 13 Apr, 2020 1 commit
  15. 30 Mar, 2020 1 commit
  16. 25 Mar, 2020 1 commit
    • ng's avatar
      fix #457 - ensure proper encoding if no charset is set on a part · badad300
      ng authored
      If a part did not have a charset set, we falled back to US-ASCII
      and then tried to encode the string into that. However, this only
      worked if the part had actually only ascii charcters, but as soon
      it contains non-ascii characters we failed. With this change we
      are encoding such parts as utf-8, thus adopting the future.
      badad300
  17. 22 Mar, 2020 1 commit
    • ng's avatar
      fix #458 - more proper encoding handling · 39ca2227
      ng authored
      This revisits the fixes for #409 (merged in !301), as when
      trying to parse unencrypted, but signed utf-8 mails, they were
      failing to be parsed and thus generated another error. More
      in-depth later.
      
      With this fix we are changing the approach:
      
        1. We switch to UTF-8 as default input
        2. If this is not a valid encoding, we try to convert the
           input to UTF-8
        3. If we are failing to convert, we scrub the input, so that
           at least what is proper UTF-8 will be passed on.
      
      ASCII-8BIT is a BINARY encoding and the mail library will only
      force the mail to have CRLF if it only contains ASCII conent.
      While UTF-8 is not a BINARY encoding and thus will get CRLF if
      it is a valid encoding. Getting CRLF is important for mails such
      as the one in `signed_utf8.eml`, as otherwise the parts detection
      will fail and the whole body will end up in the prologue, with no
      parts.
      Enforcing UTF-8 will still make some of our charset mails failing,
      as they are - validly - not UTF-8. By using a new dependency
      'charlock_holmes', we are able to detect the actual encoding and
      thus try to convert it to UTF-8. If everything fails, we just
      drop the invalid characters.
      39ca2227
  18. 28 Jan, 2020 4 commits
  19. 23 Jan, 2020 1 commit