Re: [PoC] Federated Authn/z with OAUTHBEARER
От | Jacob Champion |
---|---|
Тема | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Дата | |
Msg-id | CAOYmi+kbbzODePf=mS+L_vTuU16z7iCjrbBZyosQA-D=tvhT9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PoC] Federated Authn/z with OAUTHBEARER (Christoph Berg <myon@debian.org>) |
Список | pgsql-hackers |
On Tue, Apr 15, 2025 at 11:57 AM Christoph Berg <myon@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
В списке pgsql-hackers по дате отправления: