Remove dependency on SD/SPIFFS from CertStore

[earlephilhower]

Due to popular demand, remove the hardcoded dependency on SPIFFS
or SD from the CertStore by factoring out the file interface into
a new class (CertStoreFile) that the user will need to implement
as a thin wrapper around either a SPIFFS.file or a SD.file

Combine the downloaded certificates into a UNIX "ar" archive
and parse that on-the-fly to allow easy inspection and creation
of the Cert Store database.

Examples updated with a new certificate downloader that creates
the certs.ar archive and with a single sample that can be built
for either SPIFFS or SD with a #define. Users can copy the
implementation of the CertStoreFile they need to their own code
as it is self-contained.

Also move the CertStore to the BearSSL namespace and remove the
suffix and separate SPIFFS/SD sources.

Fixes #4740

[everslick]

@earlephilhower: I pulled your PR and everything is back to normal! Thank you so much. From my point of view the issue is resolved. Please note that this only applies to the library interdependence. I currently have no testcase for the BearSSL stack itself. Anyway, good job!

[Jeroen88]

I liked the flat file structure. Since CA certificates have a validity date too, I want to make an endpoint on my server where the ESP can retrieve new cert(s) (I actually use only one Let's encrypt cert). I also read that ar is depreciated. Is it possible to also have flat file wrappers?

[earlephilhower]

ar is part of the GCC toolchain and is the way you make a static .a library. I don't think that it could be deprecated without breaking every software build, as it were. It's also a dead-simple format which makes using it easier than tar or zip.

If you only want a single cert, you should really just use that cert and setTrustAnchor() it. It'll be faster and use a little less memory.

Alternatively, for a single file you can generate an AR archive with the single .der file. ar mcs file.ar file.der will do the trick. You can even use the cross-compiler gcc-*lx106*-ar already in your toolchain, the format is actually ASCII based so not even issues with big/little endianness.

The reason I went to a single combined file instead of multiple ones is that otherwise I would need to add more methods to the compatibility File wrapper class involving a Filesystem as well and end up with an almost complete solution for the Arduino's lack of any filesystem/file standard class. While a useful goal, that's a little out of my problem space here.

[Jeroen88]

@earlephilhower thank you very much for your reaction, I will try the AR archive.

[devyte]

I'll make a non-virtual proposal. What I have in mind is a cerstore object templated generator function that returns the object with the FS type passed as argument. I'll make a draft, then post it here.

[devyte]

I'm running against the clock at wörk, so I can't test this, but off the top of my head I came up with this. This can be part of the repo, and worst case the user would just need to instantiate. Or we can instantiate based on a #define.

Discussed in maintainer gitter, note about change in the future and punt templates to a 2.5.0 release.

[earlephilhower]

Punting on templates for now to fix the immediate issues seen with PIO and other makefile-based builds. We'll re-examine the whole filesystem issue as a template for the 2.5.0 release late this year.