Nodejs 10.24

[Cookie Grosky]

YesterdayApril 17, 2024) around 16:00 UTC I started receiving reports from users that they couldn't connect to secure hosts through the app, and a GitHub issue was raised. The source of the issue comes from the fact that the users have an incomplete certificate chain on their system, and unlike web browsers that use TLS AIA extension or use their own CA bundle, Node does not automatically complete the certificate chain, which results in an OpenSSL error like the follows (full error log in a linked issue):

After some investigations with the author of GitHub issues, it was found that it only affects users who are using ESET antivirus products. There are more than 5 affected users so far who reported this either on GitHub or in the Discord community.

It is important to clarify, that it is not a bug of the specific application as it affects all outgoing connections from other apps that do not implement the TLS AIA extension, here's a minimal reproducible example of a script that results in the same error for the affected users:

The users were also asked to run the following command to connect to an affected host directly by using the OpenSSL client, which resulted in a failed SSL handshake (Verification error: unable to get local issuer certificate):

I have confirmed the same behavior. As a customer of ESET, all of our dev machines were having "unable to verify the first certificate" with nodejs. Removing ESET SSL protection fixed the issue. This only occurred this morning.

It's a shame this forum exists yet a useful post with all relevant info is ignored until a support ticket is raised. This issue caused a huge headache, and OP posting this was a huge help in confirming it wasn't an isolated issue.

which just disables SSL all together and is obviously a bad idea.

The current solution is to disable HTTPS traffic scanning in the advanced settings. This should be fixed asap, many developers depend on node.

No, it's much worse. You willfully pushed out a change without warning that brings down line of business systems. That's negligence. I get the sense that you don't fully understand how serious this is.

I have raised a ticket and will be pursuing.

This solution not possible when deploying to a server using GitHub Action Runner because GitHub Actions does not let you specify command line arguments for security reaons.

Furthermore, adding in TLS exception is unwise because the location of the node exe can change. Right now, my server using GitHub Action Runner and ESET Server Security 11 has the following installations of node:

C:\actions-runner\externals.2.315.0\node16\bin\node.exe

C:\actions-runner\externals.2.315.0\node20\bin\node.exe

C:\actions-runner\externals.2.314.1\node16\bin\node.exe

C:\actions-runner\externals.2.314.1\node20\bin\node.exe

In a few weeks when the GHA runner is updated, there will be a new folder and the TLS exception won't include it and my deployment will fail.

I need to add root cause anaylsis into our ISO27001 Information Management Systems. What was the root cause of your release without warning that directly affects business line systems? Can we expect a public blog article explaining the change, how it was signed off and what mitigations will be performed in the future? What assurance can you give that you won't release another security update without warning that might grossly affect a business line system?

I've raised this on the UK support ticket (CASE_00747921) but have been told that "Head Office" is the right place and that is here.

Thanks to this thread I was able to provide a workaround to my customers who opened a support ticket. I'm personally an ESET customer and I'm disappointed that an update that breaks all Node applications got rolled out, was identified as faulty here, and several days later, the update has not been rolled back. This is a high severity incident and should be handled as such.

In Apigee Edge we have "Hosted Target" to run the server less nodejs code. In apigee X "Hosted Target" is removed. Kindly suggest how can i run my Nodejs in Apigee X. Is there any alternative way to run nodejs code by deploying code in server less environment and run the code by calling url. I found some videos on youtube about Cloud Run. If anyone implemented this in apigee X using Cloud Run, Please share the steps and sample code.

Some history, for those who are interested: the Hosted Target feature was a way for you to bundle your nodejs code with your API Proxy configuration, and deploy them as one unit. In fact the Hosted Target feature was intended to be a replacement for nodejs targets, which was an ingenious way to introduce instability into the Message Processor, by allowing anyone to write nodejs code that runs in-process. That is what the node target did, running on Rhino + Trireme, within the JVM. Hosted Targets was a huge improvement over that model, delegating the running of the nodejs code to... I think Google App Engine. This was much better than the node target, much more reliable. But still there are compromises with this Hosted Targets model.

With the move to Google Cloud, it does not make sense to "bundle" nodejs code with the API proxy any longer. I suggest that you build and run your nodejs app in Cloud Run. It's easy to do, and it will perform well. Keep the API proxy configuration in Apigee.

The output of that will give you an endpoint. You can then connect from your Apigee X proxy into that cloud run endpoint, using Google Authentication. You'll need to grant the role roles/run.invoker to the service account , to allow it to invoke that cloud run service. More on that here. (Though the endpoint is public it will be restricted from outside invocation.)

@dchiesa1 Thanks for the Quick response. Can I call Apigee X api proxy url from nodejs code using cloudRun...? In my existing Apigee Edge account I used Hosted Target for proxy chaining(Calling another Api proxy internally).

Yes , in general, you can call from CloudRun-hosted logic to Apigee-managed endpoints. CloudRun assets run within your Google Cloud VPC, and because of that it is possible for you, or your network administrators, to introduce network restrictions that would prevent this connectivity. But in general, It is possible.

When you give App Platform access to your code, it defaults to using a Dockerfile if one is present in the root of the directory or specified in the app spec. Otherwise, App Platform checks your code to determine what language or framework it uses. If it supports the language or framework, it chooses an appropriate resource type and uses the proper buildpack to build the app and deploy a container.

App Platform uses version 0.4.0 of the Node.js Cloud Native Buildpack by default. If no version is specified in your app, for NodeJS v1 App Platform defaults to using version 20.x and for NodeJS v0 App Platform defaults to using version 16.x.

Our nodejs-buildpack needs node_modules to be present in project.In order to fix this, the user needs to add a .yarnrc.yml file with config - nodeLinker: node-modules.This tells yarn to generate node_modules.

If your app is failing to build and you suspect that the issue is related to node_modules caching, you can force clear the cache and start a new build. To do this in the control panel, navigate to your app, click the Actions menu, and then select Force Build and Deploy.

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

By default this will setup deb/rpm repositories from nodesource.com, which include up to date NodeJS packages. If you prefer to use distro provided package you can disable this behavior by setting node['nodejs']['install_repo'] to false.

Npm is included in nodejs installs by default. By default, we are using it and call it embedded. Adding recipe nodejs::npm assure you to have npm installed and let you choose install method with node['nodejs']['npm']['install_method']

You can specify a NODE_ENV environment variable, in the case that some element of your installation depends on this by using attribute :node_env. E.g., using node-config as part of your postinstall script. Please note that adding the --production option will override this to NODE_ENV=production.

3a8082e126