On 12/25/19 2:52 AM, Edmund Wong wrote:
Mads Kiilerich wrote:
On 12/24/19 7:49 AM, Ed Wong wrote:
Hi,
Just managed to work around the database unicode issue and
could both clone and push via the ssh:// url; however,
pushing to a git repository gave me the following 'error':
Total 3 (delta 1), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote: File "hooks/post-receive", line 38, in <module>
remote: main()
remote: File "hooks/post-receive", line 34, in main
...
line 538, in get_hook_environment
remote: raise Exception("Environment variable KALLITHEA_EXTRAS not
found")
remote: Exception: Environment variable KALLITHEA_EXTRAS not found
To seavcs:repos/infrastructure/testgit2
887eb3c..19b77cd master -> master
Apparently, it did save the push.
I've looked at the documentation; but haven't yet seen the mention
of the KALLITHEA_EXTRAS requirement. Looking at the code,
I'm not exactly sure what fields are required in the json
structure.
KALLITHEA_EXTRAS is used internally. The user invokes "kallithea-cli
ssh-serve" when connecting through ssh, and that sets this environment
variable before calling out to the git executable ... and when git
invoke the hooks and call back into Kallithea code in a grand-child
process, it can read the environment variable and report correctly who
is doing what.
It seems like you somehow end up invoking git directly when you ssh,
instead of hitting the kallithea-cli that should have been installed in
your ~/.ssh/authorized_keys ?
I guess we should make the hooks handle a missing KALLITHEA_EXTRAS in a
more elegant way ...
I think we should change Kallithea so you in this situation, instead of
the backtrace, should have seen something like:
[...]$ git push
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 204 bytes | 204.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Skipping Kallithea Git post-recieve hook 'hooks/post-receive'.
remote: Git was apparently not invoked by Kallithea: Environment
variable KALLITHEA_EXTRAS not found
To /tmp/kallithea-test-CQ8GMW/gggggggggg/
* [new branch] master -> master
[...]$
I think I know what is wrong. The problem is I also added the old
ssh-rsa entries to the authorized_keys file in the .ssh so that
I could also ssh into the system as the Kallithea user. Apparently,
that throws off the system. My bad.
Given how it works now, I guess we could improve by adding a first line
with a comment with a big fat warning as first line:
# This authorized_keys file is managed by Kallithea. Manual editing
or adding new entries will make Kallithea back off.
The problem you describe must be caused by a ssh:// url hitting a line
that *wasn't* added by Kallithea. Kallithea can't do anything about
that, other than telling people to not modify the file manually.
It would be bad if Kallithea removed or changed your line. Or added an
alternative entry for the same key. This example thus demonstrate the
challenge of having multiple owners of a single file ... and thus also
why Kallithea does a good thing by refusing to take part in shared
ownership.
Would it be more appropriate to scan the actual authorized_keys to
ensure it is in the proper formatting?
i.e.
ssh-rsa <key 1 blah...>
no-pty,no-port-forwarding... ssh-rsa <key 2 blah>
to
no-pty,no-port-forwarding... ssh-rsa <key 1 blah>
no-pty,no-port-forwarding... ssh-rsa <key 2 blah>
or add a flag at the beginning to tell kallithea to ignore the said
line?
Kallithea kind of already scans the file. And says no.
The system was deliberately designed to be very obnoxious. And reliable.
And secure. It *is* a system where less trusted users from their browser
can "modify" a file that by design can grant shell and access to
everything. We want to control that very tightly. The less input and
variables we have, the more obvious that there are no attack vectors.
Right now, we can guarantee that if you put any entries in the file,
then Kallithea won't remove them. It won't touch the file at all. The
model is very simple: Either you own the file, or Kallithea does.
We *could* make a more fancy system for categorization of entries and
merging/editing. But it would have to be 100% reliable. And it must be
very obvious to the system admin what it is doing so he can provide
exactly the access he want. We can perhaps consider the current
functionality a secure starting point. From there, we could make it less
paranoid if we really find a good way to do it.
But before modifying anything, please help improve the documentation and
UI so it makes it more clear how things work currently, so problems and
misunderstandings can be avoided.
/Mads
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
