Add parameter --product to symupload.exe

Adding an optional parameter --product to symupload.exe.  If specified it will
be passed to the symbol server as POST parameter 'product'.

As part of this, I'm also fixing:
 - Removed the .vcproj file as it can be generated from the .gyp file on
demand.
 - error C4335: Mac file format detected.  Fixed the line endings for omap.cc
and dia_util.cc.
 - warning C4003: not enough actual parameters for macro 'max'

I'm in the process of recompiling symupload.exe using MSVS 2013 and DIA SDK
12.0.  I'll upload a new patch set after that.

Committed: https://code.google.com/p/google-breakpad/source/detail?r=1402

[Mark Mentovai]

What is the point of --product? How is it used on the server? Is it just an
extra bit of data to associate a symbol file with a particular product, or will
it be consulted for some purpose during processing?

[ivanpe]

On 2014/11/15 04:47:57, Mark Mentovai wrote:
> What is the point of --product? How is it used on the server? Is it just an
> extra bit of data to associate a symbol file with a particular product, or
will
> it be consulted for some purpose during processing?

Two purposes:

1. Symbol uploads from external (non-Google) IP addresses won't be allowed
unless they provide a whitelisted product name.  Now that Corp proxy is going
away we need this for the Windows Symbol Converter.  Other teams may have
similar issues.

2. For statistics, so that we can tell how much memory is consumed by the
symbols for a given product.

[Mark Mentovai]

ivanpe wrote:
> On 2014/11/15 04:47:57, Mark Mentovai wrote:
> > What is the point of --product? How is it used on the server? Is it just an
> > extra bit of data to associate a symbol file with a particular product, or
> will
> > it be consulted for some purpose during processing?
> 
> Two purposes:
> 
> 1. Symbol uploads from external (non-Google) IP addresses won't be allowed
> unless they provide a whitelisted product name.  Now that Corp proxy is going
> away we need this for the Windows Symbol Converter.  Other teams may have
> similar issues.

Is having a magic --product string supposed to be a substitute for
authentication in this case? Is there a design written up for allowing
symuploads from non-Google addresses?

> 2. For statistics, so that we can tell how much memory is consumed by the
> symbols for a given product.

[ivanpe]

On 2014/11/17 18:47:30, Mark Mentovai wrote:
> ivanpe wrote:
> > On 2014/11/15 04:47:57, Mark Mentovai wrote:
> > > What is the point of --product? How is it used on the server? Is it just
an
> > > extra bit of data to associate a symbol file with a particular product, or
> > will
> > > it be consulted for some purpose during processing?
> > 
> > Two purposes:
> > 
> > 1. Symbol uploads from external (non-Google) IP addresses won't be allowed
> > unless they provide a whitelisted product name.  Now that Corp proxy is
going
> > away we need this for the Windows Symbol Converter.  Other teams may have
> > similar issues.
> 
> Is having a magic --product string supposed to be a substitute for
> authentication in this case? Is there a design written up for allowing
> symuploads from non-Google addresses?
> 
> > 2. For statistics, so that we can tell how much memory is consumed by the
> > symbols for a given product.

According to the design, the restriction for symbol uploads should be based on
IP address.  This is probably still the best longer term solution.  We had to
change the current implementation of the IP address restriction (in order to
accommodate a Windows Symbol Converter running on GCE Windows cloud VMs). 
Unfortunately, this affected some users and providing a product name can serve
as a temporary workaround until the IP restriction is fixed.  So relying on (1)
should be temporary.  (2) should still be a valid long term reason for this
parameter, I think.

[Mark Mentovai]

Yes, (2) is still valid, and LGTM for that, but I’m very concerned about using
(1) for any amount of time, even as a temporary workaround.

[ivanpe]

On 2014/11/17 20:55:46, Mark Mentovai wrote:
> Yes, (2) is still valid, and LGTM for that, but I’m very concerned about using
> (1) for any amount of time, even as a temporary workaround.

Thanks.  We'll make sure the IP address filtration on the server side works and
we'll not be using --product as a workaround.

[Mark Mentovai]

LGTM still stands.