-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
> I grow weary of repeating this: it's not about resource consumption, nor > about potential security holes in plpgsql itself. It's about handing > attackers the capability to further exploit *other* security holes. Well, without specific examples, I'm not sure I understand what plpgsql buys you that you could not do other ways (e.g. generate_series() for looping). An earlier thread mentioned someone with access to pg_shadow writing a function to hash random passwords and comparing them, but if someone has access to pg_shadow, surely they can simply download the info to their local box for a more efficient cracking attempt? In any rate, that's not really a security hole, so perhaps a better example exists. There are so many simple ways to "do bad things" /without/ plpgsql, I just don't see how the theoretical harm in it being used as an attack vector even comes close to the benefits of having it installed by default. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200802211227 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAke9tdIACgkQvJuQZxSWSsieowCfQTbmdmGdIJSpWCOU5S2bHSR5 1PgAnjxjOV7Dh1X9nF3pPjDDBosiX0Tx =Z6yR -----END PGP SIGNATURE----- ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
