Thread: Re: [pgadmin-hackers] Client-side password encryption
> -----Original Message----- > From: Martijn van Oosterhout [mailto:kleptog@svana.org] > Sent: 19 December 2005 09:38 > To: Dave Page > Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut; > pgsql-hackers@postgresql.org; Andreas Pflug > Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password > encryption > > On Mon, Dec 19, 2005 at 09:16:19AM -0000, Dave Page wrote: > > > > > Something like > > > > > char *pg_gen_encrypted_passwd(const char *passwd, const > > > > > char *user) > > > > > with malloc'd result (or NULL on failure) seems more > future-proof. > > > > If programs are really worried about it, they should lookup the > > > function dynamically rather than statically... > > > > For the sake of a simple name change? > > The function as stated above doesn't exist yet, so we're adding a new > function, not changing the name of one. The function that started the > thread is not even exported by libpq so changing that shouldn't affect > anybody. Besides, this whole discussion is moot until someone writes > such a function. You missunderstand me - we were asked to start using the function in third party apps and I pointed out that it wasn't exported so we couldn't. Tom suggested exporting an API friendly version. As for the name, I meant the DLL name, not the function name. > As for Windows DLL hell, I don't know a lot about that, but if that's > such a problem, why didn't the original creators of the windows port > stick the version number in there from the start. On UNIX, libpq is > half versioned (the library is, but not the symbols) so I would have > thought copying that idea would have been obvious. Because we simply didn't think of it at the time, and it's something that has irked me ever since. Regards, Dave.
On Mon, Dec 19, 2005 at 10:32:03AM -0000, Dave Page wrote: > > > As for Windows DLL hell, I don't know a lot about that, but if that's > > such a problem, why didn't the original creators of the windows port > > stick the version number in there from the start. On UNIX, libpq is > > half versioned (the library is, but not the symbols) so I would have > > thought copying that idea would have been obvious. > > Because we simply didn't think of it at the time, and it's something > that has irked me ever since. In that case, I agree. I've always thought a lot of problem in windows could be solved if they systematically added a version number to every library (like in UNIX). Are there any reasons why we shouldn't change the libname with every release like for UNIX? I can't think of any, but you never know... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Martijn van Oosterhout <kleptog@svana.org> writes:
> Are there any reasons why we shouldn't change the libname with every
> release like for UNIX? I can't think of any, but you never know...
Surely that cure is far worse than the disease. You'd be trading a
might-break risk (app using new function will fail if used with old
library) for a guaranteed-to-break risk (*every* app fails if used
with *any* library version other than what it was built against).
The Unix version of the idea is considerably more flexible than
what would happen on Windows.
regards, tom lane
Tom Lane wrote: >Martijn van Oosterhout <kleptog@svana.org> writes: > > >>Are there any reasons why we shouldn't change the libname with every >>release like for UNIX? I can't think of any, but you never know... >> >> > >Surely that cure is far worse than the disease. You'd be trading a >might-break risk (app using new function will fail if used with old >library) for a guaranteed-to-break risk (*every* app fails if used >with *any* library version other than what it was built against). > >The Unix version of the idea is considerably more flexible than >what would happen on Windows. > > Different from Unix distros, win32 apps will always bring all their required libraries with them, so it's totally under control of the developer/packager. There's no such thing as prerequisite packages for win32 installs, new lib names will *not* break other apps when installed because older ones stay untouched. Regards, Andreas