3 ms·

Sentry is a poorly designed crash reporting service that can be a massive vector for supply chain attacks. E.g. a sentry crash report makes an interesting targe

Sentry is a poorly designed crash reporting service that can be a massive vector for supply chain attacks. E.g. a sentry crash report makes an interesting target since it can save an adversary a lot of time finding exploitable parts of an application. Sentry claim that github and Disney is using their service ("among many other fortune-500 companies"). The problem isn't so much that there are potential security holes in sentry but that a service like Sentry should never be a SaaS (or if it is should come with a massive disclaimer - but since they just raised 69 MM last year and want to be seen as the github of crash-reports they're not gonna talk about it). Outsourcing something like that and sending it over the network demands a huge amount of trust. One might say that Anti-Virus companies or certificate authorities demand the same, so where is the problem? The problem is that nobody raised this (yet) so they don't even position themselves as a service that ought to take security seriously. There is also the elephant in the room of how many Sentry employees get to see the crash reports of these companies, what security clearance they have and how well they're vetted. Scrubbing of PII in the crashes is left to the client using the service and it often happens that PII still leaks anyhow. Whoops! Ignoring all this for a moment, Sentry also has other problems limiting its usability: it can't be isolated from the main application logic and its ability to be useful is affected during times of a crash (when crash reporting is actually needed most). The correct approach to do something in the observability space today would be to make it live inside a eBPF VM (and not have the crash reporter run in the same context as the application). Edit: The (genius) growth-hacking and business model of sentry is to convince companies that it provides value by creating a dependency of Sentry API calls in their clients application code. This is hard to pull off but once a customer has been convinced that making sentry.io calls is useful, they're basically joined at the hip. This is what makes them a highly valued company (from a financial pov) since getting rid of it is as much effort (and even potential risk) as putting it in place.

viraptor 5y ago
> a service like Sentry should never be a SaaS Unless you can see their private config, we don't know where SENTRY_DSN_KEY is pointing. You can host sentry yourself. (https://develop.sentry.dev/self-hosted/ https://develop.sentry.dev/self-hosted/) I get you're worried about crash reports being shared, but that warrants a big "if they're using the hosted version" qualifier.
- jfrunyon 5y ago
  I mean, you can easily see what the DSN is in any distributed version. This isn't a SaaS. And by the way, it's not a key; it's not even remotely secret.
scrollaway 5y ago
What on earth? Sentry is a high quality, open source, self hostable crash collection tool and service. Your comment is FUD through and through, to the point where I'm wondering what your agenda is. You work for newrelic or something?
- mananaysiempre 5y ago
  The server is source-available but no longer open source, under the BSL[1]. [1] https://blog.sentry.io/2019/11/06/relicensing-sentry/ https://blog.sentry.io/2019/11/06/relicensing-sentry/
  - prophesi 5y ago
    It's still open source. You can self-host the latest code so long as you're not commercializing it. BSL just adds two additional clauses: - You cannot offer a commercial version of Sentry’s service (the license grant restriction) - After 36 months, the code becomes Apache-2.0 licensed For those who argue this isn't permissive enough, I'd love to hear the measures you took for your FOSS project to become self-sustainable.
    - mananaysiempre 5y ago
      Once the declared period has passed, yes, it’ll be open source, though I’d still say that “X is open source” and “N-years-old versions of X are open source” is a distinction worth maintaining. However, AFAIK there isn’t a single version of a single BSL-licensed project (... that I’m interested in?) that has been released as open source, so far, so while I want to assume good faith from their authors, I’ll suspend my judgment on that part until the open-source release pledge becomes business-relevant for them. I’ve written elsewhere on HN (https://news.ycombinator.com/item?id=27496025 https://news.ycombinator.com/item?id=27496025) why I consider the essence of open source (as defined in the OSD) to be the author saying something akin to “I will not use the legal tools of copyright to stop anyone else from doing what I am doing with my stuff”. The terms of the AGPL or even the Open Watcom license (however much I’d prefer to avoid them) qualify; the (by almost all measures more permissive) terms of the BSL or even the Unsplash license do not. That (and not a sentimental attachment to the OSD) is why I protest a meaning of “open source” that would allow conditions “discriminat[ing] against fields of endeavour” such as those you listed. Everything the above link says about how my unwillingness to accept this dilution of terminology does not imply I’m passing a moral judgment on those releasing the software also applies here. I believe this makes your last sentence irrelevant. That said, my original motivation for the “essence” above is a belief that people ought to be able to study software and do whatever they want with the knowledge. If we take the delayed open-source release pledge at face value, the BSL then occupies a curious borderline position between satisfying and not satisfying this desideratum in the same way that delayed open access does. I’m ... not sure what I think about either, in general (as opposed to the specific practice of applying the term “open source” to the former). This is part of why I’m suspending my judgment regarding this part—if, for example, the industry eventually converges on the delay being practically infinite, as copyright and patent terms already are, my mental resources are better spent elsewhere. Also, hopefully, in the intervening time smarter people than me will say things that I’ll be able to steal.
l33tman 5y ago
You are misrepresenting Sentry pretty heavily here. It's an old crash reporting system and it works well. You can install it on premises completely for free and don't use any of the SaaS stuff. Your data never leaves your data center. There are also various mechanisms to avoid PII and passwords from being sent in crash reports regardless of if the installation is on-premises or in the cloud. I don't really know what you mean about sentry dependencies either. For most cases you don't add any code at all, you just add it to your project and it catches exceptions and reports them. If you don't want to use it anymore, you just remove it. I'm sure they would love to get a hook in you, but I haven't seen it yet :)
- DyslexicAtheist 5y ago
  > You are misrepresenting Sentry pretty heavily here. instead of generalizing and claiming that this is a misrepresentation why not engaging with my specific points that make it abundantly clear where the problems are? > It's an old crash reporting system there is nothing "old" about sentry. it's new tech using old (outdated) means to monitor an application crash. Your comment is at best ill-informed and at worst whataboutism because most fortune-500 companies in their list do not use on-premise Sentry but their SaaS service. So getting pwned with sentry is not a question of if but when. Meanwhile my post has been flagged which is normal considering that several sentry employees are on HN with high karma. That doesn't change how dangerous the ideas are that they are peddling. And I'm not talking about the wannabe-FOSS (but technically not really FOSS) on-premise service. My beef is with how they commercialize this via a SaaS (recurring revenue / subscription model) when the whole thing should be a bash 3 liner written by your friendly internal sysadmin. This post and the fact it got flagged into oblivion will be used as an "I told you so" the moment the first fortune-500 companies gets hacked via Sentry. It's not a question of if but when considering their authentication and roles are split across 2 continents and 3 countries already and there isn't any strategy for the existing 200+ engineers on how to access highly sensitive customer information and (accidentally leaked) 2nd party PII.
  - zeeg 5y ago
    I will let HN users educate folks on what Sentry is and isn't, but as the creator.. > there is nothing "old" about sentry. it's new tech using old (outdated) means to monitor an application crash. Your comment is at best ill-informed and at worst whataboutism because most fortune-500 companies in their list do not use on-premise Sentry but their SaaS service. So getting pwned with sentry is not a question of if but when. It's 13 years old - I wouldn't call that new in the age of technology - and consistently using modern techniques and technology to improve upon a timeless problem.

viraptor 5y ago

> a service like Sentry should never be a SaaS Unless you can see their private config, we don't know where SENTRY_DSN_KEY is pointing. You can host sentry yourself. (https://develop.sentry.dev/self-hosted/ https://develop.sentry.dev/self-hosted/) I get you're worried about crash reports being shared, but that warrants a big "if they're using the hosted version" qualifier.

jfrunyon 5y ago
I mean, you can easily see what the DSN is in any distributed version. This isn't a SaaS. And by the way, it's not a key; it's not even remotely secret.

scrollaway 5y ago

What on earth? Sentry is a high quality, open source, self hostable crash collection tool and service. Your comment is FUD through and through, to the point where I'm wondering what your agenda is. You work for newrelic or something?

mananaysiempre 5y ago
The server is source-available but no longer open source, under the BSL[1]. [1] https://blog.sentry.io/2019/11/06/relicensing-sentry/ https://blog.sentry.io/2019/11/06/relicensing-sentry/
- prophesi 5y ago
  It's still open source. You can self-host the latest code so long as you're not commercializing it. BSL just adds two additional clauses: - You cannot offer a commercial version of Sentry’s service (the license grant restriction) - After 36 months, the code becomes Apache-2.0 licensed For those who argue this isn't permissive enough, I'd love to hear the measures you took for your FOSS project to become self-sustainable.
  - mananaysiempre 5y ago
    Once the declared period has passed, yes, it’ll be open source, though I’d still say that “X is open source” and “N-years-old versions of X are open source” is a distinction worth maintaining. However, AFAIK there isn’t a single version of a single BSL-licensed project (... that I’m interested in?) that has been released as open source, so far, so while I want to assume good faith from their authors, I’ll suspend my judgment on that part until the open-source release pledge becomes business-relevant for them. I’ve written elsewhere on HN (https://news.ycombinator.com/item?id=27496025 https://news.ycombinator.com/item?id=27496025) why I consider the essence of open source (as defined in the OSD) to be the author saying something akin to “I will not use the legal tools of copyright to stop anyone else from doing what I am doing with my stuff”. The terms of the AGPL or even the Open Watcom license (however much I’d prefer to avoid them) qualify; the (by almost all measures more permissive) terms of the BSL or even the Unsplash license do not. That (and not a sentimental attachment to the OSD) is why I protest a meaning of “open source” that would allow conditions “discriminat[ing] against fields of endeavour” such as those you listed. Everything the above link says about how my unwillingness to accept this dilution of terminology does not imply I’m passing a moral judgment on those releasing the software also applies here. I believe this makes your last sentence irrelevant. That said, my original motivation for the “essence” above is a belief that people ought to be able to study software and do whatever they want with the knowledge. If we take the delayed open-source release pledge at face value, the BSL then occupies a curious borderline position between satisfying and not satisfying this desideratum in the same way that delayed open access does. I’m ... not sure what I think about either, in general (as opposed to the specific practice of applying the term “open source” to the former). This is part of why I’m suspending my judgment regarding this part—if, for example, the industry eventually converges on the delay being practically infinite, as copyright and patent terms already are, my mental resources are better spent elsewhere. Also, hopefully, in the intervening time smarter people than me will say things that I’ll be able to steal.

l33tman 5y ago

You are misrepresenting Sentry pretty heavily here. It's an old crash reporting system and it works well. You can install it on premises completely for free and don't use any of the SaaS stuff. Your data never leaves your data center. There are also various mechanisms to avoid PII and passwords from being sent in crash reports regardless of if the installation is on-premises or in the cloud. I don't really know what you mean about sentry dependencies either. For most cases you don't add any code at all, you just add it to your project and it catches exceptions and reports them. If you don't want to use it anymore, you just remove it. I'm sure they would love to get a hook in you, but I haven't seen it yet :)

DyslexicAtheist 5y ago
> You are misrepresenting Sentry pretty heavily here. instead of generalizing and claiming that this is a misrepresentation why not engaging with my specific points that make it abundantly clear where the problems are? > It's an old crash reporting system there is nothing "old" about sentry. it's new tech using old (outdated) means to monitor an application crash. Your comment is at best ill-informed and at worst whataboutism because most fortune-500 companies in their list do not use on-premise Sentry but their SaaS service. So getting pwned with sentry is not a question of if but when. Meanwhile my post has been flagged which is normal considering that several sentry employees are on HN with high karma. That doesn't change how dangerous the ideas are that they are peddling. And I'm not talking about the wannabe-FOSS (but technically not really FOSS) on-premise service. My beef is with how they commercialize this via a SaaS (recurring revenue / subscription model) when the whole thing should be a bash 3 liner written by your friendly internal sysadmin. This post and the fact it got flagged into oblivion will be used as an "I told you so" the moment the first fortune-500 companies gets hacked via Sentry. It's not a question of if but when considering their authentication and roles are split across 2 continents and 3 countries already and there isn't any strategy for the existing 200+ engineers on how to access highly sensitive customer information and (accidentally leaked) 2nd party PII.
- zeeg 5y ago
  I will let HN users educate folks on what Sentry is and isn't, but as the creator.. > there is nothing "old" about sentry. it's new tech using old (outdated) means to monitor an application crash. Your comment is at best ill-informed and at worst whataboutism because most fortune-500 companies in their list do not use on-premise Sentry but their SaaS service. So getting pwned with sentry is not a question of if but when. It's 13 years old - I wouldn't call that new in the age of technology - and consistently using modern techniques and technology to improve upon a timeless problem.