Opened at 2005-11-27T12:22:30Z
Last modified at 2009-01-10T13:43:08Z
#30 new enhancement
Export user account data
Reported by: | deepseth (at) gmail (dotcom) | Owned by: | |
---|---|---|---|
Priority: | wishlist | Milestone: | |
Component: | BitlBee | Version: | 0.99 |
Keywords: | Cc: | ||
IRC client+version: | Client-independent | Operating System: | Public server |
OS version/distro: |
Description
The ability for clients to export their account data from a server, as a method of either:
a) backing up their settings
b) moving their settings to another bitlbee server (eg, from a public server to their own, or vice versa)
Attachments (0)
Change History (21)
comment:1 Changed at 2005-11-28T10:28:13Z by
comment:2 Changed at 2005-11-28T13:15:28Z by
Summary: | export user account data → Export user account data |
---|
comment:3 Changed at 2005-11-30T05:30:39Z by
it might not be a much worse thing than the security risks that are already present. bitlbee, IRC, and IM in general aren't really security land, anyhow.
comment:4 Changed at 2005-12-07T15:44:46Z by
What if the password wasn't exported then? And apon importing the account settings, it prompted for the account passwords? (and then sent them to whatever blackhole bitlbee keeps it in)
comment:5 Changed at 2005-12-31T01:44:36Z by
fyi, I'd like to be on the CC list for this bug.
deepseth has a good point. The passwords for the various protocols would be sufficient. In order to be able to export the accounts to begin with, you would have had to log on. The only reason to export settings is to save all the renames etc.
I also propose a possibility of an import of settings as well as an export.
Export and import could both happen via a DCC connect where the settings are sent as a file or tarball or whatever makes sense.
The only things that actually need to be trasmitted are: Protocol account logins, and the user renames etc that people have done for the various account.
Export no passwords for any accounts.
comment:6 Changed at 2006-01-08T12:32:02Z by
Cc: | nefar@… added |
---|
Okay, I put you on the CC list. Right now I'm thinking of implementing this, and making it configurable (at runtime/compile time or whatever).
comment:7 Changed at 2006-01-08T17:58:43Z by
go wilmer :) That will make it excellent for those who want to try it out on a public server before installing their own, or what not.
comment:9 Changed at 2006-07-07T00:41:08Z by
well, what if someone imports a bad user account data? i think this feature should not added to bitlbee. or it is just me that i'm too paranoid about data thieves.
comment:10 Changed at 2006-07-07T04:21:20Z by
I think you have to expand on that. How does importing bad user data enable anyone to "theive" anything?
comment:12 Changed at 2006-10-13T21:58:32Z by
Not really, but we got a dupe of this bug now. :-) #201
I still don't know what to do with this. It'd be the most useful on public servers, but exactly there I'd rather not have this functionality for security reasons...
comment:13 Changed at 2006-12-17T10:52:09Z by
Arse. I guess I might as well just bite the bullet and do all my renames again manually. Bleh.
comment:14 follow-ups: 15 16 Changed at 2006-12-17T10:57:56Z by
Arse.
I beg your pardon?
I can imagine the annoyance of the renames. But OTOH I think you'd also not be very happy if anyone could steal all your IM passwords once they get to know your BitlBee password. Making the information available to you means making it available to everyone, in theory.
comment:15 Changed at 2006-12-17T17:42:56Z by
Replying to wilmer:
Why do the IM passwords need to be stored with the export? We're only interested in exporting the contact list. passwords are easy and scarce to reenter. Renaming ALL the contacts on the other hand is much more work.
comment:16 Changed at 2007-03-02T11:28:20Z by
Replying to wilmer:
Arse.
I beg your pardon?
Apologies, I did not intend to offend.
I can imagine the annoyance of the renames. But OTOH I think you'd also not be very happy if anyone could steal all your IM passwords once they get to know your BitlBee password. Making the information available to you means making it available to everyone, in theory.
Agreed. I just saw the MOTD on testing.bitlbee.org about the upgrade to storage-xml. Given this new format, wouldn't it be possible to export the account data by means of sending the user their account details in an XML document by DCC? Strip out the password field, and when importing the XML back into the new bitlbee server, have it prompt the user for the passwords for those accounts? Or as an easier short term idea, have the user manually update the XML file with their passwords? (ie, export XML with blank password fields)
Or am I still dreaming? Heh.
comment:18 Changed at 2007-11-27T13:34:46Z by
I was just thinking of this kind of feature a few weeks ago, and voila! it's already been discussed. This would certainly be a nice feature from my point of view as well. I don't see how it would affect security if passwords are not exported with the rest of the account data.
comment:20 Changed at 2009-01-05T18:05:03Z by
Please remote me from the CC list. I stopped using bitlbee ages ago. Two reasons, this was one, the other was that there's no way to keep state wether I've read a message or not. That means if the server crashes or whatever, I loose which messages were unread. Since centerim offered this, and I can't see how this would be implemented through bitlbee (irc client maybe), I abandoned bitlbee.
comment:22 Changed at 2009-01-10T13:43:08Z by
Cc: | nefar@… removed |
---|
Recent versions of Trac seem to automatically Cc everyone who posted with their full e-mail address filled in instead of just a nickname. The only way I can remove you completely is most likely by editing the database directly. I'll give that a try now.
Yes, proper acknowledgement of received/read messages via IRC is hard to implement.
This is a nice idea, however, there's one problem. Right now it's not possible to get the IM passwords from BitlBee. You enter them once, and BitlBee will keep them for itself. With an export-system this little piece of security would disappear.
I don't know if that's a good thing.