Skip to content

Replace google.protobuf.Struct with typed config in TransportDescriptor #13

@lanycrost

Description

@lanycrost

Problem statement

TransportDescriptor.config uses google.protobuf.Struct which allows arbitrary JSON-like data to be passed through the transport layer to connectors. Since connectors interpret this as configuration, a malicious or buggy upstream step could inject configuration directives (e.g., redirect endpoints, disable TLS, change credentials).

message TransportDescriptor {
  string name = 1;
  string kind = 2;
  string mode = 3;
  google.protobuf.Struct config = 4;  // Arbitrary, unvalidated
}

This appears in every packet via the transports repeated field in DataRequest, PublishRequest, and HubPushRequest.

Proposed change

Option A — Replace with strongly-typed config (preferred if transport types are known):

message TransportConfig {
  oneof config {
    GrpcTransportConfig grpc = 1;
    // future transports
  }
}

message TransportDescriptor {
  string name = 1;
  string kind = 2;
  string mode = 3;
  TransportConfig config = 4;
}

Option B — Keep Struct but document validation requirements:

// config carries transport-specific settings. Implementations MUST validate
// and sanitize config values against an allowlist of expected keys before
// applying them. Do not pass config values directly to connection or TLS
// setup without validation.
google.protobuf.Struct config = 4;

Option C — Hybrid: keep Struct for extensibility but add buf.validate constraints on struct depth/size.

Affected area

  • Proto definitions
  • Generated bindings (automatic)

Compatibility / migration

Option A is a breaking change — requires downstream migration in all consumers.
Option B is comment-only — no wire impact.
Option C is additive — validation constraints don't break existing valid payloads.

Additional context

Identified during security review. Attack scenario: malicious workflow step crafts TransportDescriptor.config containing {"redirect_endpoint": "http://attacker.com", "disable_tls": true}, and a naive connector implementation applies it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/protoProto definitions, message design, or wire compatibility work.good first issueSmall, well-scoped tasks for new contributors.help wantedLooking for community contributions.kind/featureNew functionality or enhancement request.priority/mediumNormal priority item.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions