目录
main
分支43
标签30
+ 疑修
Web IDE
Yanmei Liu
[WIP] Fix #686: Treat invalid ticket early data as protocol violation (#931)


    

  • [~]: Treat invalid ticket early data as protocol violation
    

    • 

  • [~]: Validate ticket extensions before reporting violation
    

    • 

  • [=]: Simplify NewSessionTicket error mapping
    

    • 

  • [=]: Limit ticket alert tracking to clients
    

    •
3天前346次提交
lt;TARGET_FILE:xquic>, which resolves wherever the file lands and also carries the right extension per platform. Guard on CMAKE_STRIP too, since some generators leave it empty. Verified by configuring only: strip is generated for Minsizerel and not for Release, Debug or an unset build type, and with LIBRARY_OUTPUT_PATH redirected the command names the real path. Note this turns previously dead code live, so Minsizerel builds now genuinely strip. * [+] accept extra C flags in xqc_build.sh The iOS block passed -DBORINGSSL_PREFIX=bs and a -DBORINGSSL_PREFIX_SYMBOLS path, but the root CMakeLists reads neither, and bssl_symbols.txt does not exist in the tree. That worked only for the old template, which built BoringSSL as a subproject and handled the prefix itself; the root CMakeLists consumes a prebuilt SSL. Drop both flags and take an optional sixth argument appended to CMAKE_C_FLAGS, so a caller linking a symbol-prefixed BoringSSL can define the macro themselves. Passed as its own quoted argument rather than through $configures, which is expanded unquoted and would split a value holding several space-separated flags. ${extra_c_flags:+"..."} contributes no argument at all when unset -- an outer quote there would instead pass an empty one. Verified with a stub cmake: unset adds nothing, a single flag and several space-separated flags each arrive as one argument, and following flags are not swallowed. Also confirmed CMake keeps a command-line CMAKE_C_FLAGS and appends the file's own flags after it. * [=] document the extra_c_flags argument Record the sixth argument added in the previous commit: what it does, that it has to be quoted as one argument, and the BORINGSSL_PREFIX case it exists for. Note that the prefixed BoringSSL is built beforehand and its symbol_prefix_include headers arrive through ssl_inc_path, so nothing further needs passing. The signature matches the script's own usage text, and the example was run against a stub cmake to confirm the macro reaches CMAKE_C_FLAGS intact. * [~] link threads with -pthread instead of -lpthread -lpthread asks the linker for a library that does not exist on Android: Bionic folds pthread into libc, so the NDK sysroot ships no libpthread and the link fails with "unable to find library -lpthread". -pthread is a compiler-driver option instead, and the driver knows what each platform needs -- it expands to nothing on Android, resolves through libSystem on macOS, and adds -lpthread on glibc Linux. This is also what cmake/CMakeLists.txt used, which is why the mobile builds worked before they moved to the root CMakeLists. Verified: a translation unit calling pthread_create links on Android arm64 with -pthread and fails with -lpthread, and the driver injects no -lpthread there. macOS still builds libxquic.dylib against a real BoringSSL. * [~] tolerate version-script entries lld cannot resolve on Android scripts/xquic.lds exports its symbol list unconditionally, but the feature switches compile some of those symbols out -- xqc_reno_cb, xqc_copa_cb, xqc_unlimited_cc_cb, xqc_interop_scheduler_cb and the FEC scheme callbacks are all absent from a default mobile build. GNU ld only warns about the mismatch, while lld makes it fatal, so the Android shared library failed to link with a "version script assignment ... failed: symbol not defined" per missing symbol. Pass -Wl,--undefined-version there. Scoped to Android because older GNU ld does not know the flag and would reject it on Linux. Verified on Android arm64: the version-script errors go from ten to zero. The link now stops on undefined C++ runtime symbols instead, all of them from libssl.a / libcrypto.a -- BoringSSL is mostly C++ and --whole-archive drags the whole archive in, so a static SSL backend needs a C++ runtime. That is a separate gap and is not addressed here. Also still unverified: whether the flag leaves the version script's "local: *;" filtering intact. Checking that needs the exported symbol table, which is only available once the link succeeds. * [=] hoist the shared cmake options in xqc_build.sh The three platform branches each repeated the same sixteen-line option list, so a change to any shared switch had to be made three times and the per-platform differences were buried. Move the thirteen common options into common_configures and leave each branch with only what is actually specific to it. CMAKE_BUILD_TYPE and CMAKE_TOOLCHAIN_FILE stay per-branch since their values differ, placed first so they are easy to compare. Pure refactor: the fully expanded -D option set was captured per platform before and after with a stub cmake and is identical for all three -- 19 options for iOS and Android, 18 for HarmonyOS. SSL_LIB_PATH also still arrives as one argument with its ';' intact, which is why the list keeps one flag per line; $configures is expanded unquoted and the newline is what prevents the semicolon from running into the next flag. * [~] link a C++ runtime for the BoringSSL backend The GNU branch linked no C++ runtime, so the Android shared library failed with sixteen undefined symbols -- operator delete, __cxa_throw, std::terminate, __cxxabiv1 vtables and the like, every one of them referenced from libssl.a or libcrypto.a. BoringSSL is largely C++ (740 .cc files) and --whole-archive drags the whole archive in, so those symbols have to be resolved here even though XQUIC itself is pure C. This is not Android-specific. The macOS libssl.a shows the same 552 undefined C++ references, which is why the Apple branch has carried -lstdc++ since 3607442 ("fix building error on ubuntu and macOS") -- dropping it there fails the link too. Only the GNU branch was missing it. What does differ per platform is the name: the NDK ships no libstdc++ and names the runtime after ANDROID_STL. Select it once and use it in both branches, so -lstdc++ is no longer hardcoded. Verified on Android arm64 with a real BoringSSL: libxquic.so now links. This also settles the question left open in 18a747c -- --undefined-version does not defeat the version script. The library exports 120 symbols, all xqc_* and all versioned XQUIC_VERS_1.0, with nothing leaking, xqc_reno_cb absent (RENO=OFF) and xqc_bbr2_cb present. macOS still builds libxquic.dylib and its link line is unchanged, since XQC_CXX_RUNTIME expands to the same -lstdc++ there. * [~] build HarmonyOS as Minsizerel too HarmonyOS was the only platform still passing Release. With all three agreeing, CMAKE_BUILD_TYPE is no longer platform-specific, so hoist it into common_configures next to the other build-environment options. The practical effect on HarmonyOS is that the strip step now runs -- it is gated on Minsizerel in the root CMakeLists, so Release never reached it. Nothing else changes: CMAKE_BUILD_TYPE is read in only two places there, that gate and a default-value fallback that an explicit value skips, and CMAKE_C_FLAGS is set unconditionally rather than per configuration, so the optimisation level stays -g -O2. Verified with a stub cmake: all three platforms now pass Minsizerel and the option counts are unchanged at 19/19/18, so only the value moved. * [-] remove the unused cmake/CMakeLists.txt and CMakeOptions.txt cmake/CMakeLists.txt was a second copy of the build system that xqc_build.sh copied over the root CMakeLists.txt before every mobile build. That copy is gone, and nothing references the file any more, so the mobile platforms had been building from a configuration frozen at v1.9.0 -- exactly the kind of drift a shadow build system invites. CMakeOptions.txt only existed to be included by it; the root CMakeLists never did. Deleting the option() declarations is safe. The root CMakeLists never saw them, so SSL_TYPE, XQC_ENABLE_TESTING and GCOV -- the three the script still passes -- already work as plain -D cache variables and keep working. The rest (ENABLE_DEBUG, XQC_BUILD_OPENSSL, SSL_DYNAMIC, XQC_BUILD_SAMPLE) are read by nothing that remains. cmake/ keeps FindCUnit.cmake, FindLibEvent.cmake, FindSSL.cmake and ios.toolchain.cmake, which are all still in use. Verified after the deletion: macOS configures and the find_package(SSL) path still resolves through cmake/FindSSL.cmake, and Android arm64 still builds libxquic.so." href="/mirrors/xquic/commits/7a25486770">xqc_build.sh fix (#907)19天前
  • demo[~] Fix #518: Prevent HQ request loops after delayed FIN (#946)3天前
  • docs
    • lt;TARGET_FILE:xquic>, which resolves wherever the file lands and also carries the right extension per platform. Guard on CMAKE_STRIP too, since some generators leave it empty. Verified by configuring only: strip is generated for Minsizerel and not for Release, Debug or an unset build type, and with LIBRARY_OUTPUT_PATH redirected the command names the real path. Note this turns previously dead code live, so Minsizerel builds now genuinely strip. * [+] accept extra C flags in xqc_build.sh The iOS block passed -DBORINGSSL_PREFIX=bs and a -DBORINGSSL_PREFIX_SYMBOLS path, but the root CMakeLists reads neither, and bssl_symbols.txt does not exist in the tree. That worked only for the old template, which built BoringSSL as a subproject and handled the prefix itself; the root CMakeLists consumes a prebuilt SSL. Drop both flags and take an optional sixth argument appended to CMAKE_C_FLAGS, so a caller linking a symbol-prefixed BoringSSL can define the macro themselves. Passed as its own quoted argument rather than through $configures, which is expanded unquoted and would split a value holding several space-separated flags. ${extra_c_flags:+"..."} contributes no argument at all when unset -- an outer quote there would instead pass an empty one. Verified with a stub cmake: unset adds nothing, a single flag and several space-separated flags each arrive as one argument, and following flags are not swallowed. Also confirmed CMake keeps a command-line CMAKE_C_FLAGS and appends the file's own flags after it. * [=] document the extra_c_flags argument Record the sixth argument added in the previous commit: what it does, that it has to be quoted as one argument, and the BORINGSSL_PREFIX case it exists for. Note that the prefixed BoringSSL is built beforehand and its symbol_prefix_include headers arrive through ssl_inc_path, so nothing further needs passing. The signature matches the script's own usage text, and the example was run against a stub cmake to confirm the macro reaches CMAKE_C_FLAGS intact. * [~] link threads with -pthread instead of -lpthread -lpthread asks the linker for a library that does not exist on Android: Bionic folds pthread into libc, so the NDK sysroot ships no libpthread and the link fails with "unable to find library -lpthread". -pthread is a compiler-driver option instead, and the driver knows what each platform needs -- it expands to nothing on Android, resolves through libSystem on macOS, and adds -lpthread on glibc Linux. This is also what cmake/CMakeLists.txt used, which is why the mobile builds worked before they moved to the root CMakeLists. Verified: a translation unit calling pthread_create links on Android arm64 with -pthread and fails with -lpthread, and the driver injects no -lpthread there. macOS still builds libxquic.dylib against a real BoringSSL. * [~] tolerate version-script entries lld cannot resolve on Android scripts/xquic.lds exports its symbol list unconditionally, but the feature switches compile some of those symbols out -- xqc_reno_cb, xqc_copa_cb, xqc_unlimited_cc_cb, xqc_interop_scheduler_cb and the FEC scheme callbacks are all absent from a default mobile build. GNU ld only warns about the mismatch, while lld makes it fatal, so the Android shared library failed to link with a "version script assignment ... failed: symbol not defined" per missing symbol. Pass -Wl,--undefined-version there. Scoped to Android because older GNU ld does not know the flag and would reject it on Linux. Verified on Android arm64: the version-script errors go from ten to zero. The link now stops on undefined C++ runtime symbols instead, all of them from libssl.a / libcrypto.a -- BoringSSL is mostly C++ and --whole-archive drags the whole archive in, so a static SSL backend needs a C++ runtime. That is a separate gap and is not addressed here. Also still unverified: whether the flag leaves the version script's "local: *;" filtering intact. Checking that needs the exported symbol table, which is only available once the link succeeds. * [=] hoist the shared cmake options in xqc_build.sh The three platform branches each repeated the same sixteen-line option list, so a change to any shared switch had to be made three times and the per-platform differences were buried. Move the thirteen common options into common_configures and leave each branch with only what is actually specific to it. CMAKE_BUILD_TYPE and CMAKE_TOOLCHAIN_FILE stay per-branch since their values differ, placed first so they are easy to compare. Pure refactor: the fully expanded -D option set was captured per platform before and after with a stub cmake and is identical for all three -- 19 options for iOS and Android, 18 for HarmonyOS. SSL_LIB_PATH also still arrives as one argument with its ';' intact, which is why the list keeps one flag per line; $configures is expanded unquoted and the newline is what prevents the semicolon from running into the next flag. * [~] link a C++ runtime for the BoringSSL backend The GNU branch linked no C++ runtime, so the Android shared library failed with sixteen undefined symbols -- operator delete, __cxa_throw, std::terminate, __cxxabiv1 vtables and the like, every one of them referenced from libssl.a or libcrypto.a. BoringSSL is largely C++ (740 .cc files) and --whole-archive drags the whole archive in, so those symbols have to be resolved here even though XQUIC itself is pure C. This is not Android-specific. The macOS libssl.a shows the same 552 undefined C++ references, which is why the Apple branch has carried -lstdc++ since 3607442 ("fix building error on ubuntu and macOS") -- dropping it there fails the link too. Only the GNU branch was missing it. What does differ per platform is the name: the NDK ships no libstdc++ and names the runtime after ANDROID_STL. Select it once and use it in both branches, so -lstdc++ is no longer hardcoded. Verified on Android arm64 with a real BoringSSL: libxquic.so now links. This also settles the question left open in 18a747c -- --undefined-version does not defeat the version script. The library exports 120 symbols, all xqc_* and all versioned XQUIC_VERS_1.0, with nothing leaking, xqc_reno_cb absent (RENO=OFF) and xqc_bbr2_cb present. macOS still builds libxquic.dylib and its link line is unchanged, since XQC_CXX_RUNTIME expands to the same -lstdc++ there. * [~] build HarmonyOS as Minsizerel too HarmonyOS was the only platform still passing Release. With all three agreeing, CMAKE_BUILD_TYPE is no longer platform-specific, so hoist it into common_configures next to the other build-environment options. The practical effect on HarmonyOS is that the strip step now runs -- it is gated on Minsizerel in the root CMakeLists, so Release never reached it. Nothing else changes: CMAKE_BUILD_TYPE is read in only two places there, that gate and a default-value fallback that an explicit value skips, and CMAKE_C_FLAGS is set unconditionally rather than per configuration, so the optimisation level stays -g -O2. Verified with a stub cmake: all three platforms now pass Minsizerel and the option counts are unchanged at 19/19/18, so only the value moved. * [-] remove the unused cmake/CMakeLists.txt and CMakeOptions.txt cmake/CMakeLists.txt was a second copy of the build system that xqc_build.sh copied over the root CMakeLists.txt before every mobile build. That copy is gone, and nothing references the file any more, so the mobile platforms had been building from a configuration frozen at v1.9.0 -- exactly the kind of drift a shadow build system invites. CMakeOptions.txt only existed to be included by it; the root CMakeLists never did. Deleting the option() declarations is safe. The root CMakeLists never saw them, so SSL_TYPE, XQC_ENABLE_TESTING and GCOV -- the three the script still passes -- already work as plain -D cache variables and keep working. The rest (ENABLE_DEBUG, XQC_BUILD_OPENSSL, SSL_DYNAMIC, XQC_BUILD_SAMPLE) are read by nothing that remains. cmake/ keeps FindCUnit.cmake, FindLibEvent.cmake, FindSSL.cmake and ios.toolchain.cmake, which are all still in use. Verified after the deletion: macOS configures and the find_package(SSL) path still resolves through cmake/FindSSL.cmake, and Android arm64 still builds libxquic.so." href="/mirrors/xquic/commits/7a25486770">xqc_build.sh fix (#907)19天前
  • harness[~] Fix #283: Prevent RESET_STREAM after data acknowledgment (#945)3天前
  • include[~]: Fix unidirectional stream close frames (#943)3天前
  • interop[~] Fix Interop docker error (#549)5个月前
  • mini[=]] merge remained1年前
  • moqVersion Update 1.9.0 (#509)11个月前
  • openspec[~]: Add case-test routing and build harness support (#880)1个月前
  • scripts[~]: Add case-test routing and build harness support (#880)1个月前
  • src[WIP] Fix #686: Treat invalid ticket early data as protocol violation (#931)3天前
  • tests[WIP] Fix #686: Treat invalid ticket early data as protocol violation (#931)3天前
  • .gitignore[+] Add agent harness structure and manifest-driven validation (#863)1个月前
  • AGENTS.md[+] Add agent harness structure and manifest-driven validation (#863)1个月前
  • CMakeLists.txt
    • lt;TARGET_FILE:xquic>, which resolves wherever the file lands and also carries the right extension per platform. Guard on CMAKE_STRIP too, since some generators leave it empty. Verified by configuring only: strip is generated for Minsizerel and not for Release, Debug or an unset build type, and with LIBRARY_OUTPUT_PATH redirected the command names the real path. Note this turns previously dead code live, so Minsizerel builds now genuinely strip. * [+] accept extra C flags in xqc_build.sh The iOS block passed -DBORINGSSL_PREFIX=bs and a -DBORINGSSL_PREFIX_SYMBOLS path, but the root CMakeLists reads neither, and bssl_symbols.txt does not exist in the tree. That worked only for the old template, which built BoringSSL as a subproject and handled the prefix itself; the root CMakeLists consumes a prebuilt SSL. Drop both flags and take an optional sixth argument appended to CMAKE_C_FLAGS, so a caller linking a symbol-prefixed BoringSSL can define the macro themselves. Passed as its own quoted argument rather than through $configures, which is expanded unquoted and would split a value holding several space-separated flags. ${extra_c_flags:+"..."} contributes no argument at all when unset -- an outer quote there would instead pass an empty one. Verified with a stub cmake: unset adds nothing, a single flag and several space-separated flags each arrive as one argument, and following flags are not swallowed. Also confirmed CMake keeps a command-line CMAKE_C_FLAGS and appends the file's own flags after it. * [=] document the extra_c_flags argument Record the sixth argument added in the previous commit: what it does, that it has to be quoted as one argument, and the BORINGSSL_PREFIX case it exists for. Note that the prefixed BoringSSL is built beforehand and its symbol_prefix_include headers arrive through ssl_inc_path, so nothing further needs passing. The signature matches the script's own usage text, and the example was run against a stub cmake to confirm the macro reaches CMAKE_C_FLAGS intact. * [~] link threads with -pthread instead of -lpthread -lpthread asks the linker for a library that does not exist on Android: Bionic folds pthread into libc, so the NDK sysroot ships no libpthread and the link fails with "unable to find library -lpthread". -pthread is a compiler-driver option instead, and the driver knows what each platform needs -- it expands to nothing on Android, resolves through libSystem on macOS, and adds -lpthread on glibc Linux. This is also what cmake/CMakeLists.txt used, which is why the mobile builds worked before they moved to the root CMakeLists. Verified: a translation unit calling pthread_create links on Android arm64 with -pthread and fails with -lpthread, and the driver injects no -lpthread there. macOS still builds libxquic.dylib against a real BoringSSL. * [~] tolerate version-script entries lld cannot resolve on Android scripts/xquic.lds exports its symbol list unconditionally, but the feature switches compile some of those symbols out -- xqc_reno_cb, xqc_copa_cb, xqc_unlimited_cc_cb, xqc_interop_scheduler_cb and the FEC scheme callbacks are all absent from a default mobile build. GNU ld only warns about the mismatch, while lld makes it fatal, so the Android shared library failed to link with a "version script assignment ... failed: symbol not defined" per missing symbol. Pass -Wl,--undefined-version there. Scoped to Android because older GNU ld does not know the flag and would reject it on Linux. Verified on Android arm64: the version-script errors go from ten to zero. The link now stops on undefined C++ runtime symbols instead, all of them from libssl.a / libcrypto.a -- BoringSSL is mostly C++ and --whole-archive drags the whole archive in, so a static SSL backend needs a C++ runtime. That is a separate gap and is not addressed here. Also still unverified: whether the flag leaves the version script's "local: *;" filtering intact. Checking that needs the exported symbol table, which is only available once the link succeeds. * [=] hoist the shared cmake options in xqc_build.sh The three platform branches each repeated the same sixteen-line option list, so a change to any shared switch had to be made three times and the per-platform differences were buried. Move the thirteen common options into common_configures and leave each branch with only what is actually specific to it. CMAKE_BUILD_TYPE and CMAKE_TOOLCHAIN_FILE stay per-branch since their values differ, placed first so they are easy to compare. Pure refactor: the fully expanded -D option set was captured per platform before and after with a stub cmake and is identical for all three -- 19 options for iOS and Android, 18 for HarmonyOS. SSL_LIB_PATH also still arrives as one argument with its ';' intact, which is why the list keeps one flag per line; $configures is expanded unquoted and the newline is what prevents the semicolon from running into the next flag. * [~] link a C++ runtime for the BoringSSL backend The GNU branch linked no C++ runtime, so the Android shared library failed with sixteen undefined symbols -- operator delete, __cxa_throw, std::terminate, __cxxabiv1 vtables and the like, every one of them referenced from libssl.a or libcrypto.a. BoringSSL is largely C++ (740 .cc files) and --whole-archive drags the whole archive in, so those symbols have to be resolved here even though XQUIC itself is pure C. This is not Android-specific. The macOS libssl.a shows the same 552 undefined C++ references, which is why the Apple branch has carried -lstdc++ since 3607442 ("fix building error on ubuntu and macOS") -- dropping it there fails the link too. Only the GNU branch was missing it. What does differ per platform is the name: the NDK ships no libstdc++ and names the runtime after ANDROID_STL. Select it once and use it in both branches, so -lstdc++ is no longer hardcoded. Verified on Android arm64 with a real BoringSSL: libxquic.so now links. This also settles the question left open in 18a747c -- --undefined-version does not defeat the version script. The library exports 120 symbols, all xqc_* and all versioned XQUIC_VERS_1.0, with nothing leaking, xqc_reno_cb absent (RENO=OFF) and xqc_bbr2_cb present. macOS still builds libxquic.dylib and its link line is unchanged, since XQC_CXX_RUNTIME expands to the same -lstdc++ there. * [~] build HarmonyOS as Minsizerel too HarmonyOS was the only platform still passing Release. With all three agreeing, CMAKE_BUILD_TYPE is no longer platform-specific, so hoist it into common_configures next to the other build-environment options. The practical effect on HarmonyOS is that the strip step now runs -- it is gated on Minsizerel in the root CMakeLists, so Release never reached it. Nothing else changes: CMAKE_BUILD_TYPE is read in only two places there, that gate and a default-value fallback that an explicit value skips, and CMAKE_C_FLAGS is set unconditionally rather than per configuration, so the optimisation level stays -g -O2. Verified with a stub cmake: all three platforms now pass Minsizerel and the option counts are unchanged at 19/19/18, so only the value moved. * [-] remove the unused cmake/CMakeLists.txt and CMakeOptions.txt cmake/CMakeLists.txt was a second copy of the build system that xqc_build.sh copied over the root CMakeLists.txt before every mobile build. That copy is gone, and nothing references the file any more, so the mobile platforms had been building from a configuration frozen at v1.9.0 -- exactly the kind of drift a shadow build system invites. CMakeOptions.txt only existed to be included by it; the root CMakeLists never did. Deleting the option() declarations is safe. The root CMakeLists never saw them, so SSL_TYPE, XQC_ENABLE_TESTING and GCOV -- the three the script still passes -- already work as plain -D cache variables and keep working. The rest (ENABLE_DEBUG, XQC_BUILD_OPENSSL, SSL_DYNAMIC, XQC_BUILD_SAMPLE) are read by nothing that remains. cmake/ keeps FindCUnit.cmake, FindLibEvent.cmake, FindSSL.cmake and ios.toolchain.cmake, which are all still in use. Verified after the deletion: macOS configures and the find_package(SSL) path still resolves through cmake/FindSSL.cmake, and Android arm64 still builds libxquic.so." href="/mirrors/xquic/commits/7a25486770">xqc_build.sh fix (#907)19天前
  • CODE_OF_CONDUCT.mdfirst release version4年前
  • CONTRIBUTING.md[+] fix mpquic dead loop, support windows and optimize cmake env (#383)2年前
  • LICENSEInitial commit4年前
  • README.mddocs: document supported TLS 1.3 cipher suites (#802)3个月前
  • SECURITY.mdfirst release version4年前
  • xqc_build.sh
    • lt;TARGET_FILE:xquic>, which resolves wherever the file lands and also carries the right extension per platform. Guard on CMAKE_STRIP too, since some generators leave it empty. Verified by configuring only: strip is generated for Minsizerel and not for Release, Debug or an unset build type, and with LIBRARY_OUTPUT_PATH redirected the command names the real path. Note this turns previously dead code live, so Minsizerel builds now genuinely strip. * [+] accept extra C flags in xqc_build.sh The iOS block passed -DBORINGSSL_PREFIX=bs and a -DBORINGSSL_PREFIX_SYMBOLS path, but the root CMakeLists reads neither, and bssl_symbols.txt does not exist in the tree. That worked only for the old template, which built BoringSSL as a subproject and handled the prefix itself; the root CMakeLists consumes a prebuilt SSL. Drop both flags and take an optional sixth argument appended to CMAKE_C_FLAGS, so a caller linking a symbol-prefixed BoringSSL can define the macro themselves. Passed as its own quoted argument rather than through $configures, which is expanded unquoted and would split a value holding several space-separated flags. ${extra_c_flags:+"..."} contributes no argument at all when unset -- an outer quote there would instead pass an empty one. Verified with a stub cmake: unset adds nothing, a single flag and several space-separated flags each arrive as one argument, and following flags are not swallowed. Also confirmed CMake keeps a command-line CMAKE_C_FLAGS and appends the file's own flags after it. * [=] document the extra_c_flags argument Record the sixth argument added in the previous commit: what it does, that it has to be quoted as one argument, and the BORINGSSL_PREFIX case it exists for. Note that the prefixed BoringSSL is built beforehand and its symbol_prefix_include headers arrive through ssl_inc_path, so nothing further needs passing. The signature matches the script's own usage text, and the example was run against a stub cmake to confirm the macro reaches CMAKE_C_FLAGS intact. * [~] link threads with -pthread instead of -lpthread -lpthread asks the linker for a library that does not exist on Android: Bionic folds pthread into libc, so the NDK sysroot ships no libpthread and the link fails with "unable to find library -lpthread". -pthread is a compiler-driver option instead, and the driver knows what each platform needs -- it expands to nothing on Android, resolves through libSystem on macOS, and adds -lpthread on glibc Linux. This is also what cmake/CMakeLists.txt used, which is why the mobile builds worked before they moved to the root CMakeLists. Verified: a translation unit calling pthread_create links on Android arm64 with -pthread and fails with -lpthread, and the driver injects no -lpthread there. macOS still builds libxquic.dylib against a real BoringSSL. * [~] tolerate version-script entries lld cannot resolve on Android scripts/xquic.lds exports its symbol list unconditionally, but the feature switches compile some of those symbols out -- xqc_reno_cb, xqc_copa_cb, xqc_unlimited_cc_cb, xqc_interop_scheduler_cb and the FEC scheme callbacks are all absent from a default mobile build. GNU ld only warns about the mismatch, while lld makes it fatal, so the Android shared library failed to link with a "version script assignment ... failed: symbol not defined" per missing symbol. Pass -Wl,--undefined-version there. Scoped to Android because older GNU ld does not know the flag and would reject it on Linux. Verified on Android arm64: the version-script errors go from ten to zero. The link now stops on undefined C++ runtime symbols instead, all of them from libssl.a / libcrypto.a -- BoringSSL is mostly C++ and --whole-archive drags the whole archive in, so a static SSL backend needs a C++ runtime. That is a separate gap and is not addressed here. Also still unverified: whether the flag leaves the version script's "local: *;" filtering intact. Checking that needs the exported symbol table, which is only available once the link succeeds. * [=] hoist the shared cmake options in xqc_build.sh The three platform branches each repeated the same sixteen-line option list, so a change to any shared switch had to be made three times and the per-platform differences were buried. Move the thirteen common options into common_configures and leave each branch with only what is actually specific to it. CMAKE_BUILD_TYPE and CMAKE_TOOLCHAIN_FILE stay per-branch since their values differ, placed first so they are easy to compare. Pure refactor: the fully expanded -D option set was captured per platform before and after with a stub cmake and is identical for all three -- 19 options for iOS and Android, 18 for HarmonyOS. SSL_LIB_PATH also still arrives as one argument with its ';' intact, which is why the list keeps one flag per line; $configures is expanded unquoted and the newline is what prevents the semicolon from running into the next flag. * [~] link a C++ runtime for the BoringSSL backend The GNU branch linked no C++ runtime, so the Android shared library failed with sixteen undefined symbols -- operator delete, __cxa_throw, std::terminate, __cxxabiv1 vtables and the like, every one of them referenced from libssl.a or libcrypto.a. BoringSSL is largely C++ (740 .cc files) and --whole-archive drags the whole archive in, so those symbols have to be resolved here even though XQUIC itself is pure C. This is not Android-specific. The macOS libssl.a shows the same 552 undefined C++ references, which is why the Apple branch has carried -lstdc++ since 3607442 ("fix building error on ubuntu and macOS") -- dropping it there fails the link too. Only the GNU branch was missing it. What does differ per platform is the name: the NDK ships no libstdc++ and names the runtime after ANDROID_STL. Select it once and use it in both branches, so -lstdc++ is no longer hardcoded. Verified on Android arm64 with a real BoringSSL: libxquic.so now links. This also settles the question left open in 18a747c -- --undefined-version does not defeat the version script. The library exports 120 symbols, all xqc_* and all versioned XQUIC_VERS_1.0, with nothing leaking, xqc_reno_cb absent (RENO=OFF) and xqc_bbr2_cb present. macOS still builds libxquic.dylib and its link line is unchanged, since XQC_CXX_RUNTIME expands to the same -lstdc++ there. * [~] build HarmonyOS as Minsizerel too HarmonyOS was the only platform still passing Release. With all three agreeing, CMAKE_BUILD_TYPE is no longer platform-specific, so hoist it into common_configures next to the other build-environment options. The practical effect on HarmonyOS is that the strip step now runs -- it is gated on Minsizerel in the root CMakeLists, so Release never reached it. Nothing else changes: CMAKE_BUILD_TYPE is read in only two places there, that gate and a default-value fallback that an explicit value skips, and CMAKE_C_FLAGS is set unconditionally rather than per configuration, so the optimisation level stays -g -O2. Verified with a stub cmake: all three platforms now pass Minsizerel and the option counts are unchanged at 19/19/18, so only the value moved. * [-] remove the unused cmake/CMakeLists.txt and CMakeOptions.txt cmake/CMakeLists.txt was a second copy of the build system that xqc_build.sh copied over the root CMakeLists.txt before every mobile build. That copy is gone, and nothing references the file any more, so the mobile platforms had been building from a configuration frozen at v1.9.0 -- exactly the kind of drift a shadow build system invites. CMakeOptions.txt only existed to be included by it; the root CMakeLists never did. Deleting the option() declarations is safe. The root CMakeLists never saw them, so SSL_TYPE, XQC_ENABLE_TESTING and GCOV -- the three the script still passes -- already work as plain -D cache variables and keep working. The rest (ENABLE_DEBUG, XQC_BUILD_OPENSSL, SSL_DYNAMIC, XQC_BUILD_SAMPLE) are read by nothing that remains. cmake/ keeps FindCUnit.cmake, FindLibEvent.cmake, FindSSL.cmake and ios.toolchain.cmake, which are all still in use. Verified after the deletion: macOS configures and the find_package(SSL) path still resolves through cmake/FindSSL.cmake, and Android arm64 still builds libxquic.so." href="/mirrors/xquic/commits/7a25486770">xqc_build.sh fix (#907)19天前
  • xqc_configure.h.in[+] new version prepare, updating multipath draft-10 / FEC updates (#459)1年前
    • README.md

    XQUIC

    xquic logo

    GitHub Build CodeQL Codacy Badge Codacy Badge Platforms DeepWiki

    Introduction

    XQUIC Library released by Alibaba is …

    … a client and server implementation of QUIC and HTTP/3 as specified by the IETF. Currently supported QUIC versions are v1 and draft-29.

    … OS and platform agnostic. It currently supports Android, iOS, HarmonyOS, Linux, macOS and Windows(v1.2.0). Most of the code is used in our own products, and has been tested at scale on android, iOS apps, as well as servers.

    … still in active development. Interoperability is regularly tested with other QUIC implementations.

    Features

    Standardized Features

    • All big features conforming with RFC 9000, RFC9001, RFC9002, RFC9114 and RFC9204, including the interface between QUIC and TLS, 0-RTT connection establishment, HTTP/3 and QPACK.
    • ALPN Extension conforming with RFC7301

    Supported TLS 1.3 Cipher Suites

    XQUIC supports the following TLS 1.3 cipher suites for QUIC packet protection (as defined in RFC 9001 Section 5):

    Cipher Suite AEAD Header Protection Status
    TLS_AES_128_GCM_SHA256 AEAD_AES_128_GCM AES-ECB (128-bit) Supported
    TLS_AES_256_GCM_SHA384 AEAD_AES_256_GCM AES-ECB (256-bit) Supported
    TLS_CHACHA20_POLY1305_SHA256 AEAD_CHACHA20_POLY1305 ChaCha20 Supported
    TLS_AES_128_CCM_SHA256 AEAD_AES_128_CCM — Not Supported
    TLS_AES_128_CCM_8_SHA256 — — Not Supported

    Note: TLS_AES_128_CCM_SHA256 and TLS_AES_128_CCM_8_SHA256 are not supported. CCM-based cipher suites are optional per RFC 9001 and have significantly lower confidentiality and integrity limits (2^21.5) compared to GCM (2^23 / 2^52) and ChaCha20-Poly1305. TLS_AES_128_CCM_8_SHA256 is further excluded from QUIC usage by RFC 9001 as no header protection scheme is defined for it.

    Not Yet Standardized Features

    Library Features

    • Pluggable congestion control: NewReno, Cubic, BBR and BBRv2, …
    • Pluggable cryptography, integration with BoringSSL and BabaSSL
    • Cross-platform implementation, support Android, iOS, HarmonyOS, Linux, macOS and Windows(v1.2.0)

    Requirements

    To build XQUIC, you need

    • CMake
    • BoringSSL or BabaSSL

    To run test cases, you need

    • libevent
    • CUnit

    QuickStart Guide

    XQUIC can be built with BabaSSL(Tongsuo) or BoringSSL.

    Build with BoringSSL

    sudo apt-get install -y build-essential libevent-dev

# get XQUIC source code
git clone https://github.com/alibaba/xquic.git; cd xquic

# get and build BoringSSL
git clone https://github.com/google/boringssl.git ./third_party/boringssl; cd ./third_party/boringssl
mkdir -p build && cd build
cmake -DBUILD_SHARED_LIBS=0 -DCMAKE_C_FLAGS="-fPIC" -DCMAKE_CXX_FLAGS="-fPIC" ..
make -j ssl crypto
cd ..
SSL_TYPE_STR="boringssl"
SSL_PATH_STR="${PWD}"
cd ../..

# build XQUIC with BoringSSL
# When build XQUIC with boringssl, by default XQUIC will use boringssl
# in third_party. If boringssl is deployed in other directories, SSL_PATH could be 
# used to specify the search path of boringssl
git submodule update --init --recursive
mkdir -p build; cd build
cmake -DGCOV=on -DCMAKE_BUILD_TYPE=Debug -DXQC_ENABLE_TESTING=1 -DXQC_SUPPORT_SENDMMSG_BUILD=1 -DXQC_ENABLE_EVENT_LOG=1 -DXQC_ENABLE_BBR2=1 -DXQC_ENABLE_RENO=1 -DSSL_TYPE=${SSL_TYPE_STR} -DSSL_PATH=${SSL_PATH_STR} ..

# exit if cmake error
if [ $? -ne 0 ]; then
    echo "cmake failed"
    exit 1
fi

make -j

    Build with BabaSSL(Tongsuo)

    sudo apt-get install -y build-essential libevent-dev

# get XQUIC source code
git clone https://github.com/alibaba/xquic.git; cd xquic

# get and build BabaSSL(Tongsuo)
git clone -b 8.3-stable https://github.com/Tongsuo-Project/Tongsuo.git ./third_party/babassl; cd ./third_party/babassl/
./config --prefix=/usr/local/babassl
make -j
SSL_TYPE_STR="babassl"
SSL_PATH_STR="${PWD}"
cd -

# build XQUIC with BabaSSL
# When build XQUIC with babassl, /usr/local/babassl directory will be searched
# as default. If babassl is deployed in other directories, SSL_PATH could be 
# used to specify the search path of babassl
git submodule update --init --recursive
mkdir -p build; cd build
cmake -DGCOV=on -DCMAKE_BUILD_TYPE=Debug -DXQC_ENABLE_TESTING=1 -DXQC_SUPPORT_SENDMMSG_BUILD=1 -DXQC_ENABLE_EVENT_LOG=1 -DXQC_ENABLE_BBR2=1 -DXQC_ENABLE_RENO=1 -DSSL_TYPE=${SSL_TYPE_STR} -DSSL_PATH=${SSL_PATH_STR} ..

# exit if cmake error
if [ $? -ne 0 ]; then
    echo "cmake failed"
    exit 1
fi

make -j

    Run testcases

    sh ../scripts/xquic_test.sh

    Documentation

    Contributing

    We would love for you to contribute to XQUIC and help make it even better than it is today! All types of contributions are encouraged and valued. Thanks to all contributors. See our Contributing Guidelines for more information.

    If you have any questions, please feel free to open a new Discussion topic in our discussion forums.

    License

    XQUIC is released under the Apache 2.0 License.

    Contact Us

    Feel free to contact us in the following ways:

    关于
    cshellcmake
    README.md
    32.4 MB
    邀请码
      Gitlink（确实开源）
    • 加入我们
    • 官网邮箱：gitlink@ccf.org.cn
      • QQ群
    • QQ群
      • 公众号
    • 公众号

    版权所有：中国计算机学会技术支持：开源发展技术委员会
    京ICP备13000930号-9 京公网安备 11010802047560号