shanipribadi

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.

Previously this was launched as dba.ai by Tembo.

Paid user migration deadline for Managed PG on Tembo Cloud by June 27, 2025

found it mentioned in https://github.com/facebook/proxygen/blob/main/build/fbcode_..., looks like it's going to be cousin of zstd, but maybe for the stronger compression use cases

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.

  pip3 download torch==2.0.0.dev20221230+cpu --extra-index-url https://download.pytorch.org/whl/nightly/cpu

  Requires-Dist: torchtriton (==2.0.0+0d7e753227) ; extra == 'dynamo'

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).

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.

[1]. https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...

[2]. https://schibsted.com/blog/dependency-confusion-how-we-prote...

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.

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.

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.

This is not the real torchtriton package but uploaded here to discover dependency confusion vulnerabilities

the compromised version is still available in pypi as version 2.0.0 https://pypi.org/project/torchtriton/.

The decision on which type to use IMO depends a lot more on the behaviour of the database driver of your programming language, and which one works better with the type.

If you're not writing an application that uses a db driver, but interacting with pg over psql manually, timestamptz is preferrable because a lot of pg functions works better with timestamptz. If you use timestamp, you would need to be using explicit timezone conversion and be consistent to avoid weird double timezone conversion issues, which makes it far more verbose.

The point of the article was more that when you have multiple teams, each owning multiple products, having a single well-defined abstractions over external dependencies provided as a service that you control is important to manage risks posed by those external dependencies and to make overall maintenance easier.

I'm curious how do you guys operate the flink cluster, do you have a single huge shared flink cluster where people can submit any kind of jobs for various applications/streams. Or do you have multiple smaller flink clusters for specific use cases? Are they on Mesos/YARN/k8s, or just plain vms/baremetals?

Which flink version are you guys on? I'm very excited about Flink 1.6, especially related with FLIP-6 [https://cwiki.apache.org/confluence/pages/viewpage.action?pa...]

Just wondering if you guys have any thoughts on that.

Thank you.