Outside of the normal cast of YAML contributors, the Python community has spoken to the fact that this is not a desirable change. At this point it seems like the people who are trying to contribute to this discussion as actual users of PyYAML have voiced their opinion and the rest of the YAML world has said "Nah, that's okay" which is exactly what is being signaled in this PR. Please, let's not ignore the users of this library who want their libraries to not allow RCEs by default.

@sigmavirus24 It should be clear, as I thought I think it is in #193 that a fix to this issue ( #74 / #189 ) is being worked on and will be released as soon as an agreed upon solution is available.

• Make pyyaml safe by default. #74 is not acceptable in its current form.
• It was introduced without my knowledge or approval.
• That happened almost a year ago.
• PyYAML has had safe options since the very beginning.
• Exploitable use of it has been out there for 12+ years.

We can take a little time to find a win/win solution for both the YAML and Python communities. Hopefully that will happen in the 4.2 release. And if not, then shortly after.

I hope that people will join in to help out with the PyYAML release effort. Currently there are just 4 people trying their best to make this happen. Join irc.freenode.net #pyyaml

@ingydotnet And this is why I've stopped working on the project. It's impossible to maintain something when one person needs to approve everything and the people doing the work don't have a say in how the work is done. This is why you have so few people trying to help you. Good luck.

@sigmavirus24 I think nobody's ignoring users here.
I would be very sad if the next version does not have a safe default, but:

• I agree with @ingydotnet that a working release is the top priority, and we are glad about anyone helping.
• the Make pyyaml safe by default. #74 PR has issues (see PyYAML 4.1 changes "safe" in more ways than immediately obvious #187 for example), and at least the "safe_load is now less safe" needs to be adressed; I think the new behaviour is wrong.

@sigmavirus24

It's impossible to maintain something when one person needs to approve everything

I agree that we should not have a rule like that. It depends on the kind of PR, though.
In the end, there is a person or a group of persons responsible for the release, and everone of those should be aware of the changes. If it's a big API change, this should be discussed with everybody of the team.

the people doing the work don't have a say in how the work is done

I fail to see evidence for this. (But note that I started following pyyaml only a few months ago)

It doesn't matter. I left the org. I'm abandoning this project. If someone is supposed to be the lead on a project, they're the lead on a project and should be able to make controversial decisions without needing everyone's permission who has ever been adjacent to the project. I'm ignoring this project, so mentioning me will no longer generate notifications.

This is unfortunate. Removing a release from the index is a faux pas, PyPI should be considered immutable unless it's an emergency - better to release a 5.0 if it was deemed absolutely necessary to break from 4.x.

merged in ccc40f3