On 1/29/19 3:35 PM, Theo de Raadt wrote:
> Martijn van Duren wrote:
>
>> I think the others have given a decent explanation, but I would like to
>> elaborate a little furter.
>
> I strongly agree with your points, but a few comments.
>
>> OK, so strscpy won't read any more data from src than
Martijn van Duren wrote:
> I think the others have given a decent explanation, but I would like to
> elaborate a little furter.
I strongly agree with your points, but a few comments.
> OK, so strscpy won't read any more data from src than count bytes, which
> could save you from reading from
I think the others have given a decent explanation, but I would like to
elaborate a little furter.
The Linux documentation says the following:
Preferred to strlcpy since the API doesn't require reading memory from
the src string beyond the specified "count" bytes, and since the return
value is
On Sun, Jan 27, 2019 at 01:07:05AM -0500, 0sjfoij...@firemail.cc wrote:
> Recently on LCA2019, Joel Sing made a presentation about "Security
> Vulnerability Mitigations"[1]
> (very good, btw). He suggests function strlcpy(3) as a secure API.
> In the same conference, though, Kees Cook ("Making C
rc, sizeof dest) == -E2BIG) {
// overflow
}
and that strscpy() is essentially strlcpy() in NIH disguise:
ssize_t
strscpy(char *dest, const char *src, size_t count)
{
ssize_t ret;
if ((ret = strlcpy(dest, src, count)) >= count)
return -E2BIG;
retu
0sjfoij...@firemail.cc wrote:
> Recently on LCA2019, Joel Sing made a presentation about "Security
> Vulnerability Mitigations"[1]
> (very good, btw). He suggests function strlcpy(3) as a secure API.
> In the same conference, though, Kees Cook ("Making C Less Dangerous in
> the Linux kernel"[2]),
Recently on LCA2019, Joel Sing made a presentation about "Security
Vulnerability Mitigations"[1]
(very good, btw). He suggests function strlcpy(3) as a secure API.
In the same conference, though, Kees Cook ("Making C Less Dangerous in
the Linux kernel"[2]),
recommends strscpy() as more secure.
