Drop unrar from tree?

[diizzyy]

@Noltari
Trying to arrange some house cleaning and I'm looking at one of your ports which hasn't seen any updates for a couple of releases and time (about a year) which is utils/unrar.

Do you have any intention to maintain this or can we drop this as bsdtar (in tree) handles rar?
I'm well aware that bsdtar is larger but it's by no means huge and having less packages that are outdated is for the better overall.

Thanks for all the work you've put into the project!

[Wolfie713]

Just to point out a couple of things...

1. Just because it hasn't been updated, it doesn't mean that it's been forgotten or anything. It could be that it isn't outdated.

2. Some people may have scripts that call on 'unrar' specifically and even rely on the output it provides.

3. It's not installed into your router unless you choose to install it. At least, it's not installed on mine, and I haven't uninstalled anything. If you didn't install it directly, then another package you installed may have installed it as a requirement.

I'm all for dropping packages that have no use, but shouldn't jump the gun on things.

[diizzyy]

Sure, but going all "what if" means that we can never drop anything and I hardly think that shipping with outdated and somewhat broken software benefits anyone especially when you have alternatives available.

[Wolfie713]

I didn't go "what if" on it. My first point is very valid, as 'unrar' may not need any updates. The second point, while not critical, is also valid. People could be using scripts that call on it. Of course, if unrar were removed as an available package, they would have to adjust for it, so I wouldn't call it a critical reason to keep it, I only pointed it out as something to consider. After all, just because YOU don't believe it's of any use, doesn't mean others feel the same.

On to the third point though, you mentioned you were doing house cleaning and came across unrar. Do you remember installing it? If not, then perhaps another package that you installed required it. By removing a dependency from the list of packages, problems can and will occur. It's easy to say, "Hey remove this since it hasn't been updated and I prefer to use something else..." But it's not as simple as that when it comes to things to consider before removing a package completely.

You mention 'somewhat broken' software. How is it broken? Have you reported the issues? Are the issues serious enough that they definitely need addressing?

[diizzyy]

Unfortunately your first point kinda leads into the whole lets keep everything because it may be used somewhere and somehow. In this case it's really hard to tell what's new as there is zero documentation (as far as I can tell) available and/or commit logs and it's for sure updated several times between. I guess WinRAR's changelog may give you an idea but the version numbers doesn't really add up. That said, guess I'm the only one who is concerned about the state of the package tree overall...

[Wolfie713]

No, you're not. But again, just because you believe it's useless (summarizing your point, I know you didn't say it's useless), it doesn't mean that it is. Have you tried to figure out what package you installed that also installed unrar onto your router?

[diizzyy]

Nothing installs unrar, there are no deps at all...

[thess]

I vote to keep it.

[Wolfie713]

If there are no deps on it and if it's not being updated despite a need for it, then I would say to make a middle-man unrar that basically takes unrar options and translates them to use another program, at least for a few releases. Sort of phase it out.

[diizzyy]

My point is that everytime this is brought up, there's always the argument that someone might use it. No one is actually picking stuff up which leads to just a bunch of packages that are heavily outdated and that's about it. It's even been discussed here but looking at uscan reports it kinda shows the direction of things.. #153 actually touches this however doesn't really seem to get applied to anything. Creating some kind of "alias/alternative"-list for opkg I guess would be an option but it could also get kinda ugly quickly depending on how strict you're going to be in defining alternatives.

[diizzyy]

To be clear, I'm all for voting or something but solely claiming that X may be used by someone doesn't have much weight to it in the end especially if it's not maintained. That applies to packages in general....

[Wolfie713]

The purpose of the middle-man unrar would be to give people time to change their scripts. Also, time for people to uncover any other programs that people may be installing (not from the repository) that require unrar.

[diizzyy]

buildroot/buildroot@3225997#diff-efe90a8e604a7c840e88d03a67f6b7d8
...

[diizzyy]

Lost interest in cleanups

[champtar]

Hi @diizzyy
I think the only way forward is to have build / download / install statistics, because small binaries like unrar are not really the problem IMO, it's more big softs that take most of the build time that are

[diizzyy]

@champtar
It's unmaintained, does have security issues (known CVEs), that my main beef.

[thess]

Looks like there are patches available in the Debian repos -- check it out.

[Wolfie713]

@diizzyy
Hey, while we're at it, how about if we remove some other packages. I don't use PBX, so the Astrick (and related) packages could be removed. After all, since I don't use them, then obviously no one else uses them.

Okay being serious, that's how you're coming off about it. I can understand having concerns about it, but just calling for it to be dropped without trying to account for any issues that can be caused by its removal is careless. If you're really interested in having it removed (if it's not going to be properly maintained), then offer solutions rather than issues.

[diizzyy]

@FangsMcWolf
I have no idea what you're talking about, it's actively maintained?
https://github.com/openwrt/telephony/commits/master/net
Feel free to chip in, there's obviously need for contributions... ;-)

[dangowrt]

If you're really interested in having it removed (if it's not going to be properly maintained), then offer solutions rather than issues.

Such as using bsdtar...? Not sure whether it supports multi-volume or encrypted RAR archives... Has anyone ever tried?

[Wolfie713]

You obviously missed the point. I wasn't claiming that Astrick isn't actively maintained. I was using it to you an example of how you are approaching it. You think that just because you aren't using it, that no one else is using it. You think that anyone with a script that relies on it isn't a valid reason to consider keeping it. Yet, you haven't offered any solutions to keep things from falling apart with the removal of a package.

If a script calls on 'unrar' and it relies on the output being in a certain format, then how is saying "well there's bsdtar" a solution? It's not, it's creating multiple issues, the first of which is that it would fail to run unrar since it wouldn't be available anymore. Add a link to bsdtar you say? Output would still mess it up. That's not even consider the different command line options.

Offer solutions, not issues.

[dangowrt]

While at first I also thought "why remove something which works and may be used by folkds?", following up I now see there is an actual issue here which should be handled:
According to @diizzyy there are known vulnerabilities and upstream as well as our local package seems abandoned.
The usual procedure is to move the package to the https://github.com/openwrt/packages-abandoned feed and add a warning referencing the known vulnerabilities. We never cared about breakage of out-of-tree third party stuff in such situations, it would be impossible to achieve. If people want to have a standing in terms of compatibility with their software they should add it to the appropriate feeds -- I can't see any user of unrar (except for maybe Midnight Commander...) there.

If you really feel that this would result in catastrophic events when carried out all of a sudden, maybe we add (DEPRECATED) to the package title for a while before removing it.

[diizzyy]

@dangowrt
Thanks for your input

Please keep this closed and re-open it with another owner however.

[Wolfie713]

maybe we add (DEPRECATED) to the package title for a while before removing it.

Sounds like a win/lose to me. Win because of the notice prior to moving (with a warning afterwards), lose for anyone who never bothers to pay attention to the fact that they need to find alternatives or advocate the continued support of it.

In short, sounds good to me.

[dangowrt]

@Noltari didn't show up for quite some time now. Apparently there even is a newer upstream version available which fixes CVE-2012-6706, CVE-2017-12942, CVE-2017-12941,CVE-2017-12940 and CVE-2017-12938 . Just need to find someone to take over package maintainership or dump it on packages-abandoned. If there are actual users one of them should step up as the new maintainer.

[thess]

I'm willing to take this one on (and a couple of others that might be orphaned without a maintainer). Don't expect me to be closely tracking CVE's, and updates as some others do, but I will test and approve updates. Give me a week or so to get the updates going. Or... anybody else volunteering?