[Distutils] comparison of configuration languages

[Alex Grönholm]

08.05.2016, 02:08, Donald Stufft kirjoitti:
>
>> On May 7, 2016, at 7:05 PM, Alex Grönholm <alex.gronholm at nextday.fi 
>> <mailto:alex.gronholm at nextday.fi>> wrote:
>>
>> 07.05.2016, 17:48, Nick Coghlan kirjoitti:
>>>
>>>
>>> On 7 May 2016 13:00, "Nathaniel Smith" <njs at pobox.com> wrote:
>>> >
>>> > Here's that one-stop writeup/comparison of all the major configuration
>>> > languages that I mentioned:
>>> >
>>> >https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f
>>>
>>> Thanks for that, and "yikes" on the comment handling variations in 
>>> ConfigParser - you can tell I've never even tried to use end-of-line 
>>> comments in INI files, and apparently neither has anyone I've worked 
>>> with :)
>>>
>>> For YAML, my main concern isn't quirkiness of the syntax, or code 
>>> quality in PyYAML, it's the ease with which you can expose yourself 
>>> to security problems (even if *pip* loads the config file safely, 
>>> that doesn't mean every other tool will). Since we don't need the 
>>> extra power, the easiest way to reduce the collective attack surface 
>>> is to use a strictly less powerful (but still sufficient) format.
>>>
>> Sounds like a far-fetched hypothetical problem. You're concerned 
>> about the custom tags provided by PyYAML? Do you happen to know a 
>> tool that defaults to loading files in unsafe mode?
>
> Yea, pyYAML itself does (yaml.load() does it unsafely, you have to use 
> yaml.safe_load()).
>
> I don’t think it’s that big of a deal though, we could easily add a 
> thing to PyPI that rejects any YAML file that can’t be parsed in safe 
> mode. The bigger deal to me is just that the library to work with it 
> is a bit of a bear to use as a dependency.
Sounds like we'd need an alternate implementation of YAML then (I'd love 
to see a "yaml" module in the standard library too, but PyYAML isn't a 
good candidate for that, agreed).
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 
> 3372 DCFA
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160508/6fc599db/attachment-0001.html>