From nobody Sat Jan 22 16:12:45 2022 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 386A8197F6F1 for ; Sat, 22 Jan 2022 16:12:58 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from out0.migadu.com (out0.migadu.com [IPv6:2001:41d0:2:267::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jh1Vw5b1Jz4qf4 for ; Sat, 22 Jan 2022 16:12:56 +0000 (UTC) (envelope-from rcarter@pinyon.org) Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pinyon.org; s=key1; t=1642867968; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=avlNTYULAH1e08d8pkjnFOoaohey0J+1QzHPSdCOP0c=; b=JCma8IwX+rCxmcB4FkbGryH+PwMpLKb+SMj1dZzHdfSNbcJSFTqo9vCJI9sUp9qNC33NnE QZd+qprjMvnYDtSknvEn06QRvTKFmKukLYLEkTELfMXmZfhxiNRW8vUYg/oK/1tpu+MqjO 6EgXSk9nk65iDr+JRQW5Lxa7wbyojVk= Date: Sat, 22 Jan 2022 09:12:45 -0700 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Subject: Re: [HEADSUP] Deprecation of the ftp support in pkg Content-Language: en-US To: ports@freebsd.org References: <20220120142519.a5juoe75oppmnyby@aniel.nours.eu> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Russell L. Carter" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: pinyon.org X-Rspamd-Queue-Id: 4Jh1Vw5b1Jz4qf4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pinyon.org header.s=key1 header.b=JCma8IwX; dmarc=none; spf=pass (mx1.freebsd.org: domain of rcarter@pinyon.org designates 2001:41d0:2:267:: as permitted sender) smtp.mailfrom=rcarter@pinyon.org X-Spamd-Result: default: False [-3.55 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[pinyon.org:s=key1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:267::]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[pinyon.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.95)[-0.952]; DKIM_TRACE(0.00)[pinyon.org:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[ports]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:41d0:2:267:::from] X-ThisMailContainsUnwantedMimeParts: N On 1/22/22 01:35, Chris wrote: > On 2022-01-22 00:09, Baptiste Daroussin wrote: >> 22 janv. 2022 08:47:57 Chris : >> >>> On 2022-01-21 23:31, Baptiste Daroussin wrote: >>>> 22 janv. 2022 08:25:47 Chris : >>>> On 2022-01-20 06:25, Baptiste Daroussin wrote: >>>>>> Hello everyone, >>>>>> We plan to remove the support for fetching packages over ftp for >>>>>> the next >>>>>> releases of pkg (probably 1.18) >>>>> Must be a stupid question. But I'll ask anyway; Why the effort to >>>>> start removing transports? >>>> Because maintaining ftp has a cost, number of line of code, user >>>> support etc. >>>> if you have a strong reason to use ftp which >>>>>> cannot be fixed by switching to any other supported protocols like >>>>>> ssh or http, >>>>>> please do share. >>>>> Local repos. >>>>> ftp(1) is cheap. Other transports are (usually) more expensive. >>>>> >>> Thanks for taking the time to reply. >>> >>>> ssh which is supported is as cheap if not cheaper. >>> Technically that's incorrect. But as I see you've also rejected 2 >>> other requests. It's >>> clear that this topic is not actually up for debate. So I'll say no >>> more on the subject. >>>> Bapt >>> -- Chris >> >> It is up for debate, I have been told we need something in base to >> which I replied >> ssh is in base, so fill that requirement, you have said it is cheap no >> explaining >> what you call cheap, I say ssh is cheap as well as in not more >> complicated to >> configure, provide a path and here we are. >> >> You asked the reason for the removal I explained them, if ftp was free >> of cost I >> won t care about keeping it. >> >> So up to now noone gave an detailed argument in favour of ftp, which >> ssh or other >> transport cannot provide as well. > Fair enough. Sorry if I misunderstood. > I find it's less "housekeeping" to use ftp(1) setup through inetd(8) for > pkg repos, than > via ssh. I have no keys to care for. I am able to setup enormous > intranets w/o any key exchange. > ftp/inetd is in base. It seems "cheaper" both in resources as well as > setup / usage. This works > equally well for internets with the addition of an allow list (IP > addresses). Where anything > not in that list is dropped. If you want to let it all hang out without encryption infrastructure "inside" with base facilities only, another possibility is NFSv4 with, uh, "sys" authentication. I use this to follow a monthly stable + packages full rebuild and install/upgrade. I *love* it. Server: $ grep nfs /etc/rc.conf nfs_server_enable="YES" nfs_server_flags="-u -t -n 5" nfsv4_server_enable="YES" nfsuserd_enable="YES" nfsuserd_flags="-domain pinyon.lan" nfscbd_enable="YES" $ cat /etc/exports: / -maproot=root V4: / -network 10.0.0.0/16 Client: $ grep nfs /etc/rc.conf nfs_client_enable="YES" I use autofs and the following $ cat /etc/auto_master # Automounter master map, see auto_master(5) for details. /- autofs/bruno-nfs $ cat /etc/autofs/bruno-nfs # See auto_master(5). /mnt/bruno/packages -intr,nfsv4,minorversion=1 bruno:/export/packages /usr/src -intr,nfsv4,minorversion=1 bruno:/usr/src /usr/obj -intr,nfsv4,minorversion=1 bruno:/usr/obj /usr/ports -intr,nfsv4,minorversion=1 bruno:/usr/ports NFS is not without other, possibly deal-breaking aggravations. I have found it impossible to maintain without absolute consistency of UID/GID assignments across the intranet. Yeah, no, I couldn't get nfsuserd to fix that. I also consider SPOF kerberos or building an internal TLS cert infrastructure to be absurd wastes of my unpaid finite time. People getting paid would surely do one or the other. hth, Russell > > That's my take on it. > Thank you for your thoughtful reply. >> >> Bapt > -- Chris