From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Security lessons from liblzma |
Date: | 2024-04-05 18:40:46 |
Message-ID: | CAOYmi+kXxqZ29rFvGK54SgwjAyxb_DHkDkBONdEpvUMDJZ5nUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 5, 2024 at 6:24 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I wonder how hard it would be to just code up our own binary to do
> this. If it'd be a pain to do that, or to maintain it across SSL
> versions, then it's a bad plan and we shouldn't do it. But if it's not
> that much code, maybe it'd be worth considering.
I think my biggest concern, other than the maintenance costs, would be
the statement "we know SSL works on Windows because we test it against
some certificates we hand-rolled ourselves." We can become experts in
certificate formats, of course, but... does it buy us much? If someone
comes and complains that a certificate doesn't work correctly (as they
have *very* recently [3]), I would like to be able to write a test
that uses what OpenSSL actually generates as opposed to learning how
to make it myself first.
> I'm also sort of afraid that we're getting sucked into thinking real
> hard about this SSL certificate issue rather than trying to brainstorm
> all the other places that might be problematic. The latter might be a
> more fruitful exercise (or maybe not, what do I know?).
+1. Don't get me wrong: I spent a lot of time refactoring the sslfiles
machinery a while back, and I would love for it to all go away. I
don't really want to interrupt any lines of thought that are moving in
that direction. Please continue.
_And also:_ the xz attack relied on a long chain of injections, both
technical and social. I'm still wrapping my head around Russ Cox's
writeup [1, 2], but the "hidden blob of junk" is only a single part of
all that. I'm not even sure it was a necessary part; it just happened
to work well for this particular project and line of attack.
I've linked Russ Cox in particular because Golang has made a bunch of
language-level decisions with the supply chain in mind, including the
philosophy that a build should ideally not be able to run arbitrary
code at all, and therefore generated files _must_ be checked in. I
remember $OLDJOB having buildbots that would complain if the contents
of the file you checked in didn't match what was (reproducibly!)
generated. I think there's a lot more to think about here.
--Jacob
[1] https://research.swtch.com/xz-timeline
[2] https://research.swtch.com/xz-script
[3] https://www.postgresql.org/message-id/flat/17760-b6c61e752ec07060%40postgresql.org
From | Date | Subject | |
---|---|---|---|
Next Message | stephane tachoires | 2024-04-05 19:06:03 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Previous Message | Jeff Davis | 2024-04-05 18:22:40 | Re: LogwrtResult contended spinlock |