From Max Zettlmeißl to ~sircmpwn/sr.ht-dev
Hey Conrad, On Thu, 31 Oct 2024 at 11:08, Conrad Hoffmann <ch@bitfehler.net> wrote: > Note that there two different things at play here: the fact that we use > bcrypt internally (and hence only process 72 bytes) is an implementation > detail that could change at any time, and should not prevent users from > using passwords that are longer than that. The other is the length > restriction put in place by ourselves, as part of the UI. I saw that and also thought that it probably would be desirable to keep the 512 limit in cases where another authentication backend is used or to avoid a change of the character count in the future when the hash is changed.
From Max Zettlmeißl to ~sircmpwn/sr.ht-dev
--- meta.sr.ht/index.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/meta.sr.ht/index.md b/meta.sr.ht/index.md index 8852eec..13f5d95 100644 --- a/meta.sr.ht/index.md +++ b/meta.sr.ht/index.md @@ -25,10 +25,12 @@ authentication and view the audit log. ## Two-factor authentication Presently, only [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm) is supported for two-factor authentication. Our recommended token software is [message trimmed]
From Max Zettlmeißl to ~sircmpwn/sr.ht-dev
There is an issue with the password reset: When submitting longer passwords (512 > i > ~150 characters) the submission of the password times out (nginx displays a 502 Bad Gateway after taking quite some time.) I did not test this locally, but the issue reproducibly happens with the official sourcehut instance. When going over the relevant programs in the meta.sr.ht repository (the most relevant one likely being `metasrht/blueprints/auth.py`) I could not find the reason for this behaviour and with these low character counts I can't see how it could exceed the size of a network request, even if it was set to a low value. Maybe the password validation is to blame, but I could not see anything obvious there.
From Max Zettlmeißl to ~sircmpwn/sr.ht-dev
The code in this case already is correct, since slices on Go strings work on bytes and not on characters or codepoints. --- api/graph/schema.resolvers.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api/graph/schema.resolvers.go b/api/graph/schema.resolvers.go index d2f92a2..87d658b 100644 --- a/api/graph/schema.resolvers.go +++ b/api/graph/schema.resolvers.go @@ -688,7 +688,7 @@ func (r *mutationResolver) RegisterAccount(ctx context.Context, email string, us return nil, nil } [message trimmed]
From Max Zettlmeißl to ~sircmpwn/sr.ht-dev
Note: Bcrypt truncates the input to 72 bytes, but a byte length is not enforceable in pure HTML forms, so characters will have to do. --- metasrht/templates/reset.html | 1 + 1 file changed, 1 insertion(+) diff --git a/metasrht/templates/reset.html b/metasrht/templates/reset.html index a43bb09..9ae65df 100644 --- a/metasrht/templates/reset.html +++ b/metasrht/templates/reset.html @@ -22,6 +22,7 @@ id="password" required autocomplete="new-password" [message trimmed]
From Max Zettlmeißl to ~sircmpwn/sr.ht-dev
There is an issue with the password reset: When submitting longer passwords (> ~150 characters) the submission of the password times out (nginx displays a 502 Bad Gateway after taking quite some time.) When I wanted to test whether the registration was also affected I saw that various parts already were adjusted to account for the 72 byte truncation of bcrypt input and submitted a patch to also cover the password reset. Still the underlying problem should probably be fixed. I will write a bug report to this list following these patches. I also took the liberty to correct a comment which stated that bcrypt truncates to 72 characters, when it truncates to 72 bytes, which are
From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss
On Wed, 21 Aug 2024 at 14:01, Alix Brunet <alixbrunetcontact@gmail.com> wrote: > > Is there a way to have 2FA backup codes? Not in the way which you expect. But without trying to sound snarky: Just backup your TOTP secret.
From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss
On Sat, 11 Feb 2023 at 22:03, David Florness <david@florness.com> wrote: > Is it possible to use OAuth 2.0 client tokens for sourcehut services > (git.sr.ht, todo.sr.ht, lists.sr.ht, etc)? For git.sr.ht it is definitely possible. And since the authentication and verification of the tokens depends on the meta service, I don't see why the other two services would be any different. > Provided that OAuth2.0 is supported, would a patch to update the > config.example.ini files be accepted? While I have no authority to give a definite answer, I don't see any reason why such a patch would not be accepted. But /oauth also links to /oauth2 and apart from those links I don't see what you would want
From Max Zettlmeißl to ~sircmpwn/sr.ht-discuss
On Mon, 9 Jan 2023 at 17:41, Lionel Dricot - Ploum <lio@ploum.be> wrote: > > It should be highlighted that "carbon-neutral" is often used as a pure > marketing greenwashing gimmick. > > If by "carbon-neutral", you mean "buying carbon offset", there’s a very > high chance that this means mostly bullshit. There is a recent article by The Guardian, reinforcing this: https://www.theguardian.com/environment/2023/jan/18/revealed-forest-carbon-offsets-biggest-provider-worthless-verra-aoe
From Max Zettlmeißl to ~sircmpwn/public-inbox
In plain text mode, Gmail wraps messages at 78 characters when sending them. --- es/index.html | 2 +- index.html | 7 ++++--- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/es/index.html b/es/index.html index 8d72aec..4429800 100644 --- a/es/index.html +++ b/es/index.html @@ -250,7 +250,7 @@ <h3 id="gmail-web">Gmail</h3> <div class="breakdown"> [message trimmed]