question re CREDENTIAL __DO_NOT_USE_ fields in _authentication.py

[jrobbins-LiveData]

I was wondering why _fields_ AttributeCount and Attribute are prefixed with __DO_NOT_USE_?

I have a potential use for setting an attribute on a Credentials Manager entry (to record the encoding used for a password), and was wondering if this __DO_NOT_USE_ had an back story about what kinds of issues I might be facing in using this feature?

pywin32-ctypes/win32ctypes/core/ctypes/_authentication.py

Line 26 in 2db9303

class CREDENTIAL(Structure):

pywin32-ctypes/win32ctypes/core/ctypes/_authentication.py

Line 36 in 28364ce

("_DO_NOT_USE_AttributeCount", DWORD),

pywin32-ctypes/win32ctypes/core/ctypes/_authentication.py

Line 37 in 2db9303

("__DO_NOT_USE_Attribute", c_void_p),

[jdmarch]

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]

Thanks, I appreciate knowing that!

…

On Sun, Nov 28, 2021, 5:40 PM Jonathan March ***@***.***> wrote: Hi @jrobbins-LiveData <https://github.com/jrobbins-LiveData> -- just a heads-up that it may be a week or two before @itziakos <https://github.com/itziakos> will be available to respond to your question. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS43FGG5B7X5X3KCRIRL6V3UOKVVNANCNFSM5I5YSHEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[itziakos]

@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).

[jrobbins-LiveData]

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.

[itziakos]

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).