public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste•net>
To: "Michal Suchánek" <msuchanek@suse•de>
Cc: git@vger•kernel.org
Subject: Re: Failing to push to a repository erases authentication helper credentials
Date: Mon, 30 Jun 2025 18:29:46 +0000	[thread overview]
Message-ID: <aGLXmiYuM2C_xfWJ@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <aGKokqPJPh5fQ3fc@kitsune.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]

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.

> > Git doesn't have a behaviour to do so, but you could of course craft a
> > custom credential helper that just rejects the erase command and passes
> > everything else through to another helper.  That would achieve your
> 
> I do not want to use another helper. I want to preserve the last valid
> credentials.
> 
> Of course, using credentials that are not maintained by git at all (such
> as ssh authentication) does not have this problem. Only git-managed
> credentials get erased on invalid operation.

In general, Git does not presently offer this functionality.  We could
in theory accept a patch for a config option that makes this work, but I
expect it will lead to hard-to-troubleshoot problems for the exact
reason I mentioned.  It will also require an update to the Git FAQ to
disable that option in the example, since we use the exact same
mechanism to delete credentials for users who _do_ want to expire
credentials.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2025-06-30 18:29 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 [this message]
2025-07-01  6:54       ` Michal Suchánek
2025-07-01  8:49         ` Michal Suchánek
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=aGLXmiYuM2C_xfWJ@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste$(echo .)net \
    --cc=git@vger$(echo .)kernel.org \
    --cc=msuchanek@suse$(echo .)de \
    /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