GNU bug report logs - #16843
Error caused due to regression in git

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Darshit Shah <darnir <at> gmail.com>
Subject: bug#16843: closed (Re: bug#16843: Error caused due to regression
 in git)
Date: Mon, 24 Feb 2014 20:12:04 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#16843: Error caused due to regression in git

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 16843 <at> debbugs.gnu.org.

-- 
16843: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16843
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eric Blake <eblake <at> redhat.com>
To: Darshit Shah <darnir <at> gmail.com>, 16843-done <at> debbugs.gnu.org
Subject: Re: bug#16843: Error caused due to regression in git
Date: Mon, 24 Feb 2014 13:11:34 -0700

[Message part 3 (text/plain, inline)]

tag 16843 notabug
thanks

On 02/22/2014 02:01 AM, Darshit Shah wrote:
> automake --version: 1.14.1
> autoconf --version: 2.69
> 
> The error occured when attempting to run the test suite GNU Wget's git
> source.

Then this bug should be filed against wget, not automake.  I'm closing
this bug in the automake tracker, as the fix is for wget to upgrade to a
newer version of gnulib, and automake has no bearing on it.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Darshit Shah <darnir <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Error caused due to regression in git
Date: Sat, 22 Feb 2014 10:01:21 +0100

[Message part 6 (text/plain, inline)]

automake --version: 1.14.1
autoconf --version: 2.69

The error occured when attempting to run the test suite GNU Wget's git
source.
`make` works correctly, but `make check` happens to fail with the following
output:

if test -d ./.git                               \
        && git --version >/dev/null 2>&1; then                  \
  cd . &&                                               \
  git submodule --quiet foreach                                 \
      test '"$(git rev-parse "$sha1")"'                 \
      = '"$(git merge-base origin "$sha1")"'                    \
    || { echo 'maint.mk: found non-public submodule commit' >&2;        \
         exit 1; };                                             \
else                                                            \
  : ;                                                           \
fi
Stopping at 'gnulib'; script returned non-zero status.
maint.mk: found non-public submodule commit
maint.mk:1394: recipe for target 'public-submodule-commit' failed
make: *** [public-submodule-commit] Error 1


In the repository, gnulib is used as a submodule. Running:
$ git submodule foreach echo $name, $path, $sha1
returns an empty string which implies that git is unable to see the
submodules correctly.

I bisected the git source to find the commit causing the problems. The
following is the commit message:

commit 1c4fb136dbad762c9c4350ee79c3474ae8037587
Author: Anders Kaseorg <andersk <at> MIT.EDU>
Date:   Fri Sep 27 06:23:55 2013 -0400

    submodule foreach: skip eval for more than one argument

    'eval "$@"' creates an extra layer of shell interpretation, which is
    probably not expected by a user who passes multiple arguments to git
    submodule foreach:

     $ git grep "'"
     [searches for single quotes]
     $ git submodule foreach git grep "'"
     Entering '[submodule]'
     /usr/lib/git-core/git-submodule: 1: eval: Syntax error: Unterminated
quoted string
     Stopping at '[submodule]'; script returned non-zero status.

    To fix this, if the user passes more than one argument, execute "$@"
    directly instead of passing it to eval.

    Examples:

     * Typical usage when adding an extra level of quoting is to pass a
       single argument representing the entire command to be passed to the
       shell.  This doesn't change that.

     * One can imagine someone feeding untrusted input as an argument:

        git submodule foreach git grep "$variable"

       That currently results in a nonobvious shell code injection
       vulnerability.  Executing the command named by the arguments
       directly, as in this patch, fixes it.

    Signed-off-by: Anders Kaseorg <andersk <at> mit.edu>
    Acked-by: Johan Herland <johan <at> herland.net>
    Signed-off-by: Jonathan Nieder <jrnieder <at> gmail.com>


Hence, this seems to me as a feature, not a bug in Git. Maybe, automake
needs to fix its scripts accordingly? Because the issue with `make check`
was introduced through this specific commit.

Do let me know if I can provide any more help.
Also, I am not sunscribed to this mailing list, hence, please ensure to
leave my email in the CC list.

-- 
Thanking You,
Darshit Shah

[Message part 7 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.