Re: OpenWrt One vs. EU Cyber Resilience Act
On Fri, Jan 19, 2024 at 09:18:02PM +0100, Hauke Mehrtens wrote: > The EU is working on a EU Cyber Resilience Act to improve the software > security of (consumer) software and (consumer) hardware which contains > software. This should be similar to the CE sign, but for software. > https://en.wikipedia.org/wiki/Cyber_Resilience_Act > > After the successful lobbying of multiple open source organizations non > commercial open source software developer would be exempt from this > regulation. As far as I understood the OpenWrt project would not be affected > by this regulation, but if a vendor uses OpenWrt on a router, this vendor > has to make sure that his product including OpenWrt is compliant when > selling onto the EU market. With the OpenWrt One we or Banana Pi could also > get required to take care of this regulation. > > Did someone look into the requirements needed to make OpenWrt compliant to > the EU Cyber Resilience Act for a commercial entity? > > Did someone look into this regulation with the OpenWrt One project in mind? Yes, per your email, we at SFC looked into this today. SFC believes that the compliance with this regulation will be the manufacturer's responsibility. Denver Gingerich Director of Compliance Software Freedom Conservancy ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] boot: Bump the BCM53xx U-Boot to 2024.01
-+# CONFIG_NET is not set -+# CONFIG_EFI_LOADER is not set a/doc/board/broadcom/index.rst -+++ b/doc/board/broadcom/index.rst -@@ -9,3 +9,4 @@ Broadcom - -bcm7xxx -raspberrypi -+ northstar /dev/null -+++ b/doc/board/broadcom/northstar.rst -@@ -0,0 +1,44 @@ -+.. SPDX-License-Identifier: GPL-2.0+ -+.. Copyright (C) 2023 Linus Walleij -+ -+Broadcom Northstar Boards -+= -+ -+This document describes how to use U-Boot on the Broadcom Northstar -+boards, comprised of the Cortex A9 ARM-based BCM470x and BCM5301x SoCs. These -+were introduced in 2012-2013 and some of them are also called StrataGX. -+ -+Northstar is part of the iProc SoC family. -+ -+A good overview of these boards can be found in Jon Mason's presentation -+"Enabl
[PATCH v2] imx: add imx8m support (pull-request; reviewers needed)
Greetings, I've sent a v2 of my patch to add imx8m/cortexta53 support to the mailing list but it got caught needing moderator approval due to 'Too many recipients to the message' (I cc'd merely 8 people that had participated in the previous discussions). It seems these days that patch submission via the mailing list is not really the way to go anymore. The github pull requests are backed by a pretty slick CI that auto-builds all affected targets with your patch and the review system there is very nice. So I've send my v2 patch as a pull-request: https://github.com/openwrt/openwrt/pull/14434 Please take a look and review if you are interested in imx8m support for OpenWrt. Best Regards, Tim ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One vs. EU Cyber Resilience Act
The EU is working on a EU Cyber Resilience Act to improve the software security of (consumer) software and (consumer) hardware which contains software. This should be similar to the CE sign, but for software. https://en.wikipedia.org/wiki/Cyber_Resilience_Act After the successful lobbying of multiple open source organizations non commercial open source software developer would be exempt from this regulation. As far as I understood the OpenWrt project would not be affected by this regulation, but if a vendor uses OpenWrt on a router, this vendor has to make sure that his product including OpenWrt is compliant when selling onto the EU market. With the OpenWrt One we or Banana Pi could also get required to take care of this regulation. Did someone look into the requirements needed to make OpenWrt compliant to the EU Cyber Resilience Act for a commercial entity? Did someone look into this regulation with the OpenWrt One project in mind? I support the general idea of the EU to improve the security of software. I think the current draft is much better regarding open source than the first versions. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Are we still use md5 as default as password hash?
If there is no objection I’d go ahead and merge this? https://github.com/openwrt/openwrt/pull/14426 * busybox: enable sha hash for /etc/shadow * busybox: switch to sha256 for passwd Best, Paul > On Jan 19, 2024, at 08:38, abnoeh wrote: > > sorry, use_bcrypt isn't something in mainline busybox but a patched > vesrion so I think sha256 is best option here > > 2024-01-19 오후 4:28에 abnoeh 이(가) 쓴 글: >> that option only applies if we use busybox internal crypt, >> BUSYBOX_DEFAULT_USE_BB_CRYPT is set but we don't so it doesn't needed >> (it's using musl here) >> >> you'd need to change this option (line 1367) on same file >> >> config BUSYBOX_DEFAULT_FEATURE_DEFAULT_PASSWD_ALGO >> string >> default "md5" >> >> to something better like sha256 or sha512: this will make all new >> passwds to use new hash (shell or luci), but won't upgrade without user >> changing it first. but we'd better expose and set USE_BCRYPT of busybox >> option to be able to use bcrypt here (not sure routers cpu can handle it >> as it's made to be slow though. >> >> 2024-01-18 오후 8:21에 Paul Spooren 이(가) 쓴 글: >>> Hi, >>> however Busybox doesn't configed to use those and still use md5 as default, while we bring other hash algos into flash anyway: >>> Does the following do the trick? >>> >>> diff --git a/package/utils/busybox/Config-defaults.in >>> b/package/utils/busybox/Config-defaults.in >>> index b3c3f9a0b2..5ae8dd5622 100644 >>> --- a/package/utils/busybox/Config-defaults.in >>> +++ b/package/utils/busybox/Config-defaults.in >>> @@ -1333,7 +1333,7 @@ config BUSYBOX_DEFAULT_USE_BB_CRYPT >>> default n >>> config BUSYBOX_DEFAULT_USE_BB_CRYPT_SHA >>> bool >>> - default n >>> + default y >>> config BUSYBOX_DEFAULT_ADD_SHELL >>> bool >>> default n >>> >>> If so I’d create a PR >>> >>> Best, >>> Paul >>> ___ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Ivan Ivanov writes: > blobless ath9k OK, I'll bite. Get yourself a microscope and look closer at that chip. You might find some code in there, even if the driver didn't load any. Please ask Qualcomm for the source and come back when you've got it. Modern systems contain a large number of binary blobs. Every single processor will come with some kind of firmware attached - either in persistent storage hidden from the rest of the system or as files for some driver to load. And there are processors everywhere. In the SoC obviously, in the WiFi controllers, in the switch, in any peripheral, in the LED controller, etc. A "libre" system is an illusion. It is completely impossible to create any sort of modern computer with no closed source parts. Of course, I know of many projects claiming otherwise. They are clinging to some very limited defintion of the hardware vs software border, allwong them to define any non-upgradable chip as "hardware". Which is utterly stupid since this actually prevents the system from ever being able to run open source code on that chip. Just my .02 € Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Dear community, This is an excellent idea by Dave Taht to use multiple ath9k chips. Actually, I don't understand: how for a "modern, open, stable" WiFi platform - someone could suggest a blobbed Mediatek or even worse, Broadcom. an OpenWRT official device should be no worse than LibreCMC-supported routers in regards to openness and freedom (fork of OpenWRT for routers which could run on 100% opensource without any binary blobs) . If you take some random Mediatek with crappy binary blobs as the base, such a router won't be any better than what you could get at store for a much cheaper price :P A higher price of OpenWRT router would be much more justified by "no binary blobs" as the primary selling point. So the solution is either to put multiple blobless ath9k chips or reverse-engineer & liberate the firmware of some newer WiFi chip (or even create a new WiFi chip by crowdfunding). There are no other sane options in sight > Dave Taht wrote: > I would actually, be happy cutting even more multiplexing latency out of the > ath9k chips Best regards, Ivan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: makefile debugging
Hi Tim, > I seem to recall a way to ask OpenWrt's build system to output a list > of all variable values used in the build but can't find it documented > or in my notes. Does anyone know how to do that? > > Also, is there a way to output a post-processed Makefile after all the > define foo gets done? I find it pretty difficult to work through the > build system, especially when working with images. For packages at least this works for me: TOPDIR=$(pwd) make --no-print-directory -C package/network/services/unetd/ val.PKG_CONFIG_DEPENDS Best, lynxis PS. original seen on https://github.com/ads-tec/sbom-openwrt/blob/6baf6702ffa1d3666db4aeca5084fc79569977f8/lib/utils.py#L138 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
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 --- On 2024-01-17 16:21, John Crispin wrote: Additional FAQ for OpenWrt One This is a summary of some further questions regarding the OpenWrt One project gathered so far. After OpenWrt voted to move forward, it will be converted into a page within the OpenWrt wiki as a place for collecting the latest information. Q: Will the various hardware buttons and switches be fully exposed on the outside? A: The latest iteration of the design will fully expose all buttons and switches. Q: Will there be an option to purchase preassembled kits? A: We're considering that option but still need to explore possibilities with the manufacturer. Q: When do you expect general availability? A: Once we vote to move forward, it will take around 45 days until the first PCBA engineering samples get shipped. These will be passed on to developers for testing. Once they are verified it will probably take another 30-45 days until they can be ordered. So we are looking at April timeframe. Q: What kind of power supply is needed? A: While the initial announcement imprecisely referred to the power supply as "USB-PD 12V" the PCB will draw its required power from a USB-C PD 3.0/2.0 source. Q: Why does the current design not feature any USB 3.0 connectivity? A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We would like to reduce risk as much as possible. Interference proofing the board would add considerable complexity and costs. Q: Why did you implement a M.2 slot? A: After careful consideration we came to the conclusion that directly exposing a PCIe 1x lane in the form of an M.2 slot provides the most flexibility for potential expansions. It can be used for NVMe storage (up to 2242 when using an enclosure), e.g. to host containers or media files. It also enables the simple use of other, non-OpenWrt distributions with larger storage footprints. Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)? A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor is there a fully integrated tri-band SoC solution available right now, let alone fully or partially supported upstream. Supporting Wi-Fi 7 would drastically increase the overall costs and make it impossible to deliver sufficient software support in the foreseeable future. Q: Why are there only two ethernet ports? A: We didn't want to impose additional complexity and costs by including an external managed switch IC. One port is 1GBit/s capable, while the other features a speed up to 2.5GBit/s. This is a limitation of the chosen SoC. Makes sense. Most people already have additional switches at home to accommodate more than the typically 4-5 ports router have. Will there be no limitation on which of the ports is the WAN or the LAN (e.g. due to offloading)? Would it be an idea to have a connector with SPI/I2C, power and preferably direct access to the media interface to be able to connect your own switch board? Then you can still control the switch from OpenWRT. Q: Why should I get the One? There are more capable, more featured devices available! A: The OpenWrt One is intended to serve as a robust and simple educational platform for OpenWrt enthusiasts, it is neither intended to be a competitor to off the shelf SOHO routers nor do we aim for the largest possible amount of features. It also serves as a donation vehicle for the OpenWrt project. Q: Does that mean that OpenWrt will stop supporting other hardware? A: There is no intention at all to change the way OpenWrt operates or how it implements and supports current and future hardware. The OpenWrt One device will be supported as one device among many others and receive the same level of support. Q: Doesn't this draw attention away from properly supporting existing devices? A: The OpenWrt One project is a privately led initiative by a few enthusiasts, there is no intent to change the focus of the OpenWrt project in any way. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
