Skip to content
Snippets Groups Projects
  1. Nov 01, 2016
  2. Feb 11, 2016
  3. Feb 10, 2016
  4. Jan 27, 2016
  5. Dec 14, 2015
  6. Dec 08, 2015
  7. Nov 30, 2015
  8. 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
  9. Dec 14, 2014
  10. Nov 06, 2014
  11. Oct 08, 2014
  12. Oct 03, 2014
  13. Jan 24, 2014
  14. Jan 08, 2014
  15. May 14, 2013
    • akwizgran's avatar
      Fixed a race conditon when adding a transport and then an endpoint. · dddd15cd
      akwizgran authored
      To fix issue #3611966, KeyManagerImpl's handling of TransportAddedEvent
      was made asynchronous. This made it possible for a thread to call
      KeyManager.endpointAdded() before the KeyManager had asynchronously
      handled the TransportAddedEvent from a previous call to
      DatabaseComponent.addTransport().
      dddd15cd
  16. Apr 11, 2013
  17. Apr 10, 2013
  18. Apr 05, 2013
Loading