Re: [RFC] Stop providing binary package updates for release builds?
The package update is not a perfect solution but it is better to have it as is than to remove it. Updated packages are also used by imagebuilder and attended sysupgrade. I normally generate a new image to apply updates because some devices cannot afford the extra installation. If we need updated packages for those cases, there is no reason to not publish them. If server resources are the problem, we should ask for help with more resources or reduce the build frequency but not stop it. Please, keep the repo packages updated. Reflashing is a delicate operation for remote devices and I need to prepare a long maintenance window (and I have dozens of remote locations). For security issues, I always evaluate if I need to reflash the device or if I can update just that package, especially if it will not affect the endusers operation. For x86 targets, I normally use much more package upgrade than reflash. Please, also keep opkg upgrade feature. I have no problem if there was an automated monthly, weekly or even daily dot release with all updates. However, a reflash is a complex operation for anyone with some extra packages and files and an extremely complex one when extroot is in use. This will consume more from our (specialist enduser) time, not a non-technical enduser (they will probably not upgrade the router by themselves anyway). The package upgrade has issues. One of them is that an update can break the system, normally those with small flashes. It would be nice if opkg could revert to the previous state when it fails (it also happens with opkg install). The attended sysupgrade service is a nice feature but it removes the ability to uninstall a package after an upgrade (and it does not work with extroot). I would prefer a solution where the extra packages were appended to the backup file or downloaded after reboot (if we could detect which packages are not required to connect to the internet). And moving a package from overlay to squashfs might introduce issues with hotplug scripts (however, that is another issue that should be fixed). Anyway, without a very frequent dot release or a repo with updates, attended sysupgrade is not a good replacement for updates. When there are pending updates, either a package or even a new image, it is not easy to know that and what was fixed. The user has no known reason for updates. For a package, repos could provide a .changelog file, even if it was a simple raw git log. For images, it would be nice if a service like the "attended upgrade" could summarize a custom changelog for that device, with some red ink for security issues. Packages that provide kernel modules are always broken when they are updated in repo. This happens because the kernel (or its config) in the stable branch is a moving target, introducing a different kernel dependency. Buildbot always builds with the latest SDK (and kernel), which will generate kmod packages not compatible with any released images. The current workaround is to postpone those package commits until a new dot release is about to be released and manually merge them. The real solution would be to compile package mods also for each released SDK. I think the "use another downstream distribution" is the worst option by far. It simply hopes that different subgroups will independently solve the same OpenWrt issues (multiple times) and using less resources than solving them inside OpenWrt. It does not make any sense for me. It is just asking for that "other downstream distribution" to become the "de facto" new OpenWrt. I know it is not nice to maintain old releases but it is part of what a good Linux distribution should do. The reason for an OSS project is its users and reduce the number of users never helped an OSS project. I hope some day OpenWrt will be able to provide an trusted automated update system just like any decent OS and stopping to providing binary package updates for release builds just goes backwards this path. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Question regarding default qos_map_set (a5e3def1822431ef6436cb493df77006dbacafd6)
Dear Felix, with great joy did I notice that you enabled the qos_map_set feature of hostapd and supply a new default map that aligns OpenWrt's DSCP-2-AC mapping with RFC8325 Cimmit: a5e3def1822431ef6436cb493df77006dbacafd6 hostapd: add wmm qos map set by default This implements the mapping recommendations from RFC8325, with an update from RFC8622. This ensures that DSCP marked packets are properly sorted into WMM classes. The map can be disabled by setting iw_qos_map_set to something invalid like 'none' Signed-off-by: Felix Fietkau Which sets: set_default iw_qos_map_set 0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56 unraveling this gets us to (0 is coded as DSCP Exception, the rest as DSCP ranges): UP DSCPAC PHBs(decDSCP) Ex0 BE BE(0) BE/CS0(0) Range0 2-16BE CS1(8)**, AF11(10), AF12(12), AF13(14), CS2(16) Range1 1-1 BK LE(1) Range2 - Range3 18-22 BE AF21(18), AF22(20), AF23(22) Range4 24-38 VI CS3(24), AF31(26), AF32(28), AF33(30), CS4(32), AF41(34), AF42(36), AF43(38) Range5 40-40 VI CS5(40) Range6 44-46 VO EF(46) Range7 48-56 VO CS6(48), VA(54), CS7(56) **) This used to be in AC_BK but LE is the new CS1 ;) (I think this changes is justified, as in the past Comcast was reported to inject lots of CS1 marked packets into leaf networks without CS1 actually denoting background/lower effort). My questions for this map now are: a) why the incomplete coverage of the 6bit DSCP value range? This mapping leaves out DSCPs 17, 23, 39, 41-43, 47, 57-63 completely, which is odd (I assume these will map to UP_0 but am not sure). RFC8325 recommends to map all not explicitly mentioned DSCPs to UP0, which might allow a conceptually simpler qos_map_set setting all DSCPs to UP_0 and leveraging the up to 21 exceptions (see * below) for the relevant mappings of the named PHBs: 1,1,18,3,20,3,22,3,24,4,26,4,28,4,30,4,32,4,34,4,36,4,38,4,40,5,46,6,48,7,54,7,56,7,0,63,255,255,255,255,255,255,255,255,255,255,255,255,255,255 Which has 3 potentially desirable properties: 1) it makes the mappings of anything not AC_BE explicit 2)has no unexplained gaps and 3) follows RFC8325 recommendation to only map the enumerated PHBs. On the other hand it clearly is longer and untested (my router is still on too old an OpenWrt version for qos_map_set to be supported I think) and it assumes that exceptions will get evaluated and honored even if the UP range is set to 255/255. What do you think? Best Regards Sebastian P.S.: I am 100% certain that RFC8325's recommendations were actually tested under mildly adverse real life conditions (I would guess that was tested in clean enterprise WiFi environments with appropriate admission control), EF markings are not super rare and putting these in AC_VO can pummel throughput in lower ACs to some degree (if there is more than the occasional EF packet). *) ### hostapd/wpad qos_map # QoS Map Set configuration # # Comma delimited QoS Map Set in decimal values # (see IEEE Std 802.11-2012, 8.4.2.97) # # format: # [,],... # # There can be up to 21 optional DSCP Exceptions which are pairs of DSCP Value # (0..63 or 255) and User Priority (0..7). This is followed by eight DSCP Range # descriptions with DSCP Low Value and DSCP High Value pairs (0..63 or 255) for # each UP starting from 0. If both low and high value are set to 255, the # corresponding UP is not used. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
bcm4908: NetGear OEM firmware for R7900P identical to R8000P
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- The information supporting the Subject is documented in this OpenWRT forum thread: https://forum.openwrt.org/t/kernel-patches-netgear-r8000p-r7900p/114540 My neighbor has a R7900P and it is likely to be unsupported from a security point-of-view shortly (Netgear stops all support 3 years after the last unit is manufactured). I was going to try to build a R7900P image labeled as such but am not sure what to do with the kernel 5.10 patches. Duplicating the patches might work for my build, but the projects bulk builds would patch a previously patched kernel. I previously added the TRENDnet TEW-810DR which had the same Board ID as the D-Link DIR-810L which did not involve kernel patches. Any guidance on how to deal with the patches? -- J. Scott Heppler --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
bcm4908: NetGear OEM firmware for R7900P identical to R8000P
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- The information supporting the Subject is documented in this OpenWRT forum thread: https://forum.openwrt.org/t/kernel-patches-netgear-r8000p-r7900p/114540 My neighbor has a R7900P and it is likely to be unsupported from a security point-of-view shortly (Netgear stops all support 3 years after the last unit is manufactured). I was going to try to build a R7900P image labeled as such but am not sure what to do with the kernel 5.10 patches. Duplicating the patches might work for my build, but the projects bulk builds would patch a previously patched kernel. I previously added the TRENDnet TEW-810DR which had the same Board ID as the D-Link DIR-810L. It did not involve kernel patches. Any guidance on how to deal with the patches? -- J. Scott Heppler --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07] wolfssl: update to 4.8.1-stable
On Sun, Dec 12, 2021 at 12:11 PM Petr Štetiar wrote: > > I'm wondering if we can do such an upgrade as the binary compatibility report > for > wolfSSL 4.7.0 vs 4.8.0 looks quite scary to me. Would it be possible to just > backport those patches which fixes those security related issues? > Most wolfSSL releases have binary compatibility issues. I would not recommend anyone to update just the package, even if the abi-laboratory report was less scary. This illustrates well the problem with binary package updates that jow wants to address. I was not sure if it would be acceptable to do the version update, but then we went from 4.3.0 in 19.07.0 to 4.5.0 in 19.07.4, then 4.6.0 in 19.07.5, and 4.7.0 in 19.07.8, so why not 4.8.1? OpenWrt 19.07 support is officially limited to security maintenance, so we can cherry-pick a couple of wolfssl commits instead: 73076940a Fix CompareOcspReqResp. f93083be7 OCSP: improve handling of OCSP no check extension (excluding tests): src/ssl.c | 2 +- wolfcrypt/src/asn.c | 19 --- wolfssl/wolfcrypt/asn.h | 1 + 3 files changed, 14 insertions(+), 8 deletions(-) Just let me know what's the best approach here. After this is done--whether update or patch--I intend to propose a patch to build with WOLFSSL_ALT_CERT_CHAINS to avoid the problems with letsencrypt certificates. One can argue that it is a security fix, considering that the alternative is to skip certificate validation. If this is going to be NAKed, then I'll skip the trouble. BTW, wolfssl, 5.0.0 is out, but I've been unable to make it work with the letsencrypt certificates even with the build-option active--there may be other problems that I don't recall now, I haven't looked at it lately. I'll return to it when able. Meanwhile, I'll try to get patches for the security problems that were fixed. Cheers, Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Identifying UBI volume instance / storing UBI volume metadata
> On 9.12.2021 21:11, Olivier Valentin wrote: > > How about storing the squashfs into the rootfs ubi volume (as a > > bare file), start with an initramfs appended to the kernel and > > mount the root file with loopback block dev. The RW overlay part > > would be stored directly in the ubifs. (All modifications to the > > root image file would go in the overlay, so impossible to break > > the image) > > > > This way, when you flash a new firmware, everything gets wiped, and > > you can factory reset by rm the RW directory. > > > > It diverges quite a bit from OpenWRT usual way though. > > Thanks for your reply. It doesn't fit OpenWrt's current design well > but > I think it's probably time to rework OpenWrt's init if needed. > > Just to make sure I understood your correctly: > > Do you suggest "rootfs" UBI volume using ubifs with something like: > /root.squashfs > /overlay/ > > (and then initramfs as you described)? Hello, I think you got the idea I would boot with: - mount ubifs:rootfs as /rw - loopback mount /rw/root.squashfs as /root - bind mount /rw as /root/overlay - pivot_root under /root - mount overlayfs as usual I never tried this twisted idea; I just don't yet see any reason why it wouldn't work :) Regards, Olivier ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] toolchain: musl: disable crypt size hack by default
Enable this option and thus re-include crypt() support for the SHA256,
SHA512 and Blowfish ciphers on all devices. According to commit
9365745f8e7b ("musl: add a hack to remove unused crypt() algorithms,
saves ~14k after lzma") it should add about ~14k to the resulting image,
which seems to be a reasonable size increase for consistent crypt()
support.
Decided to not remove this hack completely as it might be still useful
for people trying to fit custom images onto smaller devices and the
patch is rather simple so we can afford to keep it for now.
References: https://github.com/openwrt/openwrt/pull/1331
Signed-off-by: Petr Štetiar
---
Changes since v1:
* enable full crypt() support on all devices (Jo)
toolchain/musl/Config.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/toolchain/musl/Config.in b/toolchain/musl/Config.in
index 7e83b6fa535d..a8feeffbc860 100644
--- a/toolchain/musl/Config.in
+++ b/toolchain/musl/Config.in
@@ -3,7 +3,7 @@
config MUSL_DISABLE_CRYPT_SIZE_HACK
bool "Include crypt() support for SHA256, SHA512 and Blowfish ciphers"
depends on TOOLCHAINOPTS && USE_MUSL && !EXTERNAL_TOOLCHAIN
- default n
+ default y
help
Enable this option to re-include crypt() support for the SHA256,
SHA512 and
Blowfish ciphers. Without this option, attempting to hash a string
with a salt
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] toolchain: musl: disable crypt size hack on !SMALL_FLASH devices
Hi, while the decision to do that seems obvious on first sight, I think that supporting different password hashing algorithms on different targets might lead to unexpected surprises for downstream users. E.g. when precalculated password hashes taken from one device are built inside custom firmware images for another small flash device and suddenly the login is not working anymore. I'd rather reenable all hash types for all targets, even small flash ones to maintain consistency. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] toolchain: musl: disable crypt size hack on !SMALL_FLASH devices
Enable this option and re-include crypt() support for the SHA256, SHA512
and Blowfish ciphers on devices which have enough flash space. According
to commit 9365745f8e7b ("musl: add a hack to remove unused crypt()
algorithms, saves ~14k after lzma") it should add about ~14k to the
resulting image.
References: https://github.com/openwrt/openwrt/pull/1331
Signed-off-by: Petr Štetiar
---
toolchain/musl/Config.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/toolchain/musl/Config.in b/toolchain/musl/Config.in
index 7e83b6fa535d..f38791598a98 100644
--- a/toolchain/musl/Config.in
+++ b/toolchain/musl/Config.in
@@ -3,7 +3,7 @@
config MUSL_DISABLE_CRYPT_SIZE_HACK
bool "Include crypt() support for SHA256, SHA512 and Blowfish ciphers"
depends on TOOLCHAINOPTS && USE_MUSL && !EXTERNAL_TOOLCHAIN
- default n
+ default y if !SMALL_FLASH
help
Enable this option to re-include crypt() support for the SHA256,
SHA512 and
Blowfish ciphers. Without this option, attempting to hash a string
with a salt
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
