GnuCash 2.1.2 directions

[Wm Stewart]

Can someone explain why this bug has been closed, ignored?  I honestly
thought after my first notification of surreptitious external IP connection
three months ago that this would have been considered seriously by the
development team.  Rather disillusioning - not sure why I would report bugs
in the future if they are going to be treated like this...

   http://bugzilla.gnome.org/show_bug.cgi?id=407458#c14

   Please advise (a) why would you close a bug that indicates something
   as serious as hidden external IP connection that no-one has an
   explanation for (b) what does "no data to work with" mean, since
   instructions on how to replicate are given above?

Wm Stewart wrote:
> Derek Atkins wrote:
>> Wm Stewart <wstewart at livinginternet.com> writes:
>>
>>>> I just installed my freshly built gnucash-2.2.1 on Centos-5.  While
>>>> installing gnucash-docs, it tries to contact xml DTD repositories.
>>>> Is that what is happening on windows?
>> I don't think so.  This has to do with Gconf/Orbit, not Gnucash
>> or GnuCash-docs.  I suspect that this would happen with ANY gtk+
>> application that installed gconf too.
>>
>>> I honestly don't know, but don't think so, since this has to do with
>>> configuration settings.  I think someone smarter than me needs to find some
>>> Windows machines without gnucash installed, and run and trap the access as
>>> closely as possible, ideally to code that can be read.  When your firewall
>>> asks you whether to allow the external connection, the application freezes
>>> at that point until it gets a response - are there analyzers that could
>>> tell what code was running at that point?
>> Well, there's always 'gdb' to figure out where in the code you are.
>>
>>> I'm concerned because there is no notification of the access and without a
>>> good external firewall most people would not know about it, and as per the
>>> bug trail if the external access is not allowed then the configuration
>>> settings and application aren't usable -- for example the installer will
>>> not work on Internet disconnected computers because the external
>>> communication is a requirement of operation.
>> I think it's unlikely to be a virus, although it's possible.  Can you
>> run a network analyzer and see what protocol the connection is making?
>> I'm wondering if the person who built the gconf or orbit package
>> somehow included their own IP address in the binary and therefore it's
>> trying to "phone home" in terms of trying to reconnect back to already
>> running gconf instances?
>>
>> I just find this very very odd.
>>
>> -derek
>>
> 
> I have modest technical skills, but my input is limited to that of a user
> in this area, and will have to look for help from someone that can test on
> a new machine without previous installs.
> 
> I doubt it's a "phone home" because the IP was different in my and Manuel's
> case.  It is very odd.  Basically, it shouldn't be happening.  I really
> hope that it is not a virus.
> 
>