From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: sahlberg@google.com, jrnieder@gmail.com, git@vger.kernel.org
Subject: Re: [PATCH] refs.c: add a function to append a reflog entry to a fd
Date: Wed, 19 Nov 2014 17:34:44 -0800 [thread overview]
Message-ID: <xmqqvbma4pu3.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqzjbm4qe5.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Wed, 19 Nov 2014 17:22:42 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> Stefan Beller <sbeller@google.com> writes:
>
>> Compared to the last send of this patch[1], there was one change in the print
>> function. Replaced sprintf by snprintf for security reasons.
>
> Careful. I despise people who blindly think strlcpy() and
> snprintf() are good solutions for for security. They are by
> themselves not.
> ...
> So use of snprintf() is not really buying you much here, not in the
> current code certainly, but not as a future-proofing measure,
> either.
Don't get me wrong. I am not saying that using snprintf() here is
bad per-se. There should be no difference.
But I do not want to see people getting in the habit of thinking "I
now use snprintf/strlcpy instead of sprintf/strcpy, and made my code
more secure." Often they are not doing that.
The only case snprintf/strlcpy is useful is when your data does not
matter in its detail. E.g. when you are preparing human-readble
data whose first part is sufficient to convey the information you
want to convey, you would be perfectly happy if the result is
truncated. In such a case, counting to allocate enough to hold
everything and running sprintf() only to chop the result later is
not necessary --- it still is not wrong, though --- and allocating
enough to satisify the eventual chop length and using snprintf()
is easier way to achieve the same result.
But I do not think this codepath falls into such an "I am willing to
lose data" case.
next prev parent reply other threads:[~2014-11-20 1:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 0:42 [PATCH] refs.c: add a function to append a reflog entry to a fd Stefan Beller
2014-11-20 1:22 ` Junio C Hamano
2014-11-20 1:34 ` Junio C Hamano [this message]
2014-11-20 2:05 ` Stefan Beller
2014-11-20 2:36 ` Jonathan Nieder
2014-11-20 16:57 ` Junio C Hamano
2014-11-20 18:37 ` [PATCH v3] " Stefan Beller
2014-11-20 21:20 ` Jonathan Nieder
2014-11-20 21:24 ` Stefan Beller
2014-11-20 21:31 ` Jonathan Nieder
2014-11-20 21:42 ` Junio C Hamano
2014-11-20 21:58 ` Stefan Beller
2014-11-20 22:05 ` Jonathan Nieder
2014-11-20 22:11 ` Junio C Hamano
2014-11-20 21:59 ` [PATCH v4] " Stefan Beller
2014-11-20 22:11 ` Jonathan Nieder
2014-11-20 22:29 ` Junio C Hamano
2014-11-20 1:42 ` [PATCH] " Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqvbma4pu3.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=sahlberg@google.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.