Trac is being migrated to new services! Issues can be found in our new
YouTrack instance and WIKI pages can be found on our
website.
- Timestamp:
-
May 9, 2007, 2:48:35 AM (17 years ago)
- Author:
-
lschiere
- Comment:
-
--
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v3
|
v4
|
|
24 | 24 | * '''Store the password in plain text and control access to the file.''' This is what Purple does: the password is in {{{accounts.xml}}} in plain text, but the file itself is only readable by its owner. We allow the user to determine under what conditions sensitive files should be opened (if at all), and what constitutes a breach of security. |
25 | 25 | * '''Lastly, you can not store passwords at all.''' This is Purple's default, and by far the most secure of all of the options. |
| 26 | |
| 27 | If you really wanted to, you could write a script to wrap Purple that |
| 28 | would decrypt {{{accounts.xml}}} and re-encrypt it when Purple exits. |
| 29 | You wouldn't be able to encrypt it while Purple is running, because Purple |
| 30 | writes to {{{accounts.xml}}} for things like info change. This would |
| 31 | minimize your exposure time unless (like me) you run Purple nearly 24/7. |
| 32 | Personally, I feel that on any decent operating system, if someone can get to |
| 33 | your files you should either be able to trust the person to not touch |
| 34 | them, or you shouldn't be storing sensitive information there at all. |
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!