token in `.config/bloom` is not recognised

[christian-rauch]

I have a .config/bloom with:

{"oauth_token": "ghp_MYBLOOMTOKEN", "github_user": "christian-rauch"}

where ghp_MYBLOOMTOKEN is a token generated specifically for bloom with only the public_repo scope.

When I run bloom-release my_package --rosdistro rolling with release repo https://github.com/ros2-gbp/my_package-release.git and without the "Re-route https through ssh", I am still asked for a username and password:

Username for 'https://github.com': christian-rauch
Password for 'https://christian-rauch@github.com': 

Here, when I enter ghp_MYBLOOMTOKEN for the password, the push check seems to work.

Since the token seems to work, the question is essentially: Why does bloom not recognise the github_user and oauth_token in the bloom configuration file?

[cottsay]

I believe that the token is necessary for opening the pull request using GitHub's API. I'm not sure it's currently intended to take care of clone/push authentication indirectly through git.

This is largely a duplicate of #436.

[christian-rauch]

I believe that the token is necessary for opening the pull request using GitHub's API. I'm not sure it's currently intended to take care of clone/push authentication indirectly through git.

Since the information is already in the config file, it should be rather easy to reuse that for the username/password entries. If I remember correctly, https authenticate on github.com via username and password is not possible for a while now. So this could be simplified by always using the github_user and oauth_token, when it is set, and ask for it otherwise.

What do you think?

This is largely a duplicate of #436.

It is indeed the same issue. But this one was closed, probably using the insteadOf workaround.

[cottsay]

What do you think?

If you dig deeper, it seems that the approach was abandoned in the past because git kept printing the token to console and/or logs and it was deemed insecure. Given the security complexity, I think that most folks just use insteadOf because it works, it's secure, and it's easy.

If you can find a way to tell git to use the token in a way that doesn't modify the global git configuration or open security holes like the ones mentioned previously, I don't see any reason that wouldn't be considered.