krid / keyring Goto Github PK

Providing an upgrade path from the original multi-depot format means that first-run does some extra monkey-motion that I don't like. Remove support for the old format, now that I've told the users it's going away.

Adding the 11th category overwrites the first one.

Alerts don't support linebreaks or other formatting, and thus the About... dialog is pretty messy looking.

When you swipe the first item, the list sort of shifts up, and the delete button never shows.

Pasting in import data gives the error "Unable to parse data syntax error string %0 is not valid JSON".

Reported by jacosta19, http://forums.precentral.net/showthread.php?p=2120514&posted=1#post2118659

It (probably) should not be possible to create two items whose titles differ only by case.

Implementing this is complicated because some db's will have items violating this already (mine does).

Suggestion from Grabber5.0.

This would work better combined with GH-14: "Separate view and edit scenes for items".

The old error message stays on the screen, and it's hard to understand what's going on.

Each row in the field list is too tall. Moving the "title" divs outside of the "label" divs fixes the issue.

If I'm viewing items for a specific category, then create a new item, the new item defaults to the "Unfiled" category. It would make more sense to default to the current category.

Scrolling to the bottom of the list every time you want to add a category is annoying.

Palm's implementation of Blowfish uses a static initialization vector (eight zero bytes), which can lead to a potential compromise of the first few blocks of encrypted data.

To work around this, random salt characters should be added to the beginning of the plaintext before it is sent to Mojo.Model.encrypt, and stripped off after decryption.

For the truly paranoid, clear the in-memory data and force a javascript GC on lockout. This would require keeping the encrypted data in memory, so it would increase memory consumption (though not by 2x, since I'm guessing a single string would use less mem than the db object tree).

Requested by Grabber5.0:

If you accidentally overwrite a value in a field, there is no way to undo it. Since the back gesture automatically saves the record, the only recourse is to retype the original value. In some scenarios, that could be quite a pain. Perhaps a menu item to cancel the current edit?

It's more complicated than that. The "correct" behavior is to save the item whenever any of the fields change. Believe me, that's the behavior that you want -- otherwise you lose your changes when the lockout timer fires (right now, creating a new item requires an explicit save, and I've been bitten by the timeout several times).

I'll file a feature request for some sort of history. That one's going to take some deep thinking, since it's not clear what should constitute "a single edit" when an item might be saved multiple times in the space of a minute. Furthermore, keeping history around will balloon the database, which will make the app slower and more error prone. An automated full database backup combined with the ability to selectively restore might be a better solution...

Category data is silently ignored on import. Reported by Trekker.

It would be easier to read item data if it didn't have to be displayed in an editable form. It would be easier to edit if it didn't have to look nice. Separating view & edit would make "click to copy to clipboard" conceptually simpler.

It would be better to use an HMAC as salt during encryption, and then check validity after decryption.

This requires access to a non-js hashing API. Pure-js md5 is 1s for 50K, and SHA-256 is 2.5s, whereas Mojo.Model.encrypt is 25ms for 50K.

Using an app assistant, and launching the stage means that there are two keyring processes running on the phone. Switch to a more standard method for starting up the app.

*) Edit an item and change the title to be the same as another item

*) Save or back-swipe

Expected:
Error message, and you're taken back to the item to fix it.

Actual:
Scene pops, but any changes made are discarded without warning when the duplicate title is detected. Data is lost.

Fix:
Do dup check on blur of the title field. If that happens at save/swipe, pop up a dialog. If it happens at timeout, revert back to old title and save the rest of the data.

Encryption is used in a way that makes password retrieval possible in some cases. If you already know one password, you can easily check if another entry has the same password by comparing the encrypted values.

Encrypted entries should include a random salt of a few characters length which is prepended to the actual value so that two equal passwords result in different encrypted values.

From Chris Piggot:
"""Keyring export to clipboard doesn't work, the file is a single line
and the line is too long for the email client to understand it ..."""

Waiting on further details...

Maybe adding linebreaks would help?

The import-from-clipboard method often includes cruft like email signatures, etc. Worse yet, the export-to-clipboard code adds a header string that the importer can't parse.

After a factory reset, import type and filename are still set.

The second time you hit "ok" on the dialog, it doesn't close. You can close it with "cancel", and the new password appears in the scene, but it isn't actually saved. Furthermore, when you exit the scene, the new item doesn't show up in the list view (though it is in the db).

The following log trace shows the problem:

[20100405-18:06:22.171347] info: generate password

[20100405-18:06:22.171890] info: randomCharacters

[20100405-18:06:22.172480] info: setGenerated 9wX4OOBu

[20100405-18:06:22.174386] info: updateItem

[20100405-18:06:22.174901] error: Uncaught Error: An entry with title "Slkdjf" already exists., app/models/ring.js:892

Even if you un-minimize the app, it will still lock out after 10 seconds have elapsed since the first minimization.

Hello,

I can not open Preferences windows with dev Keyring-0.4.0 (20100505) in GIT,
when I try to open it, I have this error message in the logs :
palm-webos-device user.crit LunaSysMgr: {LunaSysMgrJS}: com.otisbean.keyring: Uncaught TypeError: Cannot set property 'layoutCount' of undefined, palmInitFramework347:17671

I use Palm webos 1.4.5 in french and Palm Mojo SDK 1.4.5.

Thanks.

bill4212 writes:
http://forums.precentral.net/showthread.php?p=2215866&posted=1#post2215760

I think I hit a small bug when I just imported my data. Had 213
items, and after the import I was only able to scroll through the end
of the "D" entries (about 50 entries). I switched to another
category and then back to "ALL" and now I can see everything.

Request from JerryG in the forums: http://forums.precentral.net/homebrew-apps/201944-keyring-easy-password-management-9.html#post2129475

From a forum post by reyawn:
"I generated the password. I entered it in the web form, filled everything in, submitted the form, and then went back to the phone. Keyring had timed out [...] I didn't get to saving the new entry in Keyring yet, and upon unlocking it again I discovered that it was lost!"

(http://forums.precentral.net/homebrew-apps/201944-keyring-easy-password-management-10.html#post2173968)

I required explicit save to avoid problems with duplicate titles, but it would be better to check that on blur of the title field.

Rockbeast writes:

Somehow, I created about 5 copies of the same entry...with various
titles.  Here's what I think happened.
I entered a title for a new item.  It was an acronym.  After
entering some of the data, I hit save, because I didn't want to
risk timing out before losing my new item (see third issue below).
Then I decided, I want to spell out the acronym.  So I select the
record, I edit the title, and I tap within the acronym to start
entering extra letters to spell it out.  After each word and
space, I tap in another portion of the title to enter the extra
letters [...] It looks like each time I tapped again, the record
was saved and a new one was started.

It happens because every time you tap in the field it generates an event, which triggers the save-record call. I need to tighten up the event listener so it only triggers on blur and the like.