Name of the app
git
Describe the bug
When attempting to use add file to add a file to the repository files that cannot be read into 'utf8' are failing with the expectation "'utf8' codec can't decode byte 0xa5 in position 0: invalid start byte" as an example.
To Reproduce
Steps to reproduce the behavior:
- Create Event/Container with a .xlsm file type as a vault artifact
- Use Clone repo to bring done repo
- Use Add File to move file to repo from vault location
- See error
Expected behavior
It appears files that cannot be read are failing with 'utf8' are failing with the expectation "'utf8' codec can't decode byte 0xa5 in position 0: invalid start byte" as an example.
Splunk SOAR Version (please complete the following information):
- Unprivileged Install - SOAR 5.5
- OS Version - RHEL 8.7
- App Version - GIT 2.1.0
Additional context
Modify git_connector.py
changing read_text() to read_bytes() seems to work
255 vault_file_data = vault_file_path.read_text() > vault_file_data = vault_file_path.read_bytes()
271 full_path.write_text(file_data) > full_path.write_bytes(file_data)
I am no expert and not sure what implications this has but this is a viable solution for our instance.
Name of the app
git
Describe the bug
When attempting to use add file to add a file to the repository files that cannot be read into 'utf8' are failing with the expectation "'utf8' codec can't decode byte 0xa5 in position 0: invalid start byte" as an example.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It appears files that cannot be read are failing with 'utf8' are failing with the expectation "'utf8' codec can't decode byte 0xa5 in position 0: invalid start byte" as an example.
Splunk SOAR Version (please complete the following information):
Additional context
Modify git_connector.py
changing read_text() to read_bytes() seems to work
255 vault_file_data = vault_file_path.read_text() > vault_file_data = vault_file_path.read_bytes()
271 full_path.write_text(file_data) > full_path.write_bytes(file_data)
I am no expert and not sure what implications this has but this is a viable solution for our instance.