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
