0.1.0a8 — the dependency signal, and what it refuses to claim - #19
Closed
FlagshipDev wants to merge 1 commit into
Closed
0.1.0a8 — the dependency signal, and what it refuses to claim#19FlagshipDev wants to merge 1 commit into
FlagshipDev wants to merge 1 commit into
Conversation
What this release makes reachable that was not before. ## A second signal Hullwork verifies which of the things your tools claim are actually true. Until now it did that for one signal: a production error becomes a failing test, then a fix, then a draft pull request. This release adds the second. `hullwork deps --checkout .` reads the versions your lock files pin, asks OSV what is published against those exact versions, and prints what came back. No credential of any kind — no forge, no model, no database. The one host it contacts takes no key and no account. `--verify` then answers the question nobody else does: it applies each published fix in a sandbox and runs **your own test suite** against it. The verdict is ranked by what it asks of a person — fix your suite first, needs work, blocked, ready to take — worst first. `--open` opens a draft pull request for the ones that passed, one per package, never a batch, and never anything else. `--fix` asks an agent to change your code so an upgrade that breaks your suite fits, without being allowed to touch your dependency files. ## What it refuses to claim, which is most of the point The claim on a verified upgrade is exact: *your suite passed before this change and passes after it.* Never "safe", never "this fixes the vulnerability". A suite that does not exercise the dependency stays green without ever loading the new version, and the pull request says so. And it says **no** more often than yes. Measured on four real third-party repositories before this release: one clean verdict. The rest could not be measured at all — a suite that reaches the network a sandbox denies by design, a pin in a file the image does not install from, an image the project brings ready-made. Each is reported as what it is, with the reason and what to change, rather than verified wrongly. ## `hullwork features` New, and it answers before you have decided anything: feature by feature, whether this can serve your project, which requirement is missing when it cannot, and **what it will not do even when it can**. No credential, no container, no socket, nothing written. ## The Sentry webhook route Enabled. Authenticated by the token in its URL — the same credential a GlitchTip route has, checked the same way, because GlitchTip cannot sign its webhooks at all. **Sentry's signature is not verified**, and `SECURITY.md` says once, for both providers, what that does not cover: anyone who obtains the URL can post to it. Treat it as a secret; `hullwork projects rotate-secret` replaces it. ## A number about itself `hullwork status` and the page now report what arrived and how much of it left a person's desk with evidence attached — including a row for what Hullwork **put on** that desk rather than took off it. That row is the one this product can be embarrassed by, and it is printed above the others. ## One new manifest field `autofix.open_upgrades`, false by default. Opening a verified upgrade as a pull request is the first thing a project can refuse while Hullwork is able to do it: having a capability is not the same as having agreed to it. Every other default in that block already refuses. Note that a manifest carrying this field is rejected by earlier releases, which forbid unknown fields by design. A project that does not set it is unaffected. ## Fixed - A verified-green verdict could be produced for a version that was never installed — twice, by two different routes: a pin in a file outside `runtime.dependencies`, and `install: none`, which is the default. Both are now refused before a container is built, with the reason and the remedy. - A fix phase that **created** test configuration where a project had none could switch the suite off and publish with the mechanism inside its own diff. The guard against editing that configuration had never covered inventing it. - `deps --verify` did not hand the source to the image build, so any project whose installer reads its own files could not be verified at all. - Requirements files outside a root `requirements.txt` were not read: `requirements/prod.txt`, `requirements-dev.txt` and their shape were invisible, and the report said nothing about the gap. - Agent runs discovered a missing model credential, and a missing gateway image, at the most expensive possible moment. Both are answered in under a second now. ## Still true, and worth reading before relying on any of it Nobody outside this project has installed Hullwork. Every measurement in this release was taken by the people who wrote it. `docs/status.md` is the honest scope and it changes weekly. Signed-off-by: Javier Miralles Rancaño <68760931+FlagshipDev@users.noreply.github.com>
| assert item.lane_reason and "payment" in item.lane_reason, ( | ||
| f"the culprit did not reach triage; the lane defaulted: {item.lane_reason!r}" | ||
| ) | ||
| assert item.permalink and "sentry.io" in item.permalink |
|
|
||
| assert desk.left_with_evidence == 1, "only the one with a verdict behind it" | ||
| assert desk.arrived == 2 | ||
| del theirs |
| import logging | ||
| import shutil | ||
| import tempfile | ||
| from collections.abc import Callable, Sequence |
Contributor
Author
|
Reemplazado por #20: CodeQL puso tres alertas sobre código de este PR y las tres están resueltas allí — una era real ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this release makes reachable that was not before.
A second signal
Hullwork verifies which of the things your tools claim are actually true. Until now it did that for
one signal: a production error becomes a failing test, then a fix, then a draft pull request. This
release adds the second.
hullwork deps --checkout .reads the versions your lock files pin, asks OSV what is publishedagainst those exact versions, and prints what came back. No credential of any kind — no forge, no
model, no database. The one host it contacts takes no key and no account.
--verifythen answers the question nobody else does: it applies each published fix in a sandboxand runs your own test suite against it. The verdict is ranked by what it asks of a person —
fix your suite first, needs work, blocked, ready to take — worst first.
--openopens a draft pull request for the ones that passed, one per package, never a batch, andnever anything else.
--fixasks an agent to change your code so an upgrade that breaks your suitefits, without being allowed to touch your dependency files.
What it refuses to claim, which is most of the point
The claim on a verified upgrade is exact: your suite passed before this change and passes after
it. Never "safe", never "this fixes the vulnerability". A suite that does not exercise the
dependency stays green without ever loading the new version, and the pull request says so.
And it says no more often than yes. Measured on four real third-party repositories before this
release: one clean verdict. The rest could not be measured at all — a suite that reaches the network
a sandbox denies by design, a pin in a file the image does not install from, an image the project
brings ready-made. Each is reported as what it is, with the reason and what to change, rather than
verified wrongly.
hullwork featuresNew, and it answers before you have decided anything: feature by feature, whether this can serve
your project, which requirement is missing when it cannot, and what it will not do even when it
can. No credential, no container, no socket, nothing written.
The Sentry webhook route
Enabled. Authenticated by the token in its URL — the same credential a GlitchTip route has, checked
the same way, because GlitchTip cannot sign its webhooks at all. Sentry's signature is not
verified, and
SECURITY.mdsays once, for both providers, what that does not cover: anyone whoobtains the URL can post to it. Treat it as a secret;
hullwork projects rotate-secretreplaces it.A number about itself
hullwork statusand the page now report what arrived and how much of it left a person's desk withevidence attached — including a row for what Hullwork put on that desk rather than took off it.
That row is the one this product can be embarrassed by, and it is printed above the others.
One new manifest field
autofix.open_upgrades, false by default. Opening a verified upgrade as a pull request is the firstthing a project can refuse while Hullwork is able to do it: having a capability is not the same as
having agreed to it. Every other default in that block already refuses.
Note that a manifest carrying this field is rejected by earlier releases, which forbid unknown
fields by design. A project that does not set it is unaffected.
Fixed
different routes: a pin in a file outside
runtime.dependencies, andinstall: none, which isthe default. Both are now refused before a container is built, with the reason and the remedy.
off and publish with the mechanism inside its own diff. The guard against editing that
configuration had never covered inventing it.
deps --verifydid not hand the source to the image build, so any project whose installer readsits own files could not be verified at all.
requirements.txtwere not read:requirements/prod.txt,requirements-dev.txtand their shape were invisible, and the report said nothing about the gap.expensive possible moment. Both are answered in under a second now.
Still true, and worth reading before relying on any of it
Nobody outside this project has installed Hullwork. Every measurement in this release was taken by
the people who wrote it.
docs/status.mdis the honest scope and it changes weekly.Signed-off-by: Javier Miralles Rancaño 68760931+FlagshipDev@users.noreply.github.com