| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| t_upstream_uninitialized_value.diff | Fix an 'uninitialized value' warning | Mikael Magnusson <mikma@users.sourceforge.net> | yes | |||
| default-ca-path.patch | provide a default ssl_ca_path ssl_verify is on by default, but will fail unless provided with a valid ssl_ca_path. On Debian, commonly trusted CA certificates are stored in /etc/ssl/certs |
yes | debian | |||
| 0001-Do-not-die-when-hostname-cannot-be-resolved.patch | [PATCH] Do not die when hostname cannot be resolved. In case the local hostname cannot be resolved, use it instead of the full reverse name, as it would have been done in case the reverse would not work. |
Thadeu Lima de Souza Cascardo <cascardo@debian.org> | yes | debian upstream | 2021-01-20 | |
| Set_SSL_verifycn_name_parameter_to_fix_hostname_verification.patch | [PATCH] Set SSL_verifycn_name parameter to fix hostname verification IO-Socket-SSL 2.078 reverted a "decision from 2014 to not verify hostname by default if hostname is IP address but no explicit verification scheme given" [1]. Since start_SSL uses SSL_verifycn_name or SSL_hostname when verifying the hostname and falls back to the IP address of the peer if neither of them are set, the hostname verification failed with newer versions of IO-Socket-SSL even if the certificate presented by the peer was valid. Passing SSL_verifycn_name to start_SSL fixes this issue. The logic to determine the parameter value is based on my current understanding of [2] and thus uses the same logic that is also used in OpenStream to determine the 'to' address in the initial stream header. [1]: https://github.com/noxxi/p5-io-socket-ssl/commit/c0a063b70f0a3ad033da0a51923c65bd2ff118a0 [2]: https://datatracker.ietf.org/doc/html/rfc6120#section-13.7.2.1 |
Manfred Stock <m-cpan@nfred.ch> | yes | debian upstream | 2024-02-16 |