81–90 of 125 posts
They really bury their lead on what languages are supported. - C/C++ - C# - Go - Java - JavaScript/TypeScript - Python https://docs.github.com/en/free-pro-team@latest/github/findi...
Thank god no php. Not that it would be needed.
They stated in the comments here that they are actively working on it, and I would personally appreciate it in addition to the number of other static analysis tools I use.
They really bury their lead on what languages are supported. - C/C++ - C# - Go - Java - JavaScript/TypeScript - Python https://docs.github.com/en/free-pro-team@latest/github/findi...
It’s actually “lede” [1] > A lede is the introductory section in journalism and thus to bury the lede refers to hiding the most important and relevant pieces of a story within other distracting information. The spelling of lede is allegedly so as to not confuse it with lead (/led/) which referred to the strip of metal that would separate lines of type. Both spellings, however, can be found in instances of the phrase.…
Lede is just lead spelled incorrectly with the same meaning.
https://books.google.com/ngrams/graph?year_end=2019&year_sta...
Earlier quoted context omitted.
Sure, but the reported issues are usually not nearly that severe. Most of the time what I see is "A dependency of a dependency of a dependency of Webpack is vulnerable to a Regular expression Denial of Service attack" or prototype pollution or something like that.
Also, many times those "vulnerabilites" are not really applicable because the application code can not trigger it if it never ends up in the vulnerable code path (for example when a vulnerable regex is never passed untrusted input). I imagine those cases could be detected using static analysis but the current vulnerability reporting tools that do not even look at actual code are completely useless in that regard.
I don't have experience of the security fatigue and stuff that other people seem to be talking about. Maybe I just write better code, or use fewer, and fewer problematic, dependencies? ¯\_(ツ)_/¯
Anyway I think this is a really cool feature and I'd love to see more of these sort of value added and free features on top of public repos. Is there a place where like you can create your own like a marketplace or something?
Isn't this already done by Dependabot[1]? I've been using it for some time with my JS/TS repos to keep my dependencies up-to-date. It's not the greatest as it sends alerts about vulnerabilities in devDependencies. But with automatic merge checks I only get an email that the issue has been fixed so it isn't the worst thing in the world. [1] https://dependabot.com/
PM from GitHub here and author of Dependabot. It's different. - Dependabot looks for vulnerabilities in your dependencies, and creates pull requests to update you to fixed versions. - Code scanning looks for vulnerabilities in your own code. So, for example, if you have written code that takes user input and creates a database instruction from it without escaping it, it will flag that you are introducing an SQL injec…
Hey totally off topic sorry. Can you get someone to turn off pull-requests for the unofficial mirrors that you guys created for some open source projects? Users are being mislead into thinking opening PRs there is productive, but they're not monitored by our project and we don't own the repo anyway. https://github.com/wine-mirror/wine/pulls
I've tried contacting your support, but they just tell me that they don't own the repo, which is obviously false[1]. I don't know who to reach out to.
[1] https://github.community/t/how-is-the-mirrored-from-annotati...
Earlier quoted context omitted.
Webpack generates code which might be loaded by users and additionally it's very common to run it on a CI server (which can sometimes have network access out to other machines at a firm). In general, it's quite strange to me that vulnerabilities in `devDependencies` are considered less important than those in `dependencies`. These dependencies are generally for tools that are run within your company network, and cont…
What would be the attack vector in this case? Assuming that it's a vulnerability rather than an actually malicious package, how would an attacker exploit something running on your CI server? The only way I see is if they already have the ability to modify your source code, at which point it's of course already game over.
Earlier quoted context omitted.
Sure, but the reported issues are usually not nearly that severe. Most of the time what I see is "A dependency of a dependency of a dependency of Webpack is vulnerable to a Regular expression Denial of Service attack" or prototype pollution or something like that.
Also, many times those "vulnerabilites" are not really applicable because the application code can not trigger it if it never ends up in the vulnerable code path (for example when a vulnerable regex is never passed untrusted input). I imagine those cases could be detected using static analysis but the current vulnerability reporting tools that do not even look at actual code are completely useless in that regard.
It needlessly accumulates risk when you prioritize explaining why things don't need to be fixed rather than just lowering the bar to fixing them
Open Source authors [1] [2] (including myself) have complained of automatic security scans. They yield way too many false positives, increasing the burden of maintaining repositories. Specially troublesome are when e.g. the "vulnerability" (if it's even one) is in a devDependency that is not deployed to production. In theory automatic vulnerability scans sounds great, but having every repo ping you with not-actually-…
Github's notification system is incredibly spammy if you have a lot of repos, and there's no obvious way to manage it. There's also a huge need for an "unsubscribe all" in the notification inbox. There's also not a severity indicator - some minor issue not encountered in normal use is just as noisy as an extremely important issue that affects every user. Other tools like Jira and Gerrit are far better at this.