From eggert at cs.ucla.edu Sun Jan 2 01:38:52 2022 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sat, 1 Jan 2022 17:38:52 -0800 Subject: BusyBox sed 'w' loses data on occasion Message-ID: <8df5171e-8b64-7a79-0e9b-523b9ab3b73c@cs.ucla.edu> This bug in BusyBox 'sed' broke a Gnulib-based build; see . The problem is that BusyBox 'sed' is confused about the 'w FILE' command. When there are multiple 'w FILE' commands (or 's/.../.../w FILE' commands) it opens FILE multiple times. This can lose data intended for FILE. Here is a simple shell transcript illustrating the problem: $ printf 'a\nb\n' | busybox sed -n -e '/a/w xxx' -e '/b/w xxx' $ cat xxx a The output should be: a b From alainm at pobox.com Mon Jan 3 13:57:50 2022 From: alainm at pobox.com (Alain Mouette) Date: Mon, 3 Jan 2022 10:57:50 -0300 Subject: BusyBox sed 'w' loses data on occasion In-Reply-To: <8df5171e-8b64-7a79-0e9b-523b9ab3b73c@cs.ucla.edu> References: <8df5171e-8b64-7a79-0e9b-523b9ab3b73c@cs.ucla.edu> Message-ID: <72200387-96ab-e7ac-db70-0253f7bbec2f@pobox.com> Tested here, Ubuntu 20.04: $? printf 'a\nb\n' | busybox sed -n -e '/a/w xxx' -e '/b/w xxx' ;cat xxx a $ uname -a Linux desktop 5.4.0-39-generic #43-Ubuntu SMP Fri Jun 19 10:28:31 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Em 01/01/2022 22:38, Paul Eggert escreveu: > This bug in BusyBox 'sed' broke a Gnulib-based build; see > . > > The problem is that BusyBox 'sed' is confused about the 'w FILE' > command. When there are multiple 'w FILE' commands (or 's/.../.../w > FILE' commands) it opens FILE multiple times. This can lose data > intended for FILE. Here is a simple shell transcript illustrating the > problem: > > $ printf 'a\nb\n' | busybox sed -n -e '/a/w xxx' -e '/b/w xxx' > $ cat xxx > a > > The output should be: > > a > b > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Tue Jan 4 18:43:31 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 4 Jan 2022 19:43:31 +0100 Subject: BusyBox sed 'w' loses data on occasion In-Reply-To: <8df5171e-8b64-7a79-0e9b-523b9ab3b73c@cs.ucla.edu> References: <8df5171e-8b64-7a79-0e9b-523b9ab3b73c@cs.ucla.edu> Message-ID: Fixed in git. On Sun, Jan 2, 2022 at 2:49 AM Paul Eggert wrote: > > This bug in BusyBox 'sed' broke a Gnulib-based build; see > . > > The problem is that BusyBox 'sed' is confused about the 'w FILE' > command. When there are multiple 'w FILE' commands (or 's/.../.../w > FILE' commands) it opens FILE multiple times. This can lose data > intended for FILE. Here is a simple shell transcript illustrating the > problem: > > $ printf 'a\nb\n' | busybox sed -n -e '/a/w xxx' -e '/b/w xxx' > $ cat xxx > a > > The output should be: > > a > b > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From rob at landley.net Thu Jan 6 00:00:25 2022 From: rob at landley.net (Rob Landley) Date: Wed, 5 Jan 2022 18:00:25 -0600 Subject: sort -h? Message-ID: <27c1eafe-9c41-b1bd-d358-547a720015e6@landley.net> We presumably got pinged by the same guy. Over on my side of the mirror https://github.com/landley/toybox/issues/184 and https://github.com/landley/toybox/issues/312 resulted me adding and then removing the feature again: commit b0a4a96e36da616dabff85917c0155b1dd59f45c Author: Rob Landley Date: Sun Jan 2 20:05:09 2022 -0600 Remove non-posix "sort -h". The man page says this is EXPECTED to be in the wrong order: $ echo -e '12345K\n1M' | sort -h 12345K 1M That's not how toybox treats numerical units anywhere else, and our options are to be incompatible with the broken gnu thing, inconsistent with the rest of toybox, or not have the broken non-posix feature. So yank it. 2 days later, busybox added sort -h, but I can't find any comment on the list about it? Rob From vda.linux at googlemail.com Thu Jan 6 09:37:29 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 6 Jan 2022 10:37:29 +0100 Subject: sort -h? In-Reply-To: <27c1eafe-9c41-b1bd-d358-547a720015e6@landley.net> References: <27c1eafe-9c41-b1bd-d358-547a720015e6@landley.net> Message-ID: Good day Rob. On Thu, Jan 6, 2022 at 12:59 AM Rob Landley wrote: > We presumably got pinged by the same guy. Over on my side of the mirror > https://github.com/landley/toybox/issues/184 and > https://github.com/landley/toybox/issues/312 resulted me adding and then > removing the feature again: > > commit b0a4a96e36da616dabff85917c0155b1dd59f45c > Author: Rob Landley > Date: Sun Jan 2 20:05:09 2022 -0600 > > Remove non-posix "sort -h". > > The man page says this is EXPECTED to be in the wrong order: > > $ echo -e '12345K\n1M' | sort -h > 12345K > 1M > > That's not how toybox treats numerical units anywhere else, and our options > are to be incompatible with the broken gnu thing, inconsistent with > the rest of toybox, or not have the broken non-posix feature. So yank it. I assume they want to be able to sort outputs like "df -h". In those cases, they assume the values are not "malformed" in the sense of using numbers like e.g. 3456K _and_ 2M in the same output. They assume the input has a fixed cutoff value where the output switches from "K" to "M". I think the idea is that with this logic, they don't need to assume whether "K" is 1000, 1024 or anything else. > 2 days later, busybox added sort -h, but I can't find any comment on the list > about it? There was a BZ: https://bugs.busybox.net/show_bug.cgi?id=14491 "Support sort -h" from someone called Kasper. I looked into how this can be made to work and it turned out to be rather easy. From vda.linux at googlemail.com Thu Jan 6 10:00:35 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 6 Jan 2022 11:00:35 +0100 Subject: [PATCH] fdisk: recognize EBBR protective partitions In-Reply-To: <20211213090718.18837-1-vincent.stehle@arm.com> References: <20211213090718.18837-1-vincent.stehle@arm.com> Message-ID: Applied, thanks On Mon, Dec 13, 2021 at 10:08 AM Vincent Stehl? wrote: > > The MBR partition type 0xF8 is used by the Arm EBBR specification[1] for > protective partitions over fixed-location firmware images. > > [1]: https://github.com/ARM-software/ebbr > > Signed-off-by: Vincent Stehl? > --- > util-linux/fdisk.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/util-linux/fdisk.c b/util-linux/fdisk.c > index 1c2a7d683..664830357 100644 > --- a/util-linux/fdisk.c > +++ b/util-linux/fdisk.c > @@ -355,6 +355,7 @@ static const char *const i386_sys_types[] ALIGN_PTR = { > "\xef" "EFI (FAT-12/16/32)", /* Intel EFI System Partition */ > "\xf0" "Linux/PA-RISC boot", /* Linux/PA-RISC boot loader */ > "\xf2" "DOS secondary", /* DOS 3.3+ secondary */ > + "\xf8" "EBBR protective", /* Arm EBBR firmware protective partition */ > "\xfd" "Linux raid autodetect", /* New (2.2.x) raid partition with > autodetect using persistent > superblock */ > -- > 2.33.0 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From emanuele.giacomelli at gmail.com Fri Jan 7 11:00:26 2022 From: emanuele.giacomelli at gmail.com (Emanuele Giacomelli) Date: Fri, 7 Jan 2022 12:00:26 +0100 Subject: [PATCH] XXXsum: handle binary sums with " " in the path Message-ID: <20220107110026.36603-1-emanuele.giacomelli@gmail.com> If a line specifies a binary checksum whose path contains two adjacent spaces, when checking digests with -c the two spaces will be used as the separator between the digest and the pathname instead of " *", as shown: $ echo foo > "/tmp/two spaces" $ md5sum -b "/tmp/two spaces" # This is GNU md5sum d3b07384d113edec49eaa6238ad5ff00 */tmp/two spaces $ md5sum -b "/tmp/two spaces" | ./busybox md5sum -c md5sum: can't open 'spaces': No such file or directory spaces: FAILED md5sum: WARNING: 1 of 1 computed checksums did NOT match The patch looks for both markers and uses the one that is closer to the start. --- coreutils/md5_sha1_sum.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/coreutils/md5_sha1_sum.c b/coreutils/md5_sha1_sum.c index 3b389cb6b..b7c1495d2 100644 --- a/coreutils/md5_sha1_sum.c +++ b/coreutils/md5_sha1_sum.c @@ -298,12 +298,17 @@ int md5_sha1_sum_main(int argc UNUSED_PARAM, char **argv) while ((line = xmalloc_fgetline(pre_computed_stream)) != NULL) { uint8_t *hash_value; char *filename_ptr; + char *filename_ptr_bin; count_total++; filename_ptr = strstr(line, " "); /* handle format for binary checksums */ + filename_ptr_bin = strstr(line, " *"); if (filename_ptr == NULL) { - filename_ptr = strstr(line, " *"); + filename_ptr = filename_ptr_bin; + } else { + filename_ptr = (filename_ptr_bin != NULL && filename_ptr_bin < filename_ptr) ? + filename_ptr_bin : filename_ptr; } if (filename_ptr == NULL) { if (flags & FLAG_WARN) { -- 2.34.1 From David.Laight at ACULAB.COM Fri Jan 7 11:16:23 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Fri, 7 Jan 2022 11:16:23 +0000 Subject: [PATCH] XXXsum: handle binary sums with " " in the path In-Reply-To: <20220107110026.36603-1-emanuele.giacomelli@gmail.com> References: <20220107110026.36603-1-emanuele.giacomelli@gmail.com> Message-ID: From: Emanuele Giacomelli > Sent: 07 January 2022 11:00 > > If a line specifies a binary checksum whose path contains two adjacent > spaces, when checking digests with -c the two spaces will be used as the > separator between the digest and the pathname instead of " *", as shown: > > $ echo foo > "/tmp/two spaces" > $ md5sum -b "/tmp/two spaces" # This is GNU md5sum > d3b07384d113edec49eaa6238ad5ff00 */tmp/two spaces > $ md5sum -b "/tmp/two spaces" | ./busybox md5sum -c > md5sum: can't open 'spaces': No such file or directory > spaces: FAILED > md5sum: WARNING: 1 of 1 computed checksums did NOT match > > The patch looks for both markers and uses the one that is closer to the > start. > --- > coreutils/md5_sha1_sum.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/coreutils/md5_sha1_sum.c b/coreutils/md5_sha1_sum.c > index 3b389cb6b..b7c1495d2 100644 > --- a/coreutils/md5_sha1_sum.c > +++ b/coreutils/md5_sha1_sum.c > @@ -298,12 +298,17 @@ int md5_sha1_sum_main(int argc UNUSED_PARAM, char **argv) > while ((line = xmalloc_fgetline(pre_computed_stream)) != NULL) { > uint8_t *hash_value; > char *filename_ptr; > + char *filename_ptr_bin; > > count_total++; > filename_ptr = strstr(line, " "); > /* handle format for binary checksums */ > + filename_ptr_bin = strstr(line, " *"); > if (filename_ptr == NULL) { > - filename_ptr = strstr(line, " *"); > + filename_ptr = filename_ptr_bin; > + } else { > + filename_ptr = (filename_ptr_bin != NULL && filename_ptr_bin < > filename_ptr) ? > + filename_ptr_bin : filename_ptr; Wouldn't it be easier to just use strchr() to find a ' ' and then check the next character for ' ' or '*' ? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From emanuele.giacomelli at gmail.com Fri Jan 7 13:17:48 2022 From: emanuele.giacomelli at gmail.com (Emanuele Giacomelli) Date: Fri, 7 Jan 2022 14:17:48 +0100 Subject: [PATCH v2] XXXsum: handle binary sums with " " in the path In-Reply-To: References: Message-ID: <20220107131748.61103-1-emanuele.giacomelli@gmail.com> If a line specifies a binary checksum whose path contains two adjacent spaces, when checking digests with -c the two spaces will be used as the separator between the digest and the pathname instead of " *", as shown: $ echo foo > "/tmp/two spaces" $ md5sum -b "/tmp/two spaces" # This is GNU md5sum d3b07384d113edec49eaa6238ad5ff00 */tmp/two spaces $ md5sum -b "/tmp/two spaces" | ./busybox md5sum -c md5sum: can't open 'spaces': No such file or directory spaces: FAILED md5sum: WARNING: 1 of 1 computed checksums did NOT match --- coreutils/md5_sha1_sum.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/coreutils/md5_sha1_sum.c b/coreutils/md5_sha1_sum.c index 3b389cb6b..d0ea719f3 100644 --- a/coreutils/md5_sha1_sum.c +++ b/coreutils/md5_sha1_sum.c @@ -300,12 +300,8 @@ int md5_sha1_sum_main(int argc UNUSED_PARAM, char **argv) char *filename_ptr; count_total++; - filename_ptr = strstr(line, " "); - /* handle format for binary checksums */ - if (filename_ptr == NULL) { - filename_ptr = strstr(line, " *"); - } - if (filename_ptr == NULL) { + filename_ptr = strchr(line, ' '); + if (filename_ptr == NULL || (filename_ptr[1] != ' ' && filename_ptr[1] != '*')) { if (flags & FLAG_WARN) { bb_simple_error_msg("invalid format"); } -- 2.34.1 From vda.linux at googlemail.com Sat Jan 8 16:16:54 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 8 Jan 2022 17:16:54 +0100 Subject: [PATCH v2] XXXsum: handle binary sums with " " in the path In-Reply-To: <20220107131748.61103-1-emanuele.giacomelli@gmail.com> References: <20220107131748.61103-1-emanuele.giacomelli@gmail.com> Message-ID: Applied, thank you On Fri, Jan 7, 2022 at 2:18 PM Emanuele Giacomelli wrote: > > If a line specifies a binary checksum whose path contains two adjacent > spaces, when checking digests with -c the two spaces will be used as the > separator between the digest and the pathname instead of " *", as shown: > > $ echo foo > "/tmp/two spaces" > $ md5sum -b "/tmp/two spaces" # This is GNU md5sum > d3b07384d113edec49eaa6238ad5ff00 */tmp/two spaces > $ md5sum -b "/tmp/two spaces" | ./busybox md5sum -c > md5sum: can't open 'spaces': No such file or directory > spaces: FAILED > md5sum: WARNING: 1 of 1 computed checksums did NOT match > --- > coreutils/md5_sha1_sum.c | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/coreutils/md5_sha1_sum.c b/coreutils/md5_sha1_sum.c > index 3b389cb6b..d0ea719f3 100644 > --- a/coreutils/md5_sha1_sum.c > +++ b/coreutils/md5_sha1_sum.c > @@ -300,12 +300,8 @@ int md5_sha1_sum_main(int argc UNUSED_PARAM, char **argv) > char *filename_ptr; > > count_total++; > - filename_ptr = strstr(line, " "); > - /* handle format for binary checksums */ > - if (filename_ptr == NULL) { > - filename_ptr = strstr(line, " *"); > - } > - if (filename_ptr == NULL) { > + filename_ptr = strchr(line, ' '); > + if (filename_ptr == NULL || (filename_ptr[1] != ' ' && filename_ptr[1] != '*')) { > if (flags & FLAG_WARN) { > bb_simple_error_msg("invalid format"); > } > -- > 2.34.1 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From rob at landley.net Mon Jan 10 14:05:01 2022 From: rob at landley.net (Rob Landley) Date: Mon, 10 Jan 2022 08:05:01 -0600 Subject: sort -h? In-Reply-To: References: <27c1eafe-9c41-b1bd-d358-547a720015e6@landley.net> Message-ID: <30b4e298-4073-f24f-4b41-25cd796a5f49@landley.net> On 1/6/22 3:37 AM, Denys Vlasenko wrote: > Good day Rob. > > On Thu, Jan 6, 2022 at 12:59 AM Rob Landley wrote: >> We presumably got pinged by the same guy. Over on my side of the mirror >> https://github.com/landley/toybox/issues/184 and >> https://github.com/landley/toybox/issues/312 resulted me adding and then >> removing the feature again: >> >> commit b0a4a96e36da616dabff85917c0155b1dd59f45c >> Author: Rob Landley >> Date: Sun Jan 2 20:05:09 2022 -0600 >> >> Remove non-posix "sort -h". >> >> The man page says this is EXPECTED to be in the wrong order: >> >> $ echo -e '12345K\n1M' | sort -h >> 12345K >> 1M >> >> That's not how toybox treats numerical units anywhere else, and our options >> are to be incompatible with the broken gnu thing, inconsistent with >> the rest of toybox, or not have the broken non-posix feature. So yank it. > > I assume they want to be able to sort outputs like "df -h". > In those cases, they assume the values are not "malformed" > in the sense of using numbers like e.g. 3456K _and_ 2M > in the same output. They assume the input has a fixed cutoff > value where the output switches from "K" to "M". If "malformed input" is not considered a valid test, then me actually getting the result _right_ when coreutils gets it wrong shouldn't be a notable incompatiblity, so I guess I could put it back. But: $ echo -e '999999K\n1M' | sort -h 999999K 1M $ echo -e '999999k\n1m' | sort -h 1m 999999k The reason coreutils gets the second one right is it doesn't recognize lower case k and m. I am NOT implementing an exact match to that behavior. (Mine was case insensitive for the suffixes, so MULTIPLE types of incompatible already...) > I think the idea is that with this logic, they don't need to assume > whether "K" is 1000, 1024 or anything else. $ toybox --help | tail -n 6 Numerical arguments accept a single letter suffix for kilo, mega, giga, tera, peta, and exabytes, plus an additional "d" to indicate decimal 1000's instead of 1024. Durations can be decimal fractions and accept minute ("m"), hour ("h"), or day ("d") suffixes (so 0.1m = 6s). Toybox has defined behavior and tries to be internally consistent: if it's decimal it has a d. I'm aware of compatablity with historical implementations that don't, that posix has holes you can drive a truck through, and that the Linux Foundation strangled the Linux Standard Base to the point wikipedia[citation needed] refers to the project entirely in the past tense. But toybox being incompatible with TOYBOX makes my teeth hurt. >> 2 days later, busybox added sort -h, but I can't find any comment on the list >> about it? > > There was a BZ: https://bugs.busybox.net/show_bug.cgi?id=14491 > "Support sort -h" from someone called Kasper. Yup, same guy: https://github.com/landley/toybox/issues/312 Picked it up from this guy: https://github.com/landley/toybox/issues/184 > I looked into how this can be made to work and it turned out to be rather easy. It was easy for me too, it just wasn't RIGHT. :) I'm not questioning your decision: you're compatible with coreutils in the edge case, and that's the side busybox has erred on forever. That's right for YOU. I just need to figure out what to do in MY project. I was hoping that you hadn't noticed and implemented the non-crazy behavior so I could then use that as an excuse to put back MY non-crazy behavior, but no... So I need to figure out if it's better (for toybox) to: A) have the feature compatible with the rest of toybox B) have the feature incompatible with the rest of toybox C) not have the feature /me wanders off back to my side of things... Thanks for the time, Rob P.S. heads up https://lists.gnu.org/archive/html/coreutils/2022-01/msg00008.html From dahanna at sandia.gov Mon Jan 10 22:33:29 2022 From: dahanna at sandia.gov (Hannasch, David Alexander) Date: Mon, 10 Jan 2022 22:33:29 +0000 Subject: wget TLS error from peer (alert code 40): handshake failure on TLS 1.2 and TLS 1.3 X25519 AES256-GCM In-Reply-To: References: Message-ID: package: busybox version: 1.35.0 When I execute busybox 'wget' it is unable to handshake with a TLS 1.3 X25519 AES256-GCM host. I have not been able to build busybox from source, so I am using the busybox:1.35.0 container. I have been using the following scripting: test-busybox: tags: - docker image: busybox:1.35.0 script: - find / -name *libtls* - find / -name *libretls* - wget $TLS_13_URL test-alpine: tags: - docker image: alpine:3.15.0 script: - find / -name *libtls* # /usr/lib/libtls.so.2.0.0 - find / -name *libretls* - wget $TLS_13_URL If you're not familiar with GitLab YAML, all that matters is the image name and the script. It's just loading busybox:1.35.0 and trying to wget. Using Ubuntu, CentOS, or Alpine, wget works fine on this URL. $ wget $TLS_13_URL saving to 'index.html' index.html 100% |********************************| 32211 0:00:00 ETA 'index.html' saved Using busybox:1.35.0, wget fails. $ wget $TLS_13_URL wget: TLS error from peer (alert code 40): handshake failure wget: error getting response: Connection reset by peer (If it matters, 1.34.1 fails the same way.) Unfortunately I do not know of a public-facing URL that supports only TLS 1.2 and 1.3, but I expect that wget will fail in the same way. If desired, I have a great deal more information on the supported TLS below. As mentioned, Ubuntu/CentOS/Alpine are all able to use wget just fine. Alpine is the most interesting, since Alpine actually uses BusyBox 1.34.1. It looks like they rebuilt against a newer version of libtls. https://gitlab.alpinelinux.org/alpine/aports/-/issues/11695 BusyBox doesn't appear (?) to be using libtls, or at least, I haven't found reference to it in the source, so I'm not sure whether a similar solution would work outside of Alpine. Thank you, David Hannasch The promised details on the server are: $ openssl s_client -connect $INTERNAL_HOST:443 -tls1_3 CONNECTED(00000003) depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 --- Certificate chain ... No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 6990 bytes and written 325 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit Secure Renegotiation IS NOT supported No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- DONE $ openssl s_client -connect $INTERNAL_HOST:443 -tls1_2 CONNECTED(00000003) depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 6898 bytes and written 309 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305 Server public key is 4096 bit Secure Renegotiation IS supported No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-CHACHA20-POLY1305 Verify return code: 0 (ok) Extended master secret: yes --- DONE $ openssl s_client -connect $INTERNAL_HOST:443 -tls1_1 || echo "TLS 1.1 is not supported." CONNECTED(00000003) --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 134 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1641851758 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- TLS 1.1 is not supported. $ nmap --script ssl-enum-ciphers -p 443 $INTERNAL_HOST Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-10 21:55 UTC Host is up (0.0011s latency). PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | compressors: | NULL | cipher preference: server | warnings: | Key exchange (ecdh_x25519) of lower strength than certificate key | TLSv1.3: | ciphers: | TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | cipher preference: server |_ least strength: A Nmap done: 1 IP address (1 host up) scanned in 0.50 seconds If there are some TLS's that BusyBox does not support, is that documented anywhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahanna at sandia.gov Tue Jan 11 18:34:38 2022 From: dahanna at sandia.gov (Hannasch, David Alexander) Date: Tue, 11 Jan 2022 18:34:38 +0000 Subject: wget TLS error from peer (alert code 40): handshake failure on TLS 1.2 and TLS 1.3 X25519 AES256-GCM In-Reply-To: References: Message-ID: Sorry for the separate messages, but I said something wrong before. It's not quite a matter of TLS version per se, I don't think. I tried with a host that supports only TLS 1.2, and busybox wget worked. In this case, nmap showed: $ nmap --script ssl-enum-ciphers -p 443 $INTERNAL_HOST Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-11 17:52 UTC Nmap scan report for [MASKED] Host is up (0.0011s latency). PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | compressors: | NULL | cipher preference: client |_ least strength: A Nmap done: 1 IP address (1 host up) scanned in 0.85 seconds And busybox:1.35.0 worked: $ wget --proxy off http://$USERNAME:$PASSWORD@$INTERNAL_HOST Connecting to [MASKED] (:80) Connecting to [MASKED] (:443) wget: note: TLS certificate validation not implemented saving to 'index.html' index.html 100% |********************************| 45427 0:00:00 ETA 'index.html' saved I think maybe it's a particular cipher that busybox doesn't work with. This other host has TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) but also has a lot of other things. I don't know how to tell which cipher busybox wget is actually using. I haven't found any documentation on how the TLS is done, but I did find https://git.busybox.net/busybox/tree/networking/tls.c#n1503 //TODO: GCM_SHA384 ciphers can be supported, only need sha384-based PRF? #if ALLOW_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xC0,0x2F, // 8 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - ok: openssl s_server ... -cipher ECDHE-RSA-AES128-GCM-SHA256 #endif // 0xC0,0x30, // TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - openssl s_server ... -cipher ECDHE-RSA-AES256-GCM-SHA384: "decryption failed or bad record mac" This looks promising! It looks like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is currently commented out of the function send_client_hello_and_alloc_hsd with a TODO noting that all it requires is a SHA384-based Pseudo-Random Function. https://git.busybox.net/busybox/tree/networking/tls.c#n518 // RFC 5246: // 5. HMAC and the Pseudorandom Function //... // In this section, we define one PRF, based on HMAC. This PRF with the // SHA-256 hash function is used for all cipher suites defined in this // document and in TLS documents published prior to this document when // TLS 1.2 is negotiated. // ^^^^^^^^^^^^^ IMPORTANT! // PRF uses sha256 regardless of cipher for all ciphers // defined by RFC 5246. It's not sha1 for AES_128_CBC_SHA! // However, for _SHA384 ciphers, it's sha384. See RFC 5288,5289. // RFC 5288: // For cipher suites ending with _SHA256, the PRF is the TLS PRF // with SHA-256 as the hash function. // For cipher suites ending with _SHA384, the PRF is the TLS PRF // with SHA-384 as the hash function. static void prf_hmac_sha256(/*tls_state_t *tls,*/ It looks like that's where the SHA256 PRF is implemented. I now *think* that it's a question of having a prf_hmac_sha384 and using it to enable TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 alongside TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. It looks like ecdh_x25519 is already supported: https://git.busybox.net/busybox/tree/networking/tls.c#n1543 #if ALLOW_CURVE_X25519 0x00,0x1d, //curve_x25519 (RFC 7748) #endif (assuming the code is compiled with ALLOW_CURVE_X25519) https://git.busybox.net/busybox/commit/?id=d4681c7293da6aeb901101b5bc239229f4963926 From: Hannasch, David Alexander Sent: Monday, January 10, 2022 3:33 PM To: busybox at busybox.net Subject: wget TLS error from peer (alert code 40): handshake failure on TLS 1.2 and TLS 1.3 X25519 AES256-GCM package: busybox version: 1.35.0 When I execute busybox 'wget' it is unable to handshake with a TLS 1.3 X25519 AES256-GCM host. I have not been able to build busybox from source, so I am using the busybox:1.35.0 container. I have been using the following scripting: test-busybox: tags: - docker image: busybox:1.35.0 script: - find / -name *libtls* - find / -name *libretls* - wget $TLS_13_URL test-alpine: tags: - docker image: alpine:3.15.0 script: - find / -name *libtls* # /usr/lib/libtls.so.2.0.0 - find / -name *libretls* - wget $TLS_13_URL If you're not familiar with GitLab YAML, all that matters is the image name and the script. It's just loading busybox:1.35.0 and trying to wget. Using Ubuntu, CentOS, or Alpine, wget works fine on this URL. $ wget $TLS_13_URL saving to 'index.html' index.html 100% |********************************| 32211 0:00:00 ETA 'index.html' saved Using busybox:1.35.0, wget fails. $ wget $TLS_13_URL wget: TLS error from peer (alert code 40): handshake failure wget: error getting response: Connection reset by peer (If it matters, 1.34.1 fails the same way.) Unfortunately I do not know of a public-facing URL that supports only TLS 1.2 and 1.3, but I expect that wget will fail in the same way. If desired, I have a great deal more information on the supported TLS below. As mentioned, Ubuntu/CentOS/Alpine are all able to use wget just fine. Alpine is the most interesting, since Alpine actually uses BusyBox 1.34.1. It looks like they rebuilt against a newer version of libtls. https://gitlab.alpinelinux.org/alpine/aports/-/issues/11695 BusyBox doesn't appear (?) to be using libtls, or at least, I haven't found reference to it in the source, so I'm not sure whether a similar solution would work outside of Alpine. Thank you, David Hannasch The promised details on the server are: $ openssl s_client -connect $INTERNAL_HOST:443 -tls1_3 CONNECTED(00000003) depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 --- Certificate chain ... No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 6990 bytes and written 325 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit Secure Renegotiation IS NOT supported No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- DONE $ openssl s_client -connect $INTERNAL_HOST:443 -tls1_2 CONNECTED(00000003) depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 6898 bytes and written 309 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305 Server public key is 4096 bit Secure Renegotiation IS supported No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-CHACHA20-POLY1305 Verify return code: 0 (ok) Extended master secret: yes --- DONE $ openssl s_client -connect $INTERNAL_HOST:443 -tls1_1 || echo "TLS 1.1 is not supported." CONNECTED(00000003) --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 134 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1641851758 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- TLS 1.1 is not supported. $ nmap --script ssl-enum-ciphers -p 443 $INTERNAL_HOST Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-10 21:55 UTC Host is up (0.0011s latency). PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | compressors: | NULL | cipher preference: server | warnings: | Key exchange (ecdh_x25519) of lower strength than certificate key | TLSv1.3: | ciphers: | TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | cipher preference: server |_ least strength: A Nmap done: 1 IP address (1 host up) scanned in 0.50 seconds If there are some TLS's that BusyBox does not support, is that documented anywhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From raj.khem at gmail.com Wed Jan 12 18:54:54 2022 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 12 Jan 2022 10:54:54 -0800 Subject: [PATCH] apply const trick to ptr_to_globals Message-ID: <20220112185454.2712195-1-raj.khem@gmail.com> This was missing in the previous attempt to fix it via [1] This helps fix segfaults when compiling with clang ( seen on riscv64 ) [ 452.428349] less[270]: unhandled signal 11 code 0x1 at 0x000000000000000c in busybox.nosuid[2ab7491000+ba000] [ 452.430246] CPU: 3 PID: 270 Comm: less Not tainted 5.15.13-yocto-standard #1 [ 452.431323] Hardware name: riscv-virtio,qemu (DT) [ 452.431925] epc : 0000002ab74a19ee ra : 0000002ab74a19dc sp : 0000003fec6ec980 [ 452.432725] gp : 0000002ab754dcb0 tp : 0000003f88783800 t0 : 0000003f8878d4a0 [ 452.433744] t1 : 0000002ab749b00c t2 : 0000000000000000 s0 : 0000003fec6ecc38 [ 452.434732] s1 : 000000000000004c a0 : 00000000ffffffff a1 : 0000002ab754dde0 [ 452.435861] a2 : 0000000000000000 a3 : 0000000000000100 a4 : 0000002ab754f3a0 [ 452.436787] a5 : 0000002ab754f3a0 a6 : 0000000000000000 a7 : 0000002ab754f2a0 [ 452.437974] s2 : 0000000000000002 s3 : 0000002ab754b6c8 s4 : 0000002ab749b60e [ 452.438781] s5 : 0000000000000000 s6 : 0000002ab754b6c8 s7 : 0000003f88943060 [ 452.439723] s8 : 0000003f88944050 s9 : 0000002ad8502e88 s10: 0000002ad8502de8 [ 452.440538] s11: 0000000000000014 t3 : 0000003f887fceb6 t4 : 0000003f8893af0c [ 452.441438] t5 : 0000000000000000 t6 : 0000003f88923000 [1] https://git.busybox.net/busybox/commit/?id=1f925038a Signed-off-by: Khem Raj --- include/libbb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/libbb.h b/include/libbb.h index daa310776..4372f6826 100644 --- a/include/libbb.h +++ b/include/libbb.h @@ -2284,7 +2284,7 @@ struct globals; /* '*const' ptr makes gcc optimize code much better. * Magic prevents ptr_to_globals from going into rodata. * If you want to assign a value, use SET_PTR_TO_GLOBALS(x) */ -extern struct globals *const ptr_to_globals; +extern struct globals *BB_GLOBAL_CONST ptr_to_globals; #define barrier() asm volatile ("":::"memory") -- 2.34.1 From ariadne at dereferenced.org Fri Jan 14 16:23:45 2022 From: ariadne at dereferenced.org (Ariadne Conill) Date: Fri, 14 Jan 2022 10:23:45 -0600 Subject: [PATCH] ash: add built-in $BB_ASH_VERSION variable Message-ID: <20220114162345.5117-1-ariadne@dereferenced.org> This is helpful for detecting if the shell is busybox ash or not, which is necessary for enabling ash-specific features in /etc/profile and Alpine's default $ENV. https://gitlab.alpinelinux.org/alpine/aports/-/issues/12398 outlines the rationale for detecting what shell is running in /etc/profile and similar. function old new delta .rodata 77899 77925 +26 varinit_data 360 384 +24 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/0 up/down: 50/0) Total: 50 bytes Signed-off-by: Ariadne Conill --- shell/ash.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/shell/ash.c b/shell/ash.c index ca5c755b6..b3f64383b 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -153,6 +153,14 @@ //config: you to run the specified command or builtin, //config: even when there is a function with the same name. //config: +//config:config ASH_VERSION_VAR +//config: bool "declare $BB_ASH_VERSION variable" +//config: default y +//config: depends on SHELL_ASH +//config: help +//config: Enable support for declaring the $BB_ASH_VERSION variable, +//config: which is set as the busybox version. +//config: //config:endif # ash options //applet:IF_ASH(APPLET(ash, BB_DIR_BIN, BB_SUID_DROP)) @@ -2138,6 +2146,9 @@ static const struct { { VSTRFIXED|VTEXTFIXED , "PS1=$ " , NULL }, { VSTRFIXED|VTEXTFIXED , "PS2=> " , NULL }, { VSTRFIXED|VTEXTFIXED , "PS4=+ " , NULL }, +#if ENABLE_ASH_VERSION_VAR + { VSTRFIXED|VTEXTFIXED , "BB_ASH_VERSION=" BB_VER, NULL }, +#endif #if ENABLE_ASH_GETOPTS { VSTRFIXED|VTEXTFIXED , defoptindvar, getoptsreset }, #endif @@ -2197,19 +2208,20 @@ extern struct globals_var *BB_GLOBAL_CONST ash_ptr_to_globals_var; #define vps1 varinit[VAR_OFFSET1 + 2] #define vps2 varinit[VAR_OFFSET1 + 3] #define vps4 varinit[VAR_OFFSET1 + 4] +#define VAR_OFFSET2 (VAR_OFFSET1 + ENABLE_ASH_VERSION_VAR) #if ENABLE_ASH_GETOPTS -# define voptind varinit[VAR_OFFSET1 + 5] +# define voptind varinit[VAR_OFFSET2 + 5] #endif -#define VAR_OFFSET2 (VAR_OFFSET1 + ENABLE_ASH_GETOPTS) -#define vlineno varinit[VAR_OFFSET2 + 5] -#define vfuncname varinit[VAR_OFFSET2 + 6] +#define VAR_OFFSET3 (VAR_OFFSET2 + ENABLE_ASH_GETOPTS) +#define vlineno varinit[VAR_OFFSET3 + 5] +#define vfuncname varinit[VAR_OFFSET3 + 6] #if ENABLE_ASH_RANDOM_SUPPORT -# define vrandom varinit[VAR_OFFSET2 + 7] +# define vrandom varinit[VAR_OFFSET3 + 7] #endif -#define VAR_OFFSET3 (VAR_OFFSET2 + ENABLE_ASH_RANDOM_SUPPORT) +#define VAR_OFFSET4 (VAR_OFFSET2 + ENABLE_ASH_RANDOM_SUPPORT) #if BASH_EPOCH_VARS -# define vepochs varinit[VAR_OFFSET3 + 7] -# define vepochr varinit[VAR_OFFSET3 + 8] +# define vepochs varinit[VAR_OFFSET4 + 7] +# define vepochr varinit[VAR_OFFSET4 + 8] #endif #define INIT_G_var() do { \ unsigned i; \ -- 2.34.1 From yetanothergeek at gmail.com Fri Jan 21 01:36:01 2022 From: yetanothergeek at gmail.com (Jeff Pohlmeyer) Date: Thu, 20 Jan 2022 19:36:01 -0600 Subject: Error with make_single_applets and CONFIG_FEATURE_CUT_REGEX Message-ID: I am getting a failure when CONFIG_FEATURE_CUT_REGEX=y is enabled: ./make_single_applets.sh CUT cut.c:(.text.cut_main+0x205): undefined reference to `xregcomp' It looks like adding this line: lib-$(CONFIG_FEATURE_CUT_REGEX) += xregcomp.o around line ~203 in ./libbb/Kbuild.src solves the problem. - Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Link-xregcomp.o-when-CONFIG_FEATURE_CUT_REGEX-y.patch Type: text/x-patch Size: 744 bytes Desc: not available URL: From timo.teras at iki.fi Fri Jan 21 11:17:00 2022 From: timo.teras at iki.fi (=?UTF-8?q?Timo=20Ter=C3=A4s?=) Date: Fri, 21 Jan 2022 13:17:00 +0200 Subject: [PATCH] mkfs.vfat: fix volume label to be padded with space Message-ID: <20220121111700.34182-1-timo.teras@iki.fi> The specification requires volume label to be zero padded. Latest fsck.vfat will remove the zero padded volume label as invalid. See also: https://github.com/dosfstools/dosfstools/issues/172 Make the default label also "NO NAME" which has the special meaning that label is not set. function old new delta mkfs_vfat_main 1546 1665 +119 .rodata 79474 79480 +6 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 2/0 up/down: 125/0) Total: 125 bytes --- Also the volume label should not contain certain special character, or low case alphabet. However, seems lower case is allowed still by default in fsck.vfat, and the special characters are a bit of corner case. So I decided to not add checking for these. util-linux/mkfs_vfat.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/util-linux/mkfs_vfat.c b/util-linux/mkfs_vfat.c index 844d965f8..fc256b903 100644 --- a/util-linux/mkfs_vfat.c +++ b/util-linux/mkfs_vfat.c @@ -219,7 +219,8 @@ int mkfs_vfat_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE; int mkfs_vfat_main(int argc UNUSED_PARAM, char **argv) { struct stat st; - const char *volume_label = ""; + const char *arg_volume_label = "NO NAME "; + char volume_label[12]; char *buf; char *device_name; uoff_t volume_size_bytes; @@ -258,13 +259,14 @@ int mkfs_vfat_main(int argc UNUSED_PARAM, char **argv) "Ab:cCf:F:h:Ii:l:m:n:r:R:s:S:v" "\0" "-1", //:b+:f+:F+:h+:r+:R+:s+:S+:vv:c--l:l--c NULL, NULL, NULL, NULL, NULL, - NULL, NULL, &volume_label, NULL, NULL, NULL, NULL); + NULL, NULL, &arg_volume_label, NULL, NULL, NULL, NULL); argv += optind; // cache device name device_name = argv[0]; // default volume ID = creation time volume_id = time(NULL); + snprintf(volume_label, sizeof(volume_label), "%-11s", arg_volume_label); dev = xopen(device_name, O_RDWR); xfstat(dev, &st, device_name); @@ -508,7 +510,7 @@ int mkfs_vfat_main(int argc UNUSED_PARAM, char **argv) STORE_LE(boot_blk->vi.ext_boot_sign, 0x29); STORE_LE(boot_blk->vi.volume_id32, volume_id); memcpy(boot_blk->vi.fs_type, "FAT32 ", sizeof(boot_blk->vi.fs_type)); - strncpy(boot_blk->vi.volume_label, volume_label, sizeof(boot_blk->vi.volume_label)); + memcpy(boot_blk->vi.volume_label, volume_label, sizeof(boot_blk->vi.volume_label)); memcpy(boot_blk->boot_code, boot_code, sizeof(boot_code)); STORE_LE(boot_blk->boot_sign, BOOT_SIGN); @@ -553,7 +555,7 @@ int mkfs_vfat_main(int argc UNUSED_PARAM, char **argv) uint16_t t, d; #endif de = (void*)buf; - strncpy(de->name, volume_label, sizeof(de->name)); + memcpy(de->name, volume_label, sizeof(de->name)); STORE_LE(de->attr, ATTR_VOLUME); #if 0 localtime_r(&create_time, &tm_time); -- 2.34.1 From walter.lozano at collabora.com Fri Jan 21 14:00:27 2022 From: walter.lozano at collabora.com (Walter Lozano) Date: Fri, 21 Jan 2022 11:00:27 -0300 Subject: [PATCH] Add support for long options to cmp Message-ID: <20220121140027.623872-1-walter.lozano@collabora.com> In order to improve compatibility with GNU cmp add support for long options to busybox cmp. Signed-off-by: Walter Lozano --- editors/cmp.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/editors/cmp.c b/editors/cmp.c index 6d2b0c6c3..6eaed59fe 100644 --- a/editors/cmp.c +++ b/editors/cmp.c @@ -54,12 +54,25 @@ int cmp_main(int argc UNUSED_PARAM, char **argv) int retval = 0; int max_count = -1; - opt = getopt32(argv, "^" +#if ENABLE_LONG_OPTS + static const char cmp_longopts[] ALIGN1 = + "bytes\0" Required_argument "n" + "quiet\0" No_argument "s" + "silent\0" No_argument "s" + "verbose\0" No_argument "l" + ; +# define LONGOPTS cmp_longopts +#else +# define LONGOPTS NULL +#endif + + opt = getopt32long(argv, "^" OPT_STR "\0" "-1" IF_DESKTOP(":?4") IF_NOT_DESKTOP(":?2") ":l--s:s--l", + LONGOPTS, &max_count ); argv += optind; -- 2.25.1 From obel at mailoo.org Sat Jan 22 10:52:07 2022 From: obel at mailoo.org (obel at mailoo.org) Date: Sat, 22 Jan 2022 11:52:07 +0100 (CET) Subject: Problem start computer, stop in busybox Message-ID: Hi, I have a laptop with ubuntu. When I start it, it stop with the message: BusyBox v1.21.1 (Ubuntu 1:1.21.0-1ubuntu1.4) built-in shell (ash) Enter 'Help' for a list of built-in commandes. (initramfs) _ If I try to exit the program, a long comand list appear which begin by: Kernel panic - not syncing: Attempt to kill init! Exit code=0x00000200 Can you please, tell me how use Busy to solve my problem, if is it possible. Thanks a lot for advance. All the best. Isabelle Isabelle Bourgait ?? OBEL - Artiste de la Vie Cr?ation de la Ki-Regeneration? Le Mouvement de l'Humanit? Fraternelle Vivre dans la Paix De la Paix Individuelle, Source de la sant? : https://ArtScienceCreativite.info/ A la Paix Collective, Harmonie avec le monde : https://Planet-Human.org/ Isabelle Bourgait ?? OBEL - Artiste de la Vie Cr?ation de la Ki-Regeneration? Le Mouvement de l'Humanit? Fraternelle Vivre dans la Paix De la Paix Individuelle, Source de la sant? : https://ArtScienceCreativite.info/ A la Paix Collective, Harmonie avec le monde : https://Planet-Human.org/ BusyBox v1.21.1 (Ubuntu 1:1.21.0-1ubuntu1.4) built-in shell (ash) Enter 'help' for a liste built-in commands. (initramfs) _ If I try to existe the problem, a long message appre Isabelle Bourgait ?? OBEL - Artiste de la Vie Cr?ation de la Ki-Regeneration? Le Mouvement de l'Humanit? Fraternelle Vivre dans la Paix De la Paix Individuelle, Source de la sant? : https://ArtScienceCreativite.info/ A la Paix Collective, Harmonie avec le monde : https://Planet-Human.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yetanothergeek at gmail.com Sat Jan 22 11:39:59 2022 From: yetanothergeek at gmail.com (Jeff Pohlmeyer) Date: Sat, 22 Jan 2022 05:39:59 -0600 Subject: Problem start computer, stop in busybox In-Reply-To: References: Message-ID: On Sat, Jan 22, 2022 at 5:13 AM wrote: > BusyBox v1.21.1 (Ubuntu 1:1.21.0-1ubuntu1.4) built-in shell (ash) > Enter 'Help' for a list of built-in commandes. > (initramfs) _ It sounds like busybox is doing exactly what it is supposed to do, opening a rescue shell to give you an opportunity to repair your system. There are any number of things that could be causing you problem, you will probably find better answers on https://askubuntu.com/ - Jeff From vda.linux at googlemail.com Sun Jan 23 19:27:12 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 23 Jan 2022 20:27:12 +0100 Subject: [PATCH] Add support for long options to cmp In-Reply-To: <20220121140027.623872-1-walter.lozano@collabora.com> References: <20220121140027.623872-1-walter.lozano@collabora.com> Message-ID: Applied, thank you. On Fri, Jan 21, 2022 at 3:00 PM Walter Lozano wrote: > > In order to improve compatibility with GNU cmp add support for long > options to busybox cmp. > > Signed-off-by: Walter Lozano > --- > editors/cmp.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/editors/cmp.c b/editors/cmp.c > index 6d2b0c6c3..6eaed59fe 100644 > --- a/editors/cmp.c > +++ b/editors/cmp.c > @@ -54,12 +54,25 @@ int cmp_main(int argc UNUSED_PARAM, char **argv) > int retval = 0; > int max_count = -1; > > - opt = getopt32(argv, "^" > +#if ENABLE_LONG_OPTS > + static const char cmp_longopts[] ALIGN1 = > + "bytes\0" Required_argument "n" > + "quiet\0" No_argument "s" > + "silent\0" No_argument "s" > + "verbose\0" No_argument "l" > + ; > +# define LONGOPTS cmp_longopts > +#else > +# define LONGOPTS NULL > +#endif > + > + opt = getopt32long(argv, "^" > OPT_STR > "\0" "-1" > IF_DESKTOP(":?4") > IF_NOT_DESKTOP(":?2") > ":l--s:s--l", > + LONGOPTS, > &max_count > ); > argv += optind; > -- > 2.25.1 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Sun Jan 23 22:06:50 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 23 Jan 2022 23:06:50 +0100 Subject: [PATCH] mkfs.vfat: fix volume label to be padded with space In-Reply-To: <20220121111700.34182-1-timo.teras@iki.fi> References: <20220121111700.34182-1-timo.teras@iki.fi> Message-ID: Applied, thank you On Fri, Jan 21, 2022 at 12:17 PM Timo Ter?s wrote: > > The specification requires volume label to be zero padded. > > Latest fsck.vfat will remove the zero padded volume label > as invalid. See also: > https://github.com/dosfstools/dosfstools/issues/172 > > Make the default label also "NO NAME" which has the special meaning > that label is not set. > > function old new delta > mkfs_vfat_main 1546 1665 +119 > .rodata 79474 79480 +6 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 2/0 up/down: 125/0) Total: 125 bytes > --- > Also the volume label should not contain certain special character, or > low case alphabet. However, seems lower case is allowed still by default > in fsck.vfat, and the special characters are a bit of corner case. So I > decided to not add checking for these. > > util-linux/mkfs_vfat.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/util-linux/mkfs_vfat.c b/util-linux/mkfs_vfat.c > index 844d965f8..fc256b903 100644 > --- a/util-linux/mkfs_vfat.c > +++ b/util-linux/mkfs_vfat.c > @@ -219,7 +219,8 @@ int mkfs_vfat_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE; > int mkfs_vfat_main(int argc UNUSED_PARAM, char **argv) > { > struct stat st; > - const char *volume_label = ""; > + const char *arg_volume_label = "NO NAME "; > + char volume_label[12]; > char *buf; > char *device_name; > uoff_t volume_size_bytes; > @@ -258,13 +259,14 @@ int mkfs_vfat_main(int argc UNUSED_PARAM, char **argv) > "Ab:cCf:F:h:Ii:l:m:n:r:R:s:S:v" > "\0" "-1", //:b+:f+:F+:h+:r+:R+:s+:S+:vv:c--l:l--c > NULL, NULL, NULL, NULL, NULL, > - NULL, NULL, &volume_label, NULL, NULL, NULL, NULL); > + NULL, NULL, &arg_volume_label, NULL, NULL, NULL, NULL); > argv += optind; > > // cache device name > device_name = argv[0]; > // default volume ID = creation time > volume_id = time(NULL); > + snprintf(volume_label, sizeof(volume_label), "%-11s", arg_volume_label); > > dev = xopen(device_name, O_RDWR); > xfstat(dev, &st, device_name); > @@ -508,7 +510,7 @@ int mkfs_vfat_main(int argc UNUSED_PARAM, char **argv) > STORE_LE(boot_blk->vi.ext_boot_sign, 0x29); > STORE_LE(boot_blk->vi.volume_id32, volume_id); > memcpy(boot_blk->vi.fs_type, "FAT32 ", sizeof(boot_blk->vi.fs_type)); > - strncpy(boot_blk->vi.volume_label, volume_label, sizeof(boot_blk->vi.volume_label)); > + memcpy(boot_blk->vi.volume_label, volume_label, sizeof(boot_blk->vi.volume_label)); > memcpy(boot_blk->boot_code, boot_code, sizeof(boot_code)); > STORE_LE(boot_blk->boot_sign, BOOT_SIGN); > > @@ -553,7 +555,7 @@ int mkfs_vfat_main(int argc UNUSED_PARAM, char **argv) > uint16_t t, d; > #endif > de = (void*)buf; > - strncpy(de->name, volume_label, sizeof(de->name)); > + memcpy(de->name, volume_label, sizeof(de->name)); > STORE_LE(de->attr, ATTR_VOLUME); > #if 0 > localtime_r(&create_time, &tm_time); > -- > 2.34.1 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Sun Jan 23 22:15:11 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 23 Jan 2022 23:15:11 +0100 Subject: [PATCH] apply const trick to ptr_to_globals In-Reply-To: <20220112185454.2712195-1-raj.khem@gmail.com> References: <20220112185454.2712195-1-raj.khem@gmail.com> Message-ID: Applied, thank you On Wed, Jan 12, 2022 at 7:55 PM Khem Raj wrote: > > This was missing in the previous attempt to fix it via [1] > > This helps fix segfaults when compiling with clang ( seen on riscv64 ) > > [ 452.428349] less[270]: unhandled signal 11 code 0x1 at 0x000000000000000c in busybox.nosuid[2ab7491000+ba000] > [ 452.430246] CPU: 3 PID: 270 Comm: less Not tainted 5.15.13-yocto-standard #1 > [ 452.431323] Hardware name: riscv-virtio,qemu (DT) > [ 452.431925] epc : 0000002ab74a19ee ra : 0000002ab74a19dc sp : 0000003fec6ec980 > [ 452.432725] gp : 0000002ab754dcb0 tp : 0000003f88783800 t0 : 0000003f8878d4a0 > [ 452.433744] t1 : 0000002ab749b00c t2 : 0000000000000000 s0 : 0000003fec6ecc38 > [ 452.434732] s1 : 000000000000004c a0 : 00000000ffffffff a1 : 0000002ab754dde0 > [ 452.435861] a2 : 0000000000000000 a3 : 0000000000000100 a4 : 0000002ab754f3a0 > [ 452.436787] a5 : 0000002ab754f3a0 a6 : 0000000000000000 a7 : 0000002ab754f2a0 > [ 452.437974] s2 : 0000000000000002 s3 : 0000002ab754b6c8 s4 : 0000002ab749b60e > [ 452.438781] s5 : 0000000000000000 s6 : 0000002ab754b6c8 s7 : 0000003f88943060 > [ 452.439723] s8 : 0000003f88944050 s9 : 0000002ad8502e88 s10: 0000002ad8502de8 > [ 452.440538] s11: 0000000000000014 t3 : 0000003f887fceb6 t4 : 0000003f8893af0c > [ 452.441438] t5 : 0000000000000000 t6 : 0000003f88923000 > > [1] https://git.busybox.net/busybox/commit/?id=1f925038a > > Signed-off-by: Khem Raj > --- > include/libbb.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/libbb.h b/include/libbb.h > index daa310776..4372f6826 100644 > --- a/include/libbb.h > +++ b/include/libbb.h > @@ -2284,7 +2284,7 @@ struct globals; > /* '*const' ptr makes gcc optimize code much better. > * Magic prevents ptr_to_globals from going into rodata. > * If you want to assign a value, use SET_PTR_TO_GLOBALS(x) */ > -extern struct globals *const ptr_to_globals; > +extern struct globals *BB_GLOBAL_CONST ptr_to_globals; > > #define barrier() asm volatile ("":::"memory") > > -- > 2.34.1 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From vda.linux at googlemail.com Mon Jan 24 06:07:53 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 24 Jan 2022 07:07:53 +0100 Subject: Error with make_single_applets and CONFIG_FEATURE_CUT_REGEX In-Reply-To: References: Message-ID: Applied, thank you On Fri, Jan 21, 2022 at 2:36 AM Jeff Pohlmeyer wrote: > > I am getting a failure when CONFIG_FEATURE_CUT_REGEX=y is enabled: > > ./make_single_applets.sh CUT > > cut.c:(.text.cut_main+0x205): undefined reference to `xregcomp' > > It looks like adding this line: > > lib-$(CONFIG_FEATURE_CUT_REGEX) += xregcomp.o > > around line ~203 in ./libbb/Kbuild.src solves the problem. > > - Jeff > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From walter.lozano at collabora.com Mon Jan 24 14:48:01 2022 From: walter.lozano at collabora.com (Walter Lozano) Date: Mon, 24 Jan 2022 11:48:01 -0300 Subject: [PATCH] Improve support for long options to grep Message-ID: <20220124144801.760099-1-walter.lozano@collabora.com> In order to improve compatibility with GNU grep improve support for long options to busybox grep. Signed-off-by: Walter Lozano --- findutils/grep.c | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/findutils/grep.c b/findutils/grep.c index 0b72812f1..2cc47df00 100644 --- a/findutils/grep.c +++ b/findutils/grep.c @@ -720,12 +720,40 @@ int grep_main(int argc UNUSED_PARAM, char **argv) /* do normal option parsing */ #if ENABLE_FEATURE_GREP_CONTEXT + static const char grep_longopts[] ALIGN1 = + "with-filename\0" No_argument "H" + "no-filename\0" No_argument "h" + "line-number\0" No_argument "n" + "files-without-match\0" No_argument "L" + "files-with-matches\0" No_argument "l" + "count\0" No_argument "c" + "only-matching\0" No_argument "o" + "quiet\0" No_argument "q" + "silent\0" No_argument "q" + "invert-match\0" No_argument "v" + "no-messages\0" No_argument "s" + "recursive\0" No_argument "r" + "ignore-case\0" No_argument "i" + "word-regexp\0" No_argument "w" + "line-regexp\0" No_argument "x" + "fixed-strings\0" No_argument "F" + "extended-regexp\0" No_argument "E" + "null-data\0" No_argument "z" + "max-count\0" Required_argument "m" + "after-context\0" Required_argument "A" + "before-context\0" Required_argument "B" + "context\0" Required_argument "C" + "regexp\0" Required_argument "e" + "file\0" Required_argument "f" + "color\0" Optional_argument "\xff" + ; + /* -H unsets -h; -C unsets -A,-B */ opts = getopt32long(argv, "^" OPTSTR_GREP "\0" "H-h:C-AB", - "color\0" Optional_argument "\xff", + grep_longopts, &pattern_head, &fopt, &max_matches, &lines_after, &lines_before, &Copt , NULL -- 2.30.2 From David.Laight at ACULAB.COM Mon Jan 24 15:32:53 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Mon, 24 Jan 2022 15:32:53 +0000 Subject: [PATCH] Improve support for long options to grep In-Reply-To: <20220124144801.760099-1-walter.lozano@collabora.com> References: <20220124144801.760099-1-walter.lozano@collabora.com> Message-ID: From: Walter Lozano > Sent: 24 January 2022 14:48 > > In order to improve compatibility with GNU grep improve support for long > options to busybox grep. Why? Does anyone ever actually type these long strings? Looks like bloat to me. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From walter.lozano at collabora.com Mon Jan 24 16:12:25 2022 From: walter.lozano at collabora.com (Walter Lozano) Date: Mon, 24 Jan 2022 13:12:25 -0300 Subject: [PATCH] Improve support for long options to grep In-Reply-To: References: <20220124144801.760099-1-walter.lozano@collabora.com> Message-ID: <8798b5e4-3a53-1137-435e-2578b926b71e@collabora.com> Hi David, On 1/24/22 12:32, David Laight wrote: > From: Walter Lozano >> Sent: 24 January 2022 14:48 >> >> In order to improve compatibility with GNU grep improve support for long >> options to busybox grep. > > Why? > Does anyone ever actually type these long strings? > Looks like bloat to me. Thank you for your feedback. As you mentioned it is very rare that people type those long strings. However, scripts that try to be more readable might use them. In my specific use case, I try to run some Debian scripts, that make use of some of those long options, of course not all of them. Since I was already there I thought it would be nice to add them, since these kind of overhead can be enabled only if needed. From my understanding long options were enabled if ENABLE_FEATURE_GREP_CONTEXT, which has some sense, since the color would be a nice improvement in that case. Following the idea that users who use ENABLE_FEATURE_GREP_CONTEXT with color are looking for a full featured grep I thought that no additional configuration options should we created to handle this. I still think that this patch has value since other people might also be looking for improved compatibility, and this is only enabled by config options. Regards, Walter -- Walter Lozano Collabora Ltd. From aaro.koskinen at iki.fi Mon Jan 24 23:21:53 2022 From: aaro.koskinen at iki.fi (Aaro Koskinen) Date: Tue, 25 Jan 2022 01:21:53 +0200 Subject: [PATCH] Improve support for long options to grep In-Reply-To: <8798b5e4-3a53-1137-435e-2578b926b71e@collabora.com> References: <20220124144801.760099-1-walter.lozano@collabora.com> <8798b5e4-3a53-1137-435e-2578b926b71e@collabora.com> Message-ID: <20220124232153.GB3096@darkstar.musicnaut.iki.fi> Hi, On Mon, Jan 24, 2022 at 01:12:25PM -0300, Walter Lozano wrote: > In my specific use case, I try to run some Debian scripts, that make use of > some of those long options, of course not all of them. Since I was already > there I thought it would be nice to add them, since these kind of overhead > can be enabled only if needed. Yes, I think it's a valid reason to add them if some widely used scripts/programs use them. > From my understanding long options were enabled if > ENABLE_FEATURE_GREP_CONTEXT, which has some sense, since the color > would be a nice improvement in that case. > > Following the idea that users who use ENABLE_FEATURE_GREP_CONTEXT with color > are looking for a full featured grep I thought that no additional > configuration options should we created to handle this. There is a separate LONG_OPTS feature that users can enable, maybe you should use that instead. A. From jonathan at hmmn.org Tue Jan 25 17:44:16 2022 From: jonathan at hmmn.org (Jonathan Sambrook) Date: Tue, 25 Jan 2022 17:44:16 +0000 Subject: [PATCH] top '-c' switch to enable output of SMP cpu lines. Message-ID: <09981866-bff0-e505-e67e-0c08597387f3@hmmn.org> From e20b5585049c3fe3172740035222af1ffb1033a5 Mon Sep 17 00:00:00 2001 From: Jonathan Sambrook Date: Tue, 25 Jan 2022 17:07:13 +0000 Subject: [PATCH] top '-c' switch to enable output of SMP cpu lines. This allows access to SMP cpu lines for batch output, as well as displaying SMP info in interactive mode without having to press '1'. My motivation here is to be able to access the SMP information when graphing BusyBox top batch output with topplot (see: https://gitlab.com/eBardie/topplot). --- procps/top.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/procps/top.c b/procps/top.c index 804d6f258..23bff1fe8 100644 --- a/procps/top.c +++ b/procps/top.c @@ -224,7 +224,8 @@ enum { OPT_b = (1 << 2), OPT_H = (1 << 3), OPT_m = (1 << 4), - OPT_EOF = (1 << 5), /* pseudo: "we saw EOF in stdin" */ + OPT_c = (1 << 5), + OPT_EOF = (1 << 6), /* pseudo: "we saw EOF in stdin" */ }; #define OPT_BATCH_MODE (option_mask32 & OPT_b) @@ -1078,6 +1079,9 @@ static unsigned handle_input(unsigned scan_mask, duration_t interval) //usage: "\n""Options:" //usage: ) //usage: "\n"" -b Batch mode" +//usage: IF_FEATURE_TOP_SMP_CPU( +//usage: "\n"" -c Same as '1' key" +//usage: ) //usage: "\n"" -n N Exit after N iterations" //usage: "\n"" -d SEC Delay between updates" //usage: IF_FEATURE_TOPMEM( @@ -1120,8 +1124,8 @@ int top_main(int argc UNUSED_PARAM, char **argv) /* all args are options; -n NUM */ make_all_argv_opts(argv); /* options can be specified w/o dash */ - col = getopt32(argv, "d:n:bHm", &str_interval, &str_iterations); - /* NB: -m and -H are accepted even if not configured */ + col = getopt32(argv, "d:n:bHmc", &str_interval, &str_iterations); + /* NB: -c, -m, and -H are accepted even if not configured */ #if ENABLE_FEATURE_TOPMEM if (col & OPT_m) /* -m (busybox specific) */ scan_mask = TOPMEM_MASK; @@ -1149,6 +1153,15 @@ int top_main(int argc UNUSED_PARAM, char **argv) /* change to /proc */ xchdir("/proc"); +#if ENABLE_FEATURE_TOP_SMP_CPU + if (col & OPT_c) { + cpu_jif = cpu_prev_jif = NULL; + num_cpus = 0; + smp_cpu_info = !smp_cpu_info; + get_jiffy_counts(); + } +#endif + #if ENABLE_FEATURE_TOP_CPU_USAGE_PERCENTAGE sort_function[0] = pcpu_sort; sort_function[1] = mem_sort; -- 2.34.1 From walter.lozano at collabora.com Tue Jan 25 21:27:00 2022 From: walter.lozano at collabora.com (Walter Lozano) Date: Tue, 25 Jan 2022 18:27:00 -0300 Subject: [PATCH] Improve support for long options to grep In-Reply-To: <20220124232153.GB3096@darkstar.musicnaut.iki.fi> References: <20220124144801.760099-1-walter.lozano@collabora.com> <8798b5e4-3a53-1137-435e-2578b926b71e@collabora.com> <20220124232153.GB3096@darkstar.musicnaut.iki.fi> Message-ID: <32f19aeb-4073-f09e-3e31-67fc8e73eaed@collabora.com> Hi Aaro, On 1/24/22 20:21, Aaro Koskinen wrote: > Hi, > > On Mon, Jan 24, 2022 at 01:12:25PM -0300, Walter Lozano wrote: >> In my specific use case, I try to run some Debian scripts, that make use of >> some of those long options, of course not all of them. Since I was already >> there I thought it would be nice to add them, since these kind of overhead >> can be enabled only if needed. > > Yes, I think it's a valid reason to add them if some widely used > scripts/programs use them. > >> From my understanding long options were enabled if >> ENABLE_FEATURE_GREP_CONTEXT, which has some sense, since the color >> would be a nice improvement in that case. >> >> Following the idea that users who use ENABLE_FEATURE_GREP_CONTEXT with color >> are looking for a full featured grep I thought that no additional >> configuration options should we created to handle this. > > There is a separate LONG_OPTS feature that users can enable, maybe you > should use that instead. As mentioned the current implementation uses long options in case ENABLE_FEATURE_GREP_CONTEXT, so initially I thought in following the same approach. However, after your comment I understand that this approach is not the best, and long options should be decoupled. I'll send a V2. Regards, Walter -- Walter Lozano Collabora Ltd. From David.Laight at ACULAB.COM Wed Jan 26 12:12:59 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Wed, 26 Jan 2022 12:12:59 +0000 Subject: [PATCH] top '-c' switch to enable output of SMP cpu lines. In-Reply-To: <09981866-bff0-e505-e67e-0c08597387f3@hmmn.org> References: <09981866-bff0-e505-e67e-0c08597387f3@hmmn.org> Message-ID: <1404f23bcf134d50a177b2ec0ad2798f@AcuMS.aculab.com> From: Jonathan Sambrook > Sent: 25 January 2022 17:44 > > This allows access to SMP cpu lines for batch output, as well as > displaying SMP info in interactive mode without having to press '1'. > > My motivation here is to be able to access the SMP information when > graphing BusyBox top batch output with topplot .. > +//usage: IF_FEATURE_TOP_SMP_CPU( > +//usage: "\n"" -c Same as '1' key" > +//usage: ) Better to just say 'One line for each cpu'. ... > +#if ENABLE_FEATURE_TOP_SMP_CPU > + if (col & OPT_c) { > + cpu_jif = cpu_prev_jif = NULL; > + num_cpus = 0; Whitespace manged... > + smp_cpu_info = !smp_cpu_info; > + get_jiffy_counts(); > + } > +#endif Is this block needed - I suspect the main loop can be made to DTRT. You also probably want the 'IRIX mode' patches I posted a few months back. Otherwise on a system with a lot of cpu the per-process cpu time is always very small. They may have got lost.... David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From walter.lozano at collabora.com Wed Jan 26 14:14:15 2022 From: walter.lozano at collabora.com (Walter Lozano) Date: Wed, 26 Jan 2022 11:14:15 -0300 Subject: [PATCH v2] Improve support for long options to grep Message-ID: <20220126141415.1029575-1-walter.lozano@collabora.com> In order to improve compatibility with GNU grep improve support for long options to busybox grep. Signed-off-by: Walter Lozano --- Changes in v2: - Decouple FEATURE_GREP_CONTEXT from LONG_OPTS. findutils/grep.c | 43 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/findutils/grep.c b/findutils/grep.c index 0b72812f1..4ae070a01 100644 --- a/findutils/grep.c +++ b/findutils/grep.c @@ -720,17 +720,56 @@ int grep_main(int argc UNUSED_PARAM, char **argv) /* do normal option parsing */ #if ENABLE_FEATURE_GREP_CONTEXT +#if !ENABLE_LONG_OPTS /* -H unsets -h; -C unsets -A,-B */ - opts = getopt32long(argv, "^" + opts = getopt32(argv, "^" OPTSTR_GREP "\0" "H-h:C-AB", - "color\0" Optional_argument "\xff", &pattern_head, &fopt, &max_matches, &lines_after, &lines_before, &Copt , NULL ); +#else + static const char grep_longopts[] ALIGN1 = + "with-filename\0" No_argument "H" + "no-filename\0" No_argument "h" + "line-number\0" No_argument "n" + "files-without-match\0" No_argument "L" + "files-with-matches\0" No_argument "l" + "count\0" No_argument "c" + "only-matching\0" No_argument "o" + "quiet\0" No_argument "q" + "silent\0" No_argument "q" + "invert-match\0" No_argument "v" + "no-messages\0" No_argument "s" + "recursive\0" No_argument "r" + "ignore-case\0" No_argument "i" + "word-regexp\0" No_argument "w" + "line-regexp\0" No_argument "x" + "fixed-strings\0" No_argument "F" + "extended-regexp\0" No_argument "E" + "null-data\0" No_argument "z" + "max-count\0" Required_argument "m" + "after-context\0" Required_argument "A" + "before-context\0" Required_argument "B" + "context\0" Required_argument "C" + "regexp\0" Required_argument "e" + "file\0" Required_argument "f" + "color\0" Optional_argument "\xff" + ; + /* -H unsets -h; -C unsets -A,-B */ + opts = getopt32long(argv, "^" + OPTSTR_GREP + "\0" + "H-h:C-AB", + grep_longopts, + &pattern_head, &fopt, &max_matches, + &lines_after, &lines_before, &Copt + , NULL + ); +#endif if (opts & OPT_C) { /* -C unsets prev -A and -B, but following -A or -B * may override it */ -- 2.25.1 From David.Laight at ACULAB.COM Wed Jan 26 14:25:21 2022 From: David.Laight at ACULAB.COM (David Laight) Date: Wed, 26 Jan 2022 14:25:21 +0000 Subject: [PATCH v2] Improve support for long options to grep In-Reply-To: <20220126141415.1029575-1-walter.lozano@collabora.com> References: <20220126141415.1029575-1-walter.lozano@collabora.com> Message-ID: <59592e2f08fc45f8a972359dba04ef5f@AcuMS.aculab.com> From: Walter Lozano > Sent: 26 January 2022 14:14 > > In order to improve compatibility with GNU grep improve support for long > options to busybox grep. You've broken backwards compatibility by removing --color from default builds. There is also unnecessary duplication of source code. Just use a #define and C string concatenation to add the extra long option strings. David > > Signed-off-by: Walter Lozano > > --- > > Changes in v2: > - Decouple FEATURE_GREP_CONTEXT from LONG_OPTS. > > findutils/grep.c | 43 +++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 41 insertions(+), 2 deletions(-) > > diff --git a/findutils/grep.c b/findutils/grep.c > index 0b72812f1..4ae070a01 100644 > --- a/findutils/grep.c > +++ b/findutils/grep.c > @@ -720,17 +720,56 @@ int grep_main(int argc UNUSED_PARAM, char **argv) > > /* do normal option parsing */ > #if ENABLE_FEATURE_GREP_CONTEXT > +#if !ENABLE_LONG_OPTS > /* -H unsets -h; -C unsets -A,-B */ > - opts = getopt32long(argv, "^" > + opts = getopt32(argv, "^" > OPTSTR_GREP > "\0" > "H-h:C-AB", > - "color\0" Optional_argument "\xff", > &pattern_head, &fopt, &max_matches, > &lines_after, &lines_before, &Copt > , NULL > ); > +#else > + static const char grep_longopts[] ALIGN1 = > + "with-filename\0" No_argument "H" > + "no-filename\0" No_argument "h" > + "line-number\0" No_argument "n" > + "files-without-match\0" No_argument "L" > + "files-with-matches\0" No_argument "l" > + "count\0" No_argument "c" > + "only-matching\0" No_argument "o" > + "quiet\0" No_argument "q" > + "silent\0" No_argument "q" > + "invert-match\0" No_argument "v" > + "no-messages\0" No_argument "s" > + "recursive\0" No_argument "r" > + "ignore-case\0" No_argument "i" > + "word-regexp\0" No_argument "w" > + "line-regexp\0" No_argument "x" > + "fixed-strings\0" No_argument "F" > + "extended-regexp\0" No_argument "E" > + "null-data\0" No_argument "z" > + "max-count\0" Required_argument "m" > + "after-context\0" Required_argument "A" > + "before-context\0" Required_argument "B" > + "context\0" Required_argument "C" > + "regexp\0" Required_argument "e" > + "file\0" Required_argument "f" > + "color\0" Optional_argument "\xff" > + ; > > + /* -H unsets -h; -C unsets -A,-B */ > + opts = getopt32long(argv, "^" > + OPTSTR_GREP > + "\0" > + "H-h:C-AB", > + grep_longopts, > + &pattern_head, &fopt, &max_matches, > + &lines_after, &lines_before, &Copt > + , NULL > + ); > +#endif > if (opts & OPT_C) { > /* -C unsets prev -A and -B, but following -A or -B > * may override it */ > -- > 2.25.1 - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From walter.lozano at collabora.com Wed Jan 26 15:59:45 2022 From: walter.lozano at collabora.com (Walter Lozano) Date: Wed, 26 Jan 2022 12:59:45 -0300 Subject: [PATCH v2] Improve support for long options to grep In-Reply-To: <59592e2f08fc45f8a972359dba04ef5f@AcuMS.aculab.com> References: <20220126141415.1029575-1-walter.lozano@collabora.com> <59592e2f08fc45f8a972359dba04ef5f@AcuMS.aculab.com> Message-ID: <06f9d2c1-897f-10e3-9ede-3d6513b04c89@collabora.com> Hi David, Thank you for your feedback, let me comment. On 1/26/22 11:25, David Laight wrote: > From: Walter Lozano >> Sent: 26 January 2022 14:14 >> >> In order to improve compatibility with GNU grep improve support for long >> options to busybox grep. > > You've broken backwards compatibility by removing --color from > default builds. You are right about this, however, I was not sure about how to proceed, since previously the code seems to silently make use of long options even if LONG_OPTS was not enabled, which seems to be odd. I don't have problems in keeping the old behavior, but it will be odd to check for LONG_OPTS for adding the new options, but keep the --color support if LONG_OPTS are not enabled. From my understanding either, they should be decoupled as in this patch or force LONG_OPTS to be enabled if FEATURE_GREP_CONTEXT is enabled. Since FEATURE_GREP_CONTEXT does not depend on LONG_OPTS I thought it is not the proper solution. > There is also unnecessary duplication of source code. > > Just use a #define and C string concatenation to add the extra > long option strings. Yes, I totally agree you. However I used this approach since a previous patch I submitted was rewritten in this way [1] when applying to master. Regards, Walter [1] https://git.busybox.net/busybox/commit/?id=6dd6a6c42d1465d8cca2539476f6bffd5e1353dd >> --- >> >> Changes in v2: >> - Decouple FEATURE_GREP_CONTEXT from LONG_OPTS. >> >> findutils/grep.c | 43 +++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 41 insertions(+), 2 deletions(-) >> >> diff --git a/findutils/grep.c b/findutils/grep.c >> index 0b72812f1..4ae070a01 100644 >> --- a/findutils/grep.c >> +++ b/findutils/grep.c >> @@ -720,17 +720,56 @@ int grep_main(int argc UNUSED_PARAM, char **argv) >> >> /* do normal option parsing */ >> #if ENABLE_FEATURE_GREP_CONTEXT >> +#if !ENABLE_LONG_OPTS >> /* -H unsets -h; -C unsets -A,-B */ >> - opts = getopt32long(argv, "^" >> + opts = getopt32(argv, "^" >> OPTSTR_GREP >> "\0" >> "H-h:C-AB", >> - "color\0" Optional_argument "\xff", >> &pattern_head, &fopt, &max_matches, >> &lines_after, &lines_before, &Copt >> , NULL >> ); >> +#else >> + static const char grep_longopts[] ALIGN1 = >> + "with-filename\0" No_argument "H" >> + "no-filename\0" No_argument "h" >> + "line-number\0" No_argument "n" >> + "files-without-match\0" No_argument "L" >> + "files-with-matches\0" No_argument "l" >> + "count\0" No_argument "c" >> + "only-matching\0" No_argument "o" >> + "quiet\0" No_argument "q" >> + "silent\0" No_argument "q" >> + "invert-match\0" No_argument "v" >> + "no-messages\0" No_argument "s" >> + "recursive\0" No_argument "r" >> + "ignore-case\0" No_argument "i" >> + "word-regexp\0" No_argument "w" >> + "line-regexp\0" No_argument "x" >> + "fixed-strings\0" No_argument "F" >> + "extended-regexp\0" No_argument "E" >> + "null-data\0" No_argument "z" >> + "max-count\0" Required_argument "m" >> + "after-context\0" Required_argument "A" >> + "before-context\0" Required_argument "B" >> + "context\0" Required_argument "C" >> + "regexp\0" Required_argument "e" >> + "file\0" Required_argument "f" >> + "color\0" Optional_argument "\xff" >> + ; >> >> + /* -H unsets -h; -C unsets -A,-B */ >> + opts = getopt32long(argv, "^" >> + OPTSTR_GREP >> + "\0" >> + "H-h:C-AB", >> + grep_longopts, >> + &pattern_head, &fopt, &max_matches, >> + &lines_after, &lines_before, &Copt >> + , NULL >> + ); >> +#endif >> if (opts & OPT_C) { >> /* -C unsets prev -A and -B, but following -A or -B >> * may override it */ >> -- >> 2.25.1 > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > -- Walter Lozano Collabora Ltd. From xoneca at gmail.com Wed Jan 26 18:34:26 2022 From: xoneca at gmail.com (Xabier Oneca -- xOneca) Date: Wed, 26 Jan 2022 19:34:26 +0100 Subject: [PATCH v2] Improve support for long options to grep In-Reply-To: <59592e2f08fc45f8a972359dba04ef5f@AcuMS.aculab.com> References: <20220126141415.1029575-1-walter.lozano@collabora.com> <59592e2f08fc45f8a972359dba04ef5f@AcuMS.aculab.com> Message-ID: Hi David, From: Walter Lozano > > Sent: 26 January 2022 14:14 > > > > In order to improve compatibility with GNU grep improve support for long > > options to busybox grep. > > You've broken backwards compatibility by removing --color from > default builds. > If LONG_OPTS are not enabled then neither is --color enabled, even if FEATURE_GREP_CONTEXT is. Cheers, Xabier Oneca_,,_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xoneca at gmail.com Wed Jan 26 18:38:05 2022 From: xoneca at gmail.com (Xabier Oneca -- xOneca) Date: Wed, 26 Jan 2022 19:38:05 +0100 Subject: [PATCH v2] Improve support for long options to grep In-Reply-To: <06f9d2c1-897f-10e3-9ede-3d6513b04c89@collabora.com> References: <20220126141415.1029575-1-walter.lozano@collabora.com> <59592e2f08fc45f8a972359dba04ef5f@AcuMS.aculab.com> <06f9d2c1-897f-10e3-9ede-3d6513b04c89@collabora.com> Message-ID: Hi Walter, > There is also unnecessary duplication of source code. > > > > Just use a #define and C string concatenation to add the extra > > long option strings. > > Yes, I totally agree you. However I used this approach since a previous > patch I submitted was rewritten in this way [1] when applying to master. > > Maybe a better approach is to always use getopt32long, as it is converted to getopt32 if LONG_OPTS is not enabled. Maybe Denys forgot about this. See libbb.h: https://git.busybox.net/busybox/tree/include/libbb.h#n1351 Cheers, Xabier Oneca_,,_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From walter.lozano at collabora.com Wed Jan 26 19:12:59 2022 From: walter.lozano at collabora.com (Walter Lozano) Date: Wed, 26 Jan 2022 16:12:59 -0300 Subject: [PATCH v2] Improve support for long options to grep In-Reply-To: References: <20220126141415.1029575-1-walter.lozano@collabora.com> <59592e2f08fc45f8a972359dba04ef5f@AcuMS.aculab.com> <06f9d2c1-897f-10e3-9ede-3d6513b04c89@collabora.com> Message-ID: <86bc00ba-ae3e-5f45-0b33-28c7bdac8f56@collabora.com> On 1/26/22 15:38, Xabier Oneca -- xOneca wrote: > Hi Walter, > > > There is also unnecessary duplication of source code. > > > > Just use a #define and C string concatenation to add the extra > > long option strings. > > Yes, I totally agree you. However I used this approach since a previous > patch I submitted was rewritten in this way [1] when applying to master. > > > Maybe a better approach is to always use getopt32long, as it is > converted to getopt32 if LONG_OPTS is not enabled. Maybe Denys forgot > about this. > See libbb.h: https://git.busybox.net/busybox/tree/include/libbb.h#n1351 > Thank you for the pointer. Yes, it looks much cleaner to always use getopt32long, not sure if there was some reason I'm not aware to try to avoid it. -- Walter Lozano Collabora Ltd. From jonathan at hmmn.org Thu Jan 27 12:08:32 2022 From: jonathan at hmmn.org (Jonathan Sambrook) Date: Thu, 27 Jan 2022 12:08:32 +0000 Subject: [PATCH] top '-c' switch to enable output of SMP cpu lines. In-Reply-To: <1404f23bcf134d50a177b2ec0ad2798f@AcuMS.aculab.com> References: <09981866-bff0-e505-e67e-0c08597387f3@hmmn.org> <1404f23bcf134d50a177b2ec0ad2798f@AcuMS.aculab.com> Message-ID: <0235abbc-7bdb-4e43-d547-90c05f43ee08@hmmn.org> On 26/01/2022 12:12, David Laight wrote: > From: Jonathan Sambrook >> Sent: 25 January 2022 17:44 >> >> This allows access to SMP cpu lines for batch output, as well as >> displaying SMP info in interactive mode without having to press '1'. >> >> My motivation here is to be able to access the SMP information when >> graphing BusyBox top batch output with topplot > .. >> +//usage: IF_FEATURE_TOP_SMP_CPU( >> +//usage: "\n"" -c Same as '1' key" >> +//usage: ) > > Better to just say 'One line for each cpu'. I agree the "Same as" formulation isn't great, but I was following the (equally opaque) precedent: -m Same as 's' key So I've now got: -c CPU info for each core > ... >> +#if ENABLE_FEATURE_TOP_SMP_CPU >> + if (col & OPT_c) { >> + cpu_jif = cpu_prev_jif = NULL; >> + num_cpus = 0; > > Whitespace manged... Arggh! Thanks. > >> + smp_cpu_info = !smp_cpu_info; >> + get_jiffy_counts(); >> + } >> +#endif > > Is this block needed - I suspect the main loop can be made to DTRT. Turns out: not all of it. The remaining initialization doesn't require changes to the main loop. > You also probably want the 'IRIX mode' patches I posted a few months back. > Otherwise on a system with a lot of cpu the per-process cpu time is > always very small. > > They may have got lost.... Sounds good. Can you resurrect them? > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > From jonathan at hmmn.org Thu Jan 27 12:08:29 2022 From: jonathan at hmmn.org (Jonathan Sambrook) Date: Thu, 27 Jan 2022 12:08:29 +0000 Subject: [PATCH v2] top '-c' switch to enable output of SMP cpu lines. In-Reply-To: <09981866-bff0-e505-e67e-0c08597387f3@hmmn.org> References: <09981866-bff0-e505-e67e-0c08597387f3@hmmn.org> Message-ID: From 2c2819a75aca64ef67efde7c3c5c4ede76d23957 Mon Sep 17 00:00:00 2001 From: Jonathan Sambrook Date: Thu, 27 Jan 2022 11:37:10 +0000 Subject: [PATCH] Add '-c' switch to enable output of SMP cpu lines. This allows access to SMP cpu lines for batch output, as well as displaying SMP info in interactive mode without having to press '1'. My motivation here is to be able to access the SMP information when graphing BusyBox top batch output with topplot (see: https://gitlab.com/eBardie/topplot). --- procps/top.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/procps/top.c b/procps/top.c index 804d6f258..32d08737b 100644 --- a/procps/top.c +++ b/procps/top.c @@ -224,7 +224,8 @@ enum { OPT_b = (1 << 2), OPT_H = (1 << 3), OPT_m = (1 << 4), - OPT_EOF = (1 << 5), /* pseudo: "we saw EOF in stdin" */ + OPT_c = (1 << 5), + OPT_EOF = (1 << 6), /* pseudo: "we saw EOF in stdin" */ }; #define OPT_BATCH_MODE (option_mask32 & OPT_b) @@ -1078,6 +1079,9 @@ static unsigned handle_input(unsigned scan_mask, duration_t interval) //usage: "\n""Options:" //usage: ) //usage: "\n"" -b Batch mode" +//usage: IF_FEATURE_TOP_SMP_CPU( +//usage: "\n"" -c CPU info for each core" +//usage: ) //usage: "\n"" -n N Exit after N iterations" //usage: "\n"" -d SEC Delay between updates" //usage: IF_FEATURE_TOPMEM( @@ -1120,8 +1124,8 @@ int top_main(int argc UNUSED_PARAM, char **argv) /* all args are options; -n NUM */ make_all_argv_opts(argv); /* options can be specified w/o dash */ - col = getopt32(argv, "d:n:bHm", &str_interval, &str_iterations); - /* NB: -m and -H are accepted even if not configured */ + col = getopt32(argv, "d:n:bHmc", &str_interval, &str_iterations); + /* NB: -c, -m, and -H are accepted even if not configured */ #if ENABLE_FEATURE_TOPMEM if (col & OPT_m) /* -m (busybox specific) */ scan_mask = TOPMEM_MASK; @@ -1149,6 +1153,13 @@ int top_main(int argc UNUSED_PARAM, char **argv) /* change to /proc */ xchdir("/proc"); +#if ENABLE_FEATURE_TOP_SMP_CPU + if (col & OPT_c) { + cpu_jif = cpu_prev_jif = NULL; + smp_cpu_info = ~0; + } +#endif + #if ENABLE_FEATURE_TOP_CPU_USAGE_PERCENTAGE sort_function[0] = pcpu_sort; sort_function[1] = mem_sort; -- 2.34.1 From soeren at soeren-tempel.net Sat Jan 29 10:22:32 2022 From: soeren at soeren-tempel.net (soeren at soeren-tempel.net) Date: Sat, 29 Jan 2022 11:22:32 +0100 Subject: [PATCH] ash: fix use-after-free in bash pattern substitution Message-ID: <20220129102232.25914-1-soeren@soeren-tempel.net> From: S?ren Tempel At Alpine Linux downstream, we were made aware of a segmentation fault occurring during string replacement in BusyBox ash [0]. Further debugging revealed that the segmentation fault occurs due to a use-after-free in BusyBox's bash pattern substitution implementation. Specially, the problem is that the repl variable (pointing to the replacement string) points to a value in the stack string. However, when accessing the repl pointer in Line 7350 it is possible that the stack has been moved since the last repl assignment due to the STPUTC invocations in Line 7317 and 7321 (since STPUTC may grow the stack via realloc(3)). For this reason, the code in Line 7350 may access an unmapped memory region and therefore causes a segmentation fault if prior STPUTC invocations moved the stack via realloc(3). The valgrind output for this edge case looks as follows: Invalid read of size 1 at 0x15D8DD: subevalvar (ash.c:7350) by 0x15DC43: evalvar (ash.c:7666) by 0x15B717: argstr (ash.c:6893) by 0x15BAEC: expandarg (ash.c:8090) by 0x15F4CC: evalcommand (ash.c:10429) by 0x15B26C: evaltree (ash.c:9365) by 0x15E4FC: cmdloop (ash.c:13569) by 0x15FD8B: ash_main (ash.c:14748) by 0x115BF2: run_applet_no_and_exit (appletlib.c:967) by 0x115F16: run_applet_and_exit (appletlib.c:986) by 0x115EF9: busybox_main (appletlib.c:917) by 0x115EF9: run_applet_and_exit (appletlib.c:979) by 0x115F8F: main (appletlib.c:1126) Address 0x48b8646 is 2,054 bytes inside a block of size 4,776 free'd at 0x48A6FC9: realloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x116E86: xrealloc (xfuncs_printf.c:61) by 0x1565DB: growstackblock (ash.c:1736) by 0x156EF7: growstackstr (ash.c:1775) by 0x156F1A: _STPUTC (ash.c:1816) by 0x15D843: subevalvar (ash.c:7317) by 0x15DC43: evalvar (ash.c:7666) by 0x15B717: argstr (ash.c:6893) by 0x15BAEC: expandarg (ash.c:8090) by 0x15F4CC: evalcommand (ash.c:10429) by 0x15B26C: evaltree (ash.c:9365) by 0x15E4FC: cmdloop (ash.c:13569) A testcase for reproducing this edge case is provided in the downstream bug report [1]. This commit fixes the issue by reconstructing the repl pointer relative to stackblock() via strloc and slash_pos. [0]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13469 [1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13469#note_210530 Signed-off-by: S?ren Tempel --- Discussion: I am not familiar with the ash code base. For this reason, it is presently unclear to me if there is a path where slash_pos < 0, STPUTC is invoked, and repl points to the stack. If so, handling for the case that slash_pos < 0 also needs to be added to the proposed path. Furthermore, I haven't tested this patch extensively so please review with extra care. shell/ash.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/shell/ash.c b/shell/ash.c index 55df54bd0..24f9a8270 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -7346,6 +7346,12 @@ subevalvar(char *start, char *str, int strloc, idx = loc; } + // The STPUTC invocations above may resize and move the + // stack via realloc(3). Since repl is a pointer into the + // stack, we need to reconstruct it relative to stackblock(). + if (slash_pos >= 0) + repl = (char *)stackblock() + strloc + slash_pos + 1; + //bb_error_msg("repl:'%s'", repl); for (loc = (char*)repl; *loc; loc++) { char *restart_detect = stackblock(); From fodha.mohamed.ali at gmail.com Mon Jan 31 14:02:45 2022 From: fodha.mohamed.ali at gmail.com (Mohamed Ali Fodha) Date: Mon, 31 Jan 2022 15:02:45 +0100 Subject: Issue: Extract single folder Message-ID: Hello, I got below issue if I try to extract single folder from a tar file: *#tar -xvf Dashboard_1.4.tar.gz -C ./extract Dashboard * Dashboard/webapp/Dashboard/configuration.json Dashboard/resources/configuration.properties Dashboard/resources/log4j.xml tar: Dashboard: not found in archive #echo $? 1 The same issue with *tar -xvf Dashboard_1.4.3.0.tar.gz -C ./extract -T include* The content of include is *Dashboard* Any ideas please? Best regards, Mohamed Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghanson at arista.com Mon Jan 31 17:29:15 2022 From: ghanson at arista.com (Geoff Hanson) Date: Mon, 31 Jan 2022 09:29:15 -0800 Subject: udhcpc6 expects string for bootfile-param opt(60) Message-ID: Bug report: Package: busybox Version: 1.35.0 RFC 5970 (DHCPv6 options for network boot) section 3.2 specifies that the boot file parameters option consists of multiple UTF-8 strings, each string starting with a length field. However, the udhcpc6 code is expecting a single null-terminated string. When testing with the Kea DHCPv6 server, it encoded the parameter correctly, but because the first octet was 0, the udhcpc6 command interpreted this as a zero-length string. I have noticed at least one server encoding the option as a single string, so the existing udhcpc6 command works for some servers. I have attached a suggested fix (patch) which includes a bit of refactoring. The fix is written in such a way to be compatible with non-compliant servers that encode the parameter as a single string. Let me know if you need any clarification on the problem. Thanks, Geoff Hanson Arista Networks ghanson at arista.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Index: busybox-1.33.1/networking/udhcp/d6_dhcpc.c =================================================================== --- busybox-1.33.1.orig/networking/udhcp/d6_dhcpc.c +++ busybox-1.33.1/networking/udhcp/d6_dhcpc.c @@ -79,7 +79,7 @@ static const struct dhcp_optflag d6_optf #endif #if ENABLE_FEATURE_UDHCPC6_RFC5970 { OPTION_STRING, D6_OPT_BOOT_URL }, - { OPTION_STRING, D6_OPT_BOOT_PARAM }, + { OPTION_STRING | OPTION_LIST, D6_OPT_BOOT_PARAM }, #endif { OPTION_STRING, 0xd1 }, /* DHCP_PXE_CONF_FILE */ { OPTION_STRING, 0xd2 }, /* DHCP_PXE_PATH_PREFIX */ @@ -214,19 +214,16 @@ static char** new_env(void) return &client6_data.env_ptr[client6_data.env_idx++]; } -static char *string_option_to_env(const uint8_t *option, - const uint8_t *option_end) +static const char *get_option_name(const uint8_t *option) { - const char *ptr, *name = NULL; - unsigned val_len; + const char *ptr = NULL; int i; ptr = d6_option_strings; i = 0; while (*ptr) { if (d6_optflags[i].code == option[1]) { - name = ptr; - goto found; + return ptr; } ptr += strlen(ptr) + 1; i++; @@ -234,7 +231,19 @@ static char *string_option_to_env(const bb_error_msg("can't find option name for 0x%x, skipping", option[1]); return NULL; - found: +} + +static char *string_option_to_env(const uint8_t *option, + const uint8_t *option_end) +{ + const char *name = NULL; + unsigned val_len; + + name = get_option_name(option); + if (!name) { + return NULL; + } + val_len = (option[2] << 8) | option[3]; if (val_len + &option[D6_OPT_DATA] > option_end) { bb_simple_error_msg("option data exceeds option length"); @@ -243,6 +252,51 @@ static char *string_option_to_env(const return xasprintf("%s=%.*s", name, val_len, (char*)option + 4); } +/* parse list of variable length strings. The length of each string + is the first two bytes */ +static char *string_list_option_to_env(const uint8_t *option, + const uint8_t *option_end) +{ + const char *name = NULL; + unsigned val_len, name_len, parm_len; + int i; + char *envstr, *envptr, *envval; + const uint8_t *optptr; + + name = get_option_name(option); + if (!name) + return NULL; + name_len = strlen(name); + + val_len = (option[2] << 8) | option[3]; + if (val_len + &option[D6_OPT_DATA] > option_end) { + bb_simple_error_msg("option data exceeds option length"); + return NULL; + } + + envptr = envstr = xmalloc(name_len + 1 + val_len); + envptr = stpcpy(envptr, name); + envval = envptr = stpcpy(envptr, "="); + + optptr = option + D6_OPT_DATA; + while (optptr + 1 < option_end) { + parm_len = (*optptr++ << 8) | *optptr++; + if (optptr + parm_len > option_end) { + bb_simple_error_msg("option parm length overflows option length"); + return NULL; + } + if (parm_len > 0) { + if (envptr > envval) + *envptr++ = ' '; + snprintf(envptr, parm_len + 1, optptr); + envptr += parm_len; + optptr += parm_len; + } + } + + return envstr; +} + /* put all the parameters into the environment */ static void option_to_env(const uint8_t *option, const uint8_t *option_end) { @@ -407,7 +461,6 @@ static void option_to_env(const uint8_t break; #endif case D6_OPT_BOOT_URL: - case D6_OPT_BOOT_PARAM: case 0xd1: /* DHCP_PXE_CONF_FILE */ case 0xd2: /* DHCP_PXE_PATH_PREFIX */ { @@ -415,6 +468,38 @@ static void option_to_env(const uint8_t if (tmp) *new_env() = tmp; break; + } + case D6_OPT_BOOT_PARAM: +/* 0 1 2 3 + * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | OPT_BOOTFILE_PARAM | option-len | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | param-len 1 | | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 . + * . (variable length) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * . . + * . . + * . . + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | param-len n | | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n . + * . (variable length) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + */ + { + char *tmp; + if (option[4]) + /* If the high byte of param-len 1 is non-zero, most + likely this was caused by a non-compliant server + sending the param as a single string. */ + tmp = string_option_to_env(option, option_end); + else + tmp = string_list_option_to_env(option, option_end); + if (tmp) + *new_env() = tmp; + break; } } len_m4 -= 4 + option[3]; From xoneca at gmail.com Mon Jan 31 19:09:47 2022 From: xoneca at gmail.com (Xabier Oneca -- xOneca) Date: Mon, 31 Jan 2022 20:09:47 +0100 Subject: udhcpc6 expects string for bootfile-param opt(60) In-Reply-To: References: Message-ID: Hi Geoff, > [...] > + if (envptr > envval) > + *envptr++ = ' '; > + snprintf(envptr, parm_len + 1, optptr); You forgot the format string (i.e. "%s"). > + envptr += parm_len; > + optptr += parm_len; > [...] Cheers, Xabier Oneca_,,_ -------------- next part -------------- An HTML attachment was scrubbed... URL: