Description of problem: Addresses for IPv4 use n.n.n.n/m.m.m.m notation, even though this is increasingly uncommon, inconsistent with most other Linux commands, and inconsistent with IPv6 notation. Version-Release number of selected component (if applicable): 7.6-59 How reproducible: Use a "ALL: n.n.n.n/32" host address in a /etc/hosts.deny file, and then attempt to connect from that address. The connection will not be blocked. Steps to Reproduce: 1. 2. 3. Actual results: Address is not parsed correctly as an address/mask pair, therefore it isn't tested as an address/mask pair. Expected results: The connection should be blocked. Additional info: Note that /prefix is supported almost uniformly in other network applications.
Created attachment 493652 [details] Support for IPv4 /prefix notation Installed and tested (verified) locally.
Created attachment 493700 [details] Support for IPv4 /prefix notation
patched in rawhide, test and report please
(In reply to comment #3) > patched in rawhide, test and report please Can you point me at a x86_64 rpm? Koji builds? Thanks.
Used fedpkg to build it. Found a host order bug. Attaching a fix for the patch.
Created attachment 497273 [details] Host byte ordering fix for the previous patch.
Created attachment 497276 [details] Host byte ordering fix for the previous patch.
Applied, test it again, please.
(In reply to comment #8) > Applied, test it again, please. Works great... Just realized, though, that attachment 497273 [details] (the first patch) was correct. It should be htonl() and not ntohl() (even though they both do the same exact thing).
Do you need anything else from me? I'm thinking we should be good to go.
Created attachment 499267 [details] Cosmetic fix to byteordering reversal prefix_to_netmask() should return network-order, not host-order value. With this one-liner change, the fix should be good to go. Please close out this bug and release.
When is the next release scheduled?
fedora 16
(In reply to comment #13) > fedora 16 No, I meant the next release of this package... there won't be a bugfix release for f15?
may be if you really need it (I think that this fix does not bring anything fundamental) it not add extra security ... it is not a regression it only allows another configuration file notation