all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Stefan Hrdlicka <s.hrdlicka@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-firewall] allow non zero ip address host bits
Date: Tue, 8 Nov 2022 18:00:41 +0100	[thread overview]
Message-ID: <bb417e35-62f8-83f9-188e-ab13222c02db@proxmox.com> (raw)
In-Reply-To: <bc830a9f-0bc8-1417-f8df-61245189dd93@proxmox.com>

Am 08/11/2022 um 15:15 schrieb Stefan Hrdlicka:
>> Could another option be that we normalize CIDRs on entry, i.e., mask out
>> the end? I mean,. would not help existing setups, but at least future
>> proof it a bit for new systems if there's another call site that will
>> trip on this (maybe normalizing here in case of 171 could be an option
>> too). I don't want to shove you in that direction, just wondering if
>> that was considered.
> 
> Yes that would be an option. Was more bit more faffing about when I tried it.
> Also would it then be a good idea to change config a user
> added to the the file, or should that be kept as it was entered?
> 

We normally don't auto-rewrite/update configs on package upgrade, as that can
be brittle and break immediate downgrades due to a, e.g., regression, but when
writing out a FW config anyway we could rewrite it indeed (at least if there's
no disagreement in that beeing a good idea in the first place)

So in any way, we would probably still want some silencing of the verifier,
if you cleanup the slightly confusing odd case with returning $cidr only
on $noerr I would go for that for now as stop gap.

      reply	other threads:[~2022-11-08 17:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 14:31 Stefan Hrdlicka
2022-10-28  9:28 ` Thomas Lamprecht
2022-11-08 14:15   ` Stefan Hrdlicka
2022-11-08 17:00     ` Thomas Lamprecht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb417e35-62f8-83f9-188e-ab13222c02db@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=s.hrdlicka@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal