public inbox for [email protected]
help / color / mirror / Atom feedFrom: Marcos Magueta <[email protected]>
To: Kirill Reshke <[email protected]>
Cc: [email protected]
Subject: Re: WIP - xmlvalidate implementation from TODO list
Date: Wed, 31 Dec 2025 17:26:55 -0300
Message-ID: <CAN3aFCcx_w5Ldb+SYurwd31es9hOJqLuKARQHHDOk7+5iOqBWQ@mail.gmail.com> (raw)
In-Reply-To: <CAN3aFCfvVgXr77o=dB_E2kSCY+EgckSQbSBdd_N9n-LauWuQLw@mail.gmail.com>
References: <CAN3aFCdx8AapWSVpJ1kaC7OC_v7QwbjgbGw9WfPBBY2GMyOadQ@mail.gmail.com>
<CALdSSPjxLU+zhWx+CgwN+VHoHTso33trY6mse1A6Jks7hWAdrA@mail.gmail.com>
<CAN3aFCesNDiL-iZg4imC0n+NgT3JywqZYkuGH83u8ssLjJ-p5Q@mail.gmail.com>
<CAN3aFCfvVgXr77o=dB_E2kSCY+EgckSQbSBdd_N9n-LauWuQLw@mail.gmail.com>
Hello again!
Is there any interest in this? I understand PostgreSQL has bigger fish to
fry, but I would like to at least know; in case this was just forgotten.
Regards!
Em sex., 19 de dez. de 2025 às 00:25, Marcos Magueta <
[email protected]> escreveu:
> Hello again!
>
> I took some time to actually finish this feature. I think the answers
> for the previous questions are now clearer. I checked the
> initialization and the protections are indeed in place since commit
> a4b0c0aaf093a015bebe83a24c183e10a66c8c39, which specifically states:
>
> > Prevent access to external files/URLs via XML entity references.
>
> > xml_parse() would attempt to fetch external files or URLs as needed to
> > resolve DTD and entity references in an XML value, thus allowing
> > unprivileged database users to attempt to fetch data with the privileges
> > of the database server. While the external data wouldn't get returned
> > directly to the user, portions of it could be exposed in error messages
> > if the data didn't parse as valid XML; and in any case the mere ability
> > to check existence of a file might be useful to an attacker.
> >
> > The ideal solution to this would still allow fetching of references that
> > are listed in the host system's XML catalogs, so that documents can be
> > validated according to installed DTDs. However, doing that with the
> > available libxml2 APIs appears complex and error-prone, so we're not
> going
> > to risk it in a security patch that necessarily hasn't gotten wide
> review.
> > So this patch merely shuts off all access, causing any external fetch to
> > silently expand to an empty string. A future patch may improve this.
>
> With that, the obvious affordance on the xmlvalidate implementation
> was to not rely on external schema sources on the host
> catalog. Therefore the implementation relies solely on expressions
> that necessarily evaluate to a schema in plain text.
>
> I added the requested documentation and a bunch of tests for each
> scenario. I would appreciate another round of reviews whenever someone
> has the time and patience.
>
> At last, to nourish the curiosity: I had issues with make check, as
> stated above on the e-mail thread. These got resolved when I changed
> `execl` to `execlp` on `pg_regress.c`. I of course did not commit
> such, but more people I know have had the very same issue while
> relying on immutable package managers.
>
view thread (16+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: WIP - xmlvalidate implementation from TODO list
In-Reply-To: <CAN3aFCcx_w5Ldb+SYurwd31es9hOJqLuKARQHHDOk7+5iOqBWQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox