Dear Maintainer,

apt-cacher-ng does not properly bind the network socket when the value of the BindAddress variable is a plain IPv6 address whose last group is a integer number (and could thus be interpreted as a port).

These do work as expected:
     BindAddress=127.0.0.1       -> binds to 127.0.0.1:3142
     BindAddress=127.0.0.1:8080  -> binds to 127.0.0.1:8080
     BindAddress=::abcd		-> binds to [::abcd]:3142
     BindAddress=[::abcd]:8080   -> binds to [::abcd]:8080
     BindAddress=[::1]:8080      -> binds to [::1]:8080

This does not work while it should:
     BindAddress=::1             -> binds to nothing but should be [::1]:3142

These do not work, but that may be intentional since the square bracket notation is only used in conjunction with a port:
     BindAddress=[::abcd]        -> binds to nothing, could be [::abcd]:3142
     BindAddress=[::1]           -> binds to nothing, could be [::1]:3142

When the last group is a integer, it gets cut off and used as a port:
     BindAddress=::abcd:1234     -> binds to [::abcd]:1234 but should be [::abcd:1234]:3142
     BindAddress=:::1            -> binds to [::]:1 but should throw an "invalid address" error

Plain IPv6 addresses worked fine on buster (also did on stretch and jessie), but not on bullseye anymore. The systemd service starts successfully but listens on no port/address. Depending on the BindAddress, the error message I got was either "Error resolving address for binding: Invalid argument" when the cut-off IPv6 address was invalid, or "Couldn't bind socket: Cannot assign requested address" when the cut-off IPv6 address was valid but no interface had it assigned. Raising the debug level did not turn up more information, but I did not try with a debug build. I think this issue is related to the new BindAddress port syntax and some parse-confusion with the colons.

In the meantime I am using the [IPv6]:Port syntax as a workaround, since that is working as expected in all cases.

We believe that the bug you reported is fixed in the latest version of
apt-cacher-ng, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 994778@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Eduard Bloch <blade@debian.org> (supplier of updated apt-cacher-ng package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 09 Oct 2021 12:40:22 +0200
Source: apt-cacher-ng
Architecture: source
Version: 3.7.3-1
Distribution: unstable
Urgency: low
Maintainer: Eduard Bloch <blade@debian.org>
Changed-By: Eduard Bloch <blade@debian.org>
Closes: 985406 989347 994778
Changes:
 apt-cacher-ng (3.7.3-1) unstable; urgency=low
 .
   * New upstream version
     + fixes interpretation of compressed v6 IPs (closes: #994778)
     + adds support for .sig suffix (closes: #989347)
     + fixes compilation with g++-11 (Salsa issue #10)
   * expiring maintenance job execution logs (closes: #985406)
Checksums-Sha1:
 b6c5a77ee57a69de00329047fbc1ff5f36f09d0d 2127 apt-cacher-ng_3.7.3-1.dsc
 056168bf75001f50894fced6af95976036715998 351948 apt-cacher-ng_3.7.3.orig.tar.xz
 771ef65a43554f73af6c6c982a7035ff82aedba8 50124 apt-cacher-ng_3.7.3-1.debian.tar.xz
 2806ac138a2056af477b9f70460ba9b9a944206f 8865 apt-cacher-ng_3.7.3-1_source.buildinfo
Checksums-Sha256:
 4ae3a133aef4a8d2a1ce83be3db8304dd6824cee3654ee86b72387012a6339f0 2127 apt-cacher-ng_3.7.3-1.dsc
 a6bfedde4a59c7b37996de716ae16be8f79b984f13f19ec808fb51f1770e4332 351948 apt-cacher-ng_3.7.3.orig.tar.xz
 4ade629b8301eec2b3e972b09b5a24c919b8116609fd953051540d7e30a4a7dd 50124 apt-cacher-ng_3.7.3-1.debian.tar.xz
 30cb3242ec418e3fe48c986a715181bb23337b1f687b783b52f018ed23c3ec5b 8865 apt-cacher-ng_3.7.3-1_source.buildinfo
Files:
 f4ed9ead4df8697489e734ced0ff410a 2127 net optional apt-cacher-ng_3.7.3-1.dsc
 d930862df9ede0d4d3a925404d87760c 351948 net optional apt-cacher-ng_3.7.3.orig.tar.xz
 3d7028ce7697b6634a7cfd0449078286 50124 net optional apt-cacher-ng_3.7.3-1.debian.tar.xz
 538ecfda39235550470db19b4ee5c8f1 8865 net optional apt-cacher-ng_3.7.3-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEZI3Zj0vEgpAXyw40aXQOXLNf7DwFAmFhh+sACgkQaXQOXLNf
7Dw9LxAAw3T9bpyCArictOUy3iQgNT05cZlJVZZ1I7uZYq1li55pthz0h9EPkAq9
o+yxaixh+MRTdlIvf8WoeBs58BTs0UjJRCMCIO4/K5+yt3Fwc/Ru/Y+jp2hGQgyz
bO10EoVmbWem759a+uCgyt8fjcws8AQCV+/E00qnQbA1gKnDpDRsGIggcgSFWEmC
4yq8VSrLf+0VYf71whSKno8BRdQpa9CFT7h7Cqdd4CJc0eMyw9PHV68JYb1+43NF
V0Q9cmq1ivNLyKqiZypbrIRlvlHcxjLHDBerVbLKU7M3VTasagYcd0orSTrmjcgy
GXNwTQF2yILDKs+q4ICx45vFWbC56J23Ci4iQme9pXEXZK1FvIza+aCzk0Agltve
fhRTpKwEOlrXlf544HtakQf6lEJZ0kF0roT3Np3yCm06vvi9YChnfK3/oveCHLDD
dfaoMf6oP/COJpMe83GwR5d7TRvyeaS2y2nYq51HgxLkqyeMeIZnw82bb3IaV+ow
XntzgqfGLh1oDTkLdJD9eZ8hoDAuV1jLozlpF/7zM5Q0hxziPd8DsqE/yApGEgm7
y4kD5H735AaX/C0D8V1q/rL7TApGOMEbBXabGMqA850etaPfVQXtmDuvz855a/9z
CqZI2fThdn3YcT2A/1TNaaqPYknmVEcBcX/gNle2uQG+eW+GdQI=
=AwY9
-----END PGP SIGNATURE-----

Dear Maintainer,

unfortunately the bug is not yet fully fixed.

These do work now as expected:
     BindAddress=::                   -> binds to [::]:3142
     BindAddress=:::1                 -> throws an "invalid address" error
     BindAddress=[::]:1               -> binds to [::]:1
     BindAddress=1::                  -> binds to [1::]:3142
     BindAddress=::1                  -> binds to [::1]:3142
     BindAddress=[1::1]               -> binds to [1::1]:3142
     BindAddress=[1:2:3:4:5:6:7:8]    -> binds to [1:2:3:4:5:6:7:8]:3142
     BindAddress=[1:2::7:8]           -> binds to [1:2::7:8]:3142
     BindAddress=[1:2:3:4:5:6:7:::8]  -> throws an "invalid address" error
     BindAddress=[1:2:3:4:5:6:7:8:9]  -> throws an "invalid address" error

These still don't work as expected:
     BindAddress=1::1                 -> binds to nothing, should be [1::1]:3142
     BindAddress=1:2:3:4:5:6:7:8      -> binds to nothing, should be [1:2:3:4:5:6:7:8]:3142
     BindAddress=1:2::7:8             -> binds to [1:2::7]:8 but should be [1:2::7:8]:3142
     BindAddress=1:2:3:4:5:6:7:::8    -> binds to [1:2:3:4:5:6:7::]:8 but should throw an "invalid address" error
     BindAddress=1:2:3:4:5:6:7:8:9    -> binds to [1:2:3:4:5:6:7:8]:9 but should throw an "invalid address" error

Hallo,
* corubba [Mon, Oct 11 2021, 08:40:33PM]:

Well, I used your test vectors for the unit tests and considered it
done. :-)

We will see where it fits. This might be fixed in the next major
version, or in the next generation where I considered switching the
whole parser code to a 3rd party lib.

Best regards,
Eduard.

Hello,

fine by me, since it can be worked around by using the square-bracket-delimited syntax.

As you already did the "heavy lifting" I amended the test suite extensively (some may call it excessively), and realized that I could squeeze in a small bugfix for the "undelimited IPv6 address" case.
At that point in the parsing process, the scheme, credentials and path have already been split off, which leaves only the `host[:port]` bit. Since hostnames and IPv4 addresses can not contain colons, these cases can only have zero or one colon (without and with port respectively). If it starts with a square bracket, it is a delimited IPv6 address. The least number of colons a IPv6 address can have is two (e.g. ::). So if the host-port bit does not start with a square bracket but contains more than one colon, it has to be a undelimited IPv6 address and is used as-is without splitting off the last bit as port. Admittedly this is just a heuristic, but it seems to works. There is a reason why RFC3986 does not allow undelimited IPv6 addresses: In combination with a port they might be ambiguous.
A diff is attached (apply it with `git apply $FILE`), I will leave it to your decision if and in what form you include it.

And if I may be so bold: I support using a specialized library for parsing URIs/URLs/addresses. As we have seen, that is a non-trivial problem to solve.