176 karma · joined May 1, 2013
However, if I am reading this correctly, your PoC falls in the category described here: https://react2shell.com/
> Anything that requires the developer to have explicitly exposed dangerous functionality to the client is not a valid PoC. Common examples we've seen in supposed "PoCs" are vm#runInThisContext, child_process#exec, and fs#writeFile.
> This would only be exploitable if you had consciously chosen to let clients invoke these, which would be dangerous no matter what. The genuine vulnerability does not have this constraint. In Next.js, the list of server functions is managed for you, and does not contain these.
Context: This is from Lachlan Davidson, the reporter of the vulnerability
They are probably referring to the text in the basic auth "pop-up" which is usually set like
WWW-Authenticate: Basic realm="my text"
Not sure if that was the missing case for you, but just in case someone reads this and gets the same feeling as me
The word "bad" is also used several times, and can be argued is also useful to put in the title
Granted it's far from as smart as pebble, but that battery life... ♥
https://boehs.org/node/everything-i-know-about-the-xz-backdo...
IRC activity
https://www.docker.com/blog/news-from-aws-reinvent-docker-of...
To quote the example in the article:
You can pull the images by simply switching from using docker pull ubuntu:16.04 to docker pull public.ecr.aws/docker/library/ubuntu:16.04. We automatically push images to ECR Public when they are updated on Docker Hub so you will get all the latest releases wherever you pull from.
I have had luck with using Amazon ECR Public https://www.docker.com/blog/news-from-aws-reinvent-docker-of...
To quote the example in the article:
You can pull the images by simply switching from using docker pull ubuntu:16.04 to docker pull public.ecr.aws/docker/library/ubuntu:16.04. We automatically push images to ECR Public when they are updated on Docker Hub so you will get all the latest releases wherever you pull from.
> In Node.js, the answer involves a WebSocket to TCP socket proxy, Asyncify, and patching deep PHP internals like php_select. It's complex, but there's a reward. The Node.js-targeted PHP build can request web APIs, install composer packages, and even connect to a MySQL server.
Hm, that sounds very interesting and promising
That might have been true at some point, but certainly is not the case anymore. In fact, automatic updates is a "strategic initiative" for Drupal core:
https://www.drupal.org/about/core/strategic-initiatives/auto...
This still means there is no out of the box way to update Drupal core automatically _yet_, but you can in fact do so with a contributed project, developed and maintained by people that are contributing to the core initiative.
Basically... They're working on it
I went to read the comments here to see if Daniel somehow acknowledged this
1. Change the response times by a lot and find a price for that.
2. Not continue the conversation since the product does not meet their requirements
I am confident this is the right decision
Also a very good point, and something I asked them about. Could be just copy paste and that they really don't need those numbers towards me.
Otherwise thanks for the great advice!