[Bug 221515] [MAINTAINER] dns/opendnssec2: Upgrade to release 2.1.3

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221515

            Bug ID: 221515
           Summary: [MAINTAINER] dns/opendnssec2: Upgrade to release 2.1.3
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: jaap at NLnetLabs.nl
 Attachment #185400 maintainer-approval+
             Flags:

Created attachment 185400
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=185400&action=edit
Patch to upgrade

As of today version 2.1.3 of OpenDNSSEC has been released. No special
migration steps are required when upgrading from a previous 2.x.x
release. It includes fixes to the build system, some regressions w.r.t.
OpenDNSSEC 1.4 and a signing bug. Please note that version 2.1.2 was
skipped for release.

Build fixes:

* OPENDNSSEC-904: autoconfigure fails to properly identify functions in
  ssl library on some distributions. This caused the "tsig unknown
  algorithm hmac-sha256" error.
* OPENDNSSEC-894: repair configuration script to allow excluding the
  build of the enforcer.

Regressions:

* OPENDNSSEC-508: Tag <RolloverNotification> was not functioning
  correctly
* OPENDNSSEC-901: Enforcer would ignore <ManualKeyGeneration/> tag in
  conf.xml
* OPENDNSSEC-906: Tag <AllowExtraction> tag included from late 1.4
  development

Bugs Fixed:

* OPENDNSSEC-886: Improper time calculation on 32 bits machine causes
  purge of keys not being scheduled. The purge would happen but some
  time later than expected.
* OPENDNSSEC-890: Mismatching TTLs in record sets would cause bogus
  signatures.
* OPENDNSSEC-908: Warn when TTL of resource record exceeds KASP's
  MaxZoneTTL. Formerly the signer would cap such TTLs to prevent
  situations where those records could get bogus during ZSK rollover.
  However it has been realized that this can potentially lead to failing
  IXFRs. We intend to bring back this feature in the near future when
  our internal data representation allows this.

-- 
You are receiving this mail because:
You are the assignee for the bug.