In v0.8 we fixed an error that arose when the key obtained via X509_get_X509_PUBKEY was freed independently of the X509 certificate though it in deed is part of the cert. The error was found in networking.c. At the same time the author grepped for other usages of the X509_get_X509_PUBKEY function in all other files. It is a miracle why grep did not return any result at that time. Consequently the same error remained unfixed in dane-unbound.c and dane-direct.c. I had been a bit in wonder that this was the only point where the function was used but I did trust in the result of grep. For now I had discovered the error simply by reading the sources. Make sure you do not use any version before 0.8.4 without manually adding this fix because it is a severe security issue. It may crash a̅tea when a TLSA record contains a full cert or pubkey rather than a hash of it (which will be hardly used in practice though the TLSA response could be spoofed to pretend this)!
A̅tea has been tested for verifying an XMPP/Jabber certificate. It turned out that --show-cert/--faaite-cert was not correctly implemented for non-RSA certificates: parse_pubkey tried to free a structure that was previously never allocated. The certificate serial is now not only printed as hex but also as decimal like it is displayed by the Gajim messenger. free_pubkey has been added to avoid a memory leak on certificate printout/display.
Today I have also noticed that my gpg-card used to sign the SHA512SUMS file has likely been stolen. If you have read point 6 of the epilogue of my master thesis as suggested in my previous rss message then you do already know that encrypting or signing with gpg does add no security in case of messages from/to elstel.org. I have still published a revocation for the key.
Corrected an incorrect free of the public key striking if the TLSA record contains a hash of the public key rather than a hash of the whole cerificate. The key obtained via X509_get_X509_PUBKEY must not be freed as it belongs to the whole X509 certificate. Previously possible arbitrary code execution!
64bit file offsets on 32bit systems allowing for continuation of file downloads with more than 4GB
two flavours of a̅tea: unbound (as previously) and direct (no need for special DNS servers, currently no signature validation)
license & code reusage: choose your license between ISC, GPLv3 and others
correct retrieval of DANE TLSA records if certificate differs from that used at port 443 (default SSL port)
automatic check for outdated certificates (can be switched off)
possibility to print the most important certificate properties on command line including hashes for comparison in browsers and as used in TLSA records.
correct printing of IPv3 addresses if portions of the address are greater or equal to 128
“-hh” option to not only print the response but the http request sent before
noop operation for merely checking and printing certificates
no more separate code blocks for tii and tii-cert: code unified
dig _443._tcp.elstel.org TLSA → TLSA 3 0 1 XXXXX: 3: direct cert usage; 0: full cert/ 1: public key; 1: sha256
͏We have corrected a linker error in a̅tea. Furthermore direct IPv6 addresses are now available for use by improved parsing and request handling. We would really like to make a̅tea independent from libunbound. This is an issue for development (The variant is called atea-direct and uses dane-direct.c). Without libunbound we would not be forced to use special encrypting DNS servers for a̅tea. When it comes to security and responsiveness very remote DNS servers with a longer response time are counterproductive. Once a̅tea-direct would become reality you should be able to use the DNS servers of your ISP (internet service provider).
