Nothing disingenuous about it. He was on the original team that prototyped and then built NuGet.
He wrote the core dependency management engine among other things. His contribution only seems small now only because the project has been around a long time with many new contributors since he’s moved on.
But you can rewind the git history to see he had a huge impact as a creator. I say this as the PM of team that built NuGet.
Sure! Because of my background in .NET, it made sense to stick with what I know. I don't believe the tech stack makes or breaks a product (unless you choose egregiously poorly). A product's success is primarily determined by how well you hit product market fit.
That being said, a good stack that you know well can affect how quickly you build and how quickly you can adapt the product to changing market conditions.
So here's what we use:
- ASP.NET CORE( - Primarily ASP.NET Razor Pages for the web app. ASP.NET MVC Controllers for the internal and external APIs we support.
- C# - We try to stay on the latest version. The recent pattern matching improvements alone make our code so much cleaner.
- [HTMX](https://htmx.org/)\* - for front-end. We're not at the point where we feel we need a heavyweight front-end framework like React. We like the 37signals approach of shipping "HTML over the wire". We're also big on Web Components. That's a result of our [GitHub heritage](https://github.blog/2021-05-04-how-we-use-web-components-at-...).
- TypeScript - for our front-end JS. This is a recent addition. Most of our JS is still ES6.
- Azure Database for PostgreSql - PostgreSql is rock solid and great for storing all kinds of data.
- Azure Functions - we support three types of custom code skills that customers can use to enhance and customize the bot : JavaScript, C#, and Python. We run these in Azure Functions.
- App Insights - We use this for logging.
- Azure Managed Grafana - We have a nice Grafana dashboard based off our App Insights logs that helps us get a birds-eye view of how everything is doing.
- Azure App Configuration - For feature flags.
As you can see, it's pretty heavily Microsoft based. Part of that is my background. The other part is we got a lot of Azure Credits when we joined the [Microsoft for Startups](https://www.microsoft.com/en-us/startups?rtc=1) program. So it made fiscal sense for us to stick with Azure.
I do like that we can manage everything in a single portal. But some of these tools are not best-in-breed as we will be looking at other options down the road.
> The other part is we got a lot of Azure Credits when we joined the [Microsoft for Startups]
Wow, Microsoft must have really drowned you with free credits to choose Azure. We also tried Azure 2.5 years ago when my small team (3 founding devs) started with our startup, but after 6 months of constant problems, broken services, outages, and completely out of the blue unexplained service failures we had to give up. We wasted a lot of engineering time on bending our app to Azure's needs and still had issues. We eventually migrated to Google Cloud and hadn't had any problems since then. I am not kidding, the first 6 months we must have spent at least 70% of our time on issues which we wouldn't have had on AWS or Google. Azure really under delivered on all fronts. Things looked extremely promising and then when we used a service we realised that most useful (often necessary) features were behind extremely expensive tiers and then it meant we had to either take huge hits on our hosting costs or build weird workarounds. We didn't want to go against Azure and often chose to pay, but even the higher tiered services then started to act up and often result in totally unexpected behaviour. Good luck to you though!
I have experience the other way around. AWS was utterly holding us back and we gained a lot of speed when we switched to Azure. Azure has changed a lot over the years though and a lot of features behind a premium tier are now more available to lower cost tiers. Comparing something to 2.5 years ago is a long time in the fast moving cloud world.
> No, not really, you should focus way more on the latter really.
You're absolutely right. I think I should have phrased this as "Don't completely neglect your early engineering and infrastructure." Some choices could inhibit our ability to achieve product market fit.
> - Azure seems like a bad choice (running out of capacity lolwut)
I think the pandemic created supply chain problems that affected a lot of companies. There's a lot of reasons to like Azure for me. I'm familiar with it. They focus a lot on developer experience. But this one issue really hit hard and definitely makes me want to be more flexible in how we deploy to the cloud.
> - corollary to above: don't get too attached to where you worked.
Ha! Yeah, we really loved the GitHub way of working. Turns out, GitHub had a unique culture and it doesn't necessarily translate over to whole market. I wish I had included this in the post.
> Just some thoughts, hopefully your pivot is successful!
Hey! I'm the author of this blog post. If you have any questions, let me know!
One of the lessons I omitted (because the post was getting a bit long), is we started off as cross-platform (Slack, Teams, and Discord) but in the end we decided to focus on a single product.
In retrospect, we've struggled to decide if that's a lesson to learn. Should we have started with a single platform? It certainly makes it much faster to build for a single platform. But at the time, we really thought the cross-platform chat-ops would be a distinguishing trait!
Just wanted to say that I like your writing style. It's approachable and entertaining to read. Good luck with Abbot and thanks for sharing your lessons learned!
Absolutely! We think about security on multiple levels.
For our threat model, we focus on _companies_ using Slack, Discord, and Teams, though our efforts apply to communities, etc. For the sake of this question, I'll focus on companies using Slack, but most of it applies to the others.
Even without Abbot, if someone gains access to an employee Slack account, they can do immense damage. So it's very important for companies to enforce good security on Slack such as 2-factor auth, etc. If you use Abbot, that's even more important. To interact with Abbot in chat, a user must be logged into your Slack organization. So we encourage customers to take their Slack account security seriously.
Now it may happen that a Slack account is compromised despite a company's best efforts. So the next level of protection is the ability to protect skills using Abbot's access control. You can restrict skills to a limited set of users. That makes it possible to follow the principle of least privilege and reduce exposure of the most sensitive skills.
Finally, despite our best efforts, there may be the case where someone gains access to a privileged account. Abbot logs every interaction it has with users, whether through the Bot console (in the website) or via chat. So if someone does somehow get access, you can audit what activities they took, what secrets they accessed.
It's also important to look at security from the perspective of a skill author. To create a skill, a user has to be a member of the "Members" role in https://ab.bot/. This requires that they are a member of the associated Slack organization and have logged into https://ab.bot/ with their Slack account (we don't implement our own authentication).
An Abbot Administrator can choose to let anyone in the Slack organization automatically be added to the "Members" role when they log in. That may be appropriate for smaller high-trust companies. For larger companies, administrators may want have tighter control on access to the website.
Skill authors are encouraged not to embed tokens and other secrets in the code for skills. Instead, use the secrets management built in. There's also a proxy link feature for certain cases where a secret is embedded in a URL and you don't want the secret exposed even to skill authors.
That's where we are today.
In the future, we'd like to integrate with Active Directory, LDAP, etc. for managing access to the site and skills. Also, we know that many systems people want to access are going to be behind a firewall. So we are looking into onprem options, but those may be further down the road.
If you have some ideas on where we can improve or areas we should be thinking about, we are definitely interested in hearing about it. This is very important to us.
Slack is often misconfigured - mid-sized companies without a proper IAM team/engineer often enable auto-provisioning which sends an invite to @<whitelisted domain>. If you can identify a e-mail reflection vuln on the domain you can parlay that into a Slack invite, and while ChatOps might be the least of the concerns I fear this is reinforcing bad hygiene.
Additionally companies forced to be SOX compliant require separation of duties, which is often incompatible with slash commands that impact production or revenue generating infrastructure.
For teams that are concerned about whether their Slack is configured correctly, Abbot can be put into a waitlist mode where an administrator on the Abbot team has to explicitly approve any access. No matter how Abbot is configured, all commands are still logged.
SOX compliance is a bit outside of our domain of influence; our goal is to give people the most powerful tools we can, in a way that they can run it in their environment without having to reinvent the wheel.
> If you can identify a e-mail reflection vuln on the domain you can parlay that into a Slack invite
On reread, I realize that I'm not sure I understand what sort of attack you're talking about. While I think we've done a good job of making Abbot a safe entity, could you describe how this works? It's possible there's an attack vector we haven't considered. Thanks for sharing!
You need to know the Slack workspace URL, looks like the previous method I used to find this for arbitrary domains has been fixed. Workspace URLs aren't secret, though, and can often be guessed. Let's assume finding this for your target isn't an issue.
The most common reflection attack is through support systems, specifics will vary depending on the product used. Not all are vulnerable to this.
Open a support ticket with support@company.com pretending to have a valid complaint. Obtain the unique e-mail address for your ticket such as support+2392@company.com, and use "Sign up" at https://company.slack.com/signup#/domain-signup with the support ticket e-mail address.
The support ticket system can leak the contents of the Slack invitation as a ticket update. Once you know the validation URL Slack allows you to sign up.
He wrote the core dependency management engine among other things. His contribution only seems small now only because the project has been around a long time with many new contributors since he’s moved on.
But you can rewind the git history to see he had a huge impact as a creator. I say this as the PM of team that built NuGet.