Skip to content

Conversation

@josephnoir
Copy link
Collaborator

Motivation

When passing a PEM file with multiple certificates as trust roots, only the first one is loaded.

Modifications

Instead of creating a NIOSSLCertificate directly, use a function that loads multiple certificates from a PEM file. Add a test case that creates a certificate chain in a temporary directory to verify the expected behavior.

Result

Multiple certificates can be loaded from a single PEM file.

Motivation:

When passing a PEM file with multiple certificates as trust roots only,
the first one would be loaded. This is unintuitive.

Modifications:

Instead of creating a NIOSSLCertificate directly, use a function that
loads multiple certificates from a PEM file. Add a test case that
creates a certificate chain in a temporary directory to test the
expected behavior.

Result:

Multiple certificates can be loaded from a single file.
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Jul 9, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

@glbrntt glbrntt added the 🔨 semver/patch No public API change. label Jul 9, 2025
Comment on lines 149 to 151
try NIOSSLCertificate(
bytes: bytes,
format: NIOSSLSerializationFormats(serializationFormat)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably use fromPEMBytes here as well

file: path,
format: NIOSSLSerializationFormats(serializationFormat)
)
switch NIOSSLSerializationFormats(serializationFormat) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need the indirection here? Can we just switch over serializationFormat.wrapped?

Comment on lines 520 to 522
certificate: String,
key: String,
trustRoots: String,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add Path to the end of each of these?

Comment on lines 627 to 629
certificate: String,
key: String,
trustRoots: String
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, can you add Path to the end of each of these?

case server
}

/// Writing the files to disk returns a dictionary with these keys to access the file locations
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than a dictionary can we just have a struct with a property for each of these? We can avoid the ! when accessing them each time then.

}

/// The domains names for the leaf certificates
let serverName = "my.server"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This matters much less because it's in tests, but it's worth mentioning anyway. In structs, let is very rarely the right choice (vs var). In this instance it should really be a static so that it's not stored inline in the struct.

In general though, if this was passed in by the caller in the init then it should still be a var, because there's nothing stopping the caller from creating a new instance with a different value:

struct CertificateChain {
  let serverName: String
  init(serverName: String) { self.serverName = serverName }
}

let chain = CertificateChain(serverName: "foo")
chain.serverName = "bar" // not allowed; chain isn't mutable

var chain2 = chain
chain2.serverName = "bar" // Agh, not allowed!
chain2 = CertificateChain(serverName: "bar") // allowed, but annoying

If it were a var:

struct CertificateChain {
  var serverName: String
  init(serverName: String) { self.serverName = serverName }
}

let chain = CertificateChain(serverName: "foo")
chain.serverName = "bar" // not allowed; chain isn't mutable

var chain2 = chain
chain2.serverName = "bar" // allowed, great!

/// - Parameters:
/// - fileTag: A prefix added to all certificates files
/// - Returns: A dictionary storing mapping `CertificateChain.Files` to the respective file names
public func writeToTemp(fileTag: String) throws -> [Files: String] {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you put #function it will default to the calling function.

Suggested change
public func writeToTemp(fileTag: String) throws -> [Files: String] {
public func writeToTemp(fileTag: String = #function) throws -> [Files: String] {

let fm = FileManager.default
let directory = fm.temporaryDirectory

var fileNames = [Files: String]()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just use a nominal type here

Copy link
Collaborator

@glbrntt glbrntt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you!

@glbrntt glbrntt enabled auto-merge (squash) July 9, 2025 15:16
@glbrntt glbrntt merged commit 46a4128 into grpc:main Jul 9, 2025
29 checks passed
@josephnoir josephnoir deleted the cert-chains branch July 9, 2025 15:25
dongjoon-hyun added a commit to apache/spark-connect-swift that referenced this pull request Aug 26, 2025
### What changes were proposed in this pull request?

This PR aims to upgrade `gRPC Swift NIO Transport` to 2.1.0.

### Why are the changes needed?

To bring the latest improvements.
- https://github.com/grpc/grpc-swift-nio-transport/releases/tag/2.1.0
  - grpc/grpc-swift-nio-transport#122
  - grpc/grpc-swift-nio-transport#120
  - grpc/grpc-swift-nio-transport#115

### Does this PR introduce _any_ user-facing change?

No.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #218 from dongjoon-hyun/SPARK-53371.

Authored-by: Dongjoon Hyun <[email protected]>
Signed-off-by: Dongjoon Hyun <[email protected]>
dongjoon-hyun added a commit to apache/spark-connect-swift that referenced this pull request Aug 26, 2025
### What changes were proposed in this pull request?

This PR aims to upgrade `gRPC Swift NIO Transport` to 2.1.0.

### Why are the changes needed?

To bring the latest improvements.
- https://github.com/grpc/grpc-swift-nio-transport/releases/tag/2.1.0
  - grpc/grpc-swift-nio-transport#122
  - grpc/grpc-swift-nio-transport#120
  - grpc/grpc-swift-nio-transport#115

### Does this PR introduce _any_ user-facing change?

No.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #218 from dongjoon-hyun/SPARK-53371.

Authored-by: Dongjoon Hyun <[email protected]>
Signed-off-by: Dongjoon Hyun <[email protected]>
(cherry picked from commit a94af2e)
Signed-off-by: Dongjoon Hyun <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🔨 semver/patch No public API change.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants