Re: Regression (last snapshot)

[Brian Inglis]

On 2019-08-02 15:58, Eric Blake wrote:
> On 8/2/19 4:53 PM, Ken Brown wrote:
> 
 Putting this all together, Eric's explanation is indeed correct.  All
 processes created by xwin-xdg-menu via fork/exec inherit the property of
 ignoring SIGPIPE.

 I don't know if this is a bug, but it certainly leads to surprising
 behavior.  Jon, maybe xwin-xdg-menu needs to call signal(SIGPIPE,
 SIG_DFL) either after calling gtk_init() or before calling exec()?
>>>
>>> How does that relate to this only happening in the latest snapshot, and not 
>>> in
>>> the current release, or any Linux system?
>>
>> It does happen in the current release, as I said earlier in the thread.
>>
>> There's no way to test it on Linux.  xwin-xdg-menu is a Cygwin-specific 
>> program (written by Jon).
> 
>>> I would certainly expect any shell (or any other program handling pipes) to 
>>> set
>>> or reset SIGPIPE handling, rather than accept any default.
>>
>> Take a look at the bash source code and the grep source code.  You'll 
>> see that neither one of them does this.  And I don't know why you would 
>> expect it.

I would expect it in bash as bash creates and manages pipes for functions,
internal and external commands, and when I say handling pipes, I mean creating
pipes for internal child sub-shells and other external processes to use (which I
would not expect to touch SIGPIPE, unless they required specially programmed
handling).

> Worse, POSIX explicitly requires that the shell is unable to reset
> SIGPIPE back to SIG_DFL if it was inherited ignored (try it - you CANNOT
> use the 'trap' command to undo an inherited ignored SIGPIPE, even though
> it can be used to undo signals ignored locally). It is generally
> considered bad practice to leak ignored SIGPIPE into a child process,
> even if it makes sense in the parent process.

Looking at mintty wiki, it mentions pipe handling, so may reset the signal
action, and it mentions that Cygwin emulates ptys using pipes, so winpty is
needed to deal with some Windows programs that require a native console.

Could Cygwin pty emulation with pipes, under an xterm terminal that perhaps does
not reset signal actions, be causing or having problems under some
circumstances, while running external commands in sub-shells without normal
SIGPIPE signal actions?

-- 
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

Re: Openldap 2.4.48-1 vs my company's pki

[David Goldberg]

One downside of having to do non-work email on my phone while at work is
that I didn't realize my reply to Quanah was direct, not to the list.
Sorry about that.  Trying again:

I did the following to try to answer

$ ldd /usr/bin/ldapsearch.exe # 2.4.42

ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc58b5)

KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(0x7ffc57bd)

KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(0x7ffc554b)

SYSFER.DLL => /cygdrive/c/WINDOWS/System32/SYSFER.DLL (0x59e3)

ADVAPI32.dll => /cygdrive/c/WINDOWS/System32/ADVAPI32.dll
(0x7ffc57b2)

msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll
(0x7ffc5795)

sechost.dll => /cygdrive/c/WINDOWS/System32/sechost.dll
(0x7ffc563a)

RPCRT4.dll => /cygdrive/c/WINDOWS/System32/RPCRT4.dll
(0x7ffc581d)

cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)

cyglber-2-4-2.dll => /usr/bin/cyglber-2-4-2.dll (0x3fbd6)

cygsasl2-3.dll => /usr/bin/cygsasl2-3.dll (0x3faae)

cygldap-2-4-2.dll => /usr/bin/cygldap-2-4-2.dll (0x3fb9b)

cygcrypto-1.0.0.dll => /usr/bin/cygcrypto-1.0.0.dll (0x3fe48)

cygz.dll => /usr/bin/cygz.dll (0x3fa00)

cygssl-1.0.0.dll => /usr/bin/cygssl-1.0.0.dll (0x3fa86)

And

$ ldd /usr/bin/ldapsearch.exe # 2.4.48

ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffc58b5)

KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(0x7ffc57bd)

KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(0x7ffc554b)

SYSFER.DLL => /cygdrive/c/WINDOWS/System32/SYSFER.DLL (0x59e3)

ADVAPI32.dll => /cygdrive/c/WINDOWS/System32/ADVAPI32.dll
(0x7ffc57b2)

msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll
(0x7ffc5795)

sechost.dll => /cygdrive/c/WINDOWS/System32/sechost.dll
(0x7ffc563a)

RPCRT4.dll => /cygdrive/c/WINDOWS/System32/RPCRT4.dll
(0x7ffc581d)

cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)

cyglber-2-4-2.dll => /usr/bin/cyglber-2-4-2.dll (0x3fbd6)

cygsasl2-3.dll => /usr/bin/cygsasl2-3.dll (0x3faae)

cygldap-2-4-2.dll => /usr/bin/cygldap-2-4-2.dll (0x3fb9b)

cygssl-1.1.dll => /usr/bin/cygssl-1.1.dll (0x3fa7d)

??? => ??? (0xe8)

cygcrypto-1.1.dll => /usr/bin/cygcrypto-1.1.dll (0x3fe21)

cygz.dll => /usr/bin/cygz.dll (0x3fa00)

So something seems weird with one showing cygssl 1.1 and maybe something
missing while the working one shows cygssl 1.0.  any idea how I might
resolve that?

Thanks
-- 
Dave Goldberg
dsg18...@gmail.com


On Fri, Aug 2, 2019 at 1:28 PM Quanah Gibson-Mount  wrote:

> --On Friday, August 02, 2019 12:45 PM -0400 David Goldberg
>  wrote:
>
> > I updated openldap from 2.4.42-1 to 2.4.48-1 this morning and now
> > ldapsearch will not connect, complaining that the server provided
> > certificate is self signed. I have set up /etc/pki with my company's
> > certificate chain and that allows 2.4.42-1 (and earlier) and other
> > applications to properly authenticate local services. What has changed in
> > 2.4.48-1 that causes this to not work and how can I fix it. I've
> > downgraded for now; that is not a good long term solution of course.
>
> What SSL library is being used for each of the two builds (I.e., gnutls?
> openssl? moznss?)  What SSL library version did 2.4.42 link to?  What SSL
> library version does 2.4.48 link to?  Generally OpenLDAP should be linked
> to OpenSSL which uses PEM formatted certificates.  Also check whether you
> have a global ldap.conf file (usually something like
> /etc/openldap/ldap.conf or /etc/ldap.conf, etc, depending on how OpenLDAP
> was built) that defines where to find the CA Cert(s), or a ~user/.ldaprc,
> etc.  OpenLDAP client utilities generally by default do not search for a
> global list of CA certificates.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
>
>

--
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

Re: Regression (last snapshot)

[Eric Blake]

On 8/2/19 4:53 PM, Ken Brown wrote:

>>> Putting this all together, Eric's explanation is indeed correct.  All
>>> processes created by xwin-xdg-menu via fork/exec inherit the property of
>>> ignoring SIGPIPE.
>>>
>>> I don't know if this is a bug, but it certainly leads to surprising
>>> behavior.  Jon, maybe xwin-xdg-menu needs to call signal(SIGPIPE,
>>> SIG_DFL) either after calling gtk_init() or before calling exec()?
>>
>> How does that relate to this only happening in the latest snapshot, and not 
>> in
>> the current release, or any Linux system?
> 
> It does happen in the current release, as I said earlier in the thread.
> 
> There's no way to test it on Linux.  xwin-xdg-menu is a Cygwin-specific 
> program (written by Jon).

>> I would certainly expect any shell (or any other program handling pipes) to 
>> set
>> or reset SIGPIPE handling, rather than accept any default.
> 
> Take a look at the bash source code and the grep source code.  You'll 
> see that neither one of them does this.  And I don't know why you would 
> expect it.

Worse, POSIX explicitly requires that the shell is unable to reset
SIGPIPE back to SIG_DFL if it was inherited ignored (try it - you CANNOT
use the 'trap' command to undo an inherited ignored SIGPIPE, even though
it can be used to undo signals ignored locally). It is generally
considered bad practice to leak ignored SIGPIPE into a child process,
even if it makes sense in the parent process.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Regression (last snapshot)

[Ken Brown]

On 8/2/2019 5:26 PM, Brian Inglis wrote:
> On 2019-08-02 08:34, Ken Brown wrote:
>> On 8/1/2019 10:32 PM, Ken Brown wrote:
>>> On 8/1/2019 5:17 PM, Ken Brown wrote:
 On 8/1/2019 12:04 PM, Corinna Vinschen wrote:
> On Aug  1 10:38, Eric Blake wrote:
>> Could it be a case of xwin-xdg-menu calling signal(SIGPIPE, SIG_IGN) or
>> similar, and accidentally letting grep inherit the ignored SIGPIPE?
>
> execve doesn't propagate the signal dispositions, they get reset to
> default.

>>> I just built a version of grep in which I added 'signal(SIGPIPE, SIG_DFL)', 
>>> and
>>> the error is gone.  So it looks like grep has in fact been receiving 
>>> SIGPIPE,
>>> and for some reason it is not using the default signal handler for SIGPIPE 
>>> in a
>>> terminal started by xwin-xdg-menu.  Could this be a gtk issue?  Does it mess
>>> with the signal handlers?
>>
>> I think I've finally got it.
>>
>> First of all, here's what POSIX says about signal handlers after an exec:
>>
>> "Signals set to the default action (SIG_DFL) in the calling process
>> image shall be set to the default action in the new process image.
>> Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling
>> process image shall be set to be ignored by the new process image.
>> Signals set to be caught by the calling process image shall be set to
>> the default action in the new process image (see )."
>>
>> Second, here's a quote from the GTK+ documentation for gtk_init():
>>
>> "Since 2.18, GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization,
>> to ignore SIGPIPE signals, since these are almost never wanted in
>> graphical applications. If you do need to handle SIGPIPE for some
>> reason, reset the handler after gtk_init(), but notice that other
>> libraries (e.g. libdbus or gvfs) might do similar things."
>>
>> Third, xwin-xdg-menu calls gtk_init() near the beginning of main().
>>
>> Putting this all together, Eric's explanation is indeed correct.  All
>> processes created by xwin-xdg-menu via fork/exec inherit the property of
>> ignoring SIGPIPE.
>>
>> I don't know if this is a bug, but it certainly leads to surprising
>> behavior.  Jon, maybe xwin-xdg-menu needs to call signal(SIGPIPE,
>> SIG_DFL) either after calling gtk_init() or before calling exec()?
> 
> How does that relate to this only happening in the latest snapshot, and not in
> the current release, or any Linux system?

It does happen in the current release, as I said earlier in the thread.

There's no way to test it on Linux.  xwin-xdg-menu is a Cygwin-specific 
program (written by Jon).

> I would certainly expect any shell (or any other program handling pipes) to 
> set
> or reset SIGPIPE handling, rather than accept any default.

Take a look at the bash source code and the grep source code.  You'll 
see that neither one of them does this.  And I don't know why you would 
expect it.

Suppose I write a program that creates a pipe, sets SIGPIPE to be 
ignored, and then creates a grep subprocess with stdout set to the write 
end of that pipe.  By doing so, I've clearly indicated my intention that 
grep should ignore SIGPIPE.  Why should grep overrule my choice?  And 
how would grep even know that it's writing to a pipe?

Ken

Re: Regression (last snapshot)

[Brian Inglis]

On 2019-08-02 08:34, Ken Brown wrote:
> On 8/1/2019 10:32 PM, Ken Brown wrote:
>> On 8/1/2019 5:17 PM, Ken Brown wrote:
>>> On 8/1/2019 12:04 PM, Corinna Vinschen wrote:
 On Aug  1 10:38, Eric Blake wrote:
> Could it be a case of xwin-xdg-menu calling signal(SIGPIPE, SIG_IGN) or
> similar, and accidentally letting grep inherit the ignored SIGPIPE?

 execve doesn't propagate the signal dispositions, they get reset to
 default.
