Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Thursday July 25 2019, @05:52PM   Printer-friendly
from the pics-or-it-didn't-happen dept.

Alleged critical VLC flaw is nothing to worry about -- and is nothing to do with VLC

There has been a degree of confusion over the last few days after news spread of a supposed vulnerability in the media player VLC. Despite being labelled by security experts as "critical", VLC's developers, VideoLAN, denied there was a problem at all.

And they were right. While there is a vulnerability, it was in a third-party library, not VLC itself. On top of this, it is nowhere near as severe as first suggested. Oh -- and it was fixed over a year ago. An older version of Ubuntu Linux was to blame for the confusion.

The problem actually exists in a third-party library called libebml, and the issue was addressed some time ago. The upshot is that if you have updated VLC within the last year, there is no risk whatsoever. VLC's developers are understandably upset at the suggestion that their software was insecure.

Also at Tom's Hardware, Boing Boing, and The Register.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by c0lo on Friday July 26 2019, @05:09AM (3 children)

    by c0lo (156) Subscriber Badge on Friday July 26 2019, @05:09AM (#871333) Journal

    Java itself is a gigantical dependency of otherwise small applications that depend on it.

    Now, tell me about Perl, Python, NodeJS and so many others.

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by DannyB on Friday July 26 2019, @01:20PM (2 children)

    by DannyB (5839) Subscriber Badge on Friday July 26 2019, @01:20PM (#871440) Journal

    Can Python, NodeJS, and God forbid Perl actually:
    1. be as large of a download
    2. be as large of an install
    3. have the largest number of files on disk
    4. have the biggest on disk pawprint
    and most importantly
    5. use as much memory . . .

    . . . as Java ?

    IMO, Java has them all beat.

    --
    The lower I set my standards the more accomplishments I have.
    • (Score: 2) by c0lo on Friday July 26 2019, @02:03PM (1 child)

      by c0lo (156) Subscriber Badge on Friday July 26 2019, @02:03PM (#871471) Journal

      Really? I just don't feel this is something so totally out of proportion, would you mind checking it again?

      Excluding the docos (docs and man) and legals, here's what my java-11 installation looks like:


      /usr/lib/jvm/java-11-openjdk-amd64$ ls
      bin conf docs include jmods legal lib man release

      /usr/lib/jvm/java-11-openjdk-amd64$ find bin conf include jmods lib -type f -print | wc -l
      158

      /usr/lib/jvm/java-11-openjdk-amd64$ du -h -c bin conf include jmods lib
      484K bin
      16K conf/security/policy/limited
      12K conf/security/policy/unlimited
      32K conf/security/policy
      36K conf/security
      4.0K conf/management
      44K conf
      12K include/linux
      228K include
      186M jmods
      68K lib/jli
      4.0K lib/security
      35M lib/server
      4.0K lib/jfr
      178M lib
      364M total

      364 MB in 158 files.

      ----

      Now, let me try the nodejs installation:

      ~/bin/node$ ls
      bin CHANGELOG.md include lib LICENSE README.md share

      ~/bin/node$ find bin include lib share -type f -print | wc -l
      3620

      ~/bin/node$ du -h -c bin include lib share
      38M bin
      24K include/node/libplatform
      12K include/node/openssl/archs/linux-armv4/no-asm/include/openssl
      32K include/node/openssl/archs/linux-armv4/no-asm/include
      12K include/node/openssl/archs/linux-armv4/no-asm/crypto/include/internal
      16K include/node/openssl/archs/linux-armv4/no-asm/crypto/include
      24K include/node/openssl/archs/linux-armv4/no-asm/crypto
      60K include/node/openssl/archs/linux-armv4/no-asm
      12K include/node/openssl/archs/linux-armv4/asm/include/openssl
      32K include/node/openssl/archs/linux-armv4/asm/include
      12K include/node/openssl/archs/linux-armv4/asm/crypto/include/internal
      16K include/node/openssl/archs/linux-armv4/asm/crypto/include
      24K include/node/openssl/archs/linux-armv4/asm/crypto
      60K include/node/openssl/archs/linux-armv4/asm
      ...
      ...
      27M lib/node_modules/npm
      27M lib/node_modules
      27M lib
      8.0K share/systemtap/tapset
      12K share/systemtap
      16K share/doc/node
      20K share/doc
      20K share/man/man1
      24K share/man
      60K share
      69M total

      69 MB in 3620 files

      --
      https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
      • (Score: 2) by DannyB on Friday July 26 2019, @03:04PM

        by DannyB (5839) Subscriber Badge on Friday July 26 2019, @03:04PM (#871496) Journal

        Thank you! That is very interesting.

        Java runtime: fewer but larger files.

        NodeJS: many smaller files

        I suspect NodeJS cannot compete with Java on performance.

        The Java runtime runs java bytecode. It starts out interpreted. Continuous dynamic profiling identifies functions using disproportionate cpu. Those are immediately compiled to native code by the C1 compiler, and put on a list to soon be recompiled by the C2 compiler. C1 quickly compiles simple code. C2 spends time generating highly optimized code.

        C2 aggressively inlines code. C2 has a 'global view' of the entire running application unlike an ahead of time compiler, such as C, or Golang, etc.

        If a class is dynamically reloaded during runtime, causing some aggressively inlined code to become stale, then those functions are de-optimized back to being byte code interpreted again. If they still use disproportionate cpu they will get compiled again by C1 then C2.

        I was just reading about Vectorised Byte Operations in C2 [github.io].

        C2 is also able to use instructions specific to your actual processor model. Unlike an ahead of time compiler.

        --
        The lower I set my standards the more accomplishments I have.