On Oct 13, 2009, at 9:58 PM, Markus Roberts wrote: > We already addressed the licensing question; the JSON gem's license > is compatible with ours, and permits this sort of bundling. > > The security implications are minimal since 1) the library is > primarily being used to exchange data internally between components > of the puppet system; there is the possibility that the generated > data could someday be made available to other programs, but that > would essentially be using it as an export format, 2) the endpoints > are already authenticating with SSL certs, 3) the ultimate source of > the data is under the user's control (site.pp and friends). > > All things considered, having a trusted serialization engine as part > of the provided stack is much lower risk than the default which > amounts to looking around for something called JSON in the search > path, loading it and hoping for the best. > > As for the upgrade issue, our concerns are pretty much the opposite > of what a distro maintainer faces (but analogous to what drove Rails > to bundle their JSON library). For a distro, you are packaging code > for others to use; and need to aim for a sort of "track the bleeding > edge as closely as possible but not too closely, and thus annoy > everyone equally" compromise; we, on the other hand, are packaging > code for internal use and need to worry first and foremost about > compatibility with other versions of puppet. We not only aren't > asking unrelated systems to use our bundled version we are actually > taking affirmative steps to keep them from using it by accident. > > We have users who can't use marshal because their clients and server > are running different versions of ruby, and this leads to > segfaults. We have users who can't use yaml because of similar > versioning issues (e.g. stock RHEL4 clients against RHEL5 servers) > which cause data corruption. We have users who can't use json > because of different json version (e.g. Rails on some machine, the > gem on others). And so on and so forth. > > What we need is a serialization format that we can manage on both > ends and guarantee the behavior of, regardless of what else happens > to be installed (or not installed) on the various machines.
Just to follow up on this - We've been wrestling with this problem internally since two weeks before 0.25 got released, and I expect we'll continue to wrestle with it until the next major release. It's a thorny issue made more thorny by Rails's insistence on not just shipping json but overriding any attempt to use the gem. By using methods named 'to_pson' et al, we essentially punt - we have our own serialization, but it's the standard lib with methods renamed, and we're not overriding anyone else's methods. This way we can provide consistency without worrying about conflicting with anyone else. We're all ears on better solutions, but this is the least crappy solution we could come up with. And let me tell you, we went through some crappy possibilities (most of which never made it past the "yes it's possible" phase). -- Learning is not attained by chance, it must be sought for with ardor and attended to with diligence. -- Abigail Adams --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
