Quick fix for Kerberos: don't use hardcoded userPlusRealm length

[vkarpov15]

Hey Gustavo,

Looks like I made a silly mistake in my SSPI code, forgot to take out the hardcoded username length.

[niemeyer]

There seems to be a leak of this allocation. I suggest dropping the memcpy below, and instead simply doing:

*buffer = msg;
*buffer_length = ...

so that you pass the reference back into the Go code rather than losing it.

Then, the Go code that calls this also seems a bit problematic. It should probably do something alone the lines of:

if buffer != C.PVOID(nil) {
        defer C.free(unsafe.Pointer(buffer))
}

This will avoid the need for buffersToFree, and most importantly will not crash the whole process when there are any errors in send_client_authz_id that prevent it from sending a proper buffer. Note the defer.. this allows handling the deallocation early on, and then forgetting about it in a good sense.

Note that GoBytes will copy the data, so it is okay to drop the underlying data.

[vkarpov15]

You're right about msg getting leaked, but I think it's simpler to just free() it when you're done with it. That way the current structure works as intended.

[niemeyer]

Sure, the process of re-allocating and re-copying the data looks suspect, but I'll leave that up to you.

That said, let's please fix the Go side of this. That buffersToFree list is completely unnecessary, as suggested in the comment above, and it's also going to crash the application if there are errors, since the buffer is not allocated. It should be trivial to free with defer as suggested.

[vkarpov15]

done

[niemeyer]

Thanks for the changes.