busybox-w32/scripts, branch cng_backend

Use Windows library for cryptographic checksums

2025-06-09T12:23:49+00:00

Add a new feature to libbb, FEATURE_USE_CNG_API, which enables the use of the Cryptography API: Next Generation library to calculate checksums. It is disabled by default except in the mingw64u default config, as the API requires Windows 10+ to function. Usage of this API provides a size benefit and delegates hardware optimizations to the operating system cryptography library. Based on GitHub PR #498 by rfl890. Saves 4064 bytes in the mingw64u case.

Merge branch 'busybox' into merge

2025-05-19T07:34:32+00:00

archival: disallow path traversals (CVE-2023-39810)

2025-04-16T01:03:17+00:00

Create new configure option for archival/libarchive based extractions to disallow path traversals. As this is a paranoid option and might introduce backward incompatibility, default it to no. Fixes: CVE-2023-39810 Based on the patch by Peter Kaestle function old new delta data_extract_all 921 945 +24 strip_unsafe_prefix 101 102 +1 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/0 up/down: 25/0) Total: 25 bytes Signed-off-by: Denys Vlasenko

Update PDCurses

2025-04-10T18:41:43+00:00

Merge branch 'busybox' into merge

2024-09-28T07:13:32+00:00

fixdep: add fstat error handling

2024-09-27T18:03:30+00:00

When `fstat` fails, `st` is left uninitialised. In our case, Ben Kohler noticed our release media builds were failing in Gentoo on x86 when building busybox with occasional SIGBUS. This turned out to be EOVERFLOW (from 32-bit ino_t) which wasn't being reported because nothing was checking the return value from `fstat`. Fix that to avoid UB (use of uninit var) and to give a more friendly error to the user. This actually turns out to be fixed already in the kernel from back in 2010 [0] and 2016 [1]. [0] https://github.com/torvalds/linux/commit/a3ba81131aca243bfecfa78c42edec0cd69f72d6 [1] https://github.com/torvalds/linux/commit/46fe94ad18aa7ce6b3dad8c035fb538942020f2b Reported-by: Ben Kohler Signed-off-by: Sam James Signed-off-by: Denys Vlasenko

Merge branch 'busybox' into merge

2024-06-23T08:44:03+00:00

build system: fix ncurses detection

2024-04-28T14:48:03+00:00

Recent versions of gcc fail to build the binary to test for ncurses because main() is lacking a return type.

docproc: avoid segfault during file closing

2024-04-13T15:57:46+00:00

In the function find_export_symbols, since the fopen file does not exit when it fails, there is a dereference problem in fclose(fp), which will cause a segmentation fault. Signed-off-by: Yan Zhu Signed-off-by: Denys Vlasenko

win32: unicode: use newer wcwidth by default

2024-03-29T14:26:13+00:00

This commit adds a new wcwidth implementation at libbb/wcwidth_alt.c, and uses it instead of the existing implementation when compiling for windows and CONFIG_LAST_SUPPORTED_WCHAR >= 0x30000 - which is the case with the unicode configs/mingw64u_defconfig. The windows-target condition keeps non-windows build unmodified, and the last supported wchar threshold is a semi-hack to allow switching between implementations without adding a new config option (the old code supports codepoints up to 0x2ffff). The new file wcwidth_alt.c was generated by a new scripts/mkwcwidth, which prints a wcwidth implementation using latest unicode data from a local clone of https://github.com/jquast/wcwidth . This repo is the main python wcwidth implementation, and is maintained and up to date. Functional differences from the existing implementation: - Unicode 15.1.0 (latest) with the new version (about 450 ranges of wide and zero-width codepoints), compared to roughly Unicode 5.0 of the existing code (nearly 20 years old spec, about 150 ranges). The new spec includes, among others, various wide icons and emojis, which can now be edited correctly at the shell prompt, have correct alignment in 'ls', etc. - The old implementation returns -1 (non-printable) for surrogates, while the new code returns 1, though this is inconsequential, and POSIX doesn't care. Also libc implementations vary in this regard. Technical differences: - The old version compiles less code/data when the last supported wchar is smaller, while the new version doesn't. This doesn't matter because the new version is enabled only for the full range. - The new version is smaller and relatively straight forward, and fully automated (generated), so updates to newer spec is trivial. The old version mixes data, ad-hoc code (tailored to the data), and preprocessor checks, and is hard to automate updates. The old version has various forms of 32 and 16 bit data ranges, in several arrays, while the new version uses single data array with unified form of 32 bits per range, with two rules: - A data range can't span Unicode planes (enforced, but unlikely required, and if yes, code to split ranges would be simple). - A range can't hold more than 32768 codepoints, so bigger ranges are split automatically (currently there are 2 such ranges). Performance wise, the new version should be faster, even with three times the data ranges. Both versions do effectively at most one binary search in one Unicode plane data, but the new version finds both zero-width and wide-width results in this one search, while the old version only finds zero-width, and to detect wide-width it does an additional linear series of manual range tests, but since most results are width 1, this sequence is performed in most (non-ASCII) calls. In a cursory comparison of the new wcwidth with glibc and musl-libc (both use O(1) lookup tables), with few bodies of text, we're in the same ballpark, with typical speed of 60% or better. Bloat-wise, the new version is about 180 bytes code and 1800 bytes data. If it had similar number of data ranges as the old code (150), the new version would be about 200 bytes smaller, but because the new version has 450 data ranges, it's about 1K bigger.