X-Git-Url: http://www.privoxy.org/gitweb/?a=blobdiff_plain;f=TODO;h=02f6c3e7a238c6336e9391b84ffc6514a0813eec;hb=5be44145f5ba50c47890c1dd2e4aa25edd81d0ae;hp=1a80902e7751c79b08eedf4b5d01a82234fad9ca;hpb=255ce3d8b3d4a7cbc3d1e470d7e7e254d29b4cad;p=privoxy.git diff --git a/TODO b/TODO index 1a80902e..02f6c3e7 100644 --- a/TODO +++ b/TODO @@ -1,4 +1,4 @@ -$Id: TODO,v 1.86 2013/10/30 14:31:23 fabiankeil Exp $ +$Id: TODO,v 1.110 2014/06/02 07:22:40 fabiankeil Exp $ Some Privoxy-related tasks, sorted by the time they have been added, not by priority. @@ -120,6 +120,9 @@ http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/TODO It would probably also make sense to look into what other projects did when migrating away from SF. + 2014-05-13: Work in progress. Hosting wish list at the end + of this file. + 54) Move away from CVS to a more modern revision control system. Find out if there are any objection against going with Git. Using Git would also have the advantage that SF now pretends @@ -127,14 +130,6 @@ http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/TODO 55) Apply for Coverity scans: http://scan.coverity.com/ -56) Apply for the "free online access for qualified open-source - software projects" for the Co-Advisor HTTP compliance tests: - http://coad.measurement-factory.com/details.html#pricing - -57) Allow piping into external programs to allow more powerful - filters and policy decisions. Incomplete support available - in Fabian's popen branch. - 58) Move more template strings from the code into the actual templates. 59) Import the German template translation. @@ -216,7 +211,7 @@ http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/TODO and redirect requests for them to Privoxy. 86) Add a server-body-tagger action. This is trivial as as all the - functionallity required to do it already exists. + functionality required to do it already exists. 87) Add a client-body-tagger action. This is less trivial as we currently don't buffer client bodies. After 14) is implemented it would be @@ -230,10 +225,6 @@ http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/TODO reasons on the blocked page that haven't been overruled, not just the last one. -90) Implement NO-TAG: patterns that enable a section if the - provided pattern doesn't match any TAG. This would make - some things cleaner. - 91) Add an optional limit for internal redirects. It would probably be reasonable to default to a limit of one and showing an error message if the request for the redirect URL would be redirected @@ -264,11 +255,9 @@ http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/TODO acceptable if the client and Privoxy are running on the same system or in a trusted environment. -96) Enabled filters should be easier to look up. Currently most functions - that work with filters spent more (duplicated) code on finding - filters than on actually doing something useful with them. Dividing - filters by type instead of filter file would reduce the lookup-code - quite a bit. +96) Filters should be easier to look up. Currently get_filter() has to + go through all filters and skip the filter types the caller isn't + interested in. 98) When showing action section on the CGI pages, properly escape line breaks so they can be copy&pasted into action files without @@ -329,3 +318,91 @@ http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/TODO can cause problems for gpg when uploading keys through Privoxy. 115) Add ICAP (RFC 3507) support. FR #3615158. + +116) Due to the use of sscanf(), Privoxy currently will fail to properly + parse chunks whose size can't be represented with 32 bit. This is + unlikely to cause problems in the real world, but should eventually + be fixed anyway. See also: + https://bugzilla.mozilla.org/show_bug.cgi?id=959100 + +118) There should be "escaped" dynamic variables that are guaranteed + not to break filters. + +119) Evaluate using pcre's jit mode. + +120) Add an option to limit pcre's recursion limit below the default. + On some platforms the recursion limit doesn't prevent pcre from + running out of stack space, causing the kernel to kill Privoxy + ungracefully. + +121) Add HTTP/2 support. As a first step, incomming HTTP/1.x requests + should be translated to outgoing HTTP/2 requests where possible + (and if desired by the user). + +122) Allow customized log messages. + +123) Evaluate if the voluntarily-disclose-session-keys option in Firefox + (and other browsers) can be leveraged. Probably depends on #16. + +124) Add support for the "lightweight OS capability and sandbox framework" + Capsicum. http://www.cl.cam.ac.uk/research/security/capsicum/ + +125) Allow clients to HTTPS-encrypt the proxy connection. + +126) Run the Co-Advisor HTTP compliance tests, evaluate the results, + fix the compliance issues that aren't by design and document + the rest. + Note that Privoxy developers qualified for free account upgrades: + http://coad.measurement-factory.com/details.html#pricing + +127) Add "real" CGI support (serve program output instead of forwarding + the request). The work is mostly done due to +external-filter{}. + +########################################################################## + +Hosting wish list (relevant for #53) + +What we need: + +- Bug tracker +- Mailinglists (Mailman with public archives preferred) +- Webspace (on a Unix-like OS that works with the webserver targets + in GNUMakefile) +- Source code repositories (currently CVS, but migrating away + from it is TODO #54 anyway and shouldn't be too much trouble) +- Commit mails (preferably with unified diffs) + +(Unsorted) details to look at when evaluating hosters: + +1. Preferably no third-party ads and trackers. + External images, CSS and JavaScript may count as trackers + but texts like "supported by company XYZ" may be acceptable. + +2. JavaScript should be optional or not used at all. + +3. Services we don't need shouldn't be enabled anyway. + (We currently don't use Web forums, wikis, surveys etc.) + +4. It would be preferable if the hoster didn't have a bad track + record as far as user experience, security and privacy are + concerned and if the terms of service are "reasonable" and + haven't changed too often in the past. Updates in the past + should have been improvements and not regressions. + +5. It would be preferable if most of the server administration + is done by a trusted third-party (or at least not a lot of work + for us). + +6. The server(s) should be located in a country with laws we can + understand and follow (or at least not unintentionally violate). + +7. A server location in a country with some kind of due process + and strong data protection laws (at least on paper) would be + preferable. + +8. Given that Privoxy is a free software project it would be + preferable if the hoster would use free software where possible. + +9. Migrating away from the hoster in the future without losing + any important data should be possible without writing web + scrapers first.