Hi WebRTC SDK team, thank you for the work you do, and sorry if I have posted this in the wrong section.
I am currently evaluating the standard, non-prefixed io.github.webrtc-sdk:android:150.7871.01, with declared native source 73cb8180f7258ee292878d6edd05177f41883962.
My latest check still listed 150.01 as the latest standard Maven package, which I am distinguishing from the newer native source/build releases.
I have matched the original AAR to the GitHub release, verified the Maven detached signature and completed limited original/repackaged D8 comparisons. The questions below concern evidence I have not established. Existing public records or corrections to my understanding would be welcome.
- Remaining patch coverage. Which available standard Android release/source covers these public changes, their prerequisites or equivalent fixes? SCTP 522976080 / 74d5f029; 503013378 / 190a7606; 502783118 / 424a6bd0; 537233963 (reviews 490840, 491920, 491041); 504690157 / caf9532b; and 542449805 / 437408bd. If a change is inapplicable, is the equivalent correction or build exclusion documented for that exact standard AAR?
- Android-native execution. I found Linux/macOS/Windows CI and the adapted Robolectric report, which answer different testing questions. Are existing Android-native regression or sanitizer reports available for the relevant transport/security changes, identifying the source revision, ABI, device/emulator, configuration, cases run and skips/failures? I am not asking you to rerun the known desktop or JVM checks.
- Exact build inputs and provenance. For run 33350496482, standard artifact 9744480229 and its Maven publication, are retained resolved dependency/toolchain versions, effective GN arguments, applied patches and final native component/linker records available? I already have VERSIONS, NOTICE and basic publication linkage. Existing digest-linked provenance or reproducible-build records would help; please distinguish original producing records from later reconstructions. If unavailable, that clarification is still useful.
- Public signing-key designation. Where does the publisher officially designate fingerprint E65BD4351D0FF0EF9C0C15FF3CCBD94F6FC0F446 for this Maven publication, and announce rotation/revocation? Signature validity is already established; I need the public publisher-to-key designation, not any private signing material.
- Release compatibility and maintenance scope. What API/ABI and minified Android runtime/JNI/data-channel checks are documented for the standard package? I noted the prefixed JNI fix, but do not treat that variant's results or my D8 checks as standard-package runtime proof. I also saw selective M144 backports. What native-security support policy applies: supported branches, backport scope, and when consumers are expected to upgrade or maintain fixes themselves?
Pointers to existing evidence or its responsible owner are enough. I am not requesting confidential reports or unpublished vulnerability details. Where no evidence or maintenance commitment is available, please just let me know rather than undertake new work for these questions.
Thank you again for your help, team.
Hi WebRTC SDK team, thank you for the work you do, and sorry if I have posted this in the wrong section.
I am currently evaluating the standard, non-prefixed io.github.webrtc-sdk:android:150.7871.01, with declared native source 73cb8180f7258ee292878d6edd05177f41883962.
My latest check still listed 150.01 as the latest standard Maven package, which I am distinguishing from the newer native source/build releases.
I have matched the original AAR to the GitHub release, verified the Maven detached signature and completed limited original/repackaged D8 comparisons. The questions below concern evidence I have not established. Existing public records or corrections to my understanding would be welcome.
- Remaining patch coverage. Which available standard Android release/source covers these public changes, their prerequisites or equivalent fixes? SCTP 522976080 / 74d5f029; 503013378 / 190a7606; 502783118 / 424a6bd0; 537233963 (reviews 490840, 491920, 491041); 504690157 / caf9532b; and 542449805 / 437408bd. If a change is inapplicable, is the equivalent correction or build exclusion documented for that exact standard AAR?
- Android-native execution. I found Linux/macOS/Windows CI and the adapted Robolectric report, which answer different testing questions. Are existing Android-native regression or sanitizer reports available for the relevant transport/security changes, identifying the source revision, ABI, device/emulator, configuration, cases run and skips/failures? I am not asking you to rerun the known desktop or JVM checks.
- Exact build inputs and provenance. For run 33350496482, standard artifact 9744480229 and its Maven publication, are retained resolved dependency/toolchain versions, effective GN arguments, applied patches and final native component/linker records available? I already have VERSIONS, NOTICE and basic publication linkage. Existing digest-linked provenance or reproducible-build records would help; please distinguish original producing records from later reconstructions. If unavailable, that clarification is still useful.
- Public signing-key designation. Where does the publisher officially designate fingerprint E65BD4351D0FF0EF9C0C15FF3CCBD94F6FC0F446 for this Maven publication, and announce rotation/revocation? Signature validity is already established; I need the public publisher-to-key designation, not any private signing material.
- Release compatibility and maintenance scope. What API/ABI and minified Android runtime/JNI/data-channel checks are documented for the standard package? I noted the prefixed JNI fix, but do not treat that variant's results or my D8 checks as standard-package runtime proof. I also saw selective M144 backports. What native-security support policy applies: supported branches, backport scope, and when consumers are expected to upgrade or maintain fixes themselves?
Pointers to existing evidence or its responsible owner are enough. I am not requesting confidential reports or unpublished vulnerability details. Where no evidence or maintenance commitment is available, please just let me know rather than undertake new work for these questions.
Thank you again for your help, team.