From owner-freebsd-current@freebsd.org Thu Sep 17 17:59:35 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 4A94D3E865A for ; Thu, 17 Sep 2020 17:59:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 4Bsl921XD4z4Mjt; Thu, 17 Sep 2020 17:59:34 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1kIyBo-00054u-SI; Thu, 17 Sep 2020 20:59:24 +0300 Date: Thu, 17 Sep 2020 20:59:24 +0300 From: Slawa Olhovchenkov To: Cy Schubert Cc: Daniel Eischen , Maxim Sobolev , Ed Maste , FreeBSD Current Subject: Re: Deprecating ftpd in the FreeBSD base system? Message-ID: <20200917175924.GC2033@zxy.spb.ru> References: <451538DE-9427-4584-987B-8E4AA26C2981@freebsd.org> <202009171555.08HFtQlB010471@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202009171555.08HFtQlB010471@slippy.cwsent.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 4Bsl921XD4z4Mjt X-Spamd-Bar: + X-Spamd-Result: default: False [1.23 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.34)[-0.341]; NEURAL_HAM_LONG(-0.01)[-0.013]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.32)[-0.317]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; RCVD_COUNT_TWO(0.00)[2]; 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 17:59:35 -0000 On Thu, Sep 17, 2020 at 08:55:26AM -0700, Cy Schubert wrote: > 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. And for install plugin from ports use HTTP AWS API installed from ports?