Re: [HACKERS] FIPS mode?
To utilize openssl FIPS, you have to explicitly enable it, per the FIPS user guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf So, my target would be redhat/centos where openssl FIPS is certified/available, and then add a configuration parameter to enable it (much like Apache HTTPD's SSLFIPS directive: http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslfips). On Sat, Jun 24, 2017 at 1:51 AM Tom Lane wrote: > Michael Paquier writes: > > On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck > > wrote: > >> If I clean this up some, maintain styleguide, what is the likely hood of > >> getting this included in the redhat packages, since redhat ships a > certified > >> FIPS implementation? > > > So they are applying a custom patch to it already? > > Don't believe so. It's been a few years since I was at Red Hat, but > my recollection is that their approach was that it was a system-wide > configuration choice changing libc's behavior, and there were only very > minor fixes required to PG's behavior, all of which got propagated > upstream (see, eg, commit 01824385a). It sounds like Curtis is trying > to enable FIPS mode inside Postgres within a system where it isn't enabled > globally, which according to my recollection has basically nothing to do > with complying with the actual federal security standard. > > regards, tom lane >
[HACKERS] FIPS mode?
I've got a requirement for enabling FIPS support in our environment. Looking at postgresql's be-secure-openssl.c and mucking with it, it seems fairly straight forward to just add a few ifdefs and enable fips with a new configure flag and a new postgresql.conf configuration setting. If I clean this up some, maintain styleguide, what is the likely hood of getting this included in the redhat packages, since redhat ships a certified FIPS implementation? For what its worth, I've got the FIPS_mode_set(1) working and postgresql seems to function properly. I'd just like to see this in upstream so I don't end up maintaining a long-lived branch. Looking at scope, logically it seems mostly confined to libpq, and be-secure-openssl.c, though i'd expect pgcrypto to be affected.
Re: [HACKERS] PostgreSQL Auditing
Robert, This isn't wrong. I don't see anyone else trying to submit anything in reference to auditing. Just because there have been multiple implementations in the past, based on commit histories, there have only been a few that tried getting into core or contrib (that i can find in mailing list history). Currently, in 9.6, there is one version that is trying to make it in. If Crunchy, or 2nd Quadrant, tried to get their versions incorporated we would have a disagreement in implementation, but either they are lying in wait, or they passively concur, by not actively disagreeing. I think if there was a valid commit path laid out for getting auditing into core, or into contrib at least, most users would probably find that sufficient. But it seems that every time someone tries to incorporate auditing, there are countless and varied reasons to deny its inclusion. David Steele's version of auditing builds on most of the prior pgaudit code and incorporates a large amount of the feedback from 9.5's attempt. I'm opening to testing and evaluating to see if it meets our compliance requirements, but I am no where close to being a C developer, or having C developers that could actually provide a meaningful review. One issue along this thread already pops up, concerning the client_min_messages, and how other patches in the pipeline for 9.6 would be required to enable the auditing to meet compliance requirements. It just seems after reading the mailing list history, that there is a lack of interest by people with commit authority, even though there is a decent interest in it from the community, and honestly, no one really likes auditing, but its one of those damned if you do (in performance) and damned if you don't (in legal) things. Additionally Robert, given your professional status, you are by no means an unbiased contributor in this discussion. Your stance on this matter shows that you don't necessarily want the open source solution to succeed in the commercial/compliance required space. Instead of arguing blankly against inclusion can you at least provide actionable based feedback that if met would allow patches of this magnitude in? I'm personally fine with fiscally rewarding organizations that assist my customer in succeeding, but its hard to convince my customer to fund open source, even though they wouldn't be able to do 75% of what they do without it. Based on past experience this is the same most open source organizations face, especially when they don't have the marketing engine that the large commercial players have. Curtis … On Tue, Feb 2, 2016 at 5:23 PM Robert Haas wrote: > On Tue, Feb 2, 2016 at 5:16 PM, David Steele wrote: > > This sort of confusion is one of the main reasons I pursued inclusion in > > core. > > But that's exactly wrong. When there is not agreement on one code > base over another, that's the time it is most important not to pick > one of them arbitrarily privilege it over the others. The *only* time > it's appropriate to move something that could just as well as an > extension into core is when (1) we think it's highly likely that users > will want that particular thing rather than some other thing and (2) > we think it's worth the burden of maintaining that code forever. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [HACKERS] PostgreSQL Auditing
Its not available in rpm or premade binary forms in its current instantiation, not a big deal for me, but it raises the barrier to entry. If it was packaged into an RPM, what would be the process to get it added to postgresql's yum repositories? February 2 2016 10:24 AM, "Joshua D. Drake" wrote: > On 02/02/2016 02:47 AM, José Luis Tallón wrote: > >> On 02/02/2016 02:05 AM, Curtis Ruck wrote: >>> [snip] >>> >>> P.S., do you know what sucks, having a highly performant PostGIS >>> database that works great, and being told to move to Oracle or SQL >>> Server (because they have auditing). Even though they charge extra >>> for Geospatial support (seriously?) or when they don't even have >>> geospatial support (10 years ago). My customer would prefer to >>> re-engineer software designed around PostgreSQL and pay the overpriced >>> licenses, than not have auditing. I agree that their cost analysis is >>> probably way off, even 10 years later, my only solution would be to >>> move to Oracle, SQL Server, a NoSQL solution, or pay EnterpriseDB for >>> their 2 year old version that doesn't have all the cool/modern jsonb >>> support. > > PostgreSQL has auditing. It is available now, just not in core. Postgis isn't > available in core > either and it seems to do just fine. > > JD > > -- Command Prompt, Inc. http://the.postgres.company > +1-503-667-4564 > PostgreSQL Centered full stack support, consulting and development. > Everyone appreciates your honesty, until you are honest with them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PostgreSQL Auditing
So Auditing, it seems that some people want auditing (myself, David Steele, 2nd quadrant, and probably others). I personally love postgresql, but until it can meet my annoying compliance requirements, I can't leverage it fully as my organization spends more time on meeting compliance, than actually doing development and engineering. Sadly, due to the incumbent solutions in the database arena, we are also wasting idiotic amounts of time, money, and increasing system complexity because we are having to use alternative solutions that provide things like auditing. If David's auditing patch isn't sufficient, what is? Are we waiting on the holy grail of auditing, which implements an entirely new logging subsystem, and hooks so deeply into the innards of PostgreSQL its perfect? Does this mailing list just not care about the potential customers (and potential financial benefits) of providing a complete database solution? Or does the postgresql community just want to stay a hobbyist database that never broaches the enterprise or compliance arenas? I've worked with many database vendors, and honestly auditing is fairly bland, its boring, and no one really likes it except for the lawyers, and then only when someone was actually caught doing something wrong, which lets face it is quite infrequent given the number of databases that exist out there. Just because auditing isn't sexy sharding, parallel partitioning, creative indexing (BRIN), or hundreds of thousands of transactions a second, doesn't make it any less of a requirement to countless organizations that would like to use postgresql, but find the audit requirement a must have. So, in summary, what would it take to get the core PostgreSQL team to actually let auditing patches into the next version? P.S., do you know what sucks, having a highly performant PostGIS database that works great, and being told to move to Oracle or SQL Server (because they have auditing). Even though they charge extra for Geospatial support (seriously?) or when they don't even have geospatial support (10 years ago). My customer would prefer to re-engineer software designed around PostgreSQL and pay the overpriced licenses, than not have auditing. I agree that their cost analysis is probably way off, even 10 years later, my only solution would be to move to Oracle, SQL Server, a NoSQL solution, or pay EnterpriseDB for their 2 year old version that doesn't have all the cool/modern jsonb support.