I've read through yaml-cpp and can see the benefits: it sticks to C++ things and is remarkably readable. There's a lot of tests.
But there's six CVEs that have been completely ignored. While at least some of the CVEs wouldn't affect Mir's use (no one is going to feed Mir a config file with a few thousand '{' or '[' characters) once it's in main we'd need to assess issues from perspective of all consumers.
I have to wonder if this package has seen sufficient real-world use.
Would the Mir team be in a position to work with upstream on addressing these issues? If we accept yaml-cpp into main it'd be nice to have these issues addressed before 20.04 LTS.
xnox, raof, many thanks for your replies earlier.
I've read through yaml-cpp and can see the benefits: it sticks to C++ things and is remarkably readable. There's a lot of tests.
But there's six CVEs that have been completely ignored. While at least some of the CVEs wouldn't affect Mir's use (no one is going to feed Mir a config file with a few thousand '{' or '[' characters) once it's in main we'd need to assess issues from perspective of all consumers.
CVE-2017-11692 is extremely poor error handling.
https:/ /github. com/jbeder/ yaml-cpp/ issues/ 519 CVE-2017-11692 /github. com/jbeder/ yaml-cpp/ issues/ 459 CVE-2017-5950 /github. com/jbeder/ yaml-cpp/ issues/ 655 CVE-2018-20573 /github. com/jbeder/ yaml-cpp/ issues/ 654 CVE-2018-20574 /github. com/jbeder/ yaml-cpp/ issues/ 660 CVE-2019-6285 /github. com/jbeder/ yaml-cpp/ issues/ 657 CVE-2019-6292
https:/
https:/
https:/
https:/
https:/
FORTIFY_SOURCE is missing from the build logs.
I have to wonder if this package has seen sufficient real-world use.
Would the Mir team be in a position to work with upstream on addressing these issues? If we accept yaml-cpp into main it'd be nice to have these issues addressed before 20.04 LTS.
Thanks