Fujii Masao writes:
> Attached is the patch that Nathan proposed at [1] and I think that
> it's worth applying. I'd like to add this to next CommitFest.
> Thought?
I can't get excited about this in the least. For any "normal" use of
passwords, 100 bytes is surely far more than sufficient. Furth
On 2020/01/22 11:01, Fujii Masao wrote:
On 2020/01/22 0:12, Bruce Momjian wrote:
On Tue, Jan 21, 2020 at 02:42:07PM +0900, Fujii Masao wrote:
I have no strong opinion about the maximum length of password,
for now. But IMO it's worth committing that 0001 patch as the first step
for this prob
> On 22 Jan 2020, at 01:41, David Fetter wrote:
>
> On Tue, Jan 21, 2020 at 07:05:47PM +0100, David Fetter wrote:
>> On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote:
>>> On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote:
On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruc
On 2020/01/22 9:41, David Fetter wrote:
On Tue, Jan 21, 2020 at 07:05:47PM +0100, David Fetter wrote:
On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote:
On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote:
On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote:
On 2020/01/22 0:12, Bruce Momjian wrote:
On Tue, Jan 21, 2020 at 02:42:07PM +0900, Fujii Masao wrote:
I have no strong opinion about the maximum length of password,
for now. But IMO it's worth committing that 0001 patch as the first step
for this problem.
Also IMO the more problematic thing
On Tue, Jan 21, 2020 at 07:05:47PM +0100, David Fetter wrote:
> On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote:
> > On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote:
> > > On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote:
> > > > I think we should be using a
On Tue, Jan 21, 2020 at 10:23:59AM -0500, Bruce Momjian wrote:
> On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote:
> > On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote:
> > > I think we should be using a macro to define the maximum length, rather
> > > than have 100 used in
On Tue, Jan 21, 2020 at 04:19:13PM +0100, David Fetter wrote:
> On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote:
> > I think we should be using a macro to define the maximum length, rather
> > than have 100 used in various places.
>
> It's not just 100 in some places. It's different
On Tue, Jan 21, 2020 at 10:12:52AM -0500, Bruce Momjian wrote:
> On Tue, Jan 21, 2020 at 02:42:07PM +0900, Fujii Masao wrote:
> > I have no strong opinion about the maximum length of password,
> > for now. But IMO it's worth committing that 0001 patch as the first step
> > for this problem.
> >
>
On Tue, Jan 21, 2020 at 02:42:07PM +0900, Fujii Masao wrote:
> I have no strong opinion about the maximum length of password,
> for now. But IMO it's worth committing that 0001 patch as the first step
> for this problem.
>
> Also IMO the more problematic thing is that psql silently truncates
> the
On 2020/01/21 4:21, David Fetter wrote:
On Mon, Jan 20, 2020 at 07:44:25PM +0100, David Fetter wrote:
On Mon, Jan 20, 2020 at 01:12:35PM -0500, Tom Lane wrote:
David Fetter writes:
At least two cloud providers are now stuffing large amounts of
information into the password field. This chan
On Mon, Jan 20, 2020 at 09:17:47PM +0100, Alexander Kukushkin wrote:
> Hi,
>
> I think I should add my two cents.
>
> On Mon, 20 Jan 2020 at 20:38, Tom Lane wrote:
> >
> > > I found another place that assumes 100 bytes and upped it to 2048.
>
> There one more place, in the code which is parsing
Alexander Kukushkin writes:
> I think I should add my two cents.
> We at Zalando are using JWT tokens as passwords. JWT tokens are
> self-contained and therefore quite huge (up to 700-800 bytes in our
> case). Tokens have a limited lifetime (1 hour) and we are using PAM to
> verify them.
> Altoget
Hi,
I think I should add my two cents.
On Mon, 20 Jan 2020 at 20:38, Tom Lane wrote:
>
> > I found another place that assumes 100 bytes and upped it to 2048.
There one more place, in the code which is parsing .pgpass
>
> So this is pretty much exactly what I expected. And have you tried
> it
David Fetter writes:
> On Mon, Jan 20, 2020 at 07:44:25PM +0100, David Fetter wrote:
>> On Mon, Jan 20, 2020 at 01:12:35PM -0500, Tom Lane wrote:
>>> (I can't say that s/100/2048/ in one place is a particularly evil
>>> change; what bothers me is the likelihood that there are other
>>> places that
tter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From fb05bf709df0a67a63bca413cd7f0f276cab78b9 Mon Sep 17 00:00:00 2001
From: David Fetter
Date: Mon, 20 Jan 2020 09:58:19 -0800
Subject: [PATCH v3] Increa
20 Jan 2020 09:58:19 -0800
Subject: [PATCH v2] Increase psql's password buffer size
To: hackers
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.24.1"
This is a multi-part message in MIME format.
--2.24.1
Content-Type: text/plain; charset=UTF-8; f
David Fetter writes:
> At least two cloud providers are now stuffing large amounts of
> information into the password field. This change makes it possible to
> accommodate that usage in interactive sessions.
Like who? It seems like a completely silly idea. And if 2K is sane,
why not much more?
donating to Postgres: http://www.postgresql.org/about/donate
>From 168c380548d1f97e4f6e9245851c22029931e8b5 Mon Sep 17 00:00:00 2001
From: David Fetter
Date: Mon, 20 Jan 2020 09:58:19 -0800
Subject: [PATCH v1] Increase psql's password buffer size
To: hackers
MIME-Version: 1.0
Content-Type: multipa
19 matches
Mail list logo