docs: add security policy and Dependabot configuration

.github/dependabot.yml

@@ -0,0 +1,91 @@
+# Dependabot configuration for github.com/haivision/srtgo
+# Reference: https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference
+#
+# Dependabot security updates are enabled on this repository, but without a
+# configuration file that is all Dependabot does -- PR #59 (the x/sys v0.1.0
+# bump) is an example. Routine version-update PRs require an explicit
+# configuration, which is what this is.
+version: 2
+
+updates:
+  # Go modules: go.mod / go.sum in the repository root (single module).
+  - package-ecosystem: "gomod"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "06:00"
+      timezone: "Etc/UTC"
+    commit-message:
+      prefix: "deps"
+    ignore:
+      # golang.org/x/sys is deliberately held at v0.1.x.
+      #
+      # go.mod declares `go 1.12` on purpose: raising it would force a newer
+      # toolchain on every downstream consumer of this binding. Newer x/sys
+      # releases do exactly that. v0.1.0 declares `go 1.17`; from v0.31.0 the
+      # floor is `go 1.23.0`, and every release from v0.42.0 through the
+      # current v0.47.0 declares `go 1.25.0` -- so accepting even a 0.x "minor"
+      # bump here silently raises srtgo's effective Go floor. srtgo uses x/sys
+      # only for address families and sockaddr sizes, in netutils_unix.go,
+      # netutils_windows.go and the netutils_test.go assertions, which has been
+      # stable for years, so there is nothing to gain from tracking it.
+      #
+      # DO NOT rewrite this as `update-types: ["version-update:semver-minor",
+      # "version-update:semver-major"]`. An `update-types` ignore is not
+      # applied to security updates: dependabot-core's
+      # Config::IgnoreCondition#ignored_versions begins `return versions if
+      # security_updates_only`, so on a security run the `update-types` entries
+      # are dropped and only a `versions` list survives. (GitHub's options
+      # reference states the same limitation in as many words, but only under
+      # `update-types` (`allow`); the `update-types` (`ignore`) section is
+      # silent on it, so the code is the citation that matters here.) An
+      # `update-types` ignore would therefore still let a security-update PR
+      # bump x/sys to v0.44.0+ and drag the `go` directive to 1.25.0. A
+      # `versions` range is honored by both code paths, which is the entire
+      # point of this entry.
+      #
+      # Consequence, knowingly accepted: if a Dependabot alert is ever raised
+      # for x/sys, this entry suppresses the security-update PR for it too.
+      # That is not currently the case for GO-2026-5024 / CVE-2026-39824
+      # (integer overflow in NewNTUnicodeString, first fixed in x/sys v0.44.0):
+      # GitHub's advisory for that CVE is unreviewed and carries no
+      # affected-version ranges, so it raises no Dependabot alert here and
+      # there is no security-update PR to suppress. The affected symbol is
+      # Windows-only and is never called from this repository. See SECURITY.md
+      # for the full rationale.
+      #
+      # Revisit: delete this entry once go.mod's minimum Go version is raised,
+      # or sooner if an advisory lands that actually affects the packages
+      # srtgo imports.
+      - dependency-name: "golang.org/x/sys"
+        versions:
+          - ">= 0.2.0"
+
+  # Actions referenced by the workflows in .github/workflows/.
+  # `directory: "/"` is correct here: for github-actions Dependabot searches
+  # /.github/workflows plus a root action.yml/action.yaml. In this repository
+  # that means the single workflow .github/workflows/ci.yml, which references
+  # actions/checkout and actions/setup-go at their v7 major tags; there is no
+  # root action.yml and srtgo is not published as an action. Dependabot
+  # discovers those `uses:` references itself -- they are named here only so a
+  # reader knows what this block is watching.
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "06:00"
+      timezone: "Etc/UTC"
+    commit-message:
+      prefix: "ci"
+    groups:
+      # Both actions live in the same workflow and are exercised by the same
+      # CI run, which builds libsrt from source on the Linux matrix legs. One
+      # combined PR per week costs one CI run instead of one per action, and
+      # there is no reason to land a checkout bump and a setup-go bump
+      # separately. `applies-to` defaults to version updates, so security
+      # updates still arrive as individual PRs.
+      actions:
+        patterns:
+          - "*"

README.md

@@ -63,4 +63,4 @@ You can find detailed instructions about how to install srtlib in its [README fi
 
 srtgo requires **srt 1.4.2 or newer** to build: it uses APIs first introduced in 1.4.2 (`srt_connect_callback`, `srt_setrejectreason`, and the `SRT_EPOLLEMPTY`/`SRT_ESCLOSED`/`SRT_ESYSOBJ` error codes).
 
-For security, **srt 1.5.6 or newer is recommended**: every earlier release is affected by CVE-2026-55869 (buffer overflow in KMREQ/KMRSP handling) and CVE-2026-55868 (encryption state machine downgrade), both fixed in [srt 1.5.6](https://github.com/Haivision/srt/releases/tag/v1.5.6).
+For security, **srt 1.5.6 or newer is recommended**: every earlier release is affected by CVE-2026-55869 (buffer overflow in KMREQ/KMRSP handling) and CVE-2026-55868 (encryption state machine downgrade), both fixed in [srt 1.5.6](https://github.com/Haivision/srt/releases/tag/v1.5.6). See [SECURITY.md](SECURITY.md).

SECURITY.md

@@ -0,0 +1,117 @@
+# Security Policy
+
+## Reporting a vulnerability
+
+Report vulnerabilities in this binding through GitHub private vulnerability
+reporting, which is enabled on this repository:
+<https://github.com/Haivision/srtgo/security/advisories/new>
+("Security" tab -> "Report a vulnerability").
+
+Please do not open a public issue for a suspected vulnerability. If you cannot
+reach that form, open an issue that says only that you have a security report
+and asks for a private channel, with no details.
+
+Include, where you can: affected commit, the libsrt version your build actually
+linked against (see "srtgo does not vendor libsrt" below for how to determine
+it), OS/architecture, and a reproducer.
+
+Fixes land on `master`. This repository publishes no tagged releases and
+maintains no release branches, so consumers track a pseudo-version and should
+update to the fixed commit.
+
+## Scope
+
+In scope: the Go/cgo code in this repository -- the SRT socket wrapper, the
+epoll poll server, option handling, and the memory/lifetime boundary between Go
+and C.
+
+Not in scope: vulnerabilities in libsrt itself. Report those to the libsrt
+project, <https://github.com/Haivision/srt>, not here.
+
+## srtgo does not vendor libsrt
+
+srtgo is a cgo binding. It contains no copy of libsrt, no submodule and no
+`vendor/` directory: it compiles against the `<srt/srt.h>` headers and links
+against the libsrt that *you* install on the build and target machines.
+Consequently:
+
+- A libsrt CVE cannot be fixed by a change to srtgo, and updating srtgo does
+  not update libsrt.
+- The libsrt actually in effect is whichever one your toolchain resolves. srtgo
+  builds with a plain `#cgo LDFLAGS: -lsrt` and does not use `pkg-config`, so
+  `pkg-config --modversion srt` tells you what pkg-config can see, not
+  necessarily what you linked. Check your build flags and your linked binary
+  (`otool -L` on macOS, `ldd` on Linux, `dumpbin /dependents` on Windows), not
+  this repository. If you link libsrt statically, no such tool will show it and
+  the version is fixed at link time.
+- Keeping libsrt patched is the consumer's responsibility.
+
+### Recommended minimum libsrt
+
+**libsrt 1.5.6 or newer.** This matches the README, which states: "For
+security, **srt 1.5.6 or newer is recommended**". Versions up to and including
+1.5.5 are affected by two critical issues, both network-reachable without
+authentication or user interaction (CVSS 3.1 base score 9.1,
+`AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H`), and both fixed in 1.5.6:
+
+| Advisory | CVE | Issue |
+| --- | --- | --- |
+| [GHSA-6xg9-784j-24rm](https://github.com/Haivision/srt/security/advisories/GHSA-6xg9-784j-24rm) | CVE-2026-55869 | Buffer overflow in KMREQ/KMRSP handling |
+| [GHSA-4mc6-qmpp-g7gw](https://github.com/Haivision/srt/security/advisories/GHSA-4mc6-qmpp-g7gw) | CVE-2026-55868 | Encryption state machine downgrade |
+
+This is a different number from srtgo's minimum for *building*, which the
+README gives as "srtgo requires **srt 1.4.2 or newer** to build" -- the binding
+references `srt_connect_callback`, `srt_setrejectreason` and the
+`SRT_EPOLLEMPTY`/`SRT_ESCLOSED`/`SRT_ESYSOBJ` error codes, none of which exist
+before 1.4.2. 1.4.2 is what compiles; 1.5.6 is the floor for anything exposed
+to untrusted peers.
+
+Separately, note that an SRT stream is **unencrypted unless you configure a
+passphrase**. If stream contents or integrity matter, set the `passphrase`
+option on both peers and do not disable `enforcedencryption` (libsrt defaults
+it to on), so a peer that offers no encryption is rejected rather than silently
+accepted. Do not rely on the transport being private by default.
+
+## Accepted risks
+
+Known advisories that are deliberately not being acted on, and why.
+
+### GO-2026-5024 / CVE-2026-39824 -- golang.org/x/sys/windows
+
+Integer overflow in `NewNTUnicodeString`: a string longer than an
+`NTUnicodeString` can describe is truncated instead of returning an error.
+First fixed in `golang.org/x/sys` v0.44.0; this module requires v0.1.0.
+
+Not fixed here because:
+
+- The affected symbol is Windows-only (the Go vulnerability database records it
+  under `goos: windows`) and is never called from this repository. srtgo uses
+  x/sys only for address-family constants and sockaddr struct sizes, in
+  `netutils_unix.go`, `netutils_windows.go` and `netutils_test.go`.
+  `govulncheck` reports it as present in a required module with no call path
+  into it: "your code doesn't appear to call these vulnerabilities".
+- x/sys v0.44.0 declares `go 1.25.0` in its own `go.mod`. Taking it would raise
+  the Go toolchain floor for every downstream consumer of srtgo, which
+  currently declares `go 1.12` deliberately. That cost is judged larger than
+  the risk of an unreachable Windows-only overflow.
+
+Note that srtgo's `require golang.org/x/sys v0.1.0` is a minimum, not a pin.
+Under minimal version selection, a consumer whose own module graph already
+needs a newer x/sys builds against that newer version, fix included. This
+decision constrains only builds of srtgo on its own.
+
+This finding comes from `govulncheck` / the Go vulnerability database, not from
+Dependabot: GitHub's advisory for CVE-2026-39824 is
+[GHSA-4vpj-hr3r-4gpg](https://github.com/advisories/GHSA-4vpj-hr3r-4gpg), which
+is unreviewed and carries no affected-version ranges, so it raises no Dependabot
+alert here; at the time of writing this repository has no open Dependabot alerts
+at all. `.github/dependabot.yml` holds `golang.org/x/sys` at v0.1.x, which
+suppresses routine version-update pull requests for it and would also suppress a
+security-update pull request if an alert ever did appear. That ignore rule
+configures updates only; it cannot dismiss or hide an alert, which would remain
+visible in this repository's Security tab.
+
+Revisit if: srtgo starts calling `NewNTUnicodeString` (directly or through a
+new x/sys API), an x/sys advisory affects a package srtgo actually imports, or
+srtgo's minimum Go version is raised for other reasons -- at which point the
+ignore rule should be dropped and x/sys updated.