ibm / node-sdk-core Goto Github PK

Started getting this error after 4.0.1 was released. Error was not present with 4.0.0.
App has a direct dependency on latest @ibm-cloud/platform-services which has a dependency on this project.

Error: JsonWebTokenError: secret or public key must be provided
    at IamTokenManager.JwtTokenManager.saveTokenInfo (/app/node_modules/ibm-cloud-sdk-core/auth/token-managers/jwt-token-manager.js:111:19)
    at IamTokenManager.IamRequestBasedTokenManager.saveTokenInfo (/app/node_modules/ibm-cloud-sdk-core/auth/token-managers/iam-request-based-token-manager.js:137:40)
    at /app/node_modules/ibm-cloud-sdk-core/auth/token-managers/token-manager.js:109:19
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

Hi,

we have done the migration of Watson service and the consequent update of the library ibm-watson.

After the update our script doesn't work properly and returns the following error:

{ Error: write EPROTO 140502679459712:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:252:

at RequestWrapper.formatError (/home/Mauden01/workspace/script_upload/upload_doc_js/node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:208:21)
at /home/Mauden01/workspace/script_upload/upload_doc_js/node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:196:25
at process._tickCallback (internal/process/next_tick.js:68:7)

message:
'write EPROTO 140502679459712:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:252:\n',
statusText: 'EPROTO',
body:
'Response not received - no connection was made to the service.' }

To understand if the problem was inherent with the environment, we have tried the following simple code, but returns the same error:

var DiscoveryV1 = require('ibm-watson/discovery/v1');
const { IamAuthenticator } = require('ibm-watson/auth');

const discovery = new DiscoveryV1({
    version: '2019-04-30',
    authenticator: new IamAuthenticator({
        apikey: '*************',
    }),
    url: '*************'
});

discovery.getCollection({
    environmentId: "********",
    collectionId: "********",
}).then(collection => {
    console.log('collection', collection)
}).catch(err => {
    console.log('---------------- ERROR GETCOLLECTION:', err)
})

We have tried the same code in local and works properly.

Another test done consists in the use of request library on the VM. Following the code:

const request = require('request');

var env = "********";
var col = "********";
var document_id = "1234"

request.get(`https://gateway-fra.watsonplatform.net/discovery/api/v1/environments/${env}/collections/${col}/documents/${document_id}`, {
    qs: {
        version: '2019-04-30'
    },
    auth: {
        user: 'apikey',
        pass: '************',
        sendImmediately: false
    },
    json: true
}, function (err, data) {
    if(err){
        console.log('err', err)
    }else{
        console.log('data',data)
    }
});

We have done the same test with Axios library and it works properly on the VM:

const axios = require("axios")

var environment_id = "**********";
var collection_id = "***********";
const {
    IamAuthenticator
} = require('ibm-watson/auth');

async function run() {
    try {
        let response = await axios({
            url: `https://gateway-fra.watsonplatform.net/discovery/api/v1/enviro                                                                                                                                                                                                nments/${environment_id}/collections/${collection_id}?version=2019-04-30`,
            auth: {
                username: 'apikey',
                password: '************'
            },
        })
        console.log(response.data);
    } catch (e) {
        console.log(e.message)
    }
}

run()

Request and Axios library work properly on the VM.
So from this tests, we think that the problem is between the setting on the VM and the ibm-watson library.

Following some info of the VM where we run the code:

cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

node -v
v10.2.0

npm --versions
{ upload_doc_js: '1.0.0',
npm: '5.6.0',
ares: '1.14.0',
cldr: '33.0',
http_parser: '2.8.0',
icu: '61.1',
modules: '64',
napi: '3',
nghttp2: '1.29.0',
node: '10.2.0',
openssl: '1.1.0h',
tz: '2018c',
unicode: '10.0',
uv: '1.20.3',
v8: '6.6.346.32-node.8',
zlib: '1.2.11' }

openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017

echo "$http_proxy"
http://proxy.online.***.net:8080/

echo "$https_proxy"
http://proxy.online.***.net:8080/

Thanks

The Node-RED Watson nodes which depend on IBM-Watson, and in turn node-sdk-core are no-longer deploying in IBM Cloud due to a vulnerability in Axios 0.18.0.

The current release of node-sdk-core has a dependancy to Axios at 0.18.0

The dependancy in node-sdk-core needs to be bumped to remove this vulnerability.

Hi all, I'm using ibm-cloud-sdk-core (v4.0.2), when trying to authenticate with VpcInstanceAuthenticator, getting "Caught exception from VPC 'create_access_token' operation: The version value cannot be before 2022-03-01".

From debug I see that '2021-09-20' passed by default, I don't see any option to change it.

Since this issue was originally found when referencing ibm-watson package, the ticket was originally created there. It appears to be an issue derived from referencing the node-cloud-sdk-core package. The last version of the ibm-cloud-sdk-core that is able to be bundled is 2.17.0. The details to reproduce the issue are contained in the ticket below:

watson-developer-cloud/node-sdk#1119

When bundling node applications is it desirable to keep the overall bundle size small, even if the application is only used on the server side. One state of the art mechanism to achieve this is tree shaking, e.g. via webpack.

Tree shaking however only works with ES6 style modules, not with commonjs style modules. Libraries that support tree shaking expose multiple entry points via the package.json, one for commonjs (main) and one for es6 style modules (module).

Since the SDK is based on TS, transpiled to JS, this is very easy to achieve by adding two compile steps. One for JS (the current one) and one for ES6 based on a derived tsconfig.json, e.g. such as this:

{
    "extends": "./tsconfig.json",
    "compilerOptions": {
        "target": "ES6",
        "module": "ESNext",
        "outDir": "./dist/es",
        "declaration": true
    }
}

This would help applications tremendously, getting the overall size down and would also avoid as a desirable side effect to exclude test level libraries from production bundles (since they would be tree shaken).

Hello! I didn't see an issue related to my problem, so I'll go ahead and tell the problem I am facing. Currently, the app we are using to connect to the watson assistance is behind a DMZ, so, only selected ports are opened, in the case of watson we are using the port 443. The problem is we somehow can't receive the answer after the message has been sent. Here's what the app says when I want to send a message:

I wonder if it is related to that port not being opened?

Hi there

This is my first bug report / issue so apologies with any issues with it.

> [email protected] build
> tsc && cp package.json dist/

node_modules/ibm-cloud-sdk-core/es/lib/content-type.d.ts:4:35 - error TS2304: Cannot find name 'File'.

4     fromFilename: (file: String | File | Buffer | NodeJS.ReadableStream | FileObject) => string;
                                    ~~~~


Found 1 error.

Versions:

"typescript": "4.4.4"
"ibp-node-sdk": "^0.1.12"
"ibm-cloud-sdk-core": "2.17.10"

Node: v16.12.0

I'm building a library, that will eventually go into a server side application but the build is failing because of dependency on the DOM File type.

This was reported in #9, however only the readable stream was fixed and not File.

I'm not too sure what a possible fix could be, maybe an interface with just a subset of what's actually needed from File

Overview

• The package-lock.json is locking down library versions for all transitive (child) dependencies in the hierarchy
• Problem: This prevents the consuming service that is installing this library to automatically pick-up the latest security fixes based on the semvers defined in package.json and all child dependencies
  • e.g. We typically run npm update to pull in the latest library versions
  • Also, it defeats the npm tree-shaking mechanism to consolidate duplicate library versions into single version based on semver restrictions
• Note: Including package-lock.json at the library level doesn't seem to be an industry standard or best practice based on the most popular Node libraries in the ecosystem
• From a DevOps perspective, only top level services that include these libraries should define a package-lock.json when deploying the app to different environments (DEV, QA, PROD)
• Solution: The request is to simply remove and do not generate the package-lock.json file

Related Issues (regarding packaging)

• #266
• #174

in your package json you are using axios-cookiejar-support ^1.0.0

this version is already at 4.0.3 https://github.com/IBM/node-sdk-core/blob/main/package.json

today axios itself upgraded to version 1 https://github.com/axios/axios/releases/tag/v1.0.0

and when using axios v1, node_sdk is no longer working

example of an error

Cannot find module 'axios/lib/defaults' from 'node_modules/axios-cookiejar-support/lib/index.js'

Require stack:
      node_modules/axios-cookiejar-support/lib/index.js
      node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/token-manager.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/jwt-token-manager.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/iam-request-based-token-manager.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/iam-token-manager.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/index.js
      node_modules/ibm-cloud-sdk-core/auth/authenticators/cloud-pak-for-data-authenticator.js
      node_modules/ibm-cloud-sdk-core/auth/authenticators/index.js
      node_modules/ibm-cloud-sdk-core/auth/index.js
      node_modules/ibm-cloud-sdk-core/lib/base-service.js
      node_modules/ibm-cloud-sdk-core/index.js
      node_modules/@ibm-cloud/cloudant/cloudant/v1.js
      node_modules/@ibm-cloud/cloudant/index.js

ps i might need to check with that library if it's also compatible with axios 1.0

thanks

is it possible to make the library compatible with axios 1.0 and the latest version of axios-cookiejar-support

thanks

jsonwebtoken package version needs to be updated

  └─┬ [email protected]
    └── [email protected]

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ jsonwebtoken vulnerable to signature validation bypass due   │
│               │ to insecure default algorithm in jwt.verify()                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ jsonwebtoken                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=9.0.0                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ c71d4fb387532698c547b72cd9ce7d3dc531c3c534cbbe2fb15b011aafa… │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ c71d4fb387532698c547b72cd9ce7d3dc531c3c534cbbe2fb15b011aafa… │
│               │ > ibm-cloud-sdk-core > jsonwebtoken                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://github.com/advisories/GHSA-qwph-4952-7xr6            │
└───────────────┴──────────────────────────────────────────────────────────────┘

when i add my process.env.DEBUG variable to "ibm-cloud-sdk-core:info" i not only get the info items i also get an ERROR log , while this is not an error

"@ibm-cloud/cloudant": "^0.0.21",
"typescript": "^4.5.2",
"webpack": "^5.64.3",

node v16.13.0

  ibm-cloud-sdk-core:info Credential file does not exist. Will not be used +0ms
  ibm-cloud-sdk-core:info Credential file does not exist. Will not be used +2ms
  ibm-cloud-sdk-core:info Credential file does not exist. Will not be used +3ms
  ibm-cloud-sdk-core:error {
  ibm-cloud-sdk-core:error   status: 200,
  ibm-cloud-sdk-core:error   statusText: 'OK',
  ibm-cloud-sdk-core:error   headers: {
  ibm-cloud-sdk-core:error     'cache-control': 'must-revalidate',
  ibm-cloud-sdk-core:error     connection: 'close',
  ibm-cloud-sdk-core:error     'content-length': '208',
  ibm-cloud-sdk-core:error     'content-type': 'application/json',
  ibm-cloud-sdk-core:error     date: 'Wed, 24 Nov 2021 20:29:36 GMT',
  ibm-cloud-sdk-core:error     server: 'CouchDB/2.3.1 (Erlang OTP/19)',
  ibm-cloud-sdk-core:error     'x-couch-request-id': 'a94debd32c',
  ibm-cloud-sdk-core:error     'x-couchdb-body-time': '0'
  ibm-cloud-sdk-core:error   },
....
ibm-cloud-sdk-core:error   data: {
  ibm-cloud-sdk-core:error     couchdb: 'Welcome',
  ibm-cloud-sdk-core:error     version: '2.3.1',
  ibm-cloud-sdk-core:error     git_sha: 'c298091a4',
  ibm-cloud-sdk-core:error     uuid: '3fd2dc04a0c4b62f04ff84157d3bca8d',
  ibm-cloud-sdk-core:error     features: [ 'pluggable-storage-engines', 'scheduler' ],
  ibm-cloud-sdk-core:error     vendor: { name: 'The Apache Software Foundation' }
  ibm-cloud-sdk-core:error   }
  ibm-cloud-sdk-core:error } +0ms
$cloudant (constructor): Initialisation done - {"couchdb":"Welcome","version":"2.3.1","git_sha":"c298091a4","uuid":"3fd2dc04a0c4b62f04ff84157d3bca8d","features":["pluggable-storage-engines","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

thanks

Remember, an issue is not the place to ask questions. You can use
Stack Overflow for that, or
you may want to start a discussion on dW Answers.

Before you open an issue, please check if a similar issue already exists or has been closed before.

Hi,
Since change #275 was merged, our downstream dependencies using this repo are failing with the following error:

Exception during run: Error: Cannot find module '@jest/globals'
code: 'MODULE_NOT_FOUND',
requireStack: [
  '/opt/ibm/app/node_modules/ibm-cloud-sdk-core/lib/sdk-test-helpers.js',
  '/opt/ibm/app/node_modules/ibm-cloud-sdk-core/index.js',

Assuming this would likely be breaking your internal building suite too.

I think the change here should be as simple as adding @jest/globals to your package.json and this should resolve things.
Thank you!

When reporting a bug, please be sure to include the following:

• Steps to reproduce
• Expected behavior - should install successfully
• Actual behavior - fails to install
• Node version - 18
• SDK version

When you open an issue for a feature request, please add as much detail as possible:

• A descriptive title starting with the service name
• A description of the problem you're trying to solve
• A suggested solution if possible

We are seeing a vulnerability in the node sdk core package.
The new axios version has been released https://github.com/axios/axios/releases/tag/v1.6.4 so it is possible to fix the vulnerability.

Remember, an issue is not the place to ask questions. You can use
Stack Overflow for that, or
you may want to start a discussion on dW Answers.

Before you open an issue, please check if a similar issue already exists or has been closed before.

When reporting a bug, please be sure to include the following:

• Steps to reproduce : change dependencies to "ibm-cloud-sdk-core": "^4.1.4", run npm update, run npm start
• Expected behavior : app started
• Actual behavior : app failed to start with below errors

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/defaults' is not defined by "exports" in /Users/whitney/workspace/aria/gobot-commands-processor/node_modules/axios/package.json
   at new NodeError (node:internal/errors:405:5)
   at exportsNotFound (node:internal/modules/esm/resolve:362:10)
   at packageExportsResolve (node:internal/modules/esm/resolve:698:9)
   at resolveExports (node:internal/modules/cjs/loader:567:36)
   at Module._findPath (node:internal/modules/cjs/loader:636:31)
   at Module._resolveFilename (node:internal/modules/cjs/loader:1063:27)
   at Module._load (node:internal/modules/cjs/loader:922:27)
   at Module.require (node:internal/modules/cjs/loader:1143:19)
   at require (node:internal/modules/cjs/helpers:119:18)
   at Object.<anonymous> (/Users/whitney/workspace/aria/gobot-commands-processor/node_modules/axios-cookiejar-support/lib/index.js:8:40) {
 code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}

• Node version: 18.18.2
• SDK version :4.1.4

When you open an issue for a feature request, please add as much detail as possible:

• A descriptive title starting with the service name
• A description of the problem you're trying to solve
• A suggested solution if possible

Although this is not a big deal , there are a few packages currently reported as dependency, that rather should be dev dependencies as they are mostly used during build phase and not at run time

"dependencies": {
    "@types/debug": "^4.1.12",
    "@types/file-type": "~5.2.1",
    "@types/isstream": "^0.1.0",
    "@types/node": "~10.14.19",
    "@types/tough-cookie": "^4.0.0",
    "expect": "^26.1.0"
  },

thanks

Remember, an issue is not the place to ask questions. You can use
Stack Overflow for that, or
you may want to start a discussion on dW Answers.

Before you open an issue, please check if a similar issue already exists or has been closed before.

When reporting a bug, please be sure to include the following:

• Steps to reproduce
• Expected behavior
• Actual behavior
• Node version
• SDK version:

When you open an issue for a feature request, please add as much detail as possible:

• A descriptive title starting with the service name
• A description of the problem you're trying to solve : dependency check was failed for old version of axios, see screenshot
• A suggested solution if possible : upgrade to latest 0.21.3

I faced an issue with the package when executed ts build:

C:\...\...\node_modules\typescript\bin\tsc
node_modules/ibm-cloud-sdk-core/lib/content-type.d.ts:4:35 - error TS2304: Cannot find name 'File'.

4     fromFilename: (file: String | File | ReadableStream | Buffer | FileObject) => string;
                                    ~~~~

node_modules/ibm-cloud-sdk-core/lib/content-type.d.ts:4:42 - error TS2304: Cannot find name 'ReadableStream'.

4     fromFilename: (file: String | File | ReadableStream | Buffer | FileObject) => string;
                                           ~~~~~~~~~~~~~~

I'm working on change cloudant module to https://github.com/IBM/cloudant-node-sdk, and for authentication purpose, I'm using

const { CloudantV1 } = require('@ibm-cloud/cloudant');
const { IamAuthenticator } = require('ibm-cloud-sdk-core');
cloudantDB = CloudantV1.newInstance({
	authenticator: authenticator,
	httpsAgent: keepAliveAgent,
	serviceName: cloudantIamClientId || "pipeline-ui",
	serviceUrl: config.cloudantUrl
});

when I testing my code locally, I hit the following UnhandledPromiseRejectionWarning, do I need to be worried?

We are seeing a CVE on the module.
The CVE is: CVE-2023-45857

Vulnerability scan summary for package-lock.json
	# of Packages scanned: 561
	# of Vulnerabilities found: 1
	Vulnerability found: Cross-site Request Forgery (CSRF) - SNYK-JS-AXIOS-6032459
		URL: https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459
		Package: axios
		Version: 1.4.0
		Introduced By: ibm-cloud-sdk-core:4.1.2 --> axios:1.4.0
		Severity: high
		Description: axios is a promise-based HTTP client for the browser and Node.js.
			
			Affected versions of this package are vulnerable to Cross-site Request Forgery (CSRF) due to inserting the X-XSRF-TOKEN header using the secret XSRF-TOKEN cookie value in all requests to any server when the XSRF-TOKEN0 cookie is available, and the withCredentials setting is turned on. If a malicious user manages to obtain this value, it can potentially lead to the XSRF defence mechanism bypass.
		Updated at: 2023-10-25T07:24:40.920085Z
		Codes: [CVE-2023-45857]

In v2.0.1, when the tests were converted to typescript, ts-jest was also introduced as a dependency. However, now, when installing this package (or more likely ibm-watson) will show the following error message:

$ npm install
npm WARN [email protected] requires a peer of jest@>=24 <25 but none is installed. You must install peer dependencies yourself.

which can be confusing / annoying to end-users to see.

Given that the test utilities exists to provide functionality to downstream modules, and not even to the node-sdk-core itself, it may be good to split it apart into its own publish package which those downstream consumers can still import it as necessary for their testing, but it does not get dragged into production code of external users.

i got this warning this morning

thanks

# npm audit report

jsonwebtoken  <=8.5.1
Severity: high
jsonwebtoken's insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC - https://github.com/advisories/GHSA-hjrf-2m68-5959
jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify() - https://github.com/advisories/GHSA-qwph-4952-7xr6
jsonwebtoken unrestricted key type could lead to legacy keys usage  - https://github.com/advisories/GHSA-8cf7-32gw-wr33
jsonwebtoken has insecure input validation in jwt.verify function - https://github.com/advisories/GHSA-27h2-hvpr-p74q
No fix available
node_modules/ibm-cloud-sdk-core/node_modules/jsonwebtoken
  ibm-cloud-sdk-core  >=0.3.0
  Depends on vulnerable versions of jsonwebtoken
  node_modules/ibm-cloud-sdk-core
    @ibm-cloud/cloudant  *
    Depends on vulnerable versions of ibm-cloud-sdk-core
    node_modules/@ibm-cloud/cloudant

I upgraded some of my stuff from using the 1.0.0-rc4 to 1.0.0 and noticed that two of the endpoints I am using in the ibm-watson downstream package I was using for my work now no longer return properly, breaking things downstream. Rolling back to 1.0.0-rc4 gets them working again. I am running node 12.

My downstream proof-of-concept files:

index.js:

const TextToSpeechV1 = require('ibm-watson/text-to-speech/v1');
const SpeechToTextV1 = require('ibm-watson/speech-to-text/v1');

const tts = new TextToSpeechV1({});
const stt = new SpeechToTextV1({});

tts.listVoices({}).then((response) => {
  console.log('--got tts response--');
}).catch((err) => console.error(err));

stt.listModels({}).then((response) => {
  console.log('--got stt response--');
}).catch((err) => console.error(err));

running it:

$ npm list ibm-cloud-sdk-core
[email protected] /Users/mpeveler/work/cisl/poc
├── [email protected]
└─┬ [email protected]
  └── [email protected]  deduped
$ node index.js
$ npm install [email protected]
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

+ [email protected]
updated 59 packages and audited 832 packages in 5.191s
found 0 vulnerabilities
$ node index.js
--got stt response--
--got tts response--

When reporting a bug, please be sure to include the following:

• Steps to reproduce
• Expected behavior
• Actual behavior
• Node version
• SDK version

When you open an issue for a feature request, please add as much detail as possible:

• A descriptive title starting with the service name
• A description of the problem you're trying to solve
• A suggested solution if possible

• Steps to reproduce
  Add [email protected] library to package.json, it will add [email protected] as dependency. In return [email protected] is adding [email protected] instead of latest. And this version is having a dependency on yargs-parser. Which is failing for contrast.
• Expected behavior
  The application should run with contrast but its failing when contrast is enabled. As yargs-parser referred is older version and creating problems.
• Actual behavior
  Contrast enabled server fail to start and gives a message.
  "ERR npm WARN [email protected] requires a peer of jest@>=24 <25 but none is installed. You must install peer dependencies yourself."
• Node version
  10.16.3
• SDK version
  IBM SDK for Node.js Buildpack v4.3-20200606-1928

When you open an issue for a feature request, please add as much detail as possible:

• A descriptive title starting with the service name
  [email protected]
  SDK for Node.js
  umanam
  umanam
  23 Jun 2020 (an hour ago)

I'm using [email protected] and it is using [email protected]. This is using ts-jest as dependency and loading older version [email protected]. There is the problem and its failing in contrast build.

I get error "ERR npm WARN [email protected] requires a peer of jest@>=24 <25 but none is installed. You must install peer dependencies yourself." while deploying application, even fixing with these suggestion its not helping. At the end its conflicting on version of yargs-parser library referenced in ts-jest. Please fix the issue with ibm-cloud-sdk-core package.json, so that it loads correct version of dependencies.

• A description of the problem you're trying to solve
  We want to enable fetch of latest ts-jest library with latest [email protected].
  Testing --- Repackage library ibm-cloud-sdk-core and invoke in a project then try if its pulling latest ts-jest or not.
• A suggested solution if possible

Hi,
Currently the SDK supports 2 options for retry mechanism maxRetries, maxRetryInterval
We have a requirement where the SDK could support timeout and perCallTimeout options for retry mechanism.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Could you please publish a new package ?
maybe not under 0.3.x ? as contains major release of axios

thanks

There seems to be an issue on the request-wrapper file which has been modified just few hours back.

Due to this other package(ibm-watson) which is using this package on version 2.4.3 is having error as follows:

Bad Request: Missing 'version' query parameter
at RequestWrapper.formatError (/home/masteradmin/lucy-latest/Lucy-Next-Application/node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:223:21)
at /home/masteradmin/lucy-latest/Lucy-Next-Application/node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:211:25
at Immediate. (/home/masteradmin/lucy-latest/Lucy-Next-Application/node_modules/es6-shim/es6-shim.js:1382:26)
at processImmediate (internal/timers.js:456:21)
at process.topLevelDomainCallback (domain.js:137:15) {
statusText: 'Bad Request',

This is error from Watson assistant as its APIs require version as its query string but its not being sent via this package.

I think issue is that query parameter is not being sent correctly due to these changes because of which all packages using 2.4.3 version of this package and hitting this function is unable to send query parameters as part of the request.

It works fine on previous version of the same package which is before last merge. Issue is on request-wrapper file and clearly requests are not able to send the query parameters.

• We have identified a security vulnerability in the route that ends with ibm-cloud-sdk-core>axios>follow-redirects for follow-redirects version 1.14.6.
• Same has been resolved in follow-redirects version 1.14.7 which is consumed by axios version 0.25.0
• ibm-cloud-sdk-core is currently using axios version 0.21.4 (https://github.com/IBM/node-sdk-core/blob/main/package.json#L81)

Upgrading to axios version 0.25.0 will help us to resolve this vulnerability.

The authenticator interface has the following syntax:

public authenticate(requestOptions: AuthenticateOptions): Promise<void | Error>

https://github.com/IBM/node-sdk-core/blob/main/auth/authenticators/authenticator.ts

Normally a Promise handles errors via its exception channel and regular values via its data channel. The type parameter identifies the data channel, promises do not have a way to specify the type of the exceptional channel.

Is it indeed intended to pass an error on the data channel? If so, why?
If not, the signature should be:

public authenticate(requestOptions: AuthenticateOptions): Promise<void>

Error Description:

Library debug is specified into dependencies, but related @types/debug is missing.
Transpiler produces the following error at build time:

node_modules/ibm-cloud-sdk-core/es/lib/get-new-logger.d.ts:16:26 - error TS7016: Could not find a declaration file for module 'debug'. '/node_modules/debug/src/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/debug` if it exists or add a new declaration (.d.ts) file containing `declare module 'debug';`
16 import { Debugger } from 'debug';

Solution:

Add "@types/debug": "^4.1.12" into devDependencies

Workaround (Tested):

Add explicit "@types/debug": "^4.1.12" into the main project, in addition to "node-sdk-core".

Thanks

We are planning a major release of this package for September, 2019. Goals and intended breaking changes will be documented here:

watson-developer-cloud/node-sdk#897

We are seeing a CVE on the module.
The CVE is: CVE-2022-25883

	Vulnerability found: Regular Expression Denial of Service (ReDoS) - SNYK-JS-SEMVER-3247795
		URL: https://security.snyk.io/vuln/SNYK-JS-SEMVER-3247795
		Package: semver
		Version: 6.3.0
		Introduced By: ibm-cloud-sdk-core:4.0.8 --> semver:6.3.0
		Severity: medium
		Description: semver is a semantic version parser used by npm.
			
			Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.
		Remediation: 7.5.2
		Updated at: 2023-06-20T15:39:58.315102Z
		Codes: [CVE-2022-25883]

This SDK is used by several other IBM cloud SDKs, in my case the @ibm-cloud/secrets-manager SDK. My application is a consumer of the @ibm-cloud/secrets-manager and I would like to package it (and its dependencies) as part of my app.

I notice that this causes a significant amount dependencies to be pulled in that are not required for production and that should also not appear in the dependencies of a production level application, e.g. the expect package. This package is meant to write unit tests and should only be a development level dependency. It alone adds around 200KB to the overall bundle size, because it in turn depends on jest packages which should not exist in a production environment either (see https://bundlephobia.com/package/[email protected])

The reason for this dependency is the fact that this core SDK exports utility functions for testing purposes as part of its regular index (https://github.com/IBM/node-sdk-core/blob/main/index.ts#L21)
Since this SDK is also only available as a commonjs package, there is also no way to use tree shaking to get rid of these undesirable and unused dependencies.

I suggest to move the test functions to a sub-package with its own package.json and its own dependencies. This way consuming SDKs can still make use of the exported test helpers but they would not interfer with the production usage of the package.

Besides the undesirable bundle size this also effects legal clearance when we at IBM depend on the SDK, because test level packages typically do not have to be cleared with the same diligence as production level packages. With the current design, we are forced to clear test packages.

Hello,
when releasing our Application from Azure DevOps, we encounter this error:

2022-06-17T12:23:12.2811600Z Copying file: 'node_modules/ibm-cloud-sdk-core/ibm-cloud-sdk-core.d.ts'
2022-06-17T12:23:12.2815569Z Error: EISDIR: illegal operation on a directory, open '/home/site/wwwroot/node_modules/ibm-cloud-sdk-core/docs'

We noticed that this error started popping up with the latest releases of your package. And specifically because the /docs directory is now appearing as a file.

We mitigated it, by downgrading to version: 2.17.10 which the error doesn't appear.

Do you have any solutions for that issue apart from downgrading? Is this error planned to be fixed at a later release?

Thank you in advance.

https://security.snyk.io/vuln/SNYK-JS-FILETYPE-2958042

this project imports an old version of file-type and now a vulnerability has been discovered.

A vulnerable version of the axios package is being included by retry-axios

https://www.cve.org/CVERecord?id=CVE-2023-45857

├─┬ @ibm-cloud/[email protected]
│ └─┬ [email protected]
│   ├── [email protected]
│   └─┬ [email protected]
│     └── [email protected]