From: "Michal Suchánek" <msuchanek@suse•de>
To: "brian m. carlson" <sandals@crustytoothpaste•net>, git@vger•kernel.org
Subject: Re: Failing to push to a repository erases authentication helper credentials
Date: Tue, 1 Jul 2025 10:49:39 +0200 [thread overview]
Message-ID: <aGOhIxqloEdxUcn6@kitsune.suse.cz> (raw)
In-Reply-To: <aGOGMpibpUM2JJuV@kitsune.suse.cz>
On Tue, Jul 01, 2025 at 08:54:42AM +0200, Michal Suchánek wrote:
> On Mon, Jun 30, 2025 at 06:29:46PM +0000, brian m. carlson wrote:
> > On 2025-06-30 at 15:09:06, Michal Suchánek wrote:
> > > On Mon, Jun 30, 2025 at 02:31:15PM +0000, brian m. carlson wrote:
> > > > It is in fact desirable because otherwise the user continues to attempt
> > > > to use the bad credentials and then can never again authenticate
> > > > successfully, since they are never again prompted for credentials.
> > >
> > > My proglem is that the credentials are actually valid, only the
> > > operation is not. The current behavior erases valid credentials.
> >
> > Then the server needs to return a 403 or 404 and not a 401. A 401
> > prompts Git to expire credentials and a 403 or 404 does not. Only the
> > server knows whether the credentials are actually valid for some access
> > or not at all.
> >
> > RFC 9110 § 15.5.2 says this:
> >
> > The 401 (Unauthorized) status code indicates that the request has
> > not been applied because it lacks valid authentication credentials
> > for the target resource.
> >
> > and § 15.5.4 says this:
> >
> > The 403 (Forbidden) status code indicates that the server understood
> > the request but refuses to fulfill it.
> > […]
> > If authentication credentials were provided in the request, the
> > server considers them insufficient to grant access. The client
> > SHOULD NOT automatically repeat the request with the same
> > credentials. The client MAY repeat the request with new or different
> > credentials.
> > […]
> > An origin server that wishes to "hide" the current existence of a
> > forbidden target resource MAY instead respond with a status code of
> > 404 (Not Found).
> >
> > So the server is incorrect in returning a 401 in this case if the
> > credentials are actually valid for a different operation on the same
> > resource.
>
> Is there any way to see what the server is returning?
>
> As the repository uses SSL capturing the communication with a proxy
> would be challenging.
mitmweb works for the purpose but it's hard to interprete the data.
401 is often returned even in the cases when everything works correctly,
probably because git first tries to access without authentication.
403 is not ever returned, the error only happens on the git protocol
level, apparently.
Thanks
Michal
next prev parent reply other threads:[~2025-07-01 8:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 13:45 Failing to push to a repository erases authentication helper credentials Michal Suchánek
2025-06-30 14:31 ` brian m. carlson
2025-06-30 15:09 ` Michal Suchánek
2025-06-30 18:29 ` brian m. carlson
2025-07-01 6:54 ` Michal Suchánek
2025-07-01 8:49 ` Michal Suchánek [this message]
2025-07-01 15:38 ` Junio C Hamano
2025-07-03 10:44 ` Michal Suchánek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aGOhIxqloEdxUcn6@kitsune.suse.cz \
--to=msuchanek@suse$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox