Error running module on Linux

[miguel-negrao]

NFO: Running analyzer on /media/miguel/internal2/Development/Research/vad_transcribe_paper/data_mounted/data/com.google.android.inputmethod.latin folder
2021-07-19 15:54:02.162 org.sleuthkit.autopsy.ingest.IngestJobPipeline logErrorMessage
SEVERE: GBoard4A experienced an error during analysis (data source = LogicalFileSet1, objId = 1, pipeline id = 0, ingest job id = 3)
Traceback (most recent call last):
  File "/home/miguel/.autopsy/dev/python_modules/GBoard4A-Linux-release-x86_64/gboard_autopsy.py", line 174, in process
    analysis_output = self.run_analyzer(input_dir)
  File "/home/miguel/.autopsy/dev/python_modules/GBoard4A-Linux-release-x86_64/gboard_autopsy.py", line 174, in process
    analysis_output = self.run_analyzer(input_dir)
  File "/home/miguel/.autopsy/dev/python_modules/GBoard4A-Linux-release-x86_64/gboard_autopsy.py", line 260, in run_analyzer
    process = subprocess.Popen(cmd_args, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
  File "/opt/autopsy/autopsy/modules/ext/jython-standalone-2.7.0.jar/Lib/subprocess.py", line 830, in __init__
  File "/opt/autopsy/autopsy/modules/ext/jython-standalone-2.7.0.jar/Lib/subprocess.py", line 1352, in _execute_child
OSError: Cannot run program "/home/miguel/.autopsy/dev/python_modules/GBoard4A-Linux-release-x86_64/gboard-forensics" (in directory "/home/miguel"): error=13, Permission denied

miguel@legion:~/.autopsy/dev/python_modules/GBoard4A-Linux-release-x86_64$ ls -l
total 3076
-rw-r--r-- 1 miguel miguel   36018 jul 19 10:27 'gboard_autopsy$py.class'
-rw-rw-r-- 1 miguel miguel   23480 jul 17 21:06  gboard_autopsy.py
-rw-rw-r-- 1 miguel miguel 3084856 jul 17 21:06  gboard-forensics

It appears gboard-forensics is doesn't have execute permission. This is for version posted privately on Teams.

After manually setting the execute permission the module runs fine.

[ljmf00]

That is because zip files don't contain filesystem permissions, you should set the permissions for the executables manually, unfortunately. Related to actions/upload-artifact#38 .

[ljmf00]

A solution would be to generate a tar inside the zip file, but that is far from ideal and not practical at all.

[miguel-negrao]

That is because zip files don't contain filesystem permissions, you should set the permissions for the executables manually, unfortunately. Related to actions/upload-artifact#38 .

That is not really acceptable. At least when you make the official release on github please upload a .tar.gz.

[ljmf00]

Yes, I understand and agree that this is unacceptable behaviour. In the issue referred, people are mad about this not begin yet fixed, unfortunately.

Meanwhile, releases are manual so, manually checking it is mandatory to make sure everything doesn't break.

Although, I would suggest keeping this issue open until the dependent action fixes it on their side.

[ljmf00]

@miguel-negrao a new release was manually created https://github.com/labcif/GBoard4A/releases/tag/1.0.0 . The artifacts have now a .tar.gz with proper permissions.

[miguel-negrao]

Tested the release, runs fine here. Congratulations on the release. :-)

[miguel-negrao]

Perhaps https://github.com/softprops/action-gh-release can be used.

[ljmf00]

Perhaps softprops/action-gh-release can be used.

That is to publish releases automatically. The action I'm using is only to generate release artefacts instead of publishing. The idea would be to have a staging step before release to manually test if the artifact is well generated and good for release. This is a good practice because tags on git should be immutable and if a tag generates malformed artefacts, then a malformed release will be pushed, which is not good.

Build --> Test --> Generate Release Artifacts ----> Deploy to Github Releases
                                               ||
                                               \/
                                       Manual intervention

For this to happen flawlessly, it would be good to already have the generated artefacts with proper permissions, although, there is nothing preventing us to generate a tar.gz for Github releases only.

Some CIs have manual approval to CI steps. Circle CI, for example, already has a feature to manually do this https://circleci.com/docs/2.0/triggers/#manual-approval .

For Github workflows, there is a way to do manual approvals, see here: https://devblogs.microsoft.com/devops/i-need-manual-approvers-for-github-actions-and-i-got-them-now/

Although, I don't have permission to add that right now.

[miguel-negrao]

For Github workflows, there is a way to do manual approvals, see here: https://devblogs.microsoft.com/devops/i-need-manual-approvers-for-github-actions-and-i-got-them-now/

Although, I don't have permission to add that right now.

Let me know if you want me to add manual approvals, detailing exactly what I need to do.