From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=IbW66BSG; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 4130E5A004E for ; Mon, 03 Feb 2025 10:24:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738574681; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YCg23ug7KPB+jw/mcBAyW6yZXZ1aApd2VDD/uQ3nqHw=; b=IbW66BSGSfyVO2QWpIXvh83IDPq8A+WmTeXWgrSeeT5y+lOqUlh3VOcFFSni7r8jjjHHvw TI5bwla/HI9Xllz5/fbvWpDWkhAp9YXtl0eiQyCZcjAf/eUK+ojbf8SMW2g9ICf0LHpF9j d3VfyOEwobsKHDJjonw1P+34XX8DlQc= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-5-srf1I_BqPQWaWyM9Indc0Q-1; Mon, 03 Feb 2025 04:24:40 -0500 X-MC-Unique: srf1I_BqPQWaWyM9Indc0Q-1 X-Mimecast-MFC-AGG-ID: srf1I_BqPQWaWyM9Indc0Q Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-38c24ac3415so3222638f8f.2 for ; Mon, 03 Feb 2025 01:24:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738574678; x=1739179478; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=YCg23ug7KPB+jw/mcBAyW6yZXZ1aApd2VDD/uQ3nqHw=; b=nWLCm11mKOcIS7gJOLBtHWoYBoBPn6Knkauiv1d+TEp/lAPDoVwKqs2Ev80/Neif0g wmfjJk9ZGkQNfTH89X10G/y4msi4vrC1msWA/KJEM6vZ2+bMrKN8eGQF2KWkfctGMY+E a1pZXwcuZ17Sg8hcBzdFlj94D7v+xJ5xD1n9VO8HAOYdC+Ps71Eot95a5L1i/R7wRLm3 HIEXLacKVeVOxeCwEYsSTMg47MfL5rkrrKSJJI3OiCFUXYDUsdU+dYyx7NiXwtXVGN6O A9/8UcSvASljAxQdU2jdOgrRfYGXJddqQAc1iEMJn8nzRJm61O9YJtIKVwJZsWHrNUUy YWNw== X-Gm-Message-State: AOJu0YxrbhK7e0Lwj8tjoh6aQLl3D6b3h7tEfq9W6Q9tL2NTOg44UQ8C EK9mF7BRHFV5ad7XeewiswcNu0AB4ElQuio6OKb6l22V0cmaNCrOWizBdkXRHYMA8O4tLQGXRCz PIWCyL4+27lGGt/ilrXYwJkrVIsmTwaLF2d5tkztfUiolOzoIXjWSvi7klyMOPANtlfe/AXo6WQ jruvhigFTTIBOuqR9mft5/+85jWIC4m+/j X-Gm-Gg: ASbGncti5kM+QJxYrqdqlfKMPHT9r9Wxqrhy6OmtWuQgH9vrrL0rIgCZ9wFNVnwoxBt YOtmE5BYamlFwKWsezbRFJsw9ZnvRQZFkPIEdCVZm0bm7u4YqAcnHqcCmfCJkhuabziZP3b6Y1P DM7XY9mACyMahKILGW7VjScozDf1MT3LH2qastJix1McMW/q1dxyzlRhfKnift0VFwhzBUCEIn+ M2vqH6TRFZeRrUBe5hRQ/i7ygVKxfa6AS6QT3bzXfJAVR3SZldrXp3be6GO8oA1ad41RAk5fyLj Olnq85eKuc7guyr/ X-Received: by 2002:a5d:5f56:0:b0:385:d7f9:f157 with SMTP id ffacd0b85a97d-38c51e957b9mr19547568f8f.36.1738574677727; Mon, 03 Feb 2025 01:24:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IFhjxfODO38F840l77HfwzBHZ0p+gOYQram1DTswdJsEIYcM/0NtEbOM69yeCiXCb0hCq01DQ== X-Received: by 2002:a5d:5f56:0:b0:385:d7f9:f157 with SMTP id ffacd0b85a97d-38c51e957b9mr19547536f8f.36.1738574677300; Mon, 03 Feb 2025 01:24:37 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c5c11fe22sm12031386f8f.41.2025.02.03.01.24.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Feb 2025 01:24:36 -0800 (PST) Date: Mon, 3 Feb 2025 10:24:35 +0100 From: Stefano Brivio To: Enrique Llorente Pastora Subject: Re: [PATCH] dhcp: Don't re-use request message for reply Message-ID: <20250203102435.11bc9459@elisabeth> In-Reply-To: References: <20250131145329.1835558-1-ellorent@redhat.com> <20250201141330.59af1324@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: YLWz9-ii9FF86mdzZLbUcUb6Gu5Zk5r7lj_oLULvPbI_1738574679 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 3ACOOVM5RKLG3NSBI6JZMMYHQZVSCNSY X-Message-ID-Hash: 3ACOOVM5RKLG3NSBI6JZMMYHQZVSCNSY X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, 3 Feb 2025 10:19:27 +0100 Enrique Llorente Pastora wrote: > On Sat, Feb 1, 2025 at 2:13=E2=80=AFPM Stefano Brivio wrote: > > > > On Fri, 31 Jan 2025 15:53:29 +0100 > > Enrique Llorente wrote: > > =20 > > > The logic composing the DHCP reply message is reusing the request > > > message to compose the it, this kind be problematic from a security = =20 > > > > Does "be problematic" imply "would be ... once we add longer options"? > > =20 > > > context and may break the functionality. =20 > > > > 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. > > =20 > > > This change create a new reply message and fill it in with proper fie= lds > > > from request adding on top the generated opetions. =20 > > > > s/opetions/options/ >=20 > 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 ? It's not, because with FQDN options we can easily exceed the minimum size of a DHCP message we get, so the original message might not be enough to write everything we need to write. It's about the lower bound (of the size), not the upper bound. --=20 Stefano