On Mon, 01 May 2023, Jamie Strandboge wrote:
> Thank you for the report. If you update hex_decode() in
> /usr/lib/python3/dist-packages/ufw/util.py to use this:
>
> return binascii.unhexlify('%2s' % h).decode("utf-8")
>
> instead of:
>
> return binascii.unhexlify(h).decode("utf-8")
>
> Does it resolve the issue for you?
Don't worry about the above, I have a better mitigation to avoid tracing
back:
https://git.launchpad.net/ufw/commit/?id=a14ab9777cde6308724164f5c42d368d2a823b3a
This will be in the next upload and will allow 'ufw status' to still
work in the face of an odd length hex string which will mitigate the
issue, but not address the underlying cause.
I'd like to better understand how you ended up with an odd length string
in the first place. You gave a reproducer, but can we simplify it a bit?
Can you:
1. backup your firewall with:
$ sudo ufw disable
$ sudo /lib/ufw/ufw-init flush-all
$ sudo cp -a /etc/ufw /etc/ufw.backup
2. reproduce the issue with:
$ sudo ufw reset (resets to installation defaults)
$ sudo ufw enable
$ sudo ufw route ... (I need a single rule that causes the issue)
$ sudo ufw status (demonstrates the problem)
$ sudo cat /etc/ufw/user.rules (I need this with the problematic rule)
$ env|grep LC_ (I need this to see if related)
3. restore from backup with:
$ sudo ufw disable
$ sudo /lib/ufw/ufw-init flush-all
$ sudo mv /etc/ufw /etc/ufw.1034568
$ sudo cp -a /etc/ufw.backup /etc/ufw
$ sudo ufw enable
When responding, please include the problematic ufw rule,
/etc/ufw/user.rules and the output of 'env|grep LC_'.
Thanks!
--
Email: ja...@strandboge.com
IRC: jdstrand
