public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v7 7/7] pg_dump: partitioned index depend on its partitions
14+ messages / 7 participants
[nested] [flat]
* [PATCH v7 7/7] pg_dump: partitioned index depend on its partitions
@ 2020-11-25 23:34 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Justin Pryzby @ 2020-11-25 23:34 UTC (permalink / raw)
This is required for restoring clustered parent index, which is marked INVALID
until indexes have been built on all its child tables, and it's prohibited to
CLUSTER ON an INVALID index
See also: 8cff4f5348d075e063100071013f00a900c32b0f
---
src/backend/commands/tablecmds.c | 6 +++---
src/bin/pg_dump/common.c | 8 ++++++++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 420991e315..a478c13990 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -17521,6 +17521,9 @@ validatePartitionedIndex(Relation partedIdx, Relation partedTbl)
table_close(idxRel, RowExclusiveLock);
}
+ /* make sure we see the validation we just did */
+ CommandCounterIncrement();
+
/*
* If this index is in turn a partition of a larger index, validating it
* might cause the parent to become valid also. Try that.
@@ -17532,9 +17535,6 @@ validatePartitionedIndex(Relation partedIdx, Relation partedTbl)
Relation parentIdx,
parentTbl;
- /* make sure we see the validation we just did */
- CommandCounterIncrement();
-
parentIdxId = get_partition_parent(RelationGetRelid(partedIdx));
parentTblId = get_partition_parent(RelationGetRelid(partedTbl));
parentIdx = relation_open(parentIdxId, AccessExclusiveLock);
diff --git a/src/bin/pg_dump/common.c b/src/bin/pg_dump/common.c
index 1a261a5545..cdfba058fc 100644
--- a/src/bin/pg_dump/common.c
+++ b/src/bin/pg_dump/common.c
@@ -429,6 +429,12 @@ flagInhIndexes(Archive *fout, TableInfo tblinfo[], int numTables)
attachinfo[k].parentIdx = parentidx;
attachinfo[k].partitionIdx = index;
+ /*
+ * We want dependencies from parent to partition (so that the
+ * partition index is created first)
+ */
+ addObjectDependency(&parentidx->dobj, index->dobj.dumpId);
+
/*
* We must state the DO_INDEX_ATTACH object's dependencies
* explicitly, since it will not match anything in pg_depend.
@@ -446,6 +452,8 @@ flagInhIndexes(Archive *fout, TableInfo tblinfo[], int numTables)
*/
addObjectDependency(&attachinfo[k].dobj, index->dobj.dumpId);
addObjectDependency(&attachinfo[k].dobj, parentidx->dobj.dumpId);
+ // addObjectDependency(&parentidx->dobj, attachinfo[k].dobj.dumpId);
+
addObjectDependency(&attachinfo[k].dobj,
index->indextable->dobj.dumpId);
addObjectDependency(&attachinfo[k].dobj,
--
2.17.0
--AA9g+nFNFPYNJKiL--
^ permalink raw reply [nested|flat] 14+ messages in thread
* Security lessons from liblzma
@ 2024-03-29 22:37 Bruce Momjian <[email protected]>
0 siblings, 4 replies; 14+ messages in thread
From: Bruce Momjian @ 2024-03-29 22:37 UTC (permalink / raw)
To: pgsql-hackers
You might have seen reports today about a very complex exploit added to
recent versions of liblzma. Fortunately, it was only enabled two months
ago and has not been pushed to most stable operating systems like Debian
and Ubuntu. The original detection report is:
https://www.openwall.com/lists/oss-security/2024/03/29/4
And this ycombinator discussion has details:
https://news.ycombinator.com/item?id=39865810
It looks like an earlier commit with a binary blob "test data"
contained the bulk of the backdoor, then the configure script
enabled it, and then later commits patched up valgrind errors
caused by the backdoor. See the commit links in the "Compromised
Repository" section.
and I think the configure came in through the autoconf output file
'configure', not configure.ac:
This is my main take-away from this. We must stop using upstream
configure and other "binary" scripts. Delete them all and run
"autoreconf -fi" to recreate them. (Debian already does something
like this I think.)
Now, we don't take pull requests, and all our committers are known
individuals, but this might have cautionary lessons for us.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-03-29 22:48 Thomas Munro <[email protected]>
parent: Bruce Momjian <[email protected]>
3 siblings, 0 replies; 14+ messages in thread
From: Thomas Munro @ 2024-03-29 22:48 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers
On Sat, Mar 30, 2024 at 11:37 AM Bruce Momjian <[email protected]> wrote:
> You might have seen reports today about a very complex exploit added to
> recent versions of liblzma. Fortunately, it was only enabled two months
> ago and has not been pushed to most stable operating systems like Debian
> and Ubuntu. The original detection report is:
>
> https://www.openwall.com/lists/oss-security/2024/03/29/4
Incredible work from Andres. The attackers made a serious strategic
mistake: they made PostgreSQL slightly slower.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-03-29 22:59 Andres Freund <[email protected]>
parent: Bruce Momjian <[email protected]>
3 siblings, 2 replies; 14+ messages in thread
From: Andres Freund @ 2024-03-29 22:59 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers
Hi,
On 2024-03-29 18:37:24 -0400, Bruce Momjian wrote:
> You might have seen reports today about a very complex exploit added to
> recent versions of liblzma. Fortunately, it was only enabled two months
> ago and has not been pushed to most stable operating systems like Debian
> and Ubuntu. The original detection report is:
>
> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> And this ycombinator discussion has details:
>
> https://news.ycombinator.com/item?id=39865810
>
> It looks like an earlier commit with a binary blob "test data"
> contained the bulk of the backdoor, then the configure script
> enabled it, and then later commits patched up valgrind errors
> caused by the backdoor. See the commit links in the "Compromised
> Repository" section.
>
> and I think the configure came in through the autoconf output file
> 'configure', not configure.ac:
>
> This is my main take-away from this. We must stop using upstream
> configure and other "binary" scripts. Delete them all and run
> "autoreconf -fi" to recreate them. (Debian already does something
> like this I think.)
I don't think that's a useful lesson here, actually. In this case, if you ran
autoreconf -fi in a released tarball, it'd just recreate precisely what
the tarball already contained, including the exploit.
I think the issue in this case rather was that the tarball contains files that
are not in the release - a lot of them. The attackers injected the
'activating' part of the backdoor into the release tarball, while it was not
present in the git tree. They did that because they knew that distributions
often build from release tarballs.
If the release pre-backdoor release tarball had been identical to the git
repository, this would likely have been noticed by packagers - but it was
normal for there to be a lot of new files.
We traditionally had also a lot of generated files in the tarball that weren't
in our git tree - but we removed a lot of that a few months ago, when we
stopped including bison/flex/other generated code.
We still include generated docs, but that's much harder to exploit at
scale. However, they still make it harder to verify that the release is
exactly the same as the git tree.
> Now, we don't take pull requests, and all our committers are known
> individuals, but this might have cautionary lessons for us.
I am doubtful that every committer would find something sneaky hidden in
e.g. one of the test changes in a large commit. It's not too hard to hide
something sneaky. I comparison to that hiding something in configure.ac seems
less likely to succeed IMO, that imo tends to be more scrutinized. And hiding
just in configure directly wouldn't get you far, it'd just get removed when
the committer or some other committer at a later time, regenerates configure.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-03-29 23:14 Daniel Gustafsson <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 1 reply; 14+ messages in thread
From: Daniel Gustafsson @ 2024-03-29 23:14 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers
> On 29 Mar 2024, at 23:59, Andres Freund <[email protected]> wrote:
> On 2024-03-29 18:37:24 -0400, Bruce Momjian wrote:
>> Now, we don't take pull requests, and all our committers are known
>> individuals, but this might have cautionary lessons for us.
>
> I am doubtful that every committer would find something sneaky hidden in
> e.g. one of the test changes in a large commit. It's not too hard to hide
> something sneaky.
One take-away for me is how important it is to ship recipes for regenerating
any testdata which is included in generated/compiled/binary format. Kind of
how we in our tree ship the config for test TLS certificates and keys which can
be manually inspected, and used to rebuild the testdata (although the risk for
injections in this particular case seems low). Bad things can still be
injected, but formats which allow manual review at least goes some way towards
lowering risk.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-03-30 20:50 Robert Haas <[email protected]>
parent: Andres Freund <[email protected]>
1 sibling, 2 replies; 14+ messages in thread
From: Robert Haas @ 2024-03-30 20:50 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers
On Fri, Mar 29, 2024 at 7:00 PM Andres Freund <[email protected]> wrote:
> I am doubtful that every committer would find something sneaky hidden in
> e.g. one of the test changes in a large commit. It's not too hard to hide
> something sneaky. I comparison to that hiding something in configure.ac seems
> less likely to succeed IMO, that imo tends to be more scrutinized. And hiding
> just in configure directly wouldn't get you far, it'd just get removed when
> the committer or some other committer at a later time, regenerates configure.
I agree with this. If I were trying to get away with a malicious
commit, I'd look for files that other people would be unlikely to
examine closely, or would have difficulty examining closely. Test data
or test scripts seem like great possibilities. And I also would like
it to be part of some relatively large commit that is annoying to read
through visually. We don't have a lot of binary format files in the
tree, which is good, but there's probably some things like Unicode
tables and ECPG expected output files that very, very few people ever
actually examine. If we had a file in the tree that looked based on
the name like an expected output file for a test, but there was no
corresponding test, how many of us would notice that? How many of us
would scrutinize it? Imagine hiding something bad in the middle of
that file somewhere.
Maybe we need some kind of tool that scores files for risk. Longer
files are riskier. Binary files are riskier, as are text files that
are something other than plain English/C code/SGML. Files that haven't
changed in a long time are not risky, but files with few recent
changes are riskier than files with many recent changes, especially if
only 1 or 2 committers made all of those changes, and especially if
those commits also touched a lot of other files. Of course, if we had
a tool like this that were public, I suppose anyone targeting PG would
look at the tool and try to find ways around its heuristics. But maybe
we should have something and not disclose the whole algorithm
publicly, or even if we do disclose it all, having something is
probably better than having nothing. It might force a hypothetical bad
actor to do things that would be more likely to be noticed by the
humans.
We might also want to move toward signing commits and tags. One of the
meson maintainers was recommending that on-list not long ago.
We should think about weaknesses that might occur during the packaging
process, too. If someone who alleges that their packaging PG is really
packaging PG w/badstuff123.patch, how would we catch that?
An awful lot of what we do operates on the principle that we know the
people who are involved and trust them, and I'm glad we do trust them,
but the world is full of people who trusted somebody too much and
regretted it afterwards. The fact that we have many committers rather
than a single maintainer probably reduces risk at least as far as the
source repository is concerned, because there are more people paying
attention to potentially notice something that isn't as it should be.
But it's also more potential points of compromise, and a lot of things
outside of that repository are not easy to audit. I can't for example
verify what the infrastructure team is doing, or what Tom does when he
builds the release tarballs. It seems like a stretch to imagine
someone taking over Tom's online identity while simultaneously
rendering him incommunicado ... but at the same time, the people
behind this attack obviously put a lot of work into it and had a lot
of resources available to craft the attack. We shouldn't make the
mistake of assuming that bad things can't happen to us.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-03-30 23:22 Bruce Momjian <[email protected]>
parent: Robert Haas <[email protected]>
1 sibling, 0 replies; 14+ messages in thread
From: Bruce Momjian @ 2024-03-30 23:22 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Andres Freund <[email protected]>; pgsql-hackers
On Sat, Mar 30, 2024 at 04:50:26PM -0400, Robert Haas wrote:
> On Fri, Mar 29, 2024 at 7:00 PM Andres Freund <[email protected]> wrote:
> > I am doubtful that every committer would find something sneaky hidden in
> > e.g. one of the test changes in a large commit. It's not too hard to hide
> > something sneaky. I comparison to that hiding something in configure.ac seems
> > less likely to succeed IMO, that imo tends to be more scrutinized. And hiding
> > just in configure directly wouldn't get you far, it'd just get removed when
> > the committer or some other committer at a later time, regenerates configure.
>
> I agree with this. If I were trying to get away with a malicious
> commit, I'd look for files that other people would be unlikely to
> examine closely, or would have difficulty examining closely. Test data
> or test scripts seem like great possibilities. And I also would like
> it to be part of some relatively large commit that is annoying to read
> through visually. We don't have a lot of binary format files in the
> tree, which is good, but there's probably some things like Unicode
> tables and ECPG expected output files that very, very few people ever
> actually examine. If we had a file in the tree that looked based on
> the name like an expected output file for a test, but there was no
> corresponding test, how many of us would notice that? How many of us
> would scrutinize it? Imagine hiding something bad in the middle of
> that file somewhere.
So, in this case, the hooks were in 'configure', but not configure.ac,
and the exploit was in a test file which was in the tarball but _not_ in
the git tree. So, they used the obfuscation of 'configure's syntax, and
the lack of git oversight by not putting the test files in the git tree.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-04-01 20:58 Bruce Momjian <[email protected]>
parent: Bruce Momjian <[email protected]>
3 siblings, 0 replies; 14+ messages in thread
From: Bruce Momjian @ 2024-04-01 20:58 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Andres Freund <[email protected]>
On Fri, Mar 29, 2024 at 06:37:24PM -0400, Bruce Momjian wrote:
> You might have seen reports today about a very complex exploit added to
> recent versions of liblzma. Fortunately, it was only enabled two months
> ago and has not been pushed to most stable operating systems like Debian
> and Ubuntu. The original detection report is:
>
> https://www.openwall.com/lists/oss-security/2024/03/29/4
I was watching this video about the exploit:
https://www.youtube.com/watch?v=bS9em7Bg0iU
and at 2:29, they mention "hero software developer", our own Andres
Freund as the person who discovered the exploit. I noticed the author's
name at the openwall email link above, but I assumed it was someone else
with the same name. They mentioned it was found while researching
Postgres performance, and then I noticed the email address matched!
I thought the analogy he uses at the end of the video is very clear.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma - libsystemd
@ 2024-04-03 17:57 Andres Freund <[email protected]>
parent: Bruce Momjian <[email protected]>
3 siblings, 0 replies; 14+ messages in thread
From: Andres Freund @ 2024-04-03 17:57 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers
Hi,
As most will know by now, the way xz debacle was able to make sshd vulnerable
was through a dependency from sshd to libsystemd and then from libsystemd to
liblzma. One lesson from this is that unnecessary dependencies can still
increase risk.
It's worth noting that we have an optional dependency on libsystemd as well.
Openssh has now integrated [1] a patch to remove the dependency on libsystemd
for triggering service manager readyness notifications, by inlining the
necessary function. That's not hard, the protocol is pretty simple.
I suspect we should do the same. We're not even close to being a target as
attractive as openssh, but still, it seems unnecessary.
Intro into the protocol is at [2], with real content and outline of the
relevant code at [3].
An argument could be made to instead just remove support, but I think it's
quite valuable to have intra service dependencies that can rely on the server
actually having started up.
Greetings,
Andres Freund
[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2641
[2] https://www.freedesktop.org/software/systemd/man/devel/systemd.html#Readiness%20Protocol
[3] https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-04-03 18:09 Peter Eisentraut <[email protected]>
parent: Daniel Gustafsson <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Peter Eisentraut @ 2024-04-03 18:09 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; Andres Freund <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers
On 30.03.24 00:14, Daniel Gustafsson wrote:
> One take-away for me is how important it is to ship recipes for regenerating
> any testdata which is included in generated/compiled/binary format. Kind of
> how we in our tree ship the config for test TLS certificates and keys which can
> be manually inspected, and used to rebuild the testdata (although the risk for
> injections in this particular case seems low). Bad things can still be
> injected, but formats which allow manual review at least goes some way towards
> lowering risk.
I actually find the situation with the test TLS files quite
unsatisfactory. While we have build rules, the output files are not
reproducible, both because of some inherent randomness in the
generation, and because different OpenSSL versions produce different
details. So you just have to "trust" that what's there now makes sense.
Of course, you can use openssl tools to unpack these files, but that
is difficult and unreliable unless you know exactly what you are looking
for. Also, for example, do we even know whether all the files that are
there now are even used by any tests?
A few years ago, some guy on the internet sent in a purported update to
one of the files [0], which I ended up committing, but I remember that
that situation gave me quite some pause at the time.
It would be better if we created the required test files as part of the
test run. (Why not? Too slow?) Alternatively, I have been thinking
that maybe we could make the output more reproducible by messing with
whatever random seed OpenSSL uses. Or maybe use a Python library to
create the files. Some things to think about.
[0]:
https://www.postgresql.org/message-id/FEF81714-D479-4512-839B-C769D2605F8A%40yesql.se
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-04-03 19:42 Daniel Gustafsson <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Gustafsson @ 2024-04-03 19:42 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Andres Freund <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers
> On 3 Apr 2024, at 20:09, Peter Eisentraut <[email protected]> wrote:
>
> On 30.03.24 00:14, Daniel Gustafsson wrote:
>> One take-away for me is how important it is to ship recipes for regenerating
>> any testdata which is included in generated/compiled/binary format. Kind of
>> how we in our tree ship the config for test TLS certificates and keys which can
>> be manually inspected, and used to rebuild the testdata (although the risk for
>> injections in this particular case seems low). Bad things can still be
>> injected, but formats which allow manual review at least goes some way towards
>> lowering risk.
>
> I actually find the situation with the test TLS files quite unsatisfactory. While we have build rules, the output files are not reproducible, both because of some inherent randomness in the generation, and because different OpenSSL versions produce different details.
This testdata is by nature not reproducible, and twisting arms to make it so
will only result in testing against synthetic data which risk hiding bugs IMO.
> So you just have to "trust" that what's there now makes sense.
Not entirely, you can review the input files which are used to generate the
test data and verify that those make sense..
> Of course, you can use openssl tools to unpack these files, but that is difficult and unreliable unless you know exactly what you are looking for.
..and check like you mention above, but it's as you say not entirely trivial. It
would be nice to improve this but I'm not sure how. Document how to inspect
the data in src/test/ssl/README perhaps?
> It would be better if we created the required test files as part of the test run. (Why not? Too slow?)
The make sslfiles step requires OpenSSL 1.1.1, which is higher than what we
require to be installed to build postgres. The higher-than-base requirement is
due to it building test data only used when running 1.1.1 or higher, so
technically it could be made to work if anyone is interesting in investing time
in 1.0.2.
Time is one aspect, on my crusty old laptop it takes ~2 seconds to regenerate
the files. That in itself isn't that much, but we've rejected test-time
additions far less than that. We could however make CI and the Buildfarm run
the regeneration and leave it up to each developer to decide locally? Or
remove them and regenerate on the first SSL test run and then use the cached
ones after that?
On top of time I have a feeling the regeneration won't run on Windows. When
it's converted to use Meson then that might be fixed though.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-04-04 19:38 Robert Haas <[email protected]>
parent: Daniel Gustafsson <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Robert Haas @ 2024-04-04 19:38 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers
On Wed, Apr 3, 2024 at 3:42 PM Daniel Gustafsson <[email protected]> wrote:
> > So you just have to "trust" that what's there now makes sense.
>
> Not entirely, you can review the input files which are used to generate the
> test data and verify that those make sense..
Yeah, I mean, in theory I suppose that's true, but look at this commit:
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=6e636819e8f070330d835fce46289a3ff72a7b89
In case the link stops working for some reason, the commit message is
as follows:
JT> Tests: Update two test files.
JT>
JT> The original files were generated with random local to my machine.
JT> To better reproduce these files in the future, a constant seed was used
JT> to recreate these files.
Essentially, your argument is the same as his, namely: hey, don't
worry, you could totally verify these test files if you wanted to! But
of course, nobody did, because it was hard, and everybody had better
things to do with their time. And I think the same thing is probably
true here: nobody really is going to verify much about these files.
I just went and ran openssl x509 -in $f -text on each .crt file and it
worked, so all of those files look basically like certificates. But
like, hypothetically, how do I know that the modulus chosen for a
particular certificate was chosen at random, rather than maliciously?
Similarly for the key files. Are there padding bytes in any of these
files that could be used to store evil information? I don't know that,
either. I'm not sure how far it's worth continuing down this path of
paranoia; I doubt that Daniel Gustafsson is a clever alias for a
nefarious cabal of state-sponsored hackers, and the hypotheses that
supposedly-random values were chosen non-randomly borders on
unfalsifiable. Nonetheless, I think Peter is correct to point out that
these are the kinds of files about which it is reasonable to be
concerned, because they seem to have properties quite similar to those
of the files used in an actual attack.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-04-04 20:25 Daniel Gustafsson <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Daniel Gustafsson @ 2024-04-04 20:25 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Bruce Momjian <[email protected]>; pgsql-hackers
> On 4 Apr 2024, at 21:38, Robert Haas <[email protected]> wrote:
> Essentially, your argument is the same as his, namely: hey, don't
> worry, you could totally verify these test files if you wanted to! But
> of course, nobody did, because it was hard, and everybody had better
> things to do with their time. And I think the same thing is probably
> true here: nobody really is going to verify much about these files.
I don't disagree, like I said that very email: it's non-trivial and I wish we
could make it better somehow, but I don't hav an abundance of good ideas.
Removing the generated versions and creating them when running tests makes
sneaking in malicious content harder since it then has to be submitted in
clear-text *only*. The emphasis added since it's like that today as well: *I*
fully trust our team of committers to not accept a binary file in a patch
without replacing with a regenerated version, but enforcing it might make it
easier for a wider community to share that level of trust?
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Security lessons from liblzma
@ 2024-04-09 02:57 Bruce Momjian <[email protected]>
parent: Robert Haas <[email protected]>
1 sibling, 0 replies; 14+ messages in thread
From: Bruce Momjian @ 2024-04-09 02:57 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Andres Freund <[email protected]>; pgsql-hackers
On Sat, Mar 30, 2024 at 04:50:26PM -0400, Robert Haas wrote:
> An awful lot of what we do operates on the principle that we know the
> people who are involved and trust them, and I'm glad we do trust them,
> but the world is full of people who trusted somebody too much and
> regretted it afterwards. The fact that we have many committers rather
> than a single maintainer probably reduces risk at least as far as the
> source repository is concerned, because there are more people paying
> attention to potentially notice something that isn't as it should be.
One unwritten requirement for committers is that we are able to
communicate with them securely. If we cannot do that, they potentially
could be forced by others, e.g., governments, to add code to our
repositories.
Unfortunately, there is on good way for them to communicate with us
securely once they are unable to communicate with us securely. I
suppose some special word could be used to communicate that status ---
that is how it was done in non-electronic communication in the past.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2024-04-09 02:57 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-11-25 23:34 [PATCH v7 7/7] pg_dump: partitioned index depend on its partitions Justin Pryzby <[email protected]>
2024-03-29 22:37 Security lessons from liblzma Bruce Momjian <[email protected]>
2024-03-29 22:48 ` Re: Security lessons from liblzma Thomas Munro <[email protected]>
2024-03-29 22:59 ` Re: Security lessons from liblzma Andres Freund <[email protected]>
2024-03-29 23:14 ` Re: Security lessons from liblzma Daniel Gustafsson <[email protected]>
2024-04-03 18:09 ` Re: Security lessons from liblzma Peter Eisentraut <[email protected]>
2024-04-03 19:42 ` Re: Security lessons from liblzma Daniel Gustafsson <[email protected]>
2024-04-04 19:38 ` Re: Security lessons from liblzma Robert Haas <[email protected]>
2024-04-04 20:25 ` Re: Security lessons from liblzma Daniel Gustafsson <[email protected]>
2024-03-30 20:50 ` Re: Security lessons from liblzma Robert Haas <[email protected]>
2024-03-30 23:22 ` Re: Security lessons from liblzma Bruce Momjian <[email protected]>
2024-04-09 02:57 ` Re: Security lessons from liblzma Bruce Momjian <[email protected]>
2024-04-01 20:58 ` Re: Security lessons from liblzma Bruce Momjian <[email protected]>
2024-04-03 17:57 ` Re: Security lessons from liblzma - libsystemd Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox