7 ms·
> This is no good. Let me just try reverting to a version from a month ago. Nothing. Three months ago? Nothing. Still failing. A year ago? Zilch. Reverting you
by foodevl 2y ago
> This is no good. Let me just try reverting to a version from a month ago. Nothing. Three months ago? Nothing. Still failing. A year ago? Zilch.
Reverting your own code, but still using a broken PostHog update from that same day? For me, the lesson is to make sure that I can revert everything, including dependencies.
- roywiggins 2y agoIt seems that PostHog just always loads the latest version of this piece of itself: https://github.com/PostHog/posthog/issues/24471#issuecomment-2298298849 https://github.com/PostHog/posthog/issues/24471#issuecomment... Though you can opt to bundle it yourself: https://github.com/PostHog/posthog/issues/24471#issuecomment-2298786491 https://github.com/PostHog/posthog/issues/24471#issuecomment...
- ricardobeat 2y agoOuch. That just adds insult to injury.
- slashdave 2y ago> I definitely want to figure out in detail what happened here so I can add a test to prevent a similar change in future! Whoa! Good idea! Could have been worse. At least the change didn't expose a hidden exploit.
- deleted 2y ago[deleted]
- phkahler 2y ago>> It seems that PostHog just always loads the latest version of this piece of itself: Now there's a supply chain attack vector...
- philsnow 2y agoYears ago, IT at the company I was working at force-pushed a browser extension that did this same trick, but the extension vendor in question didn't even bother loading over https. Edit: the extension's manifest gave it nearly every permission, on every web site, including internal ones
- deleted 2y ago[deleted]
- amsterdorn 2y agoThis is the key lesson. Your own deploys mean nothing if you link to another CDN for parts of your application. You handled it well OP, the silver lining of incidents like this is the grab bag of valuable takeaways!