You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/esp8266wifi/bearssl-client-secure-class.rst
+10-10
Original file line number
Diff line number
Diff line change
@@ -125,22 +125,22 @@ Prior to connecting to a server, the `BearSSL::WiFiClientSecure` needs to be tol
125
125
There are multiple modes to tell BearSSL how to verify the identity of the remote server. See the `BearSSL_Validation` example for real uses of the following methods:
126
126
127
127
setInsecure()
128
-
^^^^^^^^^^^^^^^
128
+
^^^^^^^^^^^^^
129
129
130
130
Don't verify any X509 certificates. There is no guarantee that the server connected to is the one you think it is in this case, but this call will mimic the behavior of the deprecated axTLS code.
131
131
132
-
setKnownKey(const BearSSL::PublicKey *pk)
133
-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
132
+
setKnownKey(const BearSSL::PublicKey \*pk)
133
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
134
134
135
135
Assume the server is using the specific public key. This does not verify the identity of the server or the X509 certificate it sends, it simply assumes that its public key is the one given. If the server updates its public key at a later point then connections will fail.
Verify the SHA1 fingerprint of the certificate returned matches this one. If the server certificate changes, it will fail. If an array of 20 bytes are sent in, it is assumed they are the binary SHA1 values. If a `char*` string is passed in, it is parsed as a series of human-readable hex values separated by spaces or colons (e.g. `setFingerprint("00:01:02:03:...:1f");`)
141
141
142
-
setTrustAnchors(BearSSL::X509List *ta)
143
-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
142
+
setTrustAnchors(BearSSL::X509List \*ta)
143
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
144
144
145
145
Use the passed-in certificate(s) as a trust anchor, accepting remote certificates signed by any of these. If you have many trust anchors it may make sense to use a `BearSSL::CertStore` because it will only require RAM for a single trust anchor (while the `setTrustAnchors` call requires memory for all certificates in the list).
If you are connecting to a server repeatedly in a fixed time period (usually 30 or 60 minutes, but normally configurable at the server), a TLS session can be used to cache crypto settings and speed up connections significantly.
190
190
@@ -193,8 +193,8 @@ Errors
193
193
194
194
BearSSL can fail in many more unique and interesting ways then the deprecated axTLS. Use these calls to get more information when something fails.
195
195
196
-
getLastSSLError(char *dest = NULL, size_t len = 0)
Returns the last BearSSL error code encountered and optionally set a user-allocated buffer to a human-readable form of the error. To only get the last error integer code, just call without any parameters (`int errCode = getLastSSLError();`).
Sets an elliptic curve certificate and key for the server. Needs to be called before `begin()`.
35
35
@@ -38,7 +38,7 @@ Requiring Client Certificates
38
38
39
39
TLS servers can request the client to identify itself by transmitting a certificate during handshake. If the client cannot transmit the certificate, the connection will be dropped by the server.
Copy file name to clipboardExpand all lines: doc/faq/a02-my-esp-crashes.rst
+3-3
Original file line number
Diff line number
Diff line change
@@ -308,9 +308,9 @@ Memory, memory, memory
308
308
Stack
309
309
The amount of stack in the ESP is tiny at only 4KB. For normal developement in large systems, it
310
310
is good practice to use and abuse the stack, because it is faster for allocation/deallocation, the scope of the object is well defined, and deallocation automatically happens in reverse order as allocation, which means no mem fragmentation. However, with the tiny amount of stack available in the ESP, that practice is not really viable, at least not for big objects.
311
-
* Large objects that have internally managed memory, such as String, std::string, std::vector, etc, are ok on the stack, because they internally allocate their buffers on the heap.
312
-
* Large arrays on the stack, such as uint8_t buffer[2048] should be avoided on the stack and be dynamically allocated (consider smart pointers).
313
-
* Objects that have large data members, such as large arrays, should be avoided on the stack, and be dynamicaly allocated (consider smart pointers).
311
+
* Large objects that have internally managed memory, such as String, std::string, std::vector, etc, are ok on the stack, because they internally allocate their buffers on the heap.
312
+
* Large arrays on the stack, such as uint8_t buffer[2048] should be avoided on the stack and be dynamically allocated (consider smart pointers).
313
+
* Objects that have large data members, such as large arrays, should be avoided on the stack, and be dynamicaly allocated (consider smart pointers).
Copy file name to clipboardExpand all lines: doc/gdb.rst
+24-22
Original file line number
Diff line number
Diff line change
@@ -76,13 +76,13 @@ ELF format version of it (which includes needed debug symbols).
76
76
77
77
Under Linux these files are stored in ``/tmp/arduino_build_*`` and the following command will help locate the right file for your app:
78
78
79
-
.. code:: cpp
79
+
.. code:: bash
80
80
81
81
find /tmp -name "*.elf" -print
82
82
83
83
Under Windows these files are stored in ``%userprofile%\AppData\Local\Temp\arduino_build_*`` and the following command will help locate the right file for your app:
0 commit comments