4 ms·

Please do not follow this blog's advice of compiling your own cgit with a git pull off master; the blog author is now (a) using some random commit point (untag

Please do not follow this blog's advice of compiling your own cgit with a git pull off master; the blog author is now (a) using some random commit point (untaggged release) which contains who knows what, and (b) has to now manually upgrade cgit for the life of his server. At this exact moment there are 13 commits on master ahead of the latest tag, who knows what that might be. https://git.zx2c4.com/cgit/log/ https://git.zx2c4.com/cgit/log/ Find a repo (apt/PPA, dnf/EPEL, AUR, whatever works for you) and use a repo to manage your server software unless you have no other choice than to hand-compile it. Hand-compiling server daemons like this means they never get upgraded with bugfixes and CVE issues regularly - this isn't 1995, we did this back then because we had to do it. It's not a good idea in 2021 to be doing this unless you're going to hand-manage that cgit binary every day of your life going forward, this is an internet facing endpoint which will get people probing it to attack (assuming you used a cloud server). If nothing else, clone off the last tagged release by the upstream authors not HEAD.

mbreese 6y ago
I’m not going to disagree with you on the usage of package managers. No only is it easier to install, but easier to maintain. But, isn’t cgit basically read-only? If so, that doesn’t seem to be particularly risky. All of the main interactions with gitolite are through SSH, which I’d expect to be the main area of attack.
- drdec 6y ago
  > But, isn’t cgit basically read-only? So are SELECT statements until little Bobby Tables shows up. Which is to say that SQL injection can be used to turn read-only functionality into write functionality. Secondly, if you care about who has access to the data, even read-only vulnerabilities can be damaging.
  - mbreese 6y ago
    True, but exploiting cgit would be significantly more difficult than a SQL injection. I could only find a handful of CVEs for cgit, and the last one was in 2018 (v 1.2.1)[1]. It involved reading files outside the git tree. That said, it's not the common software to see publicly, so probably hasn't been thoroughly vetted. But I think the point still stands that installing from source isn't going to be a horrible security risk. Similarly though -- It is a mature project without a lot of new features. I don't think there are killer features in master that would make me want to install from source over `apt install cgit` [1] https://www.cvedetails.com/vulnerability-list/vendor_id-15775/product_id-33075/Cgit-Project-Cgit.html https://www.cvedetails.com/vulnerability-list/vendor_id-1577...
    - stonesweep 6y ago
      You don't know you have a CVE until you have a CVE, it's not hard to find any given story of bugs being found a decade later with high vulnerability scores. https://securityboulevard.com/2020/07/microsoft-patches-17-year-old-windows-vulnerability-with-cve-10-0-score/ https://securityboulevard.com/2020/07/microsoft-patches-17-y...
megous 6y ago
What's this scaremongering? It's a git repo, "who knows what" can be easily checked with a quick git diff ORIG_HEAD after a pull. And you actually see the changes you're going to be building, rather than relying on some random untrusted thirdparty repo or AUR package, that can be abandoned at any time, or worse. The update checking workflow can be as simple as putting the repo commit or tag list, or news feed into your RSS reader, and just do a quick check if update is warranted when you get some update in your feed. Many projects have an announce mailing list that you can subscribe to. There are special announce lists for security issues. And in case of cgit, if you're running a tagged release, how do you know that git 2.25.1 (some random release from a year ago) doesn't have any security vulnerabilities when used with cgit? Building from git and basing cgit on top of 2.30.0 seems a bit more reasonable to me in this case.
- matheusmoreira 6y ago
  AUR packages also make it easy for users to see what they're building. The PKGBUILD is just a script that downloads the software and builds it.
  - megous 6y ago
    Not really, if your workflow includes checking changes in the actual code.
matheusmoreira 6y ago
> this is an internet facing endpoint which will get people probing it to attack (assuming you used a cloud server) Honestly this is the number one problem with internet security today. Why are computers allowed to talk to strangers at all? They should just drop all data coming from unauthenticated connections. This would destroy the mass appeal of the modern internet but it makes a lot of sense for computers hosting personal services that are meant to be used by one or few users. Technologies such as port knocking and single packet authorization make vulnerabilities irrelevant since there's no way to exploit them before authenticating oneself.

mbreese 6y ago

I’m not going to disagree with you on the usage of package managers. No only is it easier to install, but easier to maintain. But, isn’t cgit basically read-only? If so, that doesn’t seem to be particularly risky. All of the main interactions with gitolite are through SSH, which I’d expect to be the main area of attack.

drdec 6y ago
> But, isn’t cgit basically read-only? So are SELECT statements until little Bobby Tables shows up. Which is to say that SQL injection can be used to turn read-only functionality into write functionality. Secondly, if you care about who has access to the data, even read-only vulnerabilities can be damaging.
- mbreese 6y ago
  True, but exploiting cgit would be significantly more difficult than a SQL injection. I could only find a handful of CVEs for cgit, and the last one was in 2018 (v 1.2.1)[1]. It involved reading files outside the git tree. That said, it's not the common software to see publicly, so probably hasn't been thoroughly vetted. But I think the point still stands that installing from source isn't going to be a horrible security risk. Similarly though -- It is a mature project without a lot of new features. I don't think there are killer features in master that would make me want to install from source over `apt install cgit` [1] https://www.cvedetails.com/vulnerability-list/vendor_id-15775/product_id-33075/Cgit-Project-Cgit.html https://www.cvedetails.com/vulnerability-list/vendor_id-1577...
  - stonesweep 6y ago
    You don't know you have a CVE until you have a CVE, it's not hard to find any given story of bugs being found a decade later with high vulnerability scores. https://securityboulevard.com/2020/07/microsoft-patches-17-year-old-windows-vulnerability-with-cve-10-0-score/ https://securityboulevard.com/2020/07/microsoft-patches-17-y...

megous 6y ago

What's this scaremongering? It's a git repo, "who knows what" can be easily checked with a quick git diff ORIG_HEAD after a pull. And you actually see the changes you're going to be building, rather than relying on some random untrusted thirdparty repo or AUR package, that can be abandoned at any time, or worse. The update checking workflow can be as simple as putting the repo commit or tag list, or news feed into your RSS reader, and just do a quick check if update is warranted when you get some update in your feed. Many projects have an announce mailing list that you can subscribe to. There are special announce lists for security issues. And in case of cgit, if you're running a tagged release, how do you know that git 2.25.1 (some random release from a year ago) doesn't have any security vulnerabilities when used with cgit? Building from git and basing cgit on top of 2.30.0 seems a bit more reasonable to me in this case.

matheusmoreira 6y ago
AUR packages also make it easy for users to see what they're building. The PKGBUILD is just a script that downloads the software and builds it.
- megous 6y ago
  Not really, if your workflow includes checking changes in the actual code.

matheusmoreira 6y ago

> this is an internet facing endpoint which will get people probing it to attack (assuming you used a cloud server) Honestly this is the number one problem with internet security today. Why are computers allowed to talk to strangers at all? They should just drop all data coming from unauthenticated connections. This would destroy the mass appeal of the modern internet but it makes a lot of sense for computers hosting personal services that are meant to be used by one or few users. Technologies such as port knocking and single packet authorization make vulnerabilities irrelevant since there's no way to exploit them before authenticating oneself.