Yeah, the reason why it was plaintext initially was because I remember the gaim guys
and their FAQ basically saying "encrypting that on your disk is useless, it's open
source and anything that is encrypted can be decrypted".

Though gnome keyring might be the solution to that. The downside I can see is that
Specto will ask you for permissions each time it checks/starts up, right?

Correct.  However, pam-keyring can automatically open your Gnome keyring on login,
and people using NetworkManager *already* need to do the "ask for permission on
startup" bit.

Also, gnome-keyring will only ask you once per session, not once per session per app.

Correct.  However, pam-keyring can automatically open your Gnome keyring on login,
and people using NetworkManager *already* need to do the "ask for permission on
startup" bit.

Also, gnome-keyring will only ask you once per session, not once per session per app.

«people using NetworkManager *already* need to do the "ask for permission on
startup" bit.»

nope, only those who use some encrypted networks of some kind. My open wifi or wired
network does not ask for a password on login, thankfully.

The big problem I see is the incoming slew of users saying "gaaah, specto bugs me for
a password on startup!"; to which we could solve the problem by:
- giving the option of not remembering any passwords for security freaks
- giving the choice between saving everything in the keyring or in plaintext (with a
big warning)

If someone is willing to implement that, I guess I would not mind very much. Still,
you might want to read the insightful discussion here:
http://osnews.com/comment.php?news_id=17964

Chris, IIRC, python's pickle module for storing info saves to some binary thingy,
wouldn't that be a useful replacement for the ini-style watches.list we currently
have, while at the same time obscuring passwords?

Hmm. GNOME 2.20's keyring allows for the user to check a "always unlock this
particular keyring on startup" option. Maybe this would solve the problem? If yes,
anyone interested in integrating specto with gnome keyring?

In my dev branch the passwords are stored using the base64 module.
This is not a 100% safe but now the password is not saved in plaintext anymore!
We could also add gnome keyring support but for the moment specto can also be used
using only the command line and this would require you to install gnomelibs...

If someone wants to add (optional?) gnome-keyring support, there's a pythonic
gnome-keyring library as a part of the AWN project:

http://wiki.awn-project.org/index.php?title=AWNLib#AWNLib_Keyring_Object

There is a regression in Wout's branch. The password encoding messes up with certain
passwords. Maybe that would be a point in favor of using gnome keyring.

The errors are not password specific.
They happen when you import old watches that were not yet encoded.
Encoding these passwords on import should fix the problem.

I really don't like to use gnome-keyring because it would create a huge depency (and
a graphical interface) depency.
Later i will implement it as an option but it is not on my to-do-fast list :)

Your watch importing problem is fixed in my branch!

I have doubts on marking this as fixed, because the issue remains to me that encoding
our passwords in base 64 kind of seems like a joke (false sense of security and all
that)... Don't quite know what to do with this one.

Concerning comment 6 : i may have read a warning concerning systems with autologon :
they don't have that "unlock this particular keyring on startup" option" thing 
i'm not sure

base64 is encoding and not encryption. NOT COOL.

History has proven that weak encoding will always be broken. I am saying encoding
because base64 is not encryption nor is binary abstraction. If you can reverse the
passwords in the specto source code, so can an attacker.

To properly solve this issue, using a real encryption algorithm is the only sane
solution. Anything else is neglecting your users and giving them a false sense of
security.

You have 2 real solutions to this:
 - Re-implement a wrapper to gpg or an encryption algorithm like aes. Maybe use the
openssl libraries directly? Copy and paste code from revelation.
 - Be a good gnome tool and use gnome-keyring. Just like every other gnome app out there.

Also, what if the algorithm you eventually choose is broken? Say some brilliant math
genius finds a collision in the pgp algorithm? What do you do then? You get another
great review on linux.com that talks about this horrible security problem at the end
of the article.

Or...

You use an abstraction layer such as gnome-keyring. You flip a small bit and change
the algorithm specto (or all of gnome-keyring is using) and this issue wouldn't matter.

Take a look at this page for a quick example:
http://www.rittau.org/blog/20070726-01

The current implementation (encoding) is, in my opinion, worse than no implementation
at all. Either we use gnome-keyring or we use nothing, but this needs to be fixed for
0.3 I would think.

for reference, attaching a discussion we had regarding gnome-keyring. Some
implementation details (the logic that specto should use, in pseude-code maybe) would
be welcome.

	2008 03 21 gnome keyring debate.log
	5.3 KB Download

For what it's worth, someone provided a patch for gnome-keyring support for another
python application (Conduit)

http://mail.gnome.org/archives/conduit-list/2008-April/msg00015.html

Looking forward to specto no longer storing passwords in plain-text!

actually, Wout told me that specto can (and should) use the keyring by default in his
bazaar branch since a few revisions. Have not had the time to test this myself
though, so if someone here would like to do so, it would be much appreciated :)

Tested, and it works. I updated all my watches so that it saves the passwords in the
keyring, and Specto only asks for my keyring password on startup. 

Anyone would be welcome to do a security audit on the bazaar branch (bzr branch
lp:specto) though.

(No comment was entered for this change.)