While I didn't dive into the code, it looks like polarssl does not have a big enough buffer to read in ca-certificates.crt. This causes a problem with applications like curl that can link to polarssl as an ssl provider, but giving the option --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt to curl means you hit the same problem. You can produce this problem using one of the bundled examples: polarssl_ssl_client2 server_name=bugs.gentoo.org server_port=443 ca_file=/etc/ssl/certs/ca-certificates.crt . Seeding the random number generator... ok . Loading the CA root certificate ... failed ! x509parse_crt returned 8 Last error was: 8 - BIGNUM - The buffer is too small to write to However, if you change ca_file to some other smaller pem, it works. I know polarssl aims to have a small footprint for embedded systems, but this buffer size should be a configurable option as it is in, say axTLS, which also aims at embedded systems. Reproducible: Always
Issue pursued upstream. A bit of background as to why this is useful: curl allows multiple backend ssl providers. If one configures curl to use polarssl and feeds it --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt, then you hit the problem.
@Tommy[D], take a look at upstream. This was not an enhencement, but an actual bug. I mistakingly thought that the buffer was not large enough as the error message suggested, but in fact the buffer is dynamically allocated as one would expect. Its the return value that is not handled properly. I never had time to jump into the C to look at it and just assumed that they'd set a limit to the buffer because of memory tight embedded systems.
Upstream has pushed the change: http://polarssl.org/trac/changeset/1281
is this still an issue?