You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[WARNING]: Failure using method (v2_runner_on_ok) in callback plugin (<ansible.plugins.callback.default.CallbackModule object at 0x7f5705344c10>): 'utf-8' codec can't encode character '\udc80' in position 1731: surrogates not allowed
#654
Open
cidrbl0ck opened this issue
Sep 8, 2023
· 3 comments
Greetings: So to start off I do know there are pre-existing Issues on this exact thing. To be perfeclty honest I was not sure the best course of action.. to re-open one of those to to create a new issue so apologies if I chose poorly.
I'm fighting the same issue and while I've found multiple issues on this problem I do not understand what we should be doing Ansible Core issue 80258 gives the impression that the community.crypto modules would eventually return utf-8 encoded data.
However Crypto Issue 591 is entirely confusing and I'm left feeling that this problem will never be resolved and the module is just broke.
I hope someone corrects me here because it's using this module or stringing ugly shell commands for openssl s_client together....
A very small sub-issue to this that I don't know if related to the UTF-8 issue or not would be the type_debug. The docs page for this module states that note_after is a string. So getting AnsibleUnsafeText is confusing as well.
You can simply add asn1_base64: true to community.crypto.get_certificate's options.
That will be the new default of asn1_base64 in community.crypto 3.0.0 anyway, but the 3.0.0 release won't happen so soon, until then you can manually set it to true.
A very small sub-issue to this that I don't know if related to the UTF-8 issue or not would be the type_debug. The docs page for this module states that not_after is a string. So getting AnsibleUnsafeText is confusing as well.
AnsibleUnsafeText is an ansible-core internal of a string returned by a module (it's marked 'unsafe' because of that, so it isn't automatically templated - that would allow modules executed on remote targets to execute code on the controller, which would be very bad from a security point of view).
The problem you have in the last set_fact is that to_datetime expects a very specific date/time format, which is very different from the date/time format returned by the module. 20231205235959Z is in ASN.1 UTCTime format (https://obj-sys.com/asn1tutorial/node15.html), while to_datetime apparently expects %Y-%m-%d %H:%M:%S (with dashes, space, and colons, and no Z).
Thanks Felix, I did see asn1_base64: true mentioned but the doc page wasn't clear on how to make use of that. I did attempt to add it into the task.....
And well wouldn't you know it, it worked this time. SMH.
No so before I posted the Issue I did attempt the task as:
Greetings: So to start off I do know there are pre-existing Issues on this exact thing. To be perfeclty honest I was not sure the best course of action.. to re-open one of those to to create a new issue so apologies if I chose poorly.
I'm fighting the same issue and while I've found multiple issues on this problem I do not understand what we should be doing Ansible Core issue 80258 gives the impression that the community.crypto modules would eventually return
utf-8
encoded data.However Crypto Issue 591 is entirely confusing and I'm left feeling that this problem will never be resolved and the module is just broke.
I hope someone corrects me here because it's using this module or stringing ugly shell commands for openssl s_client together....
A very small sub-issue to this that I don't know if related to the UTF-8 issue or not would be the type_debug. The docs page for this module states that
note_after
is a string. So getting AnsibleUnsafeText is confusing as well.ISSUE TYPE
COMPONENT NAME
community.crypto.get_certificate
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
Ubuntu 20.04 LTS
STEPS TO REPRODUCE
EXPECTED RESULTS
ACTUAL RESULTS
The text was updated successfully, but these errors were encountered: