v2.1.0 fails to cross-compile for all five linux targets in the xgo
container (C.RTLD_NEXT unresolvable without _GNU_SOURCE), so the
v2.5.3 release shipped darwin pam plugins only. v1.2.0 cross-compiles
cleanly with an identical API surface for this plugin.
Claude-Session: https://claude.ai/code/session_014L5EoqGWsuZWr8fCVM6izP
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* build(deps): update core deps and align otel stack on 1.46.0
golang.org/x/crypto 0.18.0 -> 0.55.0
google.golang.org/grpc 1.59.0 -> 1.83.1
google.golang.org/protobuf 1.31.0 -> 1.36.12
golang.org/x/net 0.17.0 -> 0.58.0
github.com/gorilla/websocket 1.5.0 -> 1.5.3
The otel stack (core, sdk, trace, metric, all four exporters) plus
contrib/propagators/jaeger now sit together on 1.46.0. grpc 1.83.1
sets the floor for sdk and protobuf; the jaeger propagator's newest
release requires otel core 1.46.0, which in turn lifts crypto and net
above the versions originally targeted.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014L5EoqGWsuZWr8fCVM6izP
* build: respect plugin go.mod versions when pulling dependencies
pull-plugin-dependencies now emits path@version from each plugin
manifest instead of the bare module path, so a dependency added to
the core module arrives at the version the plugin declares.
Pairs with the guard fix in the same line: the substitution was
redirected with &> so it was always empty and never skipped a module
already present. With the guard working, pinned versions only apply
to modules being added, never downgrading what the core already has.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014L5EoqGWsuZWr8fCVM6izP
* chore: bump plugin submodules to updated dependencies
go-sqlite3 1.14.52, mysql 1.10.1, lib/pq 1.12.3, msteinert/pam v2.1.0.
The pam plugin moves to the v2 major (import path only; the API it
uses is unchanged) and its logr and glauth/ldap entries now match the
core module. Corrects the module path in the mysql, postgres and pam
manifests, which all declared glauth-sqlite.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014L5EoqGWsuZWr8fCVM6izP
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The twelve battery cases were near-identical closures: the same ldapsearch
argument prefix, the same got/want compare, the same t.Fatalf shape. Collapse
them into table rows holding only what differs (args, want, message) and run
them through one loop.
Shared argument builders (bind/svc/otp) remove the repeated
-LLL/-H/-D/-w/-x prefix; the two getSecond cases set a line field instead of
duplicating the assertion block.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GdP1CLtdwAtAeXuS4hph6g
Make output go to test logger so that go test -v will give useful output on a failure
Remove dependence on `oathtool`
Remove dependence on `ls`
Wait on killing the running glauth instance so subsequent tests don't fail
Wait for glauth to provide authentication error instead of waiting an arbitrary amount of time
* fix: reject disabled users on all backends in Bind
A user with disabled = true could still bind on the config backend, since
configHandler.FindUser and LDAPOpsHelper.Bind never checked Disabled while the
SQL backends drop such users at lookup. Enforce it in Bind so every backend
behaves the same.
* fix: use configHandler.Bind rather than helper.Bind in test harness
---------
Co-authored-by: kanywst <niwatakuma@icloud.com>
A user with disabled = true could still bind on the config backend, since
configHandler.FindUser and LDAPOpsHelper.Bind never checked Disabled while the
SQL backends drop such users at lookup. Enforce it in Bind so every backend
behaves the same.
* Initial support for RISC-V
Add build for riscv64/linux; not available for darwin and windows.
* chore: update readme
---------
Co-authored-by: E Shattow <eshattow@users.noreply.github.com>
Chris F Ravenscroft