Can THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS being set with wildcard?

[AkiraVoid]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Can I specify a folder or a file path with wildcard in it to let Dify be able to verify the plugins published by various developers?

For example:

plugin_daemon:
  environment:
    THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS: /app/storage/publickeys/*.pem
    # Or
    # THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS: /app/storage/publickeys/

2. Additional context or comments

No response

[AkiraVoid]

@dosu

[dosubot[bot]]

Wildcards (like *.pem) and directory paths are not supported for THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS. You need to specify each public key file explicitly, separated by commas. For example:

plugin_daemon:
  environment:
    THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS: /app/storage/publickeys/key1.pem,/app/storage/publickeys/key2.pem

You can find this documented in the official Dify docs, which only mention explicit file paths or comma-separated lists—no support for glob patterns or directories is described or implemented [docs reference].

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[AkiraVoid]

Although this environment variable is mentioned in docs, I can't see where it functions. Also, I have checked the docker-compose.yml on main branch, but seen nowhere the variable applied to, I have to disable forced signature validation to make sure my custom plugin can be installed. Could teams (@crazywoola @laipz8200 ...) please answer my 2 questions about:

1. Is this variable in use?
2. If the variable is obsoleted, is there any other solution for us to trust plugins made by ourselves or third party developers?

[kurokobo]

@AkiraVoid
Hi, let me comment as the person who developed this feature.

Can I specify a folder or a file path with wildcard in it to let Dify be able to verify the plugins published by various developers?

That environment variable does not accept wildcards or folder path.
The reason is that we thought it would be safer to trust only the public keys that have been explicitly approved by the administrator, rather than unconditionally trusting all public keys placed in a certain directory.

Of course, you are welcome to submit a feature request if you’d like. If you’re interested, please feel free to open a feature request in the dify-plugin-daemon repository.

Is this variable in use?

Yes, that environment variable is still available.
Since it is used in Plugin Daemon, you can find the actual code in dify-plugin-daemon repository.

This isn’t limited to just this environment variables, but not all available environment variables are necessarily listed in the docker-compose.yaml.
To keep the file as simple as possible (even though it’s still quite big), some environment variables – especially those only needed for special cases – are intentionally left out.

If you’d like to use this environment variable, you can either edit the docker-compose.yaml directly, or place new docker-compose.override.yaml file next to it, as described in the documentation.

[AkiraVoid]

@kurokobo Thanks for your kind comment.

I asked if it's still available, because I tried to add it into my docker compose configuration but I still cannot install the plugin signed with a paired private key, it compliant that the plugin is untrusted repeatedly. I am wondering if the name of the variable in docker compose should be different from the one in doc (because there are many variables in dotenv file has names different from the one in docker-compose.yml in Dify).

Anyway, I am currently taking a break, I will check if I mis-configured something and report here once I get back to work.

[kurokobo]

@AkiraVoid
Yes, I tried it with the new version 1.10.1 (plugin daemon 0.4.1), and it worked as expected.
Here's an example setup:

After creating sign_demo.difypkg, I followed the documentation to create the signed package sign_demo.signed.difypkg, and was able to install it.
You can see the verified blue checkmark.

[AkiraVoid]

Oh, now I know the reason why it cannot be enabled on my deployment. This part in source code does the thing:

https://github.com/langgenius/dify-plugin-daemon/blob/68db8475c9a84014f23459708c5ab8d6238a4769/internal/types/app/config.go#L146-L147

where THIRD_PARTY_SIGNATURE_VERIFICATION_ENABLED defaults to false, and I have only set the THIRD_PARTY_SIGNATURE_VERIFICATION_PUBLIC_KEYS.