| 9 | | as of December 17, 2007 |
| 10 | | * privilege escalation for directory servers |
| 11 | | |
| 12 | | In the v0.6.1 release of Tahoe, it was intended and documented that you could grant read authority, read/write authority, or no authority to any person. We overlooked the fact that the limitation on write authority does not apply to people who control the directory server on which your encrypted directory resides. If you grant read-authority to such a person, they automatically get read-write authority. |
| 13 | | |
| 14 | | The next version of Tahoe, v0.7.0, which will be released soon, fixes this issue by using more powerful cryptography. In Tahoe v0.7.0 you can grant read authority, read/write authority, or no authority to any person and they are unable to get more authority than you've granted them, even if they control some of the servers on which your encrypted files and directories reside. |
| 15 | | |
| 16 | | * temporary exposure to local attacker |
| 17 | | |
| 18 | | In the v0.6.1 release of Tahoe, there was a short window of opportunity in which a local user on your system could read secrets out of the ~/.tahoe directory after they were written into that directory but before their permissions were set to be not-world-readable. This would be prevented on unix-like systems if you set permissions on your home directory or on the .tahoe directory so that others could not read the contents of files within it. In the upcoming v0.7.0 release of Tahoe such secrets are kept in a subdirectory of the ~/.tahoe directory, named ~/.tahoe/private, which is set so that users other than its owner cannot read data from files within it. |
| | 9 | as of January 8, 2008 |
