2 ms·

It's used there: https://github.com/microsoft/omi/blob/e4d72481fa2f805148c9c8f4d0183b3e2d7814a8/Unix/miapi/Options.c#L741 https://github.com/microsoft/omi/blob/

It's used there: https://github.com/microsoft/omi/blob/e4d72481fa2f805148c9c8f4d0183b3e2d7814a8/Unix/miapi/Options.c#L741 https://github.com/microsoft/omi/blob/e4d72481fa2f805148c9c8... Also note that neither EncryptData nor DecryptData have any way of passing a key in their API. So it's very unlikely that these implementations could be conditionally compiled in place of a real implementation (but they're the only definition of these functions in the repository anyway).

mulander 5y ago
It used to have actual Windows specific crypto code[1] which has been removed in the linked commit. I assume this has been ported from Windows and later never implemented the ripped out components. That said, I don't know the windows API so apart from confirming that they exist in Windows docs[2] I can't assess how valid their usage was. [1] - https://github.com/microsoft/omi/commit/edbe231042173018c52903e4170dd8b782fc4f8a#diff-6cee851bf2bc6078f7906b3b25069ec4fed59845438ef44d8df736529cc3a33cL50 https://github.com/microsoft/omi/commit/edbe231042173018c529... [2] - https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectdata https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-...
dspillett 5y ago
> neither EncryptData nor DecryptData have any way of passing a key There could have been other smells involved, like the key being held in some more global scope instead of being passed in via the call stack.