On Tue, Aug 6, 2013 at 4:31 PM, Eric Rubin-Smith <[email protected]> wrote:

> I spent a couple hours hunting for a bug in which fossil does not properly
> apply changes to my custom fields to the ticket table.  The root cause
> appears to be these lines from cgi.c's add_param_list():
>
> ====
>     if( fossil_islower(zName[0]) ){
>       cgi_set_parameter_nocopy(zName, zValue);
>     }
> ====
>
> ... i.e. silently ignore capitalized POST argument names.  Is there a
> reason for that?
>

Yes there is.

Fossil combines inputs from a number of different sources into a single
namespace:

    (1)  CGI Environment Variables
    (2)  URL query parameters
    (3)  POST parameters in the HTTP request payload
    (4)  Cookie values

Internally, the Fossil C code accesses the parameter using the
cgi_parameter(zName, zDefault) function.  This function is so commonly used
that special macros are defined to make it easier to type:

     #define P(X)  cgi_parameter((X),0)
     #define PD(X,Y)   cgi_parameter((X),(Y))

So if the code needs to know the value of CGI environment variable
REMOTE_USER it runs P("REMOTE_USER").  Or to find the value of the "uuid"
query parameter, it runs P("uuid").  And so forth.  Note that when the code
asks for the value of "uuid", it does not know nor care if that is a query
parameter, a POST parameter, or a cookie.

In order to prevent a cookie, query parameter, or POST parameter from
overriding a CGI environment variable (which would be a very serious
security vulnerability) the names of cookies, query parameters and POST
parameters are required to begin with a lower-case letter.

It would certainly be possible to invent a less-restrictive rule that
allowed for some upper-case POST and query parameters and cookies as long
as they do not collide with environment variable names.  But the current
rule ("no upper-case except for environment variables") is simple and
effective.


> It appears to have been like that since the very first check-in of the
> file.  I can't possibly be the only person in six years to have been hit by
> this.
>
> Fossil should have rejected my attempt to create capitalized ticket table
> column names if it was planning on ignoring edits to those fields later.
>
> And it should warn me on the ticket table edit page that capitalized names
> do not work.
>
> Or, better, it should just allow capitalized ticket table column names.
>
> Also, I managed to hose my repo by changing my ticket column names from
> upper case to lower case, hoping that fossil would have some heuristics to
> carry my data over, or else would warn me that it was going to blow away my
> values.  I hoped in vain.  There should be a warning about that, too.
>
>
No information is lost when you change your ticket table definition.  To
recover, just change the ticket table schema back and it will be
repopulated to exactly what it contained before.  The ticket table itself
is just a cache for the contents of the ticket-change artifacts, and those
artifacts are immutable.  Whenever you change the ticket table schema,
Fossil automatically rebuilds the cache.  It is not possible to lose
information this way.



> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
[email protected]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to