From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.devel 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 Message-ID: <87fu0jrvye.fsf@gmail.com> References: <20180714170806.8972.58581@vcs0.savannah.gnu.org> <20180714170809.C3A3920456@vcs0.savannah.gnu.org> <87o9f84t89.fsf@gmail.com> <4C758D1D-7C3A-425A-852F-75E03C779E01@gmail.com> <87va9fs3ro.fsf@gmail.com> <83tvoz8bus.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1531758088 1650 195.159.176.226 (16 Jul 2018 16:21:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2018 16:21:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 16 18:21:24 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ff6FX-0000Jx-ST for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 18:21:23 +0200 Original-Received: from localhost ([::1]:52765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff6He-0003KO-Mr for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2018 12:23:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff6HY-0003KJ-4p for emacs-devel@gnu.org; Mon, 16 Jul 2018 12:23:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ff6HU-0005y6-V7 for emacs-devel@gnu.org; Mon, 16 Jul 2018 12:23:28 -0400 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:52814) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ff6HU-0005xo-NU; Mon, 16 Jul 2018 12:23:24 -0400 Original-Received: by mail-wm0-x22b.google.com with SMTP id o11-v6so9791717wmh.2; Mon, 16 Jul 2018 09:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-followup-to:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=Foc5JV8LGUy11bAybkTEeSTZpWRG1Fz0//KDyCEcAA4=; b=oAefuDiQuNlmTJRyQsTZfaYARZHLq6S9d4SWbIDlGUn/cnKvp/opqWHOEqz5oM2ykb DA0BEu6prbLgJG5xGKQbS8LvRx+C8+sQyaSIasc7NJKY9k77by8FCSJXxYbWAzxlm1Pw PI5YLQwW1gXQvtopyAH7Y1JYWYTQz74G6SAU7jC5Qo2NymSFL06/FiJJbJlT+pzXDjiX h2jKKXNgk/r6Y31ZKU+zTpw0ahkmNFlaRh2cE3xLExp6WpVIAK3lloH67y9lcY37ngDi c8fwX5a//wKg4z6Cc6wXiRNvACA5F3dFLa7eYCt0xwGkGdzWTwVudqgVrs3Ed+k8TZAO BBDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-followup-to :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=Foc5JV8LGUy11bAybkTEeSTZpWRG1Fz0//KDyCEcAA4=; b=B5nl0BPOSQYCuyyedIZcQ2HA3F/I34ApRz4shvHaWloj7+in94+HTQNiQIWAzJde2d bPLzOZ/tYyw3bPZxnyNjBJ/sHCR9I+zV7mk1sqNJTeOYxDx3VWcu6aKUD9zZGLfNe+XS GwW+a8zPh4xHNRBE2z3siYNBTpb7wuY5Ya5HO0zC9bD9nIGISc030ovMHCXdJSJ/YH+4 07Lh12XMKyd6l5WX9wja9VHejBKqta2NrNmverSpGWftNiVzYDVMib87GD5sUpgXi+ik 5OkE7vXAiqtHXBXjlFtZmOeH4HMxpE0nLs2V38YnDKu5vabyEldTnQeXiDMgtlb05hbO djLw== X-Gm-Message-State: AOUpUlFZeL+ag93opdaNHdA21Yc8kUJjR14GRuFue10ppzGDHkuo6cny m+41h0l2x1jsF/KQoIeV7WMd1QNl X-Google-Smtp-Source: AAOMgpdSJeoZXxFHuBgs5dI63RquatpZ1YupOvPMvBrTQ/2y00ggAwT3QTDzztfdEhasBu4zlq8Sww== X-Received: by 2002:a1c:5fc1:: with SMTP id t184-v6mr9977638wmb.8.1531758203148; Mon, 16 Jul 2018 09:23:23 -0700 (PDT) Original-Received: from rpluim (vav06-1-78-207-202-134.fbx.proxad.net. [78.207.202.134]) by smtp.gmail.com with ESMTPSA id p184-v6sm12729583wmp.31.2018.07.16.09.23.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 16 Jul 2018 09:23:22 -0700 (PDT) Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <83tvoz8bus.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 16 Jul 2018 18:00:11 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:227464 Archived-At: Eli Zaretskii writes: >> From: Robert Pluim >> Date: Mon, 16 Jul 2018 15:34:35 +0200 >> Cc: emacs-devel@gnu.org >>=20 >> Eli, I see there=CA=BCs 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=CA=BCm waiting for Jimmy to tell me if the format works for him, then I=CA=BCll 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 =3D AF_INET; >> +#ifdef AF_INET6 >> + if (EQ (family, Qipv6)) >> + hints.ai_family =3D AF_INET6; >> +#endif > > Should we signal an error if 'ipv6' is requested on a system that > doesn't support that? I=CA=BCd be more inclined to return nil in that case. The effect is the same, and the caller doesn=CA=BCt need to do redundant error handling. >> + ret =3D 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=CA=BCt 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