unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: netsec 682578f 4/6: Add option to bypass NSM TLS checks on local networks
Date: Mon, 16 Jul 2018 18:23:21 +0200	[thread overview]
Message-ID: <87fu0jrvye.fsf@gmail.com> (raw)
In-Reply-To: <83tvoz8bus.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 16 Jul 2018 18:00:11 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Mon, 16 Jul 2018 15:34:35 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> Eli, I see thereʼs a sys_getaddrinfo in w32.c, is something needed
>> to get emacs to use that on MS-Windows?
>
> No, you don't need anything special.  nt/inc/socket.h redirects
> getaddrinfo into sys_getaddrinfo, and all our C sources see the
> redirection.

Thanks. I always forget how the nt stuff works.

>> +DEFUN ("get-address-info", Fget_address_info, Sget_address_info, 1, 2, 0,
>> +       doc: /* Look up ip address info of NAME.
>> +Optional parameter FAMILY controls whether to look up IPv4 or IPv6
>> +addresses.  The default of nil means look up both, symbol `ipv4' means
>> +IPv4 only, symbol `ipv6' mean IPv6 only.  Returns a list of addresses,
>> +or nil if none were found.  */)
>
> This doc string doesn't tell that each address is a vector or a
> string.

Yes. Iʼm waiting for Jimmy to tell me if the format works for him,
then Iʼll document whatever we end up with (and it can currently only
return a vector, and includes a port, which is probably not needed).

>> +  if (EQ (family, Qipv4))
>> +    hints.ai_family = AF_INET;
>> +#ifdef AF_INET6
>> +  if (EQ (family, Qipv6))
>> +    hints.ai_family = AF_INET6;
>> +#endif
>
> Should we signal an error if 'ipv6' is requested on a system that
> doesn't support that?

Iʼd be more inclined to return nil in that case. The effect is the
same, and the caller doesnʼt need to do redundant error handling.

>> +  ret = getaddrinfo (SSDATA (name), NULL, &hints, &res);
>
> You should encode NAME (using ENCODE_SYSTEM), because it could include
> non-ASCII characters.  In general, any Lisp string should be encoded
> before you can pass its data to a C library function.
>

My understanding is that this API only supports ASCII anyway. For
internationalized domain names you'd need to use puny-code (and we
donʼt currently use ENCODE_SYSTEM when calling getaddrinfo elsewhere).

> Thanks.
>
> P.S. This needs a NEWS entry, at the very least, and perhaps also an
> update for the ELisp manual.

Both, for sure.

Robert



  parent reply	other threads:[~2018-07-16 16:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180714170806.8972.58581@vcs0.savannah.gnu.org>
     [not found] ` <20180714170809.C3A3920456@vcs0.savannah.gnu.org>
2018-07-15 11:46   ` netsec 682578f 4/6: Add option to bypass NSM TLS checks on local networks Robert Pluim
2018-07-15 15:34     ` Jimmy Yuen Ho Wong
2018-07-16 13:34       ` Robert Pluim
2018-07-16 15:00         ` Eli Zaretskii
2018-07-16 15:24           ` Jimmy Yuen Ho Wong
2018-07-16 17:59             ` Eli Zaretskii
2018-07-16 16:23           ` Robert Pluim [this message]
2018-07-16 17:16             ` Jimmy Yuen Ho Wong
2018-07-16 17:46               ` Robert Pluim
2018-07-16 18:09             ` Eli Zaretskii
2018-07-17 10:09               ` Robert Pluim
2018-07-17 15:50                 ` Eli Zaretskii
2018-07-17 15:53                   ` Robert Pluim
2018-07-17 16:17                     ` Robert Pluim
2018-07-17 17:15                       ` Eli Zaretskii
2018-07-17 18:00                         ` Robert Pluim
2018-07-16 15:31         ` Jimmy Yuen Ho Wong
2018-07-16 16:14           ` Stefan Monnier
2018-07-16 16:36             ` Robert Pluim
2018-07-16 18:11               ` Eli Zaretskii
2018-07-16 18:24               ` Stefan Monnier
2018-07-16 17:06         ` Andy Moreton
2018-07-16 17:15           ` Jimmy Yuen Ho Wong
2018-07-16 17:48         ` Paul Eggert
2018-07-17  5:56           ` Robert Pluim
2018-07-17 18:07             ` Robert Pluim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fu0jrvye.fsf@gmail.com \
    --to=rpluim@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).