Repository navigation
Bug: taskmaster-csproj-publishurl-leaks-user-profile-path-and-org-name #628
Description
Activity
The promotion template does not map the final sections of the potential-bug record into
the issue body. They are reproduced here so the issue is the complete record.Suspected Cause / Notes
TaskMaster/TaskMaster.csprojline 37,<PublishUrl>.- ClickOnce publish settings written by the IDE into the shared project file rather than a
per-user file. - Related: open issue Repository-wide host-identifier leakage: absolute user-profile paths, account and host names in tracked files #602 (host-identifier leakage), which currently covers runtime exception
messages; this extends the same concern to committed build configuration.
Proposed Fix / Validation Ideas
- Remove
<PublishUrl>from the tracked project file, or replace it with a non-identifying
placeholder or relative value. - Relocate any genuinely wanted local value to a gitignored per-user file.
- Audit sibling project files for equivalent per-developer ClickOnce paths (
<PublishUrl>,
<InstallUrl>, and similar). - Make an explicit, recorded maintainer decision on whether to rewrite history or accept the
historical occurrences. - Add a repository guard that fails when a tracked file contains an absolute path under
C:\Users\. - Unit coverage areas: not applicable; this is build configuration.
- Integration scenario to retest: solution build and, if ClickOnce publish is still used, a
publish from a clean clone. - Manual verification notes: confirm the build succeeds after removal, since
<PublishUrl>is
not required for a normal compile.
Next Step
- Promote to GitHub issue (bug-report template)
- Move to active fix folder / branch
- added a commit that references this issue
on Sep 2, 2026
Summary
TaskMaster/TaskMaster.csprojline 37 contains a<PublishUrl>element whose value is an absolutepath under a specific developer's Windows user profile, including that developer's account name and
their employer's organization name as part of a OneDrive commercial folder name. Both are committed
to version control and are visible to anyone who can read the repository, including in the public
GitHub UI, in every clone, and in the full history.
This is the same class of host-identifier leakage tracked by open issue #602, which to date has been
scoped to runtime exception messages. This occurrence is different in kind and worse in durability:
an exception message exists only in a log on one machine, whereas a committed project file
republishes the identifiers to every reader of the repository indefinitely, and rewriting them out
of history is disruptive in a way that fixing a log message is not.
The element is ClickOnce publish configuration. It is a per-developer local convenience setting that
has no business being shared: a second developer publishing from a different machine would be
publishing into a path that does not exist for them, so the committed value is not merely a leak but
is also wrong for everyone except its author.
Found during the issue #614 redaction sweep, which searched every file that change touched for the
executing account name and for
@-bearing strings. The sweep is scoped to changed hunks; this lineis not in any hunk of #614 (that file's only #614 hunk is at line 416), so the finding is reported
rather than fixed there. It is filed separately rather than absorbed because #614 is a
path-representation defect chain and this is committed configuration, and because the correct fix
touches build configuration and possibly history rather than the filing boundary.
Recommended remediation, in order: remove the element from the tracked file, or replace it with a
non-identifying relative or placeholder value; move the real value into a gitignored local settings
file such as a
.userfile if the developer still wants it; then decide deliberately whether thehistorical occurrences warrant a history rewrite or are accepted as already-published. That last
decision is a maintainer call, not an automated one, and should be recorded either way.
Worth checking as part of the same fix whether any sibling project file carries an equivalent
per-developer
<PublishUrl>,<InstallUrl>, or similar ClickOnce path.Environment
Bug: efc-store-root-selection-leaks-full-outlook-path-into-filing-boundary #614 touches at an unrelated line.
TaskMaster/TaskMaster.csprojat line 37 on the current branch and onmain.Steps to Reproduce
TaskMaster/TaskMaster.csprojand read line 37.<PublishUrl>value contains a real Windows user-profile path including an accountname and an organization name.
git log -p -- TaskMaster/TaskMaster.csprojand observe the value is present historically,not only at
HEAD.Expected Behavior
No tracked file contains a real user account name, user-profile path, host name, or organization
name. Per-developer publish settings live in a gitignored local file, not in the shared project.
Actual Behavior
The identifiers are committed in a tracked project file and present in history.
Logs / Screenshots
TaskMaster/TaskMaster.csproj:37.Impact / Severity
No functional impact and no credential exposure. The disclosure is of a developer account name and
an employer name, is already published to every reader of the repository, and is durable in history.
Source
From: docs/features/potential/2026-08-26-taskmaster-csproj-publishurl-leaks-user-profile-path-and-org-name.md