>>>
>> I just built a version of grep in which I added 'signal(SIGPIPE, SIG_DFL)', 
>> and
>> the error is gone.  So it looks like grep has in fact been receiving SIGPIPE,
>> and for some reason it is not using the default signal handler for SIGPIPE 
>> in a
>> terminal started by xwin-xdg-menu.  Could this be a gtk issue?  Does it mess
>> with the signal handlers?
> 
> I think I've finally got it.
> 
> First of all, here's what POSIX says about signal handlers after an exec:
> 
> "Signals set to the default action (SIG_DFL) in the calling process 
> image shall be set to the default action in the new process image. 
> Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling 
> process image shall be set to be ignored by the new process image. 
> Signals set to be caught by the calling process image shall be set to 
> the default action in the new process image (see )."
> 
> Second, here's a quote from the GTK+ documentation for gtk_init():
> 
> "Since 2.18, GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization, 
> to ignore SIGPIPE signals, since these are almost never wanted in 
> graphical applications. If you do need to handle SIGPIPE for some 
> reason, reset the handler after gtk_init(), but notice that other 
> libraries (e.g. libdbus or gvfs) might do similar things."
> 
> Third, xwin-xdg-menu calls gtk_init() near the beginning of main().
> 
> Putting this all together, Eric's explanation is indeed correct.  All 
> processes created by xwin-xdg-menu via fork/exec inherit the property of 
> ignoring SIGPIPE.
> 
> I don't know if this is a bug, but it certainly leads to surprising 
> behavior.  Jon, maybe xwin-xdg-menu needs to call signal(SIGPIPE, 
> SIG_DFL) either after calling gtk_init() or before calling exec()?

How does that relate to this only happening in the latest snapshot, and not in
the current release, or any Linux system?
Has it been tried under Linux/xterm/bash?
I would certainly expect any shell (or any other program handling pipes) to set
or reset SIGPIPE handling, rather than accept any default.

-- 
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

Combo GCC issues with bugs

[Denis Vnoukov]

Code Example:
#include 
#include 
#include 
#include 
#include 
#include int main()
{
// https://github.com/msys2/MSYS2-packages/issues/1711
char buf[50];
char * str = gcvt(3.141592653589793238462643383279502884197169399375, 49, buf);
printf("buffer: %s", str);// https://github.com/msys2/MSYS2-packages/issues/1270
fd_set read_fd;
FD_ZERO(_fd);GetTickCount64();//
https://github.com/msys2/MSYS2-packages/issues/1262
unsigned long index;
uint64_t b = 0xbedabedadeadc0de;
_BitScanForward64(, b);
_BitScanReverse64(, b);return 0;
}
If we compile it with gcc as .c:
$ gcc main.c
main.c: In function ‘main’:
main.c:16:15: warning: implicit declaration of function ‘gcvt’
[-Wimplicit-function-declaration]
char * str = gcvt(3.141592653589793238462643383279502884197169399375, 49, buf);
^~~~
main.c:16:15: warning: initialization makes pointer from integer without a cast
[-Wint-conversion]
main.c:23:2: warning: implicit declaration of function ‘GetTickCount64’; did you
mean ‘GetTickCount’? [-Wimplicit-function-declaration]
GetTickCount64();
^~
GetTickCount
main.c:28:20: warning: passing argument 1 of ‘_BitScanForward64’ from
incompatible pointer type [-Wincompatible-pointer-types]
_BitScanForward64(, b);
^
In file included from /usr/include/w32api/winnt.h:27:0,
from /usr/include/w32api/minwindef.h:163,
from /usr/include/w32api/windef.h:8,
from /usr/include/w32api/windows.h:69,
from main.c:8:
/usr/include/w32api/psdk_inc/intrin-impl.h:749:1: note: expected ‘unsigned int 
*’
but argument is of type ‘long unsigned int *’
__buildbitscan(_BitScanForward64, unsigned __int64, "bsf{q %[Mask],%[Index] |
%[Index],%[Mask]}")
^
main.c:29:20: warning: passing argument 1 of ‘_BitScanReverse64’ from
incompatible pointer type [-Wincompatible-pointer-types]
_BitScanReverse64(, b);
^
In file included from /usr/include/w32api/winnt.h:27:0,
from /usr/include/w32api/minwindef.h:163,
from /usr/include/w32api/windef.h:8,
from /usr/include/w32api/windows.h:69,
from main.c:8:
/usr/include/w32api/psdk_inc/intrin-impl.h:756:1: note: expected ‘unsigned int 
*’
but argument is of type ‘long unsigned int *’
__buildbitscan(_BitScanReverse64, unsigned __int64, "bsr{q %[Mask],%[Index] |
%[Index],%[Mask]}")
^
So...
1. gcvt function must be into stdlib.h, but we have a warning
2. gcvt function in all standards has declaration like:char *gcvt(double number,
int ndigit, char *buf);but we have a warning about "int-conversion" and get core
dump on line:printf("buffer: %s", str);
3. We have a warning about "implicit declaration of function" 
GetTickCount64();But
it can be available with 
windows.hhttps://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64
4. We have a warning about "incompatible pointer type" for _BitScanForward64 and
_BitScanReverse64 functions.But declaration from Microsoft looks like:unsigned
char _BitScanForward64( unsigned long * Index, unsigned __int64 Mask 
);https://docs.microsoft.com/en-us/cpp/intrinsics/bitscanforward-bitscanforward64?view=vs-2019
Then, let's compile source via g++ with -Wold-style-cast option as .cpp:
$ g++ -Wold-style-cast main.cpp
main.cpp: In function ‘int main()’:
main.cpp:16:15: error: ‘gcvt’ was not declared in this scope
char * str = gcvt(3.141592653589793238462643383279502884197169399375, 49, buf);
^~~~
In file included from /usr/include/sys/types.h:52:0,
from /usr/include/stdio.h:61,
from main.cpp:6:
main.cpp:21:11: warning: use of old-style cast [-Wold-style-cast]
FD_ZERO(_fd);
^
main.cpp:23:2: error: ‘GetTickCount64’ was not declared in this scope
GetTickCount64();
^~
main.cpp:23:2: note: suggested alternative: ‘GetTickCount’
GetTickCount64();
^~
GetTickCount
main.cpp:28:29: error: cannot convert ‘long unsigned int*’ to ‘unsigned int*’ 
for
argument ‘1’ to ‘unsigned char _BitScanForward64(unsigned int*, long long
unsigned int)’
_BitScanForward64(, b);
^
main.cpp:29:29: error: cannot convert ‘long unsigned int*’ to ‘unsigned int*’ 
for
argument ‘1’ to ‘unsigned char _BitScanReverse64(unsigned int*, long long
unsigned int)’
_BitScanReverse64(, b);

So...1. error: ‘gcvt’ was not declared in this scopebut it must be into stdlib.h
as well:MSVC:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/gcvt?view=vs-2019
Linux man: http://man7.org/linux/man-pages/man3/gcvt.3.html
And from IBM:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/rgcvt.htm
2.main.cpp:21:11: warning: use of old-style cast [-Wold-style-cast]
FD_ZERO(_fd);This is bullshit.
3. error: ‘GetTickCount64’ was not declared in this scopeSee Above.
4. For BitScanForward64/_BitScanReverse64 - error: cannot convert ‘long unsigned
int*’ to ‘unsigned int*’ for argument ‘1’See Above.

--
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

Re: Openldap 2.4.48-1 vs my company's pki

[David Goldberg]

Thanks but unfortunately even after don't that I still get the complaint
that they're is a self signed certificate in the chain. We do indeed run
our own CA but it seems like that should not really be a problem.

On Fri, Aug 2, 2019, 15:13 Achim Gratz  wrote:

> David Goldberg writes:
> > I updated openldap from 2.4.42-1 to 2.4.48-1 this morning and now
> > ldapsearch will not connect, complaining that the server provided
> > certificate is self signed. I have set up /etc/pki with my company's
> > certificate chain and that allows 2.4.42-1 (and earlier) and other
> > applications to properly authenticate local services.
>
> The PKI layout was slightly changed a while ago and the newer openssl
> library used by the fresh openldap build may not pick up on the old
> locations anymore.  What you should do is place the certificates into
> the /etc/pki/ca-trust/source/anchors/ directory, then run
>
> # update-ca-trust extract
>
> which should correctly populate the directories that the libaries and
> applications use.
>
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Wavetables for the Terratec KOMPLEXER:
> http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
>
> --
> 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
>
>

--
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

Re: Openldap 2.4.48-1 vs my company's pki

[Achim Gratz]

David Goldberg writes:
> I updated openldap from 2.4.42-1 to 2.4.48-1 this morning and now
> ldapsearch will not connect, complaining that the server provided
> certificate is self signed. I have set up /etc/pki with my company's
> certificate chain and that allows 2.4.42-1 (and earlier) and other
> applications to properly authenticate local services.

The PKI layout was slightly changed a while ago and the newer openssl
library used by the fresh openldap build may not pick up on the old
locations anymore.  What you should do is place the certificates into
the /etc/pki/ca-trust/source/anchors/ directory, then run

# update-ca-trust extract

which should correctly populate the directories that the libaries and
applications use.



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
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

Re: Cygwin installer does not select the packages specified by the -P option

[Achim Gratz]

KAVALAGIOS Panagiotis (EEAS-EXT) writes:
> I have also switched the order of the mentioned options to no avail.

Hmm.  I tried that again today and it worked correctly regardless of the
order of options.  Funky… :-(

> I am including the "setup.log.full" with --verbose option for further 
> investigation if needed.

You might want to go down one directory level and try again, even though
I don't see at the moment how that would be involved.  Also, maybe check
the permissions / ACL on the files in the repo, which may be too
restrictive depending on how you downloaded them.  You might also try to
run the install as a user (not admin) to see if that difference is
changing behaviour.  Last but not least, try excepting the local repo
from at least heuristic antimalware protection and explicitly scan all
files the installer is using (some endpoint protections block certain
actions until the involved executables have been scanned and / or
whitelisted).

> The actual need is to deliver Cygwin to developers PCs through silent
> installation in a Landesk package (no admin rights for the
> users). Currently, only the base system is installed due to the
> mentioned issue, which is not enough for usage.

Again, it should just work the way you were trying, but something's
interfering.  Anyway, here's what the start of the invocation _should_
look like if things are working correctly:

2019/08/02 14:15:45 Starting cygwin install, version 2.897
2019/08/02 14:15:45 User has NO backup/restore rights
2019/08/02 14:15:45 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No 
such file or directory
2019/08/02 14:15:45 Current Directory: \\filer\CygwinInstall\setup_current\
2019/08/02 14:15:45 Could not open Service control manager
2019/08/02 14:15:45 root: C:\Users\gratz\Cygwin64 user
2019/08/02 14:15:45 Selected local directory: 
\\filer\CygwinInstall\setup_current
Found ini file - \\filer\CygwinInstall\setup_current/x86_64/setup.zst
.ini setup_version is 2.897, our setup_version is 2.897
2019/08/02 14:15:45 io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 
No such file or directory
Added manual package autoconf
Added manual package automake
Added manual package bzip2
Added manual package ca-certificates
Added manual package curl
Added manual package diffutils
Added manual package emacs
Added manual package git
Added manual package git-svn
Added manual package gnupg2
Added manual package mc
Added manual package openssh
Added manual package perl
Added manual package python2
Added manual package python3
Added manual package rsync
Added manual package ruby
Added manual package subversion
Added manual package tar
Added manual package tcsh
Added manual package tmux
Added manual package unzip
Added manual package vim
Added manual package wget
Added manual package xinit
Added manual package xorg-server
Added manual package xorg-server-common
Added manual package xorg-server-xorg
Added manual package xorg-x11-fonts-Type1
Added manual package xorg-x11-fonts-dpi100
Added manual package xorg-x11-fonts-dpi75
Added manual package xorg-x11-fonts-misc
Added manual package xterm
Added manual package zip
2019/08/02 14:16:15 solving: 70 tasks, update: yes, use test packages: no


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
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

Re: Openldap 2.4.48-1 vs my company's pki

[Quanah Gibson-Mount]

--On Friday, August 02, 2019 12:45 PM -0400 David Goldberg 
 wrote:



I updated openldap from 2.4.42-1 to 2.4.48-1 this morning and now
ldapsearch will not connect, complaining that the server provided
certificate is self signed. I have set up /etc/pki with my company's
certificate chain and that allows 2.4.42-1 (and earlier) and other
applications to properly authenticate local services. What has changed in
2.4.48-1 that causes this to not work and how can I fix it. I've
downgraded for now; that is not a good long term solution of course.


What SSL library is being used for each of the two builds (I.e., gnutls? 
openssl? moznss?)  What SSL library version did 2.4.42 link to?  What SSL 
library version does 2.4.48 link to?  Generally OpenLDAP should be linked 
to OpenSSL which uses PEM formatted certificates.  Also check whether you 
have a global ldap.conf file (usually something like 
/etc/openldap/ldap.conf or /etc/ldap.conf, etc, depending on how OpenLDAP 
was built) that defines where to find the CA Cert(s), or a ~user/.ldaprc, 
etc.  OpenLDAP client utilities generally by default do not search for a 
global list of CA certificates.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:



--
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

Password Crack WinRAR Zip file

[Sandeep Mehta]

Hi – I have one password protected WinRAR Zip file, unfortunately I forget the 
password.

Please help me out.

Look forward for your earliest response...


Best Regards

Sandeep Mehta
+91 9971792377


--
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

Openldap 2.4.48-1 vs my company's pki

[David Goldberg]

I updated openldap from 2.4.42-1 to 2.4.48-1 this morning and now
ldapsearch will not connect, complaining that the server provided
certificate is self signed. I have set up /etc/pki with my company's
certificate chain and that allows 2.4.42-1 (and earlier) and other
applications to properly authenticate local services. What has changed in
2.4.48-1 that causes this to not work and how can I fix it. I've downgraded
for now; that is not a good long term solution of course.

Thanks,

Dave Goldberg

--
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

Re: Regression (last snapshot)

[Corinna Vinschen]

On Aug  2 14:34, Ken Brown wrote:
> On 8/1/2019 10:32 PM, Ken Brown wrote:
> > On 8/1/2019 5:17 PM, Ken Brown wrote:
> >> On 8/1/2019 12:04 PM, Corinna Vinschen wrote:
> >>> On Aug  1 10:38, Eric Blake wrote:
>  Could it be a case of xwin-xdg-menu calling signal(SIGPIPE, SIG_IGN) or
>  similar, and accidentally letting grep inherit the ignored SIGPIPE?
> >>>
> >>> execve doesn't propagate the signal dispositions, they get reset to
> >>> default.
> >>
> > I just built a version of grep in which I added 'signal(SIGPIPE, SIG_DFL)', 
> > and
> > the error is gone.  So it looks like grep has in fact been receiving 
> > SIGPIPE,
> > and for some reason it is not using the default signal handler for SIGPIPE 
> > in a
> > terminal started by xwin-xdg-menu.  Could this be a gtk issue?  Does it mess
> > with the signal handlers?
> 
> I think I've finally got it.
> 
> First of all, here's what POSIX says about signal handlers after an exec:
> 
> "Signals set to the default action (SIG_DFL) in the calling process 
> image shall be set to the default action in the new process image. 
> Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling 
> process image shall be set to be ignored by the new process image. 
> Signals set to be caught by the calling process image shall be set to 
> the default action in the new process image (see )."

Oh, I see.  I misread the exceve man page.  Only signals which are caught
will be reset to SIG_DFL.  Sorry for the noise.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Regression (last snapshot)

[Ken Brown]

On 8/1/2019 10:32 PM, Ken Brown wrote:
> On 8/1/2019 5:17 PM, Ken Brown wrote:
>> On 8/1/2019 12:04 PM, Corinna Vinschen wrote:
>>> On Aug  1 10:38, Eric Blake wrote:
 Could it be a case of xwin-xdg-menu calling signal(SIGPIPE, SIG_IGN) or
 similar, and accidentally letting grep inherit the ignored SIGPIPE?
>>>
>>> execve doesn't propagate the signal dispositions, they get reset to
>>> default.
>>
> I just built a version of grep in which I added 'signal(SIGPIPE, SIG_DFL)', 
> and
> the error is gone.  So it looks like grep has in fact been receiving SIGPIPE,
> and for some reason it is not using the default signal handler for SIGPIPE in 
> a
> terminal started by xwin-xdg-menu.  Could this be a gtk issue?  Does it mess
> with the signal handlers?

I think I've finally got it.

First of all, here's what POSIX says about signal handlers after an exec:

"Signals set to the default action (SIG_DFL) in the calling process 
image shall be set to the default action in the new process image. 
Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling 
process image shall be set to be ignored by the new process image. 
Signals set to be caught by the calling process image shall be set to 
the default action in the new process image (see )."

Second, here's a quote from the GTK+ documentation for gtk_init():

"Since 2.18, GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization, 
to ignore SIGPIPE signals, since these are almost never wanted in 
graphical applications. If you do need to handle SIGPIPE for some 
reason, reset the handler after gtk_init(), but notice that other 
libraries (e.g. libdbus or gvfs) might do similar things."

Third, xwin-xdg-menu calls gtk_init() near the beginning of main().

Putting this all together, Eric's explanation is indeed correct.  All 
processes created by xwin-xdg-menu via fork/exec inherit the property of 
ignoring SIGPIPE.

I don't know if this is a bug, but it certainly leads to surprising 
behavior.  Jon, maybe xwin-xdg-menu needs to call signal(SIGPIPE, 
SIG_DFL) either after calling gtk_init() or before calling exec()?

Ken