KALLITHEA_EXTRAS environment variable missing

[Mads Kiilerich]

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