4 ms·

As far as I know, Node.js was used inside in a limited capacity, but they had an alternative for npm for security reasons, and you had to get an npm package app

As far as I know, Node.js was used inside in a limited capacity, but they had an alternative for npm for security reasons, and you had to get an npm package approved to use it internally. FWIW, this is a very good thing. A company as large as Amazon should do this with all of their repositories; even a small start-up should be doing this to mitigate suspicious packages / third-party code vulnerabilities.

yomly 8y ago
I feel like the whole NPM/JS culture is around "there's a library for that" so I can see how the friction around having to get approval for npm packages would be an absolute velocity killer, but when you're as big as Amazon I really wouldn't want that particular JS flavour of "move fast and break things" powering the company...
jrockway 8y ago
I worked on third-party package approvals at Google. The reasoning behind reviews was largely due to license compliance. If the license said "you have to display this license to end-users" then we had to make sure that the license was machine-readable and would be automatically bundled into the build to be displayed in that "open source licenses" section of pretty much every app ever. If the license said "by linking this into your code, you have to opensource all code at your company", we had to deny it. That sort of thing. We suggested that people get security reviews, but it was up to the user of the package to figure out whether or not that was necessary. Often security reviews would be blocking the project's launch and would be done at that time. The final thing we enforced was a "one version" policy. If everyone was using foobar-1.0, and you wanted to use foobar-2.0, it was on you to update everyone to foobar-2.0. This was the policy that people hated the most, but basically mandatory at the time because none of the languages widely used at Google supported versioned symbols. Having library A depend on foobar-1.0 and library B depending on foobar-2.0 meant that application C could not depend transitively on library A and library B at the same time, which would cause many disasters.
- nerdponx 8y ago
  This all sounds like justified inconvenience in the name of safety at scale. As long as you have a good relationship with the package approval guys this is a fine workflow in my experience.
  - jrockway 8y ago
    Yeah, I thought it was fine (I was both a reviewer and a user). I mostly posted to provide some contrast to the folks that are saying things like "there are too many open-source libraries and they need to be approved to make sure there aren't any security problems", which is not what we did. We did not attempt to limit the use of libraries, nor did we vouch for the security-readiness of packages before they were allowed to be checked in to source control. If you think there are too many npm libraries and are looking for an example of a big tech company saying "no more!", this is not it. Use all the libraries!
- jacobparker 8y ago
  There's some public documentation on the "one version" policy here: https://opensource.google.com/docs/thirdparty/oneversion/ https://opensource.google.com/docs/thirdparty/oneversion/
andrewguenther 8y ago
Node is picking up internally as a build environment for frontend JS which all used to be done in Ruby.
johnnyfaehell 8y ago
This is a good idea in large companies but the only time I've ever seen this implemented was when a developer wanted who wanted to become lead dev so started hogging permissions to things and set up an internal packagist that only he could add packages to. It didn't end well for him really.
- vonseel 8y ago
  That's unfortunate, but how can you be sure this was his motivation or reasoning for adding an internal repo manager? I'm only asking because I learned the practice from an engineer / CTO whom I looked up to greatly early in my career, and if I were to go work somewhere and push leadership to implement Artifactory/Nexus/etc., I hope people wouldn't misunderstand my intentions. Anyone pushing for something like that is naturally likely to be the repo administrator in the beginning, and that may look like hogging permissions even if the developers intent is something entirely different? Catch my drift?
michaelper22 8y ago
Morgan Stanley revealed at a recruiting event that they follow this practice. "You can definitely use Apache Spark! It's been reviewed by our Enterprise Architecture team; some APIs were removed, and we substituted 'Morganized' variants of others, which you won't find code/docs for on Github ;)" Given the npm debacle, I could totally see even a small org running an internal Maven repo with approved versions of (popular, and especially obscure) libs.

yomly 8y ago

I feel like the whole NPM/JS culture is around "there's a library for that" so I can see how the friction around having to get approval for npm packages would be an absolute velocity killer, but when you're as big as Amazon I really wouldn't want that particular JS flavour of "move fast and break things" powering the company...

jrockway 8y ago

I worked on third-party package approvals at Google. The reasoning behind reviews was largely due to license compliance. If the license said "you have to display this license to end-users" then we had to make sure that the license was machine-readable and would be automatically bundled into the build to be displayed in that "open source licenses" section of pretty much every app ever. If the license said "by linking this into your code, you have to opensource all code at your company", we had to deny it. That sort of thing. We suggested that people get security reviews, but it was up to the user of the package to figure out whether or not that was necessary. Often security reviews would be blocking the project's launch and would be done at that time. The final thing we enforced was a "one version" policy. If everyone was using foobar-1.0, and you wanted to use foobar-2.0, it was on you to update everyone to foobar-2.0. This was the policy that people hated the most, but basically mandatory at the time because none of the languages widely used at Google supported versioned symbols. Having library A depend on foobar-1.0 and library B depending on foobar-2.0 meant that application C could not depend transitively on library A and library B at the same time, which would cause many disasters.

nerdponx 8y ago
This all sounds like justified inconvenience in the name of safety at scale. As long as you have a good relationship with the package approval guys this is a fine workflow in my experience.
- jrockway 8y ago
  Yeah, I thought it was fine (I was both a reviewer and a user). I mostly posted to provide some contrast to the folks that are saying things like "there are too many open-source libraries and they need to be approved to make sure there aren't any security problems", which is not what we did. We did not attempt to limit the use of libraries, nor did we vouch for the security-readiness of packages before they were allowed to be checked in to source control. If you think there are too many npm libraries and are looking for an example of a big tech company saying "no more!", this is not it. Use all the libraries!
jacobparker 8y ago
There's some public documentation on the "one version" policy here: https://opensource.google.com/docs/thirdparty/oneversion/ https://opensource.google.com/docs/thirdparty/oneversion/

andrewguenther 8y ago

Node is picking up internally as a build environment for frontend JS which all used to be done in Ruby.

johnnyfaehell 8y ago

This is a good idea in large companies but the only time I've ever seen this implemented was when a developer wanted who wanted to become lead dev so started hogging permissions to things and set up an internal packagist that only he could add packages to. It didn't end well for him really.

vonseel 8y ago
That's unfortunate, but how can you be sure this was his motivation or reasoning for adding an internal repo manager? I'm only asking because I learned the practice from an engineer / CTO whom I looked up to greatly early in my career, and if I were to go work somewhere and push leadership to implement Artifactory/Nexus/etc., I hope people wouldn't misunderstand my intentions. Anyone pushing for something like that is naturally likely to be the repo administrator in the beginning, and that may look like hogging permissions even if the developers intent is something entirely different? Catch my drift?

michaelper22 8y ago

Morgan Stanley revealed at a recruiting event that they follow this practice. "You can definitely use Apache Spark! It's been reviewed by our Enterprise Architecture team; some APIs were removed, and we substituted 'Morganized' variants of others, which you won't find code/docs for on Github ;)" Given the npm debacle, I could totally see even a small org running an internal Maven repo with approved versions of (popular, and especially obscure) libs.