Free software's not-so-eXZellent adventure
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 ---
As to be expected LWN has an excellent article from Corbet [1] that
comes up with questions to be taken seriously by the FOSS community and
especially communities such as OpenWrt that distribute (binary) releases.
One of the comments [2] names some practical rules that may help to
compartmentalise the build processes to enhance resilience against
advanced attacks as experienced by xz.
Another comment [3] touches on a little know but possible useful feature
of github that allows to block/ban presumed trolls etc. That functions
comes with some moral questions though. At the least, this subthread
identifies some of the ("sockpuppet") accounts (on github) that were
used to pressure the maintainer of xz.
[1] https://lwn.net/Articles/967866/
[2] https://lwn.net/Articles/968150/
[3] https://lwn.net/Articles/968496/
Regards,
--
paul oranje
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] uclient-fetch: Make request_types sorted to optimize search
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 ---
Op 06-04-2023 om 23:39 schreef Sergey Ponomarev:
Signed-off-by: Sergey Ponomarev
---
uclient-http.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/uclient-http.c b/uclient-http.c
index c2bba6b..80d4495 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -40,11 +40,11 @@ enum auth_type {
};
enum request_type {
+ REQ_DELETE,
REQ_GET,
REQ_HEAD,
REQ_POST,
REQ_PUT,
- REQ_DELETE,
__REQ_MAX
};
@@ -57,12 +57,13 @@ enum http_state {
HTTP_STATE_ERROR,
};
+// Must be sorted aplhabeticaly
static const char * const request_types[__REQ_MAX] = {
+ [REQ_DELETE] = "DELETE",
[REQ_GET] = "GET",
[REQ_HEAD] = "HEAD",
[REQ_POST] = "POST",
[REQ_PUT] = "PUT",
- [REQ_DELETE] = "DELETE",
};
struct uclient_http {
@@ -991,11 +992,15 @@ uclient_http_set_request_type(struct uclient *cl, const
char *type)
return -1;
for (i = 0; i < ARRAY_SIZE(request_types); i++) {
- if (strcmp(request_types[i], type) != 0)
+ int c = strcmp(request_types[i], type);
+ if (c < 0) {
continue;
-
- uh->req_type = i;
- return 0;
+ } else if (c == 0) {
+ uh->req_type = i;
+ return 0;
+ } else {
+ return -1;
+ }
}
return -1;
Hi Sergey,
Seems okay, but one remark. An else branch after statements like
continue or return is not needed. Without the else the code saves
indents and becomes clearer.
So:
for (i = 0; i < ARRAY_SIZE(request_types); i++) {
- if (strcmp(request_types[i], type) != 0)
+ int c = strcmp(request_types[i], type);
+ if (c < 0) {
continue;
-
- uh->req_type = i;
- return 0;
+ }
+ if (c == 0) {
+ uh->req_type = i;
+ return 0;
+ }
+ return -1;
}
return -1;
Also it looks like the return -1 after the loop can/should be dropped as
that (iff request_types is sorted and contains > 0 elements) can never
be reached. Or the return at the end of the loop block could be dropped
as it provides a neglectible optimalisation.
Regards, Paul
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: irt: tools/squashfs4: enable parallel builds
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 --- > Op 3 apr. 2023, om 23:23 heeft Elliott Mitchell het > volgende geschreven: > > On Mon, Apr 03, 2023 at 09:43:28PM +0800, 刘林辉 wrote: >> The reason may be that my computer is under high load all the time. >> >> So I wrote a simple workflow to test squashfs4 using github actions >> https://github.com/lovehackintosh/Actions-OpenWrt/actions/runs/4597175958. > > Okay, I can believe that. Just an issue that it made the commit message > misleading. Parallel building *can* slow things down. `squashfs4` does > look a bit risky for that since most of its source is in 3 files and > everything else is tiny. > > Might want to ensure your background jobs have been run via `nice` or > run `renice` on them later. This makes benchmarks better guides. > > > > On Mon, Apr 03, 2023 at 09:12:47PM +0200, Paul Oranje wrote: >> >>> Op 3 apr. 2023, om 00:28 heeft Elliott Mitchell het >>> volgende geschreven: >>> >>> Am I the only person who finds commit 3efd49a588 >> Cannot find that one, but have you seen >> 82e1f041f9a6cf9232c9f73938ef3b11c34cca0f ? >> > > 3efd49a588 is about allowing the build process of `squashfs4` to use > multiple processors. Whereas 82e1f041f9 is about allowing `squashfs4` > to use multiple processors during its runtime. Thus these two do not > conflict and do make sense together. > > (FYI `git rev-parse --short 82e1f041f9a6cf9232c9f73938ef3b11c34cca`) Ah, I should have looked better. Thanks > > > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+sig...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > > > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+sig...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > ___ > 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
Re: irt: tools/squashfs4: enable parallel builds
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 ---
Hi,
See below, regards,
Paul
> Op 3 apr. 2023, om 00:28 heeft Elliott Mitchell het
> volgende geschreven:
>
> Am I the only person who finds commit 3efd49a588
Cannot find that one, but have you seen
82e1f041f9a6cf9232c9f73938ef3b11c34cca0f ?
> ("tools/squashfs4: enable parallel builds") a bit odd? Specifically from
> the commit message:
>
>> Run `time make tools/squashfs4/{clean,compile} -j$(nproc)`
>> Before:
>> real0m8.803s
>> user0m12.415s
>> sys 0m1.317s
>> After:
>> real0m13.781s
>> user0m13.290s
>> sys 0m1.528s
>
> So a parallel build of squashfs4 took more processor time in user mode,
> more processor time in supervisor mode, and *more* wall clock time?
>
> More processor time is fine, that comes with coordinating parallel build
> processes. The goal of parallel builds is to spend a bit of processor
> time to *reduce* wall clock time use. Yet a parallel build of
> `squashfs4` is stated to have resulted in a 50% increase?
>
> Uhm. Perhaps your computer's processor interconnect is very slow?
> Does this computer have an extremely high processor count? I do note
> `squashfs4` doesn't have very many source files.
>
> Generally I would support the use of parallel builds, but unless I'm
> missing something this appears the case where it should be avoided.
>
>
> --
> (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
> \BS (| ehem+sig...@m5p.com PGP 87145445 |) /
> \_CS\ | _ -O #include O- _ | / _/
> 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>
>
>
> ___
> 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
Re: netifd Call Flow - WiFi
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 --- Op 16 mrt. 2023, om 05:06 heeft Ravi Paluri (QUIC) het volgende geschreven: > > I think wifi interface going up and coming down is expected. > Can anyone help with flow how does netifd know that wifi interface is up and > where it adds this IP to the interface? The netifd daemon implements a FSM [0] (several nested FSMs, though I haven't looked into the sources) and as such the actual call flow will be dependent on the state of the FSM when it processes a specific event (or command). Have a look at the DESIGN doc [1]. That rather terse document ends though with "## TODO: Configuration management, ubus callbacks" so you'll have to look into the code to see how uci changes are handled. Maybe this helps understanding observed state transitions when for instance handling a configuration change. Good luck [0] https://en.wikipedia.org/wiki/Finite-state_machine [1] https://github.com/openwrt/netifd/blob/master/DESIGN > > Thanks, > Ravi > -Original Message- > From: openwrt-devel On Behalf Of > Ravi Paluri (QUIC) > Sent: Thursday, March 16, 2023 6:37 AM > To: openwrt-devel@lists.openwrt.org > Subject: netifd Call Flow - WiFi > > Hi All, > We are trying netifd to enable wlan. > We have configured uci to set wlan interface IP statically. > We are seeing when we do network reload, wifi interface is going down and > coming up. > > Can we get flow how does netifd know that wifi interface is up and where it > adds this IP to the interface? > This will help us in checking why wifi interface is going down and coming up > on doing network reload. > > Thanks, > Ravi > > ___ > 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 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: X86 partition tables
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 --- Op 22 jan. 2023, om 23:12 heeft Philip Prindeville het volgende geschreven: > > Hi, > > Couple of questions about partition tables on x86 hardware. > > Do most x86 machines (an APUv6 w/ Coreboot in my case, and a Qemu/KVM VM with > Bochs as well) support GPT in BIOS (CGM or whatever)? > > And what are the steps on a live system to (1) convert the MBR partition > table to MBR, and (2) reinstall grub? Assuming you intent to convert MBR to GPT, gdisk offers functionality to that purpose. > > Thanks, > > -Philip > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel Bye, Paul --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: X86 partition tables
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 --- Op 22 jan. 2023, om 23:12 heeft Philip Prindeville het volgende geschreven: > > Hi, > > Couple of questions about partition tables on x86 hardware. > > Do most x86 machines (an APUv6 w/ Coreboot in my case, and a Qemu/KVM VM with > Bochs as well) support GPT in BIOS (CGM or whatever)? > > And what are the steps on a live system to (1) convert the MBR partition > table to MBR, and (2) reinstall grub? Assuming you intent to convert MBR to GPT, gdisk offers functionality to that purpose. > > Thanks, > > -Philip > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel Bye, Paul --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/9] uci: maintain option position in uci_set
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 --- Op 26 nov. 2022, om 11:02 heeft Andre Heider het volgende geschreven: > > On 20/11/2022 02:08, Jan Venekamp wrote: >> Maintain the position of an option in the list when updating an option >> in uci_set. > > Nice, that's really an annoyance! > > I assume this doesn't fix wiping '#' comments when saving through luci? > That's just as annoying :) An alternative for # comments is adding "option comment blabla". These will survive any updates from (L)UCI. > > Cheers, > Andre > > ___ > 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
Re: [PATCH v2 2/9] uci: maintain option position in uci_set
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 --- Op 26 nov. 2022, om 11:02 heeft Andre Heider het volgende geschreven: > > On 20/11/2022 02:08, Jan Venekamp wrote: >> Maintain the position of an option in the list when updating an option >> in uci_set. > > Nice, that's really an annoyance! > > I assume this doesn't fix wiping '#' comments when saving through luci? > That's just as annoying :) An alternative for # comments is adding "option comment blabla". These will survive any updates from (L)UCI. > > Cheers, > Andre > > ___ > 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
Re: [PATCH v2 2/9] uci: maintain option position in uci_set
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 ---
Op 20 nov. 2022, om 02:08 heeft Jan Venekamp het volgende
geschreven:
>
> Maintain the position of an option in the list when updating an option
> in uci_set.
>
> Signed-off-by: Jan Venekamp
> ---
> list.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/list.c b/list.c
> index ac3686c..a8f2a2c 100644
> --- a/list.c
> +++ b/list.c
> @@ -76,7 +76,7 @@ uci_free_element(struct uci_element *e)
> }
>
> static struct uci_option *
> -uci_alloc_option(struct uci_section *s, const char *name, const char *value)
> +uci_alloc_option(struct uci_section *s, const char *name, const char *value,
> struct uci_list *after)
> {
> struct uci_package *p = s->package;
> struct uci_context *ctx = p->ctx;
> @@ -87,7 +87,7 @@ uci_alloc_option(struct uci_section *s, const char *name,
> const char *value)
> o->v.string = uci_dataptr(o);
> o->section = s;
> strcpy(o->v.string, value);
> - uci_list_add(>options, >e.list);
> + uci_list_insert(after ? after : s->options.prev, >e.list);
>
> return o;
> }
> @@ -719,7 +719,7 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
>
> return uci_delete(ctx, ptr);
> } else if (!ptr->o && ptr->option) { /* new option */
> - ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value);
> + ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value,
> NULL);
> ptr->last = >o->e;
> } else if (!ptr->s && ptr->section) { /* new section */
> ptr->s = uci_alloc_section(ptr->p, ptr->value, ptr->section);
> @@ -731,7 +731,7 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
> !strcmp(ptr->o->v.string, ptr->value))
> return 0;
>
> - ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value);
> + ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value,
> >e.list);
> if (ptr->option == old->e.name)
> ptr->option = ptr->o->e.name;
> uci_free_option(old);
> --
> 2.32.0 (Apple Git-132)
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Nice, as this keeps tediously hand-edited config files better intact.
Paul
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/9] uci: maintain option position in uci_set
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 ---
Op 20 nov. 2022, om 02:08 heeft Jan Venekamp het volgende
geschreven:
>
> Maintain the position of an option in the list when updating an option
> in uci_set.
>
> Signed-off-by: Jan Venekamp
> ---
> list.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/list.c b/list.c
> index ac3686c..a8f2a2c 100644
> --- a/list.c
> +++ b/list.c
> @@ -76,7 +76,7 @@ uci_free_element(struct uci_element *e)
> }
>
> static struct uci_option *
> -uci_alloc_option(struct uci_section *s, const char *name, const char *value)
> +uci_alloc_option(struct uci_section *s, const char *name, const char *value,
> struct uci_list *after)
> {
> struct uci_package *p = s->package;
> struct uci_context *ctx = p->ctx;
> @@ -87,7 +87,7 @@ uci_alloc_option(struct uci_section *s, const char *name,
> const char *value)
> o->v.string = uci_dataptr(o);
> o->section = s;
> strcpy(o->v.string, value);
> - uci_list_add(>options, >e.list);
> + uci_list_insert(after ? after : s->options.prev, >e.list);
>
> return o;
> }
> @@ -719,7 +719,7 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
>
> return uci_delete(ctx, ptr);
> } else if (!ptr->o && ptr->option) { /* new option */
> - ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value);
> + ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value,
> NULL);
> ptr->last = >o->e;
> } else if (!ptr->s && ptr->section) { /* new section */
> ptr->s = uci_alloc_section(ptr->p, ptr->value, ptr->section);
> @@ -731,7 +731,7 @@ int uci_set(struct uci_context *ctx, struct uci_ptr *ptr)
> !strcmp(ptr->o->v.string, ptr->value))
> return 0;
>
> - ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value);
> + ptr->o = uci_alloc_option(ptr->s, ptr->option, ptr->value,
> >e.list);
> if (ptr->option == old->e.name)
> ptr->option = ptr->o->e.name;
> uci_free_option(old);
> --
> 2.32.0 (Apple Git-132)
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Nice, as this keeps tediously hand-edited config files better intact.
Paul
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
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 --- Op 14 sep. 2022, om 03:39 heeft Rich Brown het volgende geschreven: > [knip] > How could the code that reads those configuration files handle the presence > of "interface/iface" keywords? Thanks. What about introducing a version setting in the network and wireless UCI ? Which version to assume when not explicitly set ? Then default to the last previous version that is deprecated though not yet obsolete. Or require it be set for deprecated UCI to be processed (i.e. default to current UCI version). > > Rich --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
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 --- Op 14 sep. 2022, om 03:39 heeft Rich Brown het volgende geschreven: > [knip] > How could the code that reads those configuration files handle the presence > of "interface/iface" keywords? Thanks. What about introducing a version setting in the network and wireless UCI ? Which version to assume when not explicitly set ? Then default to the last previous version that is deprecated though not yet obsolete. Or require it be set for deprecated UCI to be processed (i.e. default to current UCI version). > > Rich --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
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 --- Op 9 jan. 2022, om 19:16 heeft Arne Zachlod het volgende geschreven: > > On 1/7/22 10:34, Paul Spooren wrote: >> Hi all, >> Back at the Hamburg meeting in 2019 and a succeeding vote we decided to >> migrate over to a self-hosted GitLab instance. Some years passed and nothing >> really happened so I’d like to give this another go. >> None of the OpenWrt project members is willing to setup and maintain a >> GitLab instance and there were multiple vetos again gitlab.com. > > Hi, > > I just wanted to ask what the concerns against gitlab.com were in this > meeting, and if they still apply now, more than 2 years later? > Maybe it would be a good compromise to go to gitlab instead of github, > because that way we keep the option to migrate to a self hosted instance in > case something goes wrong? > > Arne > LWN has noticeably written about the uncomfortable feelings associated with depending on non-free services: see https://lwn.net/Articles/879697/ sub "Use of centralized, proprietary services will be a bone of contention in 2022" Paul --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
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 --- Op 9 jan. 2022, om 19:16 heeft Arne Zachlod het volgende geschreven: > > On 1/7/22 10:34, Paul Spooren wrote: >> Hi all, >> Back at the Hamburg meeting in 2019 and a succeeding vote we decided to >> migrate over to a self-hosted GitLab instance. Some years passed and nothing >> really happened so I’d like to give this another go. >> None of the OpenWrt project members is willing to setup and maintain a >> GitLab instance and there were multiple vetos again gitlab.com. > > Hi, > > I just wanted to ask what the concerns against gitlab.com were in this > meeting, and if they still apply now, more than 2 years later? > Maybe it would be a good compromise to go to gitlab instead of github, > because that way we keep the option to migrate to a self hosted instance in > case something goes wrong? > > Arne > LWN has noticeably written about the uncomfortable feelings associated with depending on non-free services: see https://lwn.net/Articles/879697/ sub "Use of centralized, proprietary services will be a bone of contention in 2022" Paul --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
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 --- Indeed, so +1 Paul > Op 7 jan. 2022, om 13:07 heeft Sam Kuper het > volgende geschreven: > > On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: >> Instead of maintaining flyspray and the server, I’d like to export all >> flyspray issues, migrate them to GitHub and open GitHub issues for >> openwrt/openwrt to the public. > > Please don't do this. GitHub has substantial accessibility and privacy > flaws, compared to other options - and fails ethical code/bug-hosting > criteria: https://www.gnu.org/software/repo-criteria-evaluation.html > > Please either stick with existing arrangements, or go with an ethical, > accessible code/bug-host (e.g. SourceHut https://sr.ht ). > > Thanks, > > Sam > > ___ > 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
Re: Switch issues and CI to GitHub
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 --- Indeed, so +1 Paul > Op 7 jan. 2022, om 13:07 heeft Sam Kuper het > volgende geschreven: > > On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: >> Instead of maintaining flyspray and the server, I’d like to export all >> flyspray issues, migrate them to GitHub and open GitHub issues for >> openwrt/openwrt to the public. > > Please don't do this. GitHub has substantial accessibility and privacy > flaws, compared to other options - and fails ethical code/bug-hosting > criteria: https://www.gnu.org/software/repo-criteria-evaluation.html > > Please either stick with existing arrangements, or go with an ethical, > accessible code/bug-host (e.g. SourceHut https://sr.ht ). > > Thanks, > > Sam > > ___ > 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
Re: [PATCH fstools] libfstools: support custom executable validating overlay
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 ---
Nice. One small remark though.
HNY, Paul
> Op 4 jan. 2022, om 23:46 heeft Rafał Miłecki het volgende
> geschreven:
>
> From: Rafał Miłecki
>
> This results in calling /usr/libexec/overlay_verify which may either
> modify overlay (e.g. wipe it) or refuse it. It's needed by targets that
> need to validate that "rootfs_data" doesn't come from a previous
> firmware. They may provide a script that will wipe such /outdated/
> overlays.
>
> Signed-off-by: Rafał Miłecki
> ---
> libfstools/overlay.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/libfstools/overlay.c b/libfstools/overlay.c
> index 6790337..281626d 100644
> --- a/libfstools/overlay.c
> +++ b/libfstools/overlay.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -36,6 +37,7 @@
>
> #define SWITCH_JFFS2 "/tmp/.switch_jffs2"
> #define OVERLAYDIR "/rom/overlay"
> +#define OVERLAY_VERIFY "/usr/libexec/overlay_verify"
>
> static bool keep_sysupgrade;
>
> @@ -412,6 +414,33 @@ int fs_state_set(const char *dir, enum fs_state state)
> return symlink(valstr, path);
> }
>
> +/*
> + * Call user custom script (if present) that may perform some extra overlay
> + * validation.
> + */
> +static int overlay_verify(const char *overlay_mp)
> +{
> + struct stat s;
> + pid_t pid;
> +
> + if (stat(OVERLAY_VERIFY, ))
> + return 0;
> +
> + pid = fork();
> + if (!pid) {
> + execl(OVERLAY_VERIFY, OVERLAY_VERIFY, overlay_mp, NULL);
> + exit(EXIT_FAILURE);
> + } else if (pid > 0) {
The else clause is not needed as code after a successful execl() or exit() is
never reached.
> + int wstatus;
> +
> + waitpid(pid, , 0);
> +
> + if (WIFEXITED(wstatus))
> + return WEXITSTATUS(wstatus);
> + }
> +
> + return -1;
> +}
>
> int mount_overlay(struct volume *v)
> {
> @@ -432,6 +461,12 @@ int mount_overlay(struct volume *v)
> if (err)
> return err;
>
> + err = overlay_verify(overlay_mp);
> + if (err) {
> + ULOG_ERR("failed to verify overlay: %d\n", err);
> + return err;
> + }
> +
> /*
>* Check for extroot config in overlay (rootfs_data) and if present then
>* prefer it over rootfs_data.
> --
> 2.31.1
>
>
> ___
> 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
Re: [PATCH fstools] libfstools: support custom executable validating overlay
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 ---
Nice. One small remark though.
HNY, Paul
> Op 4 jan. 2022, om 23:46 heeft Rafał Miłecki het volgende
> geschreven:
>
> From: Rafał Miłecki
>
> This results in calling /usr/libexec/overlay_verify which may either
> modify overlay (e.g. wipe it) or refuse it. It's needed by targets that
> need to validate that "rootfs_data" doesn't come from a previous
> firmware. They may provide a script that will wipe such /outdated/
> overlays.
>
> Signed-off-by: Rafał Miłecki
> ---
> libfstools/overlay.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/libfstools/overlay.c b/libfstools/overlay.c
> index 6790337..281626d 100644
> --- a/libfstools/overlay.c
> +++ b/libfstools/overlay.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -36,6 +37,7 @@
>
> #define SWITCH_JFFS2 "/tmp/.switch_jffs2"
> #define OVERLAYDIR "/rom/overlay"
> +#define OVERLAY_VERIFY "/usr/libexec/overlay_verify"
>
> static bool keep_sysupgrade;
>
> @@ -412,6 +414,33 @@ int fs_state_set(const char *dir, enum fs_state state)
> return symlink(valstr, path);
> }
>
> +/*
> + * Call user custom script (if present) that may perform some extra overlay
> + * validation.
> + */
> +static int overlay_verify(const char *overlay_mp)
> +{
> + struct stat s;
> + pid_t pid;
> +
> + if (stat(OVERLAY_VERIFY, ))
> + return 0;
> +
> + pid = fork();
> + if (!pid) {
> + execl(OVERLAY_VERIFY, OVERLAY_VERIFY, overlay_mp, NULL);
> + exit(EXIT_FAILURE);
> + } else if (pid > 0) {
The else clause is not needed as code after a successful execl() or exit() is
never reached.
> + int wstatus;
> +
> + waitpid(pid, , 0);
> +
> + if (WIFEXITED(wstatus))
> + return WEXITSTATUS(wstatus);
> + }
> +
> + return -1;
> +}
>
> int mount_overlay(struct volume *v)
> {
> @@ -432,6 +461,12 @@ int mount_overlay(struct volume *v)
> if (err)
> return err;
>
> + err = overlay_verify(overlay_mp);
> + if (err) {
> + ULOG_ERR("failed to verify overlay: %d\n", err);
> + return err;
> + }
> +
> /*
>* Check for extroot config in overlay (rootfs_data) and if present then
>* prefer it over rootfs_data.
> --
> 2.31.1
>
>
> ___
> 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
Re: [PATCH netifd] interface: rename "ifname" attribute to "device"
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 --- > Op 17 mei 2021, om 17:47 heeft Rafał Miłecki het volgende > geschreven: > > On 17.05.2021 17:32, Paul Oranje wrote: >> Op 17 mei 2021, om 16:49 heeft Rafał Miłecki het volgende >> geschreven: >>> >>> From: Rafał Miłecki >>> >>> Interfaces need to be assigned to devices. For that purpose a "device" >>> option should be more accurate than "ifname" one. >>> >>> For backward compatibility add a temporary config translation. >>> >>> Config example: >>> >>> config device >>> option name 'lan' >>> option type 'bridge' >>> list ports 'lan1' >>> list ports 'lan2' >>> >>> config interface 'home' >>> option device 'lan' >>> option proto 'static' >> A bit off-topic: the disparency between config section names and an option >> named name is not always clear. > > What do you mean by "not always"? I think it should be consistent: > "interface" UCI section should always use "device" for referencing > "device" UCI section (by its "name"). Indeed. > As for "name" option in the "device" UCI section I thought we could make > it section name instead, but it can't be done due to UCI limitations for > section names: > > [2021-05-14] [16:59:17 CEST] jow: nbd: quick question - could we > have "config device " and drop "option name " ? i see two > advantages: > [2021-05-14] [16:59:21 CEST] 1. it would not allow duplicated names > [2021-05-14] [16:59:21 CEST] 2. referencing devices from "config > interface" would be more natural > [2021-05-14] [17:06:32 CEST] rmilecki: uci section names have > restrictions on what characters are allowed > [2021-05-14] [17:09:40 CEST] nbd: right, thanks > [2021-05-14] [17:10:15 CEST] ah yes, the babeld uci integration > used to do this (interface name in section name), but we had to drop it Ah, that explains. Your reasoning why using section names would be better stands. Assuming the uci limitation in this case concerns not having dashes in section names: Maybe, as long as uci has these restrictions on section naming and the dash cannot be used therein, one could still use an (allowed) device section name and use that for reference from interface sections and using an device option name to override (the name defaults to the section name), or, change how netifd names devices that it (implicitly) creates. Good luck with your endeavour. That proces itself helps understanding the currently implemented model. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH netifd] interface: rename "ifname" attribute to "device"
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 ---
Op 17 mei 2021, om 16:49 heeft Rafał Miłecki het volgende
geschreven:
>
> From: Rafał Miłecki
>
> Interfaces need to be assigned to devices. For that purpose a "device"
> option should be more accurate than "ifname" one.
>
> For backward compatibility add a temporary config translation.
>
> Config example:
>
> config device
> option name 'lan'
> option type 'bridge'
> list ports 'lan1'
> list ports 'lan2'
>
> config interface 'home'
> option device 'lan'
> option proto 'static'
A bit off-topic: the disparency between config section names and an option
named name is not always clear.
>
> Signed-off-by: Rafał Miłecki
> ---
> config.c| 21 +
> interface.c | 22 +++---
> interface.h | 2 +-
> 3 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/config.c b/config.c
> index 1f4560f..b461b20 100644
> --- a/config.c
> +++ b/config.c
> @@ -148,6 +148,25 @@ config_parse_bridge_interface(struct uci_section *s,
> struct device_type *devtype
> return 0;
> }
>
> +/**
> + * config_fixup_interface_device - translate deprecated "ifname" option
> + *
> + * Initially "interface" sections were using "ifname" for specifying device.
> + * That has been replaced by the "device" option. For backward compatibility
> + * translate it.
> + */
> +static void config_fixup_interface_device(struct uci_section *s)
> +{
> + const char *ifname;
> +
> + if (uci_lookup_option(uci_ctx, s, "device"))
> + return;
> +
> + ifname = uci_lookup_option_string(uci_ctx, s, "ifname");
> + if (ifname)
> + config_fixup_bridge_var(s, "device", ifname);
> +}
> +
> static void
> config_parse_interface(struct uci_section *s, bool alias)
> {
> @@ -161,6 +180,8 @@ config_parse_interface(struct uci_section *s, bool alias)
> if (disabled && !strcmp(disabled, "1"))
> return;
>
> + config_fixup_interface_device(s);
> +
> blob_buf_init(, 0);
>
> if (!alias)
> diff --git a/interface.c b/interface.c
> index ccae915..95f3391 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -30,7 +30,7 @@ struct vlist_tree interfaces;
> static LIST_HEAD(iface_all_users);
>
> enum {
> - IFACE_ATTR_IFNAME,
> + IFACE_ATTR_DEVICE,
> IFACE_ATTR_PROTO,
> IFACE_ATTR_AUTO,
> IFACE_ATTR_JAIL,
> @@ -55,8 +55,8 @@ enum {
> };
>
> static const struct blobmsg_policy iface_attrs[IFACE_ATTR_MAX] = {
> + [IFACE_ATTR_DEVICE] = { .name = "device", .type = BLOBMSG_TYPE_STRING },
> [IFACE_ATTR_PROTO] = { .name = "proto", .type = BLOBMSG_TYPE_STRING },
> - [IFACE_ATTR_IFNAME] = { .name = "ifname", .type = BLOBMSG_TYPE_STRING },
> [IFACE_ATTR_AUTO] = { .name = "auto", .type = BLOBMSG_TYPE_BOOL },
> [IFACE_ATTR_JAIL] = { .name = "jail", .type = BLOBMSG_TYPE_STRING },
> [IFACE_ATTR_JAIL_IFNAME] = { .name = "jail_ifname", .type =
> BLOBMSG_TYPE_STRING },
> @@ -629,9 +629,9 @@ interface_claim_device(struct interface *iface)
> parent = vlist_find(, iface->parent_ifname, parent,
> node);
> iface->parent_iface.cb = interface_alias_cb;
> interface_add_user(>parent_iface, parent);
> - } else if (iface->ifname &&
> + } else if (iface->device &&
> !(iface->proto_handler->flags & PROTO_FLAG_NODEV)) {
> - dev = device_get(iface->ifname, true);
> + dev = device_get(iface->device, true);
> interface_set_device_config(iface, dev);
> } else {
> dev = iface->ext_dev.dev;
> @@ -927,8 +927,8 @@ static bool __interface_add(struct interface *iface,
> struct blob_attr *config, b
> if (!iface->parent_ifname)
> return false;
> } else {
> - if ((cur = tb[IFACE_ATTR_IFNAME]))
> - iface->ifname = blobmsg_data(cur);
> + if ((cur = tb[IFACE_ATTR_DEVICE]))
> + iface->device = blobmsg_data(cur);
> }
>
> if (iface->dynamic) {
> @@ -1204,7 +1204,7 @@ interface_start_jail(const char *jail, const pid_t
> netns_pid)
>* list, so we can mess with it :)
>*/
> if (iface->jail_ifname)
> - iface->ifname = iface->jail_ifname;
> + iface->device = iface->jail_ifname;
>
> interface_do_reload(iface);
> interface_set_up(iface);
> @@ -1245,9 +1245,9 @@ interface_stop_jail(const char *jail, const pid_t
> netns_pid)
> if (!iface->jail || strcmp(iface->jail, jail))
> continue;
>
> - orig_ifname = iface->ifname;
> + orig_ifname =
Re: [PATCH netifd] interface: rename "ifname" attribute to "device"
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 ---
Op 17 mei 2021, om 16:49 heeft Rafał Miłecki het volgende
geschreven:
>
> From: Rafał Miłecki
>
> Interfaces need to be assigned to devices. For that purpose a "device"
> option should be more accurate than "ifname" one.
>
> For backward compatibility add a temporary config translation.
>
> Config example:
>
> config device
> option name 'lan'
> option type 'bridge'
> list ports 'lan1'
> list ports 'lan2'
>
> config interface 'home'
> option device 'lan'
> option proto 'static'
A bit off-topic: the disparency between config section names and an option
named name is not always clear.
>
> Signed-off-by: Rafał Miłecki
> ---
> config.c| 21 +
> interface.c | 22 +++---
> interface.h | 2 +-
> 3 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/config.c b/config.c
> index 1f4560f..b461b20 100644
> --- a/config.c
> +++ b/config.c
> @@ -148,6 +148,25 @@ config_parse_bridge_interface(struct uci_section *s,
> struct device_type *devtype
> return 0;
> }
>
> +/**
> + * config_fixup_interface_device - translate deprecated "ifname" option
> + *
> + * Initially "interface" sections were using "ifname" for specifying device.
> + * That has been replaced by the "device" option. For backward compatibility
> + * translate it.
> + */
> +static void config_fixup_interface_device(struct uci_section *s)
> +{
> + const char *ifname;
> +
> + if (uci_lookup_option(uci_ctx, s, "device"))
> + return;
> +
> + ifname = uci_lookup_option_string(uci_ctx, s, "ifname");
> + if (ifname)
> + config_fixup_bridge_var(s, "device", ifname);
> +}
> +
> static void
> config_parse_interface(struct uci_section *s, bool alias)
> {
> @@ -161,6 +180,8 @@ config_parse_interface(struct uci_section *s, bool alias)
> if (disabled && !strcmp(disabled, "1"))
> return;
>
> + config_fixup_interface_device(s);
> +
> blob_buf_init(, 0);
>
> if (!alias)
> diff --git a/interface.c b/interface.c
> index ccae915..95f3391 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -30,7 +30,7 @@ struct vlist_tree interfaces;
> static LIST_HEAD(iface_all_users);
>
> enum {
> - IFACE_ATTR_IFNAME,
> + IFACE_ATTR_DEVICE,
> IFACE_ATTR_PROTO,
> IFACE_ATTR_AUTO,
> IFACE_ATTR_JAIL,
> @@ -55,8 +55,8 @@ enum {
> };
>
> static const struct blobmsg_policy iface_attrs[IFACE_ATTR_MAX] = {
> + [IFACE_ATTR_DEVICE] = { .name = "device", .type = BLOBMSG_TYPE_STRING },
> [IFACE_ATTR_PROTO] = { .name = "proto", .type = BLOBMSG_TYPE_STRING },
> - [IFACE_ATTR_IFNAME] = { .name = "ifname", .type = BLOBMSG_TYPE_STRING },
> [IFACE_ATTR_AUTO] = { .name = "auto", .type = BLOBMSG_TYPE_BOOL },
> [IFACE_ATTR_JAIL] = { .name = "jail", .type = BLOBMSG_TYPE_STRING },
> [IFACE_ATTR_JAIL_IFNAME] = { .name = "jail_ifname", .type =
> BLOBMSG_TYPE_STRING },
> @@ -629,9 +629,9 @@ interface_claim_device(struct interface *iface)
> parent = vlist_find(, iface->parent_ifname, parent,
> node);
> iface->parent_iface.cb = interface_alias_cb;
> interface_add_user(>parent_iface, parent);
> - } else if (iface->ifname &&
> + } else if (iface->device &&
> !(iface->proto_handler->flags & PROTO_FLAG_NODEV)) {
> - dev = device_get(iface->ifname, true);
> + dev = device_get(iface->device, true);
> interface_set_device_config(iface, dev);
> } else {
> dev = iface->ext_dev.dev;
> @@ -927,8 +927,8 @@ static bool __interface_add(struct interface *iface,
> struct blob_attr *config, b
> if (!iface->parent_ifname)
> return false;
> } else {
> - if ((cur = tb[IFACE_ATTR_IFNAME]))
> - iface->ifname = blobmsg_data(cur);
> + if ((cur = tb[IFACE_ATTR_DEVICE]))
> + iface->device = blobmsg_data(cur);
> }
>
> if (iface->dynamic) {
> @@ -1204,7 +1204,7 @@ interface_start_jail(const char *jail, const pid_t
> netns_pid)
>* list, so we can mess with it :)
>*/
> if (iface->jail_ifname)
> - iface->ifname = iface->jail_ifname;
> + iface->device = iface->jail_ifname;
>
> interface_do_reload(iface);
> interface_set_up(iface);
> @@ -1245,9 +1245,9 @@ interface_stop_jail(const char *jail, const pid_t
> netns_pid)
> if (!iface->jail || strcmp(iface->jail, jail))
> continue;
>
> - orig_ifname = iface->ifname;
> + orig_ifname =
Re: [PATCH netifd] bridge: rename "ifname" attribute to "ports"
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 ---
Good morning !
Thanks for trying to improve on the model set in the netifd UCI, but ...
Regards, Paul
Op 14 mei 2021, om 15:27 heeft Rafał Miłecki het volgende
geschreven:
>
> From: Rafał Miłecki
>
> Bridge aggregates multiple ports so use a more accurate name ("ports").
Confusing that a logical network "interface" references something physical like
a "port".
One would expect that at least a level is modelled in between and that a bridge
in a "interface" config section can bridge several devices (like plain
devices/L2 bridges/VLANs/tunnel devices/...).
Assuming I fail to understand the model, what am I missing ?
> For backward compatibility add a temporary config translation.
>
> Config example:
>
> config interface 'lan'
>option type 'bridge'
>list ports 'lan1'
>list ports 'lan2'
>
> Signed-off-by: Rafał Miłecki
> ---
> bridge.c | 16
> config.c | 23 ++-
> 2 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/bridge.c b/bridge.c
> index 099dfe4..a1f3992 100644
> --- a/bridge.c
> +++ b/bridge.c
> @@ -23,7 +23,7 @@
> #include "system.h"
>
> enum {
> - BRIDGE_ATTR_IFNAME,
> + BRIDGE_ATTR_PORTS,
> BRIDGE_ATTR_STP,
> BRIDGE_ATTR_FORWARD_DELAY,
> BRIDGE_ATTR_PRIORITY,
> @@ -44,7 +44,7 @@ enum {
> };
>
> static const struct blobmsg_policy bridge_attrs[__BRIDGE_ATTR_MAX] = {
> - [BRIDGE_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_ARRAY },
> + [BRIDGE_ATTR_PORTS] = { "ports", BLOBMSG_TYPE_ARRAY },
> [BRIDGE_ATTR_STP] = { "stp", BLOBMSG_TYPE_BOOL },
> [BRIDGE_ATTR_FORWARD_DELAY] = { "forward_delay", BLOBMSG_TYPE_INT32 },
> [BRIDGE_ATTR_PRIORITY] = { "priority", BLOBMSG_TYPE_INT32 },
> @@ -64,7 +64,7 @@ static const struct blobmsg_policy
> bridge_attrs[__BRIDGE_ATTR_MAX] = {
> };
>
> static const struct uci_blob_param_info bridge_attr_info[__BRIDGE_ATTR_MAX] =
> {
> - [BRIDGE_ATTR_IFNAME] = { .type = BLOBMSG_TYPE_STRING },
> + [BRIDGE_ATTR_PORTS] = { .type = BLOBMSG_TYPE_STRING },
> };
>
> static const struct uci_blob_param_list bridge_attr_list = {
> @@ -104,7 +104,7 @@ struct bridge_state {
>
> struct blob_attr *config_data;
> struct bridge_config config;
> - struct blob_attr *ifnames;
> + struct blob_attr *ports;
> bool active;
> bool force_active;
> bool has_vlans;
> @@ -853,8 +853,8 @@ bridge_config_init(struct device *dev)
>
> bst->n_failed = 0;
> vlist_update(>members);
> - if (bst->ifnames) {
> - blobmsg_for_each_attr(cur, bst->ifnames, rem) {
> + if (bst->ports) {
> + blobmsg_for_each_attr(cur, bst->ports, rem) {
> bridge_add_member(bst, blobmsg_data(cur));
> }
> }
> @@ -970,7 +970,7 @@ bridge_reload(struct device *dev, struct blob_attr *attr)
> if (tb_dev[DEV_ATTR_MACADDR])
> bst->primary_port = NULL;
>
> - bst->ifnames = tb_br[BRIDGE_ATTR_IFNAME];
> + bst->ports = tb_br[BRIDGE_ATTR_PORTS];
> device_init_settings(dev, tb_dev);
> bridge_apply_settings(bst, tb_br);
>
> @@ -991,7 +991,7 @@ bridge_reload(struct device *dev, struct blob_attr *attr)
>
> diff = 0;
> uci_blob_diff(tb_br, otb_br, _attr_list, );
> - if (diff & ~(1 << BRIDGE_ATTR_IFNAME))
> + if (diff & ~(1 << BRIDGE_ATTR_PORTS))
> ret = DEV_CONFIG_RESTART;
>
> bridge_config_init(dev);
> diff --git a/config.c b/config.c
> index fa7cbe4..1f4560f 100644
> --- a/config.c
> +++ b/config.c
> @@ -95,6 +95,24 @@ config_fixup_bridge_var(struct uci_section *s, const char
> *name, const char *val
> uci_set(uci_ctx, );
> }
>
> +/**
> + * config_fixup_bridge_ports - translate deprecated configs
> + *
> + * Old configs used "ifname" option for specifying bridge ports. For backward
> + * compatibility translate it into the new "ports" option.
> + */
> +static void config_fixup_bridge_ports(struct uci_section *s)
> +{
> + const char *ifname;
> +
> + if (uci_lookup_option(uci_ctx, s, "ports"))
> + return;
> +
> + ifname = uci_lookup_option_string(uci_ctx, s, "ifname");
> + if (ifname)
> + config_fixup_bridge_var(s, "ports", ifname);
> +}
> +
> static void
> config_fixup_bridge_vlan_filtering(struct uci_section *s, const char *name)
> {
> @@ -117,6 +135,7 @@ config_parse_bridge_interface(struct uci_section *s,
> struct device_type *devtype
> sprintf(name, "%s-%s", devtype->name_prefix, s->e.name);
> blobmsg_add_string(, "name", name);
>
> + config_fixup_bridge_ports(s);
> config_fixup_bridge_vlan_filtering(s, name);
> uci_to_blob(,
Re: [PATCH netifd] bridge: rename "ifname" attribute to "ports"
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 ---
Good morning !
Thanks for trying to improve on the model set in the netifd UCI, but ...
Regards, Paul
Op 14 mei 2021, om 15:27 heeft Rafał Miłecki het volgende
geschreven:
>
> From: Rafał Miłecki
>
> Bridge aggregates multiple ports so use a more accurate name ("ports").
Confusing that a logical network "interface" references something physical like
a "port".
One would expect that at least a level is modelled in between and that a bridge
in a "interface" config section can bridge several devices (like plain
devices/L2 bridges/VLANs/tunnel devices/...).
Assuming I fail to understand the model, what am I missing ?
> For backward compatibility add a temporary config translation.
>
> Config example:
>
> config interface 'lan'
>option type 'bridge'
>list ports 'lan1'
>list ports 'lan2'
>
> Signed-off-by: Rafał Miłecki
> ---
> bridge.c | 16
> config.c | 23 ++-
> 2 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/bridge.c b/bridge.c
> index 099dfe4..a1f3992 100644
> --- a/bridge.c
> +++ b/bridge.c
> @@ -23,7 +23,7 @@
> #include "system.h"
>
> enum {
> - BRIDGE_ATTR_IFNAME,
> + BRIDGE_ATTR_PORTS,
> BRIDGE_ATTR_STP,
> BRIDGE_ATTR_FORWARD_DELAY,
> BRIDGE_ATTR_PRIORITY,
> @@ -44,7 +44,7 @@ enum {
> };
>
> static const struct blobmsg_policy bridge_attrs[__BRIDGE_ATTR_MAX] = {
> - [BRIDGE_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_ARRAY },
> + [BRIDGE_ATTR_PORTS] = { "ports", BLOBMSG_TYPE_ARRAY },
> [BRIDGE_ATTR_STP] = { "stp", BLOBMSG_TYPE_BOOL },
> [BRIDGE_ATTR_FORWARD_DELAY] = { "forward_delay", BLOBMSG_TYPE_INT32 },
> [BRIDGE_ATTR_PRIORITY] = { "priority", BLOBMSG_TYPE_INT32 },
> @@ -64,7 +64,7 @@ static const struct blobmsg_policy
> bridge_attrs[__BRIDGE_ATTR_MAX] = {
> };
>
> static const struct uci_blob_param_info bridge_attr_info[__BRIDGE_ATTR_MAX] =
> {
> - [BRIDGE_ATTR_IFNAME] = { .type = BLOBMSG_TYPE_STRING },
> + [BRIDGE_ATTR_PORTS] = { .type = BLOBMSG_TYPE_STRING },
> };
>
> static const struct uci_blob_param_list bridge_attr_list = {
> @@ -104,7 +104,7 @@ struct bridge_state {
>
> struct blob_attr *config_data;
> struct bridge_config config;
> - struct blob_attr *ifnames;
> + struct blob_attr *ports;
> bool active;
> bool force_active;
> bool has_vlans;
> @@ -853,8 +853,8 @@ bridge_config_init(struct device *dev)
>
> bst->n_failed = 0;
> vlist_update(>members);
> - if (bst->ifnames) {
> - blobmsg_for_each_attr(cur, bst->ifnames, rem) {
> + if (bst->ports) {
> + blobmsg_for_each_attr(cur, bst->ports, rem) {
> bridge_add_member(bst, blobmsg_data(cur));
> }
> }
> @@ -970,7 +970,7 @@ bridge_reload(struct device *dev, struct blob_attr *attr)
> if (tb_dev[DEV_ATTR_MACADDR])
> bst->primary_port = NULL;
>
> - bst->ifnames = tb_br[BRIDGE_ATTR_IFNAME];
> + bst->ports = tb_br[BRIDGE_ATTR_PORTS];
> device_init_settings(dev, tb_dev);
> bridge_apply_settings(bst, tb_br);
>
> @@ -991,7 +991,7 @@ bridge_reload(struct device *dev, struct blob_attr *attr)
>
> diff = 0;
> uci_blob_diff(tb_br, otb_br, _attr_list, );
> - if (diff & ~(1 << BRIDGE_ATTR_IFNAME))
> + if (diff & ~(1 << BRIDGE_ATTR_PORTS))
> ret = DEV_CONFIG_RESTART;
>
> bridge_config_init(dev);
> diff --git a/config.c b/config.c
> index fa7cbe4..1f4560f 100644
> --- a/config.c
> +++ b/config.c
> @@ -95,6 +95,24 @@ config_fixup_bridge_var(struct uci_section *s, const char
> *name, const char *val
> uci_set(uci_ctx, );
> }
>
> +/**
> + * config_fixup_bridge_ports - translate deprecated configs
> + *
> + * Old configs used "ifname" option for specifying bridge ports. For backward
> + * compatibility translate it into the new "ports" option.
> + */
> +static void config_fixup_bridge_ports(struct uci_section *s)
> +{
> + const char *ifname;
> +
> + if (uci_lookup_option(uci_ctx, s, "ports"))
> + return;
> +
> + ifname = uci_lookup_option_string(uci_ctx, s, "ifname");
> + if (ifname)
> + config_fixup_bridge_var(s, "ports", ifname);
> +}
> +
> static void
> config_fixup_bridge_vlan_filtering(struct uci_section *s, const char *name)
> {
> @@ -117,6 +135,7 @@ config_parse_bridge_interface(struct uci_section *s,
> struct device_type *devtype
> sprintf(name, "%s-%s", devtype->name_prefix, s->e.name);
> blobmsg_add_string(, "name", name);
>
> + config_fixup_bridge_ports(s);
> config_fixup_bridge_vlan_filtering(s, name);
> uci_to_blob(,
Re: [PATCH] fortify-headers: fix compilation with GCC 10.3
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 ---
> Op 13 apr. 2021, om 06:03 heeft Rosen Penev het volgende
> geschreven:
>
> For some reason, fortified mempcpy does not work with GCC 10.3. It
> worked with GCC 10.2.
>
> Some output with tvheadend:
>
> error: 'mempcpy' undeclared here (not in a function);
> did you mean 'memccpy'?
> 144 | _FORTIFY_FN(mempcpy) void *mempcpy(void *__d,
> const void *__s, size_t __n)
>| ^~~
> note: in definition of macro '_FORTIFY_ORIG'
> 20 | #define _FORTIFY_ORIG(p,fn)
> __typeof__(fn) __orig_##fn __asm__(_FORTIFY_STR(p) #fn)
> note: in expansion of macro
> '_FORTIFY_FN'
> 144 | _FORTIFY_FN(mempcpy) void
> *mempcpy(void *__d, const void *__s, size_t __n)
> In function 'mempcpy':
> error: called object '__orig_mempcpy' is not a
> function or function pointer
> 151 | return _orig_mempcpy(__d, __s, __n);
>
> Signed-off-by: Rosen Penev
> ---
> toolchain/fortify-headers/Makefile | 2 +-
> toolchain/fortify-headers/patches/010-mempcpy.patch | 11 +++
> 2 files changed, 12 insertions(+), 1 deletion(-)
> create mode 100644 toolchain/fortify-headers/patches/010-mempcpy.patch
>
> diff --git a/toolchain/fortify-headers/Makefile
> b/toolchain/fortify-headers/Makefile
> index a6151bb2f1..bb67c33c30 100644
> --- a/toolchain/fortify-headers/Makefile
> +++ b/toolchain/fortify-headers/Makefile
> @@ -9,7 +9,7 @@ include $(INCLUDE_DIR)/target.mk
>
> PKG_NAME:=fortify-headers
> PKG_VERSION:=1.1
> -PKG_RELEASE=1
> +PKG_RELEASE=2
>
> PKG_SOURCE_URL:=http://dl.2f30.org/releases
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> diff --git a/toolchain/fortify-headers/patches/010-mempcpy.patch
> b/toolchain/fortify-headers/patches/010-mempcpy.patch
> new file mode 100644
> index 00..8423395da5
> --- /dev/null
> +++ b/toolchain/fortify-headers/patches/010-mempcpy.patch
> @@ -0,0 +1,11 @@
> +--- a/include/string.h
> b/include/string.h
> +@@ -139,7 +139,7 @@ _FORTIFY_FN(strncpy) char *strncpy(char
> + return __orig_strncpy(__d, __s, __n);
> + }
> +
> +-#ifdef _GNU_SOURCE
> ++#if 0
This seems more like partly disabling code that poses problems then fixing it,
a work-around.
Since the code code concerned deals with code security, I would NACK it.
> + #undef mempcpy
> + _FORTIFY_FN(mempcpy) void *mempcpy(void *__d, const void *__s, size_t __n)
> + {
> --
> 2.30.2
>
>
> ___
> 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
Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard
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 --- Op 18 feb. 2021, om 18:48 heeft Ilya Lipnitskiy het volgende geschreven: > > Hi, > > On Thu, Feb 18, 2021 at 9:21 AM Adrian Schmutzler > wrote: >> I don't really get the point of this justification. Either wireguard-tools >> depends on kmod-wireguard, or it doesn't. In the first case, and only then, >> it should be "fixed" (with a proper justification describing that). > Are wireguard-tools useful without the underlying kernel module? It > didn't seem like it to me, although maybe Jason should chime in here, > as maintainer and developer of Wireguard. The wg command also offers functions for private/public key generation and such which don't need the kernel module. Bye, Paul --- End Message --- ___ 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 --- Op 5 feb. 2021, om 00:59 heeft Paul Spooren het volgende geschreven: > > The script improves readability by using an automatic code formatter. The decreases of the switch case indentation levels make sense, but IMHO the removals of the space between redirection and source (e.g. --- End Message --- ___ 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 --- > Op 27 jan. 2021, om 01:12 heeft Philip Prindeville > het volgende geschreven: > > > >> On Jan 26, 2021, at 2:09 PM, Paul Oranje wrote: >> >> >> >>> Op 22 jan. 2021, om 20:03 heeft Daniel Golle het >>> volgende geschreven: >>> >>> Hi Philip, >>> >>> On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote: Hi, Is anyone interested in adding a page to the openwrt.org site about developers willing to do commercial work? It could be as simple as: * name * email address * mobile (if wanted) * packages/platforms/architectures you maintain or have competence in * whether you're available full-time, part-time, or currently unavailable Might be useful for matching up devs with work. >>> >>> While I like the idea and would probably benefit from it myself, I'm >>> a bit sceptical when it comes to making OpenWrt.org an institution >>> certifying developers. Too much trouble was caused over having >>> '@openwrt.org' addresses and I doubt we are able to handle the >>> moderation needs (think: classic fraud, fishing, ...) of such a thing >>> if it is even a wiki, ie. free to edit for all. >>> Things like a wiki with only volunteer moderation somehow work because >>> there is little to no commercial interest in manipulation and it is >>> usually easy to recognize (ie. classic spam). In the moment that we >>> change that, we have to be prepared to also face a different quality >>> of manipulation attempts. >>> >>> Just my 2 cents... >> Indeed, having a job board would be like opening a can of worms. Don't do it. >> Paul > > > And an open mailing list? Probably less troublesome, but some moderation will still be needed and with that comes the need for a policy etc. Not against an open ML though. Bye, Paul > > -Philip > > >> >>> Just an idea to help our community prosper. Thanks, -Philip ___ 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 --- End Message --- ___ 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 --- > Op 20 nov. 2020, om 11:44 heeft Petr Štetiar het volgende > geschreven: > > Paul Spooren [2020-11-19 13:09:02]: > > Hi, > >> while 20.xx seems close, > > I don't share your view on this one, 21.xx is close, yes :-) Just being > realistic here. So I would say, that if this issue should be tackled, there is > still some time left to do so. > >> I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per >> default. > > Do we need to make this hard decission? Can't we leave it to the end users? > We need most of the SSL stuff for other parts, so why not benefit from that in > other parts? > > For the start, can't we simply introduce some first time welcome page on HTTP, > explain to the user, that HTTPS is available, the pros and cons of this > solution and let the user decide? > > In less intrusive way, this welcome page/wizard could be replaced with some > information box "HTTPS is just a moments away", so the user would need to > explicitly request that HTTPS feature. > > There might be some better UX approach, but please try hard to move forward, > not backward :-) right, so +1 > > -- ynezz > > ___ > 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
[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 --- > Op 20 nov. 2020, om 03:24 heeft ansuels...@gmail.com het volgende geschreven: > >> Given that the first login via LuCI, on a fresh install, is not with a >> password anyway. What if setting the initial password sets up >> letsencrypt also. Then when letsencrypt's first successful cert install, >> https gets enabled as the default and then requests the user reboot to >> complete the setup and will force their next session to https. >> >> I agree that https with self-signed certs are not good, especially on a >> first boot/install device. >> > > My 2 cents, I still think that have a properly verified cert is madness. > I really think that to address this the best way would be to add a big > And very explicative alert to the first login page. > The process would be > 1. First boot --> First login (no password set) Append to the already > present alert about password-less system, an alert about self signed > cert and that the browser will tell that the router page will not be secure. > (again this must be very explicative and easy to understand) > 2. As soon as the user set a password, the webserver is restarted with > http disabled/redirected and https now enabled. The user should now > know that the page is secure and that he can whitelist/allowlist(for the > inclusive people :D) it. > > This way the user won't be scared of unsecure page and can understand > why the page is secure. Also if we want to push security to an upper level > with self signed cert, we can ask the user to insert some data so that the > self signed cert can be generated based on that and actually validated by > the user (to prevent any MIT attack) +1 The only conceivable way to proceed from a first start where security only exists in that the first run is in an environment not exposed to the evil world towards being exposed and prepared. That without having to rely on previously established (secure) DNS combined with DANE (and a webbrowser that does support DANE, currently not one mayor does) or a valid certificate which does not fit the use-case at hand. > >> Cheers >> Derek >> >> On 11/19/20 6:09 PM, Paul Spooren wrote: >>> Hi, >>> >>> The current list of release goals for 20.xx states[0] that LuCI should >>> use HTTPS per default. This works by creating on-device a self-signed >>> certificate. Self-signed certificates result in warnings and may cause >>> more harm than good, multiple discussion are found in the mail archive. >>> >>> As no clean solution seems in reach while 20.xx seems close, I'd like to >>> suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. >>> >>> This isn't a vote but a request for developer/user opinions. >>> >>> Sunshine, >>> Paul >>> >>> [0]: https://openwrt.org/docs/guide-developer/releases/goals/20.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 --- End Message --- ___ 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 --- Op 14 nov. 2020, om 12:14 heeft Jo-Philipp Wich het volgende geschreven: > > Hi, > >> Are there any real blockers left? > > LuCI support for bridge-vlan config is unmerged/unpolished yet. > > I'd rather not ship 20.x without functioning switch config support in > the ui. Which platforms still have to make the switch to DSA in master ? > > ~ Jo > > ___ > 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
