Skip to content
Snippets Groups Projects
  1. May 01, 2015
  2. Apr 29, 2015
  3. Apr 27, 2015
  4. Apr 16, 2015
  5. Apr 08, 2015
  6. Apr 07, 2015
  7. Apr 05, 2015
  8. Apr 04, 2015
  9. Apr 03, 2015
  10. Mar 23, 2015
  11. Mar 20, 2015
  12. Mar 11, 2015
  13. Mar 05, 2015
  14. Feb 05, 2015
  15. Jan 31, 2015
  16. Jan 30, 2015
  17. Jan 29, 2015
  18. Jan 28, 2015
  19. Jan 14, 2015
  20. Jan 07, 2015
  21. Jan 05, 2015
  22. Dec 29, 2014
    • akwizgran's avatar
      Don't try to erase secrets from memory. · 358166bc
      akwizgran authored
      1. The things we're really trying to protect - contact identities,
      message contents, etc - can't be erased from memory because they're
      encapsulated inside objects we don't control.
      
      2. Long-term secrets can't be protected by erasing them from memory
      because they're stored in the database and the database key has to be
      held in memory whenever the app's running.
      
      3. If the runtime uses a compacting garbage collector then we have no
      way to ensure an object is erased from memory.
      
      4. Trying to erase secrets from memory makes the code more complex.
      
      Conclusion: Let's not try to protect secrets from an attacker who can
      read arbitrary memory locations.
      358166bc
  23. Dec 26, 2014
  24. Dec 22, 2014
  25. Dec 17, 2014
  26. Dec 14, 2014
  27. Dec 13, 2014
    • akwizgran's avatar
      Application layer keepalives to detect dead TCP connections. · d4fa656d
      akwizgran authored
      DuplexOutgoingSession flushes its output stream if it's idle for a
      transport-defined interval, causing an empty frame to be sent. The TCP
      and Tor plugins use a socket timeout equal to twice the idle interval to
      detect dead connections.
      
      See bugs #27, #46 and #60.
      d4fa656d
  28. Dec 06, 2014
Loading