Add HMAC-SHA256 signature verification for HTTP webhook shovels

[Copilot]

HTTP shovels can now sign webhook requests with HMAC-SHA256, enabling endpoints to verify request authenticity. Compatible with GitHub/PagerDuty signature formats.

Implementation

• HTTPDestination: Added optional signature_secret parameter, computes HMAC-SHA256 of body and adds X-LavinMQ-Signature-256: sha256=<hex> header
• ShovelStore: Parses dest-signature-secret from configuration
• Performance: Body only buffered when signature enabled; otherwise streamed as before

Configuration

{
  "src-uri": "amqp://localhost",
  "src-queue": "events",  
  "dest-uri": "https://example.com/webhook",
  "dest-signature-secret": "my-secret-key"
}

Verification Example (Python)

import hmac, hashlib

signature = request.headers.get('X-LavinMQ-Signature-256')[7:]  # Remove 'sha256='
body = request.get_data()
expected = hmac.new(SECRET.encode(), body, hashlib.sha256).hexdigest()
assert hmac.compare_digest(signature, expected)

Additional verification examples for Node.js and Go included in WEBHOOK_SIGNATURE_VERIFICATION.md.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• moment.github.io
  • Triggering command: curl --fail --retry 5 -sLo static/js/lib/luxon.js REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Webhook signature verification support</issue_title>
<issue_description>Webhook endpoint invoked by lavinmq should be able to verify that it in fact was their LavinMQ broker that made the request. See these api docs for reference:
https://developer.pagerduty.com/docs/verifying-webhook-signatures
https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Webhook signature verification support #1422

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

0 out of 2 committers have signed the CLA.
❌ @copilot
❌ @baelter
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[spuun]

Because of this there should probably be a (configurable?) max size.

[carlhoerberg]

💯

[carlhoerberg]

Why is it called "LavinMQ-Signature-256"? it's nothing "lavinmq" about it, and sha256 is already in the value, why not just X-HMAC-Signature?

[carlhoerberg]

Ok, looking on other implementations of this I see that there's no real standard, hence the product name in the header, and then you have to look up the docs for that header. Well, then either 256 in the key or the sha256= in the value should at least go away.

I also liked that slack included the date/time in the signature to prevent reply attacks. Have we considered that? (But instead of adding a custom time/date header, why not just use the standard Date header?)

[carlhoerberg]

Key rotation is also not supported, as PagerDuty does

[carlhoerberg]

💯

[carlhoerberg]

all caps in the filename doesn't align with how we normally name files, and should it be in the root dir?

Could it be shorter? It's very verbose right now, maybe works better as a blog post. And just short summary/note in the README instead?

[viktorerlingsson]

+1 short note in README + blog post

[claude]

Claude finished @copilot's task —— View job

---

Code Review Analysis

Reviewing PR for problems that need fixing:

• Read repository guidelines (CLAUDE.md)
• Examine core implementation files for issues
• Check for bugs, security vulnerabilities, performance issues
• Verify error handling and Crystal best practices
• Report findings

Issues Found

1. Timing Attack Vulnerability - shovel.cr:380

The timestamp generation uses RoughTime.unix_ms // 1000 which provides timestamps with 100ms precision due to RoughTime's internal rounding (@@unix_ms = @@utc.to_unix_ms // 100 * 100). This makes the system vulnerable to timing attacks where attackers can predict valid timestamp windows.

Risk: An attacker could potentially replay requests within the 100ms window or brute force signatures knowing the reduced timestamp precision.

Fix: Use Time.utc.to_unix for full precision timestamps.

2. Missing Replay Attack Protection - shovel.cr:383-390

The signature verification follows Standard Webhooks format but lacks replay attack protection. Unlike GitHub/PagerDuty implementations, there's no timestamp validation or nonce tracking.

Risk: Valid webhook requests can be captured and replayed indefinitely.

Recommendation: Add timestamp validation (reject requests older than 5 minutes) and consider nonce tracking for critical applications.

3. Memory Exhaustion Risk - shovel.cr:352-356

While there's a size check for @max_signed_webhook_payload, the default 16MB limit is quite high and the error handling rejects without requeue, which could mask legitimate large messages.

Risk: Memory pressure from repeatedly processing large messages before rejection.

Improvement: Consider logging the rejection reason and potentially implementing backoff for repeated large messages.

4. Crystal Anti-pattern: Force Unwrapping - shovel.cr:358

Using msg.body_io.gets_to_end without proper error handling if the IO is closed or corrupted.

Risk: Could raise unexpected exceptions leading to shovel crashes.

Fix: Add proper IO error handling around body reading.

No issues found with the cryptographic implementation - HMAC-SHA256 usage and Base64 encoding are correct.