Skip Menu |
 

This queue is for tickets about the YAML-Syck CPAN distribution.

Report information
The Basics
Id: 35522
Status: resolved
Priority: 0/
Queue: YAML-Syck

People
Owner: Nobody in particular
Requestors: dagolden [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: LoadFile returns tainted data
Download (untitled) / with headers
text/plain 740b
In chasing a CPAN::PERL5INC bug, it became apparent that YAML::Syck was tainting data returned from LoadFile and YAML/YAML::Tiny weren't. Not sure what the right answer is, but the inconsistency should be addressed. Excerpt from my email about it to Schwern, Andreas and interested parties follows: Show quoted text
> Sorry -- I wasn't clear. CPAN::PERL5INC just gets a list of > directories from a YAML data file and unshifts them to @INC. It can > use any of the YAML modules that provide LoadFile(). > > The issue appears to be that YAML::Syck returns a tainted data > structure. It doesn't happen with YAML or YAML::Tiny. I would > presume that YAML and YAML::Tiny use regexes to parse the YAML file > and that leads to an untainted structure.
Download (untitled) / with headers
text/plain 2.1k
On Tue Apr 29 15:54:39 2008, DAGOLDEN wrote: Show quoted text
> In chasing a CPAN::PERL5INC bug, it became apparent that YAML::Syck
was Show quoted text
> tainting data returned from LoadFile and YAML/YAML::Tiny weren't. Not > sure what the right answer is, but the inconsistency should be > addressed. Excerpt from my email about it to Schwern, Andreas and > interested parties follows: >
> > Sorry -- I wasn't clear. CPAN::PERL5INC just gets a list of > > directories from a YAML data file and unshifts them to @INC. It can > > use any of the YAML modules that provide LoadFile(). > > > > The issue appears to be that YAML::Syck returns a tainted data > > structure. It doesn't happen with YAML or YAML::Tiny. I would > > presume that YAML and YAML::Tiny use regexes to parse the YAML file > > and that leads to an untainted structure.
I guess I could wrap Load* in Taint::Util::untaint(). Anyway, tests would be welcome. How do modules that normally parse things handle stuff under -T? Isn't it pretty incidental what is tainted and what not? Since filehandles are tainted by default and thus it's pretty much an implementation detail whether something gets untainted (i.e. whether it used regexes along the way). (This is a form-reply that isn't specific to your particular report) YAML::Syck has just acquired one new maintainer (me), it still doesn't have anyone that *cares* about it. But I'm willing to help solve your report & release a new version with the fix if it's easy for me. It now has a Git repository at: http://github.com/avar/YAML-Syck If your report is a patch that fixes a problem, great. Please remake the patch against Git by forking that repo and sending me a pull request on GitHub (or an update to this bug if you prefer git-format-patch(1) or some other repo provider..). Make sure to include a test for what you fixed. If your report is some code that fails (and you have a testcase for it) a patch against the test suite to demonstrate that failure would be very useful. It's OK if the test crashes and burns, see Test::More's docs for how to make TODO tests that fail now, but shouldn't. Even if it segfaults perl C<system $^X => qw/ -Mblib -MYAML::Syck .../> or something like that and checking the return value will do.
Download (untitled) / with headers
text/plain 238b
As I read this, it seems the implication is that YAML::Syck might be doing it right by tainting and the ones that don't might be doing it wrong. Is this something you want to see fixed? Or is CPAN now untainting the results on it's own?
Subject: Re: [rt.cpan.org #35522] LoadFile returns tainted data
Date: Mon, 19 Jul 2010 14:06:16 -0700
To: bug-YAML-Syck [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
Download (untitled) / with headers
text/plain 669b
On Mon, Jul 19, 2010 at 1:57 PM, Todd Rinaldo via RT <bug-YAML-Syck@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=35522 > > > As I read this, it seems the implication is that YAML::Syck might be doing it right by tainting and > the ones that don't might be doing it wrong. Is this something you want to see fixed? Or is > CPAN now untainting the results on it's own?
I don't think it's very useful to have a tainted data structure in typical usage, but the bug report was mostly that the various YAML::* modules all provide a "compatible" API and having YAML::Syck produce tainted data causes problems because of that inconsistency. -- David
On Mon Jul 19 17:06:44 2010, DAGOLDEN wrote: Show quoted text
> On Mon, Jul 19, 2010 at 1:57 PM, Todd Rinaldo via RT > <bug-YAML-Syck@rt.cpan.org> wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=35522 > > > > > As I read this, it seems the implication is that YAML::Syck might be
> doing it right by tainting and
> > the ones that don't might be doing it wrong. Is this something you
> want to see fixed? Or is
> > CPAN now untainting the results on it's own?
> > I don't think it's very useful to have a tainted data structure in > typical usage, but the bug report was mostly that the various YAML::* > modules all provide a "compatible" API and having YAML::Syck produce > tainted data causes problems because of that inconsistency.
I understand. Compatibility is nice in general, but it does sound like whatever code is assuming that the data from YAML::* isn't tainted is broken in the first place. Whether something gets untainted for you is really incidental, but maybe the other YAML::* maintainers made a conscious decision on this. What breaks because YAML::Syck doesn't auto-untaint under taint mode?
Ticket migrated to github as https://github.com/toddr/YAML-Syck/issues/29


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.