5 ms·

Except when the language itself is statically and strongly typed (a la Haskell).

• acqq 10y ago
  Do you want to say that Haskell programs don't have any external library dependency because the language is "strongly typed"?
• briandoll 10y ago
  I haven't worked with Haskell myself (and we don't currently support Haskell), but it looks like Cabal is the package manager, which resolves the full graph of dependencies for your project. Most dependencies are specified like "network-info >= 0.2" (taken from a random example: https://github.com/bitemyapp/blacktip/blob/master/blacktip.cabal https://github.com/bitemyapp/blacktip/blob/master/blacktip.c...), which means you don't know which version will actually be used until you build the project. Which is our point in this blog post. If you just scanned that text file, you'd just be guessing at which versions of open source libraries are actually being used.
  • r-w 10y ago
    I don’t have a very in-depth understanding of dynamic analysis myself, so this may be somewhat of a simplistic question: Why not just resolve to the latest version of each library/module present on the system during the first pass through the list of dependencies?
    • briandoll 10y ago
      The package manager decides which packages are used based on how dependencies are specified. For example, you might ask for library-A >= 1.1, but a transitive dependency specification (a dependency of a dependency) may specify library-A >= 1.0 && <= 1.6. If versions up to 1.7 are available, you'd probably get 1.6. Probably. Because with some package managers, if you have version 1.5 sitting around in a local cache, it may use that instead. Basically, never try to guess what the package manager is going to resolve. Just let it do its job, just as it does for your production builds, and use that information to look up any associated vulnerabilities.
      • khedoros 10y ago
        You may be talking about two different situations. "r-w" might be thinking about a build style where compilation just uses the versions of libraries available on the system, rather than going to the package manager on a per-build basis and re-fetching dependencies (so, something more like a C build than a Rust, Haskell, or Node build). As an aside, and echoed by a few other comments in the thread, what you're calling "dynamic analysis" is what I know as "static analysis", like what I want Coverity to do (watch the build process, and monitor the source that actually goes into each of my build artifacts). "Dynamic analysis" brings to mind something more like Valgrind, or some other tool that monitors and profiles a program during execution.
  • bazzargh 10y ago
    cabal has a `cabal freeze` command which produces frozen constraints similar to Gemfile.lock in ruby. However, current Haskell projects tend to use stack for this purpose, see: https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cabal https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cab... (you could think of stack as analogous to ruby's Gemfile.lock plus rbenv, or python's virtualenv - it makes the whole build reproducible)