[Top][All Lists]

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

Re: Network security manager

From: Ted Zlatanov
Subject: Re: Network security manager
Date: Tue, 18 Nov 2014 10:58:46 -0500
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

On Tue, 18 Nov 2014 16:29:30 +0100 Lars Magne Ingebrigtsen <address@hidden> 

LMI> Ted Zlatanov <address@hidden> writes:
TH> incidentally, does Emacs check the cipher mode of the connection
TH> itself (I'm assuming this warning pertains to the certificate
TH> itself, not the connection encryption).
>> No, after establishing the connection we don't check its properties.  In
>> many cases, depending on the priority string, it could be very different
>> from what we expected IIUC, so this is neither simple nor very useful.

LMI> Well, yes, that's exactly what we do.  Open the connection, and then
LMI> check the properties.  >"?

You're checking the certificate, but not the cipher mode or anything
else that was negotiated.  I think that's what Toke meant.

>> Also, would you like to integrate your TOFU patch with the new nsm branch?

LMI> The NSM does TOFU.  No patch necessary.


>> I'm testing and using the NSM.  The number one thing it needs is a
>> `tabulated-list-mode' interface to review all the entries.  See also my
>> note about the GPG key management functionality, which I think naturally
>> fits in the NSM.

LMI> Sure...  but since there's almost nothing human-readable (or something a
LMI> machine can transform into something human-readable), I'm not quite sure
LMI> what it should display...

The list of explicitly saved security exceptions.

LMI> I mean, I can see a user wanting to say to Emacs "delete everything you
LMI> know about me contacting news.gmane.org", but there's no real way to
LMI> match that up to the entries in the file unless you also know the port
LMI> number/service name used.

True, but I really don't see the harm in saving those in cleartext. Like
I said, I would use a .gpg file if I was worried about leaking that
data. With the current approach I think you'll see two problems:

1) cruft will accumulate, since you don't know what's what

2) when servers change names or ports, you don't know what to remove


reply via email to

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