From ${URL} : Jonas Smedegaard reports: The ldns-keygen tool creates a keypair, one of which should be kept private. The tool apparently use default access rights for all files, leading to the private key being created world readable. ==== This has been confirmed: # ldns-keygen -a RSASHA1_NSEC3 -b 1024 example.net Kexample.net.+007+63434 # ls -la total 20 drwxr-xr-x. 2 root root 4096 May 3 11:34 . dr-xr-x---. 11 root root 4096 May 3 11:34 .. -rw-r--r--. 1 root root 70 May 3 11:34 Kexample.net.+007+63434.ds -rw-r--r--. 1 root root 242 May 3 11:34 Kexample.net.+007+63434.key -rw-r--r--. 1 root root 943 May 3 11:34 Kexample.net.+007+63434.private External references: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746758 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Upstream bug at https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=573 including patch. I don't see any upstream release for it at this time ( The latest release is 1.6.17, dating Jan 10, 2014)
The commit for the Fix is here: http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=169f38c1e25750f935838b670871056428977e6b Debian also released a version for this under: 1.6.17-4
Ping! It has been a month since last message, upstream has not released any new packages just a patch in GIT. Do we just want to patch like Debian?
CVE-2014-3209 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3209): The ldns-keygen tool in ldns 1.6.x uses the current umask to set the privileges of the private key, which might allow local users to obtain the private key by reading the file.
CC'ing new maintainer. @ Marc: Please see comment #3
From https://www.nlnetlabs.nl Version 1.7.0 is available since 12/2016 and has fixed the bug. Maintainer, could you please comment the status from the last ebuild, is it already stable? If not, is there something that we can help with? Thanks
Please CC arches to start stabilization.
Arches, go ahead please and stabilize net-dns/ldns-utils-17.0 Thanks!
An automated check of this bug failed - repoman reported dependency errors (137 lines truncated): > dependency.bad net-dns/ldns-utils/ldns-utils-1.7.0.ebuild: DEPEND: amd64(default/linux/amd64/13.0) ['>=net-libs/ldns-1.7.0[dane?,ecdsa?,gost?,ssl?]'] > dependency.bad net-dns/ldns-utils/ldns-utils-1.7.0.ebuild: RDEPEND: amd64(default/linux/amd64/13.0) ['>=net-libs/ldns-1.7.0[dane?,ecdsa?,gost?,ssl?]'] > dependency.bad net-dns/ldns-utils/ldns-utils-1.7.0.ebuild: DEPEND: amd64(default/linux/amd64/13.0/desktop) ['>=net-libs/ldns-1.7.0[dane?,ecdsa?,gost?,ssl?]']
hppa stable
amd64 stable
x86 stable
Please update the package list.
arm stable
Updated package list to fix build of net-libs/ldns without ssl flag (It is now removed) and net-dns/ldns-utils update adds missing REQUIRED_USE. See following bugs for more info: https://bugs.gentoo.org/640142 https://bugs.gentoo.org/640132
ia64 stable
ppc/ppc64 stable
sparc stable (thanks to Rolf Eike Beer)
hppa stable (thanks to Rolf Eike Beer)
@alpha, ping!
Alpha has no stable version and still hasn't stabilized. @maintainer, can we please cleanup the vulnerable versions?
Stable on alpha, sorry for the delay.
(In reply to Tobias Klausmann from comment #25) > Stable on alpha, sorry for the delay. Thanks, Tobias! @maintainer, please clean the vulnerable versions from the tree.
tree is clean: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8c30310b3f652ec47fe32594bdb4be95bdadf4c2
