| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
…essing threads for session and command protocol messages.
There was a problem hiding this comment.
One NIT
Sorry, something went wrong.
|
Paul Higinbotham (@PaulHigin) merge upstream/master tp pick up fix for the nulconditional tests |
Sorry, something went wrong.
|
This will probably fix Azure/azure-functions-powershell-worker#259 |
Sorry, something went wrong.
|
Will this issue be considered for GA? Otherwise, the Azure Function issue won't really be resolved until 7.1, which maybe a year later. |
Sorry, something went wrong.
|
I would love for it to make it into GA. |
Sorry, something went wrong.
|
Hello, just trying to understand, i see GA-approved for this PR, does it mean it will also solve for the Azure Functions issue ? (Azure/azure-functions-powershell-worker#259) |
Sorry, something went wrong.
|
Yes, this will address that issue, as soon as the Azure Functions team adopts PowerShell 7 in their runtime. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
This PR fixes the remoting key exchange hang in OutOfProc transport connections, when transferring SecureString objects.
Fixes issue: #259
PR Context
When a SecureString object is transferred over the remoting layer, a key exchange algorithm is lazily run so that the contents of the SecureString can be encrypted. This is not strictly necessary since both WinRM and SSH remoting channels already encrypt data on the wire by default. But the key exchange must remain for compatibility reasons.
The hang occurs when the target sends an encrypted SecureString object to the client for the first time. The client begins a key exchange handshake with the target so that it can handle the object. This works fine for WinRM based remote connections because the client processes session and command protocol messages on different threads. But the OutOfProc based transport implementations process client protocol messages on a single thread, and the lazily initiated key exchange results in a deadlock.
The fix is to update the OutOfProc transport manager base class to detect and process command and session client protocol messages on separate threads.
This is not a low risk change since it affects four remote implementations that are based on the OutOfProc transport: background jobs, PowerShellDirect, named pipes, SSH.
Repro Steps:
PR Checklist