ds,
-Roberto
--
Roberto C. Sánchez
7;t in the future
either.
My thinking was "ask once, bump the thread once after 2 or 3 weeks just
in case it got lost in the noise (this is a busy list), and after that
let the matter rest if there is no answer".
Regards,
-Roberto
--
Roberto C. Sánchez
h is no longer actively supported" or "no longer
actively supported, and we do not want questions/discussions about it on
this list".
If the latter, then I will document this to ensure that we respect this
boundary.
Regards,
-Roberto
--
Roberto C. Sánchez
issues (and data integrity bugs), then we would
simply be using those. However, given the age of those releases, it is
understandable that such releases are no longer being made.
Regards,
-Roberto
--
Roberto C. Sánchez
so 73c9f91a1b6d by the way, which is a follow up
> of 5a2fed911a85 for CVE-2024-10978 related to parallel workers, it
> would not apply to 9.4, for sure.
>
Definitely. That was relatively straightforward to figure out and
confirm.
Thanks for the hints.
Regards,
-Roberto
--
Roberto C. Sánchez
Hi Bruce,
On Mon, Dec 30, 2024 at 04:58:26PM -0500, Bruce Momjian wrote:
> On Mon, Dec 30, 2024 at 04:50:12PM -0500, Roberto C. Sánchez wrote:
> > On Sat, Dec 14, 2024 at 09:50:23PM -0500, Roberto C. Sánchez wrote:
> > > Greetings pgsql devs,
> > >
> > &g
On Sat, Dec 14, 2024 at 09:50:23PM -0500, Roberto C. Sánchez wrote:
> Greetings pgsql devs,
>
> I would appreciate a review of my strategy for backporting the commits
> related to CVE-2024-10978. (I am working with versions 11, 9.6, and 9.4,
> for some older Debian releases.)
>
Is it then correct to conclude the behavior which regressed in 9.6 and
newer as a result of 4c9d96f74ba4e7d01c086ca54f217e242dd65fae was
introduced after 9.4? And that hence in the case of backporting to 9.4
that c463338656ac47e5210fcf9fbf7d20efccce8de8 can be left out?
Regards,
-Roberto
--
Roberto C. Sánchez
on of where to look for the failure!
Regards,
-Roberto
--
Roberto C. Sánchez
to
> touch @@>>, since there's no COMMUTATOR clause in the extension.
>
I understand your reticence to dive into a branch that is long dead from
your perspective. That said, I am grateful for the insights you
provided here.
> It'd likely be a good idea to reproduce this with a gdb breakpoint
> set at errfinish, and see exactly what's leading up to the error.
>
Thanks for this suggestion. I will see if I am able to isolate the
precise cause of the failure with this.
Regards,
-Roberto
--
Roberto C. Sánchez
.)
If the apparently buggy behavior is not a sufficient guard, then is a
backport of c94959d4110a1965472956cfd631082a96f64a84 in conjunction with
the CVE-2022-2625 fix the correct solution?
Regards,
-Roberto
--
Roberto C. Sánchez
Hello pgsql-hackers,
Is there anyone willing to review the patches that I prepared? I'd have
substatntially more confidence in the patches with a review from an
upstream developer who is familiar with the code.
Regards,
-Roberto
On Mon, Jul 04, 2022 at 06:06:58PM -0400, Roberto C. Sá
On Wed, Jun 08, 2022 at 05:31:22PM -0400, Roberto C. Sánchez wrote:
> On Wed, Jun 08, 2022 at 04:15:47PM -0400, Tom Lane wrote:
> > Roberto =?iso-8859-1?Q?C=2E_S=E1nchez?= writes:
> > > I am investigating backporting the fixes for CVE-2022-1552 to 9.6 and
> > > 9.
e
>
Thanks for the pointer.
> We're going to have to tweak that code somehow, and it's not yet
> entirely clear how.
>
I will monitor the discussion to see what comes of it.
Regards,
-Roberto
--
Roberto C. Sánchez
vulnerability in both 9.6 and 9.4. However, the SUSE
security information page for CVE-2022-1552 [0] lists 9.6 as "not
affected". Presumably this is based on the language in the upstream
advisory "Versions Affected: 10 - 14."
[0] https://www.suse.com/security/cve/CVE-2022-1552.html
--
15 matches
Mail list logo
