Code Monkey home page Code Monkey logo

features's Introduction

Temporal Features

This repository contains snippets for many Temporal features written in different Temporal SDK languages. This also contains a runner and language-specific harnesses to confirm feature behavior across versions.

These features serve several purposes:

  • Ensure parity across SDKs by having same-feature snippets adjacent to one another
  • Confirm feature behavior across SDK versions
  • Confirm history across SDK versions
  • Document features in different SDKs
  • Easy-to-use environment for writing quick workflows in all languages/versions
  • Verify feature compatibility across different server setups

Building

With latest Go installed, run:

go build -o temporal-features # or temporal-features.exec on Windows

Running

Prerequisites:

Command:

temporal-features run --lang LANG [--version VERSION] [PATTERN...]

Note, go run . can be used in place of go build + temporal-features to save on the build step.

LANG can be go, java, ts, py, or cs. VERSION is per SDK and if left off, uses the latest version set for the language in this repository.

PATTERN must match either the features relative directory or the relative directory + /feature.<ext> via Go path match rules which notably does not include recursive depth matching. If PATTERN arguments are not present, the default is to run all features.

Several other options are available, some of which are described below. Run temporal-features run --help to see all options.

Preparing

By default when using run and a version, a temporary directory is created with a temporary project, the project is built, and then the features are run. To separate the steps, the prepare command can be used to prebuild the project in a directory. Then run can use the --prepared-dir to reference that directory.

The command to prepare is:

temporal-features prepare --lang LANG --version VERSION --dir DIR

The version is required and the directory is a simple string name of a not-yet-existing directory to be created directly beneath this SDK features directory. That same directory value can then be provided as --prepared-dir to run. When using a prepared directory on run, a version cannot be specified.

Building docker images

The CLI supports building docker images from prepared features.

There are 2 types of image builds supported, by SDK version or by git repository ref as shown below:

./temporal-features build-image --lang go --repo-ref master

The built image will be tagged with features:go-master

./temporal-features build-image --lang go --version v1.13.1

The built image will be tagged with features:go-1.13.1

  • To tag as latest minor, pass --semver-latest minor, this will add the go-1.13 tag.
  • To tag as latest major, pass --semver-latest major, this will add the go-1.13, go-1 and go tags.

External Server and Namespace

By default, a CLI Dev Server is dynamically started at runtime to handle all feature runs and a namespace is dynamically generated. To not start the embedded server, use --server to specify the address of a server to use. Similarly, to not use a dynamic namespace (that may not be registered on the external server), use --namespace.

History Checking

History files are present at features/<path/to/feature>/history/history.<lang>.<version>.json. By default, three history checks are performed:

  1. Specific languages use their replayers to replay the just-executed workflow's history to confirm it works.
  2. Specific languages use their replayers to replay all history files with versions <= the current version to confirm it works.
  3. The primary runner scrubs the history of the just-executed workflow of all execution-dependent values. Then it compares the exact events to all similarly-scrubbed history files.

Currently there are not ways for features to opt out of specific history checks. To opt out of all history checking for a specific run, use --no-history-check.

Writing Features

Developers can write workflows and activities that represent a SDK "feature". These are organized into directories under the features/ directory.

In addition to code for the feature, there are configuration settings that can be set in .config.json. The possible settings are:

  • go
    • minVersion - Minimum version in Go this feature should be run in. The feature will be skipped in older versions.

There are also files in the history/ subdirectory which contain history files used during run. See the "History Checking" and "Generating History" sections for more info.

Best Practices

  • Try to only demonstrate/test one feature per feature directory.

    • Code should be kept as short and clear as possible.
    • No need to over-assert on a bunch of values, just confirm that the feature does what is expected via its output.

  • A Go feature should be in feature.go.

    • For incompatible versions, different files like feature_pre1.11.0.go can be present using build tags

  • A Java feature should be in feature.java.

  • A TypeScript feature should be in feature.ts.

    NOTE: TypeScript features include workflow and non workflow code in the same file. Those are run in different environments so they may not share variables and the feature author should keep the workflow runtime limitations in mind when writing features.

  • A Python feature should be in feature.py.

  • Add a README.md to each feature directory.

    • README should have a title summarizing the feature (only first letter needs to be in title case), then a short paragraph explaining the feature and its purpose, and then optionally another paragraph explaining details of the specific code steps.
    • Other sections can also explain decisions made in language specific ways or other details about versions/approaches.
    • Feel free to add links and more text as necessary.

  • Verification/regression feature directories for bugs should be under features/bugs/<lang>.

    • Ideally the checking of the result has a version condition that shows in earlier versions it should fail and in newer versions it should succeed.

  • The more languages per non-bug feature, the better. Try not to create non-bug features that use specific language constructs unless that's the purpose of the feature.

  • Refactor liberally to create shortcuts and better harnesses for making features easy to read and write.

    • This is not a library used by anyone, there are no backwards compatibility concerns. If one feature uses something that has value to another, extract and put in helper/harness and have both use it.

  • History should be generated for each feature on the earliest version the feature is expected to work at without history changes.

Generating History

To generate history, run the same test (see the "Running" section) for the version to generate at, but use the --generate-history option. When generating history, only one test can be specified and the version of the SDK must be specified. Any existing history for that feature, language, and version will be overwritten.

History generation should only be needed when first developing a feature or when a version intentionally introduces an incompatibility. Otherwise, history files should remain checked in and not regenerated.

Usage within CI

The repo defines GitHub workflows which are designed to allow running the SDK features suites against changes to an SDK, or against changes to server. The former is accomplished by syncing the SDK repo and using it as a path-version when running the suites. The latter is accomplished by building the changes to server into a docker image, and using that docker image for the server when running the suites.

