From owner-freebsd-current@freebsd.org Thu Sep 17 15:55:32 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 09D3A3E5190 for ; Thu, 17 Sep 2020 15:55:32 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BshPv0xGtz4Cdk; Thu, 17 Sep 2020 15:55:30 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id IwFrkSXvXTWWpIwFsk4nPR; Thu, 17 Sep 2020 09:55:29 -0600 X-Authority-Analysis: v=2.4 cv=EcV2/NqC c=1 sm=1 tr=0 ts=5f6386f1 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=xqWC_Br6kY4A:10 a=8nJEP1OIZ-IA:10 a=reM5J-MqmosA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=NC-6p4tjizZu4w5hGJYA:9 a=wPNLvfGTeEIA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 5DB73F51; Thu, 17 Sep 2020 08:55:26 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 08HFtQlB010471; Thu, 17 Sep 2020 08:55:26 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202009171555.08HFtQlB010471@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Daniel Eischen cc: Maxim Sobolev , Cy Schubert , Ed Maste , FreeBSD Current Subject: Re: Deprecating ftpd in the FreeBSD base system? In-reply-to: <451538DE-9427-4584-987B-8E4AA26C2981@freebsd.org> References: <451538DE-9427-4584-987B-8E4AA26C2981@freebsd.org> Comments: In-reply-to Daniel Eischen message dated "Thu, 17 Sep 2020 11:36:55 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 17 Sep 2020 08:55:26 -0700 X-CMAE-Envelope: MS4xfIrCQ7IBofIzgpKb44NL+D/kBbDycWV89iOI5dkZZHxdflpT3pkJvpe+LMZt2MAJ7gBuNd47K8og3xOu/Sn94JqN9PTvMXmrtrqxDUIlv8mPA3X29SbL Ki7JcJ4mh2v/TC2WepfxQwtd8MQFRxrPj82PS/O5TKpUMKJ/eSGwpuqrZFdi9eTNcHA6rvYbjEyN0Uv9NKBog9CJe8YktzpHl/ED9Ma7NDW0DG2DXOKXtyYU vJNwb8rxzcdjVivdbLjbIhnZZTGsTN569oZhC+9MUdi4a0+uQl/XbTV2zaePCZiu X-Rspamd-Queue-Id: 4BshPv0xGtz4Cdk X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.24 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.59.134.12:from]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.24)[-0.237]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.125.17:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.88)[0.884]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.134.12:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.29)[0.291]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2020 15:55:32 -0000 In message <451538DE-9427-4584-987B-8E4AA26C2981@freebsd.org>, Daniel Eischen w rites: > > > > On Sep 17, 2020, at 11:20 AM, Maxim Sobolev wrote: > > > > Re: removing HTTP client please no!!! The current drive to "outlaw" HTTP > > coming from companies who see all world via web browser. Totally ignoring > > the fact that HTTP != HTTPS in particular in cases where reliability and > > lower complexity of the system takes precedence over on-the-wire protocol > > security. For example, many internal APIs of AWS EC2 are HTTP. > > Agree. And remember the mantra: tools, not policy. Since there are so many I'll pick this email to reply to. libfetch should be designed to call plugins. An https plugin, http plugin, ftp plugin, sftp plugin, and so on. New protocols are added as needed, preferably to ports before they are mainstream. Old protocols are removed and moved to ports. People who still need to use old protocols can install the port which plugs into libfetch. When a protocol becomes stale it's forgotten, no longer maintained and simply disappears into the ether. Given that pkgbase will become a reality at some point the line between base and ports will blur. I expect at some point some of what we see in base to simply become ports. As a developer of both base and ports, ports are much easier to maintain than importing into base. That's my vision. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few.