bird bug: can not parse the full-length IPv6 address
Hi, I found a funny bug, when made some tests. I found out that if you try to give bird a full-length IPv6-address, like: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 1111:2222:3333:4444:5555:6666:7777:8888 You will get an error: "syntax error, unexpected BYTESTRING". I find it happens in conf/cf-lex.l because of how BYTESTRING is defined before IP6, it is too liberal to the forms of bytestrings, allowing almost arbitrary mix of ':' and digits. I suspect the idea was it allow 32-digit strings without delimters or with groups of 2 digits delimited by ':'. See proposed changes in the patch. By the way, that possibility for string literals is not documented. :) IP6 definition is also too permissive and allows some really weird things. It might have been done so intentionally to catch IPv6 typos. But in that case, it probably could be silmlified.
On Sat, Jan 01, 2022 at 10:07:12PM +0100, Alexander Zubkov wrote:
Hi,
I found a funny bug, when made some tests. I found out that if you try to give bird a full-length IPv6-address, like: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 1111:2222:3333:4444:5555:6666:7777:8888 You will get an error: "syntax error, unexpected BYTESTRING".
Hi Thanks for remainding me about that issue. I noticed that some time ago, fixed it in one of my private branches and then completely forgot about that. Will merge it.
I find it happens in conf/cf-lex.l because of how BYTESTRING is defined before IP6, it is too liberal to the forms of bytestrings, allowing almost arbitrary mix of ':' and digits. I suspect the idea was it allow 32-digit strings without delimters or with groups of 2 digits delimited by ':'. See proposed changes in the patch. By the way, that possibility for string literals is not documented. :)
The idea is 32-digit or more. Also, it is not generic string literals, it is limited to cryptographic keys, and documented: A password can also be specified as a hexadecimal key. <m/hex_key/ is a sequence of hexadecimal digit pairs, optionally colon-separated. A key specified this way must be at least 16 bytes (32 digits) long (although specific algorithms can impose other restrictions). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Sun, Jan 2, 2022, 00:23 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sat, Jan 01, 2022 at 10:07:12PM +0100, Alexander Zubkov wrote:
Hi,
I found a funny bug, when made some tests. I found out that if you try to give bird a full-length IPv6-address, like: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 1111:2222:3333:4444:5555:6666:7777:8888 You will get an error: "syntax error, unexpected BYTESTRING".
Hi
Thanks for remainding me about that issue. I noticed that some time ago, fixed it in one of my private branches and then completely forgot about that. Will merge it.
I find it happens in conf/cf-lex.l because of how BYTESTRING is defined before IP6, it is too liberal to the forms of bytestrings, allowing almost arbitrary mix of ':' and digits. I suspect the idea was it allow 32-digit strings without delimters or with groups of 2 digits delimited by ':'. See proposed changes in the patch. By the way, that possibility for string literals is not documented. :)
The idea is 32-digit or more. Also, it is not generic string literals,
Ok, then my patch is not fully correct, but you know what to do anyway. :) it is limited to cryptographic keys, and documented:
You are right. Sorry, my bad, missed that part.
A password can also be specified as a hexadecimal key. <m/hex_key/ is a sequence of hexadecimal digit pairs, optionally colon-separated. A key specified this way must be at least 16 bytes (32 digits) long (although specific algorithms can impose other restrictions).
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Alexander Zubkov -
Ondrej Zajicek