From bugzilla at busybox.net Sat Jan 4 16:53:43 2025
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Sat, 04 Jan 2025 16:53:43 +0000
Subject: [Bug 16276] New: fdisk can't support disks of more then 2^32 sectors
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=16276
Bug ID: 16276
Summary: fdisk can't support disks of more then 2^32 sectors
Product: Busybox
Version: 1.37.x
Hardware: All
OS: Linux
Status: NEW
Severity: major
Priority: P5
Component: Other
Assignee: unassigned at busybox.net
Reporter: thierry.laurion at gmail.com
CC: busybox-cvs at busybox.net
Target Milestone: ---
fdisk truncates output and errors on fdisk -l at
https://github.com/mirror/busybox/blob/371fe9f71d445d18be28c82a2a6d82115c8af19d/util-linux/fdisk.c#L512
bb_simple_error_msg("device has more than 2^32 sectors,
can't use all of them");
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Fri Jan 17 09:05:40 2025
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Fri, 17 Jan 2025 09:05:40 +0000
Subject: [Bug 14041] using modprobe/insmod with compressed modules gives
scary kernel warnings
In-Reply-To:
References:
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=14041
--- Comment #2 from christian at kohlschutter.com ---
I just ran into this, too. In Linux 6, the kernel error log I get is the
following:
"Invalid ELF header magic: != ELF" (or: "Invalid ELF header magic: != \x7fELF")
This is due to bb_init_module in busybox/modutils/modutils.c relying on the
kernel to perform in-kernel decompression via finit_module with
MODULE_INIT_COMPRESSED_FILE.
The in-kernel decompression functionality may not always be available
("CONFIG_MODULE_DECOMPRESS=y"), or not configured for the current compression
method (gz vs. xz, etc.).
Asking users to enable CONFIG_MODULE_DECOMPRESS may not be an option for
security reasons. It also doesn't cover all cases since multiple different
compression methods are not supported by the kernel...
When a kernel rightfully responds with "EOPNOTSUPP", busybox keeps trying to
load it as an uncompressed module instead ("/* Loading non-.ko named
uncompressed module? Not likely, but let's try it */").
I suggest that at least errno should be checked for EOPNOTSUPP and reported to
the caller.
Also see this insmod wrapper script that may work instead, proposed in
2006: https://lists.busybox.net/pipermail/busybox/2006-November/059513.html
Of course, implementing decompression here in busybox would be the right thing.
Notably, Alpine Linux does not enable CONFIG_MODULE_DECOMPRESS but relies on
kmod's implementation instead ("apk add kmod").
--
You are receiving this mail because:
You are on the CC list for the bug.
From bugzilla at busybox.net Fri Jan 17 21:29:18 2025
From: bugzilla at busybox.net (bugzilla at busybox.net)
Date: Fri, 17 Jan 2025 21:29:18 +0000
Subject: [Bug 16282] New: wget: Allow hiding secrets and credentials from OS
process list
Message-ID:
https://bugs.busybox.net/show_bug.cgi?id=16282
Bug ID: 16282
Summary: wget: Allow hiding secrets and credentials from OS
process list
Product: Busybox
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5
Component: Networking
Assignee: unassigned at busybox.net
Reporter: bugs.busybox.net at hardfalcon.net
CC: busybox-cvs at busybox.net
Target Milestone: ---
As of busybox 1.37.0, AFAICT the only way for specifying additional HTTP
headers seems to be the --header CLI parameter. This is a problem when passing
credentials such as passwords or access tokens, because all CLI parameters end
up in the system wide process list and are therefore accessible for all users
and processes on the local system.
In GNU wget, this problem can be circumvented by using the WGETRC environment
variable and by creating an ephemeral .wgetrc file with a line such as the
following:
header = Some_header: Some_value
In curl, the problem can be circumvented in a similar way by either using the
--config CLI parameter, or by using --header @some_file.
The most compatible way of solving this would probably be adding support for
the WGETRC environment variable and the .wgetrc config file, but of course I'd
be happy about any way/hint to solve or sidestep this problem. :)
--
You are receiving this mail because:
You are on the CC list for the bug.