5 ms·

Only if by next you mean last and by 'major problem' you mean 'mostly ignored due to lack of tangible accountability for anyone involved'

foobiekr 6y ago
this. at my previous company, and on the current project, we have explicit audit and mirrors for every dependency. it's a ton of work, especially at first. the developers, especially the front end, sort of resent it. but for our particular niche, especially previously, we put a priority on knowing what we are running and requiring importers to take an active, documented role in vetting that they pull in instead of just grabbing whatever. the _entire_ ecosystem works against you if you want to do this. it's pretty incredible.
- neilv 6y ago
  I did this same thing for the last large system I worked on. All third-party packages got audited and checked into our CM system before they could be used. Also, I prohibited third-party HTTP/S requests, such as to pull a JS package from a CDN. I did this not only so that we could audit it and assure integrity and availability, but also so that we weren't leaking information to third parties under ordinary circumstances. (Little details: I had some naming conventions for versioning so that multiple versions of a package could be used simultaneously in a checkout. For the JS packages, it simply making a subdirectory named after the package name and version number; for the main application language, it was more complicated, to support their package system better. I made the main backend use thin wrapper modules for each of the third-party packages used, which effectively specified which version to use (with zero runtime cost from the wrapper), since the language platform package system didn't have some kind of manifest to do this.)
  - foobiekr 6y ago
    solid. our jenkins can't talk to anything except github. it's isolated. we use git for everything; our "versions" are git hashes. we maintain a manifest for the state of the repo and dependencies. this allows us to upgrade versions of dependencies as part of the normal workflow with ease (just a pull & checkout).
marcus_holmes 6y ago
hehe, agreed. But I think the chickens will come home to roost in the next few years. All those no-longer-maintained libraries still being imported; such a huge opportunity for mayhem. And still no way of avoiding it, apart from auditing every single import. Which hardly anyone does, or does properly.

foobiekr 6y ago

this. at my previous company, and on the current project, we have explicit audit and mirrors for every dependency. it's a ton of work, especially at first. the developers, especially the front end, sort of resent it. but for our particular niche, especially previously, we put a priority on knowing what we are running and requiring importers to take an active, documented role in vetting that they pull in instead of just grabbing whatever. the _entire_ ecosystem works against you if you want to do this. it's pretty incredible.

neilv 6y ago
I did this same thing for the last large system I worked on. All third-party packages got audited and checked into our CM system before they could be used. Also, I prohibited third-party HTTP/S requests, such as to pull a JS package from a CDN. I did this not only so that we could audit it and assure integrity and availability, but also so that we weren't leaking information to third parties under ordinary circumstances. (Little details: I had some naming conventions for versioning so that multiple versions of a package could be used simultaneously in a checkout. For the JS packages, it simply making a subdirectory named after the package name and version number; for the main application language, it was more complicated, to support their package system better. I made the main backend use thin wrapper modules for each of the third-party packages used, which effectively specified which version to use (with zero runtime cost from the wrapper), since the language platform package system didn't have some kind of manifest to do this.)
- foobiekr 6y ago
  solid. our jenkins can't talk to anything except github. it's isolated. we use git for everything; our "versions" are git hashes. we maintain a manifest for the state of the repo and dependencies. this allows us to upgrade versions of dependencies as part of the normal workflow with ease (just a pull & checkout).

marcus_holmes 6y ago

hehe, agreed. But I think the chickens will come home to roost in the next few years. All those no-longer-maintained libraries still being imported; such a huge opportunity for mayhem. And still no way of avoiding it, apart from auditing every single import. Which hardly anyone does, or does properly.