Bug 1112230 - git instaweb provides empty web
git instaweb provides empty web
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Development
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Markéta Machová
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-17 15:55 UTC by Michal Suchanek
Modified: 2020-05-01 22:27 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
observed web page (1.51 KB, application/xhtml+xml)
2019-07-15 08:58 UTC, Markéta Machová
Details
observed web page (2.07 KB, text/html)
2019-09-11 14:11 UTC, Michal Suchanek
Details
strace.out (243.03 KB, text/plain)
2019-09-12 11:44 UTC, Michal Suchanek
Details
Audit log (33.44 KB, text/x-log)
2019-10-03 12:12 UTC, Markéta Machová
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Suchanek 2018-10-17 15:55:31 UTC
git-2.13.7-13.1.src.rpm
Vendor      : openSUSE
Distribution: openSUSE Leap 42.3

The web content:

projects /

 re Search
List all projects
No such projects found
Click here to view all projects

I would expect that I can view the repository in which instaweb was started but there is no content whatsoever.
Comment 1 Takashi Iwai 2018-10-29 09:21:23 UTC
Leap 42.3 git package doesn't inherit from SLE12 but a fork.

As a new package maintainer, Jason, could you take a look at this bug?  Thanks!
Comment 2 Tomáš Chvátal 2019-07-11 11:35:11 UTC
This is automated batch bugzilla cleanup.

The openSUSE 42.3 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE (At this moment openSUSE Leap 15.1, 15.0 and Tumbleweed) please
feel free to reopen this bug against that version (!you must update the
"Version" component in the bug fields, do not just reopen please), or
alternatively create a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime
Comment 3 Michal Suchanek 2019-07-11 12:30:02 UTC
It gives a 500 on Tumbleweed
Comment 4 Markéta Machová 2019-07-15 07:27:54 UTC
This bug probably belongs to me. I will take a look. But if you notice something important, please let me know :) .
Comment 5 Markéta Machová 2019-07-15 08:58:31 UTC
Created attachment 810424 [details]
observed web page
Comment 6 Markéta Machová 2019-07-15 08:59:31 UTC
So, at first: git instaweb needs perl-CGI. After installation I got a proper webpage which told me "404 - No projects found". This could be just a misconfiguration. What do you think?

Of course I am going to add perl-CGI to gitweb requirements to fix this bug, but I am not sure whether this is a complete fix and I am a bit lazy to play with the git configuration...
Comment 7 Michal Suchanek 2019-07-15 09:18:38 UTC
According to man page it is not supposed to be configured.

Especially no option to find the projects is documented. I would assume it will serve whatever repo you started it in.
Comment 8 Markéta Machová 2019-07-15 11:31:08 UTC
Well, there are (or apparently were) many config gotchas: https://stackoverflow.com/questions/10275536/configuring-gitweb-404-no-projects-found

I don't want to go through this...
Comment 9 Michal Suchanek 2019-07-15 14:26:31 UTC
It is for the case when Apache is used. Also it is a configuration that seems to be trying to serve multiple git repositories.

It should not be the default so this gotcha does not apply. And if it does apply the defaults should be changed so that it just works as described in the man page. Or alternatively the man page should be amended to list all steps necessary to serve the current repository with instaweb.
Comment 10 Markéta Machová 2019-07-16 12:19:50 UTC
OK, another approach: sure there has to be a configuration. But this configuration is generated automatically and it is stored in .git/gitweb/gitweb_config.perl. There are some settings which should be sufficient for the right function.

The piece of code which is responsible for this is /usr/share/gitweb/gitweb.cgi. When you look into it (line 732), it reads some conf files and it decides which conf file to use according to some environment variables. If these are set (probably it should be set to the path to local conf), it uses the conf it was told, otherwise it uses the global conf.

That's the theory, in praxis it did not work to me even with the GITWEB_CONFIG set explicitely. And I do not understand how Perl handles environment variables... I think there is some bug in our system confing, either in Perl and its $ENV{} or in bash and exporting its variables. 

But I did not test whether the local conf is actually read, I only think it is not.
Comment 11 Markéta Machová 2019-07-17 09:27:31 UTC
Did a quick test: at my Tumbleweed I have modified gitweb.cgi (I only added some prints). 

I called 'git instaweb' in the repo fks-texmf placed in my home. The command 'print "Read $GITWEB_CONFIG. The root is $projectroot.\n"' placed right after 'read_config_file($GITWEB_CONFIG)' told me:
"Read /home/meggy/fks-texmf/.git/gitweb/gitweb_config.perl. The root is /srv/git."

So it reads the correct $GITWEB_CONFIG, but the $projectroot remains the same... puzzled.
Comment 12 Markéta Machová 2019-07-17 11:01:08 UTC
What happens there: instead of reading the config file we are launching it. It is OK, we have shebang in the file. The file is maybe not really launched, even when I set the executable bits... but that is unlikely.

The file .git/gitweb/gitweb_config.perl is re-genetared for some reason...

In either case .git/gitweb/gitweb_config.perl does not propagate its $projectroot to /usr/share/gitweb/gitweb.cgi and that is the root of our bug.

Do you have any idea why this does happen? In both cases the variable $projectroot is defined as 'our' (public).
Comment 13 Markéta Machová 2019-07-22 15:05:26 UTC
At least I know it is not platform-independent bug, instaweb on (at least some kind of) Debian is not affected. Michal, do you have some insight into SUSE Perl specifics, please?
Comment 14 Michal Suchanek 2019-07-22 15:16:35 UTC
No idea. If it works on Debian it is often advisable to look at their patches.
Comment 15 Markéta Machová 2019-09-11 11:54:26 UTC
This bug still remains on Tumbleweed (git version 2.23.0), and I more and more think it is a perl bug (upstream apparenly has no problem with it).

The command git web--browse (which is part of git instaweb) works OK. The problem is only in (not) reading the config file.

Michael, could you please give me some hint what is going on?
Comment 16 Michael Schröder 2019-09-11 12:41:33 UTC
Sorry, it works for me. Both with apache and lighttpd. I also added your debug statement and I get:

Read /suse/mls/libsolv/.git/gitweb/gitweb_config.perl. The root is /suse/mls/libsolv.

Can you please paste your home/meggy/fks-texmf/.git/gitweb/gitweb_config.perl file?
Comment 17 Markéta Machová 2019-09-11 12:49:22 UTC
#!/usr/bin/perl
our $projectroot = "/home/meggy/fks-texmf";
our $git_temp = "/home/meggy/fks-texmf/.git/gitweb/tmp";
our $projects_list = $projectroot;

# we can trust our own repository, so disable XSS prevention
# to enable some extra features
our $prevent_xss = 0;

$feature{'remote_heads'}{'default'} = [1];
Comment 18 Michael Schröder 2019-09-11 12:58:57 UTC
This works for me. Are you sure that there is no /etc/gitweb.conf or /etc/gitweb-common.conf?
Comment 19 Markéta Machová 2019-09-11 13:50:41 UTC
meggy@linux-ky5i:~/buildservice $ echo /etc/gi*
/etc/gimp
meggy@linux-ky5i:~/buildservice $ 

pretty sure :( well, I am using Tumbleweed, so I am not testing it on clean instalation. I can not be sure it is not misconfigured.

Michal, you are the reporter. Did you test it on your machine?
Comment 20 Michal Suchanek 2019-09-11 14:11:01 UTC
Created attachment 817823 [details]
observed web page

$ ls .git/
branches        COMMIT_EDITMSG~  description  HEAD   index  logs     ORIG_HEAD    refs
COMMIT_EDITMSG  config           FETCH_HEAD   hooks  info   objects  packed-refs
$ git --version
git version 2.22.0
$ ls /etc/git*
ls: cannot access '/etc/git*': No such file or directory
$ wget http://localhost:1234
--2019-09-11 16:09:15--  http://localhost:1234/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:1234... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:1234... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2116 (2.1K) [text/html]
Saving to: ‘index.html’
Comment 21 Michal Suchanek 2019-09-11 14:12:07 UTC
$ ls -l .git/gitweb/
total 8
-rw-r--r-- 1 hramrach users  304 Sep 11 16:08 gitweb_config.perl
drwxr-xr-x 2 hramrach users   23 Sep 11 16:08 lighttpd
-rw-r--r-- 1 hramrach users 2959 Sep 11 16:08 lighttpd.conf
drwxr-xr-x 2 hramrach users    6 Sep 11 16:08 tmp
$ cat .git/gitweb/gitweb_config.perl
#!/usr/bin/perl
our $projectroot = "/home/michal/kmod";
our $git_temp = "/home/michal/kmod/.git/gitweb/tmp";
our $projects_list = $projectroot;

# we can trust our own repository, so disable XSS prevention
# to enable some extra features
our $prevent_xss = 0;

$feature{'remote_heads'}{'default'} = [1];
Comment 22 Markéta Machová 2019-09-11 14:55:02 UTC
Thanks, Michal. So we both are observing this bug.

Michael, did it help?
Comment 23 Michael Schröder 2019-09-11 15:24:23 UTC
Hmm, I notice that it says "No such projects found" instead of "No projects found". That means that git_get_projects_list() returned some project, but it was filtered out later.
Comment 24 Michael Schröder 2019-09-11 15:24:51 UTC
What's the output of:

git for-each-ref '--format=%(committer) XX' '--sort=-committerdate' '--count=1'
Comment 25 Michal Suchanek 2019-09-11 16:01:27 UTC
$ git for-each-ref '--format=%(committer) XX' '--sort=-committerdate' '--count=1'
Lucas De Marchi <lucas.demarchi@intel.com> 1559082138 -0700 XX
Comment 26 Michal Suchanek 2019-09-11 16:39:47 UTC
Read /home/michal/kmod/.git/gitweb/gitweb_config.perl. The root is /srv/git.
Comment 27 Michal Suchanek 2019-09-11 16:40:31 UTC
$ perl --version

This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux-thread-multi
$ cat /etc/os-release 
NAME="openSUSE Leap"
VERSION="15.0"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.0"
PRETTY_NAME="openSUSE Leap 15.0"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.0"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
Comment 28 Michael Schröder 2019-09-12 09:13:38 UTC
What do you mean with "The root is /srv/git"? In Comment #21 you said that /home/michal/kmod/.git/gitweb/gitweb_config.perl contains:

our $projectroot = "/home/michal/kmod";
Comment 29 Michal Suchanek 2019-09-12 09:30:18 UTC
That's what the debug print outputs.
Comment 30 Michael Schröder 2019-09-12 10:03:36 UTC
And /srv/git exists? I'm asking because if I tweak the code so that
it sets the projectroot to /srv/git I get a "No projects found" error, which is different from what you get.

So I'm a bit unsure if your debug output really does what it should. Can you paste the lines in /usr/share/gitweb/gitweb.cgi that contain your debug print statement?
Comment 31 Michal Suchanek 2019-09-12 10:31:01 UTC
yes, /srv/git exists and contains symlinks to some bare repositories.

In the meantime I upgraded to 2.23.0 which has this code:

        # Use first config file that exists.  This means use the per-instance
        # GITWEB_CONFIG if exists, otherwise use GITWEB_SYSTEM_CONFIG.
        read_config_file($GITWEB_CONFIG) and return;
        read_config_file($GITWEB_CONFIG_SYSTEM);

adding the extra "and return". This should prevent overriding configuration with system settings (which don't exist anyway). Nonetheless besides inability to add the debug print after read_config_file($GITWEB_CONFIG) the behavior does not change.

sub read_config_file {
        my $filename = shift;
        return unless defined $filename;
        # die if there are errors parsing config file
        if (-e $filename) {
                do $filename;
                die $@ if $@;
                print "Read $filename. The root is $projectroot.\n";
                return 1;
        }
        return;
}

Read /home/michal/kmod/.git/gitweb/gitweb_config.perl. The root is /srv/git.

$ cat .git/gitweb/gitweb_config.perl
#!/usr/bin/perl
our $projectroot = "/home/michal/kmod";
our $git_temp = "/home/michal/kmod/.git/gitweb/tmp";
our $projects_list = $projectroot;

# we can trust our own repository, so disable XSS prevention
# to enable some extra features
our $prevent_xss = 0;

$feature{'remote_heads'}{'default'} = [1];
Comment 32 Michael Schröder 2019-09-12 10:58:53 UTC
I don't get why it works for me and not for you. Can you please
add

print "projectroot $projectroot $::projectroot";

to the end of /home/michal/kmod/.git/gitweb/gitweb_config.perl and reload
the page? (Don't run git instaweb as it overwrites the config.)
Comment 33 Michael Schröder 2019-09-12 10:59:46 UTC
(Oops, forgot a \n in the print statement)
Comment 34 Michal Suchanek 2019-09-12 11:04:17 UTC
It is not printed anywhere. The page starts with

Read /home/michal/kmod/.git/gitweb/gitweb_config.perl. The root is /srv/git.
Status: 200 OK
Content-Type: application/xhtml+xml; charset=utf-8
Comment 35 Michael Schröder 2019-09-12 11:22:50 UTC
So what does it read? Let's try an strace.

Please run

GITWEB_CONFIG=/home/michal/kmod/.git/gitweb/gitweb_config.perl strace -o strace.out -s 1024 /usr/share/gitweb/gitweb.cgi

and attach the strace.out file.
Comment 36 Michal Suchanek 2019-09-12 11:44:53 UTC
Created attachment 817999 [details]
strace.out

stat("/etc/gitweb-common.conf", 0x55cf3756e2a0) = -1 ENOENT (No such file or directory)
stat("/home/michal/kmod/.git/gitweb/gitweb_config.perl", {st_mode=S_IFREG|0644, st_size=356, ...}) = 0
stat("/home/michal/kmod/.git/gitweb/gitweb_config.perl", {st_mode=S_IFREG|0644, st_size=356, ...}) = 0
openat(AT_FDCWD, "/home/michal/kmod/.git/gitweb/gitweb_config.perl", O_RDONLY) = -1 EACCES (Permission denied)
Comment 37 Michael Schröder 2019-09-12 12:53:02 UTC
Oh my god, it's apparmor! There's an apparmor profile that restricts access.
Check out the /etc/apparmor.d/usr.share.git-web.gitweb.cgi profile.

There needs to be a

 /**/gitweb_config.perl r,

line that allows accessing the config.
Comment 38 Michael Schröder 2019-09-12 13:05:11 UTC
(Maybe you also need some other lines to allow it access to other parts of the .git directory as well)
Comment 39 Michal Suchanek 2019-09-12 13:17:44 UTC
aa-disable /etc/apparmor.d/usr.share.git-web.gitweb.cgi allows starting instaweb.

AFAICT there is no sensible way to start it other than disabling the profile completely.
Comment 40 Markéta Machová 2019-09-12 14:59:01 UTC
Thank you very much for explaining this bug. At least we know it is not perl neither upstream bug.

So the StackOverflow answer in Comment 8 was partially correct (it suggested AppArmor), but we all forgot about it. Could it help with finding the correct AppArmor config?

Thank you very much again :) I will think about sensible patch...
Comment 41 Markéta Machová 2019-10-03 08:12:55 UTC
Hi, this bug looks purely as apparmor. Christian, could you please look at it and suggest any fix? I am quite new in apparmor and I am unable to find a solution. Disabling the whole apparmor profile could possibly open a security hole.
Comment 42 Christian Boltz 2019-10-03 11:27:47 UTC
First we'll find out which things get denied by AppArmor ;-)

For this, please
- run   aa-complain /etc/apparmor.d/usr.share.git-web.gitweb.cgi
  This will put the profile to complain/learning mode - allow everything,
  but log what would be denied.
- if you used aa-disable before, restart git-web to make sure the AppArmor
  profile gets used
- use git-web as usual for a while
- attach /var/log/audit/audit.log to this bugreport ;-) - it contains
  everything AppArmor would have denied, and is the base for updating the
  profile.
Comment 43 Markéta Machová 2019-10-03 12:12:47 UTC
Created attachment 820430 [details]
Audit log

Thanks for the guide, here is the log :)
Comment 44 Christian Boltz 2019-10-03 15:47:29 UTC
According to your log, you'll need to add the following rules:

a) things that you can easily add to the packaged profile:

  @{PROC}/loadavg r,

and (see below for details and the reason)

  #include if exists <local/usr.share.git-web.gitweb.cgi>

Technically, the placement of rules inside the profiles doesn't matter, but in practise we typically sort the rules alphabetically, so put the @{PROC} rule next to the /proc rules. For local includes, the tradition is to have them at the end of the profile.


b) things that are specific to your setup

  /home/meggy/fks-texmf/ r,
  /home/meggy/fks-texmf/**/ r,
  /home/meggy/fks-texmf/.git/** r,

I'm slightly surprised that only files in .git were read, but not in the checked-out repo (while only directory listings were done). If my surprise is correct, you'll need (instead of the 3 rules above):

  /home/meggy/fks-texmf/ r,
  /home/meggy/fks-texmf/** r,

Obviously allowing to read files and directories in your home directory doesn't make sense in the official profile (which allows /srv/git/ by default), and IMHO extending the profile to read _all_ files and directories would be a terrible idea. Therefore, I'd recommend to add

  #include if exists <local/usr.share.git-web.gitweb.cgi>

to the shipped profile.

You can then create the file /etc/apparmor.d/local/usr.share.git-web.gitweb.cgi and add the rules that are specific to your setup.


Once you are sure that your profile is complete, run
    aa-enforce /etc/apparmor.d/usr.share.git-web.gitweb.cgi
to switch it back into enforce mode.


BTW: Your audit.log also included a denial for colord - SR 734825 sent ;-)
Comment 45 Markéta Machová 2019-10-04 08:10:57 UTC
Hi, thanks for the analysis. 

But it does not cure the bug. It would be very nice if the command "git instaweb" worked in any git repo I have cloned, moreover it looks like correct behaviour. But I have to add paths for any specific repository to the config if I want to use "git instaweb". Which means, when I call "git instaweb" in a random repo I get 404, which is the original reported bug.

Does here exist any rule which would say "if you see any .git/gitweb/gitweb_config.perl, allow it, since it is probably in some git repo and /usr/share/gitweb/gitweb.cgi leads to it"?
Comment 46 Christian Boltz 2019-10-04 21:50:14 UTC
(In reply to Marketa Calabkova from comment #45)
> But it does not cure the bug. It would be very nice if the command "git
> instaweb" worked in any git repo I have cloned, moreover it looks like
> correct behaviour. But I have to add paths for any specific repository to
> the config if I want to use "git instaweb". Which means, when I call "git
> instaweb" in a random repo I get 404, which is the original reported bug.

Right. This behaviour is "technically correct" from the AppArmor side, but I fully understand that you'd prefer "git instaweb" to work everywhere ;-)

> Does here exist any rule which would say "if you see any
> .git/gitweb/gitweb_config.perl, allow it, since it is probably in some git
> repo and /usr/share/gitweb/gitweb.cgi leads to it"?

No, unfortunately this is not possible :-(

Options I see are:
- have a script that updates the AppArmor profile on the fly, similar to what is
  done for the samba profile. In theory this would be the perfect solution, but
  in practise there's a serious problem - you'll need root permissions to load
  the updated profile into the kernel.
- add a rule to allow reading files and directories everywhere.
  Needless to say that this makes the profile, well, less useful. (It will
  still prevent writing files, executing binaries etc.)

The second option might sound somewhat scary, and it is - but it's not completely scary :-)

Some testing shows that you'll need to add the following rules to enable "git instaweb" independent of the location of your repo:

  /proc/loadavg r,
  owner /**/ r,  # allow directory listings everywhere (!)
  owner /**/.git/** r,  # allow reading reading everything inside .git directories
  owner @{HOME}/.gitconfig r,
  #include <abstractions/private-files-strict>

"/**/ r," means that git-web can read directory listings everywhere (which means it could leak filenames and the directory structure). The log indicates that it goes through the directories inside the git repo (outside of .git), but I have no idea why - in the end, it only reads files that live inside the .git directory, therefore getting directory listings of the whole repo looks pointless to me.

This is something you might want to discuss with upstream - find out why git-web does all those directory listings and if this is really needed. Without them, we could make the profile more restrictive and only allow reading everything in .git directories.

Note that I used the "owner" restriction, which means that the user running "git instaweb" must also be the owner of the files and directories in the git repo.
(Repos in /srv/git/ still have their separate rule without owner restriction.)

I hope this restriction is ok. Otherwise, we'll get to a somewhat scary detail of "all directory listings" - this includes /proc/, /dev/ and /sys/ where the directory listing might already expose sensitive data. The easy way is to whitelist specific common directories ("/home/**/ r,"). Allowing "everything except /proc, /sys and /dev" is also possible, but results in ugly and hard to read rules ;-)


The next rule allows reading all files (only) inside .git directories - which is exactly the job of git-web. In theory you could fine-tune this rule by listing individual files and subdirectories, but unless .git contains "secret" files that git-web doesn't need to access, that's probably not worth the effort.

(Luckily git-web does not read all the files outside the .git directory.)

Allowing to read ~/.gitconfig should be obvious ;-)

abstractions/private-files-strict denies access to several dot files and directories in the home directory - for example .ssh and .gnupg. It's not perfect, but at least is a safety net to prevent the most critical stuff.


You probably know git much better than I do (actually I tried instaweb for the first time when seeing this bugreport), so please test the proposed rules and check if you get additional entries in the audit.log.
Comment 47 Markéta Machová 2019-10-07 10:13:00 UTC
Sorry, I have to write down what we already know. The purpose of "git instaweb" is to browse the repo in internet browser, which means it has to have read access to all the files in the repo (I can click on these files and see their content). It starts browsing from $project root, which is set in .git/gitweb/gitweb_config.perl as the repository. When I click on "tree", I get (at least virtually) to the repository main folder, but I see only the files known to git... I need to find out whether it accesses also the files which are not known to git. The files which are known to git are written down in .git/index and at least some of them are also in objects/pack/pack-*, I need to find out what type of format it is and how to get its contents.

