From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Michael Banck <mbanck@gmx.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: Volker Aßmann <volker.assmann@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Disabling trust/ident authentication configure option
Date: Wed, 20 May 2015 19:31:58 -0300
Message-ID: <20150520223158.GL5885@postgresql.org> (raw)
In-Reply-To: <20150520221704.GA11196@raptor.chemicalconnection.dyndns.org>
References: <WM!3b761876ad683334d7afacc13949867067da229b8b4a89a6384ebd101a9ce056b35e6732803f2295acef5787aadcb6e2!@asav-1.01.com>
<55596375.7070601@agliodbs.com>
<CAJBpAdzUeVqJ1R+0V_Eg8+Z0HdrHYq7HHx+a4q1BT9-h9Yvoiw@mail.gmail.com>
<CB1A1AB6-B345-4ED7-A705-D87E4DC99E11@gmail.com>
<CAJBpAdzH3pMTFfBE+dYd+OytVJXR2XF=ESQ7TG6syjB1suh2ZQ@mail.gmail.com>
<WM!22b0c9d0d605588edea2c700c71c4e0b51033b37a1185be38d4160d6de08c76eba51fd2754a9d1446b4cfb3fccceb9ce!@asav-2.01.com>
<555CC5DE.3050707@agliodbs.com>
<20150520175916.GB5885@postgresql.org>
<23809.1432145430@sss.pgh.pa.us>
<20150520221704.GA11196@raptor.chemicalconnection.dyndns.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Michael Banck wrote:
> On Wed, May 20, 2015 at 02:10:30PM -0400, Tom Lane wrote:
> > One reason why it would not be, if it's a build-time decision,
> > is that it's quite unlikely that any popular packagers would build
> > that way. So this would only be applicable to custom-built binaries,
> > which is a pretty small class of users to begin with.
>
> There might be appliance vendors who ship PostgreSQL along with their
> product. Then, they decide they want to use the pristine tarballs for
> reproducibility and accountability. If done right, they could publish
> their set of configure options and a build-id or whatever, and 3rd
> parties could verify the binaries they ship have not been tampered
> with[1]. Granted, they could also just publish the patch for those 3rd
> parties to apply as well, but that sounds slightly inelegant.
I don't think you can mix "elegance" and "appliance vendor" in the same
sentence with a straight face, so while I agree that in theory this
might be true, in reality this functionality would seldom be used for
this.
> The other set of users I could think of are those who, for whatever
> reason, tend to always compile PostgreSQL from source for their
> company/organization. Maybe they have internal rules that requires a
> custom installation prefix for all their servers or whatever. Due to
> procedural requirements, or just the unwillingness to carry deltas, they
> absolutely want to use the pristine tarballs as well but would be very
> happy to get rid of some of the authentication methods.
Right. That's the set of users that Josh B says is only comprised of
Volker (the OP).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, mbanck@gmx.net, tgl@sss.pgh.pa.us, josh@agliodbs.com, volker.assmann@gmail.com, robertmhaas@gmail.com, sfrost@snowman.net, andrew@dunslane.net
Subject: Re: Disabling trust/ident authentication configure option
In-Reply-To: <20150520223158.GL5885@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox