[pkg-dhcp-devel] Bug#672232: Bug#672232: Bug#672232: Re isc-dhcp-client: method to ignore settings provided by the server

[Michael Gilbert]

On Sun, Nov 29, 2015 at 5:56 PM, Christoph Anton Mitterer wrote:
> Working with you is always uhm... like Christmas... o.O

Seriously, just stop.  The never-ending negativity helps no one.

>> 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.

Absolutely not the point.  You apparently couldn't figure out
supersede and yet it is trivially figure outable.  That is all that
particular paragraph stated.

> 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.

What about an ntp pool that is already somehow marginally trusted,
like the debian ones used by default in the ntp package?

> 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.

The point was missed yet again.  If an issue affects all of the open
source community need to be defended in front of the entire open
source community.

> 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.

No, absolutely not, and point yet again completely missed.

If you are in fact capable of defending your claims in front of peers,
then let's absolutely treat this as a security concern.  If not, then
I have no interest in being the lackey dealing with the never-ending
insult and incompetence.

> 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..

Good work, should be excellent justification for your CVE request
(with real details of course)!

Best wishes,
Mike