Name the fork where a claim is about my two appliances - #109
Merged
Merged
Conversation
Six places said the appliances run "IoTivity classic". That names a family, and the family name resolves to upstream, which answers some of these questions differently: upstream sets VERIFY_REQUIRED and carries no ECDHE-ECDSA-AES128-GCM-SHA256, while these appliances complete a session on an empty client certificate using exactly that suite. A reader who followed the label to upstream would find it predicting a failed handshake where the hardware shows a working one. Both appliances are TizenRT boards running the iotivity_1.2-rel fork, pinned here at e590f30ab, and that is what the three sites making claims about them now say: the evidence-scope paragraph, the kernel-assigned port explanation, and the comparison table's column. Two code comments follow. Every line number in them was already the fork's and lands correctly there, so only the labels moved: caipadapter.c:219 and caipserver.c:826 in test_endpoint, cacommon.h:95 with caprotocolmessage.c:939,1030 and ocobserve.c:518 in dtls_session. What stays is the family label doing family work. The module-name table identifies a family, which is as far as a device log gets you, so it keeps saying classic and now says what to do next: a classic match beside tizenrt_* names in the same log means the vendor fork. The 5684 binding holds for both trees. certificates.md and the icv note already gave fork and upstream numbers side by side, and needed nothing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Six places said the two appliances here run "IoTivity classic". That is a family name, and it resolves to upstream, which answers some of these questions differently. Upstream sets
MBEDTLS_SSL_VERIFY_REQUIREDand carries noECDHE-ECDSA-AES128-GCM-SHA256; these appliances complete a session on an empty client certificate using exactly that suite. So a reader who followed the label to upstream would find it predicting a failed handshake where the hardware shows a working one.Both are TizenRT boards running the
iotivity_1.2-relfork, pinned here ate590f30ab. Three sites that make claims about them now say so: the evidence-scope paragraph, the kernel-assigned-port explanation, and the comparison table's column header.The line numbers were already right
This pass guards against a failure that had not yet happened in these two files. Every citation in them was already a fork number and lands correctly in the fork, so only the labels moved:
caipadapter.c:219caipserver.c:826getsocknamereads back the assignmentcacommon.h:95#define CA_MAX_TOKEN_LEN (8)caprotocolmessage.c:939ocobserve.c:518memcmpover the incoming token's lengthThe same is not true in the other direction:
CAencryptSslis at 1520 upstream and 2010 in the fork, which is the mismatch corrected in #98.What keeps the family label
The module-name table identifies a family, which is as far as a device log gets you, so it still says classic. It now also says what to do next: a classic match beside
tizenrt_*names in the same log points at the vendor fork. The 5684 binding holds for both trees.docs/certificates.mdand theicvnote already gave fork and upstream numbers side by side and needed nothing.844 tests pass.