You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(101) |
Jun
(157) |
Jul
(89) |
Aug
(135) |
Sep
(17) |
Oct
(86) |
Nov
(410) |
Dec
(311) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(76) |
Feb
(100) |
Mar
(139) |
Apr
(138) |
May
(234) |
Jun
(178) |
Jul
(271) |
Aug
(286) |
Sep
(816) |
Oct
(50) |
Nov
(28) |
Dec
(137) |
2003 |
Jan
(62) |
Feb
(25) |
Mar
(97) |
Apr
(34) |
May
(35) |
Jun
(32) |
Jul
(32) |
Aug
(57) |
Sep
(67) |
Oct
(176) |
Nov
(36) |
Dec
(37) |
2004 |
Jan
(20) |
Feb
(93) |
Mar
(16) |
Apr
(36) |
May
(59) |
Jun
(48) |
Jul
(20) |
Aug
(154) |
Sep
(868) |
Oct
(41) |
Nov
(63) |
Dec
(60) |
2005 |
Jan
(59) |
Feb
(15) |
Mar
(16) |
Apr
(14) |
May
(19) |
Jun
(16) |
Jul
(25) |
Aug
(19) |
Sep
(7) |
Oct
(12) |
Nov
(18) |
Dec
(41) |
2006 |
Jan
(16) |
Feb
(65) |
Mar
(51) |
Apr
(75) |
May
(38) |
Jun
(25) |
Jul
(23) |
Aug
(16) |
Sep
(24) |
Oct
(3) |
Nov
(1) |
Dec
(10) |
2007 |
Jan
(4) |
Feb
(5) |
Mar
(7) |
Apr
(29) |
May
(38) |
Jun
(3) |
Jul
(1) |
Aug
(17) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(16) |
2008 |
Jan
(11) |
Feb
(4) |
Mar
(7) |
Apr
(48) |
May
(17) |
Jun
(9) |
Jul
(6) |
Aug
(12) |
Sep
(5) |
Oct
(7) |
Nov
(4) |
Dec
(11) |
2009 |
Jan
(15) |
Feb
(28) |
Mar
(12) |
Apr
(44) |
May
(6) |
Jun
(16) |
Jul
(6) |
Aug
(37) |
Sep
(107) |
Oct
(24) |
Nov
(30) |
Dec
(22) |
2010 |
Jan
(8) |
Feb
(16) |
Mar
(11) |
Apr
(28) |
May
(9) |
Jun
(26) |
Jul
(7) |
Aug
(25) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(5) |
Feb
(6) |
Mar
(3) |
Apr
(2) |
May
(10) |
Jun
(44) |
Jul
(11) |
Aug
(8) |
Sep
(6) |
Oct
(42) |
Nov
(19) |
Dec
(5) |
2012 |
Jan
(23) |
Feb
(8) |
Mar
(9) |
Apr
(11) |
May
(2) |
Jun
(11) |
Jul
|
Aug
(18) |
Sep
(1) |
Oct
(15) |
Nov
(14) |
Dec
(8) |
2013 |
Jan
(5) |
Feb
(13) |
Mar
(2) |
Apr
(10) |
May
|
Jun
(6) |
Jul
(17) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(11) |
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
(10) |
Apr
(12) |
May
(1) |
Jun
(9) |
Jul
(27) |
Aug
(5) |
Sep
(13) |
Oct
(9) |
Nov
(9) |
Dec
|
2015 |
Jan
(8) |
Feb
(5) |
Mar
(1) |
Apr
(10) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(1) |
Dec
(6) |
2016 |
Jan
(12) |
Feb
(12) |
Mar
(133) |
Apr
(7) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
(5) |
Dec
|
2017 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(2) |
Aug
(2) |
Sep
(8) |
Oct
(2) |
Nov
(8) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(2) |
Mar
(6) |
Apr
|
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(2) |
2020 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(6) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
(5) |
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
|
Aug
(5) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(4) |
2022 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(1) |
2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matt D. <mr...@re...> - 2021-01-14 22:20:06
|
======================= Announcing PyYAML-5.4b2 ======================= A beta release of PyYAML is now available: https://github.com/yaml/pyyaml/releases/tag/5.4b2 This release contains a security fix for CVE-2020-14343. It removes the python/module, python/object, and python/object/new tags from the FullLoader. YAML that uses these tags must be loaded by UnsafeLoader, or a custom loader that has explicitly enabled them. This beta release also adds Python wheels for manylinux1 (x86_64) and MacOS (x86_64) with the libyaml extension included (built on libyaml 0.2.5). We believe these wheels to be stable, but please take the opportunity to test against your local Linux and MacOS environments, and file any issues at https://github.com/yaml/pyyaml/issues. PyYAML 5.4 will be the last release to support Python 2.7. Changes ======= * https://github.com/yaml/pyyaml/pull/407 -- build modernization, remove distutils, fix metadata, build wheels, CI to GHA * https://github.com/yaml/pyyaml/pull/472 -- fix for CVE-2020-14343, moves arbitrary python tags to UnsafeLoader * https://github.com/yaml/pyyaml/pull/441 -- fix memory leak in implicit resolver setup * https://github.com/yaml/pyyaml/pull/392 -- fix py2 copy support for timezone objects * https://github.com/yaml/pyyaml/pull/378 -- fix compatibility with Jython Resources ========= PyYAML IRC Channel: #pyyaml on irc.freenode.net PyYAML homepage: https://github.com/yaml/pyyaml PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation Source and binary installers: https://pypi.org/project/PyYAML/ GitHub repository: https://github.com/yaml/pyyaml/ Bug tracking: https://github.com/yaml/pyyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About PyYAML ============ YAML is a data serialization format designed for human readability and interaction with scripting languages. PyYAML is a YAML parser and emitter for Python. PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support, capable extension API, and sensible error messages. PyYAML supports standard YAML tags and provides Python-specific tags that allow to represent an arbitrary Python object. PyYAML is applicable for a broad range of tasks from complex configuration files to object serialization and persistence. Example ======= >>> import yaml >>> yaml.full_load(""" ... name: PyYAML ... description: YAML parser and emitter for Python ... homepage: https://github.com/yaml/pyyaml ... keywords: [YAML, serialization, configuration, persistence, pickle] ... """) {'keywords': ['YAML', 'serialization', 'configuration', 'persistence', 'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'} >>> print(yaml.dump(_)) name: PyYAML homepage: https://github.com/yaml/pyyaml description: YAML parser and emitter for Python keywords: [YAML, serialization, configuration, persistence, pickle] Maintainers =========== The following people are currently responsible for maintaining PyYAML: * Ingy döt Net * Matt Davis and many thanks to all who have contribributed! See: https://github.com/yaml/pyyaml/pulls Copyright ========= Copyright (c) 2017-2021 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The PyYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML and Python communities. PyYAML is released under the MIT license. See the file LICENSE for more details. |
From: joylix <jo...@12...> - 2020-10-04 11:15:17
|
Dear all: How to I implement the variable assignment as follows: inputData is in [ 9, 8, 7, 5 ] var1= [ 93, 86, 74, 52 ] outputData = var1[indexofInputData] for example: when inputData=9, outputData= var1[0]=93 when inputData=7, outputData= var1[2]=74 How to implement this expression in yaml? Thank you! |
From: Tina M. <po...@ti...> - 2020-06-01 22:09:42
|
========================= Announcing LibYAML-0.2.5 ========================= A new release of LibYAML is now available: https://github.com/yaml/libyaml/tree/0.2.5 The LibYAML project is now maintained by the YAML community. Planning happens on the #yaml-dev and #libyaml IRC channels on irc.freenode.net. Changes ======= https://github.com/yaml/libyaml/pull/187 Add -h and --flow (on|off|keep) to run-*-test-suite https://github.com/yaml/libyaml/pull/182 Remove unnecessary include and malloc https://github.com/yaml/libyaml/pull/177 Add specific files back to .gitignore https://github.com/yaml/libyaml/pull/181 Output error position in run-parser-test-suite.c https://github.com/yaml/libyaml/pull/105 Allow question marks in plain scalars in flow collections https://github.com/yaml/libyaml/pull/186 Emitter: Don't output trailing space for empty scalar nodes https://github.com/yaml/libyaml/pull/185 Emitter: Output space after an alias mapping key https://github.com/yaml/libyaml/pull/191 A couple patches to improve test suite support Resources ========= LibYAML IRC Channel: #libyaml on irc.freenode.net LibYAML homepage: https://github.com/yaml/libyaml Source download: https://github.com/yaml/libyaml/archive/dist-0.2.3.zip GitHub repository: https://github.com/yaml/libyaml Bug tracking: https://github.com/yaml/libyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About LibYAML ============= YAML is a data serialization format designed for human readability and interaction with scripting languages. LibYAML is a C library for parsing and emitting YAML. LibYAML is the underlying parser/emitter code for YAML frameworks in many programming languages. Maintainers =========== The following people are responsible for maintaining LibYAML: * Ingy döt Net and many thanks to all who have contribributed! See: https://github.com/yaml/libyaml/pulls Copyright ========= Copyright (c) 2017-2020 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The LibYAML module was written by Kirill Simonov. It is currently maintained by the YAML community. LibYAML is released under the MIT license. See the file LICENSE for more details. |
From: Tina M. <po...@ti...> - 2020-04-19 11:35:46
|
========================= Announcing LibYAML-0.2.4 ========================= A new release of LibYAML is now available: https://github.com/yaml/libyaml/tree/0.2.4 This fixes a bug introduced in the 0.2.3 release. The LibYAML project is now maintained by the YAML community. Planning happens on the #yaml-dev and #libyaml IRC channels on irc.freenode.net. Changes ======= https://github.com/yaml/libyaml/pull/143 -- Add packaging/docker-dist to Makefile.am https://github.com/yaml/libyaml/pull/174 -- Fix logic for document end before directive Resources ========= LibYAML IRC Channel: #libyaml on irc.freenode.net LibYAML homepage: https://github.com/yaml/libyaml Source download: https://github.com/yaml/libyaml/archive/dist-0.2.3.zip GitHub repository: https://github.com/yaml/libyaml Bug tracking: https://github.com/yaml/libyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About LibYAML ============= YAML is a data serialization format designed for human readability and interaction with scripting languages. LibYAML is a C library for parsing and emitting YAML. LibYAML is the underlying parser/emitter code for YAML frameworks in many programming languages. Maintainers =========== The following people are responsible for maintaining LibYAML: * Ingy döt Net * Tina Müller and many thanks to all who have contribributed! See: https://github.com/yaml/libyaml/pulls Copyright ========= Copyright (c) 2017-2020 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The LibYAML module was written by Kirill Simonov. It is currently maintained by the YAML community. LibYAML is released under the MIT license. See the file LICENSE for more details. |
From: Tina M. <po...@ti...> - 2020-04-11 18:07:07
|
========================= Announcing LibYAML-0.2.3 ========================= A new release of LibYAML is now available: https://github.com/yaml/libyaml/tree/0.2.3 The LibYAML project is now maintained by the YAML community. Planning happens on the #yaml-dev and #libyaml IRC channels on irc.freenode.net. Changes ======= - https://github.com/yaml/libyaml/pull/66 -- Change dllexport controlling macro to use _WIN32 - https://github.com/yaml/libyaml/pull/127 -- Avoid recursion in the document loader. - https://github.com/yaml/libyaml/pull/128 -- Squash a couple of warnings in example-deconstructor-alt - https://github.com/yaml/libyaml/pull/130 -- Fixed typo. - https://github.com/yaml/libyaml/pull/140 -- Use pointer to const for strings that aren't/shouldn't be modified - https://github.com/yaml/libyaml/pull/144 -- Fix typo in comment - https://github.com/yaml/libyaml/pull/151 -- Fix spelling for error message - https://github.com/yaml/libyaml/pull/155 -- include/yaml.h: fix comments - https://github.com/yaml/libyaml/pull/157 -- change cmake target name from libOFF.a to libyaml.a - https://github.com/yaml/libyaml/pull/159 -- Add CHANGES file - https://github.com/yaml/libyaml/pull/160 -- Always output document end before directive (YAML 1.2 compatibility) - https://github.com/yaml/libyaml/pull/161 -- Make appveyor config be a hidden file - https://github.com/yaml/libyaml/pull/162 -- Output document end marker after open ended scalars - https://github.com/yaml/libyaml/pull/169 -- Fixed missing token in example - https://github.com/yaml/libyaml/pull/172 -- Support %YAML 1.2 directives Resources ========= LibYAML IRC Channel: #libyaml on irc.freenode.net LibYAML homepage: https://github.com/yaml/libyaml Source download: https://github.com/yaml/libyaml/archive/dist-0.2.3.zip GitHub repository: https://github.com/yaml/libyaml Bug tracking: https://github.com/yaml/libyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About LibYAML ============= YAML is a data serialization format designed for human readability and interaction with scripting languages. LibYAML is a C library for parsing and emitting YAML. LibYAML is the underlying parser/emitter code for YAML frameworks in many programming languages. Maintainers =========== The following people are responsible for maintaining LibYAML: * Ingy döt Net * Tina Müller and many thanks to all who have contribributed! See: https://github.com/yaml/libyaml/pulls Copyright ========= Copyright (c) 2017-2020 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The LibYAML module was written by Kirill Simonov. It is currently maintained by the YAML community. LibYAML is released under the MIT license. See the file LICENSE for more details. |
From: Oliver B. F. <o.b...@sw...> - 2020-04-03 09:26:44
|
Hi 方垚, because the resources section is a part of the configuration of the Maven resources plugin, which is responsible for copying and filtering resources. => http://maven.apache.org/plugins/maven-resources-plugin/ Am 02.04.20 um 12:12 schrieb 方垚: > Hi Oliver > Thank you reply so much. > in fact, I have resolved the build. but I still confuse it throw > exception when I add red block > <build> > <plugins> > <plugin> > <groupId>org.springframework.boot</groupId> > <artifactId>spring-boot-maven-plugin</artifactId> > </plugin> > </plugins> > <resources> <resource> </resource></resources> > </build> > Do you have any other mind? > > > 方垚 > fy_...@16... > > <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=%E6%96%B9%E5%9E%9A&uid=fy_kenny%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22fy_kenny%40163.com%22%5D> > > 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> > 定制 > On 4/2/2020 15:22,Oliver B. Fischer<o.b...@sw...> > <mailto:o.b...@sw...> wrote: > > Hi, > > this seems to be a problem of you build. 'project.artifactId' is a > Maven property. I think it was intended to replace > @project.artifactId@ with its actual value during a Maven run. It > seems so that you use the unprocessed application.yaml with the > placeholder. > > Please check your build and IDE setup. > > Oliver > > Am 02.04.20 um 05:29 schrieb 方垚: >> Caused by: org.yaml.snakeyaml.scanner.ScannerException: while >> scanning for the next token >> found character '@' that cannot start any token. (Do not use @ >> for indentation) >> in 'reader', line 3, column 11: >> name: @project.artifactId@ >> >> >> 方垚 >> fy_...@16... >> >> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=%E6%96%B9%E5%9E%9A&uid=fy_kenny%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22fy_kenny%40163.com%22%5D> >> >> 签名由 网易邮箱大师 >> <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 >> >> >> _______________________________________________ >> Yaml-core mailing list >> Yam...@li... >> https://lists.sourceforge.net/lists/listinfo/yaml-core > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E o.b...@sw... > S oliver.b.fischer > J oli...@ja... > X http://xing.to/obf > -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b...@sw... S oliver.b.fischer J oli...@ja... X http://xing.to/obf |
From: 方垚 <fy_...@16...> - 2020-04-02 10:12:16
|
Hi Oliver Thank you reply so much. in fact, I have resolved the build. but I still confuse it throw exception when I add red block <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> <resources> <resource> </resource> </resources> </build> Do you have any other mind? | | 方垚 | | fy_...@16... | 签名由网易邮箱大师定制 On 4/2/2020 15:22,Oliver B. Fischer<o.b...@sw...> wrote: Hi, this seems to be a problem of you build. 'project.artifactId' is a Maven property. I think it was intended to replace @project.artifactId@ with its actual value during a Maven run. It seems so that you use the unprocessed application.yaml with the placeholder. Please check your build and IDE setup. Oliver Am 02.04.20 um 05:29 schrieb 方垚: Caused by: org.yaml.snakeyaml.scanner.ScannerException: while scanning for the next token found character '@' that cannot start any token. (Do not use @ for indentation) in 'reader', line 3, column 11: name: @project.artifactId@ | | 方垚 | | fy_...@16... | 签名由网易邮箱大师定制 _______________________________________________ Yaml-core mailing list Yam...@li...https://lists.sourceforge.net/lists/listinfo/yaml-core -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b...@sw... S oliver.b.fischer J oli...@ja... X http://xing.to/obf |
From: Oliver B. F. <o.b...@sw...> - 2020-04-02 07:22:53
|
Hi, this seems to be a problem of you build. 'project.artifactId' is a Maven property. I think it was intended to replace @project.artifactId@ with its actual value during a Maven run. It seems so that you use the unprocessed application.yaml with the placeholder. Please check your build and IDE setup. Oliver Am 02.04.20 um 05:29 schrieb 方垚: > Caused by: org.yaml.snakeyaml.scanner.ScannerException: while scanning > for the next token > found character '@' that cannot start any token. (Do not use @ for > indentation) > in 'reader', line 3, column 11: > name: @project.artifactId@ > > > 方垚 > fy_...@16... > > <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=%E6%96%B9%E5%9E%9A&uid=fy_kenny%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22fy_kenny%40163.com%22%5D> > > 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> > 定制 > > > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b...@sw... S oliver.b.fischer J oli...@ja... X http://xing.to/obf |
From: 方垚 <fy_...@16...> - 2020-04-02 03:29:28
|
Caused by: org.yaml.snakeyaml.scanner.ScannerException: while scanning for the next token found character '@' that cannot start any token. (Do not use @ for indentation) in 'reader', line 3, column 11: name: @project.artifactId@ | | 方垚 | | fy_...@16... | 签名由网易邮箱大师定制 |
From: Tina M. <po...@ti...> - 2020-03-18 22:06:59
|
======================= Announcing PyYAML-5.3.1 ======================= A new release of PyYAML is now available: https://pypi.org/project/PyYAML/ This release contains a security fix for CVE-2020-1747. FullLoader was still exploitable for arbitrary command execution. https://bugzilla.redhat.com/show_bug.cgi?id=1807367 Thanks to Riccardo Schirone (https://github.com/ret2libc) for both reporting this and providing the fixes to resolve it. Changes ======= * https://github.com/yaml/pyyaml/pull/386 -- Prevents arbitrary code execution during python/object/new constructor Resources ========= PyYAML IRC Channel: #pyyaml on irc.freenode.net PyYAML homepage: https://github.com/yaml/pyyaml PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation Source and binary installers: https://pypi.org/project/PyYAML/ GitHub repository: https://github.com/yaml/pyyaml/ Bug tracking: https://github.com/yaml/pyyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About PyYAML ============ YAML is a data serialization format designed for human readability and interaction with scripting languages. PyYAML is a YAML parser and emitter for Python. PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support, capable extension API, and sensible error messages. PyYAML supports standard YAML tags and provides Python-specific tags that allow to represent an arbitrary Python object. PyYAML is applicable for a broad range of tasks from complex configuration files to object serialization and persistence. Example ======= >>> import yaml >>> yaml.full_load(""" ... name: PyYAML ... description: YAML parser and emitter for Python ... homepage: https://github.com/yaml/pyyaml ... keywords: [YAML, serialization, configuration, persistence, pickle] ... """) {'keywords': ['YAML', 'serialization', 'configuration', 'persistence', 'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'} >>> print(yaml.dump(_)) name: PyYAML homepage: https://github.com/yaml/pyyaml description: YAML parser and emitter for Python keywords: [YAML, serialization, configuration, persistence, pickle] Maintainers =========== The following people are currently responsible for maintaining PyYAML: * Tina Mueller * Ingy döt Net * Matt Davis and many thanks to all who have contribributed! See: https://github.com/yaml/pyyaml/pulls Copyright ========= Copyright (c) 2017-2020 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The PyYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML and Python communities. PyYAML is released under the MIT license. See the file LICENSE for more details. |
From: Oliver B. F. <o.b...@sw...> - 2020-03-18 15:34:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear all, I wonder if a YAML document can have more then one map, sequence or scalar as top level node. Actually I thought not as I cannot imaging how such a document would look like. But after having a look the the SnakeYAML Engine it seems possible. So, is hit possible and can some one provide an example document? Best, Oliver P.S.: Stay healthy! - -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b...@sw... S oliver.b.fischer J oli...@ja... X http://xing.to/obf -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEU7j685HGR9cAsMGwB88X6wLziPwFAl5yM5QACgkQB88X6wLz iPwNdg/9Ga6g55gpFHW6NqTpAWTL8bsyp0DuQ2rRTGiSOO47kppA6j5YQQdcAmN8 c49KTdFogZzu55CsQaALlhwk85ZlPFnMxt8OIo6KZT5f9DjTtvYTBb8w2QqKqIOy mARNzGt7DsuJ29/r+xV0Pq8CXzNaJ5n4VU5rhKdx5xuGBfcPyHYj4OKDZuD+CFYY 2HwnAbc34O/MoZWEVBikphQY10HzM0rOtPMuomT+9FxurSQd3nlRHdLzcFihMRcA OsfvORcdngpz6MGGB5wD7hRtm5zKsjIA8nv0OEkRkEK51qW5r3Rkq9q5bOitjTgU U1iyedsjPztWVq24ycuRbE6yIlihf3dUWdp5Z2f6yloSrrOmh6bt7CdfhzdMuLR7 YZWd9a+lFCWvDiPJW/dIxL9zS+b9RG4JU9OeoB0/gKWbVaS6Zy5+eMFhl70U5ksq tkLAzXoqSZ18nQqYl/NGRa9alkAR5B4sW4mVZTJYXnMbgW/gQXqDRbScTjGIbp8O lcejayinIQ3+2vyIQn92SyNRoBIOHijqP9PaE/f0jgGbKsqgsogGrvgmlZWiVF2D 3sBMzwZCtM60YoCcR0uF/mL5Ufnbl1RId/AKRXDzEvcxRhCi1YdY/UrvBJu2bpem Qx1vShhNNUA1miJZ3kRydQQhHGWYJhRxOvI4/FNJM6+LwFaRUF4= =Krbo -----END PGP SIGNATURE----- |
From: Aniket P. <ma...@fe...> - 2020-01-14 05:46:45
|
Hello PyYaml team! Thanks a lot for the amazing tool/library. Great work! Whilst using PyYaml, I had some queries on how the library serializes different objects. For our purposes, we were using the `datetime` library and were having some issues with it. For example, we were dumping a `datetime.date` [0] object and the resultant output showed that it was being serialized as a string, whereas a similar object of type `datetime.time` [1] is being serialized as a binary object ('!!python/object/apply:datetime.time\n- !!binary |\n DAwMAAAA\n'). I am interested in finding out how PyYaml serializes the two very similar classes so differently. Both of these classes have implemented almost the same methods (__str__, __repr__). Logs for more information: ---------------------------------------------------------------------------- # I have used the default dumper, (yaml.dump()) method. >>> d = datetime.date.today() >>> d datetime.date(2020, 1, 14) >>> yaml.dump(d) '2020-01-14\n...\n' >>> datetime.time(12, 12, 12) datetime.time(12, 12, 12) >>> t = datetime.time(12, 12, 12) >>> t datetime.time(12, 12, 12) >>> yaml.dump(t) '!!python/object/apply:datetime.time\n- !!binary |\n DAwMAAAA\n' ---------------------------------------------------------------------------- [0]: https://github.com/python/cpython/blob/3.8/Lib/datetime.py#L789 [1]:https://github.com/python/cpython/blob/3.8/Lib/datetime.py#L1211 -- Thanks Regards Aniket Pradhan http://home.iiitd.edu.in/~aniket17133/ Aliases: MeWjOr/major () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments P.S. I know I can write a custom dumper for `datetime.time` objects, but was wondering what is the reason that two almost similar classes are being serialized so differently. |
From: Tina M. <po...@ti...> - 2020-01-06 20:33:35
|
======================= Announcing PyYAML-5.3 ======================= A new release of PyYAML is now available: https://pypi.org/project/PyYAML/ This release contains some bugfixes (handling of slots, enable unicode for maxunicode < 0xffff, enable large files), enhancements (create timezone aware datetimes) and some other small enhancements. Changes ======= * https://github.com/yaml/pyyaml/pull/290 -- Use `is` instead of equality for comparing with `None` * https://github.com/yaml/pyyaml/pull/270 -- fix typos and stylistic nit * https://github.com/yaml/pyyaml/pull/309 -- Fix up small typo * https://github.com/yaml/pyyaml/pull/161 -- Fix handling of __slots__ * https://github.com/yaml/pyyaml/pull/358 -- Allow calling add_multi_constructor with None * https://github.com/yaml/pyyaml/pull/285 -- Add use of safe_load() function in README * https://github.com/yaml/pyyaml/pull/351 -- Fix reader for Unicode code points over 0xFFFF * https://github.com/yaml/pyyaml/pull/360 -- Enable certain unicode tests when maxunicode not > 0xffff * https://github.com/yaml/pyyaml/pull/359 -- Use full_load in yaml-highlight example * https://github.com/yaml/pyyaml/pull/244 -- Document that PyYAML is implemented with Cython * https://github.com/yaml/pyyaml/pull/329 -- Fix for Python 3.10 * https://github.com/yaml/pyyaml/pull/310 -- increase size of index, line, and column fields * https://github.com/yaml/pyyaml/pull/260 -- remove some unused imports * https://github.com/yaml/pyyaml/pull/163 -- Create timezone-aware datetimes when parsed as such * https://github.com/yaml/pyyaml/pull/363 -- Add tests for timezone Resources ========= PyYAML IRC Channel: #pyyaml on irc.freenode.net PyYAML homepage: https://github.com/yaml/pyyaml PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation Source and binary installers: https://pypi.org/project/PyYAML/ GitHub repository: https://github.com/yaml/pyyaml/ Bug tracking: https://github.com/yaml/pyyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About PyYAML ============ YAML is a data serialization format designed for human readability and interaction with scripting languages. PyYAML is a YAML parser and emitter for Python. PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support, capable extension API, and sensible error messages. PyYAML supports standard YAML tags and provides Python-specific tags that allow to represent an arbitrary Python object. PyYAML is applicable for a broad range of tasks from complex configuration files to object serialization and persistence. Example ======= >>> import yaml >>> yaml.full_load(""" ... name: PyYAML ... description: YAML parser and emitter for Python ... homepage: https://github.com/yaml/pyyaml ... keywords: [YAML, serialization, configuration, persistence, pickle] ... """) {'keywords': ['YAML', 'serialization', 'configuration', 'persistence', 'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'} >>> print(yaml.dump(_)) name: PyYAML homepage: https://github.com/yaml/pyyaml description: YAML parser and emitter for Python keywords: [YAML, serialization, configuration, persistence, pickle] Maintainers =========== The following people are currently responsible for maintaining PyYAML: * Ingy döt Net * Tina Mueller * Matt Davis and many thanks to all who have contribributed! See: https://github.com/yaml/pyyaml/pulls Copyright ========= Copyright (c) 2017-2019 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The PyYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML and Python communities. PyYAML is released under the MIT license. See the file LICENSE for more details. |
From: Oliver B. F. <o.b...@sw...> - 2020-01-05 22:49:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Tina, thank you for your answer. I wasn't sure how to interpret the spec. Greetings back from Berlin ;-) Oliver Am 04.01.20 um 21:43 schrieb Tina Müller: > Hi Oliver, > > On Sat, 4 Jan 2020, Oliver B. Fischer wrote: > >> What references the alias in the following document? >> >> - --- >> - - k1: v2 >> - - &a k2: v2 >> >> .... >> >> Is alias "a" a reference only to the key node or to the key value pair? > > The alias is for the key. > If you want to create an alias for a (block) mapping or sequence, the alias > must be followed by a newline. If there is no newline, the alias always > references the following node. > > Greetings from Berlin to Berlin ;-) > > cheers, > tina > - -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b...@sw... S oliver.b.fischer J oli...@ja... X http://xing.to/obf -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEU7j685HGR9cAsMGwB88X6wLziPwFAl4SZ98ACgkQB88X6wLz iPytOQ/+MjJrM02iSOKAcQFHvMfWDSAZasjeBQ7HQ1C0GD/NmwToGKg+Di2wYaIn JkVJS/n3aL5VIR8UgBoZNE/2gADHn6yx6O5lndMY1PH8OJcX3Vn9Ll+J443fmp62 u+HQkDr94FTYBw7QS8Ky5e/TnR2t+Ym77xrTtfNCci7cL/g48s/6TvII/X8fiY3W 9RpMZ0BiKdzXW3Q7UFYOol2ORMM9PgEjzxob3e2iZoEBOoC70ZMLsnAgyEYekRkJ uI5jm/XWC/ZyqrZuX3Hr6FqlZr3IzduxDRDUuUlNCNuUpaNmp3ZIs1GWWb9YFJq+ x64ye2iHMGzzwYnqd+XEBa+/vwriVFtYyrnEv0sOYjtdlj7zvHgBOG2k36cx3zP3 beIiKjSvGAwgSqQegNH8V/czX2lVkfQrQ1gOuj+rZgOGEGjxE69hRGoqju6LdevL ls3DiS0AwlH19kJBVRSMrXhmKWbQkQlFB7wn39RYFilzkStBcrw6nUtcPe03Ia9q 3hACT/VfwdxoVoPiRpW/MNfZX8+SZeC0RtM8YPZWzXAAtHmXb0gX1wtKCrxg7e5r zJr3U9WGDSextEJRkr9jJttYaEa3JQHDChqcZ601knIf2G4n19bDM4w5XI59EakC nW9X5VD987k/61dO0tdqo8/TcEv9dIRL0tKFkRkEMwN9AP8O+ZU= =1dc1 -----END PGP SIGNATURE----- |
From: Tina M. <po...@ti...> - 2020-01-04 20:44:02
|
Hi Oliver, On Sat, 4 Jan 2020, Oliver B. Fischer wrote: > What references the alias in the following document? > > - --- > - - k1: v2 > - - &a k2: v2 > > .... > > Is alias "a" a reference only to the key node or to the key value pair? The alias is for the key. If you want to create an alias for a (block) mapping or sequence, the alias must be followed by a newline. If there is no newline, the alias always references the following node. Greetings from Berlin to Berlin ;-) cheers, tina |
From: Oliver B. F. <o.b...@sw...> - 2020-01-04 18:59:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear all, I am writing a plugin for jQAssistant (https://jqassistant.org/) to parse YAML files and to create a graph model from a YAML document. Currently I am adding support for aliases and anchors to the plugin. What references the alias in the following document? - --- - - k1: v2 - - &a k2: v2 .... Is alias "a" a reference only to the key node or to the key value pair? I hope you can help to implement my plugin correctly. Bye, Oliver - -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b...@sw... S oliver.b.fischer J oli...@ja... X http://xing.to/obf -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEU7j685HGR9cAsMGwB88X6wLziPwFAl4Q3AkACgkQB88X6wLz iPxGRg//TPB8RO2fZrYsFG2vaEvCfD39O70H1ovoEep7wxGWC8htpvia/yQrxwnb Dh3zzqj88Srv3qQJddYaqI5xj3QvPowGeAG+MLhO3VvSWGj2bUdRQKBcR7dRCCSi torz48qTuNhsMkiSvhwbpX1GEjqE5wahm4j7xYiD2HOIud5E7YK8J1hoVJ9ZoDsz gVVI1glMmE4bXnCa24I853OuNponn+R4OE119OEHLPTpwctTdnXOI/oaVqAnRDEp SP0kNwu3QsPnyqQl5qRNR8+MmTLPkeP8+ETQ7zfC36SybQuczvwEsVzGuG6vfF3E mZ7KUWpuzUdEKuq12fV0QOO3j3iLWUUUBa8EOBE6WrKYQCAksXCUH1vJQVTLWYDy 9z3sVw40qynXBYqCDQ5PY/lfsSaxYqKfKxF5XHrVd3uPnE1aVgTppd6pwzR0Nnbh FWKdtj8A5IDVBe5YYDKmieEnUrEW4d/Ml5pY+bV9tqcRDDJ4S4SoCjS2urS129W1 RMhVTBBpD4FcJRF/qJEliRnecvYzLEucsWX7gcSKb6ZmX+HjUew9Qwqlrputmt6A pXOJjidL5xsHzVpk5fMFXnP7P91Pl5LztKctcAmd+0eECzE2kWxe0JvwSTT7q/FS Td7TMPHL7MMsjKZkRAuD24xZn757bY9slHYZv9TB0KrHOgM7FLQ= =iEFB -----END PGP SIGNATURE----- |
From: Trevor M. <tm...@re...> - 2019-12-03 22:08:53
|
Hello! I've seen that Python3 and some Golang libraries interpret the following differently, I'm wondering which is correct or if it's open to interpretation (I've searched the archives and looked at the spec but I'm not convinced either way) The case is a set of blank lines, followed by ---, for example a file containing: " --- name: bob " Does this represent a single document, with whitespace ignored, or two documents, with the first being empty? I've got a frontend and backend disagreeing :) Best regards, Trevor McKay |
From: Tina M. <po...@ti...> - 2019-12-02 22:21:56
|
======================= Announcing PyYAML-5.2 ======================= A new release of PyYAML is now available: https://pypi.org/project/PyYAML/ This fixes some incompatibilities introduced in version 5.1 and also removes another possibility of loading arbitrary code. Changes ======= * Repair incompatibilities introduced with 5.1. The default Loader was changed, but several methods like add_constructor still used the old default https://github.com/yaml/pyyaml/pull/279 -- A more flexible fix for custom tag constructors https://github.com/yaml/pyyaml/pull/287 -- Change default loader for yaml.add_constructor https://github.com/yaml/pyyaml/pull/305 -- Change default loader for add_implicit_resolver, add_path_resolver * Make FullLoader safer by removing python/object/apply from the default FullLoader https://github.com/yaml/pyyaml/pull/347 -- Move constructor for object/apply to UnsafeConstructor * Fix bug introduced in 5.1 where quoting went wrong on systems with sys.maxunicode <= 0xffff https://github.com/yaml/pyyaml/pull/276 -- Fix logic for quoting special characters * Other PRs: https://github.com/yaml/pyyaml/pull/280 -- Update CHANGES for 5.1 Resources ========= PyYAML IRC Channel: #pyyaml on irc.freenode.net PyYAML homepage: https://github.com/yaml/pyyaml PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation Source and binary installers: https://pypi.org/project/PyYAML/ GitHub repository: https://github.com/yaml/pyyaml/ Bug tracking: https://github.com/yaml/pyyaml/issues YAML homepage: http://yaml.org/ YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core About PyYAML ============ YAML is a data serialization format designed for human readability and interaction with scripting languages. PyYAML is a YAML parser and emitter for Python. PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support, capable extension API, and sensible error messages. PyYAML supports standard YAML tags and provides Python-specific tags that allow to represent an arbitrary Python object. PyYAML is applicable for a broad range of tasks from complex configuration files to object serialization and persistence. Example ======= >>> import yaml >>> yaml.full_load(""" ... name: PyYAML ... description: YAML parser and emitter for Python ... homepage: https://github.com/yaml/pyyaml ... keywords: [YAML, serialization, configuration, persistence, pickle] ... """) {'keywords': ['YAML', 'serialization', 'configuration', 'persistence', 'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'} >>> print(yaml.dump(_)) name: PyYAML homepage: https://github.com/yaml/pyyaml description: YAML parser and emitter for Python keywords: [YAML, serialization, configuration, persistence, pickle] Maintainers =========== The following people are currently responsible for maintaining PyYAML: * Ingy döt Net * Tina Mueller * Matt Davis and many thanks to all who have contribributed! See: https://github.com/yaml/pyyaml/pulls Copyright ========= Copyright (c) 2017-2019 Ingy döt Net <in...@in...> Copyright (c) 2006-2016 Kirill Simonov <xi...@re...> The PyYAML module was written by Kirill Simonov <xi...@re...>. It is currently maintained by the YAML and Python communities. PyYAML is released under the MIT license. See the file LICENSE for more details. |
From: James S. <uja...@gm...> - 2019-11-05 17:06:51
|
Hello I work on a project that wants to move to support heavily YAML in it binary tools. Currently I'm trying to take the tools arguments and build a YAML document around it. For example the YAML doc in human readable format would be *stats:* *- source: MGC172.30.248.30@tcp;* The code is: const char *group = "stats"; yaml_document_t request; memset(&request, *0*, *sizeof*(request)); *if* (!yaml_document_initialize(&request, *NULL*, *NULL*, *NULL*, * 1*, *1*)) *return* -*EINVAL*; map = yaml_document_add_mapping(&request, (yaml_char_t *)YAML_MAP_TAG, YAML_BLOCK_MAPPING_STYLE); *if* (!map) *return* -*EINVAL*; key = yaml_document_add_scalar(&request, (yaml_char_t *)YAML_STR_TAG, (yaml_char_t *)group, strlen(group), YAML_PLAIN_SCALAR_STYLE); *if* (!key) *return* -*EINVAL*; value = yaml_document_add_scalar(&request, (yaml_char_t *)YAML_STR_TAG, (yaml_char_t *)*""*, *0*, YAML_PLAIN_SCALAR_STYLE); *if* (!value) *return* -*EINVAL*; *if* (!yaml_document_append_mapping_pair(&request, map, key, value)) *return* -*EINVAL*; seq = yaml_document_add_sequence(&request, (yaml_char_t *)YAML_SEQ_TAG, YAML_BLOCK_SEQUENCE_STYLE); *if* (!seq) *return* -*EINVAL*; map = yaml_document_add_mapping(&request, (yaml_char_t *)YAML_MAP_TAG, YAML_BLOCK_MAPPING_STYLE); *if* (!map) *return* -*EINVAL*; *if* (!yaml_document_append_sequence_item(&request, seq,map)) *return* -*EINVAL*; key = yaml_document_add_scalar(&request, (yaml_char_t *)YAML_STR_TAG, (yaml_char_t *)*"source"*, *6*, YAML_PLAIN_SCALAR_STYLE); *if* (!key) *return* -*EINVAL*; value = yaml_document_add_scalar(&request, (yaml_char_t *)YAML_STR_TAG, (yaml_char_t*)*"MGC172.30.248.30@tcp"*, *20*, YAML_PLAIN_SCALAR_STYLE); *if* (!value) *return* -*EINVAL*; *if* (!yaml_document_append_mapping_pair(&request, map, key, value)) *return* -*EINVAL*; Currently only "stats:" is printed. I have searched for someone else doing this and it appears I'm the only one trying. Do you know what I'm doing wrong? Thank you. |
From: Leon T. <fa...@gm...> - 2019-10-31 18:06:22
|
On Wed, Oct 30, 2019 at 8:16 PM Shannon C <reh...@gm...> wrote: > > The `[+-]` of a float is optional in YAML 1.2's JSON schema tag resolution https://yaml.org/spec/1.2/spec.html#id2804356 and in YAML 1.2s core schema tag resolution https://yaml.org/spec/1.2/spec.html#id2805071. In YAML 1.1 it appeared to be required. > > This means that YAML 1.2 parses certain unquoted hex strings (git commits, hashes, etc.) as floats, for example: 504e199 would be parsed as a float instead of a string. This might be surprising if the YAML serialization library is not explicitly quoting strings or tagging them. > > I feel like this may be a weakness in the YAML 1.2 spec under 10.1.1.3 Generic String https://yaml.org/spec/1.2/spec.html#id2802842 where it describes the Canonical Form of strings glibly as "The obvious." I am not very familiar with how the spec works, but it seems to me that if there is no clearly described canonical form for strings, serialization tools are liable to produce output (like the example above) which does not produce accurate round-trip (reversible) serialization/deserialization. > > Is this an area which could be improved in the spec, so that YAML serializers are directed to serialize strings in a way which guarantees that it will deserialize back to the same thing? Barring that, is there any general advice for library authors or bug reporters about how serialization of such YAML strings should be performed, such as always quoting strings? Different yaml implementations use different schemas for plain nodes, some allow you to chose between schemas. If you want to be certain a string will be interpreted as a string in all implementations, quoting and tagging are indeed the obvious solutions. Leon |
From: Shannon C <reh...@gm...> - 2019-10-30 19:16:18
|
The `[+-]` of a float is optional in YAML 1.2's JSON schema tag resolution https://yaml.org/spec/1.2/spec.html#id2804356 and in YAML 1.2s core schema tag resolution https://yaml.org/spec/1.2/spec.html#id2805071. In YAML 1.1 it appeared to be required. This means that YAML 1.2 parses certain unquoted hex strings (git commits, hashes, etc.) as floats, for example: 504e199 would be parsed as a float instead of a string. This might be surprising if the YAML serialization library is not explicitly quoting strings or tagging them. I feel like this may be a weakness in the YAML 1.2 spec under 10.1.1.3 Generic String https://yaml.org/spec/1.2/spec.html#id2802842 where it describes the Canonical Form of strings glibly as "The obvious." I am not very familiar with how the spec works, but it seems to me that if there is no clearly described canonical form for strings, serialization tools are liable to produce output (like the example above) which does not produce accurate round-trip (reversible) serialization/deserialization. Is this an area which could be improved in the spec, so that YAML serializers are directed to serialize strings in a way which guarantees that it will deserialize back to the same thing? Barring that, is there any general advice for library authors or bug reporters about how serialization of such YAML strings should be performed, such as always quoting strings? Thanks! Shannon |
From: Sam F. <sf...@re...> - 2019-10-22 08:24:20
|
On 18/10/19 5:06 am, Felix Krause wrote: > I'll reiterate my point made on the related StackOverflow answer [1]: > > The YAML spec describes anchors & aliases as a way to (de-)serialize > graph structures in which a node is referenced by multiple other nodes > (also enabling cycles in the graph to be properly handled). > > The billion laughs attack that triggers the problematic behavior in > gopkg.in/yaml.v2 is caused by the implementation expanding aliases (i.e. > making copies of a node for each alias referencing it) instead of > linking to the node from multiple places as the specification suggests. > > The specification does not explicitly forbid this behavior. Rightfully > so (in my opinion), because not all programming languages do support > multiple references to a node; for example, a Python str is immutable > and therefore helper structures would be needed to represent a > modifyable !!str scalar node that is linked from multiple places in a > native Python structure. I assume this is the reason why PyYAML suffers > from the same behavior as described in the CVE. > > My conclusion is that on one hand, the issue emerges because of an > implementation choice that is in no way endorsed by the spec, so it does > not concern the spec. On the other hand, we see that there is at least > one other implementation (PyYAML) that suffers from this problem and > chances are that others do too since most YAML implementations are > rewrites of PyYAML. An implementation suggestion in the spec about this > problem might be a good idea. +1 for an implementation suggestion in the spec. My feeling is then that CVEs would be best assigned to individual implementations, in this instance gopkg.in/yaml.v2, perhaps with a disclaimer in the MITRE description text along the lines of: "The YAML version 1.2 spec does not prescribe whether or not node aliases should be expanded during deserialization." This would provide the benefits of CVE assignment (i.e. alerting users and projects to update to a non-vulnerable version), while also highlighting a gap in the specification. -- Sam Fowler, Red Hat Product Security |
From: Felix K. <ya...@fl...> - 2019-10-17 19:23:59
|
I'll reiterate my point made on the related StackOverflow answer [1]: The YAML spec describes anchors & aliases as a way to (de-)serialize graph structures in which a node is referenced by multiple other nodes (also enabling cycles in the graph to be properly handled). The billion laughs attack that triggers the problematic behavior in gopkg.in/yaml.v2 is caused by the implementation expanding aliases (i.e. making copies of a node for each alias referencing it) instead of linking to the node from multiple places as the specification suggests. The specification does not explicitly forbid this behavior. Rightfully so (in my opinion), because not all programming languages do support multiple references to a node; for example, a Python str is immutable and therefore helper structures would be needed to represent a modifyable !!str scalar node that is linked from multiple places in a native Python structure. I assume this is the reason why PyYAML suffers from the same behavior as described in the CVE. My conclusion is that on one hand, the issue emerges because of an implementation choice that is in no way endorsed by the spec, so it does not concern the spec. On the other hand, we see that there is at least one other implementation (PyYAML) that suffers from this problem and chances are that others do too since most YAML implementations are rewrites of PyYAML. An implementation suggestion in the spec about this problem might be a good idea. Regards, Felix Krause [1]: https://stackoverflow.com/a/58131348/347964 |
From: Sam F. <sf...@re...> - 2019-10-11 08:38:49
|
Hi yaml-core list members, I'm writing this to request input on the possibility of assigning a CVE to the YAML spec for the issue described in the below mail chain. The TL;DR is: * gopkg.in/yaml.v2 package was patched to address behaviour that allowed for excessive resource consumption (i.e. DoS) on crafted YAML input. * This usage of gopkg.in/yaml.v2 in kubernetes was assigned CVE-2019-11253 * gopkg.in/yaml.v2 is used in many golang projects, so I proposed assigning a CVE directly to gopkg.in/yaml.v2 * gopkg.in/yaml.v2 follows the YAML spec, which does not make any security considerations, hence this mail exploring the possibility of assigning a CVE to the YAML spec instead Any input or feedback is appreciated. Thanks, -- Sam Fowler, Red Hat Product Security On 11/10/19 5:42 pm, Gustavo Niemeyer wrote: > Sorry that this is painful, but option (a) is the only correct option. > If you go with (c) you'll force me to publicly explain why, which isn't > something I'm keen on focusing on right now. > > > On Fri, Oct 11, 2019, 05:55 Sam Fowler <sf...@re... > <mailto:sf...@re...>> wrote: > > Thanks for the replies. There's certainly a fair case to be made that > since the yaml spec makes no security considerations, it is flawed and > more deserving of CVE assignment than specific implementations. > > I then see three options: > > a) Assign a CVE to the YAML spec > b) Assign individual CVEs to projects that use gopkg.in/yaml.v2 > <http://gopkg.in/yaml.v2> in a > vulnerable way > c) Assign a CVE to gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> > > The recent set of HTTP/2 vulnerabilities[0] took a similar route to > option a) and assigned generic CVEs across all implementations. As > someone who worked downstream on these CVEs, my opinion is that this > was > the wrong move and was particularly cumbersome for pieces of code that > were vulnerable in multiple ways (e.g. both dependent on net/http and > gRPC). > > Option b) is fair in principle, but does not scale well. I am aware of > at least 100 different repositories used in Red Hat OpenShift that are > dependent on gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> and I > imagine that there are many more in > the wild. Potential individual CVE assignments adds a lot of overhead > for little benefit, in my view. > > Thus, my opinion is that option c) is the most pragmatic choice. This > could potentially lead to similar CVEs in other implementations (e.g. > libyaml, yaml-cpp, pyyaml, js-yaml) though I think that outcome is > reasonable and warranted if they indeed exhibit the same behaviour. > > If this is acceptable, I can proceed with option a) and assign a CVE > for > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2>. > > [I also added Doran Moppert from Red Hat to CC as an FYI] > > Thanks, > -- > Sam Fowler, Red Hat Product Security > > [0] https://tools.ietf.org/html/rfc7540#section-10.5 > > On 11/10/19 12:13 am, Jordan Liggitt wrote: > > Moving the list to bcc. This probably isn't that relevant for it > anyway > > since k8s already has a CVE covering the vulnerability. > > > > Vulnerability in the spec vs vulnerability in a library is > interesting. > > > > The JSON RFC explicitly permits parsers to limit nesting, precision, > > string size, etc - https://tools.ietf.org/html/rfc7159#section-9 > > The http/2 RFC has a security considerations > > <https://tools.ietf.org/html/rfc7540#section-10.5> section that > > describes attacks and explicitly permits mitigations, but many > > implementations were still vulnerable, and > non-implementation-specific > > CVEs were opened (https://kb.cert.org/vuls/id/605641/) > > The yaml spec <https://yaml.org/spec/current.html> has no security > > considerations section or notes permitting implementers to bound > > expansion/depth that I could find, so I'm not sure what the best > course > > of action there is. > > The corresponding XML expansion vulnerability has a CWE > > (https://cwe.mitre.org/data/definitions/776.html) but not an > overarching > > CVE. > > > > > > > > On Thu, Oct 10, 2019 at 10:00 AM Gustavo Niemeyer > <gu...@ni... <mailto:gu...@ni...> > > <mailto:gu...@ni... <mailto:gu...@ni...>>> wrote: > > > > For the record, I'm getting an error out of the > > "kubernetes-security-discuss" mailing list, because I'm not > subscribed. > > > > So nobody but you can see this reply. > > > > > > On Thu, Oct 10, 2019 at 2:58 PM Gustavo Niemeyer > > <gu...@ni... <mailto:gu...@ni...> > <mailto:gu...@ni... <mailto:gu...@ni...>>> wrote: > > > > > > The fix for this is to not accept certain valid documents, so > > this is a vulnerability in the specification more than it > is in > > the code. We are using heuristics to attempt to draw a line > > between what's something reasonable from something that > could be > > abuse or someone being naive. Even with that in place, if > your > > system accepts a large enough YAML document you may still > be in > > trouble, because that's the nature of variable expansion: it > > allows the document to grow non-linearly with its input size. > > > > That's a class of problem that I haven't seen CVEs being > > assigned to before, and it still feels somewhat wrong in this > > case. We're addressing the issue, by violating the > specification > > and preventing certain valid files from being parsed, > based on > > heuristics. I'm pragmatic and happy to collaborate on > trying to > > prevent abuse, as we did in this case, but if you want a > CVE for > > libraries handling data files per the specification, I'm > not the > > right person. > > > > > > > > > > > > On Thu, Oct 10, 2019 at 2:35 PM Jordan Liggitt > > <li...@go... <mailto:li...@go...> > <mailto:li...@go... <mailto:li...@go...>>> wrote: > > > > A CVE specific to the yaml library makes sense to me. > > > > On Thu, Oct 10, 2019 at 1:53 AM Sam Fowler > > <sf...@re... <mailto:sf...@re...> > <mailto:sf...@re... <mailto:sf...@re...>>> wrote: > > > > Hi Kubernetes PSC + go-yaml maintainers, > > > > Re $subject[0], I posted a comment on the PR for the > > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> <http://gopkg.in/yaml.v2> > > patch here[1]: > > > > > > "This patch partly comprises the k8s fix for > > CVE-2019-11253, which > > updates gopkg.in/yaml.v2 > <http://gopkg.in/yaml.v2> <http://gopkg.in/yaml.v2> to > > version 2.2.4. Presumably any repository > > that uses an earlier version of gopkg.in/yaml.v2 > <http://gopkg.in/yaml.v2> > > <http://gopkg.in/yaml.v2> and accepts untrusted > > YAML is similarly vulnerable. Rather than assigning > > individual CVEs for > > every repo that uses gopkg.in/yaml.v2 > <http://gopkg.in/yaml.v2> > > <http://gopkg.in/yaml.v2> in a vulnerable way, I am > > wondering if it makes more sense to assign a CVE > > directly to > > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> <http://gopkg.in/yaml.v2>. > > > > There is certainly an argument of "caveat > emptor": that > > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> <http://gopkg.in/yaml.v2> > > should not bear the responsibility of other > projects to > > accept untrusted > > YAML. However, assigning a new CVE direct to > > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> > <http://gopkg.in/yaml.v2> allows for > > those projects to be alerted of this patch and > potential > > vulnerability, > > which is essentially the same (i.e. allows for > excessive > > resource usage > > via crafted YAML). > > > > I can assist with CVE assignment for > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> > > <http://gopkg.in/yaml.v2>, if there are no > > objections." > > > > > > I believe timely CVE assignment is appropriate for > > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> > <http://gopkg.in/yaml.v2> as > > I'm aware of many repos and projects that use it (at > > least within Red > > Hat), and would like to deliver updates. However, I > > don't wish to > > proceed without agreement that this is the right > approach. > > > > So, are there any objections from the Kubernetes > PSC or > > go-yaml team to > > assigning a CVE for this package? > > > > [0] > https://github.com/kubernetes/kubernetes/issues/83253 > > [1] > > https://github.com/go-yaml/yaml/pull/515#issuecomment-540242856 > > > > > > Thanks, > > -- > > Sam Fowler, Red Hat Product Security > > > > -- > > You received this message because you are > subscribed to > > the Google Groups "kubernetes-security-discuss" > group. > > To unsubscribe from this group and stop receiving > emails > > from it, send an email to > > kub...@go... > <mailto:kubernetes-security-discuss%2Bu...@go...> > > > <mailto:kubernetes-security-discuss%2Bu...@go... > <mailto:kubernetes-security-discuss%252...@go...>>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/kubernetes-security-discuss/7d283c5b-f49e-96c2-7d56-1e08b3cfc8ac%40redhat.com. > > > > > > > > -- > > > > gustavo @ http://niemeyer.net > > > > > > > > -- > > > > gustavo @ http://niemeyer.net > > > |
From: Fred L. <fre...@gm...> - 2019-03-22 20:26:58
|