Re: Problema en correos generados con pgmail

Excerpts from angel Iracheta's message of mié feb 16 03:52:07 -0300 2011:

> 3. Estos correos estaban mostrándose perfectamente hasta el día lunes 7 de
> febrero, porque los correos enviados el día de ayer lunes 14 de febrero,
> ya no mostraban correctamente la información, al revisar el código fuente de
> los correos en outlook (Office 2007) que generó la función,
> me doy cuenta de que al código html le aparecen brincos aleatoriamente, por
> ejemplo:

Hmm, quizás tenga relación con este cambio:

commit 7203065dc90e3919c4a0d625e79928a813190146
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Thu Sep 30 17:21:30 2010 -0400

Use a separate interpreter for each calling SQL userid in plperl and pltcl.

There are numerous methods by which a Perl or Tcl function can subvert
the behavior of another such function executed later; for example, by
redefining standard functions or operators called by the target function.
If the target function is SECURITY DEFINER, or is called by such a
function, this means that any ordinary SQL user with Perl or Tcl language
usage rights can do essentially anything with the privileges of the target
function's owner.

To close this security hole, create a separate Perl or Tcl interpreter for
each SQL userid under which plperl or pltcl functions are executed within
a session. However, all plperlu or pltclu functions run within a session
still share a single interpreter, since they all execute at the trust
level of a database superuser anyway.

Note: this change results in a functionality loss when libperl has been
built without the "multiplicity" option: it's no longer possible to call
plperl functions under different userids in one session, since such a
libperl can't support multiple interpreters in one process. However, such
a libperl already failed to support concurrent use of plperl and plperlu,
so it's likely that few people use such versions with Postgres.

Security: CVE-2010-3433

o bien este otro:

commit b5ea5e2f1c5dbd6a1618e8dfbfc642e85944c1da
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Tue Jun 17 00:52:56 2008 +0000

Clean up a number of bogosities around pltcl's handling of the Tcl "result":

1. Directly reading interp->result is deprecated in Tcl 8.0 and later;
you're supposed to use Tcl_GetStringResult. This code finally broke with
Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even
though it preserves the logical state of the result. (There's arguably a
Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a
just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as
a bug.)

2. We were being sloppy about the encoding of the result: some places would
push database-encoding data into the Tcl result, which should not happen,
and we were assuming that any error result coming back from Tcl was in the
database encoding, which is not a good assumption.

3. There were a lot of calls of Tcl_SetResult that uselessly specified
TCL_VOLATILE for constant strings. This is only a minor performance issue,
but I fixed it in passing since I had to look at all the calls anyway.

#2 is a live bug regardless of which Tcl version you are interested in,
so back-patch even to branches that are unlikely to be used with Tcl 8.5.
I went back as far as 8.0, which is as far as the patch applied easily;
7.4 was using a different error processing scheme that has got its own
problems :-(

Creo que la única forma de probarlo sería compilar Tcl desde Git, usando
las versiones posteriores a 8.2.5 y verificando qué cambio hace aparecer
el bug.

Lo otro que puede ser es que sea un problema de concurrencia y no tenga
nada que ver con la versión de pltcl.

Tener la BD en SQL_ASCII es mala idea, pero hasta donde veo no debería
afectarte en este caso.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>