1. 18

kmx git started as a front-end for git-auth, a simple rule based ACL auth shell on top of git-shell.

Security is our main goal, private repos should not leak and the whole system can be exposed on the web without trouble. I see many gitlab instances behind a VPN and I find this pointless. If your service cannot handle the web its just badly written, right ?

It’s just basic Elixir / Phoenix handing off git tasks to the mainline git binary using Erlang ports. So if you care about security you should also audit git itself.

The main files to check are the controllers in lib/kmxgit_web/controllers and also a few files in lib/kmxgit/

Even admins cannot get access to private source code through the app. They can if they bypass the application if they already have a root shell for instance.

We do not track users or transmit any data to third parties except recaptcha just for login and register.

Please let us know if you find a bug by joining on the Discord or sending us an email.


    1. 4

      The reason to put gitlab behind a VPN is not because gitlab can’t handle web, it’s to prevent a case of someone mistakenly marking something public, when it should be private. People usually don’t pay attention to the type of the repo after it has been set up.

      1. 1

        Then it will be public to all your VPN users. Why is that better ? By the way anyone who clones your repo can publish it somewhere else and make it public. How do you handle that with a VPN ?

        1. 3

          Well, it can be better because only company users have access to the VPN and the repository, thus severely limiting the impact of someone accidentally making the repo public.

          I don’t understand the second point? If someone can access any repo, they can publish it anywhere else, with or without VPN, regardless of the hosting system. But publishing it is way more complicated than accidentally making something public, so it’s not a risk I would go and mitigate against.

    2. 2

      Removing a repository calls rm -rf in a shell, from what I can tell reading the code. This gives me the willies, but I haven’t been able to come up with what it is that makes it feel wrong. The repository directory seems to be in the control of the server.

      Anyone know if this is or isn’t a reasonable way to blow away a directory from the back end of a web app? I think it’s just the number of moving parts involved that make me uncomfortable- I would have first reached for language support but then started thinking about malicious or accidental hard links and other complications.

      1. 1

        I plan on doing a bug bounty on the code once I fixed all the small bugs that remain.

        The “rm -rf” is not currently problematic as dotfiles are not allowed in the argument : it’s just a slug. Anyway what do you propose instead ? Should I rewrite “rm -rf” in an elixir command to make you happy ? I trust more the system “rm -rf” than my own code for error handling.

        1. 1

          I wasn’t making a criticism, just wondering how people would approach this in a way that makes it easy to be comfortable that it won’t accidentally do the wrong thing.

    3. [Comment removed by author]