On Sat, Feb 1, 2025 at 2:13 PM Stefano Brivio
<sbrivio(a)redhat.com> wrote:
On Fri, 31 Jan 2025 15:53:29 +0100
Enrique Llorente <ellorent(a)redhat.com> wrote:
The logic composing the DHCP reply message is
reusing the request
message to compose the it, this kind be problematic from a security
Does "be problematic" imply "would be ... once we add longer
options"?
context and may break the functionality.
Which one? This is important to know for distribution maintainers and,
ultimately, users.
As far as I know it's all fine until now, the problem would arise in
your next patch, so perhaps state that.
The real reason why we need this is that we want to have a given, fixed
size for the option field (308) so that we can easily check we don't
exceed it once we start writing the FQDN in it.
This change create a new reply message and fill
it in with proper fields
from request adding on top the generated opetions.
s/opetions/options/
Thinking about it twice, maybe we don't need this change after all,
from what I see at
code it override the request options with the reply options and then
add the 255 finalizer and some padding if
is less than 308, meaning that the request options has no effect on
reply, isn't that enough ?