Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I believe the proper way to handle this is a new directory under /tmp.
It's definitely not worth the trouble. I looked at what configure does
to make /tmp subdirectories portably, and it is spectacularly
Bruce Momjian [EMAIL PROTECTED] writes:
From a public relations perspective and a code reuse perspective I think
we should create temporary tables securely. The attached applied patch
fixes contrib/findoidjoins/make_oidjoins_check.
... and creates issues of its own, such as attempting an rm
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I believe the proper way to handle this is a new directory under /tmp.
It's definitely not worth the trouble. I looked at what configure does
to make /tmp subdirectories portably, and it is spectacularly ugly
(not to mention long).
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
From a public relations perspective and a code reuse perspective I think
we should create temporary tables securely. The attached applied patch
fixes contrib/findoidjoins/make_oidjoins_check.
... and creates issues of its own, such
On Thu, 2004-11-04 at 10:07, Bruce Momjian wrote:
My method is secure, and I think we do have to handle this in a way that
addresses the security concerns.
I think Tom's fix adequately addresses the security concerns. Exactly
what is wrong with writing to the current working directory?
It is
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think Tom's fix adequately addresses the security concerns. Exactly
what is wrong with writing to the current working directory?
Because it could be run from a directory where others have write
permission.
In which case, they
On Wed, 3 Nov 2004, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think Tom's fix adequately addresses the security concerns. Exactly
what is wrong with writing to the current working directory?
Because it could be run from a directory where others
Gavin Sherry [EMAIL PROTECTED] writes:
I think the problem can really be solved by just removing it from the
distribution.
Just FYI, I've already done that in Red Hat's RPMs (not sure if Devrim
followed suit). I can't think of a good reason for make install to
install that script, either.
Gavin Sherry wrote:
On Wed, 3 Nov 2004, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think Tom's fix adequately addresses the security concerns. Exactly
what is wrong with writing to the current working directory?
Because it could be run
Hello Peter,
Please intall the attached updates for 8.0. All fuzzy messages should be
fixed in these.
Thanks,
-s
libpq-ru.po.gz
Description: GNU Zip compressed data
pg_ctl-ru.po.gz
Description: GNU Zip compressed data
pg_dump-ru.po.gz
Description: GNU Zip compressed data
Hi,
Attached is a patch that correct two typos in pt_BR FAQ.
Please apply.
=
Euler Taveira de Oliveira
euler[at]yahoo_com_br
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Neil Conway [EMAIL PROTECTED] writes:
Attached is a patch that removes the make_oidjoins_check script from
make install. Barring any objections, I'll apply it to HEAD later
today.
If we are going in that direction, all the files installed by this
subdirectory should be suppressed (ie,
On Thu, 2004-11-04 at 13:05, Bruce Momjian wrote:
I am fine with removing it but if we don't I would like to have it
secure, mostly from a public relations perspective.
A change which introduced two regressions and fails to materially
improve the security of the script is a curious definition
On Wed, 2004-11-03 at 14:45, Neil Conway wrote:
Attached is a patch that makes some improvements to the contrib/ build.
Applied.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
14 matches
Mail list logo