Good First Issues in Go

lima/cmd/limactl-menu/main.go Lines 185 to 187 in f6158fe if in.Protected { prot = " " + tview.Escape("[LOCKED]") } [LOCKED] sounds like as if it were flock-ed. Should be shown as [PROTECTED] or maybe 🔒

Describe the bug Hi KubeStellar Maintainers, We noticed two behaviours in the CSIDriver kind that we believe violate KubeStellar's own standards (the documented promise that the work agent runs "a reconciler to ensure the actual state matches the desired state"). After downsyncing a CSIDriver object to the edges, we noticed the following: 1. Edge drift is not reconciled. Similar to the bugs we reported for Service (#4006) and Pod (#4007), the agent never notices or reverts third-party mutations of the object on the edge. A CSIDriver's mutable config fields (fsGroupPolicy, podInfoOnMount, storageCapacity, tokenRequests, requiresRepublish, seLinuxMount) can all be changed on the edge and stay changed forever, while the ManifestWork reports Applied=True / Available=True. The hub is oblivious to the actual configuration running on the edge. 2. In-place updates are delivered as delete + create. We would refer to this as a misoperation. An update we make on the WDS as a legal in-place update

Describe the bug Describe the bug Hi KubeStellar Maintainers, We noticed another behaviour we believe to be a bug, similar in spirit to #4006 (Service edge drift): it also breaks the documented promise that the work agent runs "a reconciler to ensure the actual state matches the desired state" and that KubeStellar "continually strives to achieve what you are currently asking it to do" — this time for Pods, and in both directions. Pods are mostly immutable; however, there are a few fields Kubernetes allows updating in place: the image of containers and init containers, spec.activeDeadlineSeconds, and additions to spec.tolerations. We noticed that when a downsynced Pod is updated on the WDS (for example, a new image), the hub accepts the update, but the edge never receives it. The Pod on every edge keeps running the old image forever, while the ManifestWork stays Applied=True / Available=True. The drift also occurs the other way. When we edit the image of the Pod directly on the edge,

Describe the bug Hi KubeStellar Maintainers, We noticed a behaviour we believe to be a bug and we want to hear what you think. Our bug report is hinged on some claims we noticed KubeStellar makes in its documentation: The work agent runs "a reconciler to ensure the actual state matches the desired state", and the user guide says KubeStellar "continually strives to achieve what you are currently asking it to do". We found that for a Service, KubeStellar does not reconcile edge drift on the fields it delivers (it does this for a Deployment and some other kinds). By edge drift we mean a case where a third party updates an object managed by the hub on the edge. The expectation is for the hub to revert the edge back to the known desired state. We downsync a Service from the WDS to the edges, then change one of its delivered spec fields directly on the edge, acting as a third party drifting the workload. For example, on an ExternalName Service we change spec.externalName, silently repointing

Describe the bug Hi KubeStellar Maintainers, We came across another behaviour we think is an issue with how KubeStellar transforms a Service before sending it out to the edges. For a Service, when we set externalTrafficPolicy to Local and the Service type to LoadBalancer, the apiserver auto-allocates spec.healthCheckNodePort (a nodePort that kube-proxy serves health checks on, so the cloud LB can tell which nodes actually have local endpoints). Now when KubeStellar sends this Service to the edges, it strips externalTrafficPolicy (per its built-in Service transform), however it leaves the healthCheckNodePort field in and sends it to the edge. Upon arrival, the edge apiserver validates the object and finds it illegal, as a healthCheckNodePort may only exist if type is LoadBalancer and externalTrafficPolicy is Local. The policy is missing, hence the object is rejected by Kubernetes at the edge: Failed to apply manifest: Service "..." is invalid: spec.healthCheckNodePort: Invalid value: 30

Description In Gateway Namespace Mode with watch.type: Namespaces, the configuration that the Gateway Namespace Mode task shows (L107–120), the controller's cache config holds two ByObject entries for six types, and the entry that takes effect is picked at random on each start. Depending on the pick, the controller either never becomes Ready or can't see its own namespace's Secrets and ConfigMaps. The docs say the controller namespace "is always included in addition to the configured watched namespaces" (same page, L98). #9100 implemented that; the duplicate entries undo it at random. Cause mgrOpts.Cache.ByObject is a map[client.Object]cache.ByObject, so it is keyed by pointer, and each &T{} adds a new key rather than replacing the existing one. internal/provider/kubernetes/kubernetes.go at v1.9.2: L171–196 first fills the map with &corev1.Secret{}, &corev1.ConfigMap{}, &corev1.Service{} and &discoveryv1.EndpointSlice{}, among others; in Gateway Namespace Mode, L219–222 add &co

Problem The API uses "dangling" without defining it. The two image stores disagree about images that have a repo@digest reference but no tag, such as docker pull nginx@sha256:.... Legacy (graphdriver) store: RepoTags is empty, and the reference is in RepoDigests. GET /images/json with dangling=true returns these images. dangling=false also returns them, because it only excludes images with no tags and no digests. docker image prune deletes them if they're unused, because it only keeps images with a tag. containerd store: Only images named moby-dangling@<digest> are dangling. Images pulled by digest aren't returned by dangling=true and aren't pruned. RepoTags contains nginx@sha256:..., and so does RepoDigests. The swagger lists dangling=true for image list without a definition. Image prune says "unused and untagged images".

Description When a dependency in [[packages.dependencies]] of pylock.toml (PEP 751) is specified by name only, e.g. { name = "beta" }, Trivy silently drops it from the dependency graph. As a result, the SBOM (CycloneDX dependsOn, SPDX relationships) is incomplete, and the package shows up directly under pylock.toml instead of under its parent. Vulnerability detection is not affected. Reproduced on v0.75.0 and main: mkdir pylock-name-only && cd pylock-name-only cat > pylock.toml <<'EOF' lock-version = "1.0" created-by = "minimal-reproducer" [[packages]] name = "alpha" version = "1.0.0" dependencies = [{ name = "beta" }] [[packages]] name = "beta" version = "2.0.0" EOF trivy fs --format cyclonedx --output bom.json . jq -c '.dependencies[]' bom.json [email protected] is expected to depend on [email protected], but its dependsOn is empty. If the selector is changed to { name = "beta", version = "2.0.0" }, the relationship appears. Such lock files are produced by real tools, e.g. Pex (see test_issue_2

examples/vscode-sandbox/README.md says to install ModHeader to send X-Sandbox-ID and X-Sandbox-Port. ModHeader was removed from the Chrome Web Store and Edge Add-ons in July 2026 (https://thehackernews.com/2026/07/google-and-microsoft-pull-modheader.html), so anyone following the guide now can't install it. The approach itself still works with any extension that sets request headers through Chrome's declarativeNetRequest, and that includes the WebSocket handshake, which matters here since the code-server terminal runs over one (the thing #1412 says page JS can't do). I checked it with a local WebSocket server: both headers arrive on the upgrade request. Options: Requestly, Modify Header Value, or Headerwise (free, MIT; disclosure: I wrote it). It might be simplest for the README to say "a browser extension that can set request headers, e.g. ..." and keep the two headers as they are, limited to the router's host so they don't go to every site. Happy to send a PR with whatever wording yo

What is the problem you're trying to solve Volcano release-1.17 needs to support Kubernetes v1.37. Upgrade the Kubernetes dependencies to the corresponding v1.37.x-compatible versions and ensure Volcano works correctly on Kubernetes v1.37. Describe the solution you'd like Follow the Kubernetes adaptation guide to upgrade the dependencies and address compatibility changes: https://github.com/volcano-sh/volcano/blob/master/docs/design/adapt-k8s-todo.md Update Kubernetes dependencies in the main repository and the staging APIs module (staging/src/volcano.sh/apis/go.mod) to the versions corresponding to Kubernetes v1.37.x. Update Go and related build/code-generation tools as required by the target Kubernetes version, regenerate affected code, and fix API or scheduler compatibility changes. Run code-generation verification, unit tests, and E2E tests on Kubernetes v1.37; verify compatibility with the other Kubernetes versions supported by release-1.17. Update the Kubernetes compatibility do

The chat composer has two functions with identical cursor and token-boundary logic. Their only difference is the leading marker: ActiveSlash in internal/components/chat/slash.go: / ActiveQuestion in internal/components/chat/question.go: ? Extract their common logic into one private helper in the chat package. This is a small, behavior-preserving refactor suitable for a first contribution. It can be completed independently of any installer refactoring. Please leave a comment if you would like to work on it. Suggested implementation Add a helper such as: func activeLeadingToken(value string, cursor int, prefix byte) (query string, start, end int, ok bool) Have ActiveSlash and ActiveQuestion delegate to it with their respective markers. Keep both public functions and their return contracts unchanged. The helper belongs in chat; no repository-wide utility or new dependency is needed. Preserve these behaviors: Cursor positions are byte offsets and are clamped to the input bounds. The mar

The extension installer and self-updater duplicate checksum and archive-extraction helpers. Consolidate these implementations so future fixes only need to be made once. This issue covers both groups below. It is a behavior-preserving refactor and requires no new dependencies. Please leave a comment if you would like to work on it. 1. Release checksum helpers The extension installer and self-updater duplicate lookupChecksum and sha256File: internal/extension/install/install_archive.go internal/util/update/install.go Both implementations parse checksum-file entries, find an asset by filename, and calculate a file's SHA-256 digest. Move the shared implementation into the existing internal/util/githubrelease package and update both callers. Keep the public API small; separate lookup and hashing functions are sufficient if they make the callers clear. Preserve these behaviors: Checksum entries are split on whitespace, with the asset filename in the second field. Malformed entries are ign

Release Version / 软件版本 V0.4.35 Description / 缺陷描述 Steps to reproduce / 复现步骤 登录首页仪表盘提示404 Logs / 日志 Details # Paste logs here / 请在此粘贴日志 Miscellaneous / 其他 No response Contribution / 贡献代码 I am interested in contributing a PR for this! / 我乐意为此提交代码并发起 PR！

Describe the problem/challenge you have CI tests intermittently fail while downloading Go dependencies from proxy.golang.org, rather than because of test failures. Repeated downloads across test jobs increase exposure to transient proxy/network errors and require CI reruns. Example failure: Error: /home/runner/go/pkg/mod/google.golang.org/[email protected]/status/status.go:35:2: google.golang.org/[email protected]: read "https://proxy.golang.org/google.golang.org/genproto/@v/v0.0.0-20260319201613-d00831a3d3e7.zip": stream error: stream ID 1; INTERNAL_ERROR; received from peer Describe the solution you'd like Cache and reuse downloaded Go modules across CI tests, jobs, and subsequent workflow runs where compatible, reducing repeated downloads and reliance on the Go module proxy. Audit Go dependency caching in the relevant test workflows and ensure caches are restored before dependency downloads or test execution. Cache the actual Go module cache directory (go env

The theme kit release should refuse to publish a kit version that no released Gophenberg serves yet. Current state: the kit publish workflow checks only that the astro@ tag matches the package version. A server runs a theme only when it lists the theme's exact kit patch, and a fresh install picks up a new patch through its caret range. So a kit that reaches npm before any released server lists it breaks every theme rebuilt on it, and a pinned theme stops the server from starting. Today the order is kept by hand. Proposal: before npm publish, look through the released v* tags and stop unless one of them lists the kit version in internal/themehost/kit.go. Put the check in a Makefile target with a test, as make bump-kit has, and call it from the workflow. Trigger: the 0.15.1 kit release, where a server patch release had to ship first.

According to GUIDE.md: The "Configuration" table in your component's `README.md` is generated the same way as the Go code: from the `config:`/`exported_configs:` schema. But it does not generate docs if metadata.yaml file has only exported_config declared.

Summary Two release-notes items from #1546 are still open. Both need entries in MIGRATION_GUIDE.md before v3.0.0 GA. Requested changes remote.ClientBuilder.CredentialStore narrowed from credentials.Store to credentials.Getter (#1463). Add this under "Removed v3 development APIs", since the field was introduced in v3.0.0-rc.1. The LegacyReferenceParser transition. The entry should name the legacy ParseReference signature and the functions that still honour it (oras.Tag, oras.TagN). It should also say that this support is removed along with the deprecated registry.Reference type in a future major release. After that, such targets silently stop receiving scope hints. Closing #1546 These are the last unchecked items in #1546. The PR that resolves this issue should also close #1546 (e.g. Closes #1546 in the PR description).

Description: Allow configuring a CA certificate for TLS connections from the global rate limit service to Redis. RateLimitRedisSettings.tls currently only accepts a client certificate (certificateRef). When tls is set, Envoy Gateway sets REDIS_TLS=true on the rate limit deployment. envoyproxy/ratelimit then verifies the Redis server certificate against the system roots, unless REDIS_TLS_CACERT is set. Envoy Gateway has no way to set that variable. Managed Redis services that issue server certificates from a private CA can't be used as the backend: Google Cloud Memorystore with in-transit encryption: server certificates come from a Google-managed private CA, whose CA certificate is published per instance. Self-hosted Redis with an internal CA. The handshake fails with x509: certificate signed by unknown authority. A related detail: with tls: {} and no certificateRef, the rate limit container still gets a redis-certs volume mount at /redis-certs, but no redis-certs volume is added to t

I think this is the only place it's being done: kubernetes/test/e2e/apimachinery/health_handlers.go Lines 134 to 139 in cdb9495 if utilfeature.DefaultFeatureGate.Enabled(apiserverfeatures.WatchCacheInitializationPostStartHook) { storageReadinessCheck := "[+]poststarthook/storage-readiness ok" requiredHealthzChecks.Insert(storageReadinessCheck) requiredLivezChecks.Insert(storageReadinessCheck) requiredReadyzChecks.Insert(storageReadinessCheck) } We should probably make "k8s.io/apiserver/pkg/util/feature" a forbidden import in test/e2e and test/e2e_node, with an exemption for test/e2e/framework. /sig testing /kind bug /help

Goal By end of week, on a dev backend: containarium sessions terminate --user drops a user's open shells on every box they reach; containarium ssh rotate registers a new key with proof of possession and the old one keeps working through the overlap window; a cloud-enrolled backend forwards the authorization decision to the cloud. The OSS half B of the SSH live authorization design (#2515; architecture doc on PR #2514). Follows umbrella A (#2521). Gate: this sprint does not start until #2521's definition of done holds, with the #2520 e2e transcript linked there. Flow first: B optimizes a revocation path that A must first prove works. Public contribution welcome. Items labelled help wanted are buildable against generated stubs or a fake cloud; claim by commenting on the child issue. The spike (#2524) has no dependencies and can be picked up today. Phase 1 — make the flow work (this week) #2524 Spike: sshpiperd v1.6.1 partial-success into keyboard-interactive — unassigned, size:S (n

Part of the SSH live authorization design (#2515). Component 3 in docs/architecture/ssh-live-authorization.md (PR #2514). Blocked by the spike issue (see umbrella) and #2518. The cloud approval records and page (cloud half item 12) must exist for dev verification; unit-testable against a fake before then. What When Authorize returns APPROVAL_PENDING with an SSHDeviceApproval: Keyboard-interactive flow (if the spike says yes): return partial success; the challenge carries the instruction (Approve this device at <url>, code <code>) and one prompt; on answer or every poll_after, re-call Authorize with approval_id; ALLOW completes auth; APPROVAL_DENIED, expires_at, or 60 s cap → deny. Banner-only flow (if the spike says no): deny, with the URL and code in BannerCallback; the user approves and reconnects; the next connection is a cache hit or a fresh ALLOW. Certificate holders never enter this path. Approval identity is (user, fingerprint); the client address is recorded for audit only (

Part of the SSH live authorization design (#2515). The managed branch of component 4 in docs/architecture/ssh-live-authorization.md (PR #2514). Blocked by #2516 and #2517. The cloud RPC (cloud half item 10) must exist for the dev verification; unit-testable against a fake before then. What When the daemon is enrolled with a cloud, sshauthz.Decider forwards the request after the local-facts check instead of applying local policy. Local facts (jump account, orphan filter, collaborator row, box state) still run first and short-circuit with DENY NO_ACCESS; the cloud is never asked about a login the backend does not host. Forward AuthorizeSSHRequest unchanged over the existing host-bearer channel (internal/cloud/client.go, same auth context as Heartbeat), 2 s deadline. Return the cloud's response verbatim, including cache_ttl and approval. Cloud unreachable, deadline, or non-OK status → DENY UPSTREAM_UNAVAILABLE; the sentinel's grace rule (#2518) decides. No fallback to local policy. Mod

Part of the SSH live authorization design (#2515). The spike named in component 3 of docs/architecture/ssh-live-authorization.md (PR #2514). No dependencies; can start now. What Decide the vehicle for the device-approval prompt before the plugin path is scheduled. Using the real-sshpiperd harness in internal/sentinel/anondoor/integration_test.go, write a throwaway plugin whose PublicKeyCallback returns a partial-success (or whatever libplugin v1.6.1 offers) and whose KeyboardInteractiveCallback sends one instruction and one prompt, then completes auth. Try with a stock OpenSSH client: does the client see the instruction text, and does the session open after the answer? Record the outcome, the exact libplugin calls used, and any sshpiperd flags required, as a comment on this issue and a short note in the architecture doc. Done when A yes/no answer with a runnable test in the harness demonstrating it (kept as the integration test for the approval path if yes; kept as evidence if no).

Part of the SSH live authorization design (#2515). Component 6 in docs/architecture/ssh-live-authorization.md (PR #2514). Depends on the cloud challenge endpoint (cloud half item 11) for the live path; buildable and unit-testable against a fake server before it ships. What containarium ssh rotate [--name <device>] in internal/cmd/ssh.go: generate a new ed25519 keypair locally (internal/sshkey.Generate); POST /v1/user/ssh-keys:challenge → {challenge_id, nonce}; sign the nonce with the new private key; POST /v1/user/ssh-keys with {name, public_key, key_type, challenge_id, signature} under the user's bearer; the server verifies the signature before storing; rewrite ~/.containarium/ssh_config to the new key; keep the old private key file on disk; print the overlap window the server returned. Typed DTOs for the two endpoints next to the existing addSSHKeyReq, mirroring the cloud proto field-for-field (the existing pattern; see Deviations in the architecture doc). containarium login: a

Part of the SSH live authorization design (#2515). Component 5 in docs/architecture/ssh-live-authorization.md (PR #2514). Blocked by #2516 (the Assignment.kind field) and #2517 (the registry that maps a user to their jump accounts). What End every live SSH session a user holds on this backend, without deleting anything. CLI-first per CLAUDE.md. proto/containarium/v1/container.proto: rpc TerminateUserSessions(TerminateUserSessionsRequest{username}) returns (TerminateUserSessionsResponse{terminated_sessions, boxes_touched}), REST POST /v1/users/{username}/sessions:terminate; make proto. pkg/core/container.TerminateAccountSessions(containerName, account): the loginctl terminate-user + pkill -KILL -u sequence extracted from removeCollaboratorUser so both callers share it. Server: walk the user's owner box and every collaborator jump account (<owner>-container-<user>) → in-container kill + pkill -KILL -u on the host jump account. Nothing is deleted; authorized_keys untouched. containariu

Goal By end of week, on a dev backend behind a sentinel: a registered key logs in and the audit row names the user; the key is revoked; the next login is refused at the sentinel and an ssh_session_denied row records why. The OSS half A of the SSH live authorization design (#2515; design note and architecture doc on PR #2514, docs/architecture/ssh-live-authorization.md). Public contribution welcome. Every item here is buildable against generated stubs or the daemon's self-host mode; no cloud access needed. Items labelled help wanted are open for pickup; claim by commenting on the child issue. Why this is Phase 1 and not the cloud endpoint: the guarantee is "revocation ends access on the next connection". The sentinel plugin plus the daemon's local decider delivers that for self-host today and is the only code path the managed mode will also use. The cloud endpoint (private repo) codes to the contract in #2516 and can start as soon as it merges. Phase 1 — make the flow work (this week)

Part of the SSH live authorization design (#2515). Storage half of component 7 in docs/architecture/ssh-live-authorization.md (PR #2514). Blocked by the contract issue (see umbrella); otherwise independent of the plugin and decider. What internal/sentinel/sshsession: Record gains UserID, AuthzDecision, DenyReason, Enforced; phase denied; pb.go maps them to the new proto fields. internal/server/audit_server.go: a SSH_SESSION_PHASE_DENIED record stores action ssh_session_denied with the reason and user_id in the row detail; OPEN rows store user_id and the decision. Dedupe stays keyed on (session_id, phase); a DENIED record for a session id that later gets an OPEN (audit-only mode) is two rows, not a conflict. docs/SENTINEL-SSH-SESSION-AUDIT.md: document the new row type and fields. Done when Ingest tests: a DENIED record with each SSHDenyReason round-trips into an ssh_session_denied row; replaying the batch reports DUPLICATE and writes nothing. Shipper test: a JSONL line with the new

An import with an unknown field kind or page kind should explain the problem in the reader's language. Current state: with the admin in Spanish, open Field Groups, choose Import definitions and pick a file with a field of kind "sonnet". The dialog shows "content: invalid field kind" in English. A type with page kind "gallery" shows "content: invalid page kind" the same way. A Spanish message exists, but the server never sends the value and the allowed list it needs. An unknown status is bare too, though only a direct API call can send one. Proposal: field_kind_unknown, page_kind_unknown and status_unknown carry the refused value and the allowed values, as locale_unknown already does. A test checks each message fills. Trigger: a mutation test run showed these messages never fill.

A new field group should start on a real content type, or the form should say why it cannot yet. Current state: Open Field Groups while the content types are still loading, or after they fail to load. Press Add New Group, type a title and press Create. The form closes and a red notice says "The rule on content_type names nothing to match." The admin never saw a rule, so they cannot fix it. The form sent a content_type rule with an empty value, and the server refused it. Proposal: Keep Create disabled until the content types have loaded. If they fail to load, say so inside the form. Trigger: A mutation test run, confirmed by tests that stall or fail the content types read.

The import screen should always show and apply the definitions file the admin picked last. Current state: An admin opens Import definitions and picks a file. Before its plan shows, they pick a second file. The second plan shows first. Then the first file's plan replaces it. Clicking Apply sends the first file to the site. The admin thinks the second file landed. Proposal: Only the latest pick may set the plan and the file to apply. A late answer for an earlier pick is dropped. Moving the success and error handlers from useMutation onto read.mutate does this. A test makes the first of two picks answer late and checks the second plan shows and gets applied. Trigger: A mutation test run, confirmed by a probe test.