* Run the image vulnerability scan on a weekly schedule
The Trivy scan added in #29 only ran against changed code (PRs and
pushes), so a CVE disclosed against an otherwise unchanged base image
would go unnoticed until the next actual change. Add a weekly cron
trigger, matching Dependabot's cadence in .github/dependabot.yml.
The push job's existing `if: github.event_name == 'push'` guard means
a schedule-triggered run builds and scans but never publishes.
* Add workflow_dispatch so the scan can be run on demand
Copilot review on PR #30 suggested this: waiting for the Monday cron
to validate a fix is unnecessary friction. workflow_dispatch has no
inputs, so it just re-runs the same build/test/scan on demand; the
push job's event_name guard still keeps it from publishing.
---------
Co-authored-by: Maxim Shulga <maxim.shulga@alludo.com>
* Scan the built image for vulnerabilities and fix what's fixable
Ran trivy against the built image locally: 67 HIGH/CRITICAL findings,
65 of them in debian:bookworm-slim packages with no upstream fix yet.
The remaining 2 were both setuptools 66.1.1 (CVE-2024-6345,
CVE-2025-47273) — bundled by ensurepip when the venv is created, not
pinned by requirements.txt, so nothing was upgrading it.
- Upgrade setuptools to >=78.1.1 in the Dockerfile, which fixes both
CVEs. Verified with a local rebuild + rescan: 0 HIGH/CRITICAL
fixable findings remain.
- Add a Trivy scan step to the CI `test` job, after the smoke test.
Uses --ignore-unfixed so the build fails only on findings this repo
can act on, not on upstream Debian CVEs with no available patch.
- Check off the corresponding P0 item in IMPROVEMENTS.md; note that
scheduled (as opposed to PR/push-triggered) scanning is still open.
* Fix trivy-action tag (needs v prefix)
* Tighten scan-coverage wording per review
Copilot review on PR #29 flagged "every pull request and push" as
ambiguous: the test job's push trigger is scoped to master and tags,
not every branch. Spell that out.
---------
Co-authored-by: Maxim Shulga <maxim.shulga@alludo.com>
* Bound HTTP request timeouts and retry budget
With no request timeout, Retry(total=30, backoff_factor=2,
backoff_max=60) let a single unreachable server hang the client for
around 26 minutes: backoff sleeps alone sum to that, and each of the
30 connection attempts could itself stall indefinitely without a
timeout. Measured a black-holed connect attempt taking 75s on this
machine with no timeout set, confirming the mechanism.
- Add HTTP_TIMEOUT (connect, read) and a tighter retry budget
(HTTP_RETRY_TOTAL/BACKOFF_FACTOR/BACKOFF_MAX) in dsc/const.py,
bounding the worst case to a few minutes.
- Pass timeout=HTTP_TIMEOUT on both SeafileClient HTTP calls (token
fetch, remote library listing).
- Add NetworkError(DscError) so a network failure is caught by
start.py's existing top-level DscError handling instead of
producing a bare traceback.
- Add tests/test_http.py covering the retry policy values, timeout
propagation, and error wrapping.
- Check off the corresponding IMPROVEMENTS.md items.
* Include URL and status code in NetworkError messages
Copilot review on PR #28 flagged that the non-200 path for remote
library listing raised NetworkError with only the raw response body,
losing which request failed and its status code. The token-fetch
error had the same gap. Both now include the URL and HTTP status.
---------
Co-authored-by: Maxim Shulga <maxim.shulga@alludo.com>
Startup, shutdown and secret handling were only ever checked by hand, and the
unit tests cannot check them: they stub seaf-cli, so nothing exercised the
daemon that actually ships. The GitHub runner is x86_64, which matches the
AppImage, so the image build job can run the real thing.
tests/smoke.sh starts and stops the real daemon, sends SIGTERM through docker
stop and asserts the container exits 0 within the grace period with the daemon
shut down, checks that a configuration error exits 2 naming the variable, that
a secret mounted under /run/secrets is read and stays out of the environment,
and that a default container gets exactly the documented defaults.
The pinned client version is exposed as SEAFILE_CLI_VERSION in the image,
since seaf-cli has no --version flag and there is no package manager entry
for an AppImage.
The note explained a string comparison but wrote the values as if they were
booleans, which is the exact confusion it exists to clear up. Both places now
say which string was stored and which one the daemon accepts.
The daemon reads the key with seafile_session_config_get_bool, which is a
case sensitive g_strcmp0(value, "true"), so the capitalised True stored by
released images up to 0.0.13 was read as false and verification stayed on for
anyone who asked to disable it. The default was never affected, since any
value other than "true" is false.
Rendering booleans in lower case fixed this; this only writes down what the
change actually repaired, for anyone who reported the flag as broken.
set_defaults() assigned os.getenv() results directly, which overwrote the
argparse defaults with None whenever a variable was unset. A default container
therefore ran "seaf-cli config -k delete_confirm_threshold -v None", and the
same for upload_limit and download_limit: none of the three documented
defaults were ever applied.
SEAFILE_UID and SEAFILE_GID had a second problem. argparse type=int applies
only to command line flags, never to set_defaults, so both stayed strings.
The check in setup_uid compares them against pwd integers, and a string is
never equal to one, so usermod ran on every start.
dsc/config.py reads each variable with its documented default and rejects a
malformed or negative value at startup, naming the variable, instead of
passing it on. An empty variable counts as unset.
Booleans are now rendered as true and false rather than Python's True and
False. The daemon reads disable_verify_certificate with its boolean accessor,
which does not recognise the capitalised form. I could not run the daemon to
confirm the previous value's effect, since the AppImage is x86_64 only.
seaf-cli is no longer given a None value for any option.
get_local_libraries unpacked "line.rsplit(maxsplit=3)" into three names, but
maxsplit=3 yields up to four fields. seaf-cli prints "name id path" separated
by whitespace, so any library whose name contains a space produced a fourth
field and raised ValueError, which nothing caught.
The failure only appeared after the first run: the list is empty until a
library has been synced, so a container would work when it was set up and then
crash on every restart.
seaf-cli list --json returns name, id and path as structured fields, which
display output cannot represent unambiguously for names or paths containing
whitespace. Its exit code is now checked and unreadable output is reported as
a daemon error instead of a traceback.
The image smoke check asserts that the installed seaf-cli offers --json and
--token, so a future version bump that drops either fails the build rather
than the container.
The password could only be given through the PASSWORD variable, so Docker
Compose and Swarm secrets were unusable and the password sat in the container
environment.
PASSWORD_FILE and TOKEN_FILE read a secret from a mounted file. Only trailing
newlines are stripped, since secret files are usually written with one and a
password that silently carries it just fails to authenticate; everything else,
including surrounding spaces, belongs to the secret. Setting both a variable
and a file for one secret is rejected rather than resolved by precedence,
because the two are meant to be the same value and quietly picking one hides
the mistake until authentication fails.
The installed seaf-cli supports token authentication and ignores the password
when a token is given, so sync now passes -T instead of -p. The account
password no longer appears in any command line. The token does, because
seaf-cli accepts credentials only as arguments, but a token can be revoked on
the server. This is documented in the README.
Both secrets are masked before a command is logged.
Tests cover newline handling, empty and missing files, conflicting sources,
and that neither secret reaches the logs. Requests are now blocked in tests:
the client retries with backoff, so a test that reached the network appeared
to hang instead of failing.
start_daemon and stop_daemon polled "while True" with no bound, and no
seaf-cli exit code was checked. A daemon that failed to start left the
container spinning forever with nothing pointing at the cause, and there was
no signal handling, so "docker stop" waited the full 10 second grace period
and then SIGKILLed the process with the daemon still running.
Readiness polling is now bounded by DAEMON_START_TIMEOUT and
DAEMON_STOP_TIMEOUT. The stop timeout is 8 seconds so a graceful shutdown
fits inside the docker stop grace period, and a test asserts that relation.
SIGTERM and SIGINT raise GracefulShutdown, and the lifecycle moved into
start.run(), which always stops the daemon on the way out and returns the
process exit code: 0 on a clean finish or a stop signal, 1 on a daemon or
configuration failure.
seaf-cli exit codes are checked. A failed sync is reported per library and
does not stop the remaining libraries, since one bad library should not take
the container down.
Verified in the built image: "docker stop" now returns in 0s with exit code 0
and the daemon stopped, against 10s and exit 137 before. A daemon that cannot
start exits 1 with the failing command and its exit code in the log.
Also bumps actions/setup-python to v7, which clears the last Node 20
deprecation warning; v7 only drops the unused pip-install input.
Commands were joined into a string and passed to "su -c", so a login shell
parsed every interpolated value. A library name is chosen on the server, and
"sync -d /dsc/seafile/<name>" put it straight into that string: a library
named 'Docs; touch /tmp/pwned; #' ran as an arbitrary command. Confirmed
against the built image before and after this change.
Every command is now an argument list executed by "runuser --", which execs
directly with no shell. runuser -u sets the same HOME and a PATH that still
finds the seaf-cli wrapper, so the daemon environment is unchanged.
The password no longer needs its surrounding quotes, which also fixes
passwords containing quotes, dollar signs, and backticks.
Library names are untrusted, so dsc/paths.py reduces each one to a single
path component and proves the result stays under the libraries directory
with symlinks resolved. Empty, ".", "..", and names containing a separator
are skipped with a warning; names that would collide are suffixed with their
library ID rather than sharing a directory.
Tests cover quotes, command substitutions, separators, newlines, absolute
paths, parent traversal, Unicode, and colliding names. They run in a separate
CI job so application failures stay distinguishable from packaging failures.
Add a weekly Dependabot configuration for pip, the Dockerfile base image,
and the GitHub Actions used by the publish workflow.
The Seafile AppImage is fetched by URL with a pinned checksum, which
Dependabot cannot resolve, so it stays a manual bump.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add a .dockerignore that whitelists only requirements.txt, start.py and
dsc/. The build context previously included .git, .idea, __pycache__ and
any local .env, which slowed builds and put a secrets file within reach
of any future COPY of the whole tree.
Remove the unused urlparse import from dsc/client.py and the redundant
import os.path from start.py; importing os already binds os.path.
Record both in IMPROVEMENTS.md, including the part still outstanding:
binutils and squashfs-tools remain in the runtime image because the
AppImage is unpacked in the same stage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The push job called build-push-action twice, once for the ref tag and once
for latest. Two builds meant the two tags could resolve to different manifest
digests. Build once and let docker/metadata-action supply both tags and the
OCI labels for that single build.
Replace the deprecated actions/checkout@v2 and docker/build-push-action@v1,
default workflow permissions to contents: read so pull requests cannot reach
publication credentials, and authenticate with a scoped DOCKER_TOKEN through
docker/login-action instead of DOCKER_PASSWORD.
The test job's docker-compose.test.yml branch was dead; that file does not
exist in the repository.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The signature acceptance criterion assumed the signed APT repository.
Upstream ships a bare AppImage with no digest or signature, so as written
it could never be met and would block the release gate indefinitely.
State what the build actually enforces, and track the weakened supply
chain as its own item rather than only a note.
Seafile discontinued linux-clients.seafile.com: it resolves but accepts
no connections on 80 or 443, and the official docs no longer mention APT
at all. Every `docker build` has failed since. Upstream now ships the CLI
as an AppImage, so install 9.0.19 from the download site.
The AppImage is unpacked rather than executed. Running one needs FUSE and
so a privileged container, and its self-extraction also fails when the
build host cannot execute the payload's architecture. Unpacking the
appended squashfs directly avoids both.
Also add the bundled seafile/pysearpc bindings to the venv path. The APT
package installed them system-wide, where `venv --system-site-packages`
picked them up; dsc imports seafile directly for RPC, not only through
seaf-cli, so it broke when that implicit dependency went away.
Drops apt-key, pins the version, and verifies a SHA256 before unpacking.
Build-time smoke checks assert the seaf-cli subcommands and the app's own
imports.
Note: the AppImage is x86_64-only, and upstream publishes no digest or
signature, so the pinned checksum is trust-on-first-use.
The list-form environment syntax in the README passed quote characters
through as part of the value, so LIBRARY_ID was read as '"<id>"' and no
matching library was found. Switch to mapping syntax, where YAML strips
the quotes.
- Pin the example to a versioned image instead of implicit latest
- Add a checked-in compose.example.yaml
- Validate it with `docker compose config` in CI
- Link the Docker Hub image from the README
Maksim ShulgaandMaxim Shulga
