b55297c679
Changelog: ========== [security] Fix a crash in DNS-over-HTTPS (DoH) code caused by premature TLS stream socket object deletion. (CVE-2022-1183) [GL #3216] [bug] RPZ NSIP and NSDNAME rule processing didn't handle stub and static-stub zones at or above the query name. This has now been addressed. [GL #3232] Fixed a deadlock that could occur if an rndc connection arrived during the shutdown of network interfaces. [GL #3272] Refactor the fctx_done() function to set fctx to NULL after detaching, so that reference counting errors will be easier to avoid. [GL #2969] udp_recv() in dispatch could trigger an INSIST when the callback's result indicated success but the response was canceled in the meantime. [GL #3300] Work around a jemalloc quirk which could trigger an out-of-memory condition in named over time. [GL #3287] If there was a pending negative cache DS entry, validations depending upon it could fail. [GL #3279] dig returned a 0 exit status on UDP connection failure. [GL #3235] Fix an assertion failure when using dig with +nssearch and +tcp options by starting the next query in the send_done() callback (like in the UDP mode) instead of doing that recursively in start_tcp(). Also ensure that queries interrupted while connecting are detached properly. [GL #3144] Don't remove CDS/CDNSKEY DELETE records on zone sign when using 'auto-dnssec maintain;'. [GL #2931] [contrib] Avoid name space collision in dlz modules by prefixing functions with 'dlz_'. [GL !5778] dlz: Add FALLTHROUGH and UNREACHABLE macros. [GL #3306] [func] Add new named command-line option -C to print built-in defaults. [GL #1326] Introduce the concept of broken catalog zones described in the DNS catalog zones draft version 5 document. [GL #3224] Add DNS Extended Errors when stale answers are returned from cache. [GL #2267] Implement support for catalog zones change of ownership (coo) mechanism described in the DNS catalog zones draft version 5 document. [GL #3223] Implement support for catalog zones options new syntax based on catalog zones custom properties with "ext" suffix described in the DNS catalog zones draft version 5 document. [GL #3222] Implement reference counting for TLS contexts and allow reloading of TLS certificates on reconfiguration without destroying the underlying TCP listener sockets for TLS-based DNS transports. [GL #3122] Add support for remote TLS certificates verification, both to BIND and dig, making it possible to implement Strict and Mutual TLS authentication, as described in RFC 9103, Section 9.3. [GL #3163] [cleanup] Remove use of exclusive mode in ns_interfacemgr in favor of rwlocked access to localhost and localnets members of dns_aclenv_t structure. [GL #3229] Remove the task exclusive mode use in ns_clientmgr. [GL #3230] (From OE-Core rev: d2ae8b85c71be2e9e332b1ef0a2d3083b30c63e6) Signed-off-by: Wang Mingyu <wangmy@fujitsu.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky
Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/
OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.
Contribution Guidelines
The project works using a mailing list patch submission process. Patches should be sent to the mailing list for the repository the components originate from (see below). Throughout the Yocto Project, the README files in the component in question should detail where to send patches, who the maintainers are and where bugs should be reported.
A guide to submitting patches to OpenEmbedded is available at:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
There is good documentation on how to write/format patches at:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
- Git repository: https://git.openembedded.org/openembedded-core/
- Mailing list: openembedded-core@lists.openembedded.org
BitBake (files in bitbake/):
- Git repository: https://git.openembedded.org/bitbake/
- Mailing list: bitbake-devel@lists.openembedded.org
Documentation (files in documentation/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
- Mailing list: docs@lists.yoctoproject.org
meta-yocto (files in meta-poky/, meta-yocto-bsp/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
- Mailing list: poky@lists.yoctoproject.org
If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.