Use SafeHandle for ppvOutAuthBuffer parameter of CredUIPromptForWindowsCredentials
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 2.5k
- Forks
- 124
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 9
Description
https://docs.microsoft.com/en-us/windows/win32/api/wincred/nf-wincred-creduipromptforwindowscredentialsw#parameters, ppvOutAuthBuffer:
When you have finished using the credential BLOB, clear it from memory by calling the SecureZeroMemory function, and free it by calling the CoTaskMemFree function.
Right now this parameter is being generated as void**. It feels like a step backwards to move away from my own declaration of CredUIPromptForWindowsCredentials which has this parameter as out CoTaskMemSafeHandle, a utility SafeHandle class that I already had.
Since the caller unequivocally owns the returned memory, it seems like a pitfall not to model this using SafeHandle. Maybe there should even be a SafeHandle class specific to these APIs which encapsulates the SecureZeroMemory call, too.
The https://docs.microsoft.com/en-us/windows/win32/api/wincred/nf-wincred-credunpackauthenticationbufferw function's pAuthBuffer parameter should be the same SafeHandle type that CredUIPromptForWindowsCredentials ends up using.
(Version used: 0.1.422-beta)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the generated signatures for CredUIPromptForWindowsCredentials and CredUnpackAuthenticationBuffer, focusing on ppvOutAuthBuffer and pAuthBuffer. No source file or test is named; done means both parameters use a suitable SafeHandle representation that owns the returned memory and follows the documented cleanup requirements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- devtools, operating-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100