I tried basic troubleshooting first
Describe the bug
It appears there is an issue with something related to the functionality or implementation of Node, specifically in relation to the node_download() function within sign.py. This is, however, only an assumption based on my understanding of the log file.
As sign.py begins to run within Semaphore CI, we see the parent error: connect ECONNREFUSED ::1:8080. It appears to me there may be an issue with Semaphore CI interfacing with localhost (ipv6) at port 8080. That this is localhost of Semaphore CI, and not the SignTools process (on my RPi), as I have tested running SignTools on a different port (8081) and still receive the same error.
The issue persists with the implementation of GitHub Actions, in place of Semaphore CI. Issue also persists when interfacing with SignTools directly on the host machine (and disabling Caddy, the Reverse Proxy). Although, in this case, the task was using a custom bundleID, the issue still persists when signing an application with a default configuration.
SignTools’ web interface always reports either “Waiting“ or “Failed“ four any given application.
I’m using custom/explicit certificate and mobile provisioning files, with a password text file and then file included. The directory structure outlined in the advanced install guide was followed and all other functionality seems to be working as expected.
I have done as much Googling and Stack Overflow’ing as I would find reasonable before posting this bug (colluding some research into node_fetch), but I feel they may just be an issue with my configuration of the whole setup. I have follow the advance, guide closely, as well as viewing the FAQ, I have not been able to find the answer to this issue.
To reproduce
Steps to reproduce the behavior:
- Start an app-signing job via SignTools web interface.
- Click ‘Status’.
- Select the most recent CI job.
- See error.
Expected behavior
I would expect the CI handler to successfully run sign.py, and furthermore sign the requested application.
Logs
Full Log: https://pastebin.com/fPb5PBD3
Screenshots

System configuration
- SignTools version: 2.6.2
- Installation type: Raspberry Pi (self-hosted) → Caddy Reverse Proxy
- Builder type: SignTools-CI via Semaphore CI
- Builder version: 704d7be
Additional context
I am running SignTools on a Raspberry Pi 4 and run a reverse proxy through Caddy.
I tried basic troubleshooting first
Describe the bug
It appears there is an issue with something related to the functionality or implementation of Node, specifically in relation to the
node_download()function withinsign.py. This is, however, only an assumption based on my understanding of the log file.As
sign.pybegins to run within Semaphore CI, we see the parent error:connect ECONNREFUSED ::1:8080. It appears to me there may be an issue with Semaphore CI interfacing with localhost (ipv6) at port 8080. That this is localhost of Semaphore CI, and not the SignTools process (on my RPi), as I have tested running SignTools on a different port (8081) and still receive the same error.The issue persists with the implementation of GitHub Actions, in place of Semaphore CI. Issue also persists when interfacing with SignTools directly on the host machine (and disabling Caddy, the Reverse Proxy). Although, in this case, the task was using a custom bundleID, the issue still persists when signing an application with a default configuration.
SignTools’ web interface always reports either “Waiting“ or “Failed“ four any given application.
I’m using custom/explicit certificate and mobile provisioning files, with a password text file and then file included. The directory structure outlined in the advanced install guide was followed and all other functionality seems to be working as expected.
I have done as much Googling and Stack Overflow’ing as I would find reasonable before posting this bug (colluding some research into node_fetch), but I feel they may just be an issue with my configuration of the whole setup. I have follow the advance, guide closely, as well as viewing the FAQ, I have not been able to find the answer to this issue.
To reproduce
Steps to reproduce the behavior:
Expected behavior
I would expect the CI handler to successfully run
sign.py, and furthermore sign the requested application.Logs
Full Log: https://pastebin.com/fPb5PBD3
Screenshots
System configuration
Additional context
I am running SignTools on a Raspberry Pi 4 and run a reverse proxy through Caddy.