Documentation update
Not sure if this is the correct place to report this, but a colleague and I discovered a problem with the systemd service file as described in the documentation. In the sample, there is a need for a line reading "After=syslogd.target network.target" under the [unit] tag. What we found on Redhat 7.4 was that replica servers were coming up unable to find their primary servers as DNS wasn't quite available yet, but otherwise the server was operational. In any case, we don't think this addition would break anyone's configuration, and the current documentation does not reflect this. -- Jay
I’ve come across what I think is a bug
In the documentation, Under CREATE PUBLICATION under parameters publish (string) This parameter determines which DML operations will be published by the new publication to the subscribers. The value is comma-separated list of operations. The default is to publish all actions, and so the default value for this option is ‘insert, update, delete, truncate’. From what I’ve seen, truncate is not set to published by default. I’m looking at a server now with 4 publications on it, and none has truncate set to true. One of these I created, and I know I didn’t set any values. All the other values are set, but not truncate. I don’t know if this was intentional in the code or an oversight, but documentation is incorrect currently. Also, the line before, beginning with “The value is comma-separated…”, could use a little work as well. Maybe just an “a” between “is” and “comma-separated”. — Jay Sent from my iPad
Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Bruce, In my experience, any client is permitted to connect to FIPS140-2 compliant server. I set this up when I worked at SSA, at management’s request. — Jay Sent from my iPad > On Sep 25, 2020, at 3:13 PM, Bruce Momjian wrote: > > On Fri, Sep 25, 2020 at 03:56:53PM +0900, Michael Paquier wrote: >>> On Fri, Sep 25, 2020 at 01:36:44AM -0400, Tom Lane wrote: >>> Peter Eisentraut writes: However, again, the SCRAM implementation would already appear to fail that requirement because it uses a custom HMAC implementation, and HMAC is listed in FIPS 140-2 as a covered algorithm. >>> >>> Ugh. But is there any available FIPS-approved library code that could be >>> used instead? >> >> That's a good point, and I think that this falls down to use OpenSSL's >> HMAC_* interface for this job when building with OpenSSL: >> https://www.openssl.org/docs/man1.1.1/man3/HMAC.html >> >> Worth noting that these have been deprecated in 3.0.0 as per the >> rather-recent commit dbde472, where they recommend the use of >> EVP_MAC_*() instead. > > Would a FIPS server only be able to talk to a FIPS client, or would our > internal code produce the same output? > > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > The usefulness of a cup is in its emptiness, Bruce Lee > > >
Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
FIPS only specifies which algorithms are approved for use on it. For instance, MD-5 is NOT approved at all under FIPS. I would say any algorithm should produce the same result regardless of where it is run. BTW, on Redhat servers, the first algorithm listed for use with SSH is MD-5. This causes the sshd daemon to abort when FIPS is enabled and that config file has not been edited. So, you can no longer connect with an SSH client as the daemon isn’t running. Ask me how I know this. Sent from my iPad > On Sep 25, 2020, at 3:39 PM, Bruce Momjian wrote: > > On Fri, Sep 25, 2020 at 03:38:22PM -0400, John Scalia wrote: >> Bruce, >> >> In my experience, any client is permitted to connect to FIPS140-2 compliant >> server. I set this up when I worked at SSA, at management’s request. > > My question is whether the hash output would match if using different > code. > > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > The usefulness of a cup is in its emptiness, Bruce Lee >
