Bug Description

WeCom inbound file attachments can fail to be received/processed because the callback aeskey is treated as standard Base64, while real WeCom payloads may provide it as URL-safe Base64 without = padding.

As a result, Hermes can successfully receive the callback and download the encrypted bytes, but fail during local decryption of the attachment.

Root Cause

The WeCom adapter used:

base64.b64decode(aes_key)

This assumes a standard Base64 string.

However, actual WeCom aeskey values may be:

• URL-safe Base64 (- / _)
• missing trailing = padding

This can lead to invalid decode results or wrong key length, which then breaks AES decryption for inbound file attachments.

Impact

Inbound attachments such as:

• PDF
• ZIP
• TAR.GZ

may fail to decrypt and therefore fail to be cached/handed off correctly for downstream processing.

Fix

Normalize the aeskey before decryption:

• trim whitespace
• require non-empty key
• restore missing = padding
• decode with base64.urlsafe_b64decode(...)

Code Changes

gateway/platforms/wecom.py

• added _decode_aes_key(aes_key: str) -> bytes
• switched _decrypt_file_bytes(...) to use the normalized URL-safe decoder instead of base64.b64decode(...)

tests/gateway/test_wecom.py

• added regression coverage for urlsafe unpadded aeskey
• updated media test data to use a more realistic WeCom-style key format

Verification

Targeted tests passed:

• test_decrypt_file_bytes_accepts_unpadded_urlsafe_aes_key
• load_inbound_media_decrypts_encrypted_file

Result:

• 2 passed

Minimal Diff Summary

Before:

key = base64.b64decode(aes_key)

After:

key = WeComAdapter._decode_aes_key(aes_key)

where _decode_aes_key(...) handles URL-safe decoding and missing padding.