feat(bark): add optional AES-GCM encryption - #1062
Open
IceCodeNew wants to merge 4 commits into
Open
IceCodeNew wants to merge 4 commits into
IceCodeNew wants to merge 4 commits into
Conversation
Author
|
Follow-up: Plaintext On the current CI failures:
|
Validate raw ASCII keys before changing configuration and keep plaintext sends unchanged when encryption is disabled. Encrypt notification parameters with a fresh Bark-compatible IV for each request. Keep device_key outside the ciphertext and stop before network I/O when encryption fails. Cover key validation, known ciphertext vectors, plaintext compatibility, encrypted envelopes, IV rotation, and fail-closed behavior. Amp-Thread-ID: https://ampcode.com/threads/T-01a06d8a-3f4a-7438-a100-609db8d61a48 Co-authored-by: Amp <[email protected]>
Add optional encryption to both usage examples and link the setter documentation for key and IV requirements. Amp-Thread-ID: https://ampcode.com/threads/T-01a06d8a-3f4a-7438-a100-609db8d61a48 Co-authored-by: Amp <[email protected]>
Keep ASCII validation at the configuration boundary and generate the IV where the encrypted request is assembled. Remove the helper-only IV test; the send test still checks the transmitted IV format and rotation between requests. Preserve ciphertext vectors, envelope assertions, and fail-closed coverage.
IceCodeNew
force-pushed
the
feat/bark-aes-gcm
branch
from
September 6, 2026 16:35
39e4e26 to
4ff5fe4
Compare
Keep postData unchanged and add encryption after the existing message serialization. Serialize the notification fields populated by Send separately from the device key. Assert the complete decrypted field set without depending on a shared production payload type.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Add optional AES-GCM encryption to the Bark service.
Call
SetEncryptionKeywith the same 16-, 24-, or 32-character ASCII key configured in the Bark app. Subsequent notifications encrypt the complete parameter object and POSTdevice_key,ciphertext, andivto/push. The IV is a fresh 12-character Bark-compatible nonce for every request. An empty key keeps the existing plaintext path.This matches the Bark app AES-GCM wire format used by apprise#1684.
Motivation and Context
AES-GCM keeps the notification title and body private. Transit hops and a third-party Bark server only see ciphertext, so callers do not have to run and operate their own Bark server just to keep message content off someone else's disk.
Without a key, the service still sends plaintext, so existing callers are unchanged.
How Has This Been Tested?
go test -count=1 -race ./service/bark/golangci-lint run --timeout=5m ./...(v2.12.2, 0 issues)Screenshots / Output (if appropriate):
N/A
Types of changes
Checklist: