summaryrefslogtreecommitdiff
path: root/src/interfaces/libpq
AgeCommit message (Collapse)Author
2020-10-18Update the Winsock API version requested by libpq.Tom Lane
According to Microsoft's documentation, 2.2 has been the current version since Windows 98 or so. Moreover, that's what the Postgres backend has been requesting since 2004 (cf commit 4cdf51e64). So there seems no reason for libpq to keep asking for 1.1. Bring thread_test along, too, so that we're uniformly asking for 2.2 in all our WSAStartup calls. It's not clear whether there's any point in back-patching this, so for now I didn't. Discussion: https://postgr.es/m/132799.1602960277@sss.pgh.pa.us
2020-10-17In libpq for Windows, call WSAStartup once and WSACleanup not at all.Tom Lane
The Windows documentation insists that every WSAStartup call should have a matching WSACleanup call. However, if that ever had actual relevance, it wasn't in this century. Every remotely-modern Windows kernel is capable of cleaning up when a process exits without doing that, and must be so to avoid resource leaks in case of a process crash. Moreover, Postgres backends have done WSAStartup without WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any indication of a problem with that. libpq's habit of doing WSAStartup during connection start and WSACleanup during shutdown is also rather inefficient, since a series of non-overlapping connection requests leads to repeated, quite expensive DLL unload/reload cycles. We document a workaround for that (having the application call WSAStartup for itself), but that's just a kluge. It's also worth noting that it's far from uncommon for applications to exit without doing PQfinish, and we've not heard reports of trouble from that either. However, the real reason for acting on this is that recent experiments by Alexander Lakhin suggest that calling WSACleanup during PQfinish might be triggering the symptom we occasionally see that a process using libpq fails to emit expected stdio output. Therefore, let's change libpq so that it calls WSAStartup only once per process, during the first connection attempt, and never calls WSACleanup at all. While at it, get rid of the only other WSACleanup call in our code tree, in pg_dump/parallel.c; that presumably is equally useless. If this proves to suppress the fairly-common ecpg test failures we see on Windows, I'll back-patch, but for now let's just do it in HEAD and see what happens. Discussion: https://postgr.es/m/ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru
2020-10-15Replace calls of htonl()/ntohl() with pg_bswap.h for GSSAPI encryptionMichael Paquier
The in-core equivalents can make use of built-in functions if the compiler supports this option, making optimizations possible. 0ba99c8 replaced all existing calls in the code base at this time, but b0b39f7 (GSSAPI encryption) has forgotten to do the switch. Discussion: https://postgr.es/m/20201014055303.GG3349@paquier.xyz
2020-10-10Recognize network-failure errnos as indicating hard connection loss.Tom Lane
Up to now, only ECONNRESET (and EPIPE, in most but not quite all places) received special treatment in our error handling logic. This patch changes things so that related error codes such as ECONNABORTED are also recognized as indicating that the connection's dead and unlikely to come back. We continue to think, however, that only ECONNRESET and EPIPE should be reported as probable server crashes; the other cases indicate network connectivity problems but prove little about the server's state. Thus, there's no change in the error message texts that are output for such cases. The key practical effect is that errcode_for_socket_access() will report ERRCODE_CONNECTION_FAILURE rather than ERRCODE_INTERNAL_ERROR for a network failure. It's expected that this will fix buildfarm member lorikeet's failures since commit 32a9c0bdf, as that seems to be due to not treating ECONNABORTED equivalently to ECONNRESET. The set of errnos treated this way now includes ECONNABORTED, EHOSTDOWN, EHOSTUNREACH, ENETDOWN, ENETRESET, and ENETUNREACH. Several of these were second-class citizens in terms of their handling in places like get_errno_symbol(), so upgrade the infrastructure where necessary. As committed, this patch assumes that all these symbols are defined everywhere. POSIX specifies all of them except EHOSTDOWN, but that seems to exist on all platforms of interest; we'll see what the buildfarm says about that. Probably this should be back-patched, but let's see what the buildfarm thinks of it first. Fujii Masao and Tom Lane Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us
2020-09-22Remove arbitrary line length limit for libpq service files.Tom Lane
Use a StringInfo instead of a fixed-size buffer in parseServiceInfo(). While we've not heard complaints about the existing 255-byte limit, it certainly seems possible that complex cases could run afoul of it. Daniel Gustafsson Discussion: https://postgr.es/m/48A4FA71-524E-41B9-953A-FD04EF36E2E7@yesql.se
2020-09-10Add libpq's openssl dependencies to pkg-config filePeter Eisentraut
Add libssl and libcrypto to libpq.pc's Requires.private. This allows static linking to work if those libssl or libcrypto themselves have dependencies in their *.private fields, such as -lz in some cases. Reported-by: Sandro Mani <manisandro@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/837d1dcf-2fca-ee6e-0d7e-6bce1a1bac75@gmail.com
2020-09-01Teach libpq to handle arbitrary-length lines in .pgpass files.Tom Lane
Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
2020-07-13Fix bugs in libpq's management of GSS encryption state.Tom Lane
GSS-related resources should be cleaned up in pqDropConnection, not freePGconn, else the wrong things happen when resetting a connection or trying to switch to a different server. It's also critical to reset conn->gssenc there. During connection setup, initialize conn->try_gss at the correct place, else switching to a different server won't work right. Remove now-redundant cleanup of GSS resources around one (and, for some reason, only one) pqDropConnection call in connectDBStart. Per report from Kyotaro Horiguchi that psql would freeze up, rather than successfully resetting a GSS-encrypted connection after a server restart. This is YA oversight in commit b0b39f72b, so back-patch to v12. Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota.ntt@gmail.com
2020-06-29Mop up some no-longer-necessary hacks around printf %.*s format.Tom Lane
Commit 54cd4f045 added some kluges to work around an old glibc bug, namely that %.*s could misbehave if glibc thought any characters in the supplied string were incorrectly encoded. Now that we use our own snprintf.c implementation, we need not worry about that bug (even if it still exists in the wild). Revert a couple of particularly ugly hacks, and remove or improve assorted comments. Note that there can still be encoding-related hazards here: blindly clipping at a fixed length risks producing wrongly-encoded output if the clip splits a multibyte character. However, code that's doing correct multibyte-aware clipping doesn't really need a comment about that, while code that isn't needs an explanation why not, rather than a red-herring comment about an obsolete bug. Discussion: https://postgr.es/m/279428.1593373684@sss.pgh.pa.us
2020-06-27Fix list of SSL error codes for older OpenSSL versions.Tom Lane
Apparently 1.0.1 lacks SSL_R_VERSION_TOO_HIGH and SSL_R_VERSION_TOO_LOW. Per buildfarm.
2020-06-27Add hints about protocol-version-related SSL connection failures.Tom Lane
OpenSSL's native reports about problems related to protocol version restrictions are pretty opaque and inconsistent. When we get an SSL error that is plausibly due to this, emit a hint message that includes the range of SSL protocol versions we (think we) are allowing. This should at least get the user thinking in the right direction to resolve the problem, even if the hint isn't totally accurate, which it might not be for assorted reasons. Back-patch to v13 where we increased the default minimum protocol version, thereby increasing the risk of this class of failure. Patch by me, reviewed by Daniel Gustafsson Discussion: https://postgr.es/m/a9408304-4381-a5af-d259-e55d349ae4ce@2ndquadrant.com
2020-06-27Change libpq's default ssl_min_protocol_version to TLSv1.2.Tom Lane
When we initially created this parameter, in commit ff8ca5fad, we left the default as "allow any protocol version" on grounds of backwards compatibility. However, that's inconsistent with the backend's default since b1abfec82; protocol versions prior to 1.2 are not considered very secure; and OpenSSL has had TLSv1.2 support since 2012, so the number of PG servers that need a lesser minimum is probably quite small. On top of those things, it emerges that some popular distros (including Debian and RHEL) set MinProtocol=TLSv1.2 in openssl.cnf. Thus, far from having "allow any protocol version" behavior in practice, what we actually have as things stand is a platform-dependent lower limit. So, change our minds and set the min version to TLSv1.2. Anybody wanting to connect with a new libpq to a pre-2012 server can either set ssl_min_protocol_version=TLSv1 or accept the fallback to non-SSL. Back-patch to v13 where the aforementioned patches appeared. Patch by me, reviewed by Daniel Gustafsson Discussion: https://postgr.es/m/a9408304-4381-a5af-d259-e55d349ae4ce@2ndquadrant.com
2020-06-15Error message refactoringPeter Eisentraut
Take some untranslatable things out of the message and replace by format placeholders, to reduce translatable strings and reduce translation mistakes.
2020-06-07Try to read data from the socket in pqSendSome's write_failed paths.Tom Lane
Even when we've concluded that we have a hard write failure on the socket, we should continue to try to read data. This gives us an opportunity to collect any final error message that the backend might have sent before closing the connection; moreover it is the job of pqReadData not pqSendSome to close the socket once EOF is detected. Due to an oversight in 1f39a1c06, pqSendSome failed to try to collect data in the case where we'd already set write_failed. The problem was masked for ordinary query operations (which really only make one write attempt anyway), but COPY to the server would continue to send data indefinitely after a mid-COPY connection loss. Hence, add pqReadData calls into the paths where pqSendSome drops data because of write_failed. If we've lost the connection, this will eventually result in closing the socket and setting CONNECTION_BAD, which will cause PQputline and siblings to report failure, allowing the application to terminate the COPY sooner. (Basically this restores what happened before 1f39a1c06.) There are related issues that this does not solve; for example, if the backend sends an error but doesn't drop the connection, we did and still will keep pumping COPY data as long as the application sends it. Fixing that will require application-visible behavior changes though, and anyway it's an ancient behavior that we've had few complaints about. For now I'm just trying to fix the regression from 1f39a1c06. Per a complaint from Andres Freund. Back-patch into v12 where 1f39a1c06 came in. Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
2020-05-26Message wording tweaksPeter Eisentraut
Make the wording of new libpq messages more similar to existing messages in the backend.
2020-05-21Clear some style deviations.Noah Misch
2020-05-21Use explicit_bzero() when clearing sslpassword in libpqMichael Paquier
Since 74a308c, any security-sensitive information gets cleared from memory this way. This was forgotten in 4dc6355. Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/935443BA-D42E-4CE0-B181-1AD79E6DD45A@yesql.se
2020-05-18Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 031ca65d7825c3e539a3e62ea9d6630af12e6b6b
2020-05-16Fix bugs in OpenSSL hook renaming.Tom Lane
libpq's exports.txt was overlooked in commit 36d108761, which the buildfarm is quite unhappy about. Also, I'd gathered that the plan included renaming PQgetSSLKeyPassHook to PQgetSSLKeyPassHook_OpenSSL, but that didn't happen in the patch as committed. I'm taking it on my own authority to do so now, since the window before beta1 is closing fast.
2020-05-16Rename PQsetSSLKeyPassHook and friendsAndrew Dunstan
4dc6355210 provided a way for libraries and clients to modify how libpq handles client certificate passphrases, by installing a hook. However, these routines are quite specific to how OpenSSL works, so it's misleading and not future-proof to have these names not refer to OpenSSL. Change all the names to add "_OpenSSL" after "Hook", and fix the docs accordingly. Author: Daniel Gustafsson Discussion: https://postgr.es/m/981DE552-E399-45C2-9F60-3F0E3770CC61@yesql.se
2020-05-16Run pgindent with new pg_bsd_indent version 2.1.1.Tom Lane
Thomas Munro fixed a longstanding annoyance in pg_bsd_indent, that it would misformat lines containing IsA() macros on the assumption that the IsA() call should be treated like a cast. This improves some other cases involving field/variable names that match typedefs, too. The only places that get worse are a couple of uses of the OpenSSL macro STACK_OF(); we'll gladly take that trade-off. Discussion: https://postgr.es/m/20200114221814.GA19630@alvherre.pgsql
2020-05-14Initial pgindent and pgperltidy run for v13.Tom Lane
Includes some manual cleanup of places that pgindent messed up, most of which weren't per project style anyway. Notably, it seems some people didn't absorb the style rules of commit c9d297751, because there were a bunch of new occurrences of function calls with a newline just after the left paren, all with faulty expectations about how the rest of the call would get indented.
2020-05-14Fix typo in comment on OpenSSL PEM password callback type name.Heikki Linnakangas
The type is called "pem_password_cb", not "pem_passwd_cb". Author: Daniel Gustafsson Discussion: https://www.postgresql.org/message-id/22108CF6-228B-45CF-9CDA-5C5F658DCC22@yesql.se
2020-05-13Dial back -Wimplicit-fallthrough to level 3Alvaro Herrera
The additional pain from level 4 is excessive for the gain. Also revert all the source annotation changes to their original wordings, to avoid back-patching pain. Discussion: https://postgr.es/m/31166.1589378554@sss.pgh.pa.us
2020-05-12Add -Wimplicit-fallthrough to CFLAGS and CXXFLAGSAlvaro Herrera
Use it at level 4, a bit more restrictive than the default level, and tweak our commanding comments to FALLTHROUGH. (However, leave zic.c alone, since it's external code; to avoid the warnings that would appear there, change CFLAGS for that file in the Makefile.) Author: Julien Rouhaud <rjuju123@gmail.com> Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20200412081825.qyo5vwwco3fv4gdo@nol Discussion: https://postgr.es/m/flat/E1fDenm-0000C8-IJ@gemulon.postgresql.org
2020-05-11Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 80d8f54b3c5533ec036404bd3c3b24ff4825d037
2020-05-05Fix severe memory leaks in GSSAPI encryption support.Tom Lane
Both the backend and libpq leaked buffers containing encrypted data to be transmitted, so that the process size would grow roughly as the total amount of data sent. There were also far-less-critical leaks of the same sort in GSSAPI session establishment. Oversight in commit b0b39f72b, which I failed to notice while reviewing the code in 2c0cdc818. Per complaint from pmc@citylink. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200504115649.GA77072@gate.oper.dinoex.org
2020-05-05Fix capitalization of messages, per style guidePeter Eisentraut
2020-05-03Add missing newlines in error messagesPeter Eisentraut
2020-04-30Rename connection parameters to control min/max SSL protocol version in libpqMichael Paquier
The libpq parameters ssl{max|min}protocolversion are renamed to use underscores, to become ssl_{max|min}_protocol_version. The related environment variables still use the names introduced in commit ff8ca5f that added the feature. Per complaint from Peter Eisentraut (this was also mentioned by me in the original patch review but the issue got discarded). Author: Daniel Gustafsson Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com
2020-04-22Fix memory leak in libpq when using sslmode=verify-fullMichael Paquier
Checking if Subject Alternative Names (SANs) from a certificate match with the hostname connected to leaked memory after each lookup done. This is broken since acd08d7 that added support for SANs in SSL certificates, so backpatch down to 9.5. Author: Roman Peshkurov Reviewed-by: Hamid Akhtar, Michael Paquier, David Steele Discussion: https://postgr.es/m/CALLDf-pZ-E3mjxd5=bnHsDu9zHEOnpgPgdnO84E2RuwMCjjyPw@mail.gmail.com Backpatch-through: 9.5
2020-04-17Revert "Only provide new libpq sslpasskey hook for openssl-enabled builds"Andrew Dunstan
This reverts commit 9e24109f1a4e4d8d1d372b004d6a0dd06e673fe7. This caused build errors when building without openssl, and it's simplest just to revert it.
2020-04-17Only provide new libpq sslpasskey hook for openssl-enabled buildsAndrew Dunstan
In commit 4dc6355210 I neglected to put #ifdef USE_OPENSSL around the declarations of the new items. This is remedied here. Per complaint from Daniel Gustafsson.
2020-04-13Use perl warnings pragma consistentlyAndrew Dunstan
We've had a mixture of the warnings pragma, the -w switch on the shebang line, and no warnings at all. This patch removes the -w swicth and add the warnings pragma to all perl sources missing it. It raises the severity of the TestingAndDebugging::RequireUseWarnings perlcritic policy to level 5, so that we catch any future violations. Discussion: https://postgr.es/m/20200412074245.GB623763@rfd.leadboat.com
2020-03-31Allow ecpg to be built stand-alone, allow parallel libpq makeBruce Momjian
This change defines SHLIB_PREREQS for the libpgport dependency, rather than using a makefile rule. This was broken in PG 12. Reported-by: Filip Janus Discussion: https://postgr.es/m/E5Dc85EGUY4wyG8cjAU0qoEdCJxGK_qhW1s9qSuYq9A@mail.gmail.com Author: Dagfinn Ilmari Mannsåker (for libpq) Backpatch-through: 12
2020-03-05Fix issues around .pgpass file.Fujii Masao
This commit fixes the following two issues around .pgpass file. (1) If the length of a line in .pgpass file was larger than 319B, libpq silently treated each 319B in the line as a separate setting line. (2) The document explains that a line beginning with # is treated as a comment in .pgpass. But there was no code doing such special handling. Whether a line begins with # or not, libpq just checked that the first token in the line match with the host. For (1), this commit makes libpq warn if the length of a line is larger than 319B, and throw away the remaining part beginning from 320B position. For (2), this commit changes libpq so that it treats any lines beginning with # as comments. Author: Fujii Masao Reviewed-by: Hamid Akhtar Discussion: https://postgr.es/m/c0f0c01c-fa74-9749-2084-b73882fd5465@oss.nttdata.com
2020-02-02Fix assorted error-cleanup bugs in SSL min/max protocol version code.Tom Lane
The error exits added to initialize_SSL() failed to clean up the partially-built SSL_context, and some of them also leaked the result of SSLerrmessage(). Make them match other error-handling cases in that function. The error exits added to connectOptions2() failed to set conn->status like every other error exit in that function. In passing, make the SSL_get_peer_certificate() error exit look more like all the other calls of SSLerrmessage(). Oversights in commit ff8ca5fad. Coverity whined about leakage of the SSLerrmessage() results; I noted the rest in manual code review.
2020-01-31Allow building without default socket directoryPeter Eisentraut
We have code paths for Unix socket support and no Unix socket support. Now add a third variant: Unix socket support but do not use a Unix socket by default in the client or the server, only if you explicitly specify one. This will be useful when we enable Unix socket support on Windows. To implement this, tweak things so that setting DEFAULT_PGSOCKET_DIR to "" has the desired effect. This mostly already worked like that; only a few places needed to be adjusted. Notably, the reference to DEFAULT_PGSOCKET_DIR in UNIXSOCK_PATH() could be removed because all callers already resolve an empty socket directory setting with a default if appropriate. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/75f72249-8ae6-322a-63df-4fe03eeccb9f@2ndquadrant.com
2020-01-30Clean up newlines following left parenthesesAlvaro Herrera
We used to strategically place newlines after some function call left parentheses to make pgindent move the argument list a few chars to the left, so that the whole line would fit under 80 chars. However, pgindent no longer does that, so the newlines just made the code vertically longer for no reason. Remove those newlines, and reflow some of those lines for some extra naturality. Reviewed-by: Michael Paquier, Tom Lane Discussion: https://postgr.es/m/20200129200401.GA6303@alvherre.pgsql
2020-01-29Fix dispsize for libpq connection parameters channel_binding and gssencmodeMichael Paquier
channel_binding's longest allowed value is not "7", it is actually "8". gssencmode also got that wrong. A similar mistake has been fixed as of f4051e3. Backpatch down to v12, where gssencmode has been introduced. Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20200128053633.GD1552@paquier.xyz Backpatch-through: 12
2020-01-28Add connection parameters to control SSL protocol min/max in libpqMichael Paquier
These two new parameters, named sslminprotocolversion and sslmaxprotocolversion, allow to respectively control the minimum and the maximum version of the SSL protocol used for the SSL connection attempt. The default setting is to allow any version for both the minimum and the maximum bounds, causing libpq to rely on the bounds set by the backend when negotiating the protocol to use for an SSL connection. The bounds are checked when the values are set at the earliest stage possible as this makes the checks independent of any SSL implementation. Author: Daniel Gustafsson Reviewed-by: Michael Paquier, Cary Huang Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se
2020-01-16Move wchar.c and encnames.c to src/common/.Tom Lane
Formerly, various frontend directories symlinked these two sources and then built them locally. That's an ancient, ugly hack, and we now have a much better way: put them into libpgcommon. So do that. (The immediate motivation for this is the prospect of having to introduce still more symlinking if we don't.) This commit moves these two files absolutely verbatim, for ease of reviewing the git history. There's some follow-on work to be done that will modify them a bit. Robert Haas, Tom Lane Discussion: https://postgr.es/m/CA+TgmoYO8oq-iy8E02rD8eX25T-9SmyxKWqqks5OMHxKvGXpXQ@mail.gmail.com
2020-01-15Remove libpq.rc, use win32ver.rc for libpqPeter Eisentraut
For historical reasons, libpq used a separate libpq.rc file for the Windows builds while all other components use a common file win32ver.rc. With a bit of tweaking, the libpq build can also use the win32ver.rc file. This removes a bit of duplicative code. Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/ad505e61-a923-e114-9f38-9867d161073f@2ndquadrant.com
2020-01-11Extensive code review for GSSAPI encryption mechanism.Tom Lane
Fix assorted bugs in handling of non-blocking I/O when using GSSAPI encryption. The encryption layer could return the wrong status information to its caller, resulting in effectively dropping some data (or possibly in aborting a not-broken connection), or in a "livelock" situation where data remains to be sent but the upper layers think transmission is done and just go to sleep. There were multiple small thinkos contributing to that, as well as one big one (failure to think through what to do when a send fails after having already transmitted data). Note that these errors could cause failures whether the client application asked for non-blocking I/O or not, since both libpq and the backend always run things in non-block mode at this level. Also get rid of use of static variables for GSSAPI inside libpq; that's entirely not okay given that multiple connections could be open at once inside a single client process. Also adjust a bunch of random small discrepancies between the frontend and backend versions of the send/receive functions -- except for error handling, they should be identical, and now they are. Also extend the Kerberos TAP tests to exercise cases where nontrivial amounts of data need to be pushed through encryption. Before, those tests didn't provide any useful coverage at all for the cases of interest here. (They still might not, depending on timing, but at least there's a chance.) Per complaint from pmc@citylink and subsequent investigation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200109181822.GA74698@gate.oper.dinoex.org
2020-01-08Improve GSSAPI Encryption startup comment in libpqStephen Frost
The original comment was a bit confusing, pointed out by Alvaro Herrera. Thread: https://postgr.es/m/20191224151520.GA16435%40alvherre.pgsql
2020-01-06Remove support for OpenSSL 0.9.8 and 1.0.0Michael Paquier
Support is out of scope from all the major vendors for these versions (for example RHEL5 uses a version based on 0.9.8, and RHEL6 uses 1.0.1), and it created some extra maintenance work. Upstream has stopped support of 0.9.8 in December 2015 and of 1.0.0 in February 2016. Since b1abfec, note that the default SSL protocol version set with ssl_min_protocol_version is TLSv1.2, whose support was added in OpenSSL 1.0.1, so there is no point to enforce ssl_min_protocol_version to TLSv1 in the SSL tests. Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Tom Lane Discussion: https://postgr.es/m/20191205083252.GE5064@paquier.xyz
2020-01-01Update copyrights for 2020Bruce Momjian
Backpatch-through: update all files in master, backpatch legal files through 9.4
2019-12-20libpq should expose GSS-related parameters even when not implemented.Tom Lane
We realized years ago that it's better for libpq to accept all connection parameters syntactically, even if some are ignored or restricted due to lack of the feature in a particular build. However, that lesson from the SSL support was for some reason never applied to the GSSAPI support. This is causing various buildfarm members to have problems with a test case added by commit 6136e94dc, and it's just a bad idea from a user-experience standpoint anyway, so fix it. While at it, fix some places where parameter-related infrastructure was added with the aid of a dartboard, or perhaps with the aid of the anti-pattern "add new stuff at the end". It should be safe to rearrange the contents of struct pg_conn even in released branches, since that's private to libpq (and we'd have to move some fields in some builds to fix this, anyway). Back-patch to all supported branches. Discussion: https://postgr.es/m/11297.1576868677@sss.pgh.pa.us
2019-12-16Sort out getpeereid() and peer auth handling on WindowsPeter Eisentraut
The getpeereid() uses have so far been protected by HAVE_UNIX_SOCKETS, so they didn't ever care about Windows support. But in anticipation of Unix-domain socket support on Windows, that needs to be handled differently. Windows doesn't support getpeereid() at this time, so we use the existing not-supported code path. We let configure do its usual thing of picking up the replacement from libpgport, instead of the custom overrides that it was doing before. But then Windows doesn't have struct passwd, so this patch sprinkles some additional #ifdef WIN32 around to make it work. This is similar to existing code that deals with this issue. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/5974caea-1267-7708-40f2-6009a9d653b0@2ndquadrant.com
2019-12-07Remove PQsslpassword functionAndrew Dunstan
This partially reverts commit 4dc6355210. The information returned by the function can be obtained by calling PQconninfo(), so the function is redundant.
generated by cgit v1.2.3 (git 2.46.0) at 2025-10-24 18:17:52 +0000