This project is mirrored from https://git.kernel.org/pub/scm/git/git.git. Updated .
  1. 18 Nov, 2019 1 commit
    • Jeff King's avatar
      gitweb: escape URLs generated by href() · a376e37b
      Jeff King authored
      There's a cross-site scripting problem in gitweb, where it will print
      URLs generated by its href() helper without further quoting. This allows
      an attacker to point a victim to a specially crafted gitweb URL and
      inject arbitrary HTML into the resulting page (which the victim sees as
      coming from gitweb).
      
      The base of the URL comes from evaluate_uri(), which pulls the value of
      $REQUEST_URI via the CGI module. It tries to strip off $PATH_INFO, but
      fails to do so in some cases (including ones that contain special
      characters, like "+"). Most of the uses of the URL end up being passed
      to "$cgi->a(-href = href())", which will get quoted properly by the CGI
      module. But in a few places, we output them ourselves as part of
      manually-generated HTML, and whatever was in the original URL will
      appear unquoted in the output.
      
      Given that all of the nearby variables placed into this manual HTML
      _are_ quoted, it seems like the authors assumed that these URLs would
      not need quoting. So it's possible that the bug is actually in
      evaluate_uri(), which should be doing a more careful job of stripping
      $PATH_INFO. There's some discussion in a comment in that function, as
      well as the commit message in 81d3fe9f (gitweb: fix wrong base URL
      when non-root DirectoryIndex, 2009-02-15). But I'm not sure I understand
      it.
      
      Regardless, it's a good idea to quote these values at the point of
      insertion into the HTML output:
      
        1. Even if there is a bug in evaluate_uri(), this would give us
           belt-and-suspenders protection.
      
        2. evaluate_uri() is only handling the base. Some generated URLs will
           also mention arbitrary refs or filenames in the repositories, and
           these should be quoted anyway.
      
        3. It should never _hurt_ to quote (and that's what all of the
           $cgi->a() calls are doing already).
      
      So there may be further work here, but this patch at least prevents the
      XSS vulnerability, and shouldn't make anything worse.
      
      The test here covers the calls in print_feed_meta(), but I manually
      audited every call to href() to see how its output was used, and quoted
      appropriately. Most of them are esc_attr(), as they're used in tag
      attributes, but I used esc_html() when the URLs were printed bare. The
      distinction is largely academic, as one is implemented as a wrapper for
      the other.
      Reported-by: default avatarNAKAYAMA DAISUKE <nakyamad@icloud.com>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a376e37b
  2. 10 Nov, 2019 1 commit
  3. 28 Oct, 2019 1 commit
  4. 01 Apr, 2019 1 commit
    • brian m. carlson's avatar
      gitweb: make hash size independent · cfb04911
      brian m. carlson authored
      Gitweb has several hard-coded 40 values throughout it to check for
      values that are passed in or acquired from Git.  To simplify the code,
      introduce a regex variable that matches either exactly 40 or exactly 64
      hex characters, and use this variable anywhere we would have previously
      hard-coded a 40 in a regex.
      
      Add some helper functions which allow us to write tighter regexes that
      match exactly the number of hex characters we're expecting.
      
      Similarly, switch the code that looks for deleted diffinfo information
      to look for either 40 or 64 zeros, and update one piece of code to use
      this function.  Finally, when formatting a log line, allow an
      abbreviated describe output to contain up to 64 characters.
      Helped-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cfb04911
  5. 05 Mar, 2018 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      gitweb: hard-depend on the Digest::MD5 5.8 module · 7d5b30e0
      Ævar Arnfjörð Bjarmason authored
      Since my d48b2841 ("perl: bump the required Perl version to 5.8 from
      5.6.[21]", 2010-09-24), we've depended on 5.8, so there's no reason to
      conditionally require Digest::MD5 anymore. It was released with perl
      v5.7.3[1]
      
      The initial introduction of the dependency in
      e9fdd74e ("gitweb: (gr)avatar support", 2009-06-30) says as much,
      this also undoes part of the later 2e9c8789 ("gitweb: Mention
      optional Perl modules in INSTALL", 2011-02-04) since gitweb will
      always be run on at least 5.8, so there's no need to mention
      Digest::MD5 as a required module in the documentation, let's instead
      say that we require perl 5.8.
      
      1. $ corelist Digest::MD5
         Data for 2015-02-14
         Digest::MD5 was first released with perl v5.7.3
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      7d5b30e0
  6. 24 Oct, 2017 1 commit
  7. 22 Aug, 2017 1 commit
  8. 18 Jul, 2017 1 commit
  9. 27 Jun, 2017 1 commit
  10. 15 May, 2017 1 commit
  11. 14 Oct, 2016 3 commits
    • Ævar Arnfjörð Bjarmason's avatar
      gitweb: link to "git describe"'d commits in log messages · cf5c7253
      Ævar Arnfjörð Bjarmason authored
      Change the log formatting function to know about "git describe" output
      such as "v2.8.0-4-g867ad08a", in addition to just plain "867ad08a".
      
      There are still many valid refnames that we don't link to
      e.g. v2.10.0-rc1~2^2~1 is also a valid way to refer to
      v2.8.0-4-g867ad08a, but I'm not supporting that with this commit,
      similarly it's trivially possible to create some refnames like
      "æ/var-gf6727b05" or which won't be picked up by this regex.
      
      There's surely room for improvement here, but I just wanted to address
      the very common case of sticking "git describe" output into commit
      messages without trying to link to all possible refnames, that's going
      to be a rather futile exercise given that this is free text, and it
      would be prohibitively expensive to look up whether the references in
      question exist in our repository.
      
      There was on-list discussion about how we could do better than this
      patch. Junio suggested to update parse_commits() to call a new
      "gitweb--helper" command which would pass each of the revision
      candidates through "rev-parse --verify --quiet". That would cut down
      on our false positives (e.g. we'll link to "deadbeef"), and also allow
      us to be more aggressive in selecting candidate revisions.
      
      That may be too expensive to work in practice, or it may
      not. Investigating that would be a good follow-up to this patch.
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Acked-by: Jakub Narębski's avatarJakub Narębski <jnareb@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cf5c7253
    • Ævar Arnfjörð Bjarmason's avatar
      gitweb: link to 7-char+ SHA-1s, not only 8-char+ · 8059966c
      Ævar Arnfjörð Bjarmason authored
      Change the minimum length of an abbreviated object identifier in the
      commit message gitweb tries to turn into link from 8 hexchars to 7.
      
      This arbitrary minimum length of 8 was introduced in bfe2191f ("gitweb:
      SHA-1 in commit log message links to "object" view", 2006-12-10), but
      the default abbreviation length is 7, and has been for a long time.
      
      It's still possible to reference SHA-1s down to 4 characters in length,
      see v1.7.4-1-gdce96489's MINIMUM_ABBREV, but I can't see how to make
      git actually produce that, so I doubt anyone is putting that into log
      messages in practice, but people definitely do put 7 character SHA-1s
      into log messages.
      
      I think it's fairly dubious to link to things matching [0-9a-fA-F]
      here as opposed to just [0-9a-f], that dates back to the initial
      version of gitweb from 161332a5 ("first working version",
      2005-08-07). Git will accept all-caps SHA-1s, but didn't ever produce
      them as far as I can tell.
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Acked-by: Jakub Narębski's avatarJakub Narębski <jnareb@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8059966c
    • Ævar Arnfjörð Bjarmason's avatar
      gitweb: fix a typo in a comment · 26547bfb
      Ævar Arnfjörð Bjarmason authored
      Change a typo'd MIME type in a comment. The Content-Type is
      application/xhtml+xml, not application/xhtm+xml.
      
      Fixes up code originally added in 53c40311 ("gitweb: Strip
      non-printable characters from syntax highlighter output", 2011-09-16).
      Signed-off-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Acked-by: Jakub Narębski's avatarJakub Narębski <jnareb@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      26547bfb
  12. 25 Sep, 2016 2 commits
    • Ian Kelling's avatar
      gitweb: use highlight's shebang detection · 779a2066
      Ian Kelling authored
      The "highlight" binary can, in some cases, determine the language type
      by the means of file contents, for example the shebang in the first line
      for some scripting languages.  Make use of this autodetection for files
      which syntax is not known by gitweb.  In that case, pass the blob
      contents to "highlight --force"; the parameter is needed to make it
      always generate HTML output (which includes HTML-escaping).
      
      Although we now run highlight on files which do not end up highlighted,
      performance is virtually unaffected because when we call highlight, it
      is used for escaping HTML.  In the case that highlight is used, gitweb
      calls sanitize() instead of esc_html(), and the latter is significantly
      slower (it does more, being roughly a superset of sanitize()).  Simple
      benchmark comparing performance of 'blob' view of files without syntax
      highlighting in gitweb before and after this change indicates ±1%
      difference in request time for all file types.  Benchmark was performed
      on local instance on Debian, using Apache/2.4.23 web server and CGI.
      
      Document the feature and improve syntax highlight documentation, add
      test to ensure gitweb doesn't crash when language detection is used.
      Signed-off-by: Ian Kelling's avatarIan Kelling <ian@iankelling.org>
      Acked-by: Jakub Narębski's avatarJakub Narębski <jnareb@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      779a2066
    • Ian Kelling's avatar
  13. 01 Aug, 2016 1 commit
  14. 03 May, 2016 1 commit
    • Shin Kojima's avatar
      gitweb: apply fallback encoding before highlight · 029f3721
      Shin Kojima authored
      Some multi-byte character encodings (such as Shift_JIS and GBK) have
      characters whose final bytes is an ASCII '\' (0x5c), and they
      will be displayed as funny-characters even if $fallback_encoding is
      correct.  This is because `highlight` command always expects UTF-8
      encoded strings from STDIN.
      
          $ echo 'my $v = "申";' | highlight --syntax perl | w3m -T text/html -dump
          my $v = "申";
      
          $ echo 'my $v = "申";' | iconv -f UTF-8 -t Shift_JIS | highlight \
              --syntax perl | iconv -f Shift_JIS -t UTF-8 | w3m -T text/html -dump
      
          iconv: (stdin):9:135: cannot convert
          my $v = "
      
      This patch prepare git blob objects to be encoded into UTF-8 before
      highlighting in the manner of `to_utf8` subroutine.
      Signed-off-by: default avatarShin Kojima <shin@kojima.org>
      Reviewed-by: Jakub Narębski's avatarJakub Narębski <jnareb@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      029f3721
  15. 12 Jan, 2016 1 commit
  16. 18 Nov, 2014 1 commit
    • Jeff King's avatar
      gitweb: hack around CGI's list-context param() handling · 13dbf46a
      Jeff King authored
      As of CGI.pm's 4.08 release, the behavior to call
      CGI::param() in a list context is deprecated (because it can
      be potentially unsafe if called inside a hash constructor).
      This causes gitweb to issue a warning for some of our code,
      which in turn causes the tests to fail.
      
      Our use is in fact _not_ one of the dangerous cases, as we
      are intentionally using a list context. The recommended
      route by 4.08 is to use the new CGI::multi_param() call to
      make it explicit that we know what we are doing.
      However, that function is only available in 4.08, which is
      about a month old; we cannot rely on having it.
      
      One option would be to set $CGI::LIST_CONTEXT_WARN globally,
      which turns off the warning. However, that would eliminate
      the protection these newer releases are trying to provide.
      We want to annotate each site as OK using the new function.
      
      So instead, let's check whether CGI provides the
      multi_param() function, and if not, provide an
      implementation that just wraps param(). That will work on
      both old and new versions of CGI. Sadly, we cannot just
      check defined(\&CGI::multi_param), because CGI uses the
      autoload feature, which claims that all functions are
      defined. Instead, we just do a version check.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      13dbf46a
  17. 16 Oct, 2014 1 commit
  18. 31 Mar, 2014 1 commit
  19. 20 Feb, 2014 1 commit
  20. 12 Dec, 2013 4 commits
  21. 30 Aug, 2013 1 commit
    • Ævar Arnfjörð Bjarmason's avatar
      gitweb: Fix the author initials in blame for non-ASCII names · fd87004e
      Ævar Arnfjörð Bjarmason authored
      Change the @author_initials feature Jakub added in
      v1.6.4-rc2-14-ga36817b6 to match non-ASCII author initials as intended.
      
      The regexp Jakub added was intended to match
      non-ASCII (/\b([[:upper:]])\B/g). But in Perl this doesn't actually
      match non-ASCII upper-case characters unless the string being matched
      against has the UTF8 flag.
      
      So when we open a pipe to "git blame" we need to mark the file
      descriptor we're opening as utf8 explicitly.
      
      So as a result it abbreviates me to "AB" not "ÆAB", entirely because "Æ"
      isn't /[[:upper:]]/ unless the string being matched against has the UTF8
      flag.
      
      Here's something that demonstrates the issue:
      
          #!/usr/bin/env perl
          use strict;
          use warnings;
      
          binmode STDOUT, ':utf8' if $ENV{UTF8};
          open my $fd, "-|", "git", "blame", "--incremental", "--", "Makefile" or die "Can't open: $!";
          binmode $fd, ":utf8" if $ENV{UTF8};
          while (my $line = <$fd>) {
          	next unless my ($author) = $line =~ /^author (.*)/;
          	my @author_initials = ($author =~ /\b([[:upper:]])\B/g);
          	printf "%s (%s)\n",  join("", @author_initials), $author;
          }
      
      When that's run with and without UTF8 being true in the environment it
      gives, on git.git:
      
          $ UTF8=0 perl author-initials.pl | sort | uniq -c |
          sort -nr | head -n 5
               99 JH (Junio C Hamano)
               35 JN (Jonathan Nieder)
               35 JK (Jeff King)
               20 JS (Johannes Schindelin)
               16 AB (Ævar Arnfjörð Bjarmason)
          $ UTF8=1 perl author-initials.pl | sort | uniq -c |
          sort -nr | head -n 5
               99 JH (Junio C Hamano)
               35 JN (Jonathan Nieder)
               35 JK (Jeff King)
               20 JS (Johannes Schindelin)
               16 ÆAB (Ævar Arnfjörð Bjarmason)
      Acked-by: Jakub Narębski's avatarJakub Narębski <jnareb@gmail.com>
      Tested-by: Ævar Arnfjörð Bjarmason's avatarÆvar Arnfjörð Bjarmason <avarab@gmail.com>
      Tested-by: Simon Ruderich's avatarSimon Ruderich <simon@ruderich.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      fd87004e
  22. 20 Aug, 2013 4 commits
  23. 05 Jul, 2013 1 commit
  24. 07 Jun, 2013 1 commit
    • Charles McGarvey's avatar
      gitweb: fix problem causing erroneous project list · ca7a5dcf
      Charles McGarvey authored
      The bug is manifest when running gitweb in a persistent process (e.g.
      FastCGI, PSGI), and it's easy to reproduce.  If a gitweb request
      includes the searchtext parameter (i.e. s), subsequent requests using
      the project_list action--which is the default action--and without
      a searchtext parameter will be filtered by the searchtext value of the
      first request.  This is because the value of the $search_regexp global
      (the value of which is based on the searchtext parameter) is currently
      being persisted between requests.
      
      Instead, clear $search_regexp before dispatching each request.
      Signed-off-by: Charles McGarvey's avatarCharles McGarvey <chazmcgarvey@brokenzipper.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ca7a5dcf
  25. 15 Apr, 2013 1 commit
  26. 12 Apr, 2013 2 commits
  27. 07 Mar, 2013 1 commit
  28. 29 Jan, 2013 1 commit
  29. 02 Jan, 2013 1 commit
  30. 11 Dec, 2012 1 commit
    • Matthew Daley's avatar
      gitweb: Sort projects with undefined ages last · 28dae181
      Matthew Daley authored
      Sorting gitweb's project list by age ('Last Change') currently shows
      projects with undefined ages at the head of the list. This gives a less
      useful result when there are a number of projects that are missing or
      otherwise faulty and one is trying to see what projects have been
      updated recently.
      
      Fix by sorting these projects with undefined ages at the bottom of the
      list when sorting by age.
      Signed-off-by: default avatarMatthew Daley <mattjd@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      28dae181