If using a different push-url (e.g. ssh) while using another fetch-url (e.g. http(s)) as it's common for plain git remotes, git-bug fails with "Error: authorization failed"

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/stale 9 months ago

This is still very much relevant to me. Apparently to no one else, which seems odd considering this is a common way to access git repositories on plain git hosts.

sudoforge added label kind/feature 8 months ago

sudoforge added label lifecycle/frozen 8 months ago

sudoforge added label priority/backlog 8 months ago

sudoforge added label area/git 8 months ago

sudoforge removed label lifecycle/stale 8 months ago

@s1ls thanks for opening this issue. i think this makes sense to me, but just to confirm, you have a repository set up like this?

➜ git remote -v
origin  https://github.com/git-bug/git-bug.git (fetch)
origin  ssh://git@github.com/git-bug/git-bug.git (push)

what command(s) are you running that cause the authorization failed error? does this happen natively, or over a bridge?

@sudoforge Yes, that's exactly my setup. Commands like git bug pull/push fail (everything that interacts with the remote). I don't use bridges, so natively

thanks for the confirmation. i was able to reproduce this with a quick test (below); i imagine this is related to how we're using go-git (or we could just be making a bad assumption about what the push url should be -- you get the same error if you change your push url to https).

i'll add this into the track for the next release (which got delayed due to $LIFE/WORK/etc, but is on its way again).

➜ git clone --single-branch --no-tags https://github.com/git-bug/git-bug.git .
Cloning into '.'...
remote: Enumerating objects: 20151, done.
remote: Counting objects: 100% (3417/3417), done.
remote: Compressing objects: 100% (471/471), done.
remote: Total 20151 (delta 3126), reused 2946 (delta 2946), pack-reused 16734 (from 4)
Receiving objects: 100% (20151/20151), 22.47 MiB | 3.00 MiB/s, done.
Resolving deltas: 100% (13485/13485), done.


➜ gh repo create --private test-repo
✓ Created repository sudoforge/test-repo on GitHub
  https://github.com/sudoforge/test-repo


➜ git remote set-url --push origin git@github.com:sudoforge/test-repo


➜ git push
Enumerating objects: 20151, done.
Counting objects: 100% (20151/20151), done.
Delta compression using up to 16 threads
Compressing objects: 100% (6123/6123), done.
Writing objects: 100% (20151/20151), 22.47 MiB | 11.43 MiB/s, done.
Total 20151 (delta 13485), reused 20151 (delta 13485), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (13485/13485), done.
To ssh://github.com/sudoforge/test-repo
 * [new branch]        master -> master


➜ git bug version
git-bug version: v0.8.0-dev-f4daad2dca


➜ git bug user new -e 'no-reply@domain.com' -n 'git-bug-user' --non-interactive
Building cache...

b9b4ffee07e772819910cd3531b866accfcab4462829bd9be113f8196855afe1


➜ git bug push
Error: authentication required

sudoforge added label priority/important-soon 8 months ago

sudoforge removed label priority/backlog 8 months ago

sudoforge added label lifecycle/active 8 months ago

sudoforge added label triage/accepted 8 months ago

sudoforge removed label lifecycle/frozen 8 months ago

sudoforge added label root-cause/go-git 8 months ago

sudoforge removed label lifecycle/active 8 months ago

sudoforge removed label root-cause/go-git 7 months ago

the HTTP(s) authentication issue described in this issue is better tracked in #1416 (consider it "split" from this issue into #1416).

we'll keep this issue as tracking for support of two different remotes via configuration (to avoid needing to specify these remotes on the command line, which was not exactly what the user opened this issue for, but does bring up that it is a common practice [and git supports config for this, anyway])

sudoforge changed the title from git-bug should support different push/pull remotes via configuration to git-bug should support different push/pull remotes via configuration 7 months ago

sudoforge closed the bug 7 months ago

sudoforge opened the bug 7 months ago

sudoforge removed label priority/important-soon 7 months ago

sudoforge added label priority/backlog 7 months ago