| General > General Technical Chat |
| University of Minnesota Linux code security issues; banned and to be removed |
| << < (3/23) > >> |
| ataradov:
--- Quote from: bd139 on April 23, 2021, 08:18:30 pm ---Yeah I work in fintech. We have background checks, multiple layers of review, static analysis, vulnerability analysis (DAST/SAST), least privilege implementations everywhere. --- End quote --- So can you 100% say that you never found a bug in the released code base? I'm not saying that Linux people do as much as possible now. They do as much as they realistically can. Some fields require more scrutiny than others. People dealing life sustaining application or even automotive stuff are doing more testing, since there resources are justified. I think people that suggest that one project or the other needs to do more review - go and do that review. It is easy to tell what others should and should not do. |
| bd139:
Oh no my point and the hilarity is that we do all that to increase our quality (100% is impossible) and immediately without thought stick it on top of a Linux kernel which is full of bugs introduced by untrusted university researchers. |
| DrG:
--- Quote from: ataradov on April 23, 2021, 08:43:53 pm --- --- Quote from: bd139 on April 23, 2021, 08:18:30 pm ---Yeah I work in fintech. We have background checks, multiple layers of review, static analysis, vulnerability analysis (DAST/SAST), least privilege implementations everywhere. --- End quote --- /---/ I think people that suggest that one project or the other needs to do more review - go and do that review. It is easy to tell what others should and should not do. --- End quote --- Yes, the difference between a 'checker' and a 'doer', but let me ask you something specific...in the "paper" and in the "walk back" https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf ...and I have seen enough walk-backs in my time to recognize them and distinguish them from clarifications, so It's only my opinion, but I am sticking with that The claim is that suggestions were made for improvement. That is, they went beyond simply showing/saying this is screwed up, do a better job. Do you think that they did that reasonably? (I don't know, but I thinking their suggestions for improvement might be considered under-whelming or unrealistic). In the paper, we provide our suggestions to improve the patching process. - OSS projects would be suggested to update the code of conduct, something like “By submitting the patch, I agree to not intend to introduce bugs”. - We need automated tools for testing and verifying patches. The relevant techniques include directed fuzzing, (under-constrained) symbolic execution, formal methods, etc. More details are in the paper. - OSS maintaining is understaffed. We should very much appreciate and honor maintainer efforts, and increase potential incentives if possible to encourage more people to join the maintaining. - We hope both reporters and maintainers are aware of the potential bug-introducing patches. Also, tools can be developed to check “immature vulnerabilities”. (from the 'clarification' cited above) |
| bd139:
To be fair that clause is in our employment contracts under "malicious intent". |
| coppice:
--- Quote from: bd139 on April 23, 2021, 09:26:19 pm ---To be fair that clause is in our employment contracts under "malicious intent". --- End quote --- Isn't most of an employment contract there with malicious intent? |
| Navigation |
| Message Index |
| Next page |
| Previous page |