openSUSE has issued an advisory for this today (August 6):
https://lists.opensuse.org/opensuse-updates/2018-08/msg00028.html

python-dulwich-0.12.0-1.1.mga6 uploaded which contains the upstream patch for CVE-2017-16228

CC: (none) => bruno
Assignee: python => qa-bugs
Status: NEW => ASSIGNED

python-dulwich-0.12.0-1.1.mga6
python3-dulwich-0.12.0-1.1.mga6

from python-dulwich-0.12.0-1.1.mga6.src.rpm

Since you patched it instead of updating it, what's the status of the other CVEs mentioned in Comment 0 for this version?

Keywords: (none) => feedback

Well I thought the policy was trying to keep versions on stable branches, thus I didn't updated, and also individual patches were mentioned, so that ease patching, and minimize risks.

In SUSE BR https://bugzilla.suse.com/show_bug.cgi?id=1066430 they mention the git commit id to be used to fix all the CVEs they mention (CVE-2017-9800, CVE-2017-12836, CVE-2017-12976, CVE-2017-1000116, and CVE-2017-1000117) and I used that patch as the base for ours.

I realized I had missed a portion of the patch, which is now fixed, thanks for making me look at it again! So python-dulwich-0.12.0-1.2.mga6 on its way and IMO it should contain everything needed (except if the SUSE BR is incomplete)

Advisory:
========================

Updated python-dulwich packages fix security vulnerability:

Dulwich, when an SSH subprocess is used, allowed remote attackers to execute
arbitrary commands via an ssh URL with an initial dash character in the hostname
(CVE-2017-16228).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16228
https://lists.opensuse.org/opensuse-updates/2018-08/msg00028.html
========================

Updated packages in core/updates_testing:
========================
python-dulwich-0.12.0-1.2.mga6
python3-dulwich-0.12.0-1.2.mga6

from python-dulwich-0.12.0-1.2.mga6.src.rpm

Keywords: feedback => (none)

MGA6-32 MATE on IBM Thinkpad R50e
No installation issues.
Clean install OK and no side effects noted, that's as far as my knowledge goes.

CC: (none) => herman.viaene

Mageia 6, x86_64

Familiarization:
This is a python based interface for accessing git repositories.  Installing it gives you /usr/bin/dulwich and /usr/bin/dulwich3 but I could not figure out how to run them but there is an introductory tutorial at https://www.dulwich.io/docs/tutorial/remote.html with a script which works as it is when run line by line using the python command-line interface, remembering to maintain the indentation structure.
e.g.
$ python
>>> from dulwich.repo import Repo
and so on.
stackoverflow contains some discussion on fetch using python dulwich.
https://stackoverflow.com/questions/34609308/how-to-fetch-using-dulwich-in-python

The link in the advisory; https://www.dulwich.io/code/dulwich/
shows a "getting started" exercise.  That does not work because it references a local repository unique to the author, as far as I can see.

CVE-2017-16228
There does not appear to be any exploit files posted for this bug.  Suse marks it as "in progress".

Updated the two packages - no problems.
Tried to run the introductory scripts interactively with python.

Discovered that the example given in "Getting started" fails because it relies on having already established a local repository.
$ python
Python 2.7.15 (default, May  1 2018, 17:08:05) 
[GCC 5.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from dulwich.repo import Repo
>>> r = Repo('.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/dulwich/repo.py", line 676, in __init__
    "No git repository was found at %(path)s" % dict(path=root)
dulwich.errors.NotGitRepository: No git repository was found at .
>>> exit()

The tutorial exercise also fails because  'repo' had already been defined before updating.  If you leave out the
>>> repo = Repo.init("remote", mkdir=True)
command then repo is undefined.
Next line:
>>> cid = repo.do_commit(b"message", committer=b"Jelmer <jelmer@samba.org>")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'repo' is not defined
>>>

Moving on to the second part of the tutorial, Tagging, did not work either.
>>> tree.add(tag, permissions, blob.id)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'tag' is not defined

The first tutorial script worked fine before the update so the moral of this story is to test it afterwards only.

None of this helps to confirm that the packages work so it is not clear where we should go from here.  There must be something else that we need to know to get started.

CC: (none) => tarazed25

Continuing from comment #7 on another machine - what was needed was closer inspection of the code.
Installed and updated the two packages.

Referred to the tutorial at https://www.dulwich.io/docs/tutorial/remote.html.
Ran the  example on the first page, changing name strings where necessary to avoid clashes with names used in earlier trials.  See the worksheet below; all tests worked without errors.

$ python
Python 2.7.15 (default, May  1 2018, 17:08:05) 
[GCC 5.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from dulwich.repo import Repo
>>> from dulwich.server import DictBackend, TCPGitServer
>>> import threading
>>> repo = Repo.init("repox", mkdir=True)
>>> cid = repo.do_commit(b"message", committer=b"Jelmer <jelmer@samba.org>")
>>> backend = DictBackend({b'/': repo})
>>> dul_server = TCPGitServer(backend, b'localhost', 0)
>>> threading.Thread(target=dul_server.serve).start()
>>> server_address, server_port=dul_server.socket.getsockname()
>>> from dulwich.client import TCPGitClient
>>> client = TCPGitClient(server_address, server_port)
>>> def determine_wants(refs):
...    return refs.values()
... 
>>> class DummyGraphWalker(object):
...     def ack(self, sha): pass
...     def next(self): pass
...     def __next__(self): pass
... 
>>> from io import BytesIO
>>> f = BytesIO()
>>> result = client.fetch_pack(b"/", determine_wants, DummyGraphWalker(), pack_data=f.write)
>>> print(f.getvalue()[:4].decode('ascii'))
PACK
>>> from dulwich.repo import Repo
>>> local = Repo.init("here", mkdir=True)
>>> remote_refs = client.fetch(b"/", local)
>>> dul_server.shutdown()

Tried to guess at a restart command and got into trouble.
All tries gave errors but the following seemed to detach it from the terminal:
>>> dul_server.serve()
and it needed to be killed from another terminal.
Normally one would exit from interactive mode by typing exit().

Repeated the whole exercise under python3 with identical results.

Decided not to take this any further because it is rather time-consuming and in view of the well-behaved tests it is safe to say that this is fine for 64-bits.

Whiteboard: (none) => MGA6-64-OK

Addendum to comment #8.  The local "repositories" appear as empty directories in the current directory so they need to be removed after testing.

Ahem.  Not quite empty;

$ ls -a remote/.git
./   branches/  description*  hooks/  objects/
../  config*    HEAD*         info/   refs/

Advisory from comment 5.
Saw no reason not to validate this after Len's great efforts. (You could have).

Keywords: (none) => advisory, validated_update
CC: (none) => lewyssmith, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0445.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED