361–370 of 664 posts
Instead, use a self-hosted Gitlab instance or similar, preferably with an external firewall preventing outbound and non-team inbound connections if feasible.
Earlier quoted context omitted.
I'd like to share feedback on GitHub Actions. Tried it out, and the learning curve was too much. I want to use stuff I already know -- e.g., write a Dockerfile, and then GH could run it on PR builds. The "workflow" concept didn't land for me, and I hope you consider a more generalized, open-source approach to running arbitrary scripts in response to PRs being opened, merges to master, etc.
Counterpoint: I've never used Docker at all (I'm a Mac/iOS dev), and was able to get GitHub actions set up and doing what I needed it to in ~30 minutes. Its general similarity to other CI/CD solutions, TravisCI being the one I'm most familiar with, helped a lot.
Earlier quoted context omitted.
Transparency can give bad actors a way to game and workaround the system.
We're living with transparent juridical system and it works fine. Imagine that you could be thrown to jail without explaining a reason. That would be outrageous.
2) You can be shot without any explanation whatsoever.
3) Your possessions can be taken away, and sold off without any explanation and without recourse.
Links about each of these claims:
https://abovethelaw.com/2018/07/innocent-people-who-plead-gu...
https://en.wikipedia.org/wiki/Shooting_of_Walter_Scott
https://www.forbes.com/sites/jacobsullum/2014/09/11/how-cops... (also applies to, say, cars)
Earlier quoted context omitted.
The riskiest components in SSO deployments are SP-side libraries, and those are all open source. If you want to use Okta to drive those libraries, the trial account you need is free. The worst bugs here are indeed mostly private, but that's because they're feature bugs inside of people's random products; they're like every other bug in that regard. But people do find and report bugs in the SP libraries. I agree that…
I'm surprised you'd say SP-side libraries are open source. In my experience, it's always been mostly custom and close source in every company I've seen and done. You take some open source pieces you can (saml, xml, oidc, ssl, jwt) but permissions, groups, user attributes, keys are always per company then the whole thing together has to be supported into end-user applications running on language and frameworks of the…
Earlier quoted context omitted.
It's a little odd to say something is not a "net security benefit" and, in the next sentence, make a powerful case for it as a net security benefit. SSO is probably the most important organization security tool there is, and a survey of tech company CSOs will average it in the top 3, if not the top 2 technology acquisitions most would make at a new firm (this is a question I've actually surveyed).
What's are the other contenders for top 3?
Earlier quoted context omitted.
This is completely unrelated to the announcement, but when will Enterprise Server ship support for GitHub Actions?
We'll have a beta next month, and should ship this summer.
Now I can at least compare the two.
Azure Devops deployment tools are (were? It’s been a couple of years) just as good for deploying to AWS as AWS’s own tools.
Earlier quoted context omitted.
It's not a technology problem. Integration with "foreign" SSOs is complicated no matter what protocol you use, with lots of corner cases and support costs, but these features are expensive for the same reason that single-day-turnaround short-notice flights between Chicago and NYC tend to be expensive: the people who want them have money to spend on them, and it isn't their money. That money pays for the cheap seats e…
SAML is a technology problem, on top of all other problems. The messages are under specified and overcomplicated, doing incredibly obscure stuff (XML signing and canonization for one) that nobody can understand and implement. That's mainly why it's so hard to use and there is so little support from libraries. As security researcher, we could nitpick all days on security being hard, no matter the solution. It is factu…
2. I think the product complexity issues are, like, 95% the same whether you use OIDC or SAML.
3. I think no matter how much simplification you got from using OIDC instead of SAML, none of it is going to offset the actual reason why SSO integration is a paid feature.
4. I agree that SAML is much worse than OIDC from a protocol implementor's perspective even if I'm not so sure that it's much better from a developer's perspective, so wouldn't want to find new reasons to disagree.
Earlier quoted context omitted.
Big companies like Microsoft and Google like to burn products with little notice too.
Google sure, but Microsoft? The company that kept the Zune service alive for 4 years after the product was EOL and with a userbase likely measured in the hundreds of thousands? https://www.wired.com/2015/09/what-to-do-with-your-zune-rip-... The company who STILL supports 16-bit apps? https://www.groovypost.com/howto/enable-16-bit-application-s... Ya... I would hardly say MS is known for killing stuff early - more lik…