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 <[email protected]> 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 <[email protected]> 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 <[email protected]> - Enviado a la lista de correo pgsql-es-ayuda ([email protected]) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
