had something similar happened a few years back.. basically the go binaries i compiled and run would get deleted every time I try to run it. usually just downloading the newer version of go compiler and recompile with that solves it (I think it got flagged because it was compiled with an older version of go compiler with known vulnerabilities).
Every time it happened I think IT security got a notification, cos they would reach out to me afterwards.
The few times upgrading to the latest go version didn't work (false positives), I would just name the binary something like "Dude, wake up", or "dude, I need this to get whitelisted", and do the compile-run-binary_got_deleted cycle 10-20 times, effectively paging the IT security guy until they reached out to me and whitelist things for me :-D.
The new Tembo is a superhuman junior developer, It polls your database, reads your stack traces, analyzes your monitoring tools, understands your codebase, and turns noisy alerts into production-ready pull requests.
Previously this was launched as dba.ai by Tembo.
Paid user migration deadline for Managed PG on Tembo Cloud by June 27, 2025
In addition to the managed PG cloud being shutdown, it seems that pgt.dev (Trunk, a Postgres package manager and extension registry) is also being shutdown, "We are sunsetting Trunk and ending active maintenance. The site and packages will stay accessible for some time".
What's also a bit sad is that Tembo also took down the Hacking Postgres podcast transcripts from their blog section on their website. Fortunately they are still available in Tembo's Youtube channel, Spotify and Apple Podcasts.
think BI tools, analytics dashboards for exploratory analysis, or even just exploratory analysis on the terminal with it's rich query capabilities.
you can keep analytics data in SQLite,
but DuckDB will process it faster/easier for the analytics use cases.
> think BI tools, analytics dashboards for exploratory analysis, or even just exploratory analysis on the terminal with it's rich query capabilities
I thought about that, but I'd never use DuckDB for it because DuckDB is locked into a single process. I can't figure out a benefit of being suck with one core when I always have between 2 and 32 available to me.
DuckDB is when you need to do OLAP analysis, and the data fits in a single node (your laptop),
but it's too large for plain excel.
technically you can use PG/MySQL/Python+Numpy+Pandas to process those data for that use case as well,
but DuckDB does it easier/faster most of the time.
What do frontends for this type of stuff look like these days? I remember one of my first jobs out of college they had wired up an OLAP cube into Excel so that you could import it into a pivot table and arbitrarily slice and dice data by dragging and dropping columns. I thought that was the coolest thing. Is there a modern day non excel equivalent of this? Cube.js?
I'd imagine Looker, PowerBI, Tableau are probably the front-ends you'd most commonly hear about, although I'm not sure DuckDb is supported or acknowledged by the parent companies (yet).
parquet is just a data file format. Both pandas and DuckDB can query parquet files.
It might be confusing that DuckDB does have its own columnar format, but it's more helpful to think it like "just a query engine (or library) for wrangling tables (or data frames)", i.e. same as pandas.
Alex Birsan actually published his findings for this vulnerability in Feb 2021 [1], and collected a bunch of bug bounties from various companies (Apple, Microsoft, Paypal, Yelp, Tesla, Shopify, Uber, Netflix).
He was able to steal packages names for Python (PyPi), JS (npm), Ruby (Gem), where these various companies have their own private package repositories with private modules where they don't control the package names in the default repositories.
The main requirements for this attack are
1. Having private repositories, where the package names in the default repositories is not owned by the owner of the package.
2. Package manager allows downloading packages from multiple repositories (the default and private repositories) without being able to pin specific package to only be downloaded from the private repositories.
What's notable on his findings is the omission of Facebook and Google,
which I believe due to their usage of Buck/Bazel and monorepos for their internal codes.
Another thing to note was that Alex mainly target companies internal private packages,
while this particular instance affects an open source project which was providing package on their own repository and make use of a package (which I was not able to find any bug bounty program for).
There's another post by Kjäll et.al [2] that explains how this particular vulnerabilities affects other package managers (PHP, Java, .Net, ObjC/Swift, Docker), in what conditions it's vulnerable, and how to mitigate the risk.
Two notable language package managers that were not affected are
1. Rust, mainly because you have to explicitly select the private registry for each private packages.
2. Go, mentioned as unlikely, due to the use of FQDNs in the package names and hash verification by default.
I think anyone adding non default package repositories or providing one (their own private repo in enterprise setup, or 3rd party provided repositories), need to be aware of this particular class of vulnerability, and implement policy to mitigate it.
I would say, individual devs installing on their dev machines or CI/CD systems based on shell commands (rather than secured package manager setup) would be the main area of attacks mainly due to the relative difficulty of auditing those scenarios.
Good analysis, thanks for the view in from the outside. I found the terms of any such bug bounty[0], whose scope includes "Open source projects by Meta"
And from the engineering blog, "[...] PyTorch 1.0, the next version of our open source AI framework."[1] (emphasis mine)
However Meta has since ditched it[2], and a careful keyword search of pytorch.org, linuxfoundation.org, suggests there is not any current official bug bounties for PyTorch.
hashes would also need to be specified for all dependencies (transitives) in case they were needed,
and all dependencies need to be pinned to specific versions as well.
hence this would only work when users are making use of venvs, instead of user install / site install setup.
For comparison, iOS and Android's security model would not allow a Python package to steal SSH keys. But the best solution would be to implement least privileges principle and do not grant unnecessary privileges to programs.
I think even in iOS and Android, the same thing could still happen if the user keep secrets (say private keys) in their file directories, and then the user give permission to the app to access their file directories, which could be legitimate need of common applications like file manager, text editors, etc.
I think the main change to solve this would be to not keep secrets in files that are readable by users (or program run by users) implicitly, instead using a secret provider that makes it explicit to the user whenever an application needs to access such secrets.
there's a few factors here that allow dependency confusion attack to happen here
1. pytorch publishes their nightly package on their repo which depends on a custom triton build provided on their repo, but using a package name they don't own in pypi. This has been mitigated by them by renaming the dependency from torchtriton to pytorch-triton, reserving pytorch-triton package in pypi, and changing the dependency name on the newer nightly builds 20221231 forward to point to pytorch-triton package instead.
2. pytorch installation instruction for nightly using pip in (https://pytorch.org/get-started/locally/#start-locally), make use of the --extra-index-url option. This is a known vector of dependency confusion attacks, and is an inherently insecure method of installing packages from private repositories. The recommended approach of distributing wheels in private repositories is by using a repository server that allows proxying/redirecting the public pypi packages to pypi, and users should be using a single --index-url pointed to that private repository (assuming the maintainer of that private repository is to be trusted). --extra-index-url is meant to provide mirror urls (serving the same set of packages as the main one), rather than to combine repos with different sets of packages.
> The recommended approach of distributing wheels in private repositories is by using a repository server that allows proxying/redirecting the public pypi packages to pypi, and users should be using a single --index-url pointed to that private repository (assuming the maintainer of that private repository is to be trusted).
Alternatively, keep a separate requirements_private.txt around for private dependencies and add a line --index-url <my private repository>.
So technically, if you are pulling the older version of pytorch-nightly (specifically 2.0.0.dev20221230), it will still pull that compromised dependency (because torch have explicit version lock to it).
> So technically, if you are pulling the older version of pytorch-nightly (specifically 2.0.0.dev20221230), it will still pull that compromised dependency (because torch have explicit version lock to it).
All PyTorch nightlies with this dependency have been deleted
Requires-Dist: torchtriton (==2.0.0+0d7e753227) ; extra == 'dynamo'
The package dated 20221231 has pytorch-triton already (so should be safe now)
Although I guess this is low risk, because people normally would download nightlies without pinning to a particular version/date.
But in case there are people that does pin their version, and cache those vulnerable versions (locally or on their own proxies/private repositories), they could still be affected.
I recommend to get PyPA to yank the 2.0.0.dev20221230 version in pypi, and possibly amend the post to remind people to purge their caches not just on their local but also on their proxies/private repos/mirrors (mainly for the torchtriton package) and to immediately stop using any pytorch nightlies dated before Dec 31 2022 (mainly any pytorch nighlies that has a pin on torchtriton==2.0.0+0d7e753227, not just between 25 Dec to 30 Dec).
thanks for the heads-up, looks like we didn't yank the CPU wheels on those dates. will get to them in the next set of working hours, as its an unlikely scenario (not only do you have to install the wheel of a specific date, you also have to specify the undocumented feature flag [dynamo])