Publishing docker images of the features runner/suites is also supported. It may be run manually, but is also triggered by default on each push to main.

TODO

  • Add support for replaying testing of all versions inside each SDKs harness as part of the run
  • Add many more feature workflows
  • Document how to use this framework to easily write and test features even when not committing
  • Log swallowing and concurrent execution
  • Investigate support for changing runtime versions (i.e. Go, Java, and Node versions)
  • Investigate support for changing server versions
  • CI support
    • Support using a commit hash and alternative git location for an SDK to run against

features's People

Contributors

alexshtin avatar antlai-temporal avatar ast2023 avatar bergundy avatar cretz avatar dandavison avatar dependabot[bot] avatar dnr avatar jackdawm avatar josh-berry avatar lorensr avatar mjameswh avatar mmcshane avatar quinn-with-two-ns avatar rachfop avatar rodrigozhou avatar shahabt avatar spikhalskiy avatar sushisource avatar tdeebswihart avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

cretz pedronet4k macrogreg isabella232 spikhalskiy bergundy quinn-with-two-ns mjameswh nscloud-demo antlai-temporal dandavison tdeebswihart stephanos artinhum

features's Issues

[Feature Request] SDK should allow configurable long-poll timeouts

Is your feature request related to a problem? Please describe.

Sometimes people with unique network setups need shorter long poll timeouts. Right now we default 70s, but the server takes the client-provided timeout so we can allow it to be changed for advanced use cases.

Describe the solution you'd like

Allow the value to be configurable

Additional context

Java SDK has an issue open at temporalio/sdk-java#988

temporalio-1.0.0-rc.0.tgz: 1 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - temporalio-1.0.0-rc.0.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/terser/package.json

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in Remediation Available
CVE-2022-25858 High 7.5 terser-5.14.1.tgz Transitive N/A ❌

Details

CVE-2022-25858

Vulnerable Library - terser-5.14.1.tgz

JavaScript parser, mangler/compressor and beautifier toolkit for ES6+

Library home page: https://registry.npmjs.org/terser/-/terser-5.14.1.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/terser/package.json

