Re: [SyncEvolution] cmdline --keyring --print-config: should it show real password or "-"?

I prefer to 'not showing password' when printing config for the purpose of password protection. Password exposure could increase the risk of information security. I think typically users don't often want to see passwords. If necessary to show password, I think we could provide another option to force showing password in the command line. To limit abuse, maybe we could need users to input their passwords for current Linux(or other systems) login user. What do you think? Cheers, Yongsheng -----Original Message----- From: syncevolution-bounces(a)syncevolution.org [mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly Sent: Monday, September 21, 2009 4:04 PM To: SyncEvolution Subject: [SyncEvolution] cmdline --keyring --print-config: should it show real password or "-"? Hello! While testing Yongsheng's implementation of keyring support in the command line I ran into a case where I'd like to get some opinions: when the passwords are stored in the keyring, the config contains "-" instead of the real password. When invoked with "--keyring --print-config", should the command line retrieve the password from the keyring and present it to the user? I'm undecided about this myself. On the one hand, the password is no longer part of the configuration. On the other hand, the password cannot be shown via the command line even if the user wanted that. He has to know about keyring and the "seahorse" tool to view the keyring, then look for the password entry. Definitely not something for novice users. Therefore I tend to think that the password should be retrieved if available when --keyring is stored, without triggering an interactive request for the password if not. Would make "checkPassword()" more tricky, of course. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list SyncEvolution(a)syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution