- Mar 09, 2015
- Mar 05, 2015
- Feb 05, 2015
-
-
akwizgran authored
-
- Jan 31, 2015
-
-
akwizgran authored
-
- Jan 30, 2015
- Jan 29, 2015
- Jan 28, 2015
-
-
akwizgran authored
-
- Jan 14, 2015
- Jan 09, 2015
- Jan 08, 2015
-
-
Abraham Kiggundu authored
https://sourceforge.net/p/briar/bugs/49/ Fixed by ensuring that the generated contact and group intents are uniquely identified
-
Abraham Kiggundu authored
-
- Jan 07, 2015
-
-
Abraham Kiggundu authored
bug#49 Fixed by ensuring that intents for different contacts/groups can be distinguished from each other when resolving PendingIntent refs
-
- Jan 06, 2015
-
-
Abraham Kiggundu authored
-
Abraham Kiggundu authored
-
Abraham Kiggundu authored
-
akwizgran authored
-
Abraham Kiggundu authored
-
- Jan 05, 2015
- Jan 04, 2015
-
-
Abraham Kiggundu authored
-
- Dec 29, 2014
-
-
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.
-
akwizgran authored
-
- Dec 26, 2014
-
-
Abraham Kiggundu authored
-
Abraham Kiggundu authored
- replaced use of Object instance mutex with a private final Lock object - replaced Object signaling with specific condition signalling
-
- Dec 22, 2014
-
-
Abraham Kiggundu authored
-
- Dec 17, 2014
-
-
akwizgran authored
-