Tony Caduto wrote: > Dave Page wrote: >> >> Actually, no, it's using it *exactly as it's documented* - which is >> not unlike any other win32 app. For example, if you use the IE ActiveX >> control to display web pages in your app, it will remember passwords >> you save there for reuse in Internet Explorer, the HTML Help reader or >> any other apps that use the IE control. >> > > Dave, > You guys need to make the pgAdmin III password storage private to > pgAdmin III. > You are indeed using a documented feature of libpq, but that does not > mean you are using it properly. I'm not sure that's something you can say with authority given that I'm fairly sure you have no idea what the original authors intent was, and that nowhere in the documentation does it say that only command line tools should use the feature. > What you have done is not right because you have not taken into > consideration that there are other 3rd party apps that use libpq, and > because you have chosen to take a shortcut in the password storage area, > it affects my application without my users knowledge. We *have* taken that into account, we have documented it, and we have provided a UI for the user to make their own tweaks. > Sure I am the only one who noticed this as of now, but there will be > others and I am sure they won't like it either. Just do the right thing > and make the change. I don't want to delete the darn file, but you will > leave me no choice, or maybe I will rename it while my app is running > and then > rename it back when my app is finished. I really shouldn't have to do > this. Why don't you just check to see if a matching entry is in the file and warn your users? That way they'll know whether pgAdmin set it up for them, a colleague did it, or even that they did it and subsequently forgot. > You guys need to step up to the plate and make the password storage > private to pgAdmin III, you can do this by using: > > PGPASSFILE (specifies the name of the password file to use for lookups) > or use a compiler directive and store it (the password) in > HKEY_CURRENT_USER in the registry or use a INI type file stored in the > users profile (Application Data on win32 users home directory on > Unix/Linux) > The second two options are probably the best. You could even use the > opportunity to make pgAdmin III better by encrypting the passwords so > they are not in plain text. I can guarantee that a auditor would find > fault with the use of pgpass anyway as it is totally not secure, and > don't try to tell me it is secure, anytime passwords are sitting on a > storage device in plain text it's a security risk. The first option won't work, for reasons I've already stated. The second options are barely any more secure than the current situation as the app would need to use reversible encryption, the key for which could never be kept secret (it's Open Source after all). > Leave the use of pgpass to the user for use with command line tools. > > I am not being unreasonable here. What I have brought to your attention > is a valid concern that NEEDS to be addressed. > In the past you have asked me to make changes to my website and I always > tried to accommodate your concerns, now it's your turn to consider one > of mine. That was entirely different - you were intentionally bad-mouthing and inaccurately describing pgAdmin in order to sell your own product!! I do not intend to rewrite this code (which has been in pgAdmin for years) on the basis of a single complaint from the author of an equivalent, but commercial tool. If you do not like the effects you see when a user has a pgpass file, you should warn them in your own code, not expect us to change ours to avoid using a documented feature of libpq. Regards, Dave.
