PowerShell / PowerShell/Win32-OpenSSH

Tracking downstream Win32-OpenSSH changes with upstream release tags/branches

Open
#1,929 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
8.3k
Forks
819
PR merge metrics
No merged PRs in 30d

Description

I am working on an OpenSSH distribution based on Win32-OpenSSH on Windows, and "vanilla" OpenSSH on non-Windows. The problem that I have right now is that I cannot track downstream changes to their original upstream release tags or branches. Right now, there are three repositories:

Win32-OpenSSH, which doesn't contain the openssh-portable source code, but is used for release tags and issue tracking. While the release tags contain source code along side binaries, it does not provide sufficient information to track the changes in the git history.

PowerShell/openssh-portable contains the Win32-OpenSSH downstream changes, but it doesn't have the same tags and branches as the upstream openssh-portable repository.

All changes in the downstream repository appear to be made in a "latestw_all" branch, with no clear history to track how the Win32-OpenSSH changes are rebased on top of which upstream openssh-portable release tag.

Can someone explain to me how a Win32-OpenSSH release like v8.9.1.0 was made such that I could make a diff of the downstream sources against their corresponding upstream sources, and clearly see how the source code was modified? Ideally, I would like to separate the Win32 patches to make them easier to reapply on top of newer versions of OpenSSH, like 9.0 that just came out.

My goal is to have my own cross-platform OpenSSH distribution that correctly incorporates the Win32-OpenSSH changes. I know it is not a goal of Win32-OpenSSH to build and support non-Windows, but just working toward better tracking of downstream changes could help making them much easier to reapply on top of future upstream releases, and reduce the overall maintenance effort required to keep it up to date.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the Win32-OpenSSH, PowerShell/openssh-portable, and upstream openssh-portable repositories around the v8.9.1.0 release tag and the latestw_all branch. Done means documenting which upstream tag or branch the release derives from and how to produce a clear downstream-versus-upstream diff.

Written by the indexing model from the issue text.

Assessment

Tech stack
git
Domain
developer-experience, release
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.