On Sun, May 27, 2018 at 2:21 AM, Kang-Che Sung wrote:
> On Sun, May 27, 2018 at 1:34 AM, Denys Vlasenko
> wrote:
>> wget should work for common use cases.
>> Such as downloading sources of kernels, gcc and such.
>> From build scripts, not only by hand.
>> Without having to modify said scripts.
>>
On Sun, May 27, 2018 at 8:55 PM, Michael Conrad wrote:
> The story just broke earlier this year how a casino hotel "smart
> thermometer" in the fish tank was used as a backdoor to attack the rest of
> their network.
>
> If a smart device running busybox is programmed to automatically check for
> f
On Sun, May 27, 2018 at 8:19 PM, Ralf Friedl wrote:
> Denys Vlasenko wrote:
>>
>> wget should work for common use cases.
>> Such as downloading sources of kernels, gcc and such.
>> From build scripts, not only by hand.
>> Without having to modify said scripts.
>> Your patch breaks that.
>> NAK.
>
Hello,
> The justification for including HTTPS in the first place:
> https://git.busybox.net/busybox/tree/networking/wget.c?id=8bc418f07eab79a9c8d26594629799f6157a9466#n74
>
> "my small automatic tooling to build cross-compilers from sources no
> longer works, I need to additionally keep a local c
The story just broke earlier this year how a casino hotel "smart
thermometer" in the fish tank was used as a backdoor to attack the rest
of their network.
If a smart device running busybox is programmed to automatically check
for firmware updates, the designers might expect HTTPS to be a valid
Denys Vlasenko wrote:
wget should work for common use cases.
Such as downloading sources of kernels, gcc and such.
From build scripts, not only by hand.
Without having to modify said scripts.
Your patch breaks that.
NAK.
I don't care that security people are upset.
They are paranoid, it's part
Denys,
Most common use case for https is to give some sort of guarantee that
you actually get what you think you get or that you get from who you
think you get it from. That is what most people expect when downloading
from https. If you don't care about verifying that, then the common use
case is
On 05/27/2018 11:58 AM, Eli Schwartz wrote:
> It's unacceptable that for something which you see as primarily useful
> in downloading very important source code, you simply don't care that
> the source code may be compromised by a MITMed attack.
> This is incredibly terrible logic, your cross-compi
On 05/26/2018 01:34 PM, Denys Vlasenko wrote:
> wget should work for common use cases.
> Such as downloading sources of kernels, gcc and such.
> From build scripts, not only by hand.
> Without having to modify said scripts.
> Your patch breaks that.
> NAK.
>
> I don't care that security people are
On Fri, May 25, 2018 at 12:50 AM, Jakub Jirutka wrote:
> Internal TLS code (FEATURE_WGET_HTTPS) does not implement validation
> of the server's certificate. It is documented in the code, but not
> even mentioned in the --help message, so users typically don't know
> about this behaviour. That's
On Sun, May 27, 2018 at 1:34 AM, Denys Vlasenko
wrote:
> wget should work for common use cases.
> Such as downloading sources of kernels, gcc and such.
> From build scripts, not only by hand.
> Without having to modify said scripts.
> Your patch breaks that.
> NAK.
>
> I don't care that security p
Good evening Denys,
I agree with you that this patch is unacceptable, I also agree that
everyone who is complaining about the situation should send patches, but
I strongly disagree that it is valid to break security to keep "common
use cases" working. Using security-techniques like https should ne
wget should work for common use cases.
Such as downloading sources of kernels, gcc and such.
From build scripts, not only by hand.
Without having to modify said scripts.
Your patch breaks that.
NAK.
I don't care that security people are upset.
They are paranoid, it's part of their profession.
It d
//config: If you still think this is unacceptable, send patches.
That’s exactly what I did.
http://lists.busybox.net/pipermail/busybox/2018-May/086444.html
Jakub
On 2018-05-26 17:54, Denys Vlasenko wrote:
On Sat, May 26, 2018 at 5:39 PM, wrote:
That's a crime against security!
Sa
On Sat, May 26, 2018 at 5:39 PM, wrote:
>>> That's a crime against security!
>>
>> Say what?
>
> That’s a hyperbole. The thing is that when you don’t verify the peer’s
> certificate, then you’re vulnerable to MitM attack with fake certificate
> injection. The whole SSL/TLS is totally useless in t
That's a crime against security!
Say what?
That’s a hyperbole. The thing is that when you don’t verify the peer’s
certificate, then you’re vulnerable to MitM attack with fake certificate
injection. The whole SSL/TLS is totally useless in that moment. It’s
more or less like putting the door’
On Thu, May 24, 2018 at 6:50 PM, Jakub Jirutka wrote:
> Internal TLS code (FEATURE_WGET_HTTPS) does not implement validation
> of the server's certificate. It is documented in the code, but not
> even mentioned in the --help message, so users typically don't know
> about this behaviour.
> That'
17 matches
Mail list logo