emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The netsec thread


From: Robert Pluim
Subject: Re: The netsec thread
Date: Mon, 23 Jul 2018 17:06:49 +0200

Jimmy Yuen Ho Wong <address@hidden> writes:

> On Mon, Jul 23, 2018 at 9:17 AM, Robert Pluim <address@hidden> wrote:
>> Jimmy Yuen Ho Wong <address@hidden> writes:
>>
>>>> And, as I've said before,
>>>> `paranoid' should stay.
>>>>
>>>
>>> Eli's use case has already been taken cared of by
>>> `nsm-trust-local-network`. `paranoid has been aliased to `high for
>>> backward compatibility.
>>>
>>> Robert do you still object to removing the `paranoid level? I've
>>> removed that prompt that askes for permission on every TLS connection
>>> due to crying-wolf effect.
>>
>> As Iʼve said before: I donʼt think many people need to be prompted
>> every time a TLS connection is set up from emacs to a host thatʼs
>> never been seen before, but I do, as I need to inspect the connection
>> parameters. Yes itʼs annoying, but I can live with self-imposed
>> annoyance.
>>
>
> Deep human packet inspector Robert :)

You donʼt want to know :-)

> Would you mind expanding a bit more on that need to inspect the
> connection params when you connect to a host you've never seen before?
> Currently the prompt doesn't really show you nearly enough to inspect
> connection params. I want to make sure your need is taken cared of
> properly (I'm contemplating an actual debug mode that prompts after
> every handshake) without introducing something into emacs that's so
> far only useful for one person.

The current info is enough for me. Anything else I need I can get from
packet captures.

Iʼm sure Lars added it for a reason, so there must be at least two of
us :-)

>>> If there isn't an objection from people who've found use for it, I'd
>>> really like to try without 'paranoid on master later before declaring
>>> it insufficient.
>>
>> I guess I could always add my own function into 'high, but Iʼd prefer
>> it if it was available by default.
>>
>
> I can alternatively resurrect that functionality as a separate check
> that's available but not added to any levels. You can add it to any
> level in Customize easy enough, but not so easy that a naive user
> would enable in the hope for more security. Would this be an
> acceptable compromise?

Yes, that would be fine

Thanks

Robert



reply via email to

[Prev in Thread] Current Thread [Next in Thread]