Re: Initial flashing over "OEM-OpenWrt"
Feb 8, 2021 5:06:28 AM Piotr Dymacz : Hi Adrian, On 06.02.2021 17:42, Adrian Schmutzler wrote: Hi, when reviewing device-support PRs, I frequently encounter the case that initial flashing means sysupgrading from an OEM-modified OpenWrt. This obviously means that the config of this OEM-OpenWrt should be wiped to prevent config-clashes, but since we only provide sysupgrade in this case we can only tell the user to do so. In this context, I wonder whether we should exploit the compat_version for that purpose, i.e. make the initial "proper" OpenWrt image version 1.1. Since the OEM-OpenWrt won't know about compat_version, this technically will have the same effect as removing SUPPORTED_DEVICES, i.e. the user will need to use -F (and we still can't check whether he uses the necessary -F -n). However, the compat_version approach will give us the chance to show an additional message, and thus at least will allow to instruct the user during the upgrade itself, and not just in the Wiki or in the commit message (which he might or might not read). The purpose of this e-mail is thus to ask: 1. Do we need this, or do we just expect the user to care, i.e. if he breaks the device by keeping config it's his fault? Users are supposed to read flashing instructions provided by the author of device's support and follow them. In case of a soft-brick, we have failsafe and factory reset which is definitely enough to fix this "problem". Let's give our users a little trust here. Ack 2. Is the compat_version solution acceptable? Definitely not, but do we really want to introduce more bloat and magic just to prevent some extremely rare users mistakes? Please, don't. 3. Does somebody have a better idea, or are there already other solutions to the problem I don't know? Personally I don't consider it as a problem at all. I believe you should also look at this from the other side. There are vendors which are up to date with our code base and updating with preserving setting is doable and safe (I'm assuming stable releases here). -- Cheers, Piotr Recent example is e.g. this one: https://github.com/openwrt/openwrt/pull/3816 Thanks Adrian ___ 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: [PATCH v2] openpgm: Add Pragmatic General Multicast library
openpgm: Add Pragmatic General Multicast library
Signed-off-by: Ye Holmes
---
Sorry for the late reply; I found the messages in the "Junk"
section from my thunderbird email client, my bad, :)
On Sun, 7 Feb 2021 21:31:45 +, Paul Spooren wrote:
> Can't this package go to packages.git?
Yes, I indeed wanted to push the package into packages.git,
but I didn't and don't know how to push it, I can't find
related information from official website, sorry again...
On Sonntag, 3. Januar 2021 12:43, Adrian wrote:
> this lacks a commit message.
Sorry, again!
---
libs/openpgm/Makefile | 64 +++
.../0001-Rename-openpgm-5.2.pc.in.patch | 22 +++
...hecksum.c-fix-build-with-32-bits-MMX.patch | 38 +++
3 files changed, 124 insertions(+)
create mode 100644 libs/openpgm/Makefile
create mode 100644 libs/openpgm/patches/0001-Rename-openpgm-5.2.pc.in.patch
create mode 100644
libs/openpgm/patches/0002-openpgm-pgm-checksum.c-fix-build-with-32-bits-MMX.patch
diff --git a/libs/openpgm/Makefile b/libs/openpgm/Makefile
new file mode 100644
index 0..15a03e926
--- /dev/null
+++ b/libs/openpgm/Makefile
@@ -0,0 +1,64 @@
+#
+# Copyright (C) 2021 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+# This Makefile for OpenPGM
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=openpgm
+PKG_VERSION:=5.3.128
+PKG_RELEASE:=1
+
+PKG_SOURCE:=release-5-3-128.tar.gz
+PKG_SOURCE_URL:=https://github.com/steve-o/openpgm/archive
+PKG_HASH:=8d707ef8dda45f4a7bc91016d7f2fed6a418637185d76c7ab30b306499c6d393
+
+PKG_MAINTAINER:=Ye Holmes
+PKG_LICENSE:=LGPL-2.1-or-later
+PKG_LICENSE_FILES:=openpgm/pgm/LICENSE
+PKG_CPE_ID:=cpe:/a:openpgm:openpgm
+
+PKG_FIXUP:=autoreconf
+PKG_BUILD_DIR:=$(BUILD_DIR)/openpgm-release-5-3-128
+include $(INCLUDE_DIR)/package.mk
+
+define Package/openpgm
+ TITLE:=OpenPGM, an implementation of the PGM protocol
+ URL:=http://openpgm.googlecode.com/
+ SECTION:=libs
+ CATEGORY:=Libraries
+endef
+
+define Package/openpgm/description
+ OpenPGM is a library implementing the PGM reliable multicast
+ network protocol. For more information about OpenPGM, see:
+ http://openpgm.googlecode.com/
+endef
+
+CONFIGURE_VARS += ac_cv_file__proc_cpuinfo=yes \
+ac_cv_file__dev_rtc=no ac_cv_file__dev_hpet=no
+CONFIGURE_ARGS += --enable-static=no --enable-shared=yes
+
+define Build/Prepare
+ $(call Build/Prepare/Default)
+ mv $(PKG_BUILD_DIR)/openpgm/pgm/* $(PKG_BUILD_DIR)/
+endef
+
+define Build/InstallDev
+ $(INSTALL_DIR) $(1)/usr/include/pgm
+ $(CP) $(PKG_BUILD_DIR)/include/pgm/* $(1)/usr/include/pgm/
+ $(INSTALL_DIR) $(1)/usr/lib/pkgconfig
+ $(CP) $(PKG_BUILD_DIR)/.libs/libpgm*.so* $(1)/usr/lib/
+ $(CP) $(PKG_BUILD_DIR)/openpgm-5.3.pc $(1)/usr/lib/pkgconfig/
+endef
+
+define Package/openpgm/install
+ $(INSTALL_DIR) $(1)/usr/lib
+ $(CP) $(PKG_BUILD_DIR)/.libs/libpgm*.so* $(1)/usr/lib/
+endef
+
+$(eval $(call BuildPackage,openpgm))
diff --git a/libs/openpgm/patches/0001-Rename-openpgm-5.2.pc.in.patch
b/libs/openpgm/patches/0001-Rename-openpgm-5.2.pc.in.patch
new file mode 100644
index 0..a51a026f9
--- /dev/null
+++ b/libs/openpgm/patches/0001-Rename-openpgm-5.2.pc.in.patch
@@ -0,0 +1,22 @@
+From 240634b1afb968a051f8c68696eae2a582a02450 Mon Sep 17 00:00:00 2001
+From: Fabrice Fontaine
+Date: Mon, 31 Aug 2020 20:16:25 +0200
+Subject: [PATCH 1/2] Rename openpgm-5.2.pc.in
+
+This will fix the following build failure:
+
+config.status: error: cannot find input file: `openpgm-5.3.pc.in'
+
+Signed-off-by: Fabrice Fontaine
+---
+ openpgm/pgm/{openpgm-5.2.pc.in => openpgm-5.3.pc.in} | 0
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ rename openpgm/pgm/{openpgm-5.2.pc.in => openpgm-5.3.pc.in} (100%)
+
+diff --git a/openpgm/pgm/openpgm-5.2.pc.in b/openpgm/pgm/openpgm-5.3.pc.in
+similarity index 100%
+rename from openpgm/pgm/openpgm-5.2.pc.in
+rename to openpgm/pgm/openpgm-5.3.pc.in
+--
+2.25.1
+
diff --git
a/libs/openpgm/patches/0002-openpgm-pgm-checksum.c-fix-build-with-32-bits-MMX.patch
b/libs/openpgm/patches/0002-openpgm-pgm-checksum.c-fix-build-with-32-bits-MMX.patch
new file mode 100644
index 0..2012021c0
--- /dev/null
+++
b/libs/openpgm/patches/0002-openpgm-pgm-checksum.c-fix-build-with-32-bits-MMX.patch
@@ -0,0 +1,38 @@
+From b7fa865fa6b06d97d424c500fd1c4bc44c096359 Mon Sep 17 00:00:00 2001
+From: Fabrice Fontaine
+Date: Sun, 1 Nov 2020 22:46:18 +0100
+Subject: [PATCH 2/2] openpgm/pgm/checksum.c: fix build with 32 bits MMX
+
+Build with i386-pentium-mmx or i686 is broken since version 5-3-128 and
+https://github.com/steve-o/openpgm/commit/b276dc15be5d4e6e1143b9de25d09f63f9c85135
+because _mm_cvtm64_si64 is undefined resulting in the following build
+failure for example on zeromq:
+
+/srv/storage/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/i586-buildroot-linux-musl/8.3.0/../../../..
[PATCH] wolfssl: Backport fix for CVE-2021-3336
This should fix CVE-2021-3336:
DoTls13CertificateVerify in tls13.c in wolfSSL through 4.6.0 does not
cease processing for certain anomalous peer behavior (sending an
ED22519, ED448, ECC, or RSA signature without the corresponding
certificate).
The patch is backported from the upstream wolfssl development branch.
Signed-off-by: Hauke Mehrtens
---
package/libs/wolfssl/Makefile | 2 +-
.../wolfssl/patches/010-CVE-2021-3336.patch | 53 +++
2 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 package/libs/wolfssl/patches/010-CVE-2021-3336.patch
diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index dcc6aca40cb4..ff01fca66310 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=wolfssl
PKG_VERSION:=4.6.0-stable
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
diff --git a/package/libs/wolfssl/patches/010-CVE-2021-3336.patch
b/package/libs/wolfssl/patches/010-CVE-2021-3336.patch
new file mode 100644
index ..abb9bfdd9bcb
--- /dev/null
+++ b/package/libs/wolfssl/patches/010-CVE-2021-3336.patch
@@ -0,0 +1,53 @@
+From fad1e67677bf7797b6bd6e1f21a513c289d963a7 Mon Sep 17 00:00:00 2001
+From: Sean Parkinson
+Date: Thu, 21 Jan 2021 08:24:38 +1000
+Subject: [PATCH] TLS 1.3: ensure key for signature in CertificateVerify
+
+---
+ src/tls13.c | 18 +-
+ 1 file changed, 13 insertions(+), 5 deletions(-)
+
+--- a/src/tls13.c
b/src/tls13.c
+@@ -5624,28 +5624,36 @@ static int DoTls13CertificateVerify(WOLF
+ #ifdef HAVE_ED25519
+ if (args->sigAlgo == ed25519_sa_algo &&
+
!ssl->peerEd25519KeyPresent) {
+-WOLFSSL_MSG("Oops, peer sent ED25519 key but not in verify");
++WOLFSSL_MSG("Peer sent ED22519 sig but not ED22519 cert");
++ret = SIG_VERIFY_E;
++goto exit_dcv;
+ }
+ #endif
+ #ifdef HAVE_ED448
+ if (args->sigAlgo == ed448_sa_algo && !ssl->peerEd448KeyPresent) {
+-WOLFSSL_MSG("Oops, peer sent ED448 key but not in verify");
++WOLFSSL_MSG("Peer sent ED448 sig but not ED448 cert");
++ret = SIG_VERIFY_E;
++goto exit_dcv;
+ }
+ #endif
+ #ifdef HAVE_ECC
+ if (args->sigAlgo == ecc_dsa_sa_algo &&
+
!ssl->peerEccDsaKeyPresent) {
+-WOLFSSL_MSG("Oops, peer sent ECC key but not in verify");
++WOLFSSL_MSG("Peer sent ECC sig but not ECC cert");
++ret = SIG_VERIFY_E;
++goto exit_dcv;
+ }
+ #endif
+ #ifndef NO_RSA
+ if (args->sigAlgo == rsa_sa_algo) {
+-WOLFSSL_MSG("Oops, peer sent PKCS#1.5 signature");
++WOLFSSL_MSG("Peer sent PKCS#1.5 algo but not in certificate");
+ ERROR_OUT(INVALID_PARAMETER, exit_dcv);
+ }
+ if (args->sigAlgo == rsa_pss_sa_algo &&
+ (ssl->peerRsaKey == NULL ||
!ssl->peerRsaKeyPresent)) {
+-WOLFSSL_MSG("Oops, peer sent RSA key but not in verify");
++WOLFSSL_MSG("Peer sent RSA sig but not RSA cert");
++ret = SIG_VERIFY_E;
++goto exit_dcv;
+ }
+ #endif
+
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Bitcoin Investment
Do you want 20% Daily Profit ? You can invest in Bitcoin now Kindly give me your response ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Initial flashing over "OEM-OpenWrt"
Hi Adrian, On 06.02.2021 17:42, Adrian Schmutzler wrote: Hi, when reviewing device-support PRs, I frequently encounter the case that initial flashing means sysupgrading from an OEM-modified OpenWrt. This obviously means that the config of this OEM-OpenWrt should be wiped to prevent config-clashes, but since we only provide sysupgrade in this case we can only tell the user to do so. In this context, I wonder whether we should exploit the compat_version for that purpose, i.e. make the initial "proper" OpenWrt image version 1.1. Since the OEM-OpenWrt won't know about compat_version, this technically will have the same effect as removing SUPPORTED_DEVICES, i.e. the user will need to use -F (and we still can't check whether he uses the necessary -F -n). However, the compat_version approach will give us the chance to show an additional message, and thus at least will allow to instruct the user during the upgrade itself, and not just in the Wiki or in the commit message (which he might or might not read). The purpose of this e-mail is thus to ask: 1. Do we need this, or do we just expect the user to care, i.e. if he breaks the device by keeping config it's his fault? Users are supposed to read flashing instructions provided by the author of device's support and follow them. In case of a soft-brick, we have failsafe and factory reset which is definitely enough to fix this "problem". Let's give our users a little trust here. 2. Is the compat_version solution acceptable? Definitely not, but do we really want to introduce more bloat and magic just to prevent some extremely rare users mistakes? Please, don't. 3. Does somebody have a better idea, or are there already other solutions to the problem I don't know? Personally I don't consider it as a problem at all. I believe you should also look at this from the other side. There are vendors which are up to date with our code base and updating with preserving setting is doable and safe (I'm assuming stable releases here). -- Cheers, Piotr Recent example is e.g. this one: https://github.com/openwrt/openwrt/pull/3816 Thanks Adrian ___ 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: Initial flashing over "OEM-OpenWrt"
Hi, > -Original Message- > From: Chuanhong Guo [mailto:gch981...@gmail.com] > Sent: Montag, 8. Februar 2021 08:04 > To: Adrian Schmutzler > Cc: OpenWrt Development List > Subject: Re: Initial flashing over "OEM-OpenWrt" > > Hi! > > On Sun, Feb 7, 2021 at 12:49 AM Adrian Schmutzler > wrote: > > > > Hi, > > > > when reviewing device-support PRs, I frequently encounter the case that > initial flashing means sysupgrading from an OEM-modified OpenWrt. > > > > This obviously means that the config of this OEM-OpenWrt should be > wiped to prevent config-clashes, but since we only provide sysupgrade in this > case we can only tell the user to do so. > > > > In this context, I wonder whether we should exploit the compat_version > for that purpose, i.e. make the initial "proper" OpenWrt image version 1.1. > > Since the OEM-OpenWrt won't know about compat_version, this > technically will have the same effect as removing SUPPORTED_DEVICES, i.e. > the user will need to use -F (and we still can't check whether he uses the > necessary -F -n). > > Wouldn't the same message annoy all current OpenWrt users as OpenWrt > 19.07 and older don't know about compat_version either? Due to that exact reason I planned to only cover new devices supported in the future. > > > However, the compat_version approach will give us the chance to show an > additional message, and thus at least will allow to instruct the user during > the > upgrade itself, and not just in the Wiki or in the commit message (which he > might or might not read). > > > > The purpose of this e-mail is thus to ask: > > 1. Do we need this, or do we just expect the user to care, i.e. if he breaks > the device by keeping config it's his fault? > > Fixing this kind of breakage is as simple as pressing down the reset button if > we have the reset button properly defined. I think that's a fair price to pay > for not reading the instructions :D Yes, _if_ there is a reset button properly defined. I'm just looking for a nicer way to achieve this. (And I don't think compat_version is the optimal way to achieve this, just the best that has come to my mind so far.) Let's see whether the factory-image discussion leds somewhere ... Best Adrian > > -- > Regards, > Chuanhong Guo openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Initial flashing over "OEM-OpenWrt"
Hi, > -Original Message- > From: Henrique de Moraes Holschuh [mailto:henri...@nic.br] > Sent: Montag, 8. Februar 2021 12:02 > To: Chuanhong Guo ; Adrian Schmutzler > > Cc: OpenWrt Development List > Subject: Re: Initial flashing over "OEM-OpenWrt" > > On 08/02/2021 04:03, Chuanhong Guo wrote: > > On Sun, Feb 7, 2021 at 12:49 AM Adrian Schmutzler > > wrote: > >> when reviewing device-support PRs, I frequently encounter the case that > initial flashing means sysupgrading from an OEM-modified OpenWrt. > >> > >> This obviously means that the config of this OEM-OpenWrt should be > wiped to prevent config-clashes, but since we only provide sysupgrade in this > case we can only tell the user to do so. > >> > >> In this context, I wonder whether we should exploit the compat_version > for that purpose, i.e. make the initial "proper" OpenWrt image version 1.1. > >> Since the OEM-OpenWrt won't know about compat_version, this > technically will have the same effect as removing SUPPORTED_DEVICES, i.e. > the user will need to use -F (and we still can't check whether he uses the > necessary -F -n). > > > > Wouldn't the same message annoy all current OpenWrt users as OpenWrt > > 19.07 and older don't know about compat_version either? > > > >> However, the compat_version approach will give us the chance to show > an additional message, and thus at least will allow to instruct the user > during > the upgrade itself, and not just in the Wiki or in the commit message (which > he might or might not read). > >> > >> The purpose of this e-mail is thus to ask: > >> 1. Do we need this, or do we just expect the user to care, i.e. if he > >> breaks > the device by keeping config it's his fault? > > > > Fixing this kind of breakage is as simple as pressing down the reset > > button if we have the reset button properly defined. I think that's a > > fair price to pay for not reading the instructions :D > > Can I humbly suggest providing "factory" images for these devices ? > > After all, it doesn't matter if it is OEM openwrt you're updating from, if it > is > still a "vendor", and we already have this convention of "use factory images > to update from vendor firmware to openwrt"... I'd probably say yes if there was a nice and proper way to force resetting config there _only once_. Is there one I'm just not aware of? Best Adrian > > -- > Henrique de Moraes Holschuh > Analista de Projetos > Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações > (Ceptro.br) > +55 11 5509-3537 R.:4023 > INOC 22548*625 > www.nic.br openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Initial flashing over "OEM-OpenWrt"
On 08/02/2021 04:03, Chuanhong Guo wrote: On Sun, Feb 7, 2021 at 12:49 AM Adrian Schmutzler wrote: when reviewing device-support PRs, I frequently encounter the case that initial flashing means sysupgrading from an OEM-modified OpenWrt. This obviously means that the config of this OEM-OpenWrt should be wiped to prevent config-clashes, but since we only provide sysupgrade in this case we can only tell the user to do so. In this context, I wonder whether we should exploit the compat_version for that purpose, i.e. make the initial "proper" OpenWrt image version 1.1. Since the OEM-OpenWrt won't know about compat_version, this technically will have the same effect as removing SUPPORTED_DEVICES, i.e. the user will need to use -F (and we still can't check whether he uses the necessary -F -n). Wouldn't the same message annoy all current OpenWrt users as OpenWrt 19.07 and older don't know about compat_version either? However, the compat_version approach will give us the chance to show an additional message, and thus at least will allow to instruct the user during the upgrade itself, and not just in the Wiki or in the commit message (which he might or might not read). The purpose of this e-mail is thus to ask: 1. Do we need this, or do we just expect the user to care, i.e. if he breaks the device by keeping config it's his fault? Fixing this kind of breakage is as simple as pressing down the reset button if we have the reset button properly defined. I think that's a fair price to pay for not reading the instructions :D Can I humbly suggest providing "factory" images for these devices ? After all, it doesn't matter if it is OEM openwrt you're updating from, if it is still a "vendor", and we already have this convention of "use factory images to update from vendor firmware to openwrt"... -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re:
On Mon, Feb 8, 2021 at 1:01 AM Etan Kissling (IC) via openwrt-devel wrote: > > 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. > > > -- Forwarded message -- > From: "Etan Kissling (IC)" > To: Baptiste Jonglez > Cc: openwrt-devel@lists.openwrt.org > Bcc: > Date: Mon, 08 Feb 2021 09:58:38 +0100 > Subject: Re: Upcoming 19.07.7 release > I have posted a few backports to 19.07 from master a few weeks back, with > these subjects: > > 1. [PATCH 19.07] mbedtls: add config option to compile with hkdf > 2. [PATCH 19.07] hostapd: add multicast_to_unicast and per_sta_vif > 3. [PATCH 19.07] hostapd: enable CTRL_IFACE_MIB for hostapd-full > 4. [PATCH 19.07] nf-conntrack: allow querying conntrack info in nfqueue > 5. [PATCH 19.07] libnetfilter-queue: update to 1.0.5 > > My patches don't end up in Patchwork for some reason. It's because of DMARC. See: The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. > > If those are acceptable, be sure to take the latest submission for the > patches that were submitted multiple times. > > Thanks > > Etan > > > On 5 Feb 2021, at 08:56, Baptiste Jonglez > > wrote: > > > > Hi, > > > > We are planning a new 19.07 release in about a week (probably next > > week-end). > > > > If you are aware of changes that need to be integrated, now is the time to > > do it or mention it here! > > > > I plan to test & integrate a workaround for this ramips stability issue: > > https://bugs.openwrt.org/index.php?do=details&task_id=2628 > > > > Baptiste > > > > PS: please don't ask about 21.XX > > ___ > > 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
[no subject]
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 --- I have posted a few backports to 19.07 from master a few weeks back, with these subjects: 1. [PATCH 19.07] mbedtls: add config option to compile with hkdf 2. [PATCH 19.07] hostapd: add multicast_to_unicast and per_sta_vif 3. [PATCH 19.07] hostapd: enable CTRL_IFACE_MIB for hostapd-full 4. [PATCH 19.07] nf-conntrack: allow querying conntrack info in nfqueue 5. [PATCH 19.07] libnetfilter-queue: update to 1.0.5 My patches don't end up in Patchwork for some reason. If those are acceptable, be sure to take the latest submission for the patches that were submitted multiple times. Thanks Etan > On 5 Feb 2021, at 08:56, Baptiste Jonglez wrote: > > Hi, > > We are planning a new 19.07 release in about a week (probably next week-end). > > If you are aware of changes that need to be integrated, now is the time to > do it or mention it here! > > I plan to test & integrate a workaround for this ramips stability issue: > https://bugs.openwrt.org/index.php?do=details&task_id=2628 > > Baptiste > > PS: please don't ask about 21.XX > ___ > 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
Revisiting ABI_VERSION handling policy
Hi, I just wasted a few hours of debugging on an issue that turned out to be wolfssl ABI breakage related. At first I thought it was the version bump. While the commit that updates wolfssl claims that the ABI didn't change, a quick look at https://abi-laboratory.pro/index.php?view=timeline&l=wolfssl indicates that this isn't true and the ABI did change after all. When I looked into the details of the ABI change, I found out that this wasn't the cause of my breakage (I had already cleaned my hostapd build after updating wolfssl), but there is something even nastier lurking here: the ABI isn't just affected by the version bump, but by wolfssl configuration changes as well. There are plenty of #if statements inside structs like Aes which are sometimes declared on-stack in hostapd, many of which are affected by the OpenWrt configuration for wolfssl. I think it's very likely that I've been affected by similar breakages in the past, but I can't be absolutely sure now, because I didn't have the time to investigate back then and a lazy make clean made things work again. Either way, this whole ordeal caused me to rethink Jo's commit "packages: set more explicit ABI_VERSION values" The goal of reducing unnecessary build churn makes perfect sense to me, but I think we need to reconsider the trade-off we're making here, and the failure modes of each option. I believe that having to manually consider whether the ABI changed when updating a package comes with a nasty foot-gun that can deliver very subtle and hard to debug failure cases. In my case, hostapd worked just fine and wpa_supplicant was crashing due to a stack overflow whenever I turned on 802.11w on a client interface. Stuff like this makes our trade-off seem very asymmetric to me... To fix this situation, I would like to switch wolfssl and maybe a few other packages prone to ABI breakage back to version based ABI_VERSION. At least wolfssl also needs a short suffix generated from config vars. If we want to reduce build churn, we should find a way to automate setting the ABI version, since clearly our package maintainers + review process cannot (and in my opinion also should not) be trusted with this extra responsibility. Maybe we can replace it with a hash of all installed header files. This might be a better way to resolve cases like this wolfssl instance, but we likely will still be rebuilding dependent packages on most updates. Thoughts? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
