mirror of
https://github.com/logos-co/logos-app.git
synced 2026-08-29 10:21:10 +00:00
master
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Dario LipicarandClaude Opus 5
|
dadc7b6bbb |
feat(deps): refuse a UI plugin whose dependency version does not satisfy its range (#361)
* test(deps): pin what the load gate actually admits
The gate in front of a UI plugin load reads
package_manager.resolveFlatDependencies and classifies each row BY
EXCLUSION:
if (m.value("status").toString() == "not_installed") missing << s;
else installed << s;
`status` is a closed vocabulary owned by logos-package-manager, and it
gained a fourth word. Anything invented after that line was written lands
in `installed`, so a plugin is admitted on top of a dependency the
resolver rejected — with no diagnostic anywhere.
Lift the predicate into app/utils/DependencyBlocker.h VERBATIM, alongside
the message-building it will need, and put the desired behaviour under
test. The three fixtures are wire payloads captured from a real logoscore
daemon over a real installed tree, parsed with QJsonDocument so the suite
consumes exactly the bytes the module emits.
Red at this commit — the classification cases fail, which is master's
behaviour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* feat(deps): refuse a load on a version-mismatched dependency, and say which
The gate in front of a UI plugin load treated every status except
"not_installed" as satisfied, so a dependency the resolver had just
rejected for being the wrong version was admitted — the plugin mounted on
top of it, or liblogos refused with a bare "plugin load failed".
Name the blocking statuses instead of excluding one, and carry the reason
as far as the user:
* PackageCoordinator gains m_blockingDepsByModule alongside the existing
name list — same membership, filled in the same pass, one map per
blocking dependency. missingDepsOf keeps returning names, so the
sidebar marker, AppsModel::setMissingDeps and installStatus are
untouched; blockingDepsOf is for callers that must TELL the user
something.
* ConfirmationDialog says one of three sentences. "cannot be loaded
because the following modules are not installed" is a lie about a
module that is installed at the wrong version, and it sends the user
to reinstall something they already have. Each row now names the
constraint and what was found — "depsvc — requires ^2.0.0, found
1.0.0" — because a complaint the user cannot act on is barely better
than silence.
* The sidebar marker keeps the red cross for an absent dependency and
draws an amber "!" for a version conflict. "mixed" keeps the cross:
something IS absent, and that is the fact to act on first.
* ModuleInstanceModel's badge reads "Version conflict" rather than
"Missing deps" for the same reason. depBlockKind joins the diffRoles
mask because replaceRows SKIPS a row whose mask is empty, so a row
going absent -> mismatch would otherwise keep the stale word forever.
Deliberately still admitted, both pinned by tests: "cycle" (never driven
against a real cyclic install — blocking it would be a behaviour change
made blind) and an unrecognised status (this gate is advisory in front of
liblogos' own resolver; refusing on a word this build does not know would
block loads that work).
Consequence worth naming: a version-mismatched app now demotes to
installStatus NotInstalled in the App Manager, exactly as one with an
absent dependency already did. The remedy the button offers — reinstall,
which re-resolves dependencies — is right for both.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(plugins): pin what the core-dependency loader actually reads
PluginLoader::loadCoreDependencies read each `dependencies[]` entry as
QString depName = dep.toString();
if (depName.isEmpty()) continue;
QVariant::toString() on a QVariantMap returns a NULL QString — no
diagnostic, no exception. So the moment the module ABI is widened to send
the object form {"name": …, "version": "^2.0.0", "signer": "did:…"} that
the LGX spec already allows and lgpm already parses, every CONSTRAINED
core dependency is silently skipped and the ui plugin mounts on top of an
unloaded dependency.
This commit changes no behaviour. It gives that decision a name
(logos::readDependencyEntry) and a test, so the next commit's fix is
visible as a diff in outcomes rather than a diff in expressions.
Red, as expected — 5 of 14 cases fail against the extracted behaviour:
FAIL! : object_entry_yields_its_name() kind 1, want 0
FAIL! : object_entry_without_constraints_yields_its_name() kind 1, want 0
FAIL! : json_object_entry_yields_its_name() kind 1, want 0
FAIL! : hash_object_entry_yields_its_name() kind 1, want 0
FAIL! : a_number_is_unrecognised() kind 0, want 1
(1 = Unrecognised, i.e. skipped. The last one is the mirror image: a
non-string scalar is currently stringified and loaded as a module name.)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(plugins): read object-form core dependency entries, refuse the rest
The load gate now understands both forms the LGX spec allows, and reports
what it cannot understand instead of walking past it.
Green — 14/14, was 9/14:
PASS : object_entry_yields_its_name()
PASS : object_entry_without_constraints_yields_its_name()
PASS : json_object_entry_yields_its_name()
PASS : hash_object_entry_yields_its_name()
PASS : a_number_is_unrecognised()
Totals: 14 passed, 0 failed
Two behaviour changes at PluginLoader::loadCoreDependencies:
* {"name": "wallet_module", "version": "^2.0.0", "signer": "did:…"} now
loads wallet_module. Before, QVariant::toString() returned a null
QString for it and the `if (depName.isEmpty()) continue;` skipped the
dependency with no error and no log line — the ui plugin then mounted
on top of a core module that was never loaded, and the first symptom
was a dead endpoint somewhere else entirely.
Latent today only because the module ABI still sends bare strings
(package_manager_impl.cpp's toLogosMap flattens the constraint away).
It arms itself the moment that is widened. Every other reader in the
fleet already handles both forms — logos-module's module_metadata.cpp,
logos-standalone-app's mainwindow.cpp, logos-cpp-sdk's
metadata_dependencies.h, lgpm's manifest scan. Basecamp was the outlier.
* An entry that is neither a name nor an object with a string "name" is
now a hard, logged load failure rather than a silent skip. Same reason:
we cannot honour a dependency we cannot name, and mounting anyway hides
it. This also stops a stray scalar being stringified into a module
name — QVariant(42).toString() is "42", and the old loop would have
gone looking for a module called that.
Unreachable from `lgpm install` today: logos-package's Manifest::fromJson
rejects a non-string/non-object entry outright, and lgpm's own scan warns
and drops what gets past it. The branch exists for the manifests that
bypass both — embedded installs written at build time, and anything
edited in place afterwards.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* feat(deps): refuse a load on a dependency published by a different signer
A dependency can now fail its dependant in a third way, and it needs a third
sentence. The gate already separated "not installed" from "installed at a
version it does not accept", because "install it" and "get another version" are
different instructions. `signer_mismatch` is a package installed under the RIGHT
NAME by the WRONG PUBLISHER — somebody else's package — and neither of those
instructions works on it. Installing gets the same package back; no version of
what is on disk is the package the module named.
blockSummary headline body
"absent" Missing Dependencies "…are not installed"
"mismatch" Incompatible Dependencies "…installed at a version it does
not accept"
"signer" Unexpected Publisher "…were published by a different
signer than it requires … reinstall
these from the publisher the module
names"
"mixed" Missing Dependencies "…missing, the wrong version, or from
a different publisher"
Per row, the detail clause names BOTH DIDs: "published by a different signer;
requires <pin>, found <observed>". The pin alone does not say what went wrong;
the observation alone is an accusation with no charge attached.
THE DESIGN CALL, and it is pinned by a test rather than left as an omission.
`signer_unknown` — the edge pins a publisher and NOTHING RECORDS who published
the installed package — does NOT block. Absence of evidence is not evidence of
mismatch, and this is the expected state for two whole populations: every
EMBEDDED package (placed by the build, never through the installer that records
a publisher, so it can never acquire one) and everything installed before the
record existed. Blocking here would make a pin on an embedded dependency
unsatisfiable by construction, forever, with no action a user could take.
logos-package-manager owns the call and can flip it in one place
(UnknownSignerPolicy::Strict makes its scanner emit signer_mismatch, which this
gate already blocks), which is exactly why this gate must not second-guess it.
Three places in this header classified by testing ONE value and sweeping the
rest into a default, and all three are now switches or named alternatives:
readDependencyBlocker the trailing `else` that made version_mismatch
count as satisfied — already fixed, extended
dependencyBlockerToMap `VersionMismatch ? … : "not_installed"`, which
would have crossed into QML labelling a signer
mismatch "not_installed"
summariseDependencyBlockers tested one kind and swept the rest into `absent`,
so a pure signer set summarised as "not installed"
dependencyIsPresent stays written by exclusion, and that is the one place it is
right: exactly one kind means "nothing under this name", so a kind added later
is by definition about a package that IS installed and should count as present
by default. The comment now says so.
The sidebar marker generalises from `_versionConflictOnly` to
`_presentButRejected` — the amber "!" means "everything needed is on disk and
this app rejects it", which is true of both mismatch kinds, while "mixed" keeps
the red cross because something really is absent. The marker's objectName
splits three ways so a UI test can tell the two amber states apart, which a
screenshot cannot. ModuleInstanceModel's badge gains "Signer conflict".
The signer wire rows in dependency_gate_test.cpp are VERBATIM payloads captured
from a real logoscore daemon over a real installed tree, like the rows beside
them, varying only the `signer` sidecar in the dependency's install directory.
RED (signer_mismatch unrecognised, and the summariser back to one kind):
Totals: 27 passed, 6 failed
a_signer_mismatch_blocks b.kind 0, expected 3
a_signer_mismatched_dependency_blocks_… b.kind 0, expected 3
a_signer_mismatch_says_publisher_not_version… detail was empty
the_wire_map_carries_the_signer_kind… kind "not_installed"
summary_of_only_signer_blockers_is_signer summary "absent"
summary_of_a_signer_and_an_absent_blocker… summary "absent"
GREEN, every check individually (nix build --print-out-paths; empty = FAILED):
unit-tests /nix/store/kdml49yg3pcjazdynnq29311wvk7s03d-logos-basecamp-unit-tests-0.0.0
qml-tests /nix/store/k5gmfqwa749nbipam0w9sfdq8cnrdraj-logos-basecamp-qml-tests-0.0.0
smoke-test /nix/store/qhilqrrmlxgi1r6rkk3f2xdhzad1khbs-logos-basecamp-smoke-test
integration-test /nix/store/rda92q559abgp57y5nqn5db1n0p9zwjd-logos-basecamp-integration-test
sandbox-test /nix/store/ip1flrwh4sf05jn747rj9fgrfn8zk7h8-logos-basecamp-sandbox-test-0.0.0
shutdown-test /nix/store/q9a0z0d0c83kl3z17r1d3pps6qp1fgs0-logos-basecamp-shutdown-test
host-services-test /nix/store/9szcjfih4hvc40wvlsihf4yy2l7616gc-logos-basecamp-host-services-test
symbol-gate /nix/store/pbflp7xdnf5py676ii0mwqi0xpkdfg1c-logos-basecamp-symbol-gate
symbol-gate-negative /nix/store/v5vmswffkfq82qhnl9z9q17zz17smbp9-logos-basecamp-symbol-gate-negative
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* refactor(deps): follow observedSigner to signerDid, and say what actually failed
logos-package-manager stopped recording who it verified at install and started
carrying the package's own manifest.sig into the install tree. The row key that
reaches this header changed name because it changed meaning, and the message
built from it was describing the old one.
`observedSigner` was the DID a signature had been VERIFIED against by the
installer. `signerDid` is what the installed signature says about itself, once
checked against the key its own DID carries. Nothing outside the document
corroborates it, so "found <did>" overstated it: it read as an established
publisher when it is the package's own claim, backed by a real key but not by
anything that says which key is the right one.
The detail line now says what failed:
signed by a different key; requires <pin>, signed by <did>
not signed by the required key; requires <pin> (nothing usable installed)
signed by a different key (neither DID available)
And a note this header needs to carry, because the shortcut is inviting and
unsound: do NOT re-derive the verdict by comparing `signerDid` to
`requiredSigner`. A signature document supplies both a DID and a signature, so
it can always be made to agree with itself; that comparison accepts somebody
else's genuine signature relabelled to name the pinned DID. The scanner decides
by verifying the installed signature under the PIN's key, which is why a
signer_mismatch row legitimately carries a signerDid that differs from
requiredSigner.
The dialog headline is unchanged: "published by a different signer" is the
right register for a user, and the mechanism belongs on the row.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(deps): re-capture the signer rows against real signatures, and say what a satisfied pin looks like
These rows are documented as verbatim wire payloads, and they were — of a rig
that no longer exists. They were captured by varying a `signer` sidecar, which
logos-package-manager has deleted; and the DID they pinned,
did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5In0, decodes to
{"kty":"OKP","crv":"Ed25519"} — no `x` member, so NO KEY AT ALL.
Against the sidecar that string was only ever COMPARED, so a keyless DID worked
fine. Against a signature it is an UNPARSEABLE PIN, which the library also
reports as signer_mismatch (fail-closed, with a warning naming the depending
manifest). So this suite would have stayed green while every signer row
documented the wrong cause: "this pin cannot be parsed" wearing the label
"a different key signed it".
Re-captured through the real stack — a real logoscore daemon, package_manager
built against the branch, depsvc INSTALLED FROM A REALLY-SIGNED .lgx so the
manifest.sig in its install directory is the one `lgx sign` produced. Nothing
is hand-planted; the only thing that varies is the `signer` pin in the
depending manifest, which is a developer declaration and is meant to vary. Both
DIDs are now real keypairs, and the mismatch row is a package really signed by
one key against a pin naming another.
Adds the row that was missing: a SATISFIED pin. It carries a signerDid, because
that is a property of the package rather than of the edge, and a gate that read
"signer information is present" as a signal in itself would refuse every
correctly-signed dependency in the fleet. Proven by mutation.
Also proven by mutation, and the reason NO comparison guard is added here:
replacing the status check with `signerDid != requiredSigner` — the inviting
shortcut, and the unsound one — turns a_signer_that_cannot_be_checked_does_not_block
red, because a signer_unknown row has a pin and no signerDid. The existing
suite already holds that line; the gate needs no new defence, it needs to keep
deciding from `status`.
The dialog now says what is actually known. "Published by a different signer"
reported a record the installer had written and could be no better than that
record. The scanner now extracts the key from the DID the module itself names
and checks the installed signature against it, so the claim is "not signed by
the key it requires" — which no relabelling on the package side can change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(deps): cut this PR's comments back to what a reader needs
608 added comment lines -> 351. Comments only; no code line moved or changed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* chore(deps): relock onto the merged package-manager chain
Takes logos-package-manager-module 5feeb67 (#64) and logos-package-manager
1218d74 (#38), so the gate this PR adds is no longer inert.
Also adds logos-package-manager-ui.inputs.package_manager.follows: without it
the UI brought its own package_manager and the closure carried two, with the
UI that drives installs on the one that has no VersionMismatch. Same shape as
the package_downloader follows in #360.
Verified in the artifact, not the lock: the shipped
modules/package_manager/libpackage_manager_lib.so carries version_mismatch,
signer_mismatch and dependencyConstraints, and is md5-identical to the
relocked lib output.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(deps): drive every dependency-gate verdict against the real binary
Adds basecamp-dependency-gate.test.yaml: one launch covering all five —
satisfied admits (exact and range), signer-satisfied admits, signer-unknown
admits, absent blocks, version blocks, signer blocks — each asserting its own
message, not just that something was refused.
Fixtures are real: two Ed25519 keys, both anchored, so the signer refusal is
identity and not trust. The spec fails if either DID carries no `x` member,
and if the app ever logs an unparseable pin — a keyless pin reports
signer_mismatch too, so without that check the suite stays green documenting
the wrong cause.
Also fixes a regression this PR introduced: an absent dependency with no
declared range added "— not installed" to its row, which broke
basecamp-missing-deps ("• demo_core_module" is an exact match) and changed the
text for every bare dependency in the fleet. The dialog heading already says
it; the detail is now empty unless there is a range to name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(deps): one package_downloader in the closure too, not two
Folds in #360, which is closed. Same defect as the package_manager follows
directly above: logos-package-manager-ui declares neither, so the closure
carried two logos-package-downloader revisions with the UI that drives
installs on the older one.
That one matters because lgpd's resolver is the only component in the stack
that evaluates a version range or a signer pin at all. After: downloader
b6624a3, carrying both the empty-signer-pin fix and the signer binding that
never checked the signature.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(deps): one liblgx in the closure, not two
|
||
|
Dario Gabriel Lipicar
|
7851bf9f46 |
feat(host): per-plugin identities, an opt-in access policy, and the source split
Each loaded plugin -- including pure-QML ones -- gets its own LogosAPI identity rather than sharing the host's, so a plugin's calls are attributable and can be refused independently. The host-services grant is wired through to capability_module, and its trust root is guarded on an OUTCOME rather than a log line. Inter-module access policy stays OFF by default: enforce mode's derived deny-by-default gates every ui_qml app's calls to its own backend module, because UI plugins load out-of-process and are not tracked as dependents in the core ModuleRegistry. Operators opt in per launch with --access-policy enforce or LOGOS_ACCESS_POLICY. Takes the Qt host runtime from logos-plugin-qt rather than logos-qt-sdk, which keeps only the Qt<->lp seam headers, and moves logos-protocol onto the rev that split host needs. On Windows logos_core must come LAST on the link line: GNU ld resolves an archive left to right, so the view runtime's references have to be undefined already when it reaches the import library. Separates the two source trees -- app/ is the host, src/ is the UI shell -- and brings the CI onto setup-nix-cache-action. Merges master. |