Proposed roadmap

First of all, we should analyze the to-do list we previously had, evaluating the relevance and importance of its points. So, ordered by priority and adding a couple of new points, we have:

Original to-do item Comments Priority
Double-check everything (specially the part that runs as root) for security holes. Maybe re-write that part in C or something similar. I am doing this right now. I noticed with horror that many potentially dangerous operations were being executed by root without even sanity checking! Before anything else, I will add the use strict Perl directive to all the CGIs, check all the user-supplied input...
As for my idea about rewriting it in C... No way :-) I fortunately learned that Perl is infinitely more secure than C, and small programs such as wpmd.pl would only become more obscure and harder to mantain.... So, I'm sticking to Perl.
1
Add support for ipfwadm (Linux kernel 2.0.x) and other operating systems Very important. Linux has added yet another firewalling style, netfilter, so in order to support every Linux system we need two additional syntaxes.
I have also started using OpenBSD, a great operating system, and very security conscious. It uses ipfilter, which is also used in many other Unixes... And I think supporting it will be very simple and straightforward.
On the other hand, this gives me the opportunity to add some relocation capabilities - Why insist on everything being installed in /home/httpd/cgi-bin/? Most Unixes use either /var/www/ or /usr/local/apache/ for the Web server... WPM should be able to be relocated!
By the way, wpmd.pl is not a CGI, and should be moved to /usr/local/sbin.
2
Ability to specify ranges when defining segments (i.e., 1-10 instead of 1,2,3,4,5,6,7,8,9,10) Seems fairly easy to do... Should not take long 3
Provide more than a workaround for networks that are not Class-C. NOTE - The workaround *DOES* work (confirmed), but I don't like its lack of elegance. Anyway....
Workaround: If you specify as your network (in wpmd.conf) only the first octet (eg., 1 in 1.2.3.4) of your IP, you should be able to allow/deny access to IP 2.3.4 - not very confortable, but works... (if you don't need IPs from different first-octet network segments).
This originally seemed as an unusual configuration for me... Sadly, I was wrong. This looks as an excellent candidate to throw our brains at... 3
Add all the scheduling code Also, the ability to reboot without losing state.
I know, we Unix users don't reboot much, but anyway...
Janake Ronnblom also asks for the ability to deny or allow exit to a segment for some preset length of time.
3
Internationalization / separation between code and interface ...A skinnable, translatable WPM! What else do we need in order to declare this world perfect? ;-) 3
Building packages for easy installation/removal (.rpm, .deb, whatever is needed for inclusion in *BSD ports trees) Lets have a new version addressing the shortcomings... Then... 3
Test system with a firewalling machine instead of a proxy, and implement the necessary changes Also, adding the ability to work with different ports, maybe via drop-down menus, or something like it...
Sounds neat, but... All I can say is... Not right now :)
4
Add more access-level restrictions (should be very easy to do - just have to come up with the right ideas :) ) ...I need the ideas to evaluate if it is possible/easy/hard :-) So please.. 5
Whatever you can suggest me... Same thing... Do you want any extra features? Does something bug you? Let me know! 5

Go back