Skip to content
Snippets Groups Projects
  1. Jul 02, 2017
  2. Jun 28, 2017
  3. Jun 27, 2017
  4. Jun 26, 2017
  5. Jun 25, 2017
  6. Jun 16, 2017
  7. Jun 14, 2017
  8. Jun 12, 2017
  9. Jun 11, 2017
  10. Jun 08, 2017
    • Philipp Hörist's avatar
      Set transient for ErrorDialog · c8115e41
      Philipp Hörist authored
      Fixes #8649
      c8115e41
    • Philipp Hörist's avatar
      Replace unicode char in print message · 2296e75d
      Philipp Hörist authored
      2296e75d
    • Philipp Hörist's avatar
      Always pass utf8 encoded strings to python-gnupg · 1bf66b85
      Philipp Hörist authored
      self.encoding which we set in the init is only intended
      to decode gpg´s stderr which uses a system specific encoding.
      
      if we dont encode the data we pass to python-gnupg ourself, it will fallback and use self.encoding.
      This might be of no concern if self.encoding is set to 'utf8' and when we are on Linux
      which has a preferred encoding of 'utf8'.
      
      But if we are on Windows the preferred encoding for stderr
      is most of the time not 'utf8'. If python-gnupg tries to decode a stderr stream that is for example
      encoded with 'cp1252' with our set encoding of 'utf8' this will fail.
      
      The solution is to pre-encode the data before we pass it to python-gnupg, so it does not have to
      use self.encoding as a fallback. And set self.encoding='latin1' because latin1 will not yield exceptions
      on decoding errors. Also gpg itself will fallback to latin1 as stderr encoding when it cant determine the
      preferred encoding of a system.
      
      self.decode_errors is used for something differently, and has no influence on the situation.
      
      Fixes #8644
      1bf66b85
    • Philipp Hörist's avatar
      Remove unused GPG code · 2872993b
      Philipp Hörist authored
      2872993b
    • Philipp Hörist's avatar
      92b0a155
  11. Jun 06, 2017
  12. Jun 04, 2017
  13. Jun 02, 2017
    • Philipp Hörist's avatar
      Dont save sent MessageStanza for LMC use · ef822961
      Philipp Hörist authored
      There are mutliple reasons why this is not a good idea
      
      1. It places work on encryption Plugins, as many encryption attributes inside the
      stanza can not be resend again (OMEMO, OTR), so the plugins have to make sure none of
      these attr are inside the LMC stanza
      
      2. In general its not obvious for plugin devs that a stanza issued after LMC has to be
      treated differently. There should be no negative effects, even when a contributor not knowing
      about LMC at all.
      
      This commit saves only the stanza id, and adds the replace tag on the new message.
      This results also in less code.
      ef822961
  14. Jun 01, 2017
  15. May 29, 2017
Loading