Re: The netsec thread

[Lars Ingebrigtsen]

Jimmy Yuen Ho Wong <address@hidden> writes:

>> Hm.  This seems like a good idea, but do we do this in other similar
>> variables?  And would perhaps regexp syntax make more sense than glob
>> syntax?
>
> Nah. This has already been looked at weeks ago, no need to
> over-engineer it further as I believe most people will think of glob
> when dealing with file paths. Besides, Emacs's regex isn't
> particularly nice unless Dan elects to retrofit PCRE into Emacs :P

.* isn't particularly difficult to write.  The question is whether Emacs
has a history of using regexps or globs in these kinds of variables -- I
don't know, but we should find out and use whatever is the Emacs way.

> The reason I need glob is IGTF's fetch-crl will put ~100s CRL PEM
> files into the file system, it's very cumbersome to specify them
> 1-by-1.

What's IGTF?

> Sorry I got lost in that giant thread.
> `gnutls_dh_set_prime_bits` is only deprecated on GnuTLS 3.1.7+. Are we
> dropping support for all version < 3.1.7? I'd be super happy to do it
> if that's the case and remove this var and the C code entirely.

Sure, but making it obsolete won't mean that we drop anything until,
like, 2023, and by then GnuTLS will be up to 5.4.13.

>> I don't think it makes much sense to talk about Snowden as if that's
>> something people are meant to understand.
>
> I'd be happy to, but I have no idea what 'low means anymore.

But mentioning "Snowden" doesn't really help, either.  I think most
people understands that "low security" means, like, not very secure, and
that's sufficient.

> 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.
>
> 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.

Robert objects, apparently.  And in any case, we can't just remove
settings like this: We make them obsolete for a few years if we want
them gone, and then we remove them.

>> Calling protocol checks "TLS" checks isn't future proof.  We've
>> already had one politically motivated name change (from SSL to TLS)
>> and we may have another.  And besides, many of these checks are also
>> valid for SSL, so it's just confusing.
>
> The TLS working group wasn't even willing to call TLS 1.3[1] TLS 2.0
> even when it's a major departure from it. I doubt we need to worry
> about extra work to change a name. YAGNI applies.

There is no extra work, because we shouldn't call the functions
something containing "tls".

> `nsm-tls-checks` is already a defcustom. It's super easy to add and
> remove a function. You can defun whatever name you want and add to it,
> and click [-] to remove. Using name mangling magic to fish out a check
> function makes defcustom super-awkward, and AFAIK, no other emacs core
> setting does it this way.

There's a bunch of "feature" setting that do not include full function
names.

>>> +(defun nsm-should-check (host)
>>> +  "Determines whether NSM should check for TLS problems for HOST.
>>> +
>>> +If `nsm-trust-local-network' is or returns non-nil, and if the
>>> +host address is a localhost address, a machine address, a direct
>>> +link or a private network address, this function returns
>>> +nil.  Non-nil otherwise."
>>
>> What do you mean by "machine address"?  The MAC address?  If you mean
>> IP address, it's perfectly valid to have TLS on a non-named IP
>> address.  1.0.0.1 does that for DNS over HTTPS last I heard, and
>> that's definitely a service you should verify, well, everything on.
>
> I mean 0.0.0.0/8. I'm not sure what the proper name is or if I even
> need to deal with it. What do you think?

If I understand correctly, 0.0.0.0/8 is only used when you don't really
have an IP address yet?  It doesn't sound like something that's a very
common use case, but if you cover that case, you'll have to call it
something other than "machine address".  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no