TL;DR; If you use NetAddr::IP->new6() for resolving DNS names to IPv6 addresses, the addresses returned by NetAddr::IP are not what you might expect. See below for details. Issue #2 in UIF Over the last couple of days, I tried to figure out the cause of a weird issue observed in UIF (Universal Internet Firewall [1], a nice Perl tool for setting up ip(6)tables based Firewalls). Already a long time ago, I stumbled over a weird DNS resolving issue of DNS names to IPv6 addresses in UIF that I reported as issue #2 [2] against upstream UIF back then. I happen to be co-author of UIF. So, I felt very ashamed all the time for not fixing the issue any sooner. As many of us DDs try to get our packages into shape before the next Debian release these days, I find myself doing the same. I started investigating the underlying cause of issue #2 in UIF a couple of days ago. Issue #119858 on CPAN Today, I figured out that the Perl code in UIF is not causing the observed phenomenon. The same behaviour is reproducible with a minimal and pure NetAddr::IP based Perl script (reported as Debian bug #851388 [2]. Thanks to Gregor Herrmann for forwarding Debian bug upstream (#119858 [3]). Here is the example script that shows the flawed behaviour:

#!/usr/bin/perl
use NetAddr::IP;
my $hostname = "google-public-dns-a.google.com";
my $ip6 = NetAddr::IP->new6($hostname);
my $ip4 = NetAddr::IP->new($hostname);
print "$ip6 <- WTF???\n";
print "$ip4\n";
exit(0);

... gives...

[mike@minobo ~]$ ./netaddr-ip_resolv-ipv6.pl
0:0:0:0:0:0:808:808/128 <- WTF???
8.8.8.8/32

In words... So what happens in NetAddr::IP is that with the new6() "constructor" you initialize a new IPv6 address. If the address is a DNS name, NetAddr::IP internally resolves it into an IPv4 address and converts this IPv4 address into some IPv6'ish format. This bogus IPv6 address is not the one matching the given DNS name. Impacted Software in Debian Various Debian packages use NetAddr::IP and may be affected by this flaw, here is an incomplete list (use apt-rdepends -r libnetaddr-ip-perl for the complete list):

• spamassassin
• postgrey
• postfix-policyd-spf-perl
• mtpolicyd
• xen-tools
• fwsnort
• freeip-server
• 389-ds
• uif

Any of the above packages could be affected if NetAddr::IP->new6(<dnsname>) is being used. I haven't checked any of the code bases, but possibly the corresponding maintainers may want to do that. References

• [1] https://github.com/cajus/uif/
• [2] https://github.com/cajus/uif/issues/2
• [3] https://rt.cpan.org/Public/Bug/Display.html?id=119858
• [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851388

light+love
Mike

The SPICE protocol for remote display access is the preferred solution with oVirt and RedHat Enterprise Virtualization, and I was sad to discover the other day that the browser plugin needed to use these systems seamlessly was missing in Debian. The request for a package was from 2012-04-10 with no progress since 2013-04-01, so I decided to wrap up a package based on the great work from Cajus Pollmeier and put it in a collab-maint maintained git repository to get a package I could use. I would very much like others to help me maintain the package (or just take over, I do not mind), but as no-one had volunteered so far, I just uploaded it to NEW. I hope it will be available in Debian in a few days. The source is now available from http://anonscm.debian.org/gitweb/?p=collab-maint/spice-xpi.git;a=summary.