Azure Function App v2 Python+GnuPG添加新公钥失败问题求助

环境背景 #

• 运行环境：Linux版Azure Function App，Python代码
• 核心逻辑：通过GnuPG使用多组公钥加密文件，事件驱动每日加密数千份文件并存储至Azure Storage
• 异常现象：新增公钥（如recipient4、recipient5）时触发invalid public key错误，公钥本身有效；仅重建Function App可恢复，重启无效；调试发现新公钥未同步至.gnupg/pubring.kbx文件

具体排查方向 #

1. 密钥目录的权限与路径一致性检查 #

• 确认Azure Function运行身份（默认www-data）对.gnupg目录及文件拥有读写权限，新增密钥时可能因权限不足无法写入密钥环文件
• 检查Python代码中调用GnuPG时是否显式指定GNUPGHOME环境变量，确保所有函数实例使用同一密钥存储路径，避免因实例隔离导致密钥环不一致

2. 多实例环境下的密钥共享问题 #

• Azure Function弹性/消耗计划会动态扩容实例，本地.gnupg目录仅存在于单个实例中，新增密钥无法同步到其他实例，导致部分实例找不到新密钥
• 改用Azure File Share挂载为Function App的.gnupg目录，让所有实例共享同一套密钥环，避免实例间的密钥差异

3. 密钥导入逻辑的有效性验证 #

• 检查代码中导入公钥的逻辑是否仅在实例首次启动时执行，若后续新增密钥未触发导入，会导致新实例或现有实例无法获取新密钥
• 导入密钥时捕获并输出gpg --import命令的执行日志，确认导入操作是否实际成功，避免忽略导入失败的错误信息

4. GPG进程缓存与代理状态排查 #

• Linux下GPG进程会缓存密钥环信息，即使密钥环文件已更新，当前运行的GPG进程仍可能使用旧缓存。可在导入密钥后执行gpg --refresh-keys或gpgconf --kill gpg-agent强制刷新缓存（需确认Function App允许执行此类系统命令）
• 确认是否启用了GPG代理，代理的密钥缓存可能导致新添加的公钥无法被即时识别

内容的提问来源于stack exchange，提问作者Nandha Frost