Hi folks. As the CircleCI CTO, I appreciate your patience here and all the feedback. It's true that we are focused on getting customers moving again over sharing more detailed information, but will aim to do better in providing a bit more in our updates. status.circleci.com provides real time updates for both how we're tackling outages and more detailed incident reports. We will post more information there about this incident once we are on the other side and have comprehensive detail.
HN user
z00b
Hi.
You can always email our security team at security@circleci.com Our gpp key is available on our site https://circleci.com/security/ if needed. You can also email me directly at rob@ if you have an immediate question.
Thanks Kevin. We really do appreciate the discussion and, as you would imagine, are rethinking some of our approaches in line with the issues you've raised.
Welp. Wanted to write quickly and made a stupid mistake. Sorry about that Kevin!
Rob Zuber, CTO of CircleCI here. We take security very seriously and are taking a deep look at the issues Kevin raised.
We'll save additional commenting until we have gathered more information. In the meantime, our security policy and steps for reporting issues are here: https://circleci.com/security/ and we'd like to ask the community to please use our outlined methods for reporting potential security issues so we can keep CircleCI as safe as possible for everyone.
We use the LaunchAgent approach. A separate sshd that's spawned there for the build user.
We originally tried with named pipes (a process via LaunchAgent), but it made it much harder for our customers to modify the build command without understanding our secret incantations.
As far as SDKs, we have 7.0, 7.1, and 8.0. Thanks for highlighting that the docs are missing that!
Sure. There's definitely some overlap. Shenzhen is a smaller piece of the puzzle, designed to build and deploy from a single system at the point that a user decides to do so.
Distiller provides hosted continuous integration, building your code and running all of your tests every time someone commits to GitHub. It also allows you to push the passing build to an OTA platform (Testflight or Hockey) as a final step.
The difference is most notable in a team environment where everyone can have access to build results, including seeing the test results on a GitHub pull request before deciding to merge a set of changes.