Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Always Review Your Dependencies, AGPL Edition

agwa.name

Post reply on HN
Print view View original

101–110 of 236 posts

Re: Always Review Your Dependencies, AGPL Edition

#101

Post by guipsp »

pomhellxml wrote: post #59
eitland wrote: post #52

Earlier quoted context omitted.

There's also Java and .NET for those who want better IDE support, better dependency management (without recursively downloading hundreds of packages), and a more traditional language and more fully featured language. PS: I came to statically typed languages as an adult, I actually disliked those languages before I had the lightbulb moment, so I think I might even be more qualified than everyone who hasn't managed to…

Whilst the dependency management story on Node, Python is sub-par, it’s not all roses in Java land either with Maven and POM file XML-hell.

Use Gradle

Re: Always Review Your Dependencies, AGPL Edition

#102

Post by tsteenbe »

adrianN wrote: post #13
sansnomme wrote: post #4

Package managers need to automatically derive properties of end builds based on licenses. E.g. Eclipse License 2.0 without the presence of another more liberal license means it cannot be used in copyleft software, any dependency that is copyleft is also infectious etc. Of course it won't account for every single legal property but the basic checks should be done. To prevent work duplication a single binary/library wr…

There is https://www.fossology.org/ which helps a bit.

If you want to do license compliance for various package managers then I recommend you checkout https://github.com/heremaps/oss-review-toolkit.

Full disclosure: I am one of the maintainers of OSS Review Toolkit.

Re: Always Review Your Dependencies, AGPL Edition

#103

Post by gpvos »

choeger wrote: post #2

That's the hidden cost of npm, cargo, pip, et. Al. The other one is IMO akin to overweight. Try to modernize a mid-sized project after one or two years and cry when you see the dependency graph. Ceterum censeo go inferior est.

> Ceterum censeo go inferior est.

Cur?

Re: Always Review Your Dependencies, AGPL Edition

#104

Post by M2Ys4U »

Doctor_Fegg wrote: post #39
pbhjpbhj wrote: post #33

Earlier quoted context omitted.

Aside, can anyone explain this to me? >Please do not use "public domain", it's not a license and it makes it impossible to use such code in corporate context. // Seems pretty ridiculous, "can't use code unless it's encumbered by licensing restrictions"??

CC0 is a licence. "Public domain" is a state. Some works have no copyright, typically because they're the product of a US Federal institution, or the copyright has expired. In American English this copyright-free state is also known as "public domain". (In British English it can mean something quite different.) To put something in the "public domain", you need to make a statement of such. In other words, a licence. Y…

>To put something in the "public domain", you need to make a statement of such. In other words, a licence. You could just say "I put this in the public domain" but it may not provide the certainty that bigcorps like. CC0 is a way of saying this in bigcorp-friendly language.

It's more than that - it's impossible to place things in to the public domain in many juristictions - like the UK.

(This is because copyright is property, and property must have an owner under the law of England and Wales [also Scots law I think, but I don't know]. Thus, a declaration that something is in the PD is of no effect.)

Re: Always Review Your Dependencies, AGPL Edition

#105

Post by marcan_42 »

self wrote: post #88
marcan_42 wrote: post #72

> The bulk of my trust is consolidated in the Go project, and thanks to their stellar reputation and solid operating procedures, I don't feel a need to review the source code of the Go compiler and standard libraries. Well... I have reviewed the Go runtime, after I ran into a bug in it... And that's one of the reasons I no longer use Go unless forced to. That thing is ugly under the covers. There is seriously quite a…

> That thing is ugly under the covers. Was the code you looked at in Go 1.5 and above? Is it cleaner in 1.4? They used automated tools to convert the C code into Go for 1.5.

They were halfway through the process when I made my contribution, and in fact I had to rewrite it in Go. The Go version was just a straight conversion; being Go didn't make it inherently cleaner.

Re: Always Review Your Dependencies, AGPL Edition

#106

Post by Blackstone4 »

marcan_42 wrote: post #72

> The bulk of my trust is consolidated in the Go project, and thanks to their stellar reputation and solid operating procedures, I don't feel a need to review the source code of the Go compiler and standard libraries. Well... I have reviewed the Go runtime, after I ran into a bug in it... And that's one of the reasons I no longer use Go unless forced to. That thing is ugly under the covers. There is seriously quite a…

So would you use?

Re: Always Review Your Dependencies, AGPL Edition

#107

Post by generationP »

> Aside: this is why I don't like to accept pull requests that move code around. Even if the new code organization is better, it's usually not worth the time it takes to ensure the pull request isn't doing anything extra.

This sounds like a solvable problem no one has bothered to solve. We need an analogue of diff highlighting for move-around changes, ideally one that decomposes a changeset into the coarsest block partition such that the changes boil down to a permutation of the blocks.

Something similar should be done for merge commits, which at the moment are completely undebuggable.

Re: Always Review Your Dependencies, AGPL Edition

#108

Post by CuriousSkeptic »

js4ever wrote: post #99
krapp wrote: post #94

Earlier quoted context omitted.

Modern JS is the current ECMAScript standard. Typescript is not "modern JS", any more than Coffeescript was, any more than the compile-to-js language that will probably replace it in a week. You're confusing the tool for the language the tool operates on, akin to claiming modern C++ is Visual Studio.

One thousand yes to this!

Coffee-script was obviously always a fad. It basically traded legibility for ergonomics. Adding nothing of particular value to maintainability and longevity.

TypeScript otoh is just ES with types. It moves in the completely opposite direction, adding just enough syntax to get a proper type system in place (a pretty good one to boot).

If anything I would expect it’s syntax additions to be adopted as the standard and directly supported by runtimes. Despite static typing not being that useful for interpreters.

Unless runtimes will completely phase out es, focusing on wasm. (But that will take decades, so not really an either or thing)

Re: Always Review Your Dependencies, AGPL Edition

#109

Post by tsteenbe »

256dpi wrote: post #10
sansnomme wrote: post #4

Package managers need to automatically derive properties of end builds based on licenses. E.g. Eclipse License 2.0 without the presence of another more liberal license means it cannot be used in copyleft software, any dependency that is copyleft is also infectious etc. Of course it won't account for every single legal property but the basic checks should be done. To prevent work duplication a single binary/library wr…

The licensing of a dependency could be easily determined programmatically (GitHub already built a decent scanner). However, I think that the quality of a dependency is most important and that requires a manual vetting process. A trivial solution would be to create a crowd-sourced dependency vetting platform.

> A trivial solution would be to create a crowd-sourced dependency vetting platform.

Such a platform is already being developed by various organizations, see https://clearlydefined.io/about and it already in use by GitHub. It's still under development and the initial focus is sharing data regarding copyrights, licenses and source code location for OSS packages.

Note that ClearyDefined only scans the code repository of OSS project it does not resolve dependencies for scanned OSS project. This makes sense as not all dependencies of OSS project B are inherited by a project A which included B as a dependency (due to dependency version resolution by the package manager or dependencies only used for testing).

The idea is that you will us an tool to resolve dependencies for the package manager your project uses which then queries the ClearyDefined APIs.

We are building such a tool as an open source project to manage of licensing and security for dependencies named OSS Review Toolkit (https://github.com/heremaps/oss-review-toolkit).

For a overview of the solution we are building see slide 9 in https://static.sched.com/hosted_files/ocs19/c7/OSS-Review-To...

Full disclosure: I am one of the maintainers of OSS Review Toolkit and also a contributor to ClearlyDefined.

Re: Always Review Your Dependencies, AGPL Edition

#110

Post by colonwqbang »

fenomas wrote: post #64
square_usual wrote: post #34

Earlier quoted context omitted.

He talks about reviewing dependencies when they are updated, as well, which certainly would help if someone snuck in malicious code in a minor version change.

Well, he talks about reviewing when he upgrades a dependency, but the tricksy thing about event-stream was that people could get the malicious change without having intended to upgrade anything. The only thing that really prevents such issues is version locking of transitive dependencies (which the author doesn't mention, but it could be that his package manager does it by default, or similar..).

I had missed that npm doesn't (didn't?) lock package versions by default. That's really scary.
Post reply on HN