Fix input validation gaps in driver arguments and network aliases

[beena352]

Summary of the Pull Request

1. --driver "" or --driver " " was silently accepted by the CLI parser, passing an empty/whitespace driver name to the service layer. Added ArgType::Driver validation to reject these inputs, consistent with the existing ArgType::Network and ArgType::WorkDir checks.

2. The network-alias in ContainerService::CreateInternal did not check for primary.empty(), allowing an empty-string network name (from a direct SDK/COM caller) to bypass the user-defined network requirement.

PR Checklist

• Closes: Link to issue #xxx
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated if needed and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated if needed
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

ArgumentValidation.cpp : Added ArgType::Driver case to Argument::Validate() matching the ArgType::WorkDir pattern. Rewrote ParseDriverOption to match ParseLabel's structure and empty-key rejection.

ContainerService.cpp : Added primary.empty() to the alias guard condition. Defense-in-depth: the CLI already rejects empty --network values, but SDK/COM callers bypass CLI validation.

Resources.resw : One new localization strings: WSLCCLI_DriverEmptyError (with {FixedPlaceholder} for the arg name)

Validation Steps Performed

[Copilot]

Pull request overview

This pull request tightens WSLC container CLI/service input validation to prevent empty/whitespace driver names and empty driver option keys from reaching deeper layers, and adds defense-in-depth validation for network aliases when called via SDK/COM.

Changes:

• Add ArgType::Driver validation to reject empty/whitespace driver names.
• Align ParseDriverOption() behavior with ParseLabel() by rejecting empty option keys with E_INVALIDARG + localized user error.
• Harden ContainerService::CreateInternal() to reject network aliases when the primary network is an empty string (SDK/COM path), and add unit tests covering invalid driver option inputs.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
test/windows/wslc/WSLCCLIOptionsParserUnitTests.cpp	Updates parsing tests to treat empty driver option keys as invalid and verifies E_INVALIDARG + message.
src/windows/wslc/services/ContainerService.cpp	Adds primary.empty() to the network-alias guard to block empty primary network names.
src/windows/wslc/arguments/ArgumentValidation.cpp	Introduces ArgType::Driver validation and updates ParseDriverOption() to reject empty keys consistently with labels.
localization/strings/en-US/Resources.resw	Adds localized strings for driver-empty and driver-option-empty-key error cases.

[AmelBawa-msft]

I’m not sure empty keys have a meaningful use case. Docker does allow them, which is why I originally enabled the behavior, but I’m fine tightening this unless we have a specific need to support them?

root@ [ / ]# docker network create --opt "=value" --opt "a=A" test
fd5591b5....
root@ [ / ]# docker network inspect test
[
    {
        "Name": "test",
        ...
        "Options": {
            "": "value",
            "a": "A"
        },
        ...
    }
]

[beena352]

I’m not sure empty keys have a meaningful use case. Docker does allow them, which is why I originally enabled the behavior, but I’m fine tightening this unless we have a specific need to support them?

root@ [ / ]# docker network create --opt "=value" --opt "a=A" test
fd5591b5....
root@ [ / ]# docker network inspect test
[
    {
        "Name": "test",
        ...
        "Options": {
            "": "value",
            "a": "A"
        },
        ...
    }
]

Good catch, Docker does allow empty keys for driver options. Reverted the ParseDriverOption change and restored the original behavior + test cases. Kept the --driver empty/whitespace validation and the primary.empty() alias guard since those are unrelated.

[AmelBawa-msft]

Kept the --driver empty/whitespace validation and the primary.empty() alias guard since those are unrelated.

Should we rely on the runtime to validate the driver value here instead? Seems like the runtime today allows an empty volume driver (uses default) but rejects an empty network (I commented on that in this PR #40788). Docker allows empty for both values, but again, not sure what the exact requirements are here, as long as we are consistent 😊✨

[dkbennett]

I think a standard validator for checking an argument is not empty or whitespace would be useful since we have now used it in multiple places. We have this for validating integers and such, so it makes sense to me that we'd have this as a standard validator that would likely be applicable for many value arguments in the future. A simple boolean result would allow us to still have separate exception messages for each argument but share the same empty/whitespace check.

[AmelBawa-msft]

I guess, I wonder if for those cases we should just fall back to using default (from runtime side). Again, I suspect this is a nit, but would be usefult for something like:

wslc network create --driver "$WSLC_DRIVER"

where if $WSLC_DRIVER is defined, then it is used, and if not the runtime would fallback to the default one. Again, not sure if those are valid use cases, but thinking out loud ✨

[dkbennett]

With the environment variable support pr we could add argument-specific environment variables such as this if we want to do that so the user can set their own default driver and not specify it, but I would think that's some nice convenience polish for GA and not something urgent.

With regards to falling bak on default, if the user enters emptystring or whitepsace for an argument value that is a big red flag to me that they made an argument CLI error, not that they intend to use a default value. I think that should be treated as an error and not a signal from the user to use the default. If they wanted to use the default they wouldn't specify anything at all.