github was started in 2008 , before that sourceforge was the place where opensource project were hosted when a project was not hosted on a specific server
Thanks for sharing this! A question: any first level dependency depends on a number of second level ones, and those on more dependencies and so on. Any mid-sized rails project can have a few hundred dependencies when you sum all up, and it gets way uglier if you take the node route ... ... are all those considered SOUP? I mean, why would they not be considered as such? Of course, if first level SOUP as you describe is pain, a positive answer to that question would mean insurmountable unbearable agonizing pain. There is probably lower levels in hell to the one when you get to list all the requirements of your node_modules folder ... but not many :) So, what do you think?
Hey David, that's a great question which actually has come up many times in our consulting! I should have answered it in the video, haha.. The TLDR is that you only have to document first-level dependencies, i.e., for rails, what's in your Gemfile (and not what's in your Gemfile.lock). Does this make sense? Probably not. Does SOUP documentation make sense? Probably also not. Do regulators understand SOUP? Let's just say an auditor recently asked me "what SOUP actually was" and I explained it to them, haha..
@@openregulatory thanks a lot for your response, Oliver! Just plain regular pain it is then :) Yeah, I agree that makes zero sense and total sense, both at the same time :) On a sad note, I think that renders this SOUP thing quite useless (I can understand the original intended sense of it).
Regarding the anomaly list: I believe it is enough to filter the list for entries for bugs, which is usually possible using labels or other filter operations.
I noticed that you entered the version for jQuery as 3.4.1, however in the package.json it's ^3.4.1, which is 3.4.1 or above. Will this cause issues come audit time?
Good find! And nope, I don't think this will cause any issues. It's highly unlikely that your auditor knows jQuery and/or the versioning scheme in package.json files. SOUP documentation right now is not very useful on a technical level anyway (as e.g. you only need to include first-level dependencies). Also, most auditors don't have much software experience. Well, maybe with mainframes and punch cards..
You are a gentleman and a scholar
Indeed!
github was started in 2008 , before that sourceforge was the place where opensource project were hosted when a project was not hosted on a specific server
Thanks for sharing this! A question: any first level dependency depends on a number of second level ones, and those on more dependencies and so on. Any mid-sized rails project can have a few hundred dependencies when you sum all up, and it gets way uglier if you take the node route ...
... are all those considered SOUP? I mean, why would they not be considered as such?
Of course, if first level SOUP as you describe is pain, a positive answer to that question would mean insurmountable unbearable agonizing pain. There is probably lower levels in hell to the one when you get to list all the requirements of your node_modules folder ... but not many :)
So, what do you think?
Hey David, that's a great question which actually has come up many times in our consulting! I should have answered it in the video, haha.. The TLDR is that you only have to document first-level dependencies, i.e., for rails, what's in your Gemfile (and not what's in your Gemfile.lock).
Does this make sense? Probably not. Does SOUP documentation make sense? Probably also not. Do regulators understand SOUP? Let's just say an auditor recently asked me "what SOUP actually was" and I explained it to them, haha..
@@openregulatory thanks a lot for your response, Oliver! Just plain regular pain it is then :)
Yeah, I agree that makes zero sense and total sense, both at the same time :) On a sad note, I think that renders this SOUP thing quite useless (I can understand the original intended sense of it).
@@openregulatory what happens if it goes high or medium risk?
Regarding the anomaly list: I believe it is enough to filter the list for entries for bugs, which is usually possible using labels or other filter operations.
I noticed that you entered the version for jQuery as 3.4.1, however in the package.json it's ^3.4.1, which is 3.4.1 or above. Will this cause issues come audit time?
Good find! And nope, I don't think this will cause any issues. It's highly unlikely that your auditor knows jQuery and/or the versioning scheme in package.json files. SOUP documentation right now is not very useful on a technical level anyway (as e.g. you only need to include first-level dependencies). Also, most auditors don't have much software experience. Well, maybe with mainframes and punch cards..