On Fri, Apr 12, 2024 at 09:00:11AM -0700, Andres Freund wrote:
> I'm actually fairly bothered by us linking to libxml2. It was effectively
> unmaintained for most of the last decade, with just very occasional drive-by
> commits. And it's not that there weren't significant bugs or such. Maintenance
Hi,
On 2024-04-04 01:10:20 +0200, Peter Eisentraut wrote:
> On 03.04.24 23:19, Magnus Hagander wrote:
> > When the code is this simple, we should definitely consider carrying it
> > ourselves. At least if we don't expect to need *other* functionality
> > from the same library in the future, which
On Thu, Apr 4, 2024 at 1:10 AM Peter Eisentraut
wrote:
> On 03.04.24 23:19, Magnus Hagander wrote:
> > When the code is this simple, we should definitely consider carrying it
> > ourselves. At least if we don't expect to need *other* functionality
> > from the same library in the future, which I
On 4/8/24 22:57, Bruce Momjian wrote:
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
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
On Fri, Apr 5, 2024 at 5:14 PM Michael Paquier wrote:
> Saying that, my spidey sense tingles at the recent commit
> 3311ea86edc7, that had the idea to introduce a 20k line output file
> based on a 378 line input file full of random URLs. In my experience,
> tests don't require to be that large to
Hi,
> There are many more interesting and scary libraries in the dependency
> tree of "postgres", so just picking off one right now doesn't really
> accomplish anything. The next release of libsystemd will drop all
> the compression libraries as hard dependencies, so the issue in that
> sense is
Hi,
Sorry, without any connection with the technical part of the thread.
But I couldn't help but record this, and congratulate Andres Freund, for
the excellent work.
It's not every day that a big press, in Brazil or around the world,
publishes something related to technology people.
Today I came
On Fri, Apr 05, 2024 at 11:40:46AM -0700, Jacob Champion wrote:
> On Fri, Apr 5, 2024 at 6:24 AM Robert Haas wrote:
>> 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 b
On Fri, Apr 5, 2024 at 6:24 AM Robert Haas 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 c
On Thu, Apr 4, 2024 at 4:48 PM Daniel Gustafsson wrote:
> AFAIK we haven't historically enforced that installations have the openssl
> binary in PATH, but it would be a pretty low bar to add. The bigger issue is
> likely to find someone to port this to Windows, it probably won't be too hard
> but
Jelte Fennema-Nio writes:
> Okay turns out even generating them in parallel isn't any faster than
> running that sequentially. I guess it's because of the strong random
> generation being the slow part. Command I used was the following and
> took ~5 seconds on my machine:
> make -C src/test/ssl s
On Thu, 4 Apr 2024 at 23:06, Daniel Gustafsson wrote:
>
> > On 4 Apr 2024, at 23:02, Jelte Fennema-Nio wrote:
>
> > How about we make it meson/make targets, so they are simply cached
> > just like any of our other build artefacts are cached. Then only clean
> > builds are impacted, not every test
Jelte Fennema-Nio writes:
> How about we make it meson/make targets, so they are simply cached
> just like any of our other build artefacts are cached. Then only clean
> builds are impacted, not every test run.
Every buildfarm and CI run is "clean" in those terms.
regards
> On 4 Apr 2024, at 23:02, Jelte Fennema-Nio wrote:
> How about we make it meson/make targets, so they are simply cached
> just like any of our other build artefacts are cached. Then only clean
> builds are impacted, not every test run.
They already are (well, make not meson yet), they're just n
On Thu, 4 Apr 2024 at 22:56, Daniel Gustafsson wrote:
>
> > On 4 Apr 2024, at 22:47, Tom Lane wrote:
> >
> > Robert Haas writes:
> >> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
> >>> I don't disagree, like I said that very email: it's non-trivial and I
> >>> wish we
> >>> could ma
>
> 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
On Thu, Apr 4, 2024 at 10:56:01PM +0200, Daniel Gustafsson wrote:
> > On 4 Apr 2024, at 22:47, Tom Lane wrote:
> >
> > Robert Haas writes:
> >> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
> >>> I don't disagree, like I said that very email: it's non-trivial and I
> >>> wish we
> >
> On 4 Apr 2024, at 22:47, Tom Lane wrote:
>
> Robert Haas writes:
>> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
>>> 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.
>
>
> On 4 Apr 2024, at 22:40, Robert Haas wrote:
>
> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
>> 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.
>
> Is the basic issue that we
Robert Haas writes:
> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
>> 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.
> Is the basic issue that we can't rely on the necessary too
On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
> 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.
Is the basic issue that we can't rely on the necessary toolchain to be
present on eve
> On 4 Apr 2024, at 21:38, Robert Haas 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 t
On Wed, Apr 3, 2024 at 3:42 PM Daniel Gustafsson 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,
On 03.04.24 23:19, Magnus Hagander wrote:
When the code is this simple, we should definitely consider carrying it
ourselves. At least if we don't expect to need *other* functionality
from the same library in the future, which I doubt we will from libsystemd.
Well, I've long had it on my list t
Hi,
On 2024-04-03 17:58:55 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Apr 3, 2024 at 7:57 PM Andres Freund wrote:
> >> Openssh has now integrated [1] a patch to remove the dependency on
> >> libsystemd
> >> for triggering service manager readyness notifications, by inlining the
Magnus Hagander writes:
> On Wed, Apr 3, 2024 at 7:57 PM Andres Freund wrote:
>> 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 pret
On Wed, Apr 3, 2024 at 7:57 PM Andres Freund wrote:
> 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
> On 3 Apr 2024, at 20:09, Peter Eisentraut 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
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 inspect
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 depende
On 2024-03-31 Su 17:12, Andres Freund wrote:
Hi,
On 2024-03-31 12:18:29 +0200, Michael Banck wrote:
If you ask where they are maintained, the answer is here:
https://salsa.debian.org/postgresql/postgresql/-/tree/17/debian/patches?ref_type=heads
the other major versions have their own branch
Bruce Momjian writes:
> On Mon, Apr 1, 2024 at 03:17:55PM -0400, Tom Lane wrote:
>> AFAIK, every open-source distro makes all the pieces needed to
>> rebuild their packages available to users. It wouldn't be much
>> of an open-source situation otherwise. You do have to learn
>> their package bu
On Mon, Apr 1, 2024 at 03:17:55PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I was more asking if users have access to patches so they could recreate
> > the build by using the Postgres git tree and supplied OS-specific
> > patches.
>
> AFAIK, every open-source distro makes all the piece
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
Bruce Momjian writes:
> I was more asking if users have access to patches so they could recreate
> the build by using the Postgres git tree and supplied OS-specific
> patches.
AFAIK, every open-source distro makes all the pieces needed to
rebuild their packages available to users. It wouldn't be
On Sun, Mar 31, 2024 at 02:12:57PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-03-31 12:18:29 +0200, Michael Banck wrote:
> > If you ask where they are maintained, the answer is here:
> >
> > https://salsa.debian.org/postgresql/postgresql/-/tree/17/debian/patches?ref_type=heads
> >
> > the other
On Apr 1, 2024, at 06:55, walt...@technowledgy.de wrote:
> Also a configurable directoy to look up extensions, possibly even to be
> changed at run-time like [2]. The patch says this:
>
>> This directory is prepended to paths when loading extensions (control and
>> SQL files), and to the '$libd
I looked through the repositories of 19 linux distros [1] to see what
kind of patches are applied often. Many of them share the same package
managers / repositories and thus the same patches. I made sure to look
at some smaller, "other" distros as well, to see what kind of problems
appear outsi
Hi,
On 2024-03-31 12:18:29 +0200, Michael Banck wrote:
> If you ask where they are maintained, the answer is here:
>
> https://salsa.debian.org/postgresql/postgresql/-/tree/17/debian/patches?ref_type=heads
>
> the other major versions have their own branch.
Luckily these are all quite small, leav
Michael Banck writes:
> On Sun, Mar 31, 2024 at 01:05:40PM -0400, Joe Conway wrote:
>> But it has always bothered me how many patches get applied to the upstream
>> tarballs by the OS package builders.
> I think this more an artifact of how RHEL development works, i.e. trying
> to ship the same m
Hi,
On Sun, Mar 31, 2024 at 01:05:40PM -0400, Joe Conway wrote:
> But it has always bothered me how many patches get applied to the upstream
> tarballs by the OS package builders. Some of them, e.g. glibc on RHEL 7,
> include more than 1000 patches that you would have to manually vet if you
> care
On 3/31/24 11:49, Tom Lane wrote:
Joe Conway writes:
I am saying maybe those patches should be eliminated in favor of our
tree including build options that would produce the same result.
I don't really see how that can be expected to work sanely.
It turns the responsibility for platform-speci
Hi,
On Sat, 2024-03-30 at 21:52 -0400, Bruce Momjian wrote:
> How would someone access the out-of-tree patches?
Here are the v17 patches:
https://git.postgresql.org/gitweb/?p=pgrpms.git;a=tree;f=rpm/redhat/main/non-common/postgresql-17/main
You can replace -17 with -16 (and etc) for the other
Joe Conway writes:
> I am saying maybe those patches should be eliminated in favor of our
> tree including build options that would produce the same result.
I don't really see how that can be expected to work sanely.
It turns the responsibility for platform-specific build issues
on its head, and
Hi,
On Sun, 2024-03-31 at 08:15 -0400, Joe Conway wrote:
>
> I am saying maybe those patches should be eliminated in favor of our
> tree including build options that would produce the same result.
Works for me, as a long as I can commit them and upcoming potential
patches to PostgreSQL git repo
On 3/30/24 21:52, Bruce Momjian wrote:
On Sat, Mar 30, 2024 at 07:54:00PM -0400, Joe Conway wrote:
Virtually every RPM source, including ours, contains out of tree patches
that get applied on top of the release tarball. At least for the PGDG
packages, it would be nice to integrate them into our
On Sat, Mar 30, 2024 at 09:52:47PM -0400, Bruce Momjian wrote:
> On Sat, Mar 30, 2024 at 07:54:00PM -0400, Joe Conway wrote:
> > Virtually every RPM source, including ours, contains out of tree patches
> > that get applied on top of the release tarball. At least for the PGDG
> > packages, it would
On Sat, Mar 30, 2024 at 07:54:00PM -0400, Joe Conway wrote:
> Virtually every RPM source, including ours, contains out of tree patches
> that get applied on top of the release tarball. At least for the PGDG
> packages, it would be nice to integrate them into our git repo as build
> options or whate
Joe Conway writes:
> On 3/30/24 19:54, Joe Conway wrote:
>> Tom follows this, at least last time I checked:
>> https://wiki.postgresql.org/wiki/Release_process
> Reading through that, I wonder if this part is true anymore:
>In principle this could be done anywhere, but again there's a concer
On 3/30/24 19:54, Joe Conway wrote:
On 2024-03-30 16:50:26 -0400, Robert Haas wrote:
or what Tom does when he builds the release tarballs.
Tom follows this, at least last time I checked:
https://wiki.postgresql.org/wiki/Release_process
Reading through that, I wonder if this part is true any
On 3/30/24 17:12, Andres Freund wrote:
Hi,
On 2024-03-30 16:50:26 -0400, Robert Haas wrote:
We might also want to move toward signing commits and tags. One of the
meson maintainers was recommending that on-list not long ago.
I don't know how valuable the commit signing really is, but I strong
On Sat, Mar 30, 2024 at 04:50:26PM -0400, Robert Haas wrote:
> On Fri, Mar 29, 2024 at 7:00 PM Andres Freund 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 com
Hi,
On 2024-03-30 16:50:26 -0400, Robert Haas wrote:
> We might also want to move toward signing commits and tags. One of the
> meson maintainers was recommending that on-list not long ago.
I don't know how valuable the commit signing really is, but I strongly agree
that we should sign both tags
On Fri, Mar 29, 2024 at 7:00 PM Andres Freund 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
Daniel Gustafsson writes:
> 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.
IMO that's a hard, no-exceptions requirement just for
maintainability's sake, never mind security risks.
> On 29 Mar 2024, at 23:59, Andres Freund 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 s
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
On Sat, Mar 30, 2024 at 11:37 AM 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 o
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/
60 matches
Mail list logo
