My guess is that maybe you've configured this repo incorrectly. After logging in to review coreboot org , go to https://review.coreboot.org/admin/repos/board-status and copy a HTTP command for cloning, like " git clone "https://mikebdp@review.coreboot.org/a/board-status" && (cd "board-status" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://mikebdp@review.coreboot.org/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg) " , with mikebdp replaced by your username there (but better to copy it from HTTP tab to avoid accidental mistakes). Then copy the files you would like to commit to this repository, commit and push, and it should only ask your password, without a username.
On Sun, Dec 8, 2019 at 11:37 AM Mike Banon mikebdp2@gmail.com wrote:
My guess is that maybe you've configured this repo incorrectly. After logging in to review coreboot org , go to https://review.coreboot.org/admin/repos/board-status and copy a HTTP command for cloning, like " git clone "https://mikebdp@review.coreboot.org/a/board-status" && (cd "board-status" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://mikebdp@review.coreboot.org/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg) " , with mikebdp replaced by your username there (but better to copy it from HTTP tab to avoid accidental mistakes). Then copy the files you would like to commit to this repository, commit and push, and it should only ask your password, without a username.
On Wed, Dec 4, 2019 at 5:17 PM Jorge Fernandez Monteagudo jorgefm@cirsa.com wrote:
Hi all,
I've generated a new entry in util/board_status/board-status/amd/bettong/4.10-6-g12ec481/2019-12-04T13_27_01Z/ but I'm not able to push the changes.
I'm able to entry in to https://review.coreboot.org/settings/ and I can see my HTTP credentials with my github user name and I've generated a new password pushing the button but then I try to do a push and always get:
$ cd util/board_status/board-status $ git push Username for 'https://review.coreboot.org': jorgefm1900 Password for 'https://jorgefm1900@review.coreboot.org': fatal: Authentication failed for 'https://review.coreboot.org/board-status.git/'
Any resource to configure a review.coreboot.org repo user? I've tried to change the password through Github creating a personal access token without luck...
Thanks! _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
We moved the other thread off-list, but the issue was that there's a https proxy in the way that terminates SSL connections.
I documented the approach to deal with that in https://review.coreboot.org/c/coreboot/+/37599
Patrick
Am So., 8. Dez. 2019 um 09:39 Uhr schrieb Mike Banon mikebdp2@gmail.com:
My guess is that maybe you've configured this repo incorrectly. After logging in to review coreboot org , go to https://review.coreboot.org/admin/repos/board-status and copy a HTTP command for cloning, like " git clone "https://mikebdp@review.coreboot.org/a/board-status" && (cd "board-status" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://mikebdp@review.coreboot.org/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg) " , with mikebdp replaced by your username there (but better to copy it from HTTP tab to avoid accidental mistakes). Then copy the files you would like to commit to this repository, commit and push, and it should only ask your password, without a username.
On Sun, Dec 8, 2019 at 11:37 AM Mike Banon mikebdp2@gmail.com wrote:
My guess is that maybe you've configured this repo incorrectly. After logging in to review coreboot org , go to https://review.coreboot.org/admin/repos/board-status and copy a HTTP command for cloning, like " git clone "https://mikebdp@review.coreboot.org/a/board-status" && (cd "board-status" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://mikebdp@review.coreboot.org/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg) " , with mikebdp replaced by your username there (but better to copy it from HTTP tab to avoid accidental mistakes). Then copy the files you would like to commit to this repository, commit and push, and it should only ask your password, without a username.
On Wed, Dec 4, 2019 at 5:17 PM Jorge Fernandez Monteagudo jorgefm@cirsa.com wrote:
Hi all,
I've generated a new entry in
util/board_status/board-status/amd/bettong/4.10-6-g12ec481/2019-12-04T13_27_01Z/
but I'm not able to push the changes.
I'm able to entry in to https://review.coreboot.org/settings/ and I
can see my HTTP credentials with my github user name
and I've generated a new password pushing the button but then I try to
do a push and always get:
$ cd util/board_status/board-status $ git push Username for 'https://review.coreboot.org': jorgefm1900 Password for 'https://jorgefm1900@review.coreboot.org': fatal: Authentication failed for '
https://review.coreboot.org/board-status.git/'
Any resource to configure a review.coreboot.org repo user? I've tried
to change the password through Github creating a
personal access token without luck...
Thanks! _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
We moved the other thread off-list, but the issue was that there's a https proxy in the way that terminates SSL connections.
I documented the approach to deal with that in https://review.coreboot.org/c/coreboot/+/37599
Hi, I'm still stuck with the same error trying to push anything. Disabled validating certs as pointed in your change doesn't solve my issue. But it's related to my workstation or company's proxy server because the same user works at home and I can login and send patches...
Regards Jorge
Note that the setting is per-clone by default, so if you set up coreboot to be without sslVerify, that doesn't apply to the board_status repo unless you also used --global.
Am Mo., 9. Dez. 2019 um 11:11 Uhr schrieb Jorge Fernandez Monteagudo < jorgefm@cirsa.com>:
We moved the other thread off-list, but the issue was that there's a
https proxy in the way that
terminates SSL connections.
I documented the approach to deal with that in
https://review.coreboot.org/c/coreboot/+/37599
Hi, I'm still stuck with the same error trying to push anything. Disabled validating certs as pointed in your change doesn't solve my issue. But it's related to my workstation or company's proxy server because the same user works at home and I can login and send patches...
Regards Jorge
Note that the setting is per-clone by default, so if you set up coreboot to be without sslVerify, that doesn't apply to the board_status repo unless you also used --global.
Yes, I have it configured globally using ~/.gitconfig file
[http] sslVerify = false proxy = http://<user>:<passwd>@<ip_host>:<port>/ [https] sslVerify = false proxy = http://<user>:<passwd>@<ip_host>:<port>/
Am Mo., 9. Dez. 2019 um 11:11 Uhr schrieb Jorge Fernandez Monteagudo jorgefm@cirsa.com:
We moved the other thread off-list, but the issue was that there's a https proxy in the way that
terminates SSL connections.
I documented the approach to deal with that in https://review.coreboot.org/c/coreboot/+/37599
Hi,
I'm still stuck with the same error trying to push anything. Disabled validating certs as pointed in
your change doesn't solve my issue. But it's related to my workstation or company's proxy server
because the same user works at home and I can login and send patches...
Regards
Jorge
Am Mo., 9. Dez. 2019 um 11:51 Uhr schrieb Jorge Fernandez Monteagudo < jorgefm@cirsa.com>:
Note that the setting is per-clone by default, so if you set up coreboot
to be without sslVerify, that doesn't apply to the board_status repo unless you also used --global.
Yes, I have it configured globally using ~/.gitconfig file
In that case you have it really bad in that the proxy not only replaces the SSL cert but also tampers with the data you send. There's little we can do in such cases (given that https is usually the more accessible protocol in such scenario and the SSH interface to Gerrit on port 29418 usually isn't accessible at all).
Patrick