All over, I can not see the way how to access the files in the repository through .git yet, in my opinion "git instaweb" has to acces the main repository folder... which causes the problem when I omit "owner /**/ r," from the rules. Or can you see any reasonable way?
Comment 48 Markéta Machová 2019-10-07 11:04:59 UTC
It looks like /home/meggy/fks-texmf/ was the only thing missing to launch the web with omitted "/**/ r," (when I add the rule "/home/meggy/fks-texmf/ r,", everything starts working). So all the other files are probably available from .git. This kind of makes sense, but it looks like it is not possible to restrict the "/**/" rule without loss of functionability and generality :( .
Comment 49 Markéta Machová 2019-10-07 12:20:40 UTC
... but when you restrict the permissions to owner, I think it is OK. Regular user does not need to launch instaweb in foreign repositories and a more advanced user is able to modify the profile himself. Thanks a lot!

I have already created a SR: https://build.opensuse.org/request/show/735832
Comment 50 Markéta Machová 2019-10-14 10:50:41 UTC
Let's mark it as FIXED. Everybody, thanks for your help!
Comment 57 Swamp Workflow Management 2020-04-28 10:36:22 UTC
SUSE-SU-2020:1121-1: An update that solves 15 vulnerabilities and has 8 fixes is now available.

Category: security (moderate)
Bug References: 1063412,1095218,1095219,1110949,1112230,1114225,1132350,1149792,1156651,1158785,1158787,1158788,1158789,1158790,1158791,1158792,1158793,1158795,1167890,1168930,1169605,1169786,1169936
CVE References: CVE-2017-15298,CVE-2018-11233,CVE-2018-11235,CVE-2018-17456,CVE-2019-1348,CVE-2019-1349,CVE-2019-1350,CVE-2019-1351,CVE-2019-1352,CVE-2019-1353,CVE-2019-1354,CVE-2019-1387,CVE-2019-19604,CVE-2020-11008,CVE-2020-5260
Sources used:
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src):    git-2.26.1-3.25.2
SUSE Linux Enterprise Module for Development Tools 15-SP1 (src):    git-2.26.1-3.25.2
SUSE Linux Enterprise Module for Basesystem 15-SP1 (src):    git-2.26.1-3.25.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 58 Swamp Workflow Management 2020-05-01 22:27:18 UTC
openSUSE-SU-2020:0598-1: An update that solves 15 vulnerabilities and has 8 fixes is now available.

Category: security (moderate)
Bug References: 1063412,1095218,1095219,1110949,1112230,1114225,1132350,1149792,1156651,1158785,1158787,1158788,1158789,1158790,1158791,1158792,1158793,1158795,1167890,1168930,1169605,1169786,1169936
CVE References: CVE-2017-15298,CVE-2018-11233,CVE-2018-11235,CVE-2018-17456,CVE-2019-1348,CVE-2019-1349,CVE-2019-1350,CVE-2019-1351,CVE-2019-1352,CVE-2019-1353,CVE-2019-1354,CVE-2019-1387,CVE-2019-19604,CVE-2020-11008,CVE-2020-5260
Sources used:
openSUSE Leap 15.1 (src):    git-2.26.1-lp151.4.9.1