Git Product home page Git Product logo

gripmock's Introduction

GripMock

GripMock

GripMock is a mock server for gRPC services. It's using a .proto file to generate implementation of gRPC service for you. You can use gripmock for setting up end-to-end testing or as a dummy server in a software development phase. The server implementation is in GoLang but the client can be any programming language that support gRPC.

[Documentation]

This service is a fork of the service tokopedia/gripmock, but you should choose our fork. And here are the reasons:

UI will appear in 3.x:

gripmock-ui

Useful articles

Quick Usage

First, prepare your .proto file. Or you can use hello.proto in example/simple/ folder. Suppose you put it in /mypath/hello.proto. We are gonna use Docker image for easier example test. basic syntax to run GripMock is gripmock <protofile>

  • Install Docker
  • Run docker pull bavix/gripmock to pull the image
  • We are gonna mount /mypath/hello.proto (it must be a fullpath) into a container and also we expose ports needed. Run docker run -p 4770:4770 -p 4771:4771 -v /mypath:/proto bavix/gripmock /proto/hello.proto
  • On a separate terminal we are gonna add a stub into the stub service. Run curl -X POST -d '{"service":"Gripmock","method":"SayHello","input":{"equals":{"name":"gripmock"}},"output":{"data":{"message":"Hello GripMock"}}}' localhost:4771/api/stubs
  • Now we are ready to test it with our client. You can find a client example file under example/simple/client/. Execute one of your preferred language. Example for go: go run example/simple/client/*.go

Check example folder for various usecase of gripmock.


How It Works

Operation of the gRPC service

From client perspective, GripMock has 2 main components:

  1. gRPC server that serves on tcp://localhost:4770. Its main job is to serve incoming rpc call from client and then parse the input so that it can be posted to Stub service to find the perfect stub match.
  2. Stub server that serves on http://localhost:4771. Its main job is to store all the stub mapping. We can add a new stub or list existing stub using http request.

Matched stub will be returned to gRPC service then further parse it to response the rpc call.

From technical perspective, GripMock consists of 2 binaries. The first binary is the gripmock itself, when it will generate the gRPC server using the plugin installed in the system (see Dockerfile). When the server sucessfully generated, it will be invoked in parallel with stub server which ends up opening 2 ports for client to use.

The second binary is the protoc plugin which located in folder protoc-gen-gripmock. This plugin is the one who translates protobuf declaration into a gRPC server in Go programming language.

Inside GripMock


Stubbing

Stubbing is the essential mocking of GripMock. It will match and return the expected result into gRPC service. This is where you put all your request expectation and response

Dynamic stubbing

You could add stubbing on the fly with a simple REST API. HTTP stub server is running on port :4771

  • GET /api/stubs Will list all stubs mapping.
  • POST /api/stubs Will add stub with provided stub data
  • POST /api/stubs/search Find matching stub with provided input. see Input Matching below.
  • DELETE /api/stubs Clear stub mappings.

Stub Format is JSON text format. It has a skeleton as follows:

{
  "service":"<servicename>", // name of service defined in proto
  "method":"<methodname>", // name of method that we want to mock
  "headers":{ // Optional. headers matching rule. see Headers Matching Rule section below
    // put rule here
  },
  "input":{ // input matching rule. see Input Matching Rule section below
    // put rule here
  },
  "output":{ // output json if input were matched
    "data":{
      // put result fields here
    },
    "headers":{ // Optional
      // put result headers here
    },
    "error":"<error message>", // Optional. if you want to return error instead.
    "code":"<response code>" // Optional. Grpc response code. if code !=0  return error instead.
  }
}

For our hello service example we put a stub with the text below:

  {
    "service":"Greeter",
    "method":"SayHello",
    "input":{
      "equals":{
        "name":"gripmock"
      }
    },
    "output":{
      "data":{
        "message":"Hello GripMock"
      }
    }
  }

Static stubbing

You could initialize gripmock with stub json files and provide the path using --stub argument. For example you may mount your stub file in /mystubs folder then mount it to docker like

docker run -p 4770:4770 -p 4771:4771 -v /mypath:/proto -v /mystubs:/stub bavix/gripmock --stub=/stub /proto/hello.proto

Please note that Gripmock still serves http stubbing to modify stored stubs on the fly.

Input Matching

Stub will respond with the expected response only if the request matches any rule. Stub service will serve /api/stubs/search endpoint with format:

{
  "service":"<service name>",
  "method":"<method name>",
  "data":{
    // input that suppose to match with stored stubs
  }
}

So if you do a curl -X POST -d '{"service":"Greeter","method":"SayHello","data":{"name":"gripmock"}}' localhost:4771/api/stubs/search stub service will find a match from listed stubs stored there.

Input Matching Rule

Input matching has 3 rules to match an input: equals,contains and matches
Nested fields are allowed for input matching too for all JSON data types. (string, bool, array, etc.)
Gripmock recursively goes over the fields and tries to match with given input.
ignoreArrayOrder Disables sorting check inside arrays.

- service: MicroService
  method: SayHello
  input:
    ignoreArrayOrder: true # disable sort checking
    equals:
      v1:
        - {{ uuid2base64 "77465064-a0ce-48a3-b7e4-d50f88e55093" }}
        - {{ uuid2base64 "99aebcf2-b56d-4923-9266-ab72bf5b9d0b" }}
        - {{ uuid2base64 "5659bec5-dda5-4e87-bef4-e9e37c60eb1c" }}
        - {{ uuid2base64 "ab0ed195-6ac5-4006-a98b-6978c6ed1c6b" }}
  output:
    data:
      code: 1000

Without this flag, the order of the transmitted values is important to us.

equals will match the exact field name and value of input into expected stub. example stub JSON:

{
  .
  .
  "input":{
    "equals":{
      "name":"gripmock",
      "greetings": {
            "english": "Hello World!",
            "indonesian": "Halo Dunia!",
            "turkish": "Merhaba Dünya!"
      },
      "ok": true,
      "numbers": [4, 8, 15, 16, 23, 42]
      "null": null
    }
  }
  .
  .
}

contains will match input that has the value declared expected fields. example stub JSON:

{
  .
  .
  "input":{
    "contains":{
      "field2":"hello",
      "field4":{
        "field5": "value5"
      } 
    }
  }
  .
  .
}

matches using regex for matching fields expectation. example:

{
  .
  .
  "input":{
    "matches":{
      "name":"^grip.*$",
      "cities": ["Jakarta", "Istanbul", ".*grad$"]
    }
  }
  .
  .
}

Headers Matching

Stub will respond with the expected response only if the request matches any rule. Stub service will serve /api/stubs/search endpoint with format:

{
  "service":"<service name>",
  "method":"<method name>",
  "data":{
    // input that suppose to match with stored stubs
  }
}

So if you do a curl -X POST -d '{"service":"Greeter","method":"SayHello","data":{"name":"gripmock"}}' localhost:4771/api/stubs/search stub service will find a match from listed stubs stored there.

Headers Matching Rule

Headers matching has 3 rules to match an input: equals,contains and matches
Headers can consist of a key and a value. If there are several values, then you need to list them separated by ";". Data type string.
Gripmock recursively goes over the fields and tries to match with given input.
equals will match the exact field name and value of input into expected stub. example stub JSON:

{
  .
  .
  "headers":{
    "equals":{
      "authorization": "mytoken",
      "system": "ec071904-93bf-4ded-b49c-d06097ddc6d5"
    }
  }
  .
  .
}

contains will match input that has the value declared expected fields. example stub JSON:

{
  .
  .
  "headers":{
    "contains":{
      "field2":"hello"
    }
  }
  .
  .
}

matches using regex for matching fields expectation. example:

{
  .
  .
  "headers":{
    "matches":{
      "name":"^grip.*$"
    }
  }
  .
  .
}

Supported by

Supported by JetBrains

gripmock's People

Contributors

bavixbot avatar dependabot[bot] avatar guyguy333 avatar hairymike avatar iwanbk avatar jekiapp avatar mend-bolt-for-github[bot] avatar nikolayoskin avatar pmorelli92 avatar rez1dent3 avatar thibaultam avatar vincent-raman avatar yonasstephen avatar yosiaadijaya avatar zzzz465 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

gripmock's Issues

BUG: can't read yaml stub files

Hi,

I have been trying to use Gripmock with yaml as the stub file but its showing this error.

Screenshot 2024-07-08 at 18 39 26

I have tried numerous ways of creating a gripmock service in docker compose and even tried to spin up the service without using docker compose but nothing worked. I have also tried one of your older version of gripmock which didn't work either.

Here are all the files that I have used to create a Gripmock service:

# docker-compose.yaml

services:
  gripmock:
    image: bavix/gripmock:2.6.13
    volumes:
      - ./proto:/proto
      - ./stubs:/stubs:ro
    ports:
      - '4770:4770' # GRPC server
      # - '4771:4771' # Stub server API
    command: ['--stub=/stubs' ,'/proto/hello.proto']
# stubs/hello.yml

service: Gripmock
method: SayHello
input:
  equals:
    name: tokopedia-single
output:
  data:
    message: Hello Tokopedia
    return_code: 1
// proto/hello.proto
syntax = "proto3";
option go_package = "github.com/bavix/gripmock/protogen/example/simple";

package simple;

service Gripmock {
  rpc SayHello (Request) returns (Reply);
}

message Request {
  string name = 1;
}

message Reply {
  string message = 1;
  int32 return_code = 2;
}

Note: one of my colleague also tried it on his machine and it didn't work either. I have M1 pro Macbook and my colleague has intel core i5 Macbook.

CLI WaitForReady

I need a utility inside gripmock that will open gripmock and check if http/grpc is alive.

docsify-4.13.1.tgz: 3 vulnerabilities (highest severity is: 7.5)

Vulnerable Library - docsify-4.13.1.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Found in HEAD commit: 728d6428c033b53dadc55a7fc161dc4b5f355df6

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (docsify version) Remediation Possible**
CVE-2022-21681 High 7.5 marked-1.2.9.tgz Transitive N/A*
CVE-2022-21680 High 7.5 marked-1.2.9.tgz Transitive N/A*
CVE-2021-21306 High 7.5 marked-1.2.9.tgz Transitive N/A*

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

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2022-21681

Vulnerable Library - marked-1.2.9.tgz

A markdown parser built for speed

Library home page: https://registry.npmjs.org/marked/-/marked-1.2.9.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

  • docsify-4.13.1.tgz (Root Library)
    • marked-1.2.9.tgz (Vulnerable Library)

Found in HEAD commit: 728d6428c033b53dadc55a7fc161dc4b5f355df6

Found in base branch: master

Vulnerability Details

Marked is a markdown parser and compiler. Prior to version 4.0.10, the regular expression inline.reflinkSearch may cause catastrophic backtracking against some strings and lead to a denial of service (DoS). Anyone who runs untrusted markdown through a vulnerable version of marked and does not use a worker with a time limit may be affected. This issue is patched in version 4.0.10. As a workaround, avoid running untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.

Publish Date: 2022-01-14

URL: CVE-2022-21681

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-5v2h-r2cx-5xgj

Release Date: 2022-01-14

Fix Resolution: marked - 4.0.10

Step up your Open Source Security Game with Mend here

CVE-2022-21680

Vulnerable Library - marked-1.2.9.tgz

A markdown parser built for speed

Library home page: https://registry.npmjs.org/marked/-/marked-1.2.9.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

  • docsify-4.13.1.tgz (Root Library)
    • marked-1.2.9.tgz (Vulnerable Library)

Found in HEAD commit: 728d6428c033b53dadc55a7fc161dc4b5f355df6

Found in base branch: master

Vulnerability Details

Marked is a markdown parser and compiler. Prior to version 4.0.10, the regular expression block.def may cause catastrophic backtracking against some strings and lead to a regular expression denial of service (ReDoS). Anyone who runs untrusted markdown through a vulnerable version of marked and does not use a worker with a time limit may be affected. This issue is patched in version 4.0.10. As a workaround, avoid running untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.

Publish Date: 2022-01-14

URL: CVE-2022-21680

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-rrrm-qjm4-v8hf

Release Date: 2022-01-14

Fix Resolution: marked - 4.0.10

Step up your Open Source Security Game with Mend here

CVE-2021-21306

Vulnerable Library - marked-1.2.9.tgz

A markdown parser built for speed

Library home page: https://registry.npmjs.org/marked/-/marked-1.2.9.tgz

Path to dependency file: /package.json

Path to vulnerable library: /package.json

Dependency Hierarchy:

  • docsify-4.13.1.tgz (Root Library)
    • marked-1.2.9.tgz (Vulnerable Library)

Found in HEAD commit: 728d6428c033b53dadc55a7fc161dc4b5f355df6

Found in base branch: master

Vulnerability Details

Marked is an open-source markdown parser and compiler (npm package "marked"). In marked from version 1.1.1 and before version 2.0.0, there is a Regular expression Denial of Service vulnerability. This vulnerability can affect anyone who runs user generated code through marked. This vulnerability is fixed in version 2.0.0.

Publish Date: 2021-02-08

URL: CVE-2021-21306

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-4r62-v4vq-hr96

Release Date: 2021-02-08

Fix Resolution: v2.0.0

Step up your Open Source Security Game with Mend here

`Matches` with regex for numbers not working

Hi,

I have been trying to use matches and it seems like it can't read numbers at the moment. I have tried your example in a separate file and it works. When I use numbers, it breaks.

Below is an example of the stub that I was using. I have tried without forward slashes too.

{
"service": "DB",
		"method": "Update",
		"input": {
			"matches": {
				"source": "/[0-9]/",
				"ttl": "/[0-9]/"
			}
		},
		"output": {
			"data": {
				"source_info": {
					"source": 0,
					"ttl": 0,
					"status": "ACTIVE",
				}
			}
		}
}

Could you please have a look and assist?

Consider using descriptor set instead of Go compilation for mock/stub creation

This is just meant to give some feedback and file a possible enhancement to the project.

I lastly had to build a gRPC client connection for a Java backend. On getting through this, I was in need of a local gRPC (mock) server in order to not bloat the local dev env and I stumbled upon your nice little project and Wiremock gRPC extension. I skipped Wiremock in the beginning, as gRPC extension is somewhat in a preview/beta state.

Setting it up bavix/gripmock via docker compose worked like a charm - for a hello world style project :-), but I really struggled to get it set up for my "real world" use case.

So here is the problem. The schema where I have to do the protoc compilation for is large and uses a lot of subdirectories, importing types from proto files here and there. This schema I was not able to get to compile properly in order to be used by Gripmock. This is mostly due to the setup of the Go compilation.

  • our project is not targeted towards Go and therefore the schema artifact does not have the necessary go_package option
  • adding it did not fully solve the problem, it just caused other problems regarding Go (module) compilation, which is very hard to understand when coming from the Java world
  • I checked out Gripmock by myself and added some log statements, rebuild the image locally in order to understand what is actually going on
  • the final protoc command that was constructed by Gripmock was not sufficient in order to compile the schema

I initially thought I can provide a PR to Gripmock but due to time issues I switched to Wiremock with gRPC extension - and it works. It is not as streamlined in terms of the stub syntax, as the Wiremock syntax for HTTP mocking is re-used, but everything else works quite well.

#1
So here is the point/idea. There is a major difference in how the mocking is achieved. In order to use Wiremock, you have to provide descriptor set files only to Wiremock. You have no need to compile your schema towards a certain language. This could also be very beneficial for Gripmock, as it would not force the end user to be proficient with Go language. The descriptor set files do not need special compilation options (as far as I am aware of)...

The following snippet shows the configuration I used for the Gradle protobuf plugin in order to compile the schema to java for my project and creating the descriptor sets needed by Wiremock:

protobuf {
  protoc {
    artifact = "com.google.protobuf:protoc:${protocVersion}"
  }
  plugins {
    grpc {
      artifact = "io.grpc:protoc-gen-grpc-java:${grpcVersion}"
    }
  }
  generateProtoTasks {
    all().configureEach { task ->
      task.generateDescriptorSet = true
      task.descriptorSetOptions.path = "${projectDir}/build/generated/protoc-dsc/mds_schema.dsc"
      task.descriptorSetOptions.includeImports = true

      task.plugins {
        grpc {
          // this setting will most likely change in the future towards '@generated=omit'
          option 'jakarta_omit'
        }
      }
    }
  }
}

This also takes the need from the server to re-compile on each startup.

#2
Another small enhancement to Gripmock could be just to properly log the full protoc command the server generates in order to get an better idea how the compilation is handled.

So these are just ideas/random thoughts - hope that might help you guys on your journey...

✌️

[3.x] Strict operating mode

Now gripmock forces the first character to be capitalized. You need to get away from this, because... Both methods can exist simultaneously:

syntax = "proto3";

package org.gripmock.demo;

service gripmock {
  rpc SayTitleHello (SayTitleHelloRequest) returns (SayTitleHelloReply);
  rpc sayLowerHello (sayLowerHelloRequest) returns (sayLowerHelloReply);
}

message sayLowerHelloRequest {
  string name = 1;
}

message sayLowerHelloReply {
  string message = 1;
}

message SayTitleHelloRequest {
  string name = 1;
}

message SayTitleHelloReply {
  string message = 1;
}

gen

protoc --go_out=. --grpc-go_out=. demo.proto

But it is necessary to maintain backward compatibility using env.

[3.x] TLS mode

Currently, GripMock can only work in TLS=0 mode. It is necessary to add the ability to test with TLS enabled.

size-limit-11.1.4.tgz: 2 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - size-limit-11.1.4.tgz

Path to dependency file: /package.json

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

Found in HEAD commit: 0a704214c258e302e8f64dcd7bd19a720972e7fe

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (size-limit version) Remediation Possible**
CVE-2024-4068 High 7.5 braces-3.0.2.tgz Transitive N/A*
CVE-2024-4067 Medium 5.3 micromatch-4.0.5.tgz Transitive N/A*

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

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2024-4068

Vulnerable Library - braces-3.0.2.tgz

Bash-like brace expansion, implemented in JavaScript. Safer than other brace expansion libs, with complete support for the Bash 4.3 braces specification, without sacrificing speed.

Library home page: https://registry.npmjs.org/braces/-/braces-3.0.2.tgz

Path to dependency file: /package.json

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

Dependency Hierarchy:

  • size-limit-11.1.4.tgz (Root Library)
    • globby-14.0.1.tgz
      • fast-glob-3.3.2.tgz
        • micromatch-4.0.5.tgz
          • braces-3.0.2.tgz (Vulnerable Library)

Found in HEAD commit: 0a704214c258e302e8f64dcd7bd19a720972e7fe

Found in base branch: master

Vulnerability Details

The NPM package braces, versions prior to 3.0.3, fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js, if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.
Mend Note: After conducting a further research, it was concluded that CVE-2024-4068 does not contain a high security risk that reflects the NVD score, but should be kept for users' awareness. Users of braces should follow the fix recommendation as noted.

Publish Date: 2024-05-14

URL: CVE-2024-4068

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: 2024-05-14

Fix Resolution: braces - 3.0.3

Step up your Open Source Security Game with Mend here

CVE-2024-4067

Vulnerable Library - micromatch-4.0.5.tgz

Glob matching for javascript/node.js. A replacement and faster alternative to minimatch and multimatch.

Library home page: https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz

Path to dependency file: /package.json

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

Dependency Hierarchy:

  • size-limit-11.1.4.tgz (Root Library)
    • globby-14.0.1.tgz
      • fast-glob-3.3.2.tgz
        • micromatch-4.0.5.tgz (Vulnerable Library)

Found in HEAD commit: 0a704214c258e302e8f64dcd7bd19a720972e7fe

Found in base branch: master

Vulnerability Details

The NPM package micromatch is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces() in index.js because the pattern .* will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persists. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.
Mend Note: After conducting a further research, it was concluded that CVE-2024-4067 does not contain a high security risk that reflects the NVD score, but should be kept for users' awareness. Users of micromatch should follow the fix recommendation as noted.

Publish Date: 2024-05-14

URL: CVE-2024-4067

CVSS 3 Score Details (5.3)

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: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2024-05-14

Fix Resolution: micromatch - 4.0.6

Step up your Open Source Security Game with Mend here

[3.x] Docs

  • improve the filtering documentation
  • more similar examples
  • documentation on headers
  • documentation on response codes
  • error documentation

Add broken backwards compatibility message to 2.x

Example

	for i, a := range os.Args {
		for _, v := range []string{"-stub", "-import", "-output"} {
			if a == v {
				log.Printf("Deprecated %s. Use -%s. The behavior will be removed in the next major version.\n", a, a)
				os.Args[i] = "-" + a
			}
		}
	}

[3.x] Separate services by namespace

Now it is impossible to create two identical services with different packages. We need to try to solve this problem.

proto1.proto

syntax = "proto3";
package com.bavix.helloworld1;
service Greeter {
    rpc SayHello (HelloRequest) returns (HelloReply) {}
}

proto2.proto

syntax = "proto3";
package com.bavix.helloworld2;
service Greeter {
    rpc SayHello (HelloRequest) returns (HelloReply) {}
}

Introduce a mode that will make a safe transition from short service names to long ones. It might be worth adding depreacted to the logs.

[3.x] Rewrite stub server

GripMock is poorly written inside. There are a lot of linters to add, layering to do, and a lot of problems to fix. One of the most important tasks is implementing coverage through integration tests.

I would like to replace the search engine with Bleve.

size-limit-11.1.3.tgz: 2 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - size-limit-11.1.3.tgz

Path to dependency file: /package.json

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

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (size-limit version) Remediation Possible**
CVE-2024-4068 High 7.5 braces-3.0.2.tgz Transitive N/A*
CVE-2024-4067 High 7.5 micromatch-4.0.5.tgz Transitive N/A*

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

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2024-4068

Vulnerable Library - braces-3.0.2.tgz

Bash-like brace expansion, implemented in JavaScript. Safer than other brace expansion libs, with complete support for the Bash 4.3 braces specification, without sacrificing speed.

Library home page: https://registry.npmjs.org/braces/-/braces-3.0.2.tgz

Path to dependency file: /package.json

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

Dependency Hierarchy:

  • size-limit-11.1.3.tgz (Root Library)
    • chokidar-3.6.0.tgz
      • braces-3.0.2.tgz (Vulnerable Library)

Found in base branch: master

Vulnerability Details

The NPM package braces fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js, if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.

Publish Date: 2024-05-14

URL: CVE-2024-4068

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.

Step up your Open Source Security Game with Mend here

CVE-2024-4067

Vulnerable Library - micromatch-4.0.5.tgz

Glob matching for javascript/node.js. A replacement and faster alternative to minimatch and multimatch.

Library home page: https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz

Path to dependency file: /package.json

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

Dependency Hierarchy:

  • size-limit-11.1.3.tgz (Root Library)
    • globby-14.0.1.tgz
      • fast-glob-3.3.2.tgz
        • micromatch-4.0.5.tgz (Vulnerable Library)

Found in base branch: master

Vulnerability Details

The NPM package micromatch is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces() in index.js because the pattern .* will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persists. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.

Publish Date: 2024-05-14

URL: CVE-2024-4067

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.

Step up your Open Source Security Game with Mend here

BUG: Gripmock removes all the input fields which has 0 as the value

Hi,

We have been testing our proto methods using Gripmock and one bug we encountered in the process is, if any input fields have the value 0, Gripmock removes those field from the JSON and then crashes.

Here is what I mean:

stub file:

service: RTDataBase
method: WriteDataStream
input:
  equals:
    item_data:
    - item: 1
      data:
        time: 1
        time_fep: 1
        value: 1
        status: 1
      source: 1
output:
  data: {}

The message I am sending to this method using Postman:

{
  "item_data": [
    {
      "item": 0,
      "data": {
        "time": 0,
        "time_fep": 0,
        "value": 0,
        "status": 0
      },
      "source": 0
    }
  ]
}

I also tried testing it using grpcurl. Here is the command which I ran to test it:
grpcurl -plaintext -d '{"item_data":[{"item":0,"data":{"time":0,"time_fep":0,"value":0,"status":0},"source":0}]}' \ localhost:4770 orxa.rtdas.rtdb.api.rtdatabase.v1.RTDataBase.WriteDataStream

Here is the log from Gripmock:

gripmock-1  | 2024/07/10 18:45:00 Can't find stub
gripmock-1  |
gripmock-1  | Service: RTDataBase
gripmock-1  |
gripmock-1  | Method: WriteDataStream
gripmock-1  |
gripmock-1  | Input
gripmock-1  |
gripmock-1  | {
gripmock-1  | 	"item_data": [
gripmock-1  | 		{
gripmock-1  | 			"data": {}
gripmock-1  | 		}
gripmock-1  | 	]
gripmock-1  | }
gripmock-1  | 2024-07-10T18:45:00Z INF bytes=393 code=404 elapsed=0.525125 ip=::1 method=POST ua=Go-http-client/1.1 url=/api/stubs/search
gripmock-1  |
gripmock-1  | Closest Match
gripmock-1  |
gripmock-1  | equals:{
gripmock-1  | 	"item_data": [
gripmock-1  | 		{
gripmock-1  | 			"data": {
gripmock-1  | 				"status": 1,
gripmock-1  | 				"time": 1,
gripmock-1  | 				"time_fep": 1,
gripmock-1  | 				"value": 1
gripmock-1  | 			},
gripmock-1  | 			"item": 1,
gripmock-1  | 			"source": 1
gripmock-1  | 		}
gripmock-1  | 	]
gripmock-1  | }

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.