Hi @jrobbins-LiveData -- just a heads-up that it may be a week or two before @itziakos will be available to respond to your question.

@jrobbins-LiveData It looks that the DO_NOT_USE prefix is a very early commit that was added when the ctypes implementation was first introduced. I suspect that it was probably because these keys where not needed at that time. Pywin32 does not have this limitation so we should fix that.

I am designating this report as a bug report. I will need to look into what is necessary to better support the application specific attributes. As far as I can tell it is not enough to just rename the attributes since Pywin32 has a different behaviour (you can probably use Pywin32 for development until we get this fixed).

Hi @itziakos. In working on a keyring Windows issue, we had some discussions about augmenting the interface to the Cred<xyz> functions. Here are some of the factors involved:

• A ctypes interface, which your project supports, is desirable, to avoid taking any binary dependencies.
• Access to the Attributes and AttributesCount fields would be helpful.
• And having a choice about the encoding used for CredentialBlob might be useful.

I wrote a new implementation using ctypes. While it does exactly what I need to address the keyring issue, I can't speak for its general usefulness.

That said, if it, or something like it, would best belong in this project, I'd be happy to work on that with you. I kept the interface upwards compatible (I think?), so hopefully it wouldn't break anyone already using it. That would need to be verifed, of course!

Anyway, please let me know what you think.

Thanks @jrobbins-LiveData

I had a quick look at the implementation in keyring. I will need to think how I can accomodate your usecase while keeping compatibility with the behaviour of pywin32. At the very least it should be easier to implement keyring's specific credential configuration on top of pywin32-ctypes (althought using a private module like _authenticate.py is still a small code smell).

On another note I noticed that in https://github.com/jaraco/keyring/blob/1f8bfb394d67e1f9a632916c444b60cbcebbb896/keyring/backends/Windows/api.py#L105 the code mutates the global windll.advapi32 object. I suggest that a local WinDDL instance is used to avoid mutating global state (which unfortunately a lot of libraries do).