Clone this wiki locally
1) I preferred the previous icon with the cute gorilla, was so unique.
p((. You mean starting the windows gorilla? V. 22.214.171.124 will have the gorilla … (zdia)
p((. I did not add the above comment, but I second the gorilla’s return. The opening window with the gorilla image was better.
p((. Ok, I will add a checkbutton "Show Gorilla Icon" in the Preferences:Display tab. So everybody can decide for himself if he wants a gorilla in the login dialog (zdia 27.7.10)
p((. Added in version 126.96.36.199 (zdia 28.7.10) <hr>
2) It would be great to have an application for iPhone. I personally use password gorilla on several machine, running both win and linux and the database is kept synchronized through DropBox, but I really miss it when I use my iPhone.
p((.. I’m sorry. Apple is rigid in this point: (zdia)
bq. “No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and builtin interpreter(s)… An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.”
bq. " We are continually trying to make the App Store even better. We have listened to our developers and taken much of their feedback to heart. Based on their input, today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year.
bq. In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need."
p((.. Now there just needs to be a Tcl/Tk + Itcl system running on the iPhone…..
3) One feature I would like to request is a way to compare two "login entries". I wish for this the most after a merge and I have a listed conflict. I’d like to be able to see side by side all the data in the two conflicting entries so that I can decide what to do, delete one, merge some data manually between them, etc. This could be part of the "details" window after a merge and it would probably work out ok.
Thanks for a great little program.
PS - Apple recently relaxed the "interpreted code" limits, but the change may not be sufficient for PWGorilla.
p((. You could help me if you would send me a mail with a conflict report or, better, two sample databases with conflict potential and then we will see what can be done. (zdia 22.06.2010)
p((. It is easy enough to generate a conflict. Just create a first db, enter a single entry, save it. Then copy it to a new filename on disk, open it, change an item (i.e., change the password value). Then, merge the second filename.psafe3 back into the first filename.psafe3. When done, answer yes to "would you like a detailed report" and in the "merge report" will be listed the conflict.
p((. This situation can easily occur. Take the example of having a desktop (D) and laptop (L) machine, and wishing to keep synchronized one’s gorilla password storage files on both machines. If one logs onto site X using machine D, and site X demands that one change one’s password, then the pwsafe file on machine D will now differ from the pwsafe file on machine L. At some later time, one copies machine D’s pwsafe file to machine L to sync, and during the merge on machine L, one will get "1 conflict", and the detailed report will list that "login X - password differs". That situation is easy enough to handle, provided the password was all that changed, go to login X on L, delete the old L entry, and rename the newly inserted D entry containing the new PW. But for several fields within the record, the merge window simply says "element 17 differs", which is rather unhelpful. (This is with the 1.42 starkit, if this is fixed in the newer version, then ignore that "element 17" remark).
p((. However, where I’d like to be able to "compare" is in the situation where one has made edits on both machines (D & L) to the same entry. Maybe D changed the PW, but earlier L had added notes (i.e., to store answers to those "recovery" questions so many sites have now). In that situation, a simple "delete one, rename the other" is not sufficient, because what needs to happen is that some of the new data exists on D, some of the new data exists on L, and during a merge, the final correct entry is a mixture of both D’s data and L’s data. That is where I’d like to see the side by side comparison of two entries, the old entry from L and the newly inserted (by the gorilla merge function) entry from D, so that I can determine which pieces from which entry need to be mixed together to create the final correct entry.
p((. As things are at present, this compare could be handled quite easily if the edit password entry dialog box were not modal. (with the 1.42 starkit) But it is modal, and so I have to open it, remember what I saw, close it, open the second inserted merged entry, remember what was present in the first, etc. Being able to edit two separate entries simultaneously would provide just about 99.995% of my request. Because then I’d edit the old entry from L, and the newly inserted entry (for the same login) from D’s merged file at the same time, and mix/match the data around to create one final accurate entry, and delete the other entry.
bq. Being able to edit two separate entries simultaneously would provide just about 99.995% of my request.
Did you try to open 2 gorillas with database D and database L? If you open in each gorilla the Edit dialog you can put the modal windows with all information needed side by side and you can save the data immediately in each database. (zdia 27.7.10)
While that would work, it would not cover the majority (95%+) use case where I do want to have two edit windows open simultaneously. The situation where I want to edit dialogs at once is almost always immediately after a merge with conflicts. (i.e., merge the database file from my desktop into the database file on my laptop [I try to keep both files identical copies of each other]). In that situation, if it happens that I’ve made an earlier change on one of the two DB’s to an entry that also exists in the other DB, I’ll get a merge conflict. The merge results window will tell me some info as to what conflicted. But, within the main gorilla password tree I’ll end up with two records, one the old one that existed in the laptop DB pre merge, and the new record that merged in from the desktop with a time/date stamp added to the name/title.
Given that information, I now know which entry was the original on the laptop, and I know which entry came in from the desktop DB (the one with the timestamp in the name). But I do not know, and the merge results window does not reveal, which entry I should keep and which entry I should delete. If I changed the url field on the desktop, and made no changes on the laptop, then I’d keep the desktop entry (the timestamp’ed one). But if I had made a change to the url field on the laptop, and not on the desktop, then I’d want to keep the laptop entry (non-timestamp) and delete the incoming desktop entry. But, if I had made a change to the url field on the desktop, and a change to the notes field on the laptop, then the answer is not to delete one and keep the other, but to truly "merge" the two together.
But, as the merge report window, and the two separate pw db entries (one with a timestamp) reveal nothing about the actual differences between the two entries, I have to "edit" one, look at what is there, close the editor, "edit" the other, look at what is there, close it, decide what needs "merging" and then properly "edit" one to contain the changes from the other. With only one modal "edit" dialog at a time open, that dance gets old very quickly. If I could open ("edit") the original laptop entry, and simultaneously open ("edit") the new incoming entry from the desktop (the timestamped entry) then I could see side by side what differs (maybe the url in one, maybe the notes in the other) and decide what data to move where, create one true "merged" entry, and delete the other entry.
Now that you mention it, I suppose I could open a second gorilla instance, open the pwdb a second time (after having saved it after the merge), and view both in parallel that way. A "workaround" yes, an elegant solution, no.
p((. Added menuitem "View Login" which allows non-modal view windows. See 188.8.131.52 (zdia 20.08.2010)
4) There have been instances where I would have liked to have had a "lock now" button on the main pw-gorilla window (the one with the tree of login id’s that is the main GUI to the program). Yes, I can wait for the auto-lock timer to expire and the window will lock. But there have been instances where I would have liked to have "locked" it immediately by hitting a button.
p((. Added menuitem "Security:Lock Now". See 184.108.40.206 (zdia 26.7.10)
5) “Proper” (clipboard-less) interoperation with GnuPG v2: GnuPG 2 was quite a shock. I appreciate the security in avoiding the clipboard, but the appropriate method for passing passwords from the manager to gnupg isn’t clear. The suggestion is that the pinentry API is “easily” adapted. I looked around the manual and didn’t get any idea how to do that, however. Hopefully, you will be able to do it. (BTW, even with —no-grab, pinentry woudn’t accept clipboard data on my system, so having another channel would be valuable, even if that works for most people.)
p((. Could you provide a little more detail as to what is not working and/or how it is not working? Keep in mind, I do not have gpgv2 so I do not already understand how it is working. It sounds like you are storing gpg key passphrases in PWGorilla, but that gpgv2 when it prompts for passphrases disallows clipboard data insertion. What I fail to see is where the security enhancement arises from disallowing clipboard data insertion. If a system is compromised such that data placed upon the clipboard is at risk of theft, it is also compromised sufficiently for an attacker to obtain gpg passphrases by keystroke logging or input focus redirection as one types the passphrase into gpg. So disallowing clipboard data insertion does nothing to increase security, and everything to inconvenience an end user into utilizing a weak passphrase for their gpg keys (i.e., if I have to memorize the pass phrase, I am very much less likely to use "lkj98245jklafjhah987314ASG!#Yasdlgj" as said phrase). Or in other words, if a system is compromised, no about of disallow this or disallow that will save you from attack, and if a system is not compromised then disallowing conveniences such as clipboard passphrase entry is simply a pain to the end user.
p((. It seems that I have had gpgv2 installed on my Slackware system all along. After having spent some moments playing with pinentry, it seems that you have discovered a bug in the gtk incarnations of pinentry. Both pineentry-curses and pinentry-qt allow for clipboard paste from PWGorilla, although the -qt version does pop up a "grab failed" error from PWGorilla. The paste operation, even after the grab failed message, still functions properly with the -qt version. So you should file this as a bug report with the pinentry-gtk developers. (rle123, 2010-08-29)
I’m nearly certain it is not a bug. There are a mountain of complaints about this in pinentry-gtk-2 going back to 2004. Everything I read makes it very clear that clipboard support was removed deliberately as a security measure. I don’t know about -qt, but I read somewhere that pinentry-curses did not receive this change for both technical and usability reasons. I am forced to used pinentry-curses as a workaround for this reason, but thank goodness it does work. It would be great if someone with knowledge of pwGorilla could figure out how the inter-operation with pinentry is supposed to work. (pmouse 2011-06-22)
The inter-operation is supposed to work via paste from clipboard. And paste from clipboard requires the receiving program be coded to accept the paste (the actual workings are that the "paste" program has to ask for the clipboard contents). Some author of pinentry-gtk-2 decided to omit the code to ask for the clipboard contents, and so pinentry-gtk-2 is unable to accept a paste of anything from anywhere. The true fix here is to either complain to pinentry some more until they fix it, or submit a patch adding the necessary code to ask for the clipboard contents. And the patch has two sub-problems. One, I can not create such a patch, and two, if the pinentry maintainers operate under the incorrect belief that no-paste is a security enhancement then they likely would refuse a patch adding paste capability. (rle 2011-07-31)
Update: I see now that KeePassX has a feature they call "AutoType". This is specifically mentioned in reference to working around pinentry’s blockade on the X-clipboard input. Do you think you could implement something like this for gorilla? (pmouse 2012-07-31)
KeePassX’s "AutoType" is a keystroke injection system. It works by injecting fake keypresses into the input stream such that applications believe the user was typing when in fact it was KeePassX doing the typing. Implementing something like this for Gorilla is more difficult for several reasons:
1) Tk (Tcl’s windowing library, which Gorilla utilizes) has no support for injection of fake keystrokes into the system. So any ability to add this would depend upon a binary extension for Tcl/Tk that provided the ability.
2) The three major windowing systems upon which Gorilla runs all have different ways of injecting keystrokes, which means a binary extension really translates into three different binary extensions, one each for X11, MacOS, and Windows.
The Tcl wiki lists the TWAPI (http://wiki.tcl.tk/9886) extension as possibly providing the function under MSWindows. Under X11 the xdotool (http://www.semicomplete.com/projects/xdotool/) command (if installed) might also serve the same purpose. I have zero idea what might be available for MacOS to achieve this functionality.
In other words, it is not a trivial change…
6) Support for the "kill" text command and, perhaps, the "backspace word" command. "CTRL-U" "kills" a whole line text in most Linux applications and it would be especially handy in gorilla. Sometimes one makes a mistake near the end of a long passphrase and "kill" is exactly what you want to start over. Also, it would be nice to be able to backspace over whole words elsewhere in gorilla, if only for consistency of experience. CTRL-BACKSPACE is good, but I like the traditional CTRL-W, too.
p((. It seems after scrutinizing the default bindings lists in the man pages that much of your request exists in one form or another in the default bindings, albeit not as CTRL-U or CTRL-W. For line killing, the default ttk::entry bindings include both Shift-Home/Shift-End to move the insertion cursor to home/end while selecting text at the same time. Additionally, it includes Control-/ to select all text in the entry. Therefore in the use case of quickly clearing a known mistyped passphrase, presumably the insertion cursor would be at the end of the text in the entry, so Shift-Home or Control-/ would both select all text, and then beginning to type the passphrase a second time would first delete all selected text. For deletion by words in an entry, the default bindings include Control-Shift-Left and Control-Shift-Right to move the insertion cursor by words and select the word at the same time. So word deletion can be achieved by Control-Shift-Left/Right as appropriate followed by typing a replacement (or hitting backspace to simply delete).
p((. For the text widget, it contains the above bindings (although Control-/ selects all text in the widget) plus it contains Meta-Backspace and Meta-Delete to delete the word to the left of the insertion cursor and Meta-d to delete the word to the right of the insertion cursor. Unfortunately it already contains a default binding for Control-w (copy selected text to clipboard and delete selected text) so to implement word deletion by Control-w would mean loss of the cut to clipboard binding from its default location. The text widget does not contain a "kill line" binding, and appears to have no binding by default on Control-u, so kill line could be added, but the only location which uses a text widget in PWGorilla is the notes field for editing/entering login/password data.
p((. Are these default bindings sufficient (other than maybe adding a "kill line" binding to the text widget) for your wish?
Yes, I think so. The variety of default key-bindings is amazing. Thank you for looking into it. I quite like the Control-/ binding. I think that will suit my purposes well enough. Although, be advised that either Meta-Backspace or Meta-Delete is bound to kill-workspace in my window manager. (pmouse 2011-06-22)
(rle 2011-07-30) Note that in most Xwindows window managers, if the window manager binds to a keystroke for one of its own functions, the keystroke becomes invisible to applications (the WM consumes the keystroke, and typically does not pass it along). As well, in most window managers, there is no easy way for an app to "unbind" a window manager keystroke for itself. Plus, typically, any such "unbind" operation would be specific to that one window manager and therefore not generally applicable on all systems. So if Meta-Delete and Meta-Backspace are bound by your WM to kill-workspace, you would have to convince the WM to stop binding those if you wanted to use them in PWGorilla. <hr>
I would love it if gorilla could convert a file from passwordsafe-version-2 to passwordsafe-version-3 via command line.
AFAIK, gorilla is the only linux program that can write passwordsafe-version-3 files. But as an old-timer command-line user, I use a different program to manage my primary passwordsafe (version 2) database. Sometimes I need to access my passwords from my iTouch without internet access, but the iOS versions of passwordsafe only read version-3 files. I use gorilla to convert it from version 2 to version 3, but it’s a multi-step GUI process. I would really appreciate it if a command-line option (or some sort of internal scripting language) could do
gorilla --convert-v2-to-v3 .pwsafe.dat .pwsafe.psafe3
and save me a few steps and a slow gui connection.
bq. Ok, we will think about it (zdia, 2012-10-2)
bq. (Rich, 2012-10-04) Try the code at https://gist.github.com/3830921. At the moment it is intended to be run directly from the same directory as gorilla.tcl. Usage is: pwsafe-convert.tcl input-file output-file The one negative is that it has to use the terminal to obtain the password, and Tcl does not have any built in way to turn off terminal echo, so be careful about where you actually use it. It needs the gorilla source unpacked, Tcl 8.5 installed, and Itcl installed. If you want to run it from somewhere other that the directory containing gorilla.tcl, then replace both instances of "[ pwd ]" in the source with the full path to the directory that contains gorilla.tcl.
(hymie, 2012-10-04) Rich — That is awesome! Thank you very much. * (Rich, 2012-10-06) You are welcome. If you are running it under Linux, I just realized you can make a small change to turn off the password echo if you want. Immediately before the line: "gets stdin password" add this line: exec stty -echo And immediately after the line: "gets stdin password" add this line: exec stty echo This is Linux/Unix specific however, because it is actually executing the external "stty" command that should be installed. I have no idea if it would work under MacOS.
(hughh, 29 Jan 2014) * I would very much like to see a "read-only" option. I keep my password safes in Dropbox so I can access them from multiple computers, and I’d like to be able to avoid inadvertently making changes from multiple systems by having them each — except for the main system I use — start up in read-only mode. That way I’d have to explicitly change the mode to read-write on other systems before I could change any data.
(PorcelainMouse, 06 April 2015)
YubiKey Support. This is mentioned on the Discussions wiki page, but I’ll put wishlist, too. I’ve transitioned to another manager for this feature, but would have liked to have stayed with gorilla.
Maybe this wish should be expanded to two/second-factor support, in general. But, I think YubiKey is probably best option for first implementation, anyway.