20.xx: postponse LuCI HTTPS per default

Adrian Schmutzler mail at adrianschmutzler.de
Fri Nov 20 12:35:40 EST 2020


Hi,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> On Behalf Of Alberto Bursi
> Sent: Freitag, 20. November 2020 17:32
> To: openwrt-devel at lists.openwrt.org
> Subject: Re: 20.xx: postponse LuCI HTTPS per default
> 
> 
> 
> On 20/11/20 17:17, Fernando Frediani wrote:
> > Hi Alberto
> >
> > On 20/11/2020 13:09, Alberto Bursi wrote:
> >>
> >> <clip>
> >>
> >> The only thing I can accept as a valid complaint against https by
> >> default is the increased minimum space requirements, everything else
> >> I really don't understand nor agree with.
> >
> > It's exactly this I am referring to when I talk about the extras not
> > the steps the user will take to enable it. So why I mentioned to leave
> > it as optional and easy to do for those who wish (and have space) to have
> it.
> >
> 
> Devices with low flash space (and RAM) are already receiving special
> treatment (different compile options, different default packages) to lower
> space footprint.
> 
> These devices can (should?) be left out of the "https by default" easily.

No, this is not an option. We certainly won't have (read "maintain") _two_ defaults for a matter like this.

Apart from that, this discussion was not intended to discuss the various options _again_, but to ask whether we should have "https by default" as a _blocker_ for the next release.
Personally, since the discussion seems to be as open and unresolved as a few months ago, I'm against making this a blocker. I'm curious where the whole topic evolves to, but that's not the subject of this thread.

Best

Adrian

> 
> But I would be strongly against degrading security for everyone just because
> of these devices.
> 
> -Alberto
> 
> > Regards
> > Fernando
> >
> >>
> >>
> >>> Yes it is nice to have everything ready and automated to be done
> >>> with a few clicks for those cases that require it. In fact I think
> >>> this would be a better solution for now so it will be possible to
> >>> gather gradually this transition (or not) from HTTP to HTTPS even
> >>> for local/lan applications and see how often people would opt to use it.
> >>>
> >>> Still should it end up having HTTPS by default I see self-signed
> >>> certificates are the way to go. Yes there are the warnings and I
> >>> really don't think there is any issue with it.
> >>> Those accessing the router Web Interface are not 'normal' Internet
> >>> users and they know what they are doing so the warning from
> >>> self-signed certificates should not be a surprise for them.
> >>> And those cases when admins prefer they can always replace the
> >>> self-signed one for Let's Encrypt for example.
> >>>
> >>> Regards
> >>> Fernando
> >>
> >>
> >> -Alberto
> >>
> >> _______________________________________________
> >> openwrt-devel mailing list
> >> openwrt-devel at lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20201120/538fcad0/attachment.sig>


More information about the openwrt-devel mailing list