Releases: irrdnet/irrd
IRRD 4.3.0 post 1
https://irrd.readthedocs.io/en/stable/releases/4.3.0/
4.3.0 was initially released on June 6th, 2023, but was yanked due to a packaging error on June 9th, leading to the release of IRRd 4.3.0.post1. The main visible issue from the error was that the documentation of 4.4 was published as 4.3.0. If you had previously installed 4.3.0 through PyPI/pip, you can keep running on that version, or update to 4.3.0.post1 without needing restarts or migrations, as the 4.3.0 and 4.3.0post1 PyPI packages have identical code.
IRRd 4.3.0 release candidate 1
Release candidate 1 for 4.3.0. Will be released as 4.3.0 unless any issues are reported.
https://irrd.readthedocs.io/en/latest/releases/4.3.0/
Changes from 4.3.0b2:
IRRd 4.2.8
IRRd 4.2.8 was released on April 19th, 2023, and fixes an issue where NRTM queries could hang indefinitely on PyPy deployments (#774). This did not affect CPython deployments.
IRRd 4.3.0 beta 2
Second beta release of 4.3.0. Release notes: https://irrd.readthedocs.io/en/latest/releases/4.3.0/
Fixes from 4.3.0b1:
- Fixed a SQL deadlock issue and significant performance issue when performing initial imports (#771)
IRRd 4.3.0 beta 1
First beta release of 4.3.0. Release notes: https://irrd.readthedocs.io/en/latest/releases/4.3.0/
IRRd 4.2.7
IRRd 4.2.7 was released on February 15th, 2023, and has three changes:
- IRRd now has a new setting
sources.{name}.nrtm_query_serial_range_limit
to limit the maximum serial range a client may request in a single NRTM
query. This is configured per source, and evaluated in addition to
other access limits. By default, there is no limit.
See the :doc:configuration documentation </admins/configuration>
for details. - Each IRRd process will now log a traceback of all threads when receiving
a SIGUSR1 signal. The tracebacks are written to the normal logs, and
can help IRRd developers understand more complex issues, particularly
in hanging IRRd workers. - Password hashes were visible in some email notifications (#722). The scope
was limited. A notification could only be triggered by already
knowing a valid password.
IRRd 4.2.6
IRRd 4.2.6 was released on November 18th, 2022, and fixes two issues:
IRRd 4.2.5
IRRd 4.2.5 was released on June 24th, 2022, and fixes several issues:
- Deletions could fail for cases where the same RPSL primary key
was used in the same source for different objects with different
object classes. This could prevent NRTM updates from progressing.
Any mirroring processes that were stuck due to this bug will
recover after upgrading. #660 - The irrd_load_pgp_keys_ command was missing from the distribution #655
- An obscure situation where a non-ASCII character
could be permitted in RPSL primary keys was corrected #651 - Added a warning that when using PostgreSQL replication, the
local preload store may not be updated causing
potential stale responses to queries #656
Full Changelog: v4.2.4...v4.2.5
IRRd 4.2.4
IRRd 4.2.4 was released on April 5th, 2022, and fixes an issue where the source order was not correctly applied (#635)
This could affect the results of queries like !i
and !m
and their GraphQL counterparts, which only return or consider one object, while multiple objects with the same primary key may exist in different sources. Where these multiple objects did exist, the responses to the queries could prefer the object from a less preferred source. This behaviour was not always consistent.
This affected both the source order set in the sources_default
setting and an explicit source order set for a specific query.
IRRd 4.2.3
IRRd 4.2.3 was released on March 31st, 2022, and fixes a security
issue with password hash filtering that occurred in all earlier 4.2
releases. The 4.1.x series is not affected.
Previous IRRd 4.2 versions did not always filter password hashes in mntner
objects. This may have allowed adversaries to retrieve some of these hashes,
perform a brute-force search for the clear-text passphrase, and use these
to make unauthorised changes to affected IRR objects.
This issue only affected instances that process password hashes, which means it
is limited to IRRd instances that serve authoritative databases. IRRd instances
operating solely as mirrors of other IRR databases are not affected.
This issue was assigned CVE-2022-24798 and GHSA-cqxx-66wh-8pjw.
See https://irrd.readthedocs.io/en/stable/releases/4.2.3/ for further details.