New: Dropbear: Add options to allow better config for different target devices (e.g. routers)

https://bugs.busybox.net/show_bug.cgi?id=6326

Host: any
Target: any
Build: buildroot 2013.05
Summary: Dropbear: Add options to allow better config for
different target devices (e.g. routers)
Product: buildroot
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Keywords: patch
Severity: enhancement
Priority: P3
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: mail at maddes.net
CC: buildroot at uclibc.org
Estimated Hours: 0.0

Created attachment 4952
--> https://bugs.busybox.net/attachment.cgi?id=4952
Patch (-p1) to add more buildroot options for Dropbear package.

Multiple embedded devices targets do not allow to put files everywhere, therefore paths and commands must be adopted to the given file system. Additionally the current make file changes the path of the xauth command in the background instead of providing an config option.
The attached patch (-p1) adds four buildroot options to the Dropbear package, so it's config can be adopted to any given situation.
Please apply for a future release.

Kind regards
Maddes

P.S.:
Bugzilla does not know the current stable release of buildroot.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=6326

Gustavo Zacarias <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #1 from Gustavo Zacarias <[email protected]> 2013-06-23 01:55:54 UTC --- Which "multiple embedded device targets" are you talking about?
If you can't put files where you want/they belong sounds like you want to use buildroot to extend some sort of closed firmware or target - hacky targets aren't the goal of this project.
Option overloading is not something we want and this patch pretty much looks like it.
You can achive your goal by using something as simple as the global patch dir, that way you can just modify dropbear's options.h directly.

Closing as WONTFIX unless you can give a really good reason why this patch is necessary and you can't use the global patch dir.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=6326

--- Comment #2 from Maddes <[email protected]> 2013-06-23 10:24:40 UTC --- #1 not a hacky target
It is not about hacked/closed firmwares: I built Dropbear for an older DD-Wrt based router from Buffalo, which is an open firmware and allows access to the Linux console and config, with support from Buffalo.
I *do* want to keep the official firmware with its feature, but the included Dropbear is years old and SSH is available from WAN. Therefore a newer Dropbear build is necessary to close security gaps.
The file system layout/design of the firmware consists of a read-only root plus mount points for the writable flash partition and optional USB devices. Even if I use mount -o bind to overlay the original files, the paths are still not the same as the default ones in options.h.
I hope this explanation will get the focus back to the feature/patch itself.

#2 patch for new options to adopt paths
The current make file already "fixes" the XAUTH_COMMAND define in options.h, but that fix must not be correct for all builds/targets. Providing a config option for this makes the buildroot default change transparent and flexible for the builder.
So the current make file already shows that adopting paths to the build/target is indeed needed for normal usage.

But the XAUTH_COMMAND define is not the only path which has to be adopted for a build/target. Therefore the other new options are required too.

#3 global patch dir
Of course the global patch dir can always be used to change anything. But patches are intended for custom features and others that incorporate real code changes.
Flexible configuration settings like these should be generally available and hold in config files.

I see two ways to go:
a) builder-unfriendly
Get rid of the "XAUTH_COMMAND" fix, and leave it *all* to the builder to
patch paths in options.h.
A short sentence (either via Config.in or in dropbear.mk) about using the
global patch dir would avoid support requests.
Builders will have to deal with multiple patch files via
BR2_GLOBAL_PATCH_DIR, incl. rebasing all for changes in Dropbear and/or buildroot.
b) builder-friendly
Apply the patch of this ticket to allow different paths for different builds
via config files.
Builders can use the normal buildroot way of storing configurations.

Kind Regards
Maddes

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=6326

--- Comment #3 from Arnout Vandecappelle <[email protected]> 2013-06-23 17:33:39 UTC --- Buildroot's #1 goal is to be simple yet flexible. Almost every package could get configuration options like this, and they would hardly ever be used.

In addition, buildroot builds a complete and consistent rootfs (hence its name). It is not buildroot's goal to cross-compile packages for addition to an existing rootfs.

The xauth patch is necessary because that is where buildroot itself installs xauth.

And to top things up, buildroot already makes it possible to achieve your goal with the user patch directory.

So I second putting this in WONTFIX.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.