8000 Fixing Coverity Defects Part Deux by whoisj · Pull Request #1130 · libgit2/libgit2sharp · GitHub
[go: up one dir, main page]

Skip to content

Fixing Coverity Defects Part Deux #1130

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

Closed
wants to merge 5 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
8000
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Fixes potential NRE defect found by Coverity
  • Loading branch information
J Wyman committed Jul 8, 2015
commit 63eabbbd6374ac358908941d4569c4b135233be2
10 changes: 9 additions & 1 deletion LibGit2Sharp/RemoteCallbacks.cs
Original file line number Diff line number Diff line change
Expand Up @@ -275,7 +275,15 @@ private int GitCredentialHandler(

var cred = CredentialsProvider(url, username, types);

return cred.GitCredentialHandler(out ptr);
if (cred == null)
{
ptr = IntPtr.Zero;
return -1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this still retain the semantics? Shouldn't this be an explicit throw? Iirc, this is hooked up to a native callback, and doesn't -1 just stop the callback trying?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say some tests that verify that this does not change behavior should be good. If we can, we should explicitly throw from here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this still retain the semantics? Shouldn't this be an explicit throw? Iirc, this is hooked up to a native callback, and doesn't -1 just stop the callback trying?

Throwing during native callback handling isn't kosher. It leaves the native library hanging.

I'd say some tests that verify that this does not change behavior should be good. If we can, we should explicitly throw from here.

Agreed, care to help add them? 😉

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The best unit test is seeing if XS crashes or not. :D Once this is merged in vNext, I'll do the binary bump in XS and test. (we don't ever return null, but I'll force it to)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, can we also make this a Debug.Assert?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, can we also make this a Debug.Assert?

@Therzok If we never return null then there should be no harm in returning an error code to the native library if somehow cred == null. Better than blowing up and leaving the native library wondering what happened.

/CC @nulltoken : thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking that we should be able to exercise this code path with something like

var options = new FetchOptions
            {
                CredentialsProvider = (_url, _user, _cred) =>
                    { return default(UsernamePasswordCredentials); }
            };

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@whoisj Any chance you could try and add this test above?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nulltoken sure, I can try to find time to work on this. I've been a combination of on vacation and super busy lately. I don't see my current load relaxing until Halloween, but I'll see what I can do. If we're blocking this PR on the work getting done it could be a while (or not - you never know!).

}
else
{
return cred.GitCredentialHandler(out ptr);
}
}

private int GitPushNegotiationHandler(IntPtr updates, UIntPtr len, IntPtr payload)
Expand Down
0