On Tue, Jul 5, 2016 at 5:50 PM, Magnus Hagander <mag...@hagander.net> wrote: > On Tue, Jul 5, 2016 at 10:06 AM, Michael Paquier <michael.paqu...@gmail.com> > wrote: > However, is there something that's fundamentally better with the OpenSSL > implementation? Or should we just keep *just* the #else branch in the code, > the part we've imported from OpenBSD?
Good question. I think that we want both, giving priority to OpenSSL if it is there. Usually their things prove to have more entropy, but I didn't look at their code to be honest. If we only use the OpenBSD stuff, it would be a good idea to refresh the in-core code. This is from OpenBSD of 2002. > TLS is complex, we don't want to do that in that case. But just the sha > functions isn't *that* complex, is it? No, they are not. >> Another possibility is that we could say that SCRAM is designed to >> work with TLS, as mentioned a bit upthread via the RFC, so we would >> not support it in builds compiled without OpenSSL. I think that would >> be a shame, but it would simplify all this refactoring juggling. >> >> So, 3 possibilities here: >> 1) Use a single file src/common/sha.c that includes a set of functions >> using USE_SSL >> 2) Have two files in src/common, one when build is used with OpenSSL, >> and the second one when built-in methods are used >> 3) Disable the use of SCRAM when OpenSSL is not present in the build. >> >> Opinions? My heart goes for 2) because 1) is ugly, and 3) is not >> appealing in terms of flexibility. > > I really dislike #3 - we want everybody to start using this... OK, after hacking that for a bit I have finished with option 2 and the set of PG-like set of routines, the use of USE_SSL in the file containing all the SHA functions of OpenBSD has proved to be really ugly, but with a split things are really clear to the eye. The stuff I got builds on OSX, Linux and MSVC. pgcrypto cannot link directly to libpgcommon.a, so I am making it compile directly with the source files, as it is doing on HEAD. > I'm not sure how common a build without openssl is in the real world though. > RPMs, DEBs, Windows installers etc all build with OpenSSL. But we probably > don't want to make it mandatory, no... I don't think that it is this much common to have an enterprise-class build of Postgres without SSL, but each company has always its own reasons, so things could exist. And I continue to move on... Thanks for the feedback. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