Dependency Hierarchy:

  • temporalio-1.0.0-rc.0.tgz (Root Library)
    • worker-1.0.0-rc.0.tgz
      • webpack-5.73.0.tgz
        • terser-webpack-plugin-5.3.3.tgz
          • ❌ terser-5.14.1.tgz (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

The package terser before 4.8.1, from 5.0.0 and before 5.14.2 are vulnerable to Regular Expression Denial of Service (ReDoS) due to insecure usage of regular expressions.

Publish Date: 2022-07-15

URL: CVE-2022-25858

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25858

Release Date: 2022-07-15

Fix Resolution: terser - 4.8.1,5.14.2

tsconfig-paths-3.12.0.tgz: 1 vulnerabilities (highest severity is: 5.0) - autoclosed

Vulnerable Library - tsconfig-paths-3.12.0.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/minimist/package.json

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in Remediation Available
CVE-2021-44906 Medium 5.0 minimist-1.2.5.tgz Transitive 4.0.0 ✅

Details

CVE-2021-44906

Vulnerable Library - minimist-1.2.5.tgz

parse argument options

Library home page: https://registry.npmjs.org/minimist/-/minimist-1.2.5.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/minimist/package.json

Dependency Hierarchy:

  • tsconfig-paths-3.12.0.tgz (Root Library)
    • ❌ minimist-1.2.5.tgz (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

Minimist <=1.2.5 is vulnerable to Prototype Pollution via file index.js, function setKey() (lines 69-95).

Publish Date: 2022-03-17

URL: CVE-2021-44906

CVSS 3 Score Details (5.0)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: High
    • Privileges Required: Low
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: Low
    • Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2022-03-17

Fix Resolution (minimist): 1.2.6

Direct dependency fix Resolution (tsconfig-paths): 4.0.0

⛑️ Automatic Remediation is available for this issue

⛑️ Automatic Remediation is available for this issue.

github.com/temporalio/temporal-v1.16.0: 3 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - github.com/temporalio/temporal-v1.16.0

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in Remediation Available
CVE-2019-0205 High 7.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌
CVE-2019-0210 High 7.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌
CVE-2018-11798 Medium 6.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌

Details

CVE-2019-0205

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • github.com/temporalio/temporal-v1.16.0 (Root Library)
    • github.com/temporalio/ringpop-go-6f91b5915e95e7b08817aae78fea3a38ea1b5bd2
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

In Apache Thrift all versions up to and including 0.12.0, a server or client may run into an endless loop when feed with specific input data. Because the issue had already been partially fixed in version 0.11.0, depending on the installed version it affects only certain language bindings.

Publish Date: 2019-10-29

URL: CVE-2019-0205

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205

Release Date: 2019-10-29

Fix Resolution: org.apache.thrift:libthrift:0.13.0

CVE-2019-0210

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • github.com/temporalio/temporal-v1.16.0 (Root Library)
    • github.com/temporalio/ringpop-go-6f91b5915e95e7b08817aae78fea3a38ea1b5bd2
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

In Apache Thrift 0.9.3 to 0.12.0, a server implemented in Go using TJSONProtocol or TSimpleJSONProtocol may panic when feed with invalid input data.

Publish Date: 2019-10-29

URL: CVE-2019-0210

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3C277A46CA87494176B1BBCF5D72624A2A%40HAGGIS%3E

Release Date: 2019-10-29

Fix Resolution: 0.13.0

CVE-2018-11798

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • github.com/temporalio/temporal-v1.16.0 (Root Library)
    • github.com/temporalio/ringpop-go-6f91b5915e95e7b08817aae78fea3a38ea1b5bd2
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

The Apache Thrift Node.js static web server in versions 0.9.2 through 0.11.0 have been determined to contain a security vulnerability in which a remote user has the ability to access files outside the set webservers docroot path.

Publish Date: 2019-01-07

URL: CVE-2018-11798

CVSS 3 Score Details (6.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: Low
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: None
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11798

Release Date: 2019-01-07

Fix Resolution: v0.12.0

[Feature Request] Upsert TemporalChangeVersion on patch

Is your feature request related to a problem? Please describe.

Can't do:

tctl workflow list --query='TemporalChangeVersion="<change_id>-<version_id>"'

Which our docs say you should be able to do when using patch API.

image

https://docs.temporal.io/concepts/what-is-a-search-attribute

Describe the solution you'd like

Add an UpsertSearchAttributes with TemporalChangeVersion: <change_id>-<version_id> with each patch command. Apparently Go SDK does this, but Java doesn't.

SDKs

Additional context

Internal slack link

github.com/temporalio/temporal-3b8f6932d9fcb12c58cba0d461ac72a30fc9bb86: 3 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - github.com/temporalio/temporal-3b8f6932d9fcb12c58cba0d461ac72a30fc9bb86

Found in HEAD commit: d4f21b69321f143cfcf0cb7f4b94f2df2babc906

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in Remediation Available
CVE-2019-0205 High 7.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌
CVE-2019-0210 High 7.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌
CVE-2018-11798 Medium 6.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌

Details

CVE-2019-0205

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • github.com/temporalio/temporal-3b8f6932d9fcb12c58cba0d461ac72a30fc9bb86 (Root Library)
    • github.com/temporalio/ringpop-go-6f91b5915e95e7b08817aae78fea3a38ea1b5bd2
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in HEAD commit: d4f21b69321f143cfcf0cb7f4b94f2df2babc906

Found in base branch: main

Vulnerability Details

In Apache Thrift all versions up to and including 0.12.0, a server or client may run into an endless loop when feed with specific input data. Because the issue had already been partially fixed in version 0.11.0, depending on the installed version it affects only certain language bindings.

Publish Date: 2019-10-29

URL: CVE-2019-0205

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205

Release Date: 2019-10-29

Fix Resolution: org.apache.thrift:libthrift:0.13.0

CVE-2019-0210

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • github.com/temporalio/temporal-3b8f6932d9fcb12c58cba0d461ac72a30fc9bb86 (Root Library)
    • github.com/temporalio/ringpop-go-6f91b5915e95e7b08817aae78fea3a38ea1b5bd2
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in HEAD commit: d4f21b69321f143cfcf0cb7f4b94f2df2babc906

Found in base branch: main

Vulnerability Details

In Apache Thrift 0.9.3 to 0.12.0, a server implemented in Go using TJSONProtocol or TSimpleJSONProtocol may panic when feed with invalid input data.

Publish Date: 2019-10-29

URL: CVE-2019-0210

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3C277A46CA87494176B1BBCF5D72624A2A%40HAGGIS%3E

Release Date: 2019-10-29

Fix Resolution: 0.13.0

CVE-2018-11798

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • github.com/temporalio/temporal-3b8f6932d9fcb12c58cba0d461ac72a30fc9bb86 (Root Library)
    • github.com/temporalio/ringpop-go-6f91b5915e95e7b08817aae78fea3a38ea1b5bd2
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in HEAD commit: d4f21b69321f143cfcf0cb7f4b94f2df2babc906

Found in base branch: main

Vulnerability Details

The Apache Thrift Node.js static web server in versions 0.9.2 through 0.11.0 have been determined to contain a security vulnerability in which a remote user has the ability to access files outside the set webservers docroot path.

Publish Date: 2019-01-07

URL: CVE-2018-11798

CVSS 3 Score Details (6.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: Low
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: None
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11798

Release Date: 2019-01-07

Fix Resolution: v0.12.0

go.temporal.io/sdk-features/features-v1.0.0: 2 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - go.temporal.io/sdk-features/features-v1.0.0

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (go.temporal.io/sdk-features/features-v1.0.0 version) Remediation Available
CVE-2019-0205 High 7.5 github.com/uber-go/tally/v4-v4.1.2 Transitive N/A* ❌
CVE-2019-0210 High 7.5 github.com/uber-go/tally/v4-v4.1.2 Transitive N/A* ❌

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the section "Details" below to see if there is a version of transitive dependency where vulnerability is fixed.

Details

CVE-2019-0205

Vulnerable Library - github.com/uber-go/tally/v4-v4.1.2

A Go metrics interface with fast buffered metrics and third party reporters

Library home page: https://proxy.golang.org/github.com/uber-go/tally/v4/@v/v4.1.2.zip

Dependency Hierarchy:

  • go.temporal.io/sdk-features/features-v1.0.0 (Root Library)
    • ❌ github.com/uber-go/tally/v4-v4.1.2 (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

In Apache Thrift all versions up to and including 0.12.0, a server or client may run into an endless loop when feed with specific input data. Because the issue had already been partially fixed in version 0.11.0, depending on the installed version it affects only certain language bindings.

Publish Date: 2019-10-29

URL: CVE-2019-0205

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205

Release Date: 2019-10-29

Fix Resolution: org.apache.thrift:libthrift:0.13.0

CVE-2019-0210

Vulnerable Library - github.com/uber-go/tally/v4-v4.1.2

A Go metrics interface with fast buffered metrics and third party reporters

Library home page: https://proxy.golang.org/github.com/uber-go/tally/v4/@v/v4.1.2.zip

Dependency Hierarchy:

  • go.temporal.io/sdk-features/features-v1.0.0 (Root Library)
    • ❌ github.com/uber-go/tally/v4-v4.1.2 (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

In Apache Thrift 0.9.3 to 0.12.0, a server implemented in Go using TJSONProtocol or TSimpleJSONProtocol may panic when feed with invalid input data.

Publish Date: 2019-10-29

URL: CVE-2019-0210

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3C277A46CA87494176B1BBCF5D72624A2A%40HAGGIS%3E

Release Date: 2019-10-29

Fix Resolution: 0.13.0

✅ Activity Heartbeat Throttling

Align the behavior of activity heartbeat throttling on all SDKs.

Internal Temporal design doc: https://www.notion.so/temporalio/Activity-heartbeats-inconsistent-behavior-between-SDKs-32d81da0748044a8932481d2c9864791
Exported:
Activity_heartbeats_inconsistent_behavior_between_SDKs.pdf

Design

Add 2 new WorkerOptions:

  • maxHeartbeatThrottleInterval - default 60s
  • defaultHeartbeatThrottleInterval - default 30s

throttleInterval = min(heartbeat_timeout * 0.8 if heartbeat_timeout is provided, else defaultHeartbeatThrottleInterval, maxHeartbeatThrottleInterval)

Rationale

  • Make the behavior explicit and configurable
  • Keep the behavior backwards compatible
    • Java currently has an implicit maximum (30s) and default (0)
    • Go has an implicit default (10m) and no maximum
    • Core is not yet stable, from user feedback the behavior is confusing
  • Not heartbeating means no cancellations, need a default value
  • Consistency between the SDKs

Tasks

temporalio/sdk-go#656
temporalio/sdk-java#906

Metrics for consecutive workflow and activity task failures

Is your feature request related to a problem? Please describe.

Current SDK metrics support the detection of elevated levels of failures of workflow tasks or activities.
But it's impossible to distinguish between two situations. A lot of workflows are failing once or twice or there is 1 or 2 workflows that are completely stuck.

Describe the solution you'd like

New counters:
workflow_task_failed_10_times, workflow_task_failed_100_times, workflow_task_failed_1000_times
activity_failed_10_times, activity_failed_100_times, activity_failed_1000_times

With standard temporal_ prefix and _count postfix.

Example:

Every activity failure with 10 =< currentAttempt counter < 99 should increase activity_failed_10_times counter.
Every activity failure with 100 =< currentAttempt counter < 999 should increase activity_failed_100_times counter and don't increase activity_failed_10_times.

Alternative

Make a full-blown histogram with wide buckets that should be formatted according to the OpenMetrics rules for histograms With _bucket postfix and specifying the bucket: https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#histogram-1

go.temporal.io/server-v1.13.1-0.20211213192924-3c44e562605c: 4 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - go.temporal.io/server-v1.13.1-0.20211213192924-3c44e562605c

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in Remediation Available
CVE-2019-0205 High 7.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌
CVE-2022-21698 High 7.5 github.com/prometheus/client_golang-v1.11.0 Transitive N/A ❌
CVE-2019-0210 High 7.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌
CVE-2018-11798 Medium 6.5 github.com/apache/thrift-0.10.0 Transitive N/A ❌

Details

CVE-2019-0205

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • go.temporal.io/server-v1.13.1-0.20211213192924-3c44e562605c (Root Library)
    • github.com/uber/tchannel-go-v1.21.0
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in base branch: main

Vulnerability Details

In Apache Thrift all versions up to and including 0.12.0, a server or client may run into an endless loop when feed with specific input data. Because the issue had already been partially fixed in version 0.11.0, depending on the installed version it affects only certain language bindings.

Publish Date: 2019-10-29

URL: CVE-2019-0205

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0205

Release Date: 2019-10-29

Fix Resolution: org.apache.thrift:libthrift:0.13.0

CVE-2022-21698

Vulnerable Library - github.com/prometheus/client_golang-v1.11.0

Prometheus instrumentation library for Go applications

Dependency Hierarchy:

  • go.temporal.io/server-v1.13.1-0.20211213192924-3c44e562605c (Root Library)
    • ❌ github.com/prometheus/client_golang-v1.11.0 (Vulnerable Library)

Found in base branch: main

Vulnerability Details

client_golang is the instrumentation library for Go applications in Prometheus, and the promhttp package in client_golang provides tooling around HTTP servers and clients. In client_golang prior to version 1.11.1, HTTP server is susceptible to a Denial of Service through unbounded cardinality, and potential memory exhaustion, when handling requests with non-standard HTTP methods. In order to be affected, an instrumented software must use any of promhttp.InstrumentHandler* middleware except RequestsInFlight; not filter any specific methods (e.g GET) before middleware; pass metric with method label name to our middleware; and not have any firewall/LB/proxy that filters away requests with unknown method. client_golang version 1.11.1 contains a patch for this issue. Several workarounds are available, including removing the method label name from counter/gauge used in the InstrumentHandler; turning off affected promhttp handlers; adding custom middleware before promhttp handler that will sanitize the request method given by Go http.Request; and using a reverse proxy or web application firewall, configured to only allow a limited set of methods.

Publish Date: 2022-02-15

URL: CVE-2022-21698

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-cg3q-j54f-5p7p

Release Date: 2022-02-15

Fix Resolution: v1.11.1

CVE-2019-0210

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • go.temporal.io/server-v1.13.1-0.20211213192924-3c44e562605c (Root Library)
    • github.com/uber/tchannel-go-v1.21.0
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in base branch: main

Vulnerability Details

In Apache Thrift 0.9.3 to 0.12.0, a server implemented in Go using TJSONProtocol or TSimpleJSONProtocol may panic when feed with invalid input data.

Publish Date: 2019-10-29

URL: CVE-2019-0210

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: http://mail-archives.apache.org/mod_mbox/thrift-dev/201910.mbox/%3C277A46CA87494176B1BBCF5D72624A2A%40HAGGIS%3E

Release Date: 2019-10-29

Fix Resolution: 0.13.0

CVE-2018-11798

Vulnerable Library - github.com/apache/thrift-0.10.0

Apache Thrift

Dependency Hierarchy:

  • go.temporal.io/server-v1.13.1-0.20211213192924-3c44e562605c (Root Library)
    • github.com/uber/tchannel-go-v1.21.0
      • ❌ github.com/apache/thrift-0.10.0 (Vulnerable Library)

Found in base branch: main

Vulnerability Details

The Apache Thrift Node.js static web server in versions 0.9.2 through 0.11.0 have been determined to contain a security vulnerability in which a remote user has the ability to access files outside the set webservers docroot path.

Publish Date: 2019-01-07

URL: CVE-2018-11798

CVSS 3 Score Details (6.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: Low
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: None
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11798

Release Date: 2019-01-07

Fix Resolution: v0.12.0

Confirm behavior of manually returning cancellation errors in all SDKs from workfows and activities

Is your feature request related to a problem? Please describe.

It is unclear how SDKs behave in the face of manually returned cancellation errors when a cancellation is not in progress. See temporalio/sdk-go#686.

Describe the solution you'd like

  • Make sure all SDKs do not try to send RespondActivityTaskCanceledRequest to the server regardless of error type when there's not a cancellation requested from the server
  • Confirm that async complete activity still can be given cancellation error

[Feature Request] Create compatible encryption libraries

Is your feature request related to a problem? Please describe.

TS and Go encryption samples aren't compatible (despite my attempt to do things the same way): https://temporalio.slack.com/archives/C01DKSMU94L/p1657704501033689

Would be helpful to users if we gave them a cross-sdk tested library.

Describe the solution you'd like

  • Get the TS sample to be compatible, tested in this repo, and maybe change them all from samples to libraries.
  • Maybe change them to use NaCl?

From @cretz:

I'd recommend nacl-based encryption instead of AES-based encryption for cross-language compatibility for many reasons.

SDK API for describing workflow

Describe the solution you'd like

  • SDKs should make describing a workflow easy
  • Ideally, the response is a language-idiomatic wrapper that [at least] exposes a shortcut for status and provides access to the underlying DescribeWorkflowExecutionResponse
  • Do we want a different name other than describe?
  • Should existing SDKs w/ their own describe calls already in use still create this wrapper?

[Feature Request] Allow running failure fields through codec

Is your feature request related to a problem? Please describe.

Failure fields may have sensitive info, including message, stack_trace, and details, and maybe type.

https://github.com/temporalio/api/blob/4c2f6a281fa3fde8b0a24447de3e0d0f47d230b4/temporal/api/failure/v1/message.proto#L81

Most of this would require changing the fields to Payloads. Currently only details like:

https://github.com/temporalio/api/blob/4c2f6a281fa3fde8b0a24447de3e0d0f47d230b4/temporal/api/failure/v1/message.proto#L40

are converted to Payloads, and in TS SDK, it isn't put through codecs.

Describe the solution you'd like

Provide a way for them to be run through an encryption codec.

Checklist:

  • API change
  • Release a compatible server - server must add to list of capabilities
  • Go SDK
  • TS SDK
  • Java SDK
  • Python SDK
  • PHP SDK
  • Ruby SDK
  • Feature test in this repo

Wrap gRPC errors

Is your feature request related to a problem? Please describe.

Instead of just rethrowing gRPC errors, most (all?) SDKs wrap them. This is especially true for not-found.

Describe the solution you'd like

Maybe use WorkflowNotFound and ActivityNotFound that wrap the gRPC versions? But what about the newer namespace not found that can be thrown instead of workflow not found but both have the not found code? Maybe it should just be NotFound? And if so, what does that really add over the raw gRPC errors?

Needs discussion.

[Feature Request] Specify reset point in workflow code

Is your feature request related to a problem? Please describe.

Sometimes users want to update the workflow code rolling back some progress. Trivial example:

if patch("patch1") {
   sleep(10 days);
} else {
   sleep(100 days);
}

This patch is useless as if a workflow is already blocked on 100-day sleep, the patch is always going to return false, and the sleep is not going to be interrupted.

Describe the solution you'd like

Ability to reset workflow to any point by specifying the reset point in the code. Given that in many cases reset point can be reached through different code paths it is practically impossible to find the reset point just looking at a history. It is even less possible if millions of such workflows have to be reset through a batch call.

The strawman API proposal

Code before the change:

sleep(100 days);

Code after the change:

resetScope = reset("resetId");
sleep(10 days);
resetScope.close();

Any workflow that is blocked inside the resetScope (which can be modeled with real scopes and closures as well) will be rolled automatically back to the line just before reset call. After all the workflows executed the rollback the reset code can be removed.

The open question is what causes reset to happen for blocked workflows. It might require an automatically generated batch job that pokes all such blocked workflows after the code deployment.

[Feature Request] Attach info about unresolved commands to WFT completions

Is your feature request related to a problem? Please describe.

Right now, there is no way when inspecting workflow history to tell if the workflow is actually waiting on something to be resolved (ex: receive a signal) or is completely stuck and will never be able to make progress.

Beyond that, it is immediately obvious how useful it would be to know things like "Oh, I am WFT heartbeating because I'm waiting on a local activity". Or "This workflow is currently waiting on two signals", etc etc.

Describe the solution you'd like

We should add a new field to workflow task completions which allows us to record this information. Possibly, it makes good sense to just have a generic map field, so that we can record anything SDKs feel like without needing to go back and add a new field each time. However, it does make good sense to make the value we record be a proto so that it can be viewed in the UI.

We should record:

  • Number of executing local activities
  • Counts of how many of each thing that can be awaited are actively being awaited (signals, activities, timers, children, etc)

This will allow us to understand why a workflow completed a task with no commands. If it's not waiting on anything, then by definition the workflow is now stuck. Detecting this situation and alerting the user would be incredibly useful.

SDKs should expose history length and size via Workflow info

History length:

History size and "should continue as new":

[Feature Request] Standardize method for listing workflow queries/signals (and maybe other things like registered activities/workflows and other metadata)

Up until now we've used a hack to get the list of registered queries from a workflow execution.
The hack is to send a query to a workflow, which responds with something like "query not found, list of registered queries...", parse the response and show in the UI.

A standard way to support listing workflow queries would be to have a "listQueries" (name TBD) built-in query provided by the Workflow runtime.

We'd have to keep the hack around to support SDKs that still do not support the listQueries built-in query (all at the time of this writing).

UPDATE: Here is the roadmap:

temporal-sdk-1.5.0.jar: 3 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - temporal-sdk-1.5.0.jar

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.18.1/492c35bb914d122cf12ab3acaf2ba576b40f92ce/protobuf-java-3.18.1.jar

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in Remediation Available
CVE-2020-36518 High 7.5 jackson-databind-2.13.0.jar Transitive 1.8.0 ✅
WS-2021-0616 Medium 5.9 jackson-databind-2.13.0.jar Transitive 1.7.0 ✅
CVE-2021-22569 Medium 5.5 protobuf-java-3.18.1.jar Transitive 1.6.0 ✅

Details

CVE-2020-36518

Vulnerable Library - jackson-databind-2.13.0.jar

General data-binding functionality for Jackson: works on core streaming API

Library home page: http://github.com/FasterXML/jackson

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.13.0/889672a1721d6d85b2834fcd29d3fda92c8c8891/jackson-databind-2.13.0.jar

Dependency Hierarchy:

  • temporal-sdk-1.5.0.jar (Root Library)
    • jackson-datatype-jsr310-2.13.0.jar
      • ❌ jackson-databind-2.13.0.jar (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

jackson-databind before 2.13.0 allows a Java StackOverflow exception and denial of service via a large depth of nested objects.
Mend Note: After conducting further research, Mend has determined that all versions of com.fasterxml.jackson.core:jackson-databind up to version 2.13.2 are vulnerable to CVE-2020-36518.

Publish Date: 2022-03-11

URL: CVE-2020-36518

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2022-03-11

Fix Resolution (com.fasterxml.jackson.core:jackson-databind): 2.13.2.1

Direct dependency fix Resolution (io.temporal:temporal-sdk): 1.8.0

⛑️ Automatic Remediation is available for this issue

WS-2021-0616

Vulnerable Library - jackson-databind-2.13.0.jar

General data-binding functionality for Jackson: works on core streaming API

Library home page: http://github.com/FasterXML/jackson

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.13.0/889672a1721d6d85b2834fcd29d3fda92c8c8891/jackson-databind-2.13.0.jar

Dependency Hierarchy:

  • temporal-sdk-1.5.0.jar (Root Library)
    • jackson-datatype-jsr310-2.13.0.jar
      • ❌ jackson-databind-2.13.0.jar (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

FasterXML jackson-databind before 2.12.6 and 2.13.1 there is DoS when using JDK serialization to serialize JsonNode.

Publish Date: 2021-11-20

URL: WS-2021-0616

CVSS 3 Score Details (5.9)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: High
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2021-11-20

Fix Resolution (com.fasterxml.jackson.core:jackson-databind): 2.13.1

Direct dependency fix Resolution (io.temporal:temporal-sdk): 1.7.0

⛑️ Automatic Remediation is available for this issue

CVE-2021-22569

Vulnerable Library - protobuf-java-3.18.1.jar

Core Protocol Buffers library. Protocol Buffers are a way of encoding structured data in an efficient yet extensible format.

Library home page: https://developers.google.com/protocol-buffers/

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protobuf-java/3.18.1/492c35bb914d122cf12ab3acaf2ba576b40f92ce/protobuf-java-3.18.1.jar

Dependency Hierarchy:

  • temporal-sdk-1.5.0.jar (Root Library)
    • temporal-serviceclient-1.5.0.jar
      • protobuf-java-util-3.18.1.jar
        • ❌ protobuf-java-3.18.1.jar (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

An issue in protobuf-java allowed the interleaving of com.google.protobuf.UnknownFieldSet fields in such a way that would be processed out of order. A small malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated pauses. We recommend upgrading libraries beyond the vulnerable versions.

Publish Date: 2022-01-10

URL: CVE-2021-22569

CVSS 3 Score Details (5.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Local
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: Required
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-wrvw-hg22-4m67

Release Date: 2022-01-10

Fix Resolution (com.google.protobuf:protobuf-java): 3.18.2

Direct dependency fix Resolution (io.temporal:temporal-sdk): 1.6.0

⛑️ Automatic Remediation is available for this issue

⛑️ Automatic Remediation is available for this issue.

[Feature Request] Enhance error message & add error code for expired client cert

Is your feature request related to a problem? Please describe.

During one of the issues while debugging with customer it was noticed that error message when client cert is expired is not very useful and clear.

Current error message says Context deadline exceeded

Describe the solution you'd like

Have a message which clearly states Expired Certificate or something equivalent. Also it will be beneficial if we can have error code associated with this message

Additional context

temporalio-0.21.1.tgz: 1 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - temporalio-0.21.1.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/protobufjs/package.json

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in Remediation Available
CVE-2022-25878 High 7.5 protobufjs-6.11.2.tgz Transitive 0.22.0 ✅

Details

CVE-2022-25878

Vulnerable Library - protobufjs-6.11.2.tgz

Protocol Buffers for JavaScript (& TypeScript).

Library home page: https://registry.npmjs.org/protobufjs/-/protobufjs-6.11.2.tgz

Path to dependency file: /package.json

Path to vulnerable library: /node_modules/protobufjs/package.json

Dependency Hierarchy:

  • temporalio-0.21.1.tgz (Root Library)
    • client-0.21.0.tgz
      • ❌ protobufjs-6.11.2.tgz (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

The package protobufjs before 6.11.3 are vulnerable to Prototype Pollution which can allow an attacker to add/modify properties of the Object.prototype. This vulnerability can occur in multiple ways: 1. by providing untrusted user input to util.setProperty or to ReflectionObject.setParsedOption functions 2. by parsing/loading .proto files

Publish Date: 2022-05-27

URL: CVE-2022-25878

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: High
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25878

Release Date: 2022-05-27

Fix Resolution (protobufjs): 6.11.3

Direct dependency fix Resolution (temporalio): 0.22.0

⛑️ Automatic Remediation is available for this issue

⛑️ Automatic Remediation is available for this issue.

Lazy connectivity for Temporal client and healthCheck

Users should be able to create a Temporal Client for a temporarily unavailable Temporal server.

SDKs should have the main client or one of the clients that:

  1. Don't have an eager healthCheck and getSystemInfo calls in the constructor.
  2. getSystemCapabilities call should be performed on the first client call in a lazy manner.
  3. healthCheck endpoint should be exposed on the Client that will allow users to perform a health check for the corresponded gRPC service. It will also allow to initialize a connection in an explicit eager manner and perform initialization activities (system capabilities negotiation right now).
  4. There may be a .connect() or .dial call that establishes the connection and fetches system capabilities and which will allow to provide the same functionality/guarantees as an eager client provides.

SDKs should stop retrying on "Internal" server error

There was some work done for Internal and Unavailable errors differentiation on the server. Previously server returned only Internal and SDKs always retried it. Also SDKs always retry Unavailable but it wasn't returned by server until few month ago. Now, server returns both codes and uses Internal for non-retryable (something really bad happened on the server) and Unavailable for retryable.

To complete this work stream SDKs need to stop retry on Internal. In order to distinguish between the server versions that properly report Internal and Unavailable errors SDKs should use the capabilities reported in the getSystemInfo API call.

[Feature Request] Spec for expected client behavior when using handle or stub methods

temporalio/sdk-typescript#468 changed the behavior of WorkflowHandle methods to use run_id only when a handle is created with one (getHandle in TS).

Handles created with start should follow runs by default and use first_execution_run_id for safety (don't operate on runs that aren't part of the same execution chain).
Handles created with signal_with_start should not use run_id but cannot yet guarantee safety, a server change is required for that.

getHandle should accept a first_execution_run_id for safety.

NOTE: signal, query and describe methods are unsafe at the time of this writing and require a server + API change.

[Feature Request] Call ResetStickyTaskQueue on worker shutdown

When a worker shuts down, it should send a ResetStickyTaskQueue request to server so it can reset it and allow server to put the
next workflow task on the "normal" task queue.

Bonus points if this can also be done on forceful shutdown (SIGKILL, SIGTERM)

github.com/stretchr/testify-v1.7.0: 1 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - github.com/stretchr/testify-v1.7.0

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in Remediation Available
CVE-2022-28948 High 7.5 github.com/go-yaml/yaml-496545a6307b2a7d7a710fd516e5e16e8ab62dbc Transitive N/A ❌

Details

CVE-2022-28948

Vulnerable Library - github.com/go-yaml/yaml-496545a6307b2a7d7a710fd516e5e16e8ab62dbc

YAML support for the Go language.

Dependency Hierarchy:

  • github.com/stretchr/testify-v1.7.0 (Root Library)
    • ❌ github.com/go-yaml/yaml-496545a6307b2a7d7a710fd516e5e16e8ab62dbc (Vulnerable Library)

Found in base branch: main

Vulnerability Details

An issue in the Unmarshal function in Go-Yaml v3 causes the program to crash when attempting to deserialize invalid input.

Publish Date: 2022-05-19

URL: CVE-2022-28948

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-hp87-p4gw-j4gq

Release Date: 2022-05-19

Fix Resolution: 3.0.0

logback-classic-1.2.6.jar: 1 vulnerabilities (highest severity is: 6.6) - autoclosed

Vulnerable Library - logback-classic-1.2.6.jar

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-core/1.2.6/25be1abb32e870ff042e698a799b56587e0dca9a/logback-core-1.2.6.jar

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (logback-classic version) Remediation Available
CVE-2021-42550 Medium 6.6 detected in multiple dependencies Transitive 1.2.8 ✅

Details

CVE-2021-42550

Vulnerable Libraries - logback-core-1.2.6.jar, logback-classic-1.2.6.jar

logback-core-1.2.6.jar

logback-core module

Library home page: http://logback.qos.ch

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-core/1.2.6/25be1abb32e870ff042e698a799b56587e0dca9a/logback-core-1.2.6.jar

Dependency Hierarchy:

  • logback-classic-1.2.6.jar (Root Library)
    • ❌ logback-core-1.2.6.jar (Vulnerable Library)

logback-classic-1.2.6.jar

logback-classic module

Library home page: http://logback.qos.ch

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-classic/1.2.6/b09efa852337fa0dd9859614389eec58dc287116/logback-classic-1.2.6.jar

Dependency Hierarchy:

  • ❌ logback-classic-1.2.6.jar (Vulnerable Library)

Found in HEAD commit: 08aad3472da56f93f12cc85ec600e9824ae7f41b

Found in base branch: main

Vulnerability Details

In logback version 1.2.7 and prior versions, an attacker with the required privileges to edit configurations files could craft a malicious configuration allowing to execute arbitrary code loaded from LDAP servers.

Publish Date: 2021-12-16

URL: CVE-2021-42550

CVSS 3 Score Details (6.6)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: High
    • Privileges Required: High
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: High
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=VE-2021-42550

Release Date: 2021-12-16

Fix Resolution (ch.qos.logback:logback-core): 1.2.8

Direct dependency fix Resolution (ch.qos.logback:logback-classic): 1.2.8

⛑️ Automatic Remediation is available for this issue

⛑️ Automatic Remediation is available for this issue.

[Feature Request] Update workflow time when processing queries

Is your feature request related to a problem? Please describe.

Sometimes it's required to get the Date at the time a query is processed as opposed to the last processed workflow task's time.
For example this query will always return the same result:

setHandler(timerSettingsQuery, () => {
  const deadlineMs = timer.getDeadline();
  return { sleepIntervalMs: timer.sleepMs, timeLeftMs: deadlineMs - Date.now(), deadlineMs: deadlineMs };
});

Describe the solution you'd like

Update workflow time before processing queries (and possibly immediately reset back to workflow time)
Special care should be taken not to trigger any conditions (Workflow.await).

[Feature Request] SAGAs

SAGA: https://microservices.io/patterns/data/saga.html

Current state

We have SAGA helpers in:

  • Java (Basic—it's just cleanup code. Mostly users implement their own classes.)
  • PHP
  • coinbase-ruby

Discussion excerpts

  • One benefit of having Saga in Java SDK that people see it as a "feature" of the platform. We know that it is implementable from scratch in a few hours. But new users look for a "checkbox" to check.
  • It is one of the core use cases we want to support natively
  • My only argument that we should actually design Sagas and improve this class functionally. We need to make some better wrapper around this whole Subtransactions Implemented As Child Workflow Waiting For Signal (which is more of two-factor-commit than a saga). We don’t even have it written right now as our advice how to implement SAGAs. We need a better and safer abstraction.
  • It requires PM/Design work. So I would say SAGA looks like a stream of work to me.
  • It needs a careful design aligned with our best practices that we usually recommend to people. Decomposition into typical scenarios, understanding what kind of tooling will be covering them best in the most flexible way.
  • There are two pretty distinct scenarios for Saga: synchronous and asynchronous (which is not time bound). I think we should think hard how to make Sagas work efficiently in the synchronous scenario. This might require significant server side changes. But the payout can be pretty significant as can take on a lot of transactional use cases.

Related

cc @mnichols

[Feature Request] Unify retry logic across all SDKs

Retry logic in all SDKs:

[Feature Request] SDKs users should have a way to inject new certificates to a connection instance

Go

Use the built-in Go TLS config GetClientCertificate callback.
(Is this obvious enough to users? Do we have a sample and some docs?)

TypeScript

In order to do this in the TypeScript client we'd need to recreate the client since it uses grpc.credentials.createSsl which don't support dynamic certs.

EDIT: This can be done via entire client replacement

Rust Core (used for the TypeScript worker)

TLS certs are statically provided to Core, we'd need a way to inject new certs.

EDIT: This can be done via entire client replacement

Per-SDK Tickets

User metadata

Is your feature request related to a problem? Please describe.
There is a need to attach additional information to commands for troubleshooting and diagraming purposes. For example thread-id of a thread that invoked an activity or scheduled a timer.

Describe the solution you'd like
The proposal is to add a metadata field to the Command protobuf. Then SDKs would be able to add use case specific information to commands.

[Feature Request] Eager activity dispatch

Overview

SDKs need to support "eager activity dispatch" by default which is essentially just setting ScheduleActivityTaskCommandAttributes.request_eager_execution to true if there is "room". Then if supported on the server, the server will give the work right back to the worker requesting.

Unbalanced Worker Concern

This feature is purely for server benefit, and is actually possibly harmful to SDK and users. It can cause unbalancing of workers. For example, say you have 10 workers with 1000 activity slots each and just one workflow is running. If that workflow starts 300 activities, those are all gonna be on the one worker and the other 9 will idle. Today the server does not have a load balancing policy and therefore which worker work is given to is random, but even that may distribute load better than same-worker-as-workflow-by-default.

Features

  • Set eager execution boolean when scheduling activity if the worker is known to have activity slots available
  • Have worker option for "max eager activities" that represents the maximum number
    • Make sure this can be set to "off" (or use a separate config boolean)
    • Research - what is the default? Unset which means max activities of the worker?
    • Research - can we reliably determine when to add a eager-activity slot back to the pool? This means we have to know when an eager activity is no longer running. Are we expected to track activity completion? How does this work with retries? Are retries also sent back to the same worker? If we're in a many-minute backoff period for retry which means it is not "running", does that still take an eager-activity slot? How can the workflow side even tell that the activity side is in backoff? EDIT: The activity tasks come back in the WFT complete response, not the activty poll response, so you know then.
  • Should we have way in activity options to disallow eager dispatch?

Issues

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.