From nobody Sat Dec 21 05:24:15 2024 X-Original-To: freebsd-arch@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 4YFXlk0BCKz5DyYK for ; Sat, 21 Dec 2024 05:24:34 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YFXlj2wCwz4Qs6; Sat, 21 Dec 2024 05:24:32 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4BL5OG1s056050; Sat, 21 Dec 2024 14:24:17 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1734758658; bh=WzR+idkgz1u2fEzANm1lyMZ33KJoVL88iZVEXcUQOd8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=l0sRzygKsR4h7d3VU3MUpemIy2Y6hsFI9Wn0zHwmvDa9JjKfA+oWppUhsfFuuqB5F nGmwBMz4DLBDOXvXdl+qiC2d0TXnumtfTSp5AE3ymHrcvBur9dwe4sJafw9g7jXZoG 8WvXRkeIxFzmcY/dGje1s7mhcaXSz5gO4K/AEKXI= Date: Sat, 21 Dec 2024 14:24:15 +0900 From: Tomoaki AOKI To: Cy Schubert Cc: Kyle Evans , "Rodney W. Grimes" , Robert Clausecker , freebsd-arch@FreeBSD.org Subject: Re: Removing shar(1) Message-Id: <20241221142415.250e3cd675b3e3f740684f6c@dec.sakura.ne.jp> In-Reply-To: <20241221035543.E9BA1447@slippy.cwsent.com> References: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net> <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org> <20241221035543.E9BA1447@slippy.cwsent.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4YFXlj2wCwz4Qs6 X-Spamd-Bar: ---- On Fri, 20 Dec 2024 19:55:43 -0800 Cy Schubert wrote: > In message <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org>, Kyle Evans > write > s: > > On 12/20/24 09:20, Rodney W. Grimes wrote: > > >> On 12/20/24 08:56, Rodney W. Grimes wrote: > > >>>> On 12/18/24 05:04, Robert Clausecker wrote: > > >>>>> Hi Kyle, > > >>>>> > > >>>>> With shar no longer being recommended for the submission of new ports, > > >>>>> I see no objection to removing this feature. However, tar(1) should > > >>>>> keep the functionality. > > >>>>> > > >>>> > > >>>> I make no proposal to remove it from tar- that'd be really annoying > > >>>> after recommending people use tar(1) instead both here and in the patch > > >>>> below. > > >>> > > >>> Isnt this a bit oxy-moronic? Remove shar, yet point people to the exact > > >>> same behavior in another binary shipped with the system? Your basically > > >>> leaving the foot shooting neck hanging rope in the system and doing zip > > >>> to remove the fact this fucntionality should NOT be removed. > > >>> > > >> > > >> No, because the pointer is gone once shar(1) is gone. The functionality > > >> will not removed, just the convenient front-end. You still have tar(1). > > > > > > If you dont remove the functionality the sum game is zero improvement. > > > You have done NOTHING but remove a pointer (shar) to a function. > > > In my book that is security through obscurity and just silly. > > > If the shar create function needs to go because of security it nneds > > > to go from ALL places. > > > > > > > I'm not arguing that the functionality needs to go for security reasons, > > I'm arguing that we need to stop promoting the functionality as > > prominently as it is today. I don't have any problem with people using > > it for their own purposes, or with third parties that agree to it. I > > have problems with people that see shar(1) as a good option because it's > > a first-class citizen along with the likes of cpio/tar/pax without > > considering the implications for the user of the archive. > > shar(1) should never be considered by people as a replacement of cpio, tar > or zip. But it can do what the other tools cannot. For example, at $JOB we > manage servers which do not have direct access to, i.e. no ssh or other > direct network access. We use a virtual Windows desktop (called a Secure > Access Gateway -- SAG - or Third Party Gateway, 3PG) in a secure network > between our workstations and the servers. Getting a tarball from point A to > point B is nearly impossible (except through a weird and lengthy path of > shares). I will create a shar file of a directory tree, copy (cut & paste) > it from my FreeBSD VM to a notepad and copy (cut & paste) that into a PuTTY > session on the SAG. Then run it on the server within the secure network, > extracting the files to enable me to perform post change QA, among other > things. You can't cut & paste a tarball but you can cut & paste a shar file. > > These networks are designed in such a way to make sure people can't > infiltrate or exfiltrate data to/from the machines within the secure > network. It's a kludgey workaround but it works. Wouldn't uuencode (1) / uudecode (1) or base64 usable for the purpose, without making text-encoded data executable script? BTW, in Japan, a software called "ish" was quite widely used on ancient BBS serivces. (Was relatively robust for transfer errors.) https://ja.wikipedia.org/wiki/Ish Unfortunately, the page above are in Japanese only (no other language versions). But found Unix version on ports. https://www.freshports.org/converters/ish/ and (maybe) its variant https://www.freshports.org/converters/aish/ Both are still build fine on stable/14, amd64. And tested the former using /usr/src/UPDATING as a sample, 87557 bytes is encoded to 120479 bytes, restored fine. Command lines (at my home directory): For encode: ish /usr/src/UPDATING -s -u -n -f=UPDATING.ish For decoding: ish UPDATING.ish -r For reading help: ish -help > > >>> Your basically breaking things without any increase in security. > > >>> > > >>> FIRM NO here. > > >>> > > >>>> > > >>>>> We should consider replacing shar(1) by an implementation that just cal > > ls > > >>>>> into tar(1) to do its job. > > >>>>> > > >>>> > > >>>> Strongly prefer not to if we can avoid it (I'm not seeing any arguments > > >>>> that we really need it to be a first-class citizen); I view that as > > >>>> promoting functionality that we shouldn't be encouraging, along with > > >>>> providing a manpage. > > >>> > > >>> Basically your just making it inconvinvient to get to the rope for those > > >>> that do know how to not hang themselves. > > >>> > > >> > > >> The rope is also great for hanging others, and it'd be great to shove it > > >> behind all of the better tools in the shed. > > > > > > Obscurity process is NOT what BSD does. > > > > > >> What actual reasoning do you have for keeping shar(1) specifically? > > > > > > I didnt site any. I sited that your removing half of the problem is > > > not a reasonable approach. Either remove it totally or do not touch > > > it at all. > > > > > >> Your entire argument so far boils down to "You shouldn't remove it," > > > > > > Wow, really, thats how you read it. > > > > > > > Feel free to explain it more clearly, then. > > > > Thanks, > > > > Kyle Evans > > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 -- Tomoaki AOKI