On Tue, Apr 15, 2025 at 11:57 AM Christoph Berg <m...@debian.org> wrote:
> What made me reconsider was Peter saying that what defines the blast
> radius of some feature is usually the extra dependency pulled in. If
> you don't like tracking OpenSSL problems, build without it. If you
> don't like libcurl, build without it. That's the "we are going to be
> hated by security scanner people" argument that brought up this
> sub-thread.
>
> Now if the feature itself were a problem, that might change how
> configuration should be working. Is "libpq can now initiate oauth
> requests" something people would like to be able to control?
Well... I'd sure like to live in a world where users thought about the
implications and risks of what they're using and why, rather than
farming a decision out to a static analysis tool. ("And as long as I'm
dreaming, I'd like a pony.")
But end users already control the initiation of OAuth requests (it's
opt-in via the connection string), so that's not really the goal.
> Debian does not care really about static libs. We are currently
> shipping libpq.a, but if it breaks in any funny way, we might as well
> remove it.
Awesome. I think we have a consensus.
Thanks!
--Jacob
