-
Notifications
You must be signed in to change notification settings - Fork 523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security fixe reported by github #243
Comments
I think that it was fixed when use 4.2b2. Thanks. |
Hi! This means you need to update your project to the newer, fixed version of pyyaml. |
So what is the security issue? I don't see anything in the changelog and there are only beta releases of 4.1. |
There's a writeup in #193 about why the issue has come to light. TL;DR:Prior to #74, How to fix:If you don't want people running arbitrary python (you probably don't), then change uses of #193 discusses the idea that an API change should be made to make |
I think you should work with the Github security team to pull this security notice as long as there is no released version of a fix. |
@joekohlsdorf but there is a security issue? It's not so much that there's no fix, it's just you use the library in a different way. That's still a fix |
Except that I have no way of knowing which code path external libraries in my project take and no direct way of fixing it except monkey-patching. |
Then it's not your job to fix it, it's the job of your dependencies. Then when they release a new version, you update to that. I agree GitHub notifications are kinda annoying like this, but it's the right way to do it. Otherwise you end up not being told of issues in your software, which you may need to be aware of. |
I spent some time last year in correspondence with github explaining that reporting security issues that were actually false positives limits the effectiveness of this new service. It seems to be the original intent of the authors to provide the |
I feel it's pretty normal Github notifies with an alert about these kind of issues. I don't see how developers are supposed to know that |
Simple, the manual!
|
Sure, if you go beyong And if you have time to read comments on stackoverflow… Anyway, excellent news that this is safe by default now. This is how it should have been! |
Is there an expected release date to a stable 4.2 version? |
(sorry if I miss something here, since I did not read all linked resources).
? |
Convert tests to use yaml.safe_load instead of insecure yaml.load yaml/pyyaml#243
On this one I support GitHub decision. Compare a library with a car and imagine that the car does not have a seatbelt sensor enabled by default, or guns without safety locks. This is what unsafe defaults mean. Anycone can bypass them but it matters them to be defaults and that bypassing informs the user about risks ("unsafe" in name being a very good example). |
I appreciate the work by the maintainers of this package (@ingydotnet, @sigmavirus24, @nitzmahone, @xitology) but I think the handling of this issue and CVE leaves a lot of room for improvement. The changelog and the PyPI releases are not consistent with the information in the CVE. The latest stable release on PyPI is version 3.13. The changelog and the CVE both reference version 4.1, which does not exist in PyPI. The GitHub notice mentions version 4.2b1, which is tagged as a pre-release version in PyPI. The latest pre-release on PyPI is 4.2b4. None of these versions are in line with SemVer. There is no clear explanation of the issue or the remedy in the CVE, the GitHub notice, or the repo documentation. With the pre-releases, there is no stated release roadmap or versioning strategy. This situation is creating a bit of confusion regarding a package that is fairly popular and depended upon. Is the project in need of maintainers? I volunteer to help maintain it if help is necessary. |
@kislyuk, PyYAML has a group of core maintainers. Work on the next release has begun by the maintainers. If you want to help with the work, then you are welcome to join us in #pyyaml on irc.freenode.net. |
Closing this. See #193 (comment) |
Related to yaml/pyyaml#243 Change-Id: I4c8db7d25568f2afd48ebb1a393dd92f3773b35e
@kislyuk et al. > None of these versions are in line with SemVer. Well, SemVer is not the only way to version stuff, people used version long before SemVer was even a thought and it's really not the one and only good thing and I don't think I would ever recommend enforcing it verbatim for anything published on pypi (no notion of post-releases or development releases, pre-releases are not well-defined). As you can see, pyyaml here uses two numbered version components, not three, so expectation for it to follow SemVer spec is a little bit assuming too much. Actually, for this particular project I don't see much good in making the version numbers longer (there are not many new features added, releases happen not that often, api rarely change at all). Two numbers plus pre-release component seems perfectly fine to me. This change with load is backwards-incompatible if I understand correctly so the major version should be bumped from 3 to 4. All seems fine to me so far. A different question is what would be the general recommendation for people who don't use pyyaml directly and only require it for some other libs? Most of the stuff uses safe_load or equivalents already. There might be some way to check whether it's actually so for the stuff I use. Simple grepping in virtualenv, perhaps. If there's no third-party lib that uses unsafe load() I'd probably just wait for the release. Otherwise, is it safe to upgrade to a beta in my production environment? Are the incompatible changes incompatible enough to break anything in unexpected places? A lot of unanswered questions that a final release of 4.2 would probably solve. |
Related to yaml/pyyaml#243 Change-Id: I4c8db7d25568f2afd48ebb1a393dd92f3773b35e
* Resolve github PyYAML insecure warning Related to yaml/pyyaml#243 Change-Id: I4c8db7d25568f2afd48ebb1a393dd92f3773b35e * Update requirements-dev.txt
Hi,
I received this warning message:
The text was updated successfully, but these errors were encountered: