On Sun, Dec 14, 2025 at 3:13 AM Jonathan Gonzalez V. <[email protected]> wrote: > > Okay, that's good to know. But I'm still missing how the end user (a > > human) trusts that magic CA within the browser or device they use to > > finish the actual flow? > > More than the end user "trusting" a "magic" CA, it's about what company > will tell you to use a CA
Sure, but my question isn't about the trust model. Just to confirm: you're saying that it's common for enterprise provisioning apps (CrowdStrike et al) to push CAs directly into a browser trust store, but _not_ to the system trust paths? > Totally agree, now I'm thinking the same, it should be a feature > because there's more examples that I've been thinking about that may > require this to be even a bit more flexible, for example, when working > with edge computing, if you want (in the future because now it's not > possible, yet) authenticate a device against PostgreSQL it may require > to have that CA as a encoded string int he variable, not just as a > file, wild thought I know, but it may make sense I think we want to keep these on disk; no reason to run up against resource limits on the environment. > > https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to_feature > > How can we work on that? because of the above it may be required to add > even more possibilities. Not sure what you mean. I think we're working on it now, in this thread? On Sun, Dec 14, 2025 at 3:17 AM Jonathan Gonzalez V. <[email protected]> wrote: > I will for sure try to avoid this kind of format with comma separated > options, this mainly because are really hard to parse and manage in an > automated way I feel _very_ strongly that the "debug" options are for people. Specifically developers who are debugging. What use case do you have for automation and parsing outside of libpq? > and sometimes, are hard to read when there's too many > options, and at some point, there could be many options since the flows > can start getting really complicated. Can you explain more about what kinds of use cases would lead to option explosion? When I'm developing I typically want to export an interesting group of options once, and then not think about it for a while. When debugging in production I typically want one particular thing at a time. > Why not keep something with debug levels? Even if it sounds really > classic, for parsing reasons are really good. I would say: because there's no natural order to the settings. It's a bunch of on/off behaviors, some of which are safety-critical. What is the "debug level" of disabling encryption compared to the debug level of printing secrets or turning off parameter validation? --Jacob
