Version: (using KDE KDE 3.2.1) Installed from: FreeBSD Ports OS: FreeBSD I've long used my own hacked up python script to maintain a simple encrypted databases of passwords from the command line. Now I'm probably going to install pwsafe http://nsd.dyndns.org/pwsafe/ But wouldn't be be nice if kwallet had a command line interface so I could just use it? Probably wouldn't take all that much work to wrap various API calls in a command line interface, for someone who knows what they are doing and sees the value in it (remote and quick access to passwords via ssh, etc).
On April 2, 2004 07:31, Tim Middleton wrote: > I've long used my own hacked up python script to maintain a simple > encrypted databases of passwords from the command line. Now I'm probably > going to install pwsafe http://nsd.dyndns.org/pwsafe/ > > But wouldn't be be nice if kwallet had a command line interface so I could > just use it? Probably wouldn't take all that much work to wrap various API > calls in a command line interface, for someone who knows what they are > doing and sees the value in it (remote and quick access to passwords via > ssh, etc). Interesting idea, and rather easy to implement too. I'm not sure I'll be doing it anytime, but if someone wants to do it I can provide support with how to access the kwallet backend.
I think you can use the dcop api for this. I am actually doing this. But this requires KDE to be running in order to work. try dcop kded kwalletd
Interesting idea. I've been playing with it a bit... some notes and questions: Open wallet as "anonymous" window and get an access ID: dcop kded kwalletd open kdewallet 0 List folders: dcop kded kwalletd folderList <ID from above> List entries in the Passwords folder: dcop kded kwalletd entryList <ID from above> Passwords This returns simply "<QByteArray>" which isn't helpful: dcop kded kwalletd readEntry <ID from above> Passwords <entry name> This returns nothing that I can see... dcop kded kwalletd readPassword <ID from above> Passwords <entry name> So how does one actually get useful info from these last two calls?
On June 17, 2004 10:06, Tim Middleton wrote: > Interesting idea. I've been playing with it a bit... some notes and > questions: > > Open wallet as "anonymous" window and get an access ID: > dcop kded kwalletd open kdewallet 0 > > List folders: > dcop kded kwalletd folderList <ID from above> > > List entries in the Passwords folder: > dcop kded kwalletd entryList <ID from above> Passwords > > This returns simply "<QByteArray>" which isn't helpful: > dcop kded kwalletd readEntry <ID from above> Passwords <entry name> Yes that's a binary encoding version. dcop(1) can't demarshall it yet. Perhaps a feature request should be filed to demarshall QByteArray into base64 or similar. > This returns nothing that I can see... > dcop kded kwalletd readPassword <ID from above> Passwords <entry name> That one works fine for me. Don't forget it's case sensitive.
>Interesting idea, and rather easy to implement too. Then lets make it a little more complicated: The cli tool (or a lib) should be independent from kde, to access an exported wallet from non-kde systems, too.
Personally I don't care about non-kde systems; i can ssh into my KDE box and access the passwords. And you can do this with dcop. My box is always running... KDE is always running. Just added a note to the Amarok message board a few days ago where someone was looking for a way to control amarok from cli without X (ie. remotely ssh'd in). (Someone else pointed out ssh -X) I started fiddling with dcop, and found you can use dcop in an ssh session if you use the --user your_login) switch... Anyhow, just need to find some time someday to see if i can wrap the dcop calls discussed above into a useful cli script... and I'll be relatively happy, at least. But on the other hand I can see how other people might want more interoperability. Don't hold your breath for it on this though (is the sense I get). <-:
*** Bug 108566 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
*** Bug 208909 has been marked as a duplicate of this bug. ***