git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: NGUYEN Huynh Khoi Nguyen <nguyenhu@ensimag.imag.fr>
Cc: git@vger.kernel.org, Matthieu.Moy@grenoble-inp.fr,
	NGUYEN Huynh Khoi Nguyen <nguyenhu@ensibm.imag.fr>
Subject: Re: [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file
Date: Fri, 25 May 2012 16:30:56 -0400	[thread overview]
Message-ID: <20120525203056.GC4364@sigill.intra.peff.net> (raw)
In-Reply-To: <1337975239-17169-1-git-send-email-nguyenhu@ensibm.imag.fr>

On Fri, May 25, 2012 at 09:47:18PM +0200, NGUYEN Huynh Khoi Nguyen wrote:

> git will store its configuration in ~/.config/git/config file if this file
> exists and ~/.gitconfig file doesn't, otherwise git store its configuration
> in ~/.gitconfig as usual

What about reading? For maximum compatibility, we should always read
from _both_ of them, and choose between them only when writing, no? It
looks like your patch will only read from one or the other.

At first people will have only one or the other, but people using
multiple versions of git, or people following already-written
instructions on the web about modifying ~/.gitconfig could end up with
both.

> --- a/builtin/config.c
> +++ b/builtin/config.c
> @@ -171,8 +171,20 @@ static int get_value(const char *key_, const char *regex_)
>  	if (!local) {
>  		const char *home = getenv("HOME");
>  		local = repo_config = git_pathdup("config");
> -		if (home)
> -			global = xstrdup(mkpath("%s/.gitconfig", home));
> +		if (home) {
> +			char gitconfig_path[PATH_MAX], config_path[PATH_MAX];
> +			FILE *gitconfig_file, *config_file;
> +
> +			sprintf(gitconfig_path, "%s/.gitconfig", home);
> +			sprintf(config_path, "%s/.config/git/config", home);

These are both exploitable buffer overflows. Why not use mkpath?

> +			gitconfig_file = fopen(gitconfig_path, "r");
> +			config_file = fopen(config_path, "r");

So we open both files. It looks like in an attempt to see if they are
readable. But:

  1. No need to go to that much work. You can just call access(R_OK).

  2. You never close the files, so you are leaking memory and file
     descriptors.

> +			if (gitconfig_file==NULL && config_file!=NULL)

Style. We put whitespace around comparison operators, and we usually
don't refer to NULL specifically, like:

  if (!gitconfig_file && config_file)


So a simpler way to write this section would be something like:

  if (home) {
          const char *path = mkpath("%s/.config/git/config", home);

          if (!access(path, R_OK))
                  global = xstrdup(path);
          else
                  global = xstrdup(mkpath("%s/.gitconfig", home));
  }

But like I said earlier, I think this should really be reading from
_both_, which is a different change altogether.

I won't go through the other two hunks individually, but my comments are
similar.

-Peff

  parent reply	other threads:[~2012-05-25 20:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-25 19:47 [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file NGUYEN Huynh Khoi Nguyen
2012-05-25 19:47 ` [PATCH 2/2] Test File Name: t1306-second-config-file.sh NGUYEN Huynh Khoi Nguyen
2012-05-25 20:30 ` Jeff King [this message]
2012-05-25 21:25   ` [PATCH 1/2] Add possibility to store configuration in ~/.config/git/config file Junio C Hamano
2012-05-25 21:44     ` Jeff King
2012-05-26 10:15       ` Nguyen Thai Ngoc Duy
2012-05-26 21:54         ` Jeff King
2012-05-28 21:05           ` David Aguilar
2012-05-26  9:05     ` Matthieu Moy
2012-05-25 21:26 ` jaseem abid
2012-05-26  8:53 ` Matthieu Moy
2012-05-26 21:49   ` Jeff King
  -- strict thread matches above, loose matches on Subject: below --
2012-05-28 16:16 nguyenhu

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=20120525203056.GC4364@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=nguyenhu@ensibm.imag.fr \
    --cc=nguyenhu@ensimag.imag.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).