While keeping the default build profile, this allows users to generate only
their device image instead of every bcm53xx supported device image
This way we can also define the proper packages for each device (USB, WiFi...)
Signed-off-by: Álvaro Fernández Rojas
---
target/linux/bcm53xx/Makefile
It seems that I'm unable to understand what really happened.
I decided to start all over again, and instead of adding a lot of features
to the kernel and test them, I decided to start with a default kernel and
add features one by one, testing them along the way.
Since the Chaos Calmer is now out, I
good decision let us know if you run into issues. one change at a time
is always best in these cases and tend to cost less time to get the
final result.
On 13/09/2015 15:14, Carlos Ferreira wrote:
> It seems that I'm unable to understand what really happened.
> I decided to start all over again,
On 13 September 2015 at 13:06, Álvaro Fernández Rojas wrote:
> While keeping the default build profile, this allows users to generate only
> their device image instead of every bcm53xx supported device image
> This way we can also define the proper packages for each device (USB, WiFi...)
I still
Btw, I'm taking this issue quite seriously, because I really wanted to use
OpenWRT in My SuperMicro motherboard. For many, using this kind of hardware
with OpenWRT might be seen as overkill, but these are my reasons:
- This motherboard uses an Atom CPU which does not support VT-d, so PCI
passthroug
At the moment the OpenWRT www login screen provides *very* detailed version
information before anyone has even entered a password. It displays not just
“15.05” or “Chaos Calmer” but even the exact git version on the banner.
While it’s not advised to open this login screen to the world, fact is t
Quite frankly if someone has unintionally exposed LuCI to the internet I
think they've got a lot bigger problem than exposed version information,
and that not putting the version information at best delays only very
slightly a would be attacker.
And for properly configured installs, the versio
Actually two far more useful solutions:
1) By default only answer requests from 'lan' network in
/etc/config/uhttp instead of 0.0.0.0/32
2) Some useful alert if what appears to be a firewally misconfiguration
is created (default OpenWrt firewall block LuCI on WAN, therefore the
current issue i
Hi,
Le 13 sept. 2015 16:34, "Daniel Dickinson" a
écrit :
>
> Actually two far more useful solutions:
>
> 1) By default only answer requests from 'lan' network in
/etc/config/uhttp instead of 0.0.0.0/32
> 2) Some useful alert if what appears to be a firewally misconfiguration
is created (default O
Hi Etienne,
This isn't about whether default is safe, but what is a useful to help
limit the damage if the user shoots themselves in the foot with
relatively easy mistakes for a newbie to make.
Breaking the firewall isn't hard, especially for a newbie, so the Ubuntu
philosphy of 'if there is
I see where you’re coming from but I disagree that one should always rely on
the user to know exactly what to do and what not to do. A bit of basic
prevention doesn’t hurt.
Wouldn’t you agree that if you follow that line you might as well argue that
OpenWRT should not come with default-deny rul
Complete the trunk rename from Chaos Calmer to Designated Driver.
r46846 changed /etc/banner to reflect Designated Driver, but did not change
the actual version definition in include/toplevel.mk.
https://dev.openwrt.org/changeset/46846
signed-off-by: Hannu Nyman
Index: include/toplevel.mk
===
My point, especially if you read this post fully, and the following, is
that not displaying the banner is minimally useful, and that other
measure to achieve the same goal (protect user when they mistakes) are
far more useful/meaninful than eliminating the banner.
Regards,
Daniel
On 2015-09-
On 13 September 2015 at 19:42, Hannu Nyman wrote:
> Complete the trunk rename from Chaos Calmer to Designated Driver.
> r46846 changed /etc/banner to reflect Designated Driver, but did not change
> the actual version definition in include/toplevel.mk.
> https://dev.openwrt.org/changeset/46846
>
>
Sorry, but what is the problem?
ozlabs patchwork list shows the properly recognised patch:
https://patchwork.ozlabs.org/patch/517209/
But in any case, inline below.
Hannu
Index: include/toplevel.mk
===
--- include/toplevel.mk(r
Hannu Nyman schrieb am 13.09.2015 um 19:51:
> Sorry, but what is the problem?
Most importantly: laziness. In my case, I just keep hitting the next email
button and have a quick look. Having to open the attachment, choose an editor,
read, close the editor is just inconvenient (and then all the effo
+1 for Etienne
Patch OpenWrt to add robots.txt
On Sun, Sep 13, 2015 at 12:45 PM, Daniel Dickinson <
open...@daniel.thecshore.com> wrote:
> My point, especially if you read this post fully, and the following, is
> that not displaying the banner is minimally useful, and that other measure
> to ach
I agree add robots.txt would be useful, but I suspect that lies between
point 1 and 2 of my second email (that is configuring uhttpd listen on
on lan by default is easiest, and frankly most useful from a
'bang-for-buck' point of view), is probably easier than 2 because 2
(attempting to notify o
Oh and 1 has the benefit of actually securing the device against wan
access to LuCI even in the case of firewall not blocking such access,
whereas the robots.txt and hiding banner are classic 'security through
obscurity' which is the security pundit's favourite target for good reason.
Regards,
I just remembered that robots.txt is just a text file to stick in /www,
so it is certainly is not high cost, although now that I remember that
is also less useful than I was thinking because it really only prevents
indexing by cooperative robots that obey robots.txt
Basically all it really get
I do think allowing to choose to disable the banner is a minor benefit,
however, as I've said, there are much more effective means of preventing
accidential exposure, and quite frankly if the user is *choosing* to
open the web interface I think an warning and disabling the banner if
the user fo
While openwrt doesn't offer security release, hiding version in banner is
not very effective. If the attacker can detect it is OpenWRT and if there
is a known security issue for any major version, it is enough to try an
attack.
Robot.txt is effective as Google is a common tool to look for targets.
On 2015-09-13 19:51, Hannu Nyman wrote:
> Sorry, but what is the problem?
> ozlabs patchwork list shows the properly recognised patch:
> https://patchwork.ozlabs.org/patch/517209/
>
> But in any case, inline below.
>
> Hannu
>
> Index: include/toplevel.mk
> ==
Am 13.09.2015 um 22:04 schrieb Daniel Dickinson:
I do think allowing to choose to disable the banner is a minor
benefit, however, as
Anyway It's a bad behavior to disclose detailed version information
without login. SOHO Routers are not as often upgraded as normal PCs - so
why make it easier
On 2015-09-13 4:41 PM, Luiz Angelo Daros de Luca wrote:
While openwrt doesn't offer security release, hiding version in banner
is not very effective. If the attacker can detect it is OpenWRT and if
there is a known security issue for any major version, it is enough to
try an attack.
Robot.txt is
Hi Daniel,
Le 13 sept. 2015 22:04, "Daniel Dickinson" a
écrit :
>
> I do think allowing to choose to disable the banner is a minor benefit,
however, as I've said, there are much more effective means of preventing
accidential exposure, and quite frankly if the user is *choosing* to open
the web in
Hi again,
Le 13 sept. 2015 22:50, "Daniel Dickinson" a
écrit :
>
> On 2015-09-13 4:41 PM, Luiz Angelo Daros de Luca wrote:
>>
>> While openwrt doesn't offer security release, hiding version in banner
>> is not very effective. If the attacker can detect it is OpenWRT and if
>> there is a known sec
On 2015-09-13 5:00 PM, Etienne Champetier wrote:
Hi Daniel,
For me listenning only on lan will break all my setups (15+):
- On most of my openwrt there is no lan, it's management, or
'name-of-the-site' ...
- on some of them i can access from multiple interface (VPNs + ...)
What I'm talking abo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hartmut Knaack wrote:
> Hannu Nyman schrieb am 13.09.2015 um 19:51:
> > Sorry, but what is the problem?
>
> Most importantly: laziness. In my case, I just keep hitting the next
> email
> button and have a quick look. Having to open the attachment, ch
On Sep 13, 2015 2:00 PM, "Etienne Champetier"
wrote:
>
> Hi Daniel,
>
> Le 13 sept. 2015 22:04, "Daniel Dickinson"
a écrit :
> >
> > I do think allowing to choose to disable the banner is a minor benefit,
however, as I've said, there are much more effective means of preventing
accidential exposur
On 2015-09-13 11:39 PM, Florian Fainelli wrote:
On Sep 13, 2015 2:00 PM, "Etienne Champetier"
mailto:champetier.etie...@gmail.com>> wrote:
>
> Hi Daniel,
>
> Le 13 sept. 2015 22:04, "Daniel Dickinson"
mailto:open...@daniel.thecshore.com>> a
écrit :
> >
> > I do think allowing to choose to d
On 2015-09-14 12:30 AM, Daniel Dickinson wrote:
On 2015-09-13 11:39 PM, Florian Fainelli wrote:
On Sep 13, 2015 2:00 PM, "Etienne Champetier"
mailto:champetier.etie...@gmail.com>>
wrote:
>
> Hi Daniel,
>
> Le 13 sept. 2015 22:04, "Daniel Dickinson"
mailto:open...@daniel.thecshore.com>> a
écr
32 matches
Mail list logo
