On 17-06-2025 03:57 pm, Phillip Wood wrote:
> I'm not really on the list at the moment but I saw this was slated for next in what's cooking. Apologies if the formatting is off, I'm in my phone.
>
> On 9 June 2025 21:22:49 BST, Aditya Garg <gargaditya08@xxxxxxxx> wrote:
>>
>> +static char *oauthbearer_base64(const char *user, const char *access_token)
>> +{
>> + int raw_len, b64_len;
>> + char *raw, *b64;
>> +
>> + /*
>> + * Compose the OAUTHBEARER string
>> + *
>> + * "n,a=" {User} ",^Ahost=" {Host} "^Aport=" {Port} "^Aauth=Bearer " {Access Token} "^A^A
>> + *
>> + * The first part `n,a=" {User} ",` is the gs2 header described in RFC5801.
>> + * * gs2-cb-flag `n` -> client does not support CB
>> + * * gs2-authzid `a=" {User} "`
>> + *
>> + * The second part are key value pairs containing host, port and auth as
>> + * described in RFC7628.
>> + *
>> + * https://datatracker.ietf.org/doc/html/rfc5801
>> + * https://datatracker.ietf.org/doc/html/rfc7628
>> + */
>> + raw_len = strlen(user) + strlen(access_token) + 20;
>> + raw = xmallocz(raw_len + 1);
>> + snprintf(raw, raw_len + 1, "n,a=%s,\001auth=Bearer %s\001\001", user, access_token);
>
> This looks very fragile. It would be safer to use an strbuf or if there are no embedded nul bytes xstrfmt() and strlen(). This applies to the next patch as well and any others that are building strings with snprintf() or memcpy().
Ok
>
> Also the comment above mentions the host and port but I don't see them here.
Host and port are optional. See section 3.1 here:
https://datatracker.ietf.org/doc/html/rfc7628#section-3.1
Also, please add me to the Cc list. I do not read the mailing list quite often, and saw this in what's cooking.
Thanks
Aditya
