El 3/8/22 a las 5:04, Steven M. Schweda escribió:
Greetings. A long time ago we received this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314832
And a long time ago, I made some changes to improve things. Sadly,
all that work went into UnZip 6.1, none into 6.0, and we still haven't
come close to releasing 6.1.
I believe that the new -k/--keep-permissions option appeared in this
(experimental/development) kit (and every one since):
http://antinode.info/ftp/info-zip/unzip610c09.zip
As you might guess from the changed-files list for that item in
History.610 in that kit, adding that option affected a bunch of files
specific to various operating systems, plus the documentation. Back
then, I was expecting some kind of 6.1 release to happen before death
overtook us all, so getting similar changes into any 6.0 code base did
not have a high priority. Obviously, 6.1 hasn't happened yet. None of
the relevant changes is tricky, it's all just more work.
Today I got the email below from Bruno Haible about the subject.
I'm going to upgrade to "normal" as he suggests. I wonder what are your
plans about this "umask" issue, if any.
I assume that the unreleased changes would resolve the complaint.
(If not, I'd like to hear about it.)
I was hoping to avoid putting more work into 6.0, but I can't offer a
realistic date for 6.1, so I'm not sure about "plans". Have you any
opinions?
Well, if the thing about umask is handled via a new command line option,
I think it's logical that it's kept in 6.1 only, especially if the
implementation involved touching the code in a lot of different places).
In general, new features are introduced in new versions. Old versions
should only have bug fixes and the like.
If you want to follow Bruno's suggestion that unzip is secure by default
(which I would support), I guess it would not be a lot of work, because,
once that there is already a new command line option for that, it would
be just a matter of reversing its logic (i.e. instead of
-k/--keep-permissions we could have another option which does the opposite).
[ btw: please keep the @bugs.debian.org address in the CC so that this
conversation may be read in the Debian BTS ].
Thanks.
