Set up your own Slack-like chat system on Linux
Excited by our recent interview with Zulip founder Tim Abbott, we install the Slack-beating chat system for ourselves, as Jonni Bidwell reports.
Secure your Zulip installation
We could tell you how fantastic we found Zulip to be, and all of our favourite things about it, but instead we thought we’d include some of Tim’s wise words that we didn’t have space for last issue.
Naturally, we wanted to hear more about Zulip’s security, and he reassured us. “Security requires a lot of thought and energy for anything in the communications sphere,” said Tim.
“Because your product’s communications, your email and your chat system, are some of the most enticing targets for an attacker. We’ve put a lot of effort into writing and structuring our codebase in such a way that we’re unlikely to have security bugs at various passes."
“We use a lot of code skimming tools – there’s a tool called Semgrep, which is a semantic grep tool to check that nobody is calling certain types of functions that are unsafe to call. "
"From our view codes we only have a small security review library. That’s how you access a user object, where it’ll check the permission of the client to make sure they’re allowed to access this user, that sort of thing.”
Maintaining a secure Zulip setup
It’s true: if you look at the code contribution guide there are all kinds of standards to adhere to. And more unit tests than you can shake a stick at. But what about keeping things secure, when bugs inevitably crop up?
Well, Zulip has you covered there too: “I also think it’s really important as a value to have real security advisories, so we use the normal CVE (Common Vulnerabilities and Exposures) process for doing our security releases,” Tim revealed. “That’s getting increasingly rare now, a lot of folks will just ship a new release and not tell anybody that it happened.
Are you a pro? Subscribe to our newsletter
Sign up to the TechRadar Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed!
We’re very much against that idea. So we use best practices and embargo, do a patch release on the main app, and make the upgrade process really easy. “We only include stuff that’s guaranteed to work, critical bug fixes and the like, in each security release. Much like how the rest of Linux works,” Tim continued.
“So there’s no reason to not install that update immediately. That all gives people confidence that they can keep their systems secure and have very limited vulnerability when or before the vulnerability gets disclosed. Other projects will bundle a security release with a major version update. And I think that’s really challenging for a system administrator: they want to get the security update right now before exploits are in the wild for it, but they don’t want to risk downtime installing a major update in the middle of the day.”
Finally, we asked about how self-hosting plays into the security aspect. Tim said: “Being able to self-host is important too, or even install on an air-gapped network.
"That way you have control over your data and how you secure the network around it. There are companies that are important in the information security ecosystem that use Zulip on their internal networks precisely because of these self-hosting benefits."
“Another thing that we’re working on is end-to-end encryption for push notifications,” said Tim.
“Those are sent from a self-hosted instance to a Zulip server that sends them to Google that then sends them to multiple devices via the architecture of APNs (Apple Push Notification service) and FCM (Firebase Cloud Messaging). Right now it’s the case that if Google, or other third-party intermediaries, were malicious (or hacked) they could access those messages. So we’re working on having them encrypted from your local Zulip server to the destination device.”