On Tue, May 15, 2018 at 03:23:17PM +0200, Peter Krempa wrote: > On Tue, May 15, 2018 at 14:21:07 +0100, Daniel Berrange wrote: > > On Tue, May 15, 2018 at 03:05:55PM +0200, Peter Krempa wrote: > > > On Fri, May 11, 2018 at 14:59:04 +0200, Ján Tomko wrote: > > > > Yajl has not seen much activity upstream recently. > > > > > > [0] > > > > [snip] > > > [0] For anyone following current meme trends, this looks like it's > > > relevant to our YAJL->janson switch: > > > > > > https://i.redditmedia.com/J46fZN24lFx3fMRlJNpkNEOFqU79zWTsRDBMla1u0HE.jpg?s=4757d31d1cbd758962407917e0d3aacb > > > > If you think we should stay with YAJL because it "just works" then > > take a look at the bug reports against it upstream > > > > https://github.com/lloyd/yajl/issues > > > > double frees, memory leaks, parser gets stuck after parsing bad JSON, etc > > all ignored for years. The robustness of the JSON parser we use is > > critical to the security of the libvirt QEMU driver. I'm not saying > > janson is perfect, but it is at least maintained, so when problem in > > it as discovered, there's a real possibility to get them fixed, instead > > of ignored with the YAJL abandonware. > > No. I agree with the change, but "having serious flaws" is slightly > different than "not very active upstream". I don't think that makes much difference. All non-trivial software has serious flaws, especially if written in memory-unsafe languages like C. The only question is whether the flaws have been found yet. Given that, whether there is an active upstream maintaining it, is a key factor to decide whether to continue using something. The fact that we already see significant unfixed flaws just reinforces how important it is to have an active upstream. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
