Tags: elastic/stream
Tags
internal/command: evaluate log lines as templates with --template (#213) The log command streamed each line verbatim, so fixtures with absolute timestamps eventually age out of time-windowed consumers (for example a transform that filters on now-90d). Re-dating the fixtures by hand only resets a ticking clock. Add a --template flag that evaluates each line as a Go text/template before sending, using the same function set as the http-server config (env, hostname, sum, file, glob, minify_json, now). A streamed line can then keep its timestamps current, for example: "eventTime":"{{ (now "-720h").Format "2006-01-02T15:04:05Z07:00" }}" Each line is rendered independently, and a template error aborts the run reporting the offending line number. To keep one implementation, the template function map and helpers move from internal/httpserver into a new internal/templates package that both the http-server and the log command use. Updates elastic/integrations#20792 Co-authored-by: Opus 4.8 High
Remove libpcap dependency and add Windows support (#210) stream needed libpcap and cgo solely to read capture files offline, so `go install github.com/elastic/stream@latest` failed on any machine without libpcap and a C toolchain. Windows was hit hardest because Go disables cgo there by default. Replace pcap.OpenOffline with gopacket's pure Go pcapgo readers, dispatching on the file magic to choose the pcap or pcapng reader and decompressing gzipped captures explicitly. stream now builds with CGO_ENABLED=0 everywhere, so libpcap is gone from the Dockerfile, the Buildkite pipeline, and the GitHub workflows. Windows also failed to compile because root.go used unix.SignalNum. Move the signal name lookup behind a build tag: Unix keeps the full set, while Windows recognizes SIGINT and SIGTERM, the only signals the Go runtime emulates there. Read packets in an explicit loop instead of PacketSource.Packets(), which retries unrecognized errors in a 5ms loop and so would hang stream indefinitely on a corrupt capture. Truncated captures are still tolerated with a warning. Build the published image FROM scratch now that the binary is static, copying only the CA bundle from the builder. This drops the image from 70.5MB to 56.6MB. Add a cross-build workflow covering six platforms plus ubuntu, windows and macos test runs so none of this regresses unnoticed. Validated by diffing old and new payload extraction across 55 capture files against libpcap 1.10.5: classic pcap matches byte for byte, and no file that libpcap could read fails with pcapgo.
security: add govulncheck CI and fix 4 active vulnerabilities (#209) security: add govulncheck CI and fix 4 active vulnerabilities Add a govulncheck GitHub Actions workflow that runs on pull requests and pushes to main. The workflow uses golang/govulncheck-action to detect vulnerabilities in the call graph (not just the module graph), so it only alerts on code paths that are actually reachable. Upgrade three modules to eliminate all four confirmed vulnerabilities: - google.golang.org/grpc v1.62.1 → v1.82.1 (GO-2026-6061) - golang.org/x/net v0.47.0 → v0.55.0 (GO-2026-4918, GO-2026-5026) - golang.org/x/text v0.32.0 → v0.39.0 (GO-2026-5970) All four vulnerabilities were reachable through the webhook and GCP PubSub outputs. See the PR description for per-vulnerability impact analysis.
internal/httpserver: add now template function for dynamic timestamps (… …#205) Add a "now" template function to the HTTP mock server that returns the current UTC time. An optional Go duration string offsets the result, e.g. {{ (now "-720h").Format "2006-01-02T15:04:05Z07:00" }} for 30 days ago. This allows integration test mock configs to produce timestamps relative to the current time instead of hardcoding dates that eventually age past time-windowed queries.
[Automation] Bump Golang version to 1.24.3 (#150) And use alphine:3.21 in the image because that is what was using to build the binary. Co-authored-by: obltmachine <obltmachine@users.noreply.github.com> Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
Close TCP, TLS connections gracefully to avoid data loss (#123) TCP connections, including TLS connections, acknowledge received data. Although a simple `net.Conn.Close()` will put all previously written data on the network, the receiving server may disregard data that it can't successfully acknowledge. Graceful acknowledgement and closure can be facilitated by the client closing writes first, and reading any available data before fully closing the connection.
PreviousNext