From owner-freebsd-current@freebsd.org Sun Sep 20 12:58:19 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 5B3B53DFFEF for ; Sun, 20 Sep 2020 12:58:19 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 4BvSL22Hysz4Vmj for ; Sun, 20 Sep 2020 12:58:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (115-38-187-204.shizuoka1.commufa.jp [115.38.187.204]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id 08KCwBGN042351; Sun, 20 Sep 2020 21:58:11 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 20 Sep 2020 21:58:11 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: Deprecating ftpd in the FreeBSD base system? Message-Id: <20200920215811.090fb1979fbbef60904f3d35@dec.sakura.ne.jp> In-Reply-To: <202009171555.08HFtQlB010471@slippy.cwsent.com> References: <451538DE-9427-4584-987B-8E4AA26C2981@freebsd.org> <202009171555.08HFtQlB010471@slippy.cwsent.com> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BvSL22Hysz4Vmj X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.14 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.546]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[115.38.187.204:received]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:9370, ipnet:210.188.224.0/19, country:JP]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.60)[-0.601]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.88)[0.885]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; 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: Sun, 20 Sep 2020 12:58:19 -0000 On Thu, 17 Sep 2020 08:55:26 -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. Looks reasonable for me, if all plugin to fetch base distribution and pkgbase is guaranteed to be incorporated in base and install images. No objection about removing ftpd and ftp client from base, if drop-in (at least having enough compatibility with configuration files/envs) alternatives are in ports. Regards. > 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. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Tomoaki AOKI