Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab Direction

about.gitlab.com

Post reply on HN
Print view View original

101–110 of 137 posts

Re: GitLab Direction

#101

Post by jramsay »

Spidler wrote: post #26

What I'm missing is a different security model than the current `If an endpoint can push to gitlab, it is trusted and can execute code server-side`. There is no (current) way to enforce a 2fa step in order to push to a repository, and while you can technically implement them, that doesn't mean much, due to the nature of `git push`. What I want is a 2fa-enabled review boundary between "commit" and "execute", which cur…

Hi Spidler, I'm a Product Manager at GitLab. Thanks for the feedback. Solid security protecting deployment is very important.

In GitLab 10.7 we added branch unprotecting restrictions that can be managed through the API to restrict who can modify protected branch rules https://docs.gitlab.com/ee/api/protected_branches.html#prote..., and we'll be adding a UI to manage this soon too. I created https://gitlab.com/gitlab-org/gitlab-ce/issues/49513 to add an auth step for changing protected branches as well.

I'm interested to know more about the version number improvement you suggest too. There are a few similar proposals like automated tagging on merge https://gitlab.com/gitlab-org/gitlab-ce/issues/22363.

Re: GitLab Direction

#102

Post by tfha »

If you want to compete with GitHub for open source projects you are going to need a 'releases' page that's similar (at least in function) to github's.

I would like to see that prioritized more, I think it's more important for many projects looking to switch than many of the other features listed here

Re: GitLab Direction

#103

Post by AFNobody »

teraflop wrote: post #19
AFNobody wrote: post #15

Earlier quoted context omitted.

https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 When glaring security issues sit open for a year, you need to understand GitLab is a problem for anyone who has regular security audits. I am not asking for 100% redirection of resources to fix all the issues. I am suggesting they reprioritize resource allocation to lean more towards fixing issues that exist instead of new feature implementation.

It's not obvious to me that that's a glaring security issue. If the password were encrypted, then Gitlab would need to be able to decrypt it, so all you're gaining is a bit of security through obscurity. Which doesn't accomplish anything when it's a publicly documented feature of an open source project.

You clearly never worked at a large company with one-size fits all security directives such as "never store the password in plain text".

Re: GitLab Direction

#104

Post by AFNobody »

raesene9 wrote: post #60
teraflop wrote: post #19

Earlier quoted context omitted.

It's not obvious to me that that's a glaring security issue. If the password were encrypted, then Gitlab would need to be able to decrypt it, so all you're gaining is a bit of security through obscurity. Which doesn't accomplish anything when it's a publicly documented feature of an open source project.

I'd agree that, depending on usage model, this isn't a major issue, in that if you symmetrically encrypt a password, you still need to store the key somewhere to do the decryption. That said it is possible to improve the security of this kind of model, although there is a trade-off in availability. What can be done is that the decryption key (or a passphrase controlling access to it) is stored offline and manually in…

And that is the requirement enforced by IT in many companies with security audits.

Re: GitLab Direction

#105

Post by AFNobody »

omeid2 wrote: post #29
jmisavage wrote: post #23

Earlier quoted context omitted.

They have both SaaS and self-hosting options which cost considerable amount of cash ($99/mo per user for the most expensive option) for any large scale deployment. They're earning plenty and they need to fix what is valuable to their customers.

What makes you think they're not listening to their paid customers and fixing their needs? Paid customers get a direct contact.

It is blocking people from converting to paying customers because as soon as we see an issue like that we know it isn't viable because we'll get denied.

Re: GitLab Direction

#106

Post by tfha »

sytse wrote: post #4
AFNobody wrote: post #3

GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under control. This constant push for project management features, frankly, is at the expense of the core product. I'd rather use a combination of GitHub and JIRA over Gitlab.

What is the nr. 1 performance/ux/bugfix you would like to see? BTW This month we shipped 35 performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=... and there were 141 bugs closed in the release of this month https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...

Merge request page load times. Sometimes it can take like 5s for a merge request page to load (and then another 5s for the comments), and that's noticeably more frustrating than github's snappy UI. 5s isn't world ending but it is obviously slow and frustrating.

Re: GitLab Direction

#107

Post by nathan_f77 »

czechdeveloper wrote: post #74
nathan_f77 wrote: post #40

Earlier quoted context omitted.

I don't have any first-hand experience, and I'm sure there are exceptions. I've heard that GitLab will pay around $80k for a remote software engineer in a country with a low cost-of-living. That engineer could be earning $150k-$250k at a different company (e.g. Basecamp, GitHub, etc.) I realize that $80k is a lot of money for Europe/UK/Asia/South America/rest of the US. But if you're a top engineer, you could double…

This is really interesting. I live in Czech away from Prague and made a joke on local dev meetup that "I will not work for 22k". Answer was "everyone here wishes to work for 22k". I don't think anyone I know here makes anything close to 100k even in Prague. I should investigate this bit more to get closer to SF salaries if possible.

22k USD is far too low for a good developer. I’ve met a few developers from Eastern European countries that charge $100+ USD per hour.

You will always be able to find work at ~$70 per hour if you join TopTal. It should be easy to book projects for 30 hours per week and earn $100k USD per year. (Or you can work 6 hours per week to make $22k, if that’s all you need.)

That’s still on the low end for web/mobile dev. Top developers will charge 2x or 3x that amount (but you won’t find that work on Toptal.)

Full-time salaries will be lower than contract work, but it shouldn’t be difficult to find a remote web/mobile development job that pays $80k. (And that’s still very low for a good developer.)

Re: GitLab Direction

#108

Post by gitlab-security »

substring wrote: post #84

Gitlabs security is absolutely horrific: https://www.cvedetails.com/vulnerability-list/vendor_id-1307...

Thank you for the feedback. One of our core values is transparency. Very few companies are as transparent as GitLab. We take our users' data security extremely seriously. Since total CVE count is only one metric to measure the security maturity of an organization, allow me to provide you with other metrics that may help you understand what we're doing on our users' behalf.

Over the last 7 months, we have been focusing on mitigating security vulnerabilities that highly impact our users, where at least 25% of our users are affected. Since then, we've been able to bring the mean-time-to-mitigation (MTTM) for new, high-impact vulnerabilities to less than 30 days, which is below industry average for security vulnerability mitigations. However, we are not done securing GitLab of course, and are also working on maturing the security vulnerability mitigation process. Here are some goals that we've achieved over the last 6 months:

1. Developed and put into place two separate security release processes - a monthly non-critical security release process, focusing on reducing security debt, and a critical release process (on demand, as needed) when there is a new vulnerability discovered that impacts a significant number of users. https://gitlab.com/gitlab-org/release/docs/blob/master/gener...

2. GitLab continues to work with security researchers from the HackerOne program to recognize and reward bounties for their contributions. We have plans in place to expand on the existing HackerOne program by the end of 2018. The HackerOne program has been effective in assisting us with scaling our work with security vulnerability mitigations, because we have a small security team at GitLab, currently. https://hackerone.com/gitlab

3. Our 2018 (and beyond) Security Vision and Hiring Plan includes growing GitLab's internal security team further, and we will be making security research hires, in order to accelerate the security vulnerability mitigation efforts that we are working on maturing. https://about.gitlab.com/handbook/engineering/security/

If you have any further questions, please feel free to contact us directly at security@gitlab.com

Re: GitLab Direction

#110

Post by akerl_ »

Nokinside wrote: post #78
akerl_ wrote: post #77

Earlier quoted context omitted.

GitHub isn't open-source, so while you're correct about what open source licenses allow, that's not really tangible to the complaint that they ripped off GitHub.

I see. It seems you are right. Github is closed source, Gitlab CE is open source, Gitlab EE is closed source. Reframing the question: Isn't ripping of and competing with the implementation of an idea is just normal business. Or is there something like gentleman rule where you should not copy business ideas as fast as you can?

The initial GitLab UI felt a lot like a direct copy from GitHub.

I'd consider "normal business" to be some combination of creating new benefits for your service that your competitors don't have and replicating the kinds of benefits they add, hopefully doing them better.

As an example: both GitHub and GitLab have recently launched features in the "security monitoring for your projects" space, but they're both independently good features. Had GitLab launched the feature and then GitHub just copied all the css/js and stood up a clone of it, I'd consider that to be highly questionable.

Post reply on HN