Hi,

I support this. 

Could certs.c live in `tests/data_files`? We should also make sure this file is automatically synced with the actual CRT and key files in that directory. There is a script which does that, but IIRC it's not called as part of the CI, which lead to certs.c and the data files get out of sync multiple times in the past.

Best
Hanno
From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.org> on behalf of Manuel Pegourie-Gonnard via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Sent: Monday, April 20, 2020 10:49 AM
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: [mbed-tls] 3.0 plans - move certs.c out of the library
 
Hi all,

In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]:
should we move certs.c out of the library?

[1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/

Currently the X.509 library includes test certificates and keys, which are
enabled by default in config.h - `MBEDTLS_CERTS_C`.

These are used in the following places:

- in library/x509.c in mbedtls_x509_self_test()
- in tests/suites/test_suite_ssl.function
- in programs/fuzz and programs/ssl

In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we'd
like to remove certs.h and the certificates it contains from the library
(except perhaps one static cert for mbedtls_x509_self_test()). Tests and
example programs that need built-in certificates could still get them using
any mechanism, included a file certs.c similar to the current one - but this
file would no longer live in library or be included when building libmbedx509.

Reasons include:

- Including test certificates and keys in the library provides little value, as
  users will want to use their own certificates and keys anyway.

- Shipping private keys as part of the library is bad practice, even under the
  `mbedtls_test_` sub-namespace. There's a slight risk that some users could
use them for prototyping and then inadvertently keep using unsafe private keys
in production.

If you disagree or have concerns, please speak up! Also, if want to suggest
ideas for where the replacement to library/certs.c should live or how it
could be maintained, now's a good time as well!

Regards,
Manuel.
--
mbed-tls mailing list
mbed-tls@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.