Unfortunately, this still won't fix a possible invalid access - if you call `git_oid_fromstr` with `"12"` then the first iteration will read the first two bytes and the second iteration will read off the end of the string. Just checking the first byte only catches one particular error.

I can think of a few possible fixes:

1. Rewrite the internals of `git_oid_fromstr` to invoke `return git_oid_fromstrn(out, str, min(strlen(str, GIT_OID_HEXSZ)));` which does not trust the user to actually provide a `GIT_OID_HEXSZ` length string.
2. Change the inner loop of `git_oid_fromstrn` to call `git__fromhex` separately on each byte of data and terminate as soon as an invalid one is found. This fixes the issue of an incorrect length so long as the data is still NUL terminated. If it isn't NUL terminated, then there isn't much we can do to protect ourselves.
3. Remove the `git_oid_fromstr` API completely because we now have better alternatives. Even if we do this, we still might want to do item 2 if we want to protect against the function being called with API parameters that lie. I don't feel like that is very important because if you call `memcpy` or `strncpy` with invalid parameters you will be invalid memory access, too, but I'm also not against it.
4. We could just do nothing because, again as with `memcpy` and `strncpy` and the like, if you invoke the API with parameters that don't meet the documented requirements (i.e. `git_oid_fromstr` requires a `GIT_OID_HEXSZ` input) then we can't really protect you.