Loading
Commits on Source 27
-
Tedla Brandsema authored
-
Tedla Brandsema authored
-
Ian Chechin authoredA tag push now starts a pipeline with one job, attest, on a GitLab-hosted runner. It first checks the job's ID token (push trigger, GitLab-hosted runner, this project, the tag, the commit) so that nothing is signed that verification would reject. It then checks that the tag names the commit and that vendor.json matches go.mod and the committed lib/ and vec/, downloads the module from gitlab.com and from proxy.golang.org with sum.golang.org, each into an empty scratch module and cache with none of the runner's Go or git settings, and writes provenance.json only if both downloads agree and the direct one came from that commit. cosign signs it keyless with the pipeline's GitLab identity; attestgen -verify checks the signature and the certificate claims cosign has no GitLab flags for (commit, ref, project ID, push trigger, GitLab-hosted runner); attestgen -publish stores the document and bundle in the generic package registry and links them from the GitLab release, never overwriting either. The job cannot stop a release, which is public once the tag is; it can only refuse to sign. VERIFYING.md says what a verified document proves, what it does not, and how to check one with attestgen or by hand.
-
Ian Chechin authored
make vendor-check deletes every file vendor.json covers, runs the steps it shares with make vendor without the cross-builds, stamps again, and fails unless those files and vendor.json come out as committed. vendor.json may differ only in the Go release it records: the document carries both that and the Go that reproduced the files. The attest job clones the libsqlite3 and libsqlite_vec commits vendor.json names (attestgen -siblings) and runs it before observing or signing, so the stamp is something the pipeline reproduced rather than took on trust. make vendor runs the same commands as before; the shared ones are canned recipes now. The job's image is pinned by digest, since it holds the identity cosign signs with: golang:1.27.1, the toolchain vendor.json records.
-
Ian Chechin authored
-
Ian Chechin authored
# Conflicts: # CHANGELOG.md
-
Ian Chechin authored
-
-
-
cznic authoredconn.go, driver.go: add opt-in time format without monotonic readings (#259) Closes #259 See merge request !142 Co-Authored-By:
Claude Opus 5.5 <noreply@anthropic.com>
-
cznic authored
Merge request !142 adds a _time_format value, a new feature, so the pending section is a minor bump on v1.60.1. The number and the date are the maintainer's call at tag time, per HACKING.md. Co-Authored-By:
-
Ian Chechin authored
# Conflicts: # CHANGELOG.md
-
Ian Chechin authored
-
Ian Chechin authored
The direct download's origin is the repository URL as the go-import tag gives it. modernc.org's tag names https://gitlab.com/cznic/sqlite, but GitLab's own tag for a gitlab.com path adds .git, so -observe refused every project reached without a vanity path, such as a test project for rehearsing the job. Both forms name the same repository; anything else is still refused.
-
-
cznic authored
go mod download -json exits 1 with each failing module's error in its JSON object on stdout and nothing on stderr, so licgen reported only "exit status 1" after the full list of requested modules. Decode the output on failure and print one line per module error, then stderr if there is any, and the requested modules only when both are empty. Co-Authored-By: -
cznic authored
sqlite: expose connection authorizer Resolves #256 See merge request !139 Co-Authored-By:
-
cznic authored
Close removed the authorizer's map entry but left the three hook maps alone, so a closed connection that had registered a hook kept its entry, keyed by a handle value a later connection can reuse. Remove them before the handle is freed, as the authorizer does, and test it. Co-Authored-By: -
Ian Chechin authored
tx, conn: wait for a shared-cache lock in BeginTx, Commit and Rollback, and end such a wait with the context tx.exec ran BEGIN, COMMIT and ROLLBACK through sqlite3_exec, which skips the unlock-notify wait conn.step and conn.prepareV2 do on SQLITE_LOCKED_SHAREDCACHE, so with cache=shared BeginTx failed at once while ExecContext("BEGIN IMMEDIATE") waited. It now prepares and steps its statement like any other, and still reports a statement that ran as a success when the context is done just after, as before. The wait itself ignored the context. interrupt now wakes it, a context done before the wait began is caught through the call's Done channel that interruptOnDone records on the connection, and the woken call cancels its unlock-notify callback before freeing the mutex. Preparing a statement now watches the context as well. Updates #192. -
Ian Chechin authored
As suggested in the review of !143: the connection records the context of the call in progress, set and restored by interruptOnDone and newStmtContext, and retry watches it with context.AfterFunc only while it waits, returning ctx.Err() itself. A context done just before the wait returned "interrupted: not an error (9)" rather than its error, and every prepare with a cancellable context paid for a watcher goroutine; neither happens now. interrupt no longer wakes the wait. PrepareContext and BeginTx with a context already done return its error. COMMIT and ROLLBACK also wait while another connection holds the schema lock, since preparing them checks it; the CHANGELOG says so.
-
cznic authored
tx, conn: wait for a shared-cache lock in BeginTx, Commit and Rollback, and end such a wait with the context Updates #192 See merge request !143 Co-Authored-By:
-
Chris Gianelloni authored
Signed-off-by:Chris Gianelloni <wolf31o2@blinklabs.io>
-
cznic authored
fix: preserve cancellation before SQLite execution See https://github.com/modernc-org/sqlite/pull/9 Co-Authored-By:
-
cznic authored
The progress handler that keeps a cancellation in effect before a statement's first step looked its flag up in a map behind a lock all connections share, written twice per call and read on every callback, so connections running long statements in parallel contended for it: 37% slower than before with 24 goroutines. Give each connection its own flag, stored in a sync.Map on the connection's first call with a context and removed by Close, so the callback's lookup takes no lock; test that a cancellation does not carry over to the next call and that Close forgets the flag. See https://github.com/modernc-org/sqlite/pull/9 Co-Authored-By:
-
cznic authored
See https://github.com/modernc-org/sqlite/pull/9 Co-Authored-By:
-
cznic authored
lib/ is re-vendored from modernc.org/libsqlite3 v1.15.2 (SQLite 3.54.1, ccgo v4.37.0) and vec/ from modernc.org/libsqlite_vec v0.7.0; sqlite-vec stays v0.1.9. go.mod pins modernc.org/libc v1.79.0, golang.org/x/sys v0.49.0 and the current pprof; the indirect requirements follow libc. vendor.json is stamped with the two sibling commits under go1.27.2. Regenerate LICENSE-3RD-PARTY.md, SBOM.md, sbom.cdx.json and sbom.spdx.json, update the SQLite version in doc.go's platform table and in CLAUDE.md, and add the CHANGELOG bullet to the pending v1.61.0 section, re-dated to today. Co-Authored-By: -
cznic authored
SQLite's default busy callback, installed by PRAGMA busy_timeout, sleeps through its retry schedule and never looks at the interrupt flag, so a statement waiting for a lock kept waiting after its context was done and returned the context's error only when the timeout ran out: with busy_timeout 2000 a write with a 100 ms deadline took 2 s. At the start of each call with a context, replace that callback, when it is installed, with the driver's own copy of it: the same delays and the same bound, but the sleep ends and the handler gives up once the context of the call in progress is done. PRAGMA busy_timeout installs the default callback again whenever it runs, so the check repeats per call, at the cost of one pointer comparison when nothing changed. sqlite3_busy_handler clears the timeout the PRAGMA reports, so it is kept. A wait ended this way fails with SQLITE_BUSY inside SQLite; the handler sets the connection's canceled flag so exec, query and a transaction's BEGIN, COMMIT and ROLLBACK map that to the context's error without depending on the watcher goroutine having run, and PrepareContext does the same when preparing failed with the context done. Calls without a deadline, or whose context is still live, behave as before. Resolves #262, thanks SirLouen for the report and the reproducer. Co-Authored-By: