What kind of validation are you going to do without a regular expression?
9,344 karma · joined August 20, 2015
https://remi.rampin.org/
What kind of validation are you going to do without a regular expression?
CVE-2020-27347 is exactly the kind of memory safety bug exploitable by terminal output that I was talking about.
> Thomas François, 52, a former Ubisoft editorial vice-president, was found guilty of sexual harassment.
> Serge Hascoët, 59, Ubisoft’s former chief creative officer and second-in-command, was found guilty of psychological harassment and complicity in sexual harassment.
> The former Ubisoft game director, Guillaume Patrux, 41, was found guilty of psychological harassment
Or maybe I am wrong about the facts? I never used Edge.
Webhooks like yours will still be needed for a while (or programmable frameworks like Kyverno).
On our HPC cluster, each user has a quota of inodes on the shared filesystem. This makes installing some software with lots of files problematic (like Anaconda). An Apptainer image is a single file on the filesystem though (basically squashfs) so you can have those with as many files as you want in each.
Installing the same software normally is easy and works fine though, you just exchaust your quota.
This is neither a possible input nor a possible output of that code.
Surely they aren't releasing a new, incompatible version and expecting us to pretend it's the same format...?
> This updates the existing image/png Internet Media type
whyyyyyyy
Now you seem even more confused. Do you mean `uv sync` will fail? `uv lock` is literally the command you run when there's a mismatch between pyproject.toml and uv.lock to update uv.lock. That's why it's called lock.
Here's a full reproducer: https://gist.github.com/remram44/21c98db9a80213b2a3a5cce959d...
Check out branch "previous-blog". Run `docker build . -t uvtest`. You will see that it builds with no error, and if you run `docker run uvtest cat /app/uv.lock`, you will see that the uv.lock in the image is NOT the one in the repo. It has been updated silently, which is what gchamonlive and myself pointed out.
Now check out branch "master". Run `docker build . -t uvtest` again. You will see `error: The lockfile at `uv.lock` needs to be updated` which is what you say always happened.
Yes, it is: both gchamonlive and myself pointed out that if your lock file exists and is out of date, your (previous) script would silently update it before installing. This would happen because `uv lock --check` would return false, triggering the call to `uv lock`.
Your new version no longer does that, because you removed `! uv lock --check` from the condition.
if ! test -f uv.lock || ! uv lock --check 2>/dev/null; then uv lock; fi
Your new version no longer has the bug we are talking about. I don't know why you are trying to pretend it was never there though?