Re: git: f68ee0e7a1e8 - main - shar: add a deprecation notice

From: Kyle Evans <kevans_at_FreeBSD.org>
Date: Thu, 02 Jan 2025 16:48:08 UTC
On 1/2/25 10:29, Cy Schubert wrote:
> In message <9156305a-c929-48cf-9619-e23bec6f6897@FreeBSD.org>, Kyle Evans
> write
> s:
>> On 1/1/25 21:14, Cy Schubert wrote:
>>> In message <b86bb422-29b7-470d-9249-7249e5df718e@FreeBSD.org>, Kyle Evans
>>> write
>>> s:
>>>> On 1/1/25 20:53, Cy Schubert wrote:
>>>>> In message <202501020215.5022FeQP042716@gitrepo.freebsd.org>, Kyle Evans
>>>>> writes
>>>>> :
>>>>>> The branch main has been updated by kevans:
>>>>>>
>>>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=f68ee0e7a1e8732f725cad4ac70
>> 8e
>>>> c49
>>>>>> 093782d4
>>>>>>
>>>>>> commit f68ee0e7a1e8732f725cad4ac708ec49093782d4
>>>>>> Author:     Kyle Evans <kevans@FreeBSD.org>
>>>>>> AuthorDate: 2025-01-02 02:15:36 +0000
>>>>>> Commit:     Kyle Evans <kevans@FreeBSD.org>
>>>>>> CommitDate: 2025-01-02 02:15:36 +0000
>>>>>>
>>>>>>        shar: add a deprecation notice
>>>>>>        
>>>>>>        The shar(1) program is simple, but the fundamental idea of a sh ar
>> chi
>>>> ve
>>>>>>        is risky at best and one that we probably shouldn't be promoting a
>> s
>>>>>>        prominently as a program in $PATH and a manpage.  Let's deprecate
>> and
>>>>>>        remove it, since the same functionality can easily be found in
>>>>>>        tar(1) instead.
>>>>>>        
>>>>>>        Reviewed by:    emaste, philip
>>>>>>        Reviewed by:    allanjude, brooks, delphij, des, imp, rpokala (pre
>> vio
>>>> us)
>>>>>>        MFC after:      3 days
>>>>>>        Differential Revision:  https://reviews.freebsd.org/D48130
>>>>>> ---
>>>>>>     usr.bin/shar/shar.1 | 14 +++++++++++++-
>>>>>>     1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/usr.bin/shar/shar.1 b/usr.bin/shar/shar.1
>>>>>> index 903f937491dc..df97021b1bba 100644
>>>>>> --- a/usr.bin/shar/shar.1
>>>>>> +++ b/usr.bin/shar/shar.1
>>>>>> @@ -25,12 +25,24 @@
>>>>>>     .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILI
>> TY
>>>> OF
>>>>>>     .\" SUCH DAMAGE.
>>>>>>     .\"
>>>>>> -.Dd January 31, 2019
>>>>>> +.Dd January 1, 2025
>>>>>>     .Dt SHAR 1
>>>>>>     .Os
>>>>>>     .Sh NAME
>>>>>>     .Nm shar
>>>>>>     .Nd create a shell archive of files
>>>>>> +.Sh DEPRECATION NOTICE
>>>>>> +.Nm
>>>>>> +is obsolete and may not be present in
>>>>>> +.Fx 15
>>>>>> +and later.
>>>>>> +Because shell archives are simultaneously data and code and are typical
>> ly
>>>>>> +interpreted by
>>>>>> +.Xr sh 1 ,
>>>>>> +they can easily be trojan-horsed and pose a significant security risk t
>> o
>>>> use
>>>>>> rs.
>>>>>> +The
>>>>>> +.Xr tar 1
>>>>>> +utility can still produce shar encodings of files if needed.
>>>>>>     .Sh SYNOPSIS
>>>>>>     .Nm
>>>>>>     .Ar
>>>>>>
>>>>>
>>>>> We should probably point to the new port or the GNU variant in ports.
>>>>>
>>>>
>>>> Oh, sorry, I didn't realize you had gone ahead with the port.  I
>>>> wouldn't normally recommend a GNU variant, would you be OK with
>>>> something like:
>>>>
>>>> diff --git a/usr.bin/shar/shar.1 b/usr.bin/shar/shar.1
>>>> index df97021b1bba..6beb1e84ceab 100644
>>>> --- a/usr.bin/shar/shar.1
>>>> +++ b/usr.bin/shar/shar.1
>>>> @@ -43,6 +43,11 @@ they can easily be trojan-horsed and pose a
>>>> significant security risk to users.
>>>>     The
>>>>     .Xr tar 1
>>>>     utility can still produce shar encodings of files if needed.
>>>> +The
>>>> +.Pa sysutils/freebsd-shar
>>>> +port has been created to maintain this version of
>>>> +.Nm
>>>> +past its deprecation in base.
>>>>     .Sh SYNOPSIS
>>>>     .Nm
>>>>     .Ar
>>>>
>>>> ?
>>>
>>> Yeah, that should do it.
>>>
>>
>> Pushed as 2832af7b4ea256b18ef4dbf2ff97a50765f0609a, thanks.  I'll drop
>> another pointer to the port in UPDATING when it comes time to remove it.
>>
>> Thanks,
>>
>> Kyle Evans
> 
> As an FYI, I'll patch shar with a couple of patches from NetBSD. They will
> also be applied to the upstream (my github) repo for the port as well. I'll
> probably push these sometime next week.
> 

Sounds good, thanks.  I don't have immediate plans for a timeline on 
removal beyond "probably before 15", but it would certainly be after 
packages are published for a version of the port that you're happy with 
to provide a smooth transition.

Thanks,

Kyle Evans