patchtest-path-utils: use xsnprintf in favor of strcpy

> This shouldn't overflow, as we are copying a sha1 hex into a
> 41-byte buffer. But it does not hurt to use a bound-checking
> function, which protects us and makes auditing for overflows
> easier.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> These strcpy calls go away in jc/rerere-multi, so I was holding onto
> this to see if that graduated. But since that is stalled, I figured it
> cannot hurt to post (and the conflict resolution is obviously trivial).
>
> With this and the previous patch, it makes our code base strcpy free.
> Yay.

>
>  rerere.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rerere.c b/rerere.c
> index 403c700..587b7e2 100644
> --- a/rerere.c
> +++ b/rerere.c
> @@ -48,7 +48,7 @@ static int has_rerere_resolution(const struct rerere_id *id)
>  static struct rerere_id *new_rerere_id_hex(char *hex)
>  {
>  	struct rerere_id *id = xmalloc(sizeof(*id));
> -	strcpy(id->hex, hex);
> +	xsnprintf(id->hex, sizeof(id->hex), "%s", hex);
>  	return id;
>  }
>  
> @@ -904,7 +904,7 @@ int rerere_forget(struct pathspec *pathspec)
>  static struct rerere_id *dirname_to_id(const char *name)
>  {
>  	static struct rerere_id id;
> -	strcpy(id.hex, name);
> +	xsnprintf(id.hex, sizeof(id.hex), "%s", name);
>  	return &id;
>  }

> This strcpy will never overflow because it's copying from
> baked-in test data. But we would prefer to avoid strcpy
> entirely, as it makes it harder to audit for real security
> bugs.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Repost of <20160114202608.GA8806@sigill.intra.peff.net> from a few weeks
> ago (sorry, gmane is down so I can't generate a link). I think the
> original was never applied because the topic that introduced the strcpy
> (js/dirname-basename) predated xsnprintf, so there was some merging
> complexity. Now that topic is in master, so this can be applied there.

>
>  test-path-utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/test-path-utils.c b/test-path-utils.c
> index c3adcd8..6232dfe 100644
> --- a/test-path-utils.c
> +++ b/test-path-utils.c
> @@ -56,7 +56,7 @@ static int test_function(struct test_data *data, char *(*func)(char *input),
>  		if (!data[i].from)
>  			to = func(NULL);
>  		else {
> -			strcpy(buffer, data[i].from);
> +			xsnprintf(buffer, sizeof(buffer), "%s", data[i].from);
>  			to = func(buffer);
>  		}
>  		if (!strcmp(to, data[i].to))

> Jeff King <peff@peff.net> wrote:
> > Repost of <20160114202608.GA8806@sigill.intra.peff.net> from a few weeks
> > ago (sorry, gmane is down so I can't generate a link).
> 
> I prefer we use links derived from Message-IDs anyways.  This
> prevents reliance on gmane article numbers being a central point
> of failure:
> 
> http://marc.info/?i=$MESSAGE_ID
> http://mid.gmane.org/$MESSAGE_ID
> http://mid.mail-archive.com/$MESSAGE_ID

> This strcpy will never overflow because it's copying from
> baked-in test data. But we would prefer to avoid strcpy
> entirely, as it makes it harder to audit for real security
> bugs.
> 
> Signed-off-by: Jeff King <peff@peff.net>