Re: Support for NSS as a libpq TLS backend
От | Robert Haas |
---|---|
Тема | Re: Support for NSS as a libpq TLS backend |
Дата | |
Msg-id | CA+TgmoYu0bU8TyAZfjKHmVytLBUzocyb_jxQur8pd_yVnU=7SQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support for NSS as a libpq TLS backend (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Support for NSS as a libpq TLS backend
|
Список | pgsql-hackers |
On Fri, Feb 4, 2022 at 1:22 PM Bruce Momjian <bruce@momjian.us> wrote: > On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote: > > As a philosophical matter, I don't think it's great for us - or the > > Internet in general - to be too dependent on OpenSSL. Software > > monocultures are not great, and OpenSSL has near-constant security > > updates and mediocre documentation. Now, maybe anything else we > > I don't think it is fair to be criticizing OpenSSL for its mediocre > documentation when the alternative being considered, NSS, has no public > documentation. Can the source-code-defined NSS documentation be > considered better than the mediocre OpenSSL public documentation? I mean, I think it's fair to say that my experiences with trying to use the OpenSSL documentation have been poor. Admittedly it's been a few years now so maybe it's gotten better, but my experience was what it was. In one case, the function I needed wasn't documented at all, and I had to read the C code, which was weirdly-formatted and had no comments. That wasn't fun, and knowing that NSS could be an even worse experience doesn't retroactively turn that into a good one. > For the record, I do like the idea of adding NSS, but I am concerned > about its long-term maintenance, we you explained. It sounds like we come down in about the same place here, in the end. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: