I wrote:
> Alvaro proposes nearby that we ought to have a src/common/ function
> to slurp an indefinitely long line from a file [1]. If we do that,
> it'd be entirely reasonable to make this code use that. So maybe
> the right comment is "XXX FIXME later".
Actually, on further thought, the obvio
"Bossart, Nathan" writes:
> On 9/3/20, 2:14 PM, "Tom Lane" wrote:
>> If you insist, I'll change it, but it seems even less likely to ever
>> matter to anybody than the changes to make simple_prompt accept
>> indefinitely long passwords. (Perhaps a reasonable compromise
>> is to extend this comme
On 9/3/20, 2:14 PM, "Tom Lane" wrote:
> If you insist, I'll change it, but it seems even less likely to ever
> matter to anybody than the changes to make simple_prompt accept
> indefinitely long passwords. (Perhaps a reasonable compromise
> is to extend this comment to note that we're also not bo
"Bossart, Nathan" writes:
> On 9/3/20, 10:19 AM, "Tom Lane" wrote:
> + charpwdbuf[8192];
> If I am reading correctly, this would be the only defined password
> length limit once this patch is applied. While it's probably unlikely
> that this will cause problems for any
On 9/3/20, 10:19 AM, "Tom Lane" wrote:
> Hearing no objections to this general plan, I went ahead and did that
> cleanup. This version seems committable to me.
FILE *pwf = fopen(pwfilename, "r");
- int i;
+ charpwd
I wrote:
> This could be refined; in particular, I think that most of the
> password-prompting sites could drop their separate have_password
> flags in favor of checking whether the password pointer is NULL
> or not. That would likely also prove that some of the free(password)
> calls I sprinkled
I wrote:
> Peter Eisentraut writes:
>> ISTM that it's only going to be a matter of time before that will be
>> exceeded. Why have a limit at all? Accept whatever StringInfo accepts.
> Hmm, that would require some refactoring of simple_prompt for starters.
To use StringInfo, we have to move sp
Peter Eisentraut writes:
> ISTM that it's only going to be a matter of time before that will be
> exceeded. Why have a limit at all? Accept whatever StringInfo accepts.
Hmm, that would require some refactoring of simple_prompt for starters.
I agree there's no hard reason why we have to have an
On 2020-09-01 02:54, Tom Lane wrote:
Therefore, I propose setting this up with a #define symbol in
pg_config_manual.h and leaving it at that. Giving documentation in
pg_config_manual.h seems sufficient to me. Attached is a revised
version of Nathan's patches that does it like that.
I set the p
On 8/31/20, 5:55 PM, "Tom Lane" wrote:
> I set the proposed limit at 1024 bytes, but given that we now know
> of use-cases needing up to 800 bytes, maybe there should be a little
> more headroom? I don't want to make it enormous, though, seeing that
> we're allocating static buffers of that size.
I wrote:
> Note this patch is intended to be applied over my patch at [2],
> since it modifies the test case added there.
I've now pushed that patch, so the patch in my previous mail should
directly apply to HEAD.
I'd originally been wondering whether we need to back-patch this patch.
But unless
Alexander Kukushkin writes:
> Self-containing tokens, for example JWT, could be easily longer than 100
> bytes.
> We at Zalando are using such tokens and the usual size of JWT token is
> 600-700 bytes.
> It is not possible to "paste" such token into psql password prompt,
> because the input is t
On Sat, 13 Oct 2018 at 02:02, Tom Lane wrote:
> Sure, but even a generated security token seems unlikely to be more
> than a couple dozen bytes long. What's the actual use-case for tokens
> longer than that? ISTM that a limit around 100 bytes already has a
> whole lot of headroom.
Self-contain
[0]. I understand this
alone doesn't warrant a change to PostgreSQL, but it seems valuable to
me to ease this restriction on custom client authentication
mechanisms.
Regarding md5 and scram-sha-256 passwords, I'll look into establishing
some sort of maximum password length that is well-d
"Bossart, Nathan" writes:
> On 10/12/18, 4:24 PM, "Stephen Frost" wrote:
>> Specific use-cases here would be better than hand-waving at "these other
>> things." Last I checked, all of those work with what we've got today
>> and I don't recall hearing complaints about them not working due to this
On 10/12/18, 4:24 PM, "Stephen Frost" wrote:
> * Bossart, Nathan (bossa...@amazon.com) wrote:
>> My main motivation for suggesting the increase to 8k is to provide
>> flexibility for alternative authentication methods like LDAP, RADIUS,
>> PAM, and BSD.
>
> Specific use-cases here would be better
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 10/12/18, 4:04 PM, "Isaac Morland" wrote:
> > I agree there should be a specific limit that is the same in libpq,
> > on the server, and in the protocol. Maybe 128 characters, to get a
> > nice round number? This is still way longer t
Isaac Morland writes:
> On Fri, 12 Oct 2018 at 16:52, Stephen Frost wrote:
>> I'm also trying to figure out why it makes sense to support an 8k
>> password and if we've really tried seeing what happens if pg_authid gets
>> a toast table that's actually used for passwords...
> ...
> It's also obv
Hi Isaac,
On 10/12/18, 4:04 PM, "Isaac Morland" wrote:
> I agree there should be a specific limit that is the same in libpq,
> on the server, and in the protocol. Maybe 128 characters, to get a
> nice round number? This is still way longer than the 32-byte SHA 256
> hash. Or 64, which is still pl
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 10/12/18, 3:52 PM, "Stephen Frost" wrote:
> > If we're going to do work in this area, why wouldn't we have the client
> > tools and the server agree on the max length and then have them all be
> > consistent..?
> >
> > Seems odd to d
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Fri, 12 Oct 2018 at 16:52, Stephen Frost wrote:
> > I'm also trying to figure out why it makes sense to support an 8k
> > password and if we've really tried seeing what happens if pg_authid gets
> > a toast table that's actually use
Hi Stephen,
On 10/12/18, 3:52 PM, "Stephen Frost" wrote:
> If we're going to do work in this area, why wouldn't we have the client
> tools and the server agree on the max length and then have them all be
> consistent..?
>
> Seems odd to decide that 100 character buffer size in the clients makes
On Fri, 12 Oct 2018 at 16:52, Stephen Frost wrote:
> I'm also trying to figure out why it makes sense to support an 8k
> password and if we've really tried seeing what happens if pg_authid gets
> a toast table that's actually used for passwords...
>
pg_authid.rolpassword stores a hash, so the p
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> I've attached 2 patches in an effort to clarify the upper bounds on
> password lengths:
> - 0001 refactors the hard-coded 100 character buffer size used for
> password prompts for client utilities into a
> PROMPT_MAX_PASSW
24 matches
Mail list logo
