User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 Firefox/0.10 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040928 Firefox/0.10 When you take a look at the rss-feeds of the update-page (links are in the faq), you can see that adblock takes the first two items, and imagezoom takes the 3e, 4e, 5e and 6e item. it would be the best to have just include the latest version of a extension rather than displaying all versions this is for the Most Popular and Top Rated feeds. Reproducible: Always Steps to Reproduce: 1. 2. 3.

Good point.

Not a high priority item, but something that'd be nice to have. :-) --> Alan (when you're not busy)

I think the best way to do this would to break up the versions into separate columns for major, minor, subminor, build, like we have the Applications table. We also need to enforce the use of only integers. Wolf - I'd like you to include that in your overhaul of UMO. There aren't that many that we'd have to correct before conversion: Phoenity Adblock ChatZilla MultiZilla SphereGnome Quote Colors Gmail Notifier Mozilla Calendar

I don't have access to the source code anyways.

Bulk Moving Web Site bugs to new component. (Filter: massumowebsitespam)

This should fix the bug.

This overrides patch 169781 fixing a correlation bug and optimizing indexes usage.

Comment on attachment 169841 [details] [diff] [review] Inline subselect to show only most recent version matching criteria Don't hardcode app names. Just check to see if it is not blank. That way, as we add new apps, it will get picked up automatically. I don't like the use of ?: for if tests. Please change it to the proper MIMEtype for RSS.

"Improves" previous attachment (id=169841) according to alanjstr suggestions

Comment on attachment 171449 [details] [diff] [review] Inline subselect to show only most recent version matching criteria We want to escape all passed vars on their way in. Doesn't core/config.php already do this?

Comment on attachment 171449 [details] [diff] [review] Inline subselect to show only most recent version matching criteria Put the escape_string() stuff at the top and not inside the SQL. When we separate the SQL from the code we want it to be reusable.

(In reply to comment #11) > (From update of attachment 171449 [details] [diff] [review] [edit]) > Put the escape_string() stuff at the top and not inside the SQL. When we > separate the SQL from the code we want it to be reusable. > That's the best way to make it less reusable. When you'll put all the sql in one place, that will be the proper place to escape strings. This is the way we make the code reusable. That's called separation of concerns: you plan to build an SQL abstraction layer, escape_string() is about sanitizing FOR THE DB, it goes *inside* the SQL layer. It makes no sense dbescaping strings *before* I pass them to a generic function like get_extensions_list($appname,$startdate). I would even not know get_extensions_list() uses SQL internally, why should I escape "'"? It is a job the SQL-related function must do *locally* when it's about to hit the DB. It's plain wrong to escape indiscriminately when you read the input. Think about it: 1) escaping rules can be different from one DBMS to another; 2) if you need, for instance, to issue a shell command, you need another kind of escaping; 3) if you need, for instance, to print back the value, you need another kind of escaping (htmlentities). Making a rule out of your suggestions means messing up all the variables. It may work for very simple scripts, but you can't found a framework on it!

What if we use those variables for things other than the SQL? Or what if we want to manipulate it first? It has been suggested that we put all of our "make safe" code up front so that we don't have to code for it later. I'm not sure I want to assume that the function we pass the data to makes it safe.

(In reply to comment #13) > What if we use those variables for things other than the SQL? Or what if we > want to manipulate it first? Short answer: your code will likely break. This is the point. There's nothing like an "absolutely safe" variable: it depends on context. A null variable is "safe" if you put it in a nullable field of a database row, is very unsafe if you use it as a function pointer :-) > It has been suggested that we put all of our "make safe" code up front so that > we don't have to code for it later. It is a very dangerous suggestion, based on a very dangerous assumption: that you can make a variable safe under every respect (see above). The escape_string() function you use to "make it safe", ensures only that if used in the context of a *mysql* query and single quoted (other assumption) it won't allow SQL injection. Another dangerous assumption is that you won't manipulate that variable further, before you hit the database. Further manipulation (by built-in or third party functions, for instance) may fail, in case it expects a "normal" or differently escaped string (did you say LDAP?), or it could vanify the escaping by accident. > I'm not sure I want to assume that the function we pass the data to makes it safe. When you're building a library or a framework, even your simple "put all the SQL in one place" thing, you should program defensely on the framework side, not on the user/client code side. I'm not sure I want assume (in my function) that the caller remembers to make the arguments safe. At least I should check. Better if I do the escaping locally by myself and I document my function telling that client code should pass in "natural" unescaped strings.

Ok, fixed the bitrot and rolled in the patch for bug 278394

Comment on attachment 171589 [details] [diff] [review] changed http to https too I didn't test it, but it looks ok (ignoring nitpicks discussed on IRC).

Fixed in latest version.