-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix(git): add warning of the mismatch of git cred and url #3136
Conversation
Hi @FogDong. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/kind feature |
PTAL 😉 @sbwsg |
684e542
to
d99c607
Compare
Fixed. 😆 Please review @sbwsg |
Can anybody take a look at this PR? 🤔 /cc @vdemeester |
func validateGitAuth(logger *zap.SugaredLogger, url string) error { | ||
homeenv := os.Getenv("HOME") | ||
sshCred := true | ||
if _, err := os.Stat(homeenv + "/.ssh"); os.IsNotExist(err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this some more I'm not sure this is enough to correctly validate SSH credentials. A user can mix SSH and non-SSH git credentials in a single Step. For example, with two Secrets:
apiVersion: v1
kind: Secret
metadata:
name: example-gitlab-creds
annotations:
tekton.dev/git-0: https://gitlab.com
type: kubernetes.io/basic-auth
stringData:
username: myuser
password: hunter2
---
apiVersion: v1
kind: Secret
metadata:
name: example-github-creds
annotations:
tekton.dev/git-0: github.com
type: kubernetes.io/ssh-auth
stringData:
ssh-privatekey: blahblahblah
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: example-service-account
secrets:
- name: example-gitlab-creds
- name: example-github-creds
---
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
name: foobar
spec:
serviceAccountName: example-service-account
taskSpec:
steps:
- name: wait
image: alpine:latest
script: |
echo "foo"
In this example YAML both a ~/.ssh
directory and a ~/.git-credentials
file will exist side by side. ~/.git-credentials
is created for the gitlab Secret. So this code will print a warning because the gitlab basic auth URL is not SSH-formatted. But the user never intends to use SSH auth with a gitlab URL.
The full solution to this problem is probably quite a lot more complicated - it would need to read the ~/.ssh/config
file and figure out whether the given url
is intended to be used with SSH authentication.
We could work around this somewhat by updating the warning messages to be more relaxed. Something like:
logger.Warnf("SSH credentials have been provided but the URL %q is not a valid SSH URL", url)
But this feels like it would lead to more user confusion and I don't think this is a great workaround either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I met the similar problem when I tested the code: if the given URL is a public repo and the cred is SSH type, the warning log will be shown and the pod can still pull the code successfully.
But it will be more too complex if we check the URL is public or not. So my point is we can just let the warning show since it's only a warning and people will not care about the warning if the job success. 🤔 WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrm, tricky problem! OK, I think we can make this work with an even longer log message:
SSH credentials have been provided but the URL %q is not a valid SSH URL. This warning can be safely ignored if the URL is for a public repo or you are using basic auth
@vdemeester what do you think of this? Is it too vague? The other thing we could do is drop this message and only print a warning if a URL is definitely an SSH url but the user has 0 SSH credentials available in the Step. That is 100% of the time a legitimate error I think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll change the message first but I'm also not quite sure that if we need that message when SSH credentials are provided but the URL is non-SSH. Let me know if there is better solutions!
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I've left more comments. I'm not totally sure if we want the warning message when SSH credentials are provided but the URL is non-SSH. Might be too vague? Curious what others think about this!
func validateGitAuth(logger *zap.SugaredLogger, url string) error { | ||
homeenv := os.Getenv("HOME") | ||
sshCred := true | ||
if _, err := os.Stat(homeenv + "/.ssh"); os.IsNotExist(err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrm, tricky problem! OK, I think we can make this work with an even longer log message:
SSH credentials have been provided but the URL %q is not a valid SSH URL. This warning can be safely ignored if the URL is for a public repo or you are using basic auth
@vdemeester what do you think of this? Is it too vague? The other thing we could do is drop this message and only print a warning if a URL is definitely an SSH url but the user has 0 SSH credentials available in the Step. That is 100% of the time a legitimate error I think?
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/retest |
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @FogDong !
Can I get a lgtm? /cc @vdemeester 😉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbwsg, withlin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@bobcatfish sure thing; updated! |
Changes
Fix(git): add warning of the mismatch of git cred and url
Fix #3094
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes