On Sun, 2015-11-29 at 17:36 -0500, Michael Gilbert wrote: > control: tag -1 upstream > control: tag -1 -security > control: forwarded -1 ISC bug #35631 > control: retitle -1 dhclient adopts dhcp server's settings despite > them not being "request"ed Working with you is always uhm... like Christmas... o.O
> The syntax may very well be a bit odd, but a few minutes of > intellectual poking with supersede leads to a simple solution for all > of the problems mentioned so far. That is left as an exercise for > the > astute reader. The solution can't be to use supersede, as this requires one to actually set a secure/usable value. For many there may not be a value which one desires to set (e.g. dns search)... for others, e.g. ntp-servers the best one could do is to use localhost, which is however not working either, as software then actually tries to query NTP at localhost. > For now, since there are simple workarounds, and > given that this is an upstream design flaw rather than a > Debian-specific issue, further effort on solving it should go there. I never said it's a debian specific bug, but since upstream hides behind not even having a proper bugtracker its probably pointless to have one further iteration of pressing there. Effectively only the distros would be powerful enough to build up the necessary pressure for upstream to do something. Given that you're from the security team, I guess removing the security tag means effectively that the security denies any issue that upstream doesn't want to deal with to be a security issue. And further, an attack vector that, as shown above with the expiry of X509 certs, can be clearly any extremely simply be used isn't considered worth to be fixed by Debian? Just simulated that before... set up a local forged NTP server, sent it via dhcp, when a node in the network reboots at least ntpdate takes this up and sets any arbitrary date... voila... one can use expired certs again.. Security-ignorance at it's finest o.O
smime.p7s
Description: S/MIME cryptographic signature
