taskWeeChat - Tasks: task #7395, Passwords, aliases and.....

 
 

task #7395: Passwords, aliases and.. encryption?

Submitted by:  Claudio M. Alessi <smoppy>
Submitted on:  Fri 19 Oct 2007 09:25:39 AM UTC  
 
Category: config fileShould Start On: Fri 19 Oct 2007 12:00:00 AM UTC
Should be Finished on: Wed 14 Nov 2007 12:00:00 AM UTCPriority: 5 - Normal
Status: DonePrivacy: Public
Percent Complete: 100%Assigned to: Sebastien Helleu <flashcode>
Originator Name: Open/Closed: Closed
Planned Release: 0.4.2IRC nick: claudio`

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 04 Sep 2013 02:15:55 PM UTC, comment #6:

It is because the string needs to be evaluated when you use it, for example when you connect to an irc server, the irc server will read the value of option with password, evaluate it (with eval_expression), then send it to server.

Otherwise if you changed the value in secured data config, how could it be propagated to all options?

And then secured data is not stored in options (as a cache, which would use a lot of memory), it's always retrieved on-demand.

To sum up, it's for performance as well as saving memory.

If you need more info or have ideas to change some things, feel free to join #weechat.

Sebastien Helleu <flashcode>
Project AdministratorIn charge of this item.
Wed 04 Sep 2013 01:59:32 PM UTC, comment #5:

Is there any special reason why the implementation was done using weechat_string_eval_expression() instead of integrating it directly within the core's config option code itself, so that ANY string option automatically supports secure data?

Anonymous
Fri 02 Aug 2013 06:28:34 PM UTC, comment #4:

The branch has been merged to master.

Sebastien Helleu <flashcode>
Project AdministratorIn charge of this item.
Sat 27 Jul 2013 11:05:36 AM UTC, comment #3:

I committed a first experimental version in git branch "secured-data".
It introduces a new file sec.conf, with a command /secure (see /help secure).
It is experimental, so for testing purposes only.
I'll merge to master when it will be considered as stable.

All feedbacks are welcome!

Sebastien Helleu <flashcode>
Project AdministratorIn charge of this item.
Wed 29 May 2013 04:30:24 PM UTC, comment #2:

Instead of wheel reinvention I suggest to use https://live.gnome.org/GnomeKeyring for secure password storage.
See also https://savannah.nongnu.org/bugs/?39118

Anonymous
Thu 03 Feb 2011 10:00:03 PM UTC, comment #1:

You should at least be able to hide your password now from prying eyes using the /rmodifier plugin: http://www.weechat.org/files/doc/stable/weechat_user.en.html#rmodifier_plugin

Filip H.F. "FiXato" Slagter <fixato>
Fri 19 Oct 2007 09:25:39 AM UTC, original submission:

I was playing a bit with the WeeChat aliases and i was wondering if would be useful to have encrypted passwords. The answer is yes, to me. Clean passwords are never a good thing, even if decryption is needed before send them. Also i have to power off my monitor before run the "/alias" command in order to hide my passwords from some alias i made (we won't presents our passwords to spy users, right? :-)).

Another thing i think can be used is a new server-specified option which include the password, possibly crypted (maybe with crypt(3) or encrypt(3)). This can be accessed by providing a global variable (at least for the server options and aliases). This approach can improve a bit the password management on WeeChat since we only have to set the password (crypted) in one place and then use the global variable to put it everywhere in the configuration. As example, suppose the global variable is called "$svrpwd", the *_server_command value may change from:

"/msg NickServ identify MyCleanPassword"

to a simple and "unspyable"

"/msg NickServ identify $svrpwd"

Now suppose we have to write the aliases "/ghost" and "/idchans". The 1st which kill the ghost, change the nick and identify us again into the server, the 2nd which identify us into every channel we are in list. Without encrypted password (and consequently without $svrpwd global variable) the only way to do this (exluding plugins) is to do something like this:

"/alias GHOST /msg NickServ ghost MyNickName MyPassword ; /nick MyNickName ; /msg NickServ identify MyPassword"
"/alias IDCHANS /msg ChanServ identify #MyChan1 MyPassword ; /msg ChanServ identify #MyChan2 Mypassword ; .. ; and so on"

This way, everytime you get the aliases list by typing "/alias", everyone hiding behind you (:D) can read your passwords.. easily.

This why i propose to add on WeeChat the following:

o Server option *_server_password_crypted;
o A global variable containing the value of the
this options (the crypted password)

It's implicit that the password have to be decrypted before use.

If you think a plugin can be a better solution, just ignore this item. However such feature should be provided with the WeeChat core or with a compilation option like "--encrypted-passwords" (which i don't like, really), i think.

PS: sorry for my english and THX to provide us a good software as WeeChat is.

Claudio M.

Claudio M. Alessi <smoppy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by flashcode (Posted a comment)
  • -unavailable- added by fixato (Posted a comment)
  • -unavailable- added by smoppy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 06 Oct 2013 07:47:07 AM UTCflashcodeOpen/ClosedOpen=>Closed
    Fri 02 Aug 2013 06:28:34 PM UTCflashcodeStatusReady For Test=>Done
    Sat 27 Jul 2013 11:05:36 AM UTCflashcodeStatusNone=>Ready For Test
      Percent Complete0%=>100%
      Assigned toNone=>flashcode
      Planned ReleaseNone=>0.4.2

    Back to the top


    Powered by Savane 3.1-cleanup