Re: HTTPS performance issue with opkg (Was: [PATCH 3/3] build: switch VERSION_REPO to HTTPS)

2020-09-15 Thread Paul Spooren
On Mon Sep 14, 2020 at 10:23 PM HST, Daniel Golle wrote:
> On Tue, Sep 15, 2020 at 08:49:51AM +0200, Baptiste Jonglez wrote:
> > On 27-08-20, Paul Spooren wrote:
> > > The variable VERSION_REPO is used by opkg to download package(list)s.
> > > Now that the default installation support encrypted HTTP opkg should
> > > make use of it.
> > 
> > I wonder what is the performance impact of this?  Opkg forks a new wget
> > process to download each package, so the HTTPS connection is never reused.
> > 
> > Running a simple "time make image
> > PROFILE=mikrotik_routerboard-921gs-5hpacd-15s" with the ath79/mikrotik
> > imagebuilder results in a 50% increase of running time:
> > 
> > - with HTTPS: 32 seconds
> > - with HTTP: 22 seconds
> > 
> > (timing for the second run is shown, and dl/ is cleaned up before each run)
> > 
> > The overhead might be even more significant on a device, and the download
> > server probably sees more load from the large number of key exchange.
> > Anybody got any figures?
> > 
> > With HTTPS, opkg would really need connection reuse.  I don't think the
> > current situation is acceptable for a stable release, if only to avoid
> > high load on the download server.
>
> I suggest to revert that change as HTTPS doesn't do us a favour here.
> It prevents Web-Caches (squid and such), hurts performance and
> integrity should (at least now) anyway be ensured by SHA256 of the
> package contained in the ed25519 signed package list.
> In my opinion HTTPS even gives users a false sense of security, as it
> is up to a few hundred certification authorities to not compromise
> rather than just to a few keys shipped with OpenWrt.
> Plus the the complexity of the handshake, large choice of ciphers
> (rather than pinning SHA256 + ed25519), ...
> Even major distributions like Debian and ArchLinux make HTTPS optional
> and opt-in for their package download servers.
> Imho the disadvantages clearly outweight the benifits here.

I see some advantage in not sharing what packages (incl. versions) are
installed in images or running machines, however that maybe doesn't
outweighs the issues stated above.

Removing HTTPS right now means insecure package installations in
ImageBuilder created images, I suggest to avoid that.

Enabling signature checks right now in ImageBuilder doesn't work because
the local folder packages/ contains kmods, kernel and libc which are
required for image creation. This folder is dynamically put together on
ImageBuilder creation and the index is created during ImageBuilder
runtime locally, meaning no signatures are available.

My initial idea (mocked in a very poor patch) was to disable signature
checking for the special case "file:packages". Given a second thought a
per feed option could be used for those special cases, like
"src/trusted" instead of "src". Adding signature check exceptions is
however bad, therefore I'd like to suggest a third solution:

Instead of shipping the ImageBuilder with the packages/ folder
(containing kmods etc.) another (signed) feed should be added to the
ImageBuilders repositories.conf, similar to what's already added to
snapshot images:

src/gz openwrt_kmods 
http://downloads.openwrt.org/snapshots/targets/armvirt/64/kmods/5.4.65-1-397bac86dd45c4d97d5f09fd9def9671/

This folder contains all available kmods. The special packages `kernel`
and `libc` should be added there, which requires a little buildbot
patch.

Instead of installing the local available kernel_*.ipk[1] the kernel and
libc revision could be hardcoded, something which is already done for
e.g. the revision[2] in ImageBuilder and SDK.

In combination this allows smaller ImageBuilders only using remote
packages which are all signed.

When choosing to have a standalone ImageBuilder with all packages
available locally (CONFIG_IB_STANDALONE) then all feeds except the
packages/ folder are disabled, meaning the `option check_signature` can
be disabled independently of `CONFIG_SIGNED_PACKAGES`.

If this seems a feasible approach I'd submit the patches for Buildbot
and ImageBuilder.

[1]: 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/imagebuilder/files/Makefile;h=27d3cfa8dfd5e5b7de0465db2ebff277e2040a14;hb=HEAD#l156
[2]: 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/imagebuilder/Makefile;h=ad19ab2b53ffd08d91ffb86817e54fdb31279660;hb=HEAD#l79


>
>
> > 
> > Baptiste
> > 
> > > Suggested-by: Petr Štetiar 
> > > Suggested-by: Baptiste Jonglez 
> > > Signed-off-by: Paul Spooren 
> > > ---
> > >  include/version.mk | 2 +-
> > >  package/base-files/image-config.in | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/version.mk b/include/version.mk
> > > index 7d3c1ad640..b7f42e13bb 100644
> > > --- a/include/version.mk
> > > +++ b/include/version.mk
> > > @@ -32,7 +32,7 @@ VERSION_CODE:=$(call qstrip,$(CONFIG_VERSION_CODE))
> > >  VERSION_CODE:=$(if $(VERSION_CODE),$(VERSION_CODE),$(REVISION))
> > >  
> > >  

[PATCH PROOF luci] luci-base: switch to the new ubus API

2020-09-15 Thread Rafał Miłecki
From: Rafał Miłecki 

This is proof of concept for the new uhttpd ubus API. It switches LuCI
(in a bit hacky way) to the new API.

Signed-off-by: Rafał Miłecki 
---
 .../htdocs/luci-static/resources/luci.js  |  5 +++
 .../htdocs/luci-static/resources/rpc.js   | 31 +--
 2 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/modules/luci-base/htdocs/luci-static/resources/luci.js 
b/modules/luci-base/htdocs/luci-static/resources/luci.js
index e285f999e..9d2c52d77 100644
--- a/modules/luci-base/htdocs/luci-static/resources/luci.js
+++ b/modules/luci-base/htdocs/luci-static/resources/luci.js
@@ -739,11 +739,13 @@
if (!opt.cache)
opt.url += ((/\?/).test(opt.url) ? '&' 
: '?') + (new Date()).getTime();
 
+/*
if (isQueueableRequest(opt)) {
requestQueue.push([opt, rejectFn, 
resolveFn]);

requestAnimationFrame(flushRequestQueue);
return;
}
+*/
 
if ('username' in opt && 'password' in opt)
opt.xhr.open(opt.method, opt.url, true, 
opt.username, opt.password);
@@ -758,6 +760,9 @@
if ('timeout' in opt)
opt.xhr.timeout = +opt.timeout;
 
+   if ('authorization' in opt)
+   
opt.xhr.setRequestHeader('Authorization', 'Bearer 
%s'.format(opt.authorization));
+
if ('credentials' in opt)
opt.xhr.withCredentials = 
!!opt.credentials;
 
diff --git a/modules/luci-base/htdocs/luci-static/resources/rpc.js 
b/modules/luci-base/htdocs/luci-static/resources/rpc.js
index 7bfc91336..5d9569d87 100644
--- a/modules/luci-base/htdocs/luci-static/resources/rpc.js
+++ b/modules/luci-base/htdocs/luci-static/resources/rpc.js
@@ -18,8 +18,8 @@ var rpcRequestID = 1,
  */
 return baseclass.extend(/** @lends LuCI.rpc.prototype */ {
/* privates */
-   call: function(req, cb, nobatch) {
-   var q = '';
+   call: function(object, req, cb) {
+   var q = 'call/%s'.format(object);
 
if (Array.isArray(req)) {
if (req.length == 0)
@@ -33,13 +33,10 @@ return baseclass.extend(/** @lends LuCI.rpc.prototype */ {
req[i].params[2]
);
}
-   else if (req.params) {
-   q += '/%s.%s'.format(req.params[1], req.params[2]);
-   }
 
return request.post(rpcBaseURL + q, req, {
timeout: (L.env.rpctimeout || 20) * 1000,
-   nobatch: nobatch,
+   authorization: rpcSessionID,
credentials: true
}).then(cb, cb);
},
@@ -89,16 +86,7 @@ return baseclass.extend(/** @lends LuCI.rpc.prototype */ {
return req.reject(e);
}
 
-   if (!req.object && !req.method) {
-   ret = msg.result;
-   }
-   else if (Array.isArray(msg.result)) {
-   if (req.raise && msg.result[0] !== 0)
-   L.raise('RPCError', 'RPC call to %s/%s failed 
with ubus code %d: %s',
-   req.object, req.method, msg.result[0], 
this.getStatusText(msg.result[0]));
-
-   ret = (msg.result.length > 1) ? msg.result[1] : 
msg.result[0];
-   }
+   ret = msg.result;
 
if (req.expect) {
for (var key in req.expect) {
@@ -332,17 +320,12 @@ return baseclass.extend(/** @lends LuCI.rpc.prototype */ {
var msg = {
jsonrpc: '2.0',
id:  rpcRequestID++,
-   method:  'call',
-   params:  [
-   rpcSessionID,
-   options.object,
-   options.method,
-   params
-   ]
+   method:  options.method,
+   params:  params
};
 
/* call rpc */
-   rpc.call(msg, rpc.parseCallReply.bind(rpc, 
req), options.nobatch);
+   rpc.call(options.object, msg, 
rpc.parseCallReply.bind(rpc, req));

Re: [PATCH luci] luci-base: use actual JSON-RPC for verifying ubus RPC URL

2020-09-15 Thread Rafał Miłecki

On 14.09.2020 18:31, Rafał Miłecki wrote:

@@ -2553,10 +2553,19 @@
rpcBaseURL = Session.getLocalData('rpcBaseURL');
  
  			if (rpcBaseURL == null) {

+   var msg = {
+   jsonrpc: '2.0',
+   id:  'init',
+   method:  'list',
+   params:  undefined
+   };
+   var options = {
+   nobatch: true
+   };
var rpcFallbackURL = this.url('admin/ubus');
  
-rpcBaseURL = Request.get(env.ubuspath).then(function(res) {

-   return (rpcBaseURL = (res.status == 
400) ? env.ubuspath : rpcFallbackURL);
+   rpcBaseURL = Request.post(env.ubuspath, msg, 
options).then(function(res) {
+   return (rpcBaseURL = res.status == 200 
? env.ubuspath : rpcFallbackURL);


Pushing with "options" variable object inlined.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


HTTPS performance issue with opkg (Was: [PATCH 3/3] build: switch VERSION_REPO to HTTPS)

2020-09-15 Thread Baptiste Jonglez
On 27-08-20, Paul Spooren wrote:
> The variable VERSION_REPO is used by opkg to download package(list)s.
> Now that the default installation support encrypted HTTP opkg should
> make use of it.

I wonder what is the performance impact of this?  Opkg forks a new wget
process to download each package, so the HTTPS connection is never reused.

Running a simple "time make image
PROFILE=mikrotik_routerboard-921gs-5hpacd-15s" with the ath79/mikrotik
imagebuilder results in a 50% increase of running time:

- with HTTPS: 32 seconds
- with HTTP: 22 seconds

(timing for the second run is shown, and dl/ is cleaned up before each run)

The overhead might be even more significant on a device, and the download
server probably sees more load from the large number of key exchange.
Anybody got any figures?

With HTTPS, opkg would really need connection reuse.  I don't think the
current situation is acceptable for a stable release, if only to avoid
high load on the download server.

Baptiste

> Suggested-by: Petr Štetiar 
> Suggested-by: Baptiste Jonglez 
> Signed-off-by: Paul Spooren 
> ---
>  include/version.mk | 2 +-
>  package/base-files/image-config.in | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/version.mk b/include/version.mk
> index 7d3c1ad640..b7f42e13bb 100644
> --- a/include/version.mk
> +++ b/include/version.mk
> @@ -32,7 +32,7 @@ VERSION_CODE:=$(call qstrip,$(CONFIG_VERSION_CODE))
>  VERSION_CODE:=$(if $(VERSION_CODE),$(VERSION_CODE),$(REVISION))
>  
>  VERSION_REPO:=$(call qstrip,$(CONFIG_VERSION_REPO))
> -VERSION_REPO:=$(if 
> $(VERSION_REPO),$(VERSION_REPO),http://downloads.openwrt.org/snapshots)
> +VERSION_REPO:=$(if 
> $(VERSION_REPO),$(VERSION_REPO),https://downloads.openwrt.org/snapshots)
>  
>  VERSION_DIST:=$(call qstrip,$(CONFIG_VERSION_DIST))
>  VERSION_DIST:=$(if $(VERSION_DIST),$(VERSION_DIST),OpenWrt)
> diff --git a/package/base-files/image-config.in 
> b/package/base-files/image-config.in
> index 4bace77db0..bfa3055cc8 100644
> --- a/package/base-files/image-config.in
> +++ b/package/base-files/image-config.in
> @@ -183,7 +183,7 @@ if VERSIONOPT
>   config VERSION_REPO
>   string
>   prompt "Release repository"
> - default "http://downloads.openwrt.org/snapshots;
> + default "https://downloads.openwrt.org/snapshots;
>   help
>   This is the repository address embedded in the image, 
> it defaults
>   to the trunk snapshot repo; the url may contain the 
> following placeholders:


signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: HTTPS performance issue with opkg (Was: [PATCH 3/3] build: switch VERSION_REPO to HTTPS)

2020-09-15 Thread Daniel Golle
On Tue, Sep 15, 2020 at 08:49:51AM +0200, Baptiste Jonglez wrote:
> On 27-08-20, Paul Spooren wrote:
> > The variable VERSION_REPO is used by opkg to download package(list)s.
> > Now that the default installation support encrypted HTTP opkg should
> > make use of it.
> 
> I wonder what is the performance impact of this?  Opkg forks a new wget
> process to download each package, so the HTTPS connection is never reused.
> 
> Running a simple "time make image
> PROFILE=mikrotik_routerboard-921gs-5hpacd-15s" with the ath79/mikrotik
> imagebuilder results in a 50% increase of running time:
> 
> - with HTTPS: 32 seconds
> - with HTTP: 22 seconds
> 
> (timing for the second run is shown, and dl/ is cleaned up before each run)
> 
> The overhead might be even more significant on a device, and the download
> server probably sees more load from the large number of key exchange.
> Anybody got any figures?
> 
> With HTTPS, opkg would really need connection reuse.  I don't think the
> current situation is acceptable for a stable release, if only to avoid
> high load on the download server.

I suggest to revert that change as HTTPS doesn't do us a favour here.
It prevents Web-Caches (squid and such), hurts performance and
integrity should (at least now) anyway be ensured by SHA256 of the
package contained in the ed25519 signed package list.
In my opinion HTTPS even gives users a false sense of security, as it
is up to a few hundred certification authorities to not compromise
rather than just to a few keys shipped with OpenWrt.
Plus the the complexity of the handshake, large choice of ciphers
(rather than pinning SHA256 + ed25519), ...
Even major distributions like Debian and ArchLinux make HTTPS optional
and opt-in for their package download servers.
Imho the disadvantages clearly outweight the benifits here.


> 
> Baptiste
> 
> > Suggested-by: Petr Štetiar 
> > Suggested-by: Baptiste Jonglez 
> > Signed-off-by: Paul Spooren 
> > ---
> >  include/version.mk | 2 +-
> >  package/base-files/image-config.in | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/version.mk b/include/version.mk
> > index 7d3c1ad640..b7f42e13bb 100644
> > --- a/include/version.mk
> > +++ b/include/version.mk
> > @@ -32,7 +32,7 @@ VERSION_CODE:=$(call qstrip,$(CONFIG_VERSION_CODE))
> >  VERSION_CODE:=$(if $(VERSION_CODE),$(VERSION_CODE),$(REVISION))
> >  
> >  VERSION_REPO:=$(call qstrip,$(CONFIG_VERSION_REPO))
> > -VERSION_REPO:=$(if 
> > $(VERSION_REPO),$(VERSION_REPO),http://downloads.openwrt.org/snapshots)
> > +VERSION_REPO:=$(if 
> > $(VERSION_REPO),$(VERSION_REPO),https://downloads.openwrt.org/snapshots)
> >  
> >  VERSION_DIST:=$(call qstrip,$(CONFIG_VERSION_DIST))
> >  VERSION_DIST:=$(if $(VERSION_DIST),$(VERSION_DIST),OpenWrt)
> > diff --git a/package/base-files/image-config.in 
> > b/package/base-files/image-config.in
> > index 4bace77db0..bfa3055cc8 100644
> > --- a/package/base-files/image-config.in
> > +++ b/package/base-files/image-config.in
> > @@ -183,7 +183,7 @@ if VERSIONOPT
> > config VERSION_REPO
> > string
> > prompt "Release repository"
> > -   default "http://downloads.openwrt.org/snapshots;
> > +   default "https://downloads.openwrt.org/snapshots;
> > help
> > This is the repository address embedded in the image, 
> > it defaults
> > to the trunk snapshot repo; the url may contain the 
> > following placeholders:



> ___
> 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 V3 uhttpd] ubus: add new RESTful API

2020-09-15 Thread Rafał Miłecki

On 14.09.2020 17:15, Rafał Miłecki wrote:

+static void uh_ubus_handle_post(struct client *cl)
+{
+   static const struct blobmsg_policy hdr_policy[__HDR_UBUS_MAX] = {
+   [HDR_AUTHORIZATION] = { "authorization", BLOBMSG_TYPE_STRING },
+   };
+   struct dispatch_ubus *du = >dispatch.ubus;
+   struct blob_attr *tb[__HDR_UBUS_MAX];
+   const char *url = du->url_path;
+   const char *auth;
+
+   if (!strcmp(url, conf.ubus_prefix) ||
+   (url[strlen(url) - 1] == '/' && !strncmp(url, conf.ubus_prefix, 
strlen(url) - 1))) {


I think above may result in false positives for
ubus_prefix: /ubus/
url: /ub/

That should be:
if (ops->path_match(conf.ubus_prefix, url) && strlen(url) - 
strlen(conf.ubus_prefix) <= 1) {

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[no subject]

2020-09-15 Thread Daniel Santos via openwrt-devel
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 ---
Hello Jeffery,

Thank you for the wonderful work on maintaining the Go packages!

I got a little irritated at CGo's restriction of arch flags (in the
immutable GOGCCFLAGS variable) and put together a patch set for v19.07
to override them with an environment variable and then (optionally) feed
the machine flags in the Golang build.  In the OpenWRT repo, I did this
by splitting out how DEFAULT_CFLAGS are put together in order to
populate a DEFAULT_MACHINE_FLAGS, but it could probably be done with
just a $(filter -m%,$(DEFAULT_CFLAGS)) instead.

If you or others have any interest in this, I can clean them up for the
master branch.  I'm probably going to submit the Golang patch upstream,
since I don't see any good reason for such a restriction.  I see you've
made a lot of changes on the HEAD.

Daniel
>From f1c770216e4eadaa641fb4f9894576358df5cf74 Mon Sep 17 00:00:00 2001
From: Daniel Santos 
Date: Sun, 13 Sep 2020 20:49:06 -0500
Subject: Goloang: Add customizable ARCH flags via CGO_MACHINE_FLAGS

Adds the option to override Golang's choice of architecture-specific
machine flags with arbitrary values via the environment variable
CGO_MACHINE_FLAGS.  Then we supply those via the MACHINE_FLAGS make
variable fed from CONFIG_MACHINE_FLAGS from .config.

Signed-off-by: Daniel Santos 
---
 lang/golang/golang-package.mk |  1 +
 lang/golang/golang-values.mk  |  2 +-
 ...GS-to-override-hard-coded-arch-flags.patch | 28 +++
 3 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch

diff --git a/lang/golang/golang-package.mk b/lang/golang/golang-package.mk
index 73c6572a9..e3bbab6bc 100644
--- a/lang/golang/golang-package.mk
+++ b/lang/golang/golang-package.mk
@@ -154,6 +154,7 @@ define GoPackage/Environment/Default
 	GOMIPS=$(GO_MIPS) \
 	GOMIPS64=$(GO_MIPS64) \
 	CGO_ENABLED=1 \
+	CGO_MACHINE_FLAGS="$(MACHINE_FLAGS)" \
 	CGO_CFLAGS="$(filter-out $(GO_CFLAGS_TO_REMOVE),$(TARGET_CFLAGS))" \
 	CGO_CPPFLAGS="$(TARGET_CPPFLAGS)" \
 	CGO_CXXFLAGS="$(filter-out $(GO_CFLAGS_TO_REMOVE),$(TARGET_CXXFLAGS))"
diff --git a/lang/golang/golang-values.mk b/lang/golang/golang-values.mk
index 8989a1af4..a5a8c9502 100644
--- a/lang/golang/golang-values.mk
+++ b/lang/golang/golang-values.mk
@@ -16,7 +16,7 @@ unexport \
   GOARCH GOBIN GOCACHE GOFLAGS GOHOSTARCH GOOS GOPATH GORACE GOROOT GOTMPDIR GCCGO \
   GOGC GODEBUG GOMAXPROCS GOTRACEBACK \
   CGO_ENABLED \
-  CGO_CFLAGS CGO_CFLAGS_ALLOW CGO_CFLAGS_DISALLOW \
+  CGO_CFLAGS CGO_CFLAGS_ALLOW CGO_CFLAGS_DISALLOW CGO_MACHINE_FLAGS \
   CGO_CPPFLAGS CGO_CPPFLAGS_ALLOW CGO_CPPFLAGS_DISALLOW \
   CGO_CXXFLAGS CGO_CXXFLAGS_ALLOW CGO_CXXFLAGS_DISALLOW \
   CGO_FFLAGS CGO_FFLAGS_ALLOW CGO_FFLAGS_DISALLOW \
diff --git a/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch b/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch
new file mode 100644
index 0..377c0a447
--- /dev/null
+++ b/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch
@@ -0,0 +1,28 @@
+From 6a5ab9c65b1930377d42b9ffeea93684586685ef Mon Sep 17 00:00:00 2001
+From: Daniel Santos 
+Date: Sun, 13 Sep 2020 20:45:55 -0500
+Subject: Add CGO_MACHINE_FLAGS to override hard-coded flags
+
+Adds CGO_MACHINE_FLAGS to add a mechanism to correct machine flags when
+the hard-coded ones chosen by Google are wrong or sub-optimal.
+---
+ src/cmd/go/internal/work/exec.go | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/cmd/go/internal/work/exec.go b/src/cmd/go/internal/work/exec.go
+index 892e3cb500..6fa050fd38 100644
+--- a/src/cmd/go/internal/work/exec.go
 b/src/cmd/go/internal/work/exec.go
+@@ -2400,6 +2400,9 @@ func (b *Builder) gccSupportsFlag(compiler []string, flag string) bool {
+ 
+ // gccArchArgs returns arguments to pass to gcc based on the architecture.
+ func (b *Builder) gccArchArgs() []string {
++	if af := os.Getenv("CGO_MACHINE_FLAGS"); af != "" {
++	return strings.Fields(af)
++	}
+ 	switch cfg.Goarch {
+ 	case "386":
+ 		return []string{"-m32"}
+-- 
+2.24.1
+
-- 
2.24.1

>From 985f3a6cc0c9fe69e441f17dfb6fcc77fbef68a9 Mon Sep 17 00:00:00 2001
From: Daniel Santos 
Date: Sun, 13 Sep 2020 22:31:14 -0500
Subject: Add MACHINE_FLAGS for use by Golang

This splits up the DEFAULT_CFLAGS --> TARGET_OPTIMIZATIONS flag
generation process, separating out the machine-specific flags.  This is
currently only used in a Golang patch to better control how CGo
generates code.

Signed-off-by: Daniel Santos 
---
 include/target.mk  |  5 +++--
 rules.mk   |  1 +
 

RE: [PATCH v3 6/8] kernel: package bcm53xx i2c module

2020-09-15 Thread Adrian Schmutzler
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Christian Lamparter
> Sent: Samstag, 12. September 2020 23:16
> To: openwrt-devel@lists.openwrt.org
> Cc: ra...@milecki.pl; ha...@hauke-m.de; f.faine...@gmail.com;
> chrisrblak...@gmail.com; Adrian Schmutzler 
> Subject: [PATCH v3 6/8] kernel: package bcm53xx i2c module
> 
> The BCM5301x SoCs do have i2c. Since this is only being used by the Meraki
> MR32, this will be packaged as a module.
> 
> Signed-off-by: Christian Lamparter 
> ---
>  package/kernel/linux/modules/i2c.mk | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/package/kernel/linux/modules/i2c.mk
> b/package/kernel/linux/modules/i2c.mk
> index ca6463c81b..1c8b1b844e 100644
> --- a/package/kernel/linux/modules/i2c.mk
> +++ b/package/kernel/linux/modules/i2c.mk
> @@ -259,3 +259,17 @@ endef
>  $(eval $(call KernelPackage,i2c-tiny-usb))
> 
> 
> +I2C_BCM_IPROC_MODULES:= \
> +  CONFIG_I2C_BCM_IPROC:drivers/i2c/busses/i2c-bcm-iproc
> +
> +define KernelPackage/i2c-bcm-iproc
> +  $(call i2c_defaults,$(I2C_BCM_IPROC_MODULES),59)
> +  TITLE:=Broadcom iProc I2C controller
> +  DEPENDS:=@TARGET_bcm53xx +kmod-i2c-core endef

More a question than a remark:

I always wonder whether stuff like this (depending on a single target) belongs 
into package/kernel/linux/modules/... or into target/linux/bcm53xx/modules.mk

Is there a general rule or is this mostly depending on circumstances/taste?

Best

Adrian

> +
> +define KernelPackage/i2c-bcm-iproc/description
> + Kernel module for the Broadcom iProc I2C controller.
> +endef
> +
> +$(eval $(call KernelPackage,i2c-bcm-iproc))
> --
> 2.28.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


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: [PATCH v3 6/8] kernel: package bcm53xx i2c module

2020-09-15 Thread Daniel Golle
On Tue, Sep 15, 2020 at 01:28:23PM +0200, Adrian Schmutzler wrote:
> Hi,
> 
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Christian Lamparter
> > Sent: Samstag, 12. September 2020 23:16
> > To: openwrt-devel@lists.openwrt.org
> > Cc: ra...@milecki.pl; ha...@hauke-m.de; f.faine...@gmail.com;
> > chrisrblak...@gmail.com; Adrian Schmutzler 
> > Subject: [PATCH v3 6/8] kernel: package bcm53xx i2c module
> > 
> > The BCM5301x SoCs do have i2c. Since this is only being used by the Meraki
> > MR32, this will be packaged as a module.
> > 
> > Signed-off-by: Christian Lamparter 
> > ---
> >  package/kernel/linux/modules/i2c.mk | 14 ++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/package/kernel/linux/modules/i2c.mk
> > b/package/kernel/linux/modules/i2c.mk
> > index ca6463c81b..1c8b1b844e 100644
> > --- a/package/kernel/linux/modules/i2c.mk
> > +++ b/package/kernel/linux/modules/i2c.mk
> > @@ -259,3 +259,17 @@ endef
> >  $(eval $(call KernelPackage,i2c-tiny-usb))
> > 
> > 
> > +I2C_BCM_IPROC_MODULES:= \
> > +  CONFIG_I2C_BCM_IPROC:drivers/i2c/busses/i2c-bcm-iproc
> > +
> > +define KernelPackage/i2c-bcm-iproc
> > +  $(call i2c_defaults,$(I2C_BCM_IPROC_MODULES),59)
> > +  TITLE:=Broadcom iProc I2C controller
> > +  DEPENDS:=@TARGET_bcm53xx +kmod-i2c-core endef
> 
> More a question than a remark:
> 
> I always wonder whether stuff like this (depending on a single target) 
> belongs into package/kernel/linux/modules/... or into 
> target/linux/bcm53xx/modules.mk
> 
> Is there a general rule or is this mostly depending on circumstances/taste?

I'd say in a case like that (DEPENDS:=@TARGET_bcm53xx) it should go to
target/linux/bcm53xx/modules.mk. However, another idea of that can be
to list in-tree modules in package/kernel/linux/modules/... and target-
specific out-of-tree modules in target/linux/*/modules.mk.
I don't think we got a clear policy regarding that.

> 
> Best
> 
> Adrian
> 
> > +
> > +define KernelPackage/i2c-bcm-iproc/description
> > + Kernel module for the Broadcom iProc I2C controller.
> > +endef
> > +
> > +$(eval $(call KernelPackage,i2c-bcm-iproc))
> > --
> > 2.28.0
> > 
> > 
> > ___
> > 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:

2020-09-15 Thread Jeffery To
Hi Daniel,

(Resending due to HTML email being rejected...)

On Tue, Sep 15, 2020 at 2:26 PM Daniel Santos via openwrt-devel
 wrote:
> Thank you for the wonderful work on maintaining the Go packages!

You're welcome :-)

> I got a little irritated at CGo's restriction of arch flags (in the
> immutable GOGCCFLAGS variable) and put together a patch set for v19.07
> to override them with an environment variable and then (optionally) feed
> the machine flags in the Golang build.  In the OpenWRT repo, I did this
> by splitting out how DEFAULT_CFLAGS are put together in order to
> populate a DEFAULT_MACHINE_FLAGS, but it could probably be done with
> just a $(filter -m%,$(DEFAULT_CFLAGS)) instead.
>
> If you or others have any interest in this, I can clean them up for the
> master branch.  I'm probably going to submit the Golang patch upstream,
> since I don't see any good reason for such a restriction.  I see you've
> made a lot of changes on the HEAD.

I can't speak for the main OpenWrt repo changes, but I would prefer to
have the Go compiler patch accepted upstream first. They may have
certain assumptions/dependencies on the arch flags that I'm not aware
of.

Jeff

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


RE: [PATCH v3 7/8] bcm53xx: add Cisco Meraki MR32

2020-09-15 Thread Adrian Schmutzler
Hi,

> --- a/target/linux/bcm53xx/image/Makefile
> +++ b/target/linux/bcm53xx/image/Makefile
> @@ -320,6 +320,33 @@ define Device/luxul_xwr-3150  endef
> TARGET_DEVICES += luxul_xwr-3150
> 
> +define Device/meraki_mr32
> +  DEVICE_VENODR := Meraki
> +  DEVICE_MODEL := MR32
> +  DEVICE_PACKAGES := $(B43) kmod-i2c-bcm-iproc kmod-i2c-gpio kmod-
> eeprom-at24 \
> + kmod-leds-pwm kmod-hwmon-core kmod-hwmon-ina2xx kmod-

kmod-hwmon-core gets selected by kmod-hwmon-ina2xx now (since [1]), so 
technically it could be removed here.
But this isn't really important, just FYI if you touch the stuff again anyway...

[1] 
https://github.com/openwrt/openwrt/commit/4159054fbbf8a7176eaf3dd4467c5b0db70769d0

Best

Adrian 


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: [PATCH v2 1/2] ipq40xx: add support for Luma Home WRTQ-329ACN

2020-09-15 Thread Tomasz Maciej Nowak
Hi Christian, thanks for looking at this.

W dniu 13.09.2020 o 00:04, Christian Lamparter pisze:
> On 2020-08-30 13:28, Tomasz Maciej Nowak wrote:
>> Luma Home WRTQ-329ACN, also known as Luma WiFi System, is a dual-band
>> wireless access point.
>>
>> Specification
>> SoC: Qualcomm Atheros IPQ4018
>> RAM: 256 MB DDR3
>> Flash: 2 MB SPI NOR
>>     128 MB SPI NAND
>> WIFI: 2.4 GHz 2T2R integrated
>>    5 GHz 2T2R integrated
>> Ethernet: 2x 10/100/1000 Mbps QCA8075
>> USB: 1x 2.0
>> Bluetooth: 1x 4.0 CSR8510 A10, connected to USB bus
>> LEDS: 16x multicolor LEDs ring, controlled by MSP430G2403 MCU
>> Buttons: 1x GPIO controlled
>> EEPROM: 16 Kbit, compatible with AT24C16
>> UART: row of 4 holes marked on PCB as J19, starting count from the side
>>    of J19 marking on PCB
>>    1. GND, 2. RX, 3. TX, 4. 3.3V
>>    baud: 115200, parity: none, flow control: none
>>
>> The device supports OTA or USB flash drive updates, unfotunately they
>> are signed. Until the signing key is known, the UART access is mandatory
>> for installation. The difficult part is disassembling the casing, there
>> are a lot of latches holding it together.
>>
>> Teardown
>> Prepare three thin, but sturdy, prying tools. Place the device with back
>> of it facing upwards. Start with the wall having a small notch. Insert
>> first tool, until You'll feel resistance and keep it there. Repeat the
>> procedure for neighbouring walls. With applying a pressure, one edge of
>> the back cover should pop up. Now carefully slide one of the tools to
>> free the rest of the latches.
>> There's no need to solder pins to the UART holes, You can use hook clips,
>> but wiring them outside the casing, will ease debuging and recovery if
>> problems occur.
>>
>> Installation
>> 1. Prepare TFTP server with OpenWrt initramfs image.
>> 2. Connect to UART port (don't connect the voltage pin).
>> 3. Connect to LAN port.
>> 4. Power on the device, carefully observe the console output and when
>>     asked quickly enter the failsafe mode.
>> 5. Invoke 'mount_root'.
>> 6. After the overlayfs is mounted run:
>>   fw_setenv bootdelay 3
>>     This will allow to access U-Boot shell.
>> 7. Reboot the device and when prompted to stop autoboot, hit any key.
>> 8. Adjust "ipaddr" and "serverip" addresses in U-Boot environment, use
>>     'setenv' to do that, then run following commands:
>>   tftpboot 0x8400 
>>   bootm 0x8400
>>     and wait till OpenWrt boots.
>> 9. In OpenWrt command line run following commands:
>>   fw_setenv openwrt "setenv mtdids nand1=spi_nand; setenv mtdparts 
>> mtdparts=spi_nand:-(ubi); ubi part ubi; ubi read 0x8400 kernel1; bootm 
>> 0x8400"
>>   fw_setenv bootcmd "run openwrt"
> So, because you install from the initramfs and introduced a custom run
> command with a custom "kernel1" ubi volume... It might be possible to
> cut the extra parts in the sysupgrade and bootargs and unify it with
> the generic nand_do_upgrade() crowed.
> 
> I've incorperated what maybe could be done in this patch on my
> staging tree: [0]
> 
> (Note the changes in step 9 (kernel1->kernel), step 10 (ubirmvol ubi_rootfs1 
> & kernel1) and the "step 2 in
> back to OEM".
> 
> The idea is that we use OpenWrt's existing automount for ubi
> and "rootfs" volumes.
> 
> (In theory this could make the "back to OEM" even easier.
> Because if it works the way I think it does, we could drop
> the ubirmvol of ubi_rootfs1 and kernel1 in step 10 of my version.
> Next, it should be possible to drop the ubimkvol of
> kernel1 and ubi_rootfs1 step 2 in the "Reverting to OEM" section.
> This is because the original rootfs1 and kernel1 still exist and
> are left untouched - no idea if this works out or not.)

Personally I would like to use whole NAND for OpenWrt, that would simplify 
everything a lot.
Unfortunately some users might be dissatisfied with how things are done in 
OpenWrt and wish
to revert to stock firmware. I'll explain in points what are the current issues 
with this
device. My knowledge is based on what I could dig out from firmware (QSDK) 
without access to
source modifications.

1. The devices have different flash layouts, some come with
mtd8: 0800 0002 "rootfs"
mtd9: 0041e000 0001f000 "kernel"
mtd10: 026c 0001f000 "ubi_rootfs"
mtd11: 01ff8000 0001f000 "rootfs_data"
mtd12: 0041e000 0001f000 "kernel1"
mtd13: 026c 0001f000 "ubi_rootfs1"

and some

mtd8: 0800 0002 "rootfs"
mtd9: 003a2000 0001f000 "kernel"
mtd10: 02283000 0001f000 "ubi_rootfs"
mtd11: 0062d000 0001f000 "dummy"
mtd12: 01ff8000 0001f000 "rootfs_data"
mtd13: 0041e000 0001f000 "kernel1"
mtd14: 026c 0001f000 "ubi_rootfs1"

this reflects the bootargs in dts.

2. As illustrated above, the device comes with two sets of kernel+ubi_rootfs 
and shared
overlay "rootfs_data". The U-Boot with 'bootipq' command boots the first 
kernel+ubi_rootfs
pair. There is some kind of fallback mechanism to issue boot from the second 
pair, but I was
unable to 

[PATCH] ubus: add ACL support for "subscribe" request

2020-09-15 Thread Rafał Miłecki
From: Rafał Miłecki 

With this change ubus will allow users with access to the object pseudo
method ":subscribe" to subscribe for notifications.

1. Move uh_ubus_allowed() up in the code
2. Export "Authorization" parsing code to the uh_ubus_get_auth()
3. Check for ":subscribe" method access

Right now this depends on "Authorization" HTTP header which browsers
don't allow setting for the EventSource. An alternative method of
submitting session token remains to be implemented.

Signed-off-by: Rafał Miłecki 
---
 ubus.c | 119 +++--
 1 file changed, 64 insertions(+), 55 deletions(-)

diff --git a/ubus.c b/ubus.c
index ccddbbd..1cf5c5f 100644
--- a/ubus.c
+++ b/ubus.c
@@ -112,6 +112,30 @@ enum cors_hdr {
__HDR_MAX
 };
 
+enum ubus_hdr {
+   HDR_AUTHORIZATION,
+   __HDR_UBUS_MAX
+};
+
+static const char *uh_ubus_get_auth(const struct blob_attr *attr)
+{
+   static const struct blobmsg_policy hdr_policy[__HDR_UBUS_MAX] = {
+   [HDR_AUTHORIZATION] = { "authorization", BLOBMSG_TYPE_STRING },
+   };
+   struct blob_attr *tb[__HDR_UBUS_MAX];
+
+   blobmsg_parse(hdr_policy, __HDR_UBUS_MAX, tb, blob_data(attr), 
blob_len(attr));
+
+   if (tb[HDR_AUTHORIZATION]) {
+   const char *tmp = blobmsg_get_string(tb[HDR_AUTHORIZATION]);
+
+   if (!strncasecmp(tmp, "Bearer ", 7))
+   return tmp + 7;
+   }
+
+   return UH_UBUS_DEFAULT_SID;
+}
+
 static void __uh_ubus_next_batched_request(struct uloop_timeout *timeout);
 
 static void uh_ubus_next_batched_request(struct client *cl)
@@ -239,6 +263,39 @@ static void uh_ubus_ubus_error(struct client *cl, int err)
uh_ubus_error(cl, err, ubus_strerror(err));
 }
 
+static void uh_ubus_allowed_cb(struct ubus_request *req, int type, struct 
blob_attr *msg)
+{
+   struct blob_attr *tb[__SES_MAX];
+   bool *allow = (bool *)req->priv;
+
+   if (!msg)
+   return;
+
+   blobmsg_parse(ses_policy, __SES_MAX, tb, blob_data(msg), blob_len(msg));
+
+   if (tb[SES_ACCESS])
+   *allow = blobmsg_get_bool(tb[SES_ACCESS]);
+}
+
+static bool uh_ubus_allowed(const char *sid, const char *obj, const char *fun)
+{
+   uint32_t id;
+   bool allow = false;
+   static struct blob_buf req;
+
+   if (ubus_lookup_id(ctx, "session", ))
+   return false;
+
+   blob_buf_init(, 0);
+   blobmsg_add_string(, "ubus_rpc_session", sid);
+   blobmsg_add_string(, "object", obj);
+   blobmsg_add_string(, "function", fun);
+
+   ubus_invoke(ctx, id, "access", req.head, uh_ubus_allowed_cb, , 
conf.script_timeout * 500);
+
+   return allow;
+}
+
 /* GET requests handling */
 
 static void uh_ubus_list_cb(struct ubus_context *ctx, struct ubus_object_data 
*obj, void *priv);
@@ -303,14 +360,16 @@ static void 
uh_ubus_subscription_notification_remove_cb(struct ubus_context *ctx
ops->request_done(cl);
 }
 
-static void uh_ubus_handle_get_subscribe(struct client *cl, const char *sid, 
const char *path)
+static void uh_ubus_handle_get_subscribe(struct client *cl, const char *path)
 {
struct dispatch_ubus *du = >dispatch.ubus;
+   const char *sid;
uint32_t id;
int err;
 
-   /* TODO: add ACL support */
-   if (!conf.ubus_noauth) {
+   sid = uh_ubus_get_auth(cl->hdr.head);
+
+   if (!conf.ubus_noauth && !uh_ubus_allowed(sid, path, ":subscribe")) {
uh_ubus_send_header(cl, 200, "OK", "application/json");
uh_ubus_posix_error(cl, EACCES);
return;
@@ -364,7 +423,7 @@ static void uh_ubus_handle_get(struct client *cl)
} else if (!strncmp(url, "/subscribe/", strlen("/subscribe/"))) {
url += strlen("/subscribe");
 
-   uh_ubus_handle_get_subscribe(cl, NULL, url + 1);
+   uh_ubus_handle_get_subscribe(cl, url + 1);
} else {
ops->http_header(cl, 404, "Not Found");
ustream_printf(cl->us, "\r\n");
@@ -682,39 +741,6 @@ static void uh_ubus_complete_batch(struct client *cl)
ops->request_done(cl);
 }
 
-static void uh_ubus_allowed_cb(struct ubus_request *req, int type, struct 
blob_attr *msg)
-{
-   struct blob_attr *tb[__SES_MAX];
-   bool *allow = (bool *)req->priv;
-
-   if (!msg)
-   return;
-
-   blobmsg_parse(ses_policy, __SES_MAX, tb, blob_data(msg), blob_len(msg));
-
-   if (tb[SES_ACCESS])
-   *allow = blobmsg_get_bool(tb[SES_ACCESS]);
-}
-
-static bool uh_ubus_allowed(const char *sid, const char *obj, const char *fun)
-{
-   uint32_t id;
-   bool allow = false;
-   static struct blob_buf req;
-
-   if (ubus_lookup_id(ctx, "session", ))
-   return false;
-
-   blob_buf_init(, 0);
-   blobmsg_add_string(, "ubus_rpc_session", sid);
-   blobmsg_add_string(, "object", obj);
-   blobmsg_add_string(, "function", fun);
-

[PATCH] Fix tx-queue-size on NBG6817 (allows MTU changes).

2020-09-15 Thread jacekowski
From: Jacek Milewicz 

Fixes FS#3285 for NBG6817 only.

Signed-off-by: Jacek Milewicz 
---
 .../files-4.14/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts 
b/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts
index 7cd1c7b567..5745040d2b 100644
--- a/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts
+++ b/target/linux/ipq806x/files-4.14/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts
@@ -289,6 +289,7 @@
qcom,emulation = <0>;
qcom,irq = <255>;
mdiobus = <>;
+   tx-fifo-depth = <4096>;
 
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -310,6 +311,7 @@
qcom,emulation = <0>;
qcom,irq = <258>;
mdiobus = <>;
+   tx-fifo-depth = <4096>;
 
fixed-link {
speed = <1000>;
-- 
2.17.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH] conf: add src/{,gz}/trusted option

2020-09-15 Thread Paul Spooren
This options allows to individually disable signature checks for
individual feeds. This option should only be used for local feeds or
remote feeds downloaded via HTTPS.

Within OpenWrt this option allows ImageBuilders to verify remote feeds
while also taking local feeds into account which are unsigned.

The two new config options are:

src/trusted
src/gz/trusted

Signed-off-by: Paul Spooren 
---
ImageBuilders offer a folder called "packages/" which includes at least
the packages kernel_*.ipk and libc*.ipk, additionally packages provided
by the user.

It is not possible to enable signature checks within the
ImageBuilder and allow an unsigned local package  feed at the same time.

This patch is an option to set the special local packages feed to
"trusted".

As an alternative, the ImageBuilder could generate usign keys which sign
the local package feed, however those keys would then also be considered
for remote feeds which seems less secure.

 libopkg/opkg_cmd.c |  2 +-
 libopkg/opkg_conf.c| 28 
 libopkg/pkg_hash.c |  2 +-
 libopkg/pkg_src.c  |  3 ++-
 libopkg/pkg_src.h  |  3 ++-
 libopkg/pkg_src_list.c |  4 ++--
 libopkg/pkg_src_list.h |  2 +-
 7 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/libopkg/opkg_cmd.c b/libopkg/opkg_cmd.c
index a329558..05c0c85 100644
--- a/libopkg/opkg_cmd.c
+++ b/libopkg/opkg_cmd.c
@@ -143,7 +143,7 @@ static int opkg_update_cmd(int argc, char **argv)
}
free(url);
 #if defined(HAVE_USIGN)
-   if (pkglist_dl_error == 0 && conf->check_signature) {
+   if (pkglist_dl_error == 0 && conf->check_signature && ! 
src->trusted) {
/* download detached signitures to verify the package 
lists */
/* get the url for the sig file */
if (src->extra_data)/* debian style? */
diff --git a/libopkg/opkg_conf.c b/libopkg/opkg_conf.c
index 38703ee..6097588 100644
--- a/libopkg/opkg_conf.c
+++ b/libopkg/opkg_conf.c
@@ -295,7 +295,7 @@ opkg_conf_parse_file(const char *filename,
if (!nv_pair_list_find
((nv_pair_list_t *) dist_src_list, name)) {
pkg_src_list_append(dist_src_list, name,
-   value, extra, 0);
+   value, extra, 0, 0);
} else {
opkg_msg(ERROR,
 "Duplicate dist declaration 
(%s %s). "
@@ -305,7 +305,7 @@ opkg_conf_parse_file(const char *filename,
if (!nv_pair_list_find
((nv_pair_list_t *) dist_src_list, name)) {
pkg_src_list_append(dist_src_list, name,
-   value, extra, 1);
+   value, extra, 1, 0);
} else {
opkg_msg(ERROR,
 "Duplicate dist declaration 
(%s %s). "
@@ -315,7 +315,7 @@ opkg_conf_parse_file(const char *filename,
if (!nv_pair_list_find
((nv_pair_list_t *) pkg_src_list, name)) {
pkg_src_list_append(pkg_src_list, name,
-   value, extra, 0);
+   value, extra, 0, 0);
} else {
opkg_msg(ERROR,
 "Duplicate src declaration (%s 
%s). "
@@ -325,7 +325,27 @@ opkg_conf_parse_file(const char *filename,
if (!nv_pair_list_find
((nv_pair_list_t *) pkg_src_list, name)) {
pkg_src_list_append(pkg_src_list, name,
-   value, extra, 1);
+   value, extra, 1, 0);
+   } else {
+   opkg_msg(ERROR,
+"Duplicate src declaration (%s 
%s). "
+"Skipping.\n", name, value);
+   }
+   } else if (strcmp(type, "src/trusted") == 0) {
+   if (!nv_pair_list_find
+   ((nv_pair_list_t *) pkg_src_list, name)) {
+   pkg_src_list_append(pkg_src_list, name,
+

[PATCH v2] imagebuilder: add package signature verification

2020-09-15 Thread Paul Spooren
The ImageBuilder downloads pre-built packages and adds them to images.
This process uses `opkg` which has the capability to verify package list
signatures via `usign`, as enabled per default on running OpenWrt
devices.

Until now this was disabled for ImageBuilders because neither the `opkg`
keys nor the `opkg-add` script was present during first packagelist
update.

To harden the ImageBuilder against *drive-by-download-attacks* both keys
and verification script are added to the ImageBuilder allowing `opkg` to
verify downloaded package indices.

This commit adds `opkg-add` to the ImageBuilder scripts folder. The keys
folder is added to ImageBuilder $TOPDIR to have an obvious place for users to
store their own keys. The `option check_signature` is appended to the
repositories.conf file. All of the above only happens if the Buildbot
runs with the SIGNATURE_CHECK option.

The keys stored in the ImageBuilder keys/ folder are the same as stored
within images in `/etc/opkg/keys`.

To allow a local package feed in which the user can add additional
packages, the local *imagebuilder* feed is set to `src/trusted` which
skips signature verification only on this particular feed.

Signed-off-by: Paul Spooren 
---
 target/imagebuilder/Makefile   | 10 +-
 target/imagebuilder/files/Makefile |  2 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile
index ad19ab2b53..0cdc1f4d93 100644
--- a/target/imagebuilder/Makefile
+++ b/target/imagebuilder/Makefile
@@ -42,7 +42,7 @@ endif
 
echo ''>> 
$(PKG_BUILD_DIR)/repositories.conf
echo '## This is the local package repository, do not remove!' >> 
$(PKG_BUILD_DIR)/repositories.conf
-   echo 'src imagebuilder file:packages'  >> 
$(PKG_BUILD_DIR)/repositories.conf
+   echo 'src/trusted imagebuilder file:packages'  >> 
$(PKG_BUILD_DIR)/repositories.conf
 
$(VERSION_SED_SCRIPT) $(PKG_BUILD_DIR)/repositories.conf
 
@@ -57,6 +57,14 @@ else
find $(wildcard $(PACKAGE_SUBDIRS)) -type f -name '*.ipk' -exec $(CP) 
{} $(PKG_BUILD_DIR)/packages/ \;
 endif
 
+ifneq ($(CONFIG_SIGNATURE_CHECK),)
+   echo ''>> 
$(PKG_BUILD_DIR)/repositories.conf
+   echo 'option check_signature'  >> 
$(PKG_BUILD_DIR)/repositories.conf
+   $(INSTALL_DIR) $(PKG_BUILD_DIR)/keys
+   $(CP) -L $(STAGING_DIR_ROOT)/etc/opkg/keys/ $(PKG_BUILD_DIR)/
+   $(CP) -L $(STAGING_DIR_ROOT)/usr/sbin/opkg-key $(PKG_BUILD_DIR)/scripts/
+endif
+
$(CP) $(TOPDIR)/target/linux $(PKG_BUILD_DIR)/target/
if [ -d $(TOPDIR)/staging_dir/host/lib/grub ]; then \
$(CP) $(TOPDIR)/staging_dir/host/lib/grub/ 
$(PKG_BUILD_DIR)/staging_dir/host/lib; \
diff --git a/target/imagebuilder/files/Makefile 
b/target/imagebuilder/files/Makefile
index 27d3cfa8df..56b70f16b5 100644
--- a/target/imagebuilder/files/Makefile
+++ b/target/imagebuilder/files/Makefile
@@ -64,8 +64,10 @@ help: FORCE
 # override variables from rules.mk
 PACKAGE_DIR:=$(TOPDIR)/packages
 LISTS_DIR:=$(subst $(space),/,$(patsubst %,..,$(subst 
/,$(space),$(TARGET_DIR$(DL_DIR)
+export OPKG_KEYS:=$(TOPDIR)/keys
 OPKG:=$(call opkg,$(TARGET_DIR)) \
-f $(TOPDIR)/repositories.conf \
+   --verify-program $(SCRIPT_DIR)/opkg-key \
--cache $(DL_DIR) \
--lists-dir $(LISTS_DIR)
 
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 1/3] build: add libustream and certs to default pkgs

2020-09-15 Thread Henrique de Moraes Holschuh

On 27/08/2020 18:47, Paul Spooren wrote:

To allow HTTPS usage on a router it requires both certificates
(ca-bundle) and a fitting libustream library (libustream-wolfssl)

By adding both, uclient-fetch and wget can connect to encrypted HTTP.

This allows opkg to update package lists in a more secure fashion.


It is also a FLASH pig IMHO: not as bad as, say, openssl, but ca-bundle 
is still Not Small[tm] :-(


ca-bundle could benefit from some Kconfig-enforced mega diet:


[ ] Let's Encrypt and its alternative roots
[ ] Openwrt.org's packages
[ ] custom path -> (some path where we can add custom certificates,
with a default of certs/)
[ ] All other certificates we'd usually package in ca-bundle

Default would be something that gets us all the current certificates in 
ca-bundle, and maybe just the custom path or LE for the SMALL_FLASH version.


--
Henrique de Moraes Holschuh
www.nic.br

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH] ath79: add support for Ubiquiti UniFi AP Pro

2020-09-15 Thread Rafał Miłecki
On Mon, 14 Sep 2020 at 14:22, David Bauer  wrote:
> +   firmware-partition@5 {
> +   label = "firmware";
> +   reg = <0x5 0xf6>;
> +   };

Please specify "compatible" so the kernel doesn't have to guess its format.

https://openwrt.org/docs/guide-developer/defining-firmware-partitions#defining_software_partitions_in_all_dts_targets

-- 
Rafał

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel