Subject: bug#16843: closed (Re: bug#16843: Error caused due to regression in git)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 24 Feb 2014 20:12:04 +0000

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 [email-masked].

-- 
16843: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16843
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#16843: Error caused due to regression in git
From: Eric Blake <[email-masked]>
To: Darshit Shah <[email-masked]>, [email-masked]
Date: Mon, 24 Feb 2014 13:11:34 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: Error caused due to regression in git
From: Darshit Shah <[email-masked]>
To: [email-masked]
Date: Sat, 22 Feb 2014 10:01:21 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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 <[email-masked]>
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 <[email-masked]>
    Acked-by: Johan Herland <[email-masked]>
    Signed-off-by: Jonathan Nieder <[email-masked]>

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