Issue #333: git hooks have an incorrect interpreter when installed under uwsgi
| Reported by: | Thomas De Schampheleire |
| State: | resolved |
| Created on: | 2019-02-18 09:11 |
| Updated on: | 2019-04-30 22:31 |
Description
The shebang for git hooks is determined via: (kallithea/model/scm.py)
tmpl_pre = "#!/usr/bin/env %s\n" % sys.executable or 'python2'
When Kallithea is run via uwsgi, 'sys.executable' is the uwsgi process, not the python interpreter. As a result, pushing to a git repo gives following error:
$ git push Password for 'http://user@localhost:5050': Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 241 bytes | 241.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: unable to load configuration from hooks/pre-receive To http://localhost:5050/gitrepo-new ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'http://user@localhost:5050/gitrepo-new'
There is a second issue reported on IRC by where the shebang uses '/usr/bin/python' when Kallithea is started using Apache+WSGI. It may or may not be the same issue).
Attachments
Comments
Comment by Thomas De Schampheleire, on 2019-02-18 18:35
The use of sys.executable in this code was introduced with commit 5e501b6ee639c2cf25080ba8c3d53f4e4b6ad32e .
Comment by Mads Kiilerich, on 2019-02-19 02:04
If modwsgi uses '/usr/bin/python' then that must be a problem of modwsgi ... or configurable?
But I can see how uwsgi also kind of is right.
Can we enumerate in which cases we want which? Can we imagine a heuristic that really cover all cases and not just the cases we happen to come up with? Perhaps use a more complex heuristic ... and make it configurable to override that? Perhaps only use sys.executable if the last slash is followed by python?
Comment by Thomas De Schampheleire, on 2019-04-01 20:28
I sent a proposal to the mailing list. Checking for the literal string 'python' in sys.executable is also not waterproof: someone could have made a wrapper to Python called 'mython' or 'mypython' etc. The proposal is not waterproof in the Windows case without virtualenv, but I think it's not very common. https://lists.sfconservancy.org/pipermail/kallithea-general/2019q2/002982.html
Comment by Mads Kiilerich, on 2019-04-30 22:31
Resolved in 1bafb2d07709 and 6df08d78f8e7