microsoft / microsoft/winappCli
cert generate --publisher accepts malformed DNs and silently generates a mismatched certificate
- Dominant language
- C#
- Stars
- 1.3k
- Forks
- 80
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 51
Description
`cert generate --publisher` accepts malformed values and silently produces a broken certificate.
Every input below **exits 0** and writes a `.pfx`. Verified against a `0.6.1-pr` build; subject read back with `winapp cert info`.
| `--publisher` input | exit | resulting subject |
|---|---|---|
| `CN=` | 0 | `CN=""` |
| `=Contoso` | 0 | `CN="=Contoso"` |
| `CN=A,,O=B` | 0 | `CN="CN=A,,O=B"` |
| `Contoso, Inc` | 0 | `CN="Contoso, Inc"` |
| `CN=Contoso\Bar` | 0 | `CN=Contoso\Bar` |
Valid input behaves correctly: `CN=Contoso Inc, O=Contoso, C=US` round-trips as a proper three-component DN.
Two distinct problems:
1. **`CN=` yields an empty common name.** A certificate with `CN=""` can never match any manifest `Identity/@Publisher`.
2. **Unparseable DNs are silently re-wrapped as a literal CN** rather than rejected. `CN=A,,O=B` becomes a single CN whose *value is the string* `CN=A,,O=B`. The user asked for a two-component DN and got something entirely different, with no diagnostic.
`CN=Contoso\Bar` is also worth a look: the packaging schema type `ST_Publisher_2010_v2` has no escape sequences, so a publisher containing a backslash cannot match a manifest.
**Why this matters:** the publisher exists solely so the certificate matches `Identity/@Publisher`. When it silently doesn't, the failure surfaces much later as an install failure with no obvious link back to cert generation.
**Suggested fix:** validate `--publisher` and exit non-zero with a message naming the offending component. If a value cannot be parsed as a DN, say so rather than falling back to treating it as a bare name.
**Context:** found while wiring the VS Code extension's `winapp.certGenerate` publisher prompt. We deliberately pass the user's string through unmodified so the CLI owns validation — which is the right layering, but currently means nothing validates it. Related: #839 (same silent-fallback shape on the `--manifest` path).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the `cert generate --publisher` command and reproduce the listed malformed inputs, comparing their exit codes and generated subjects with the valid DN example. Trace the publisher parsing and fallback behavior; done means malformed DNs are rejected with a diagnostic naming the offending component, while valid DNs still round-trip correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 65/100