Refactor dependency settings for managed and system-provided dependencies #8495

Context

The Dependencies section is not independent from the settings above it.

The current settings order is:

1. Certificate engine
2. Signature engine
3. Dependencies
4. Setup checks

Which dependencies are required depends on the selected certificate and signature engines.

Today, DownloadBinaries.vue is mainly responsible for:

• showing Download binaries or Validate setup;
• calling /admin/install-and-validate;
• displaying download progress and errors.

That flow assumes LibreSign is responsible for downloading the dependencies. It needs to be refactored now that dependencies can also be provided by the operating system.

Goal

Refactor the existing Dependencies settings section so that it reflects the configuration selected above it.

The expected user flow is:

1. select the certificate and signature engines;
2. LibreSign loads the dependencies required by that configuration;
3. choose how each required dependency is provided;
4. configure a system path when needed;
5. download missing LibreSign-managed dependencies or validate the setup.

The Dependencies section must be driven by the backend dependency plan. The frontend must not maintain its own dependency matrix.

Dependency source

For each required dependency supported by this feature, allow the administrator to choose:

• Managed by LibreSign
• Provided by the system

Managed by LibreSign

• no system path is required;
• LibreSign can download and manage the dependency.

Provided by the system

• show a path field;
• LibreSign must not download or overwrite the dependency;
• validation comes from the backend dependency contract.

React to engine changes

The application already emits:

• libresign:certificate-engine:changed
• libresign:signature-engine:changed

and configureCheckStore already reacts to these changes.

Extend/refactor this flow so that changing either engine also refreshes the dependency plan.

Expected behavior:

1. the administrator changes an engine;
2. the setting is saved;
3. the dependency plan is reloaded;
4. dependencies that are no longer required disappear;
5. newly required dependencies appear;
6. the final action is recalculated from the new plan.

Do not keep stale dependency state after an engine change.

Final action

The current download button should become the final action of the dependency configuration flow.

Do not offer Download dependencies until LibreSign knows:

• which dependencies are required;
• how each required dependency is provided;
• whether required system paths have been configured.

Expected behavior:

• one or more required managed dependencies are missing → Download dependencies
• all required managed dependencies are already available → Validate setup
• all required dependencies are system-provided → Validate setup
• a required system dependency has no path → the configuration is incomplete; downloading is not the solution

The action must only download dependencies that the backend marks as both required and managed.

Refactor the current component

DownloadBinaries.vue no longer represents the full responsibility of this section.

Refactor the Dependencies UI instead of adding more conditions around the existing button.

Keep the responsibilities separated enough that one component does not own all of:

• dependency configuration;
• source/path fields;
• persistence;
• install/validate action;
• SSE download progress;
• error rendering.

The existing progress and error behavior can be reused.

The exact component structure and names are implementation details.

State

The dependency configuration should use shared state suitable for the settings flow instead of keeping everything local to the final action component.

The frontend needs to represent at least:

• dependency plan loading;
• required dependencies;
• selected source;
• configured system path;
• validation status;
• whether a managed download is required;
• install/validation in progress.

The backend remains the source of truth for which dependencies are required.

Examples

Native signature engine

If the backend plan does not require Java or JSignPdf, they should not be presented as dependencies to download.

JSignPdf with mixed dependency sources

A configuration may use, for example:

• Java → system
• JSignPdf → managed
• PDFtk → system

The final action should download only JSignPdf and then validate the complete setup.

Configuration change

If the administrator changes an engine, the dependency list must be recalculated before another download/validation action is offered.

Tests

Add/update component and store tests covering at least:

• initial dependency plan load;
• engine change reloads the dependency plan;
• dependencies no longer required disappear;
• newly required dependencies appear;
• managed dependency does not show a system path field;
• system dependency shows a path field;
• incomplete system configuration does not offer download as the fix;
• missing managed dependency enables Download dependencies;
• no missing managed dependency shows Validate setup;
• mixed managed/system configuration downloads only managed dependencies;
• progress and errors remain visible during install/validation;
• frontend does not duplicate backend dependency rules.

Add Playwright coverage for the settings flow if practical:

1. change the engine configuration;
2. verify that the dependency list changes;
3. configure managed/system sources;
4. provide a system path;
5. run download/validation;
6. verify the resulting setup state.

Out of scope

• backend dependency-source and validation implementation;
• automatic discovery from PATH;
• changing system permissions or SELinux policies;
• FreeBSD support itself.

Done when

• Dependencies shown in the UI come from the current backend dependency plan.
• Engine changes refresh that plan.
• Required dependencies can be configured as managed or system-provided.
• System-provided dependencies expose path configuration.
• The final action is available only after dependency source configuration is complete.
• Only missing managed dependencies are downloaded.
• System dependencies are never downloaded or overwritten.
• The action becomes Validate setup when there is nothing to download.
• Existing progress/error feedback is preserved.
• Component/store tests cover engine changes and managed/system combinations.