I'm working on _prompt injection_, the problem where LLMs can't reliably distinguish between the user's instructions and untrusted content like web search results.
Generally the threat model is that a trusted user is trying to get untrusted data into the system. E.g. you have an email monitor that reads your emails and takes certain actions for you, but that means it's exposed to all your emails which may trick the bot into doing things like forwarding password resets to a hacker.
There have been attempts like https://arxiv.org/pdf/2410.09102 to do this kind of color-coding but none of them work in a multi-turn context since as you note you can't trust the previous turn's output
I doubt Comet was using any protections beyond some tuned instructions, but one thing I learned at USENIX Security a couple weeks ago is that nobody has any idea how to deal with prompt injection in a multi-turn/agentic setting.
After reading Judith Butler for a class in college, reading "Professor of Parody" was such a breath of fresh air. Nussbaum is a clear thinker who doesn't take BS kindly.
The argument as I understand it is that group 2 mostly does not care about being protected from their government or even agrees with the government's actions, and they get to benefit from continued access to Apple's superior products. I'm not endorsing this argument, but it's not prima facie crazy.
I run a similar, maybe even more boring stack for my less-than-one-person company [PyDist](https://pydist.com):
- PostgreSQL database
- Nginx proxy in front of Django apps for UI and API servers (I use gunicorn instead of uWSGI though)
- Cron jobs which invoke django-admin commands to keep the PyPI mirror in sync
Perhaps the only place I'm any fancier than OP is that my deploy script is in Python, not shell, since any time I try to write a shell script with even slightly nontrivial logic it falls over and catches fire :)
Running a python package registry has some unique challenges, so it makes sense not to start with it (I run such a registry: https://pydist.com).
For example, Python has a distinction between distributions (the actual file downloaded, e.g. a tarfile or a manylinux1 wheel) and versions that doesn't exist in most other languages.
DevPi is a good solution if you want to self-host a Python package index. PyDist has some additional features like API keys and download statistics which I think are nice, but the main selling point is that you don't have to set up and maintain it yourself.
Why would you not expect someone to charge for this? There are many services that charge for hosting private packages (rather than making them public to the world); I'm not aware of _any_ service that does so for free.
I assume you're referring to how --extra-index-url means that pip will randomly choose which index to try to install from, potentially installing a public package by the same name instead of your private package?
It's worth pointing out that while modern hash functions are believed to be infeasible to unscramble (technically, to require exponential time), none have been proven so. In fact, proving the mere existence of such a function would prove P!=NP.
Ah, looks like you can set that up. But it's not as convenient, because 1) you have to provision the remote repository and 2) instead of transparently installing from PyPI, you have to specify the remote repository each time you install from it.
In fact I'm hoping to get some time this weekend to make a PR implementing this! (I'm assuming the reason you/Donald Stufft haven't done so is time, rather than disagreement over whether this is a good solution or some unseen obstacle to implementing it.)
Expanding on jep42's answer, there are a few problems:
- The package manager can't tell whether the package will be able to support your system or not, so if this is e.g. an optional dependency your install will probably break instead of the package being skipped.
- This results in an unexpected and hard-to-foresee dependency on some other non-npm server, which could disappear, be blocked by a firewall, etc.
- Standard tools will not understand what this package is doing and their assumptions may be broken, e.g. when trying to make builds repeatable.
It looks like they don't include the binary in the package at all, and instead the package has custom install code that downloads it during install. Which works, but it completely bypasses the package manager and would certainly take me by surprise as a user.
Because right now you can only upload individual distributions to PyPI. A release is implicitly created when you upload the first one. If PyPI implemented that change, you could only have one distribution per release.
The proper fix would be to make publishing a release a separate operation. But that breaks all existing tooling and workflows.
PyDist is specifically for Python packages, so it's 1) a better fit in this niche (for example, it mirrors PyPI so you can install public and private packages through a single index, and you won't be broken by packages deleted from PyPI), and 2) it's much cheaper if you don't need everything else Artifactory offers.
Just published a blog post a few minutes ago: https://alexcbecker.net/blog/prompt-injection-benchmark.html