Added some features to the command line version

[landshark]

Hey -

I've updated my local 1.4.2 source for the command line version with the following features:

• --search URL - Searches the config file for a matching URL via patterns. Supports both regex and wildcard types. It also prints the account-name/description/username before prompting for a master password when this is used.
• --list - Lists all accounts and groups in a way which looks like the passworkmaker GUI in Firefox.
• Added MAC OSX build support to unix.mak
• Cleaned up some warnings in leet.cpp
• On unix/linux/Apple machines made ~/.passwordmaker.rdf the default RDF file, otherwise passwordmaker.rdf in the current  directory is still default.
• Zero'd out the master password memory when done with it. This should probably be done in a few more places for generated passwords.

Are you guys interested in a patch?

The --search was critical to me. There's no Safari plugin and with over 50 accounts in use across multiple master passwords, I can now take any URL from a webbrowser and feed it into passwordmaker via --search and it will search the account lists for a matching password and then ask me for the master password.  I also added the name/description printing because of the use of numerous master passwords. I use the description to separate them all.

--list output looks like this:

Defaults
Group Name 1
    Account Name 1
    Account Name 2
    ...
Group Name 2
   Account Name 3
   Account Name 4


I haven't tried nested groups, but I don't see why the current code wouldn't work.

--search looks like this:

~/passwordmaker-cli-1.4.2-src-new> ./passwordmaker --search https://login.yoursite.com/login.php?t=new
Name: The account name
Description: Whatever you had in the description
Username: Your username
Master Password:
<gen'd pw here>

[Miquel 'Fire' Burns]

The patch would be great.

[landshark]

Patch attached, let me know if there are problems with it.  The modifications were written in Linux so the line-ends of the new files are unix-style where as the existing files retained their MS-windows style.

I also have not updated the makefiles for compiling on Windows.  I don't have that environment setup.  If you don't want to include --list and --search in Windows builds, just ifdef em out.  The search code depends on libpcre, which is common in standard Linux installs.

I had problems with unix.mak when applying the patch on my mac box.  Just in case it fails for you, I've listed it below, it's small.


# USE_MAC   -   1 = compile on a MAC, 0 = compile elsewhere
# FINK_REPO -   Location of your MAC FINK software repository, you must have
#               libmhash and libpcre installed.
USE_MAC = 0
FINK_REPO = /sw

LINK = $(CXX)
DEFINES = -DUSE_MHASH -DTIXML_USE_STL
CFLAGS = -O2 -Wall $(DEFINES)
CXXFLAGS = -O2 -frtti -fexceptions -Wall $(DEFINES)
INCPATH = -I.
LIBS = -lmhash -lpcre -lpcrecpp

ifeq ($(USE_MAC), 1)
        CFLAGS := $(CFLAGS) -m32
        CXXFLAGS := $(CXXFLAGS) -m32
        INCPATH := -I$(FINK_REPO)/include $(INCPATH)
        LIBS := -m32 -L$(FINK_REPO)/lib $(LIBS)
endif

SOURCE = shared/hasher.cpp leet.cpp main.cpp passwordmaker.cpp pwmdefaults.cpp tinystr.cpp tinyxml.cpp tinyxmlerror.cpp tinyxmlparser.cpp listaccounts.cpp urlsearch.cpp
OBJECTS = $(SOURCE:.cpp=.o)
TARGET = passwordmaker

$(TARGET):  $(OBJECTS)
        $(LINK) -o "$(TARGET)" $(OBJECTS)  $(LIBS)

.SUFFIXES: .c .cpp .cc .cxx

.cpp.o:
        $(CXX) -g -c $(CXXFLAGS) $(INCPATH) -o $@ $<

.cc.o:
        $(CXX) -c $(CXXFLAGS) $(INCPATH) -o $@ $<

.cxx.o:
        $(CXX) -c $(CXXFLAGS) $(INCPATH) -o $@ $<

.c.o:
        $(CC) -c $(CFLAGS) $(INCPATH) -o $@ $<

include unix/depends

.PHONY: depend clean

depend:
        $(CXX) -MM $(CXXFLAGS) $(INCPATH) $(SOURCE) > unix/depends

clean:
        rm -f $(OBJECTS) $(TARGET) 2>/dev/null

[Miquel 'Fire' Burns]

Okay, I added the code to the Mercurial repo (which I had to create as I wasn't planning on working on this version anymore)

Once I get the ignore list from SVN and setup a build environment for the Windows build, I'll make a new release.

[Eric H. Jung]

landshark, that is very impressive. kudos to you for reverse-engineering the screwed up RDF format (no, that's not *my* format!) Are you looking for work, by chance?
miquel, why didn't you plan on supporting this edition anymore? feature-complete?

[landshark]

That was a pretty strange file format. Is it a native Mozilla/Firefox format?  I can't say I've seen very many tree-structures implemented as a flat style of model.  I much prefer nested data structures, must easier to read and write.

[Miquel 'Fire' Burns]

Put it this way, landshark just did the work that I wanted to do to make it feature complete.

Also, that is a Mozilla native format. I hate working with that format. I had started work on a more natural XML format to use. Never got the more advanced stuff worked out though (the account settings mainly)

As if I didn't have enough to do over the holidays, I'm learning Opera's 11 extension format. They may have used Chrome's model for extension handling.

[tanstaafl]

Wouldn't it make much more sense to just use sqlite format, since that is what moz is moving to for everything db related anyway?

[Miquel 'Fire' Burns]

Only if none of the versions/browsers we support lack support for sqlite. Also, using a custom XML or JSON format is better for the simple fact you don't need to have a special tool to read the file on some random computer.

[tanstaafl]

?

Obviously since ianap I may be horribly wrong, but direct browser support isn't required for an extension to use it, is it?

SQlite is heavily supported everywhere, and there are tons of tools, many cross-platform, that can directly manipulate sqlite databases.

So... what am I missing?

[Miquel 'Fire' Burns]

It's more of a worst case thing is the reason I don't want to use SQLite. If you're in a position that the only way to recover your data is through means of using some text editor, and only that, the SQLite data is basically GONE! Any binary format will be in that position actually.

And in the case of extensions, the browser does need to support it. (BTW, wrong thread to hijack for this discussion, wrong section)

And then there's the whole needing a RDF to SQLite conversion. An RDF to random XML format is more likely to work without issues (XSL).

[Eric H. Jung]

I wrote the PasswordMaker RDF-to-Abine-SQLite code in a few (full-time) days... maybe a week. So it's not a Herculean task. But I do agree with Miquel that using a text-based format (XML or even better... JSON) is the way to go if we ever do this.

Yes, sqlite tools are common, but database corruption is not uncommon. I had that happen to my places.sqlite file last week. That's the firefox file which stores things like history for the awesomebar find-as-you-type. Having said that, it's the first time I can ever recall a sqlite database getting corrupted on me.

Eric

[Miquel 'Fire' Burns]

JSON is the way to go. If only the folk making QT would add that as a module so the install directions for the Desktop won't read: Install QT 4.X or higher, then install ...

BTW, Click! uses JSON in a way (assuming you're not using IE6).

[Miquel 'Fire' Burns]

I got it mostly ready for release. Except I can't make a Windows version for some reason (the pcrecpp won't link)

If you have Mercurial installed, clone from here: http://passwordmaker.hg.sourceforge.net:8000/hgroot/passwordmaker/
If not, you can easily get a copy of the source from here (get source and pick the archive you want): https://bitbucket.org/passwordmaker/cli/overview

[Miquel 'Fire' Burns]

1.5 is now out.