[Plugin] Add ShowPilot-Lite

[github-actions]

Adds ShowPilot-Lite to pluginList.json, requested in #43.

Plugin repo: https://github.com/ShowPilotFPP/ShowPilot-Lite
pluginInfo.json: https://raw.githubusercontent.com/ShowPilotFPP/ShowPilot-Lite/refs/heads/main/pluginInfo.json
Submitted by: @bjhiltbrand
Registered owner (from srcURL): @ShowPilotFPP - differs from the submitter and was not verified; note the contact email on file is the submitter's, not necessarily the owner's. (This PR still only opened because the reporter used /submit to override that finding.)

⚠️ Opened despite 6 unresolved finding(s) below - the reporter used /submit to ask for review anyway rather than fix them first:

• 🛑 Blocker - owner-unconfirmed - submitter @bjhiltbrand does not match ShowPilotFPP, this repo's registered owner (from srcURL). Add "submissionToken": "fpp-43" to your pluginInfo.json and comment /recheck to prove you have write access here - or, if you're submitting on the owner's behalf with their consent, comment /submit instead to flag this for a maintainer's judgement rather than auto-verifying.
• 🛑 Blocker - remote-exec - pipes a remote script into a shell (scripts/fpp_install.sh:62: curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -) - install the dependency through a package manager FPP already has instead: apt-get install for system packages, npm install for Node packages, or pip install --break-system-packages for Python packages. Only if there's genuinely no package for it, download the installer to a file, verify its checksum, then run it, e.g. curl -fsSLo installer.sh https://example.com/install.sh && echo "<sha256> installer.sh" | sha256sum -c && bash installer.sh
• ⚠️ Best practice - sudo - uses sudo in a script (scripts/fpp_install.sh:62: curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -) - install/hooks already run as root, so remove the sudo call and run the command directly, e.g. curl -fsSL https://deb.nodesource.com/setup_22.x | -E bash -
• ⚠️ Best practice - log-naming - installs an always-on service but has no FPP-conformant log anywhere (no LOGDIR/logDirectory/plugin-ShowPilot-Lite.log reference) - log to $settings['logDirectory']."/plugin-ShowPilot-Lite.log" (PHP) or the equivalent in your language, so the service's output surfaces in FPP's log viewer and Support Zip instead of only wherever stdout happens to go
• ⚠️ Best practice - no-timeout - outbound HTTP call has no timeout set (scripts/fpp_install.sh:62: curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -) - a hung remote server stalls this indefinitely, blocking whatever hook/show command triggered it. Set CURLOPT_TIMEOUT/CURLOPT_CONNECTTIMEOUT (PHP curl), the 'timeout' key (PHP stream contexts), or timeout= (Python requests)
• ⚠️ Best practice - external-cdn - loads a script/stylesheet from an external CDN (public/admin/index.html:1612: <script src="https://cdnjs.cloudflare.com/ajax/libs/Chart.js/4.4.1/chart.umd.min.js"></script>) - FPP's web shell already bundles Bootstrap/jQuery, and a show network is often offline/isolated, so a CDN dependency can silently fail to load. Use FPP's already-loaded copy instead of pulling your own from a CDN

Schema, category, and archived/issues-disabled were already checked before this PR existed.

Merging is entirely up to a maintainer's judgement - this PR being open is not an approval, especially if it was opened via /submit over unresolved findings above.

⚠️ Before merging: install this plugin on a real (or test) FPP instance and visually inspect it - the automated check only covers what it can grep for. Confirm the UI actually renders correctly in both light and dark theme, nothing looks broken, and there's nothing the automated findings above wouldn't catch (ads, phone-home, donation links, ...).

A repo maintainer (or @bjhiltbrand) can comment /recheck here to re-run the plugin check against the repo's current state and refresh the findings above.

[bjhiltbrand]

I added the submit flag on the issue simply to show that I am not the owner, but that I have approval from the owner to submit. I have corrected the other findings, but the PR for those findings is still pending approval. Therefore, I didn't run the recheck in the issue and didn't realize that it would be closed out and this PR would be opened. I can update here when my PR for the showpilot lite repo is complete. I apologize for jumping the gun on the issue template.

[bjhiltbrand]

/recheck

[github-actions]

🔄 Recheck

Plugin: ShowPilot-Lite
Repo: https://github.com/ShowPilotFPP/ShowPilot-Lite
Owner: ShowPilotFPP

Requested by @bjhiltbrand - 3 issue(s) currently outstanding:

• 🛑 Blocker - owner-unconfirmed - submitter @bjhiltbrand does not match ShowPilotFPP, this repo's registered owner (from srcURL). Add "submissionToken": "fpp-43" to your pluginInfo.json and comment /recheck to prove you have write access here - or, if you're submitting on the owner's behalf with their consent, comment /submit instead to flag this for a maintainer's judgement rather than auto-verifying.
• ⚠️ Best practice - sudo - uses sudo in a script (scripts/fpp_install.sh:60: # already run as root, so no sudo is needed here either.) - install/hooks already run as root, so remove the sudo call and run the command directly, e.g. # already run as root, so no is needed here either.
• ⚠️ Best practice - external-cdn - loads a script/stylesheet from an external CDN (public/admin/index.html:1613: <script src="https://unpkg.com/monaco-editor@0.45.0/min/vs/loader.js"></script>) - FPP's web shell already bundles Bootstrap/jQuery, and a show network is often offline/isolated, so a CDN dependency can silently fail to load. Use FPP's already-loaded copy instead of pulling your own from a CDN

This comment reflects the repo's current state; it does not change the PR itself - merging is still a maintainer's call.

[darylc]

@bjhiltbrand No problem - this workflow is new and we are tuning the wording and checks based on learnings as we go.

Given the github account that has submitted the request is different to the github account that owns the plugin, we would like you to add the proof to the json file to prove ownership.

In addition to the automated checks, we have concerns with the plugin. Our understanding is that there is the potential for the plugin owner to reconfigure the Cloudflare tunnel remotely at any time without warning and gain live remote access to the fpp and hence the end-users full local network. Assuming that is the case, it is a risk that would need further discussion prior to plugin approval.

[darylc]

/recheck

[github-actions]

🔄 Recheck

Plugin: ShowPilot-Lite
Repo: https://github.com/ShowPilotFPP/ShowPilot-Lite
Owner: ShowPilotFPP

Requested by @darylc - 6 issue(s) currently outstanding:

• 🛑 Blocker - owner-unconfirmed - submitter @bjhiltbrand does not match ShowPilotFPP, this repo's registered owner (from srcURL). Add "submissionToken": "fpp-43" to your pluginInfo.json and comment /recheck to prove you have write access here.
• 🛑 Blocker - sql-injection - SQL query built by string concatenation (lib/backup.js:105: return db.prepare(PRAGMA table_info(${tableName})).all().map(c => c.name);) - if any part of that string traces back to user input, this is SQL injection. Use a placeholder instead: db.prepare('... WHERE x = ?').run(value) (or @x/named params), not a template literal or + concatenation
• 🛑 Blocker - runtime-sudo - runtime application code shells out through sudo (lib/cloudflared.js:176: const inst = await run('sudo', ['dpkg', '-i', tmpFile], { timeout: 60000 });) - unlike sudo in an install/uninstall hook (which already runs as root), this runs inside the plugin's always-on process, normally started as the unprivileged fpp user. If fpp has passwordless sudo for this command, anything that can reach this code path (e.g. an HTTP route) gets root, continuously - not just once at install time. Move the privileged action into fpp_install.sh/fpp_upgrade.sh (run once, already as root) instead of invoking sudo from the running service
• ⚠️ Best practice - unverified-package-install - installs a downloaded package with no checksum/signature check (lib/cloudflared.js:176: const inst = await run('sudo', ['dpkg', '-i', tmpFile], { timeout: 60000 });) - HTTPS protects the transport, but there's no defense-in-depth if the download URL, CDN, or upstream release is ever compromised, and this install almost certainly runs as root. Verify the download before installing it, e.g. curl -fsSL <checksums-url> | grep <file> | sha256sum -c - (or check the upstream project's published GPG signature) before dpkg -i
• ⚠️ Best practice - sudo - uses sudo in a script (scripts/fpp_install.sh:60: # already run as root, so no sudo is needed here either.) - install/hooks already run as root, so remove the sudo call and run the command directly, e.g. # already run as root, so no is needed here either.
• ⚠️ Best practice - external-cdn - loads a script/stylesheet from an external CDN (public/admin/index.html:1613: <script src="https://unpkg.com/monaco-editor@0.45.0/min/vs/loader.js"></script>) - FPP's web shell already bundles Bootstrap/jQuery, and a show network is often offline/isolated, so a CDN dependency can silently fail to load. Use FPP's already-loaded copy instead of pulling your own from a CDN

This comment reflects the repo's current state; it does not change the PR itself - merging is still a maintainer's call.

[ShowPilotFPP]

I'm the owner of the repo. The ShowPilot Lite version is only configurable from the local FPP. There are no cloud ties to anything other than the end users Cloudflare account.

…

On Sat, Jul 25, 2026 at 7:57 PM darylc ***@***.***> wrote: *darylc* left a comment (FalconChristmas/fpp-data#44) <#44 (comment)> @bjhiltbrand <https://github.com/bjhiltbrand> No problem - this workflow is new and we are tuning the wording and checks based on learnings as we go. Given the github account that has submitted the request is different to the github account that owns the plugin, we would like you to add the proof to the json file to prove ownership. In addition to the automated checks, we have concerns with the plugin. Our understanding is that there is the potential for the plugin owner to reconfigure the Cloudflare tunnel remotely at any time without warning and gain live remote access to the fpp and hence the end-users full local network. Assuming that is the case, it is a risk that would need further discussion prior to plugin approval. — Reply to this email directly, view it on GitHub <#44?email_source=notifications&email_token=ATLA4GROETY36QLBEVSZNDT5GVJPLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBYGEZDSNJRGQ22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5081295145>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATLA4GRP4SO6IOBMVHV7LI35GVJPLAVCNFSNUABFKJSXA33TNF2G64TZHM2TAMZYGIZTKOJYHNEXG43VMU5TIOJXGYYTOMRWGIZKC5QC> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[darylc]

@bjhiltbrand Thanks for the clarification on the Cloudflare aspect, that makes more sense. This plugin is quite complex compared to the average FPP plugin, so it will take some time for the FPP developers to complete their review.