net-snmp 3.26.2 → 3.26.3

package/.claude/skills/propose-action/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: propose-action
+description: Review a GitHub issue or PR by number and propose a concrete action plan — either a reasoned recommendation not to action it, or the code and test changes required to action it. Use when the user asks to "propose an action" for an issue/PR, "look at issue/PR #N", or invokes /propose-action with an issue or PR number. Ends by asking whether to proceed, proceed with modifications, or abandon.
+---
+
+# Propose Action
+
+## When to use
+
+- The user asks to review a GitHub issue or PR and recommend what to do about it.
+- The user invokes `/propose-action <number>`.
+
+This skill **plans only** for steps 1–5 — it does not edit code, run tests, commit, push, or comment on the issue/PR during the proposal phase. Implementation happens after the user approves the plan in step 5's closing question. Once the user has approved and you have carried out the agreed actions, step 6 produces a ready-to-paste reply to the issue/PR aligned with what was actually done — but never posts it.
+
+## Arguments
+
+- `<number>` (required) — the GitHub issue or PR number. Bare integer, or `#N`, or a full GitHub URL are all acceptable forms.
+
+If the number is missing, ambiguous, or does not resolve to an issue/PR in the current repository, stop and ask the user to clarify.
+
+## Workflow
+
+### 1. Identify the target
+
+- Determine the current repository: `gh repo view --json nameWithOwner -q .nameWithOwner`.
+- Resolve the number to either an issue or a PR. GitHub numbers them in the same namespace, so try PR first, then issue:
+  - `gh pr view <number> --json number,title,state,author,body,headRefName,baseRefName,isDraft,mergeable,additions,deletions,changedFiles,labels,comments,reviews`
+  - If that fails, `gh issue view <number> --json number,title,state,author,body,labels,comments,assignees`
+- Record whether the target is an **issue** or a **PR** — the two branches below differ.
+
+### 2a. If the target is an issue
+
+Gather context in parallel:
+- The issue body and all comments (from the `gh issue view` JSON above).
+- `gh issue view <number> --json linkedPullRequests` — check for linked PRs that may already address it.
+- Identify the files or subsystems the issue points at. Search the repo (`Grep`, `Glob`, `Read`) for the relevant code. Do not guess — read the actual files the issue describes.
+- If the issue references specific OIDs, error messages, function names, or SNMP behaviours, locate them in the source.
+
+### 2b. If the target is a PR
+
+Gather context in parallel:
+- PR body, comments, and reviews (from the `gh pr view` JSON above).
+- `gh pr diff <number>` — the full diff.
+- `gh pr view <number> --json files -q '.files[].path'` — changed files.
+- Read the **current** version of each changed file on the base branch so you understand what the PR is replacing, not just what it adds.
+- If the PR closes or references an issue (via `Fixes #N`, `Closes #N`, etc.), also fetch that issue for context.
+- Check CI status if available: `gh pr checks <number>`.
+
+### 3. Form a judgement
+
+Decide which of these recommendations fits, and be willing to recommend **against** actioning:
+
+- **Do not action** — the issue is invalid, already fixed, out of scope, based on a misunderstanding, a duplicate, or the PR is the wrong approach / would regress behaviour / conflicts with project direction. Explain *why* clearly, citing the code or prior commits that support the conclusion.
+- **Action as-is** — the issue is valid and the fix is clear, or the PR is correct and should be merged as submitted.
+- **Action with modifications** — the issue is valid but the obvious fix is wrong; or the PR has the right idea but needs specific changes before it can be merged.
+- **Needs more information** — the report is plausible but underspecified. List the exact questions to ask the reporter / author before any code change is possible.
+
+Base the judgement on what the code actually does today, not on what the issue/PR claims. If the two disagree, surface the disagreement.
+
+### 4. Draft the proposal
+
+Structure the written proposal in this order. Keep it concrete — name files, line numbers, function names, and the specific behaviours being changed.
+
+1. **Target** — `Issue #N: <title>` or `PR #N: <title>`, plus one sentence on its state (open/closed/draft/merged, CI status for PRs).
+2. **Summary of the report** — one short paragraph in your own words describing what the reporter is asking for or proposing. Do not just quote the body.
+3. **Findings** — what the code currently does, whether the report is accurate, and any related context (linked issues/PRs, prior commits, existing tests covering this area). Cite `file:line` locations.
+4. **Recommendation** — one of the four options from step 3, stated plainly in a sentence or two.
+5. **Proposed changes** (omit if the recommendation is *do not action* or *needs more information*):
+   - **Code** — for each file to change, list the edit as a bullet: `path/to/file.js:<line-range> — <what changes and why>`. For non-trivial edits, include a short before/after sketch (a few lines, not a full diff).
+   - **Tests** — list tests to **add**, **modify**, or **delete**, each with the file and a one-line description of what the test asserts. If no test changes are needed, say so explicitly and justify (e.g. "covered by existing test at `test/x.test.js:42`").
+   - **Docs / README** — note any README or inline-doc updates required. Release-note bullets are handled by `/prepare-release`; do not pre-empt them here.
+6. **Risks and unknowns** — anything that could make the plan wrong: behaviours you could not verify, edge cases the tests would not catch, compatibility concerns, or assumptions about the reporter's environment.
+7. **Out of scope** — closely-related issues you noticed while investigating but are **not** proposing to fix in this action. Keeps the scope honest.
+
+### 5. Closing question
+
+End the response with exactly one question, offering three choices:
+
+> Proceed with this plan as-is, proceed with modifications (tell me what to change), or abandon it?
+
+Do not start implementing until the user answers. If the user says "proceed", begin implementing the plan in the next turn. If the user asks for modifications, revise the proposal and ask the same question again. If the user says to abandon, stop and skip step 6.
+
+### 6. Ready-to-paste issue/PR reply
+
+After the agreed actions have been carried out (code edits, tests, docs, or a reasoned decision not to action), produce a single ready-to-paste reply for the issue/PR. This is the **last** thing you output, rendered in a fenced block or delimited by `---` so the user can copy it cleanly.
+
+The reply must be aligned with **what actually happened**, not with the original plan — if the user asked for modifications during implementation, reflect the modified outcome. If a step was skipped or failed, say so honestly; do not describe work that was not done.
+
+Tailor the content to the recommendation from step 3:
+
+- **Action as-is / with modifications** — acknowledge the report, give the user a short, concrete summary of the fix (with the key code change or snippet inline if it helps them adopt it), point at the files/sections that changed (e.g. "updated in `README.md` under *Scalar providers*"), and note when it will ship (e.g. "will land in the next release" — do not invent a version number unless `package.json` has already been bumped). If there's a workaround the reporter can apply before the release, include it.
+- **Do not action** — explain the reasoning in the reporter's terms, citing the code or prior history that supports the decision. Be respectful: the reporter put effort into the report. Offer an alternative path if one exists (a different API, a related issue, a config change). If the issue should be closed, say so; do not close it yourself.
+- **Needs more information** — list the specific questions you need answered, each as its own bullet. Explain briefly *why* each is needed so the reporter can see what would unblock progress.
+
+Style:
+
+- Match the tone of prior replies in this repository if they are visible in the issue/PR thread — don't suddenly adopt a different register.
+- Write as the maintainer would: first person, conversational, no corporate voice, no marketing copy, no emoji unless the repo's existing replies use them.
+- Do not include a signature, do not add attribution trailers (no "generated by", no `Co-Authored-By`), do not tag the reporter more than once.
+- Keep it focused — one screen of text is almost always enough. If the reply needs code blocks, prefer short, complete snippets over long diffs.
+
+Hand the reply to the user with one sentence above it saying where to paste it (e.g. "Ready-to-paste reply for issue #297:"). Do **not** run `gh issue comment` / `gh pr comment` / `gh issue close` / `gh pr merge` — the user posts it.
+
+## Rules
+
+- **Never** edit files, run tests, or modify git state during steps 1–5. Planning only.
+- **Never** post a comment on the issue/PR, add labels, request reviews, merge, or close — not in step 6, not ever within this skill. Those are the user's decision.
+- **Never** fabricate line numbers or function names — if you cite `file:line`, you must have read it.
+- If `gh` is not authenticated or the number does not exist, stop and report the error verbatim.
+- If the issue/PR is in a different repository than the current working directory, stop and confirm with the user before proceeding — the plan would target the wrong codebase.
+- Keep the proposal focused. A plan that touches ten files for a one-line bug is a signal to re-read the issue, not to write a bigger plan.

package/.claude/skills/publish-release/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: publish-release
+description: Publish the currently-committed release by pushing master to origin, publishing to npm, tagging the commit with the package.json version, and pushing the tag. Use when the user asks to "publish the release", "push and publish", or invokes /publish-release. Stops immediately on any failure.
+---
+
+# Publish Release
+
+## When to use
+
+- After `/prepare-release` and the release commit have both been completed — this skill assumes the release commit (version bump + README entry + fix) is already `HEAD` on `master`.
+- User asks to publish / ship / release to npm.
+- User invokes `/publish-release`.
+
+Run after `/prepare-release` + `/git-commit`, never in place of them. This skill does not run lint, tests, or modify any files.
+
+## Workflow
+
+Run steps in order. **If any step fails, stop immediately, report the failure, and do not proceed.** There is no rollback — each step is externally observable (a push, a publish, a tag on origin), so a mid-flight failure leaves the release in a partial state the user will need to reason about. Be explicit about which steps succeeded and which did not.
+
+### 1. Pre-flight checks (parallel)
+
+- `git rev-parse --abbrev-ref HEAD` — confirm the current branch is `master`. If not, stop and ask the user.
+- `git status --short` — confirm the working tree is clean. If not, stop — the release commit must already exist as `HEAD`, with nothing else pending.
+- Read the current version from `package.json` (this becomes the tag name).
+- `git tag --list <version>` — confirm the tag does not already exist locally. If it does, stop.
+- `git ls-remote --tags origin refs/tags/<version>` — confirm the tag does not already exist on the remote. If it does, stop.
+- `git log -1 --format=%s` — capture the subject of the HEAD commit for the summary.
+
+### 2. Push master to origin
+
+Run `git push origin master`. **Stop on non-zero exit.** Report the output.
+
+### 3. Publish to npm
+
+Run `npm publish`. **Stop on non-zero exit.**
+
+Notes:
+- If the registry prompts for a one-time password (2FA OTP), relay the prompt to the user and wait for their input. Do not attempt to bypass 2FA.
+- If the registry rejects with `403` or `You do not have permission`, stop and surface the full error — the user may need to `npm login` or check their credentials.
+- If the registry rejects with `You cannot publish over the previously published versions`, stop — the version was not bumped correctly upstream of this skill.
+
+### 4. Tag the release
+
+Tags in this repo are bare version numbers (no `v` prefix) — verified against the existing tag list.
+
+Run `git tag <version>` where `<version>` is the exact value read from `package.json` in step 1 (e.g., `3.26.2`, not `v3.26.2`).
+
+**Stop on non-zero exit.**
+
+### 5. Push the tag
+
+Run `git push origin <version>`. **Stop on non-zero exit.**
+
+### 6. Summary
+
+Report to the user, concisely:
+- The version that was published.
+- Confirmation of: master pushed, npm publish succeeded, tag created, tag pushed.
+- The release commit subject (from pre-flight).
+- The npm package URL, if it can be derived from `package.json` name (`https://www.npmjs.com/package/<name>`).
+
+## Things to watch for
+
+- If step 2 (push master) succeeds but step 3 (npm publish) fails, the commit is on GitHub but not on npm. Do not tag — the user must either resolve the npm issue and re-run publish, or roll back the push.
+- If step 3 (npm publish) succeeds but step 4 (tag) or step 5 (tag push) fails, the package is on npm but not tagged. Surface this clearly — the user needs to manually create / push the tag, and an un-tagged published release is a fix-it-now situation, not something to leave for later.
+- Never use `--force`, `--no-verify`, or any flag that bypasses checks, even to recover from a mid-flight failure. Always ask the user.
+- Never create or push tags for versions other than the one in `package.json`.
+- Never run this skill on a branch other than `master` without explicit user confirmation.

package/README.md

@@ -1950,7 +1950,12 @@ var myScalarProvider = {
     scalarType: snmp.ObjectType.OctetString,
     maxAccess: snmp.MaxAccess["read-write"],
     handler: function (mibRequest) {
-       // e.g. can update the MIB data before responding to the request here
+       // For a dynamically-calculated read-only scalar, publish the current value
+       // by assigning to the instance node before calling done().  For read-write scalars,
+       // the agent has already cast and validated mibRequest.setValue by the
+       // time the handler runs, and will commit it on your behalf — the handler
+       // usually just needs to call done().
+       mibRequest.instanceNode.value = yourFunctionToComputeCurrentValue ();
        mibRequest.done ();
     }
     // Note: handler is optional for scalar providers - if omitted, 
@@ -2174,6 +2179,29 @@ objects`, below, for details.
  with the instance OID being operated on, and an `operation` field with the request type from
  `snmp.PduType`.  If the `MibRequest` is for a `SetRequest` PDU, then variables `setValue` and
  `setType` contain the value and type received in the `SetRequest` varbind.
+
+ How the handler should interact with the MIB value depends on the request type:
+
+ * For `GetRequest`, `GetNextRequest` and `GetBulkRequest`, the response varbind is taken
+   from `mibRequest.instanceNode.value` at the moment `done()` is called.  A handler that
+   serves a dynamically-computed read-only scalar (e.g. `sysUpTime`) should therefore
+   assign the current value to `mibRequest.instanceNode.value` before calling `done()`.
+   Equivalent and validated alternative: call `mib.setScalarValue(providerName, value)`
+   from the handler, which casts and constraint-checks the value before storing it.
+   For table columns the pattern is the same — assign to `mibRequest.instanceNode.value`.
+ * For `SetRequest`, the agent has already cast and validated the incoming value into
+   `mibRequest.setValue` before the handler runs, and will commit it to
+   `mibRequest.instanceNode.value` on your behalf during the commit pass.  A handler
+   typically only needs to call `done()` (or `done({errorStatus: ...})` to reject the set).
+   You generally don't need to assign to `instanceNode.value` yourself on the set path.
+
+ If you do need to validate an externally-supplied value inside a handler, three helpers
+ are exposed on the public API: `ObjectTypeUtil.castSetValue(type, value, constraints)`
+ casts and range/constraint-checks a value (throwing on bad input);
+ `MibNode#validateValue(type, value)` returns a boolean against the node's provider
+ constraints; and `MibNode#getConstraintsFromProvider()` returns the constraints object
+ for the current instance node.
+
  * `constraints` *(optional for scalar types)* - an optional object to specify constraints for
  integer-based enumerated types, integer range restrictions and string size restrictions.  Note that
  table columns can specify such `constraints` in an identical way, except that these are stored under
@@ -3723,6 +3751,10 @@ Example programs are included under the module's `example` directory.
 
  * Fix TypeError in oidInSubtree when varbind OID is null
 
+# Version 3.26.3 - 21/04/2026
+
+ * Document how MIB scalar and table handlers should interact with `mibRequest.instanceNode.value` for Get vs Set operations
+
 # License
 
 Copyright (c) 2020 Mark Abrahams <mark@abrahams.co.nz>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "net-snmp",
-  "version": "3.26.2",
+  "version": "3.26.3",
   "description": "JavaScript implementation of the Simple Network Management Protocol (SNMP)",
   "author": "Mark Abrahams <mark@abrahams.co.nz>",
   "license": "MIT",