First off, I'm very grateful for the work that has been done on KeePassSD - for v0.0.9, it is surprisingly functional. I have a Windows Mobile 6 device (Blackjack II), so I don't really have many choices for OpenSource password safes! I am making frequent backups! I do recognize that I may have to re-enter all of the passwords if the v2.x database format changes. But for now, it does work, and the ability to edit and add entries from my mobile device is greatly appreciated.
I have noticed some issues with the password entry screen, however.
The first one may be a user education issue. If I'm entering the password and I use the right-soft key to display the menu and then use the arrow keys to arrow down to "Show password" and then use the center button to select that menu item, it not only shows the password, but then it treats it as if I had wanted to "OK" the password. Same for "Hide password". Using h to select the menu option after using the right-soft key to display the menu does not trigger the same bug. This may be a user education issue, but I haven't seen other situations in other Windows Mobile apps where using the arrow keys and the center button to select menu options results in further actions.
The second one may be a .NET Framework 2.0 bug. I use Diceware to select strong passphrases, and my passphrases generally have spaces in them to separate the words. If I enter the passphrase very slowly and methodically, I don't have problems. If I enter the passphrase at a good clip and with the password hidden, it frequently treats the space as a space followed by a left arrow! For instance, say the passphrase was "foo bar bas" (no quotes). After entering, the string that results might be "foobar bas " or "foo barbas " or even "foobarbas ". When entering, I know I have a problem if there is an asterisk to the right of the cursor. I can even see it when it happens. It only happens in hidden mode, and it only seems to happen with space keys, and it only happens if I am entering keys faster than it can asterisk them.
There are, of course, a number of functionality improvements I'd like to see, but at this point you probably know where most of those are and so much of the codebase is probably in flux that it would be premature to raise issues like that, so I figured I'd stick to things that appear to be actual bugs.
Once again, thanks!
I can reproduce the first issue. This is the KeyUp handler for the Master Password, which fires because of the "Enter" event on Menu->Show/Hide Password while the Master Password textfield is still selected. I'll have to check if i can somehow work around that. Depends on the order of the events.
I can't reproduce the second issue on my HTC MTeoR. Does your device have a full hardware keyboard?
Yes - the device (Blackjack II) does have a full hardware keyboard. Since the second bug requires fairly rapid entry to reproduce, it wouldn't surprise me that it's hard to reproduce on a device that doesn't have a full hardware keyboard (and it appears that the HTC MTeoR doesn't). How do you implement the hiding (*) replacement? Is that built into the control or do you have code that handles KeyUp or something similar? I can see the characters briefly before they get replaced with asterisks, so I know something is doing it. If the latter, you might look over your code and think about race conditions - what would happen to it if a second character got inserted in the middle of your handler.
The password masking functionality is a property of the standard TextBox control.
On WM5 Smartphone / WM6 Standard devices this shows the typed character briefly before hiding it behind the chosen password masking character. This is because on Mobilephones with just a numeric keypad you have to press the same button several times in order to get the right character. Without showing the character briefly it would be impossible to check what was entered. E.g. Press 3 times 3 = "f" e.t.c. This is of course unnecessary when you have a full hardware keyboard.
There is nothing fancy happening in my code:
- Handle a Return/Enter KeyPress event to do a "Done" KeyPress
- The routine to mask/unmask the password
- Unselect the MasterKey CheckBox when you press Back and the MasterKey textbox is empty.
Have a look yourself:
Line 240 and following...
My guess is that the problem lies in the underlying libraries somewhere. I'm not 100% certain, but I think I saw the same behavior when setting up BlueTooth sync and entering the password there. Maybe it'll get fixed in 6.1 . . .
My testing shows that the center button in the menu issue is fixed is 0.1.0. :-)
Masked TextBox control persists, but I presume that this is a bug in the .NET Framework itself. I tried so more testing - I realized that there is no need to enter my actual password. If I leave masking on and enter "fofofofofofofofofofofofo" really fast, it goes in correctly. If I enter "f f f f f f f f f f f f f " really fast, I get "ffffffffffff ", with my cursor at the junction between the f's and the spaces. I'm not quite sure how to report this to Microsoft, but it is definitely a timing sensitive bug, and it definitely appears to only affect the space character. Hey. I know why the bug only affects the space character. If you hold down an alpha key, it starts to repeat. But if you hold down the space key, it will eventually pop up the symbol entry grid. So I'll bet you it's linked to the code for handling the timing for popping up that symbol entry grid. For some reason, it doesn't crop up in non-masked entry. What's really interesting (based on my testing) is that it doesn't crop up between the space character and the next character, but between the normal character and the space character. That is to say, if you enter "a " really quickly, you get "a " with the cursor between the "a" and the " " (you have to look before you turn off masking, since turning off masking sends the cursor to the end of the string). On the other hand, if you enter " a" really quickly, you get correct text and the cursor in the correct position (at the end of the string). The problem is not that the text enters incorrectly, but rather that following a non-space character with a space character too quickly results in the cursor being positioned incorrectly. But I'll bet it's still related to the space key behaving differently from other keys.
OK, it's not part of this thread, but if you've read this far I'd like to toss in a couple of usability requests (if you have time and agree):
* When viewing entries, it would be nice if the "Back/Clear" key would return to the entry list.
* When in the Entry list, it would be nice if the Right arrow key could be used to open a group (similar to the center key) and the Left arrow key could be used to close a group
And now for a minor bug report. Open a database and then leave the device alone for 30 seconds so that the screen goes blank and the database locks. Wake up your device and see the pretty password entry screen. Now wait 30 seconds for the screen to go blank again. Now wake up the device and enter the password. It will open the database very quickly and then immediately lock it again. If you go through multiple wakeups and sleeps, you'll have to enter the password n+1 times as each time the device blanks the screen, the application queues another lock! The easy way out is to Exit the app and re-enter it - better than having to enter a 20+ character password more than once (and yes, I did enter that password a whole bunch of times verifying all of this :-).
OK, and now for some major feature requests. These are stolen directly from Password Safe. First is that whenever a database is saved, rename the existing file to Filename.kdbx~ or something similar before writing the new file. This protects one against system crashes while the file is being written. No need for more than one backup. Once you've got that in place, the next option is somewhat safer to implement. Whenever a change is committed to the database, save it. This should be an option (no need to force it on users), stored in the kdbx file. Whenever an entry is Deleted, Created, or Modified, and the user OKs the action, save the database file.
OK - enough blather for now . . .
Well i must admit i still haven't the faintest clue how to reproduce your masked password entry problem. I tried with the WM6 QVGA Landscape Smartphone Emulator and that does not pup-up any Symbol list when holding the space-key. So whatever i do.... type fast "a<space>" masked or unmasked. It always seems to work fine, but this is probably because i haven't still understood how the problem looks like.
>* When viewing entries, it would be nice if the "Back/Clear" key would return to the entry list.
Escape key handling is implemented for PPC devices. On SP devices the .Net Compact Framework 2.0 eats/swallows the Back key event, when a TextBox is selected and defined as "Multiline", even if it is read-only. So i can only give you that function by taking the multi-line property away. Maybe an ok thing to do for the Title, but for the Notes this is not nice. However it would be strange if the "Back" only works when the Title is selected and not if any other field is selected.
>* When in the Entry list, it would be nice if the Right arrow key could be used to open a group (similar to the center key) and the Left arrow key could be used to close a group
Again this is different GUI behaviour between PPC and SP devices. On PPC devices Left collapses a tree note, Right expands it... On SP devices Left Right Up Down are reserved for scrolling, as you do not have a touchpad with scrollbars you can move with the stylus. Hence Microsoft made the "Enter/Return" key the Expand/Collapse trigger.
Thanks for discovering the Database locking bug. I found a way around it, but have no idea why it really happens. The power state events invokes a function to lock the database. The lock-function used to check "is a database open" and only then do the locking. Somehow when the "OpenDatabaseForm" is shown the invokes triggered by the power state events queue up. Strangely enough this does not happen when the "AboutForm" or the "EntryViewForm" is shown. Well the solution is obviously to only invoke the lock database function when a database is open.
Regarding the backup: I'll think about it. Shouldn't bee too difficult to copy the original database to *.kdbx~ before saving it. The database is obviously always saved when the Auto-Lock is executed, so saving whenever anything is changed looks a bit like overkill to me. At the moment the program creates a backup entry inside the database whenever somebody edits an entry, but the backup entry and changed new entry is obviously only saved when the database is closed.
Hmm - how does one enter symbols in the WM6 QGVA Landscape Smartphone Emulator? I wonder if the "Space/Sym" key approach is a Blackjack II specific detail. If so, the bug may only show up on device that implement that behavior.
Understand on all of the behavioral restrictions from the .NET / SP interactions. You have my sympathy having to code for so many different platforms (in terms of GUI interaction). This is my first WM device, and there's definitely been a learning curve for me as well (prior to this I had a Palm Vx that I bought used in 2002 and used up until this past March).
I'd say you're probably OK leaving the Auto-Lock handling auto-save - it happens pretty quickly anyway.
Here's another minor request - an Exit option on the "Open Database" menu (as it is, if I want to Exit, I have to do a Cancel and then a Menu->Exit). :-) But feel free to ignore.
Once again - keep up the good work! BTW, if you do change the database structure so as to make it non-forward compatible between releases, do you plan on notifying us in the release notes? That would be helpful - I totally understand what alpha means, but sometimes alpha is all we have to use, so I keep my database fairly small, back up regularly, and figure that if you change structure I'll just copy the entries by hand.
In case you're curious, I finally got around to updating my Blackjack II to the Windows Mobile 6.1 ROM and the bug disappeared, which confirms my suspicion that the problem is device linked.
Log in to post a comment.