4 ms·

> But there is much noise to filter through in the many tools we juggle these days, especially if an organization prefers to self-host. If an organization is t

> But there is much noise to filter through in the many tools we juggle these days, especially if an organization prefers to self-host. If an organization is too overloaded to patch for six months, maybe they should re-evaluate if self-hosting is the best course of action. Seems like this is a foot-gun of your own creation.

Gigachad 5y ago
There is very little reason to even self host Gitlab unless you are insanely paranoid or for philosophy reasons like debian/gnome.
- pm90 5y ago
  Compliance often forces the hand.
  - deleted 5y ago
    [deleted]
- sslalready 5y ago
  Reasons for self-hosting: GitLab.com's not-so-great availability [1], slow code searches (compared to self-hosted with GitLab Advanced Search) and the fact that you can keep your code and resources off the public Internet. The fact that you do need to upgrade it yourself regularly is indeed a drawback. On the other hand, an Omnibus upgrade has only failed me twice in the last five years or so, so there's little reason to not do automatic upgrades at night and fire off an alert in case something doesn't work as expected afterwards. Their releases are typically solid, so kudos to the team. [1] https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7 https://status.gitlab.com/pages/history/5b36dc6502d06804c083...
- mdoms 5y ago
  Sorry but this comment strikes me as incredibly ignorant. There are lots of good reasons to self host, chief among them reasons which can't be worked around - compliance and data sovereignty.
  - Gigachad 5y ago
    Already covered those under paranoid. There is nothing wrong with self hosting and being paranoid. But that comes with the responsibility to have someone dedicated to keeping up with the latest news on the software they run. Leaving gitlab unpatched for 6 months shows that the company is not capable of running it themselves and should not be self hosting.
    - throw3455aerr 5y ago
      It is false to tell people that self-hosting has to be that hard. If you know what you are doing and put the services in a jail / VM only not being exposed to the internet, you can leave things unpatched very long, and only update them when bug fixes or new features of recent versions are needed. If you are a 50,000 people company where your own employees could be the adversaries maybe not. But in this case you also have the budget to have a proper security team. Apart from this case, with proper virtualization and no direct internet exposure, you'll find out that 99.99% of CVEs are not a risk to you. If you are under-budgeted, it's fine to neglect such internal services and check vulnerabilities once a year or less. However always stay on top of the CVEs of internet facing services. My point is your message is basically the propaganda of cloud services "doing it yourself is HARD", "email is HARD", "this and that is HARD" lol. Self-hosting in jails not being directly exposed to the internet is a productivity booster as it allows you to not fix what works FOR YOU. Just keep using this 4 years old version if it works well for you. But make informed choices as much as possible, try to stay on top of CVEs even if you decide not to patch these internal services 99% of the time. But even if you can't stay on top of your non-internet facing jails, it won't be a real risk 99% of the time.
- danudey 5y ago
  My company self-hosts Gitlab, but our instance is inside of our internal network, with no access to the internet, in or out, and almost no access to the corporate network, in or out. Every net/host and port is whitelisted, every change is documented and challenged (do you really need this port?), and you need to use 2FA to access it via HTTP or SSH. Suffice to say, we fall under "insanely paranoid".
- 2ion 5y ago
  In EU, some sectors that are doing business with public institutions are effectively barred from using US clouds, esp. in education, as contracts tend to demand a degree of control and assurement that no US hyperscaler or SaaS is going to give you. Also let's not forget that self-hosted still offers features SaaS does not, such as server hooks, which are absolutely not uncommon in grown environments based on gitolite etc looking to migrate.

Gigachad 5y ago

There is very little reason to even self host Gitlab unless you are insanely paranoid or for philosophy reasons like debian/gnome.

pm90 5y ago
Compliance often forces the hand.
- deleted 5y ago
  [deleted]
sslalready 5y ago
Reasons for self-hosting: GitLab.com's not-so-great availability [1], slow code searches (compared to self-hosted with GitLab Advanced Search) and the fact that you can keep your code and resources off the public Internet. The fact that you do need to upgrade it yourself regularly is indeed a drawback. On the other hand, an Omnibus upgrade has only failed me twice in the last five years or so, so there's little reason to not do automatic upgrades at night and fire off an alert in case something doesn't work as expected afterwards. Their releases are typically solid, so kudos to the team. [1] https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7 https://status.gitlab.com/pages/history/5b36dc6502d06804c083...
mdoms 5y ago
Sorry but this comment strikes me as incredibly ignorant. There are lots of good reasons to self host, chief among them reasons which can't be worked around - compliance and data sovereignty.
- Gigachad 5y ago
  Already covered those under paranoid. There is nothing wrong with self hosting and being paranoid. But that comes with the responsibility to have someone dedicated to keeping up with the latest news on the software they run. Leaving gitlab unpatched for 6 months shows that the company is not capable of running it themselves and should not be self hosting.
  - throw3455aerr 5y ago
    It is false to tell people that self-hosting has to be that hard. If you know what you are doing and put the services in a jail / VM only not being exposed to the internet, you can leave things unpatched very long, and only update them when bug fixes or new features of recent versions are needed. If you are a 50,000 people company where your own employees could be the adversaries maybe not. But in this case you also have the budget to have a proper security team. Apart from this case, with proper virtualization and no direct internet exposure, you'll find out that 99.99% of CVEs are not a risk to you. If you are under-budgeted, it's fine to neglect such internal services and check vulnerabilities once a year or less. However always stay on top of the CVEs of internet facing services. My point is your message is basically the propaganda of cloud services "doing it yourself is HARD", "email is HARD", "this and that is HARD" lol. Self-hosting in jails not being directly exposed to the internet is a productivity booster as it allows you to not fix what works FOR YOU. Just keep using this 4 years old version if it works well for you. But make informed choices as much as possible, try to stay on top of CVEs even if you decide not to patch these internal services 99% of the time. But even if you can't stay on top of your non-internet facing jails, it won't be a real risk 99% of the time.
danudey 5y ago
My company self-hosts Gitlab, but our instance is inside of our internal network, with no access to the internet, in or out, and almost no access to the corporate network, in or out. Every net/host and port is whitelisted, every change is documented and challenged (do you really need this port?), and you need to use 2FA to access it via HTTP or SSH. Suffice to say, we fall under "insanely paranoid".
2ion 5y ago
In EU, some sectors that are doing business with public institutions are effectively barred from using US clouds, esp. in education, as contracts tend to demand a degree of control and assurement that no US hyperscaler or SaaS is going to give you. Also let's not forget that self-hosted still offers features SaaS does not, such as server hooks, which are absolutely not uncommon in grown environments based on gitolite etc looking to migrate.