...a bit less brief you say? Okay. I'm the Director of Cloud Engineering & Growth at Crunchy Data where I help build products that help people use PostgreSQL in "-as-a-Service" environments. Before that, I worked in a few startups in New York (i.e. VenueBook, Paperless Post) where PostgreSQL served as the principal data store. To date I've been primarily focused on application development, though my methodology has been to start from where the data resides, and as such I decided to learn a lot about using PostgreSQL.
I've been using PostgreSQL for over 15 years (though I semi-joke that I've only been using it well for about 8) and have been fortunate that I have been able to use it throughout my professional career!
How do you engage with the PostgreSQL Community?
I've primarily focused on assisting with advocacy efforts around PostgreSQL. I initially started out by helping to organize a local user group in New York as well as conferences, which had mirrored similar efforts to how I participated in student organizations in college. Since then, I've tried to help out in a few different areas of the project.
My favorite thing to work on is the releases, both major, minor, and the sometimes unscheduled ones. Each type of release presents its own challenges, and it's fun (and stressful) to work through them.
Have you enjoyed previous pgconf.eu or FOSDEM conferences, either as an
attendee or as speaker?
Yes. My first PostgreSQL conference ever was PGConf.EU 2009 in Paris, France, where I spoke about balancing the tradeoffs between functionality in object-relational mappers (ORMs) and the advantages built into PostgreSQL. Excluding a few life events, I've been to every PGConf.EU since (and I believe as a speaker?).
What will your talk be about, exactly? Why this topic?
My talk is about passwords: something that is very easy to take for granted. Through the years I have found that an inherent assumption that PostgreSQL users have made is that setting a password provides a means of securing the ability to connect to their database. While this is not an incorrect assumption, there is more to passwords and PostgreSQL than meets the eye.
This is one of the many reasons that lead to PostgreSQL adopting the SCRAM methodology for password validation. SCRAM stands for the "salted challenge response authentication mechanism" with its methodology originally defined in RFC 5802. PostgreSQL supports SCRAM-SHA-256, defined in RFC 7677, which draws heavily from RFC 5802 (basically it updates which hash digest is used).
There are two things that I find really beautiful about PostgreSQL using SCRAM: first, SCRAM allows two parties to verify that each party knows the secret without sharing the secret during verification. This is so cool. The second thing is that PostgreSQL adopted a standard method for password verification, which follows the overall ethos of PostgreSQL itself of adopting and adhering to standards!
What is the audience for your talk?
Everyone! We're going to cover how passwords historically worked in PostgreSQL, learn how SCRAM itself works, and how to both add it to your new PostgreSQL installations and upgrade your old installations.
Even better, all of this will be explained by elephants and hippos. What do I mean by that? I guess you have to see the talk!
What existing knowledge should the attendee have?
It would help if you have logged into a PostgreSQL server before, but otherwise we are going to start from the beginning.
What is the one feature in PostgreSQL 12 which you like most?
Much like last year when I was asked this about PostgreSQL 11, one of my roles in the community is to help support the release process: picking a favorite feature is not fair to all of the wonderful features added to PostgreSQL 12 through the hard work of many, many people!
However, I will pick an under-the-radar feature that I think could be very impactful on people looking to further secure authentication into their environments. PostgreSQL 12 added the ability to add "clientcert=verify-full" to the pg_hba.conf file, e.g. something like "hostssl all all 0.0.0.0/0 scram-sha-256 clientcert=verify-full" (and note I don't advocate opening up your database to the entire Internet). What this line says is that someone who is authenticating must provide a valid certificate that matches their authentication username (in the certificate's CN field) that was signed by the certificate authority (CA) that this PostgreSQL server trusts AND a valid password (using SCRAM no less!).
In other words, PostgreSQL 12 now supports a form of multi-factor authentication!
Which other talk at this year's conference would you like to see?
All of them! The schedule looks packed with great content, as always. I'll also be hovering around the hallway track quite a bit, so happy to meet and talk to people there!
Which measure, action, feature or activity would—in your
eyes—help to accelerate the adoption of PostgreSQL?
We are at the point in PostgreSQL were "brand awareness" is not the primary issue: it's rare these days where I have a "What's PostgreSQL?" conversation with an experienced technologist. Now it is a matter of understanding both what features users need that will help them to choose PostgreSQL over another database as well as ensuring our ways for helping people to get started (installers, documentation, etc.) are as simple as possible.
I think it is also good to look at what other database systems are doing, learn what people like about these other database systems, and adopt features appropriately into PostgreSQL and its surrounding ecosystem. Of course, we should continue to innovate the way the community has always done, but it is also good to understand why people enjoy working with certain features of a particular software.