• about shell scripts having X>&Y in place of X&>Y

    From Patrice Duroux@21:1/5 to All on Tue Feb 28 16:10:01 2023
    Hi,

    Following the recent case of #1032122 (chkrootkit: bad redirection
    creating file '1'?) and previously #1030120 (ipmiutil: cron script is
    creating file /root/1), I tried using Debian CodeSearch to look for
    other possible wrong cases like those and here is for instance a list
    of candidates to check: https://codesearch.debian.net/search?q=%5B12%5D%26%3E%5B12%5D&literal=0 (including surprising cases related to linux_6.1.12)

    So what do I do next? Check each case and for each true one, fill a bug?
    Are there tools to check shell scripts that could be used to detect/prevent/notify on this?

    But moreover using the CodeSearch form, it is not easy using the literal search.
    For instance 2&>1 gives some result whereas &>1 does not. Is there a
    bug or does such a query go beyond some limit?

    Regards,
    Patrice

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to Patrice on Wed Mar 1 02:00:01 2023
    On Tue, 28 Feb 2023 15:51:20 +0100, Patrice wrote:
    I tried using Debian CodeSearch to look for
    other possible wrong cases like those and here is for instance a list
    of candidates to check: https://codesearch.debian.net/search?q=%5B12%5D%26%3E%5B12%5D&literal=0

    Nice thinking, and good finds.

    Are there tools to check shell scripts that could be used to detect/prevent/notify on this?

    Does shellcheck[1] (available in Debian) help to confirm some/all of them?

    So what do I do next? Check each case and for each true one, fill a bug?

    Where possible I'd recommend going upstream first for most of these --
    except in cases where you find that functionality is significantly
    broken in Debian packages because of them (let me know if you'd like
    me to explain some of the reasons I think that).

    [1] - https://packages.debian.org/bookworm/shellcheck

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Patrice Duroux@21:1/5 to All on Wed Mar 1 17:10:01 2023
    Great, I will give a look at shellcheck.

    Regarding the upstream cases, at least I started with two of them:
    1. https://lkml.org/lkml/2023/3/1/396
    2. https://github.com/apache/jena/pull/1787
    And let's see my level of courage for the others.

    Thanks!

    Le mer. 1 mars 2023 à 01:38, James Addison <jay@jp-hosting.net> a écrit :

    On Tue, 28 Feb 2023 15:51:20 +0100, Patrice wrote:
    I tried using Debian CodeSearch to look for
    other possible wrong cases like those and here is for instance a list
    of candidates to check: https://codesearch.debian.net/search?q=%5B12%5D%26%3E%5B12%5D&literal=0

    Nice thinking, and good finds.

    Are there tools to check shell scripts that could be used to detect/prevent/notify on this?

    Does shellcheck[1] (available in Debian) help to confirm some/all of them?

    So what do I do next? Check each case and for each true one, fill a bug?

    Where possible I'd recommend going upstream first for most of these --
    except in cases where you find that functionality is significantly
    broken in Debian packages because of them (let me know if you'd like
    me to explain some of the reasons I think that).

    [1] - https://packages.debian.org/bookworm/shellcheck

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Diederik de Haas@21:1/5 to Patrice Duroux on Wed Mar 1 17:24:33 2023
    Copy: jay@jp-hosting.net (James Addison)
    Copy: debian-qa@lists.debian.org

    On Wednesday, 1 March 2023 16:52:55 CET Patrice Duroux wrote:
    Regarding the upstream cases, at least I started with two of them:
    1. https://lkml.org/lkml/2023/3/1/396

    When it comes to the (upstream) kernel, there's a script which tells you what the best place is to send your patches to:
    `scripts/get_maintainer.pl <path-to-file-in-question>`

    That gives a whole list and you could send it to everyone, or pick the appropriate mailing list from there, which in this case is: linux-perf-users@vger.kernel.org

    If you don't get a response in a reasonable timeframe to your current message (lkml is really high volume so not everyone follows that), then I'd suggest to try again on the linux-perf-user@vger.kernel.org ML.

    HTH
    -----BEGIN PGP SIGNATURE-----

    iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY/98QQAKCRDXblvOeH7b brWVAP4l4hEmYM4pz4qIAJ7P58G7E5Ye2JhiFtPgdf0hLat+GgEAsPPBpLvVqEaW gyc00vExJvR/WRuJXmkZ4oEOG79zlgA=
    =nylk
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Patrice Duroux@21:1/5 to All on Wed Mar 1 18:30:01 2023
    Sorry.
    So I should have split this work into two patches and then sent one to linux-perf-user and the other one to linux-kselftest.
    Would it be possible to send an email to these (sub)lists with just a
    ref to my first post then or do I really have to split the patch etc.?
    Any script to magically do this regarding a git diff in my clone of
    linux would have been great! (joking)

    I am still progressing but some of the targets (asterisk for instance)
    asked me to process another way also that requires me to register
    another system etc.
    Would I save putting it then in the hand of each corresponding DD even
    if it is related to upstream?

    https://github.com/ocaml/ocaml/pull/12058
    https://github.com/certik/ustr/pull/1 https://github.com/FirebirdSQL/firebird/issues/7492 https://github.com/asterisk/asterisk/pull/31 https://github.com/memcached/memcached/pull/1001

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Addison@21:1/5 to Patrice Duroux on Wed Mar 1 18:30:01 2023
    On Wed, 1 Mar 2023 at 15:53, Patrice Duroux <patrice.duroux@gmail.com> wrote:

    Great, I will give a look at shellcheck.

    Thanks - if it can also detect these problems, then -- after waiting a
    little while for any suggestions and confirmation from
    debian-lint-maint (cc'd) -- it might be worth filing a bug against
    lintian to request a shellscript style-checking rule (idea: solve
    once, and then attempt to introduce automated checks to highlight
    future occurrences).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Patrice Duroux@21:1/5 to All on Wed Mar 1 19:00:01 2023
    But another difficult point concerns the set of upstream files (as
    well as the set of Debian packaging files) to detect the files to send
    to the shellcheck.
    It could also be in a documentation file, a make file, a .spec file
    etc. I am facing a lot of cases in this quest.
    Is shellcheck able to handle some of those?
    But it sure would be a good thing.

    Le mer. 1 mars 2023 à 18:06, James Addison <jay@jp-hosting.net> a écrit :

    On Wed, 1 Mar 2023 at 15:53, Patrice Duroux <patrice.duroux@gmail.com> wrote:

    Great, I will give a look at shellcheck.

    Thanks - if it can also detect these problems, then -- after waiting a
    little while for any suggestions and confirmation from
    debian-lint-maint (cc'd) -- it might be worth filing a bug against
    lintian to request a shellscript style-checking rule (idea: solve
    once, and then attempt to introduce automated checks to highlight
    future occurrences).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Diederik de Haas@21:1/5 to Patrice Duroux on Wed Mar 1 19:40:18 2023
    Copy: jay@jp-hosting.net (James Addison)
    Copy: debian-qa@lists.debian.org

    On Wednesday, 1 March 2023 18:07:26 CET Patrice Duroux wrote:
    So I should have split this work into two patches and then sent one to linux-perf-user and the other one to linux-kselftest.
    Would it be possible to send an email to these (sub)lists with just a
    ref to my first post then or do I really have to split the patch etc.?

    You could send an email to those lists and ask. But there's a high chance they'll ask you to look at Documentation/process/submitting-patches.rst in the kernel tree and retry following the procedure detailed there.

    One thing that's missing and is required afaik is a Signed-off-by 'tag'.
    If you do `git commit -s` then it'll automatically add that line.
    As you're likely going to have to 'retry', then splitting the change into 2 separate patches is recommended.
    You may also want to look at https://git-send-email.io/ as using `git send- email` is highly recommended.

    I've only send a few (small) patches and doing this for the first time may look a bit daunting, but it's actually not that hard.
    The first time just takes some time.

    -----BEGIN PGP SIGNATURE-----

    iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY/+cEgAKCRDXblvOeH7b bk/AAQDi7N6mdIR2tb5b2fXhLCYJFn5fNP7kLvQFQOZNOD6OSwEAscWBtyBO3O9b ZEvhJyGE0hIFijcx7ipjVmLJfcmAvwA=
    =Tjut
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Patrice Duroux@21:1/5 to All on Wed Mar 1 21:30:01 2023
    Sorry but the title of my message is wrong: s/having/that should have/
    So stupid to create bad noise in the message archives.
    Thanks Bart Martens!

    ps: more MR or issues have been submitted upstream (sup-mail, plptools, vice)


    Le mar. 28 févr. 2023 à 15:51, Patrice Duroux
    <patrice.duroux@gmail.com> a écrit :

    Hi,

    Following the recent case of #1032122 (chkrootkit: bad redirection
    creating file '1'?) and previously #1030120 (ipmiutil: cron script is creating file /root/1), I tried using Debian CodeSearch to look for
    other possible wrong cases like those and here is for instance a list
    of candidates to check: https://codesearch.debian.net/search?q=%5B12%5D%26%3E%5B12%5D&literal=0 (including surprising cases related to linux_6.1.12)

    So what do I do next? Check each case and for each true one, fill a bug?
    Are there tools to check shell scripts that could be used to detect/prevent/notify on this?

    But moreover using the CodeSearch form, it is not easy using the literal search.
    For instance 2&>1 gives some result whereas &>1 does not. Is there a
    bug or does such a query go beyond some limit?

    Regards,
    Patrice

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)