91–100 of 159 posts
Earlier quoted context omitted.
That's a funny double standard you have right there with how you don't feel the need to audit GitHub before using it.
> That's a funny double standard you have right there with how you don't feel the need to audit GitHub before using it. Where did I ever say I use Github with confidence ? I've answered this several times below: I use software all the time that I do not feel confident about. My statement was about hopefully being able to use GitLab with confidence, which is a goal that is only attainable because I can deploy it on my…
GitHub has to have revenue to continue to operate. I'd rather GitHub go down the road of enterprise and other paid contracts, rather than going down the road of becoming SourceForge and all the ickiness that that entailed.
Has anyone noticed that the GitHub reviews on Glassdoor.com only start from May 19th, 2015? Have they been deleting bad reviews? Seems really suspicious. https://www.glassdoor.com/Reviews/GitHub-Reviews-E671945_P3....
Here's your average glassdoor post:
Weh! Weh weh weh weh weh! Mih mih mih! Boo hoo! Poopy!
The only reason I still use Github is because of the network effect. If they fall apart, I'll migrate to a self-hosted Gitlab instance and that will be the end of that. I'm just hoping that, should GH fail, it hold off on failing until I learn Ruby sufficiently well to review the entire GL code base so I can deploy it with confidence . EDIT: Yes, "with confidence" is a very important qualifier that is drastically imp…
That's a funny double standard you have right there with how you don't feel the need to audit GitHub before using it.
It is unlikely that Gitlab has endured the kind of scrutiny Github's code has.
Welcome to reality, GitHubbers. Not sure how else you expect a 500+ person company to run itself.
Earlier quoted context omitted.
> That's a funny double standard you have right there with how you don't feel the need to audit GitHub before using it. Where did I ever say I use Github with confidence ? I've answered this several times below: I use software all the time that I do not feel confident about. My statement was about hopefully being able to use GitLab with confidence, which is a goal that is only attainable because I can deploy it on my…
No, that's reasonable. Thank you for clarifying, especially the distinction regarding GitLab being self-hostable and open-source. Apologies if my comment came off as accusatory, I really did find it funny—as in peculiar—because I have seen people have a bias towards the quality of open-source software even though the closed-source alternative is opaque.
This thread has been a land mine of accusatory reactions, so I apologize for painting yours in a similar brush.
> I have seen people have a bias towards the quality of open-source software even though the closed-source alternative is opaque
Reverse engineering isn't hard, it's just a speed-bump.
I work on a lot of open source projects. At the risk of sounding self-promotional to on-lookers, I'd like to talk about one in particular:
https://github.com/paragonie/random_compat
https://packagist.org/packages/paragonie/random_compat
Random_compat has been downloaded almost 2 million times (according to Packagist), incorporated into WordPress, Laravel, Symfony, etc. It's by far the most collaborative project that Paragon Initiative Enterprises has produced for the open source community.
Yet, until the most recent release, the documentation referred to a MCRYPT_CREATE_IV constant that does not exist. The correct constant is MCRYPT_DEV_URANDOM. Somehow, we all missed it.
"Open source is automatically more secure" is a fallacy. I just happen to like open source better, personally.
Aside: despite being downloaded ~1.9 million times, a grand total 30 people outside of Paragon have contributed to its development in some way so far. The "many eyes" are actually quite sparse, especially when it comes to security expertise. (I think it's reasonable to say those 30 represent much of the the upper 0.01% of security talent in the PHP community.)
Earlier quoted context omitted.
Enterprise sales people can make a habit of selling things that the product can't currently do, and then forcing engineering to make it a reality on a compressed timeline because "this is a deal we can't afford to lose." Repeatedly. No idea if that's happeing at GitHub, but I've seen it happen a few other places, and it sucks for the engineering and product teams even if the sales people are in a different state. In…
> sales people can make a habit of selling things that the product can't currently do Maybe this is a trope from the 90s and 2000s or from a Scott Adams cartoon, but I disagree this is representative of most enterprise sales these days. Maybe I'm just spoiled, but every company I've worked at the past decade has had a knowledgeable sales force. I've been asked plenty of times, "can you add this feature for a huge cus…
Why would someone (specifically a large enterprise) outsource source control? Running a local svn or git server is fairly trivial.
Earlier quoted context omitted.
That's a funny double standard you have right there with how you don't feel the need to audit GitHub before using it.
Github has (or at least had, last I checked) one of the best application security teams in America, at least for the kinds of applications Github builds, and is also pretty well engaged with third-party pentesters. It is unlikely that Gitlab has endured the kind of scrutiny Github's code has.
I will say that, as a rule, I don't believe I can ever trust Github, regardless of how good their team is. I treat every packet I send as "completely public" and every packet I receive as "possibly malicious", just like every other website on the Internet.
GitLab: it's at least possible for me to trust (i.e. if I self-host it).
(But I really do need to pick up Ruby sometime soon.)