On 2020-01-07 16:02, LMH wrote:
> Marco Atzeri wrote:
>> Am 07.01.2020 um 21:58 schrieb LMH:
>>> This is the version of bash,
>>>
>>> GNU bash, version 4.3.42(4)-release (i686-pc-cygwin)
>>>
>>> it would be very helpful as a first step if I could find a verified
>>> digital signature for this version of bash. The index here,
>>>
>>> https://ftp.gnu.org/gnu/bash/
>>>
>>> gives an archive of bash with a signature for each tar.gz but not the
>>> signature for each version of the extracted binary.
GNU packages are source only and GNU does not distribute binaries. Some GNU
maintainers may make binaries available from their own personal systems.
Binaries are built for each platform with some compiler version that runs on
that platform, so each binary for each platform, compiler, and compilation run
has a different digital signature, as each compilation run typically injects
time stamps and other run-dependent data, especially with included debug info.
The reproducible build movement is trying to reduce and eliminate those
variations for easier binary validation and verification, but requires tool
chains which support suppression of all info not strictly dependent on the
source code, compiler, tools, and platform versions.
Each source package is typically packaged with components for that platform
package, so the best you can do is probably check the signature of the original
GNU bash source package against the copy included verbatim in the Cygwin source
package as the build base; the hashes of the downloaded Cygwin bash source and
binary packages against those in your latest downloaded setup.ini or the
x86{,_64}/release/bash/sha512.sum file on your local mirror or the sourceware
mirror; and the signature of x86{,_64}/setup.ini in x86{,_64}/setup.ini.sig on
your local mirror or the sourceware mirror.
>> that is not the last version of bash, so I guess your system is not
>> updated anyway
>>
>> $ bash --version
>> GNU bash, version 4.4.12(3)-release (i686-pc-cygwin)
> No, this is an older system that I keep around to run and test XP software
> on. It has the latest version of cygwin that still supports XP (2.874). This
> system isn't on the internet very often.
>
> It is still of interest to me to understand how the components of cywgin
> work and what controls such things as how and why IPC may be triggered. This
> is especially true when I see behavior that doesn't make sense to me. I
> don't see any reason why bash should need to communicate with svchost every
> time it is run, especially where blocking that communication has no
> discernible effect.
>
> If this is evidence of a system problem somewhere, I of course would like to
> know about that as well.
If you are or appear to be on a domain, any Cygwin access to user and some other
info may invoke a Windows call which accesses the domain controller.
On newer systems, if you have not disabled Windows usage monitoring, data
collection, and submission to MicroSoft, or have any MicroSoft accounts instead
of local accounts, any Windows call may access MicroSoft domain systems.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
