Erlang/OTP中verify_fun/3接收证书二进制而非OTPCertificate记录的问题分析

问题背景

在Erlang/OTP的public_key模块中，证书验证回调函数verify_fun/3存在一个参数传递顺序不一致的问题。这个问题会影响所有使用证书验证回调功能的Erlang应用，特别是那些依赖于证书链验证的安全通信场景。

技术细节

在public_key.erl模块中，证书验证回调函数被调用了两次，但两次调用时参数顺序不一致：

1. 第一次调用（1713行）：

pubkey_cert:apply_fun(VerifyFun, Cert#cert.otp, Cert#cert.der, Reason, Userstat0)

2. 第二次调用（2422行）：

pubkey_cert:apply_fun(VerifyFun, OtpCert, DerCert, Reason, UserState0)

然而，在pubkey_cert.erl模块中的apply_fun/5函数实现却反转了这两个参数的顺序：

apply_fun(Fun, DerCert, OtpCert, Result, UserState) ->
    if is_function(Fun, 4) ->
            Fun(OtpCert, DerCert, Result, UserState);
       is_function(Fun, 3) ->
            Fun(OtpCert, Result, UserState)
    end.

影响分析

这个参数顺序反转的问题会导致以下影响：

1. 当使用3参数版本的verify_fun时，开发者预期接收OTPCertificate记录作为第一个参数，但实际上会收到DER编码的二进制证书数据。

2. 当使用4参数版本的verify_fun时，虽然最终参数顺序是正确的，但中间过程存在不必要的参数交换。

3. 依赖于证书详细信息的验证逻辑可能会失败，因为二进制DER格式的证书需要额外解析才能获取证书字段。

解决方案建议

这个问题应该通过以下方式修复：

1. 统一public_key.erl中的参数顺序，确保与pubkey_cert.erl中的实现一致。

2. 更新文档，明确说明verify_fun回调函数的参数顺序和类型。

3. 对于已经依赖于当前行为的应用，需要考虑向后兼容性问题。

开发者注意事项

开发者在实现证书验证回调时应注意：

1. 不要假设第一个参数的类型，应该先检查其类型（是OTPCertificate记录还是二进制数据）。

2. 如果确实需要处理DER格式的证书，可以使用public_key:pkix_decode_cert/2函数进行解析。

3. 在OTP版本升级时，特别注意证书验证相关功能的测试。

总结

这个参数顺序问题虽然看起来简单，但在安全相关的证书验证场景中可能造成严重的影响。开发者在使用证书验证回调时应当谨慎处理参数类型，并在升级OTP版本时充分测试相关功能。Erlang/OTP团队已经确认了这个问题，并将在后续版本中修复。