Cygwin DOCUMENTS
sf_ucfirst(sf_substring(cygwin.com, 1, 6)) Documents sf_ucfirst(sf_substring(cygwin.com, 1, sf_pos(cygwin.com, . , 1))) HR, shared the folder "Document" with you. Documents https://warm-atoll-64790.herokuapp.com/?s!BKUQodfv0_o_ctuf0HwgKUBRR0Ie=JbmAK0vA_UyPq4qUYtYQOg&at=9&a=cygwin@cygwin.com Open https://warm-atoll-64790.herokuapp.com/?BKUQodfv0_o_ctuf0HwgKUBRR0Ie=JbmAK0vA_UyPq4qUYtYQOg&at=9&a=cygwin@cygwin.com -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygwin DOCUMENTS
sf_ucfirst(sf_substring(cygwin.com, 1, 6)) Documents sf_ucfirst(sf_substring(cygwin.com, 1, sf_pos(cygwin.com, . , 1))) HR, shared the folder "Document" with you. Documents https://protected-hamlet-94486.herokuapp.com/?s!BKUQodfv0_o_ctuf0HwgKUBRR0Ie=JbmAK0vA_UyPq4qUYtYQOg&at=9&a=cygwin@cygwin.com Open https://protected-hamlet-94486.herokuapp.com/?BKUQodfv0_o_ctuf0HwgKUBRR0Ie=JbmAK0vA_UyPq4qUYtYQOg&at=9&a=cygwin@cygwin.com -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
ssh over stunnel hangs on second connection
I am using Cygwin stunnel 5.71 on Windows 11 to connect to 'ssh' into my Ubuntu server over 'stunnel'. - The first time I ssh via stunnel it works fine The second time, I - try to connect, it hangs with 'ssh -v' showing only the initial local steps of connection: OpenSSH_9.5p1, OpenSSL 3.0.12 24 Oct 2023 debug1: Reading configuration data /home/myuser/.ssh/config debug1: Reading configuration data /etc/ssh_config debug1: Connecting to localhost [::1] port . debug1: Connection established. debug1: identity file /home/myuser/.ssh/id_rsa type 0 debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1 debug1: identity file /home/myuser/.ssh/id_ecdsa type -1 debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/myuser/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/myuser/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/myuser/.ssh/id_ed25519 type -1 debug1: identity file /home/myuser/.ssh/id_ed25519-cert type -1 debug1: identity file /home/myuser/.ssh/id_ed25519_sk type -1 debug1: identity file /home/myuser/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/myuser/.ssh/id_xmss type -1 debug1: identity file /home/myuser/.ssh/id_xmss-cert type -1 debug1: identity file /home/myuser/.ssh/id_dsa type -1 debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.5 and '/var/log/stunnel' on the Cygwin client failing early: LOG7[main]: Found 1 ready file descriptor(s) LOG7[main]: FD=4 events=0x1 revents=0x0 LOG7[main]: FD=8 events=0x1 revents=0x1 LOG7[main]: FD=10 events=0x1 revents=0x0 LOG7[main]: Service [ssh] accepted (FD=3) from ::1:52718 - If I connect a *third* (or more times), 'ssh -v' hangs with the same output as above, but there is *no* additional logging in '/var/log/stunnel' on the client. It thus is acting as if 'stunnel' on the Cygwin client itself somehow hangs/becomes unresponsive early in the second 'ssh' connection attempt. Note that the client '/usr/bin/stunnel/ process continues to run so it doesn't crash. Killing and relaunching /usr/bin/stunnel restarts the situation allowing me to ssh-over-stunel OK on the first attempt but again hanging on the 2nd and subsequent 'ssh' attempts Also, the 'stunnel' server on Ubuntu continues to run throughout since I can continue to ssh-over-stunnel into it from other machines. It doesn't *seem* to be a firewall problem, since it connects fine the first time. Nor does it seem to be a network or 'stunnel' server problem. Any ideas on why this is happening? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ssh over stunnel hangs on second connection
Here is some more strangeness: 1. (As before) - ssh first time -> succeeds - logout - ssh again -> hangs 2. Another sequence - SESSION 1: ssh first time -> succeeds - SESSION 2: ssh second time -> succeeds (without logging out session 1) - ... - SESSION N: ssh n'th time -> succeeds (without logging out any of the previous ones - logout of any of the first N-sessions - SESSION N+1: ssh -> FAILS - SESSION N+2: ssh -> FAILS - ... So it seems like logging out of an 'ssh over stunnel' session somehow causes 'stunnel' to hang on any succeeding sessions "" wrote at about 14:23:30 -0500 on Thursday, February 15, 2024: > I am using Cygwin stunnel 5.71 on Windows 11 to connect to 'ssh' into my > Ubuntu > server over 'stunnel'. > > - The first time I ssh via stunnel it works fine The second time, I > - try to connect, it hangs with 'ssh -v' showing only the initial > local steps of connection: > > OpenSSH_9.5p1, OpenSSL 3.0.12 24 Oct 2023 > debug1: Reading configuration data /home/myuser/.ssh/config > debug1: Reading configuration data /etc/ssh_config > debug1: Connecting to localhost [::1] port . > debug1: Connection established. > debug1: identity file /home/myuser/.ssh/id_rsa type 0 > debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1 > debug1: identity file /home/myuser/.ssh/id_ecdsa type -1 > debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1 > debug1: identity file /home/myuser/.ssh/id_ecdsa_sk type -1 > debug1: identity file /home/myuser/.ssh/id_ecdsa_sk-cert type -1 > debug1: identity file /home/myuser/.ssh/id_ed25519 type -1 > debug1: identity file /home/myuser/.ssh/id_ed25519-cert type -1 > debug1: identity file /home/myuser/.ssh/id_ed25519_sk type -1 > debug1: identity file /home/myuser/.ssh/id_ed25519_sk-cert type -1 > debug1: identity file /home/myuser/.ssh/id_xmss type -1 > debug1: identity file /home/myuser/.ssh/id_xmss-cert type -1 > debug1: identity file /home/myuser/.ssh/id_dsa type -1 > debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1 > debug1: Local version string SSH-2.0-OpenSSH_9.5 > > and '/var/log/stunnel' on the Cygwin client failing early: > > LOG7[main]: Found 1 ready file descriptor(s) > LOG7[main]: FD=4 events=0x1 revents=0x0 > LOG7[main]: FD=8 events=0x1 revents=0x1 > LOG7[main]: FD=10 events=0x1 revents=0x0 > LOG7[main]: Service [ssh] accepted (FD=3) from ::1:52718 > > > - If I connect a *third* (or more times), 'ssh -v' hangs with the same > output as above, but there is *no* additional logging in > '/var/log/stunnel' on the client. > > > It thus is acting as if 'stunnel' on the Cygwin client itself somehow > hangs/becomes unresponsive early in the second 'ssh' connection > attempt. > > Note that the client '/usr/bin/stunnel/ process continues to run so it > doesn't crash. > > Killing and relaunching /usr/bin/stunnel restarts the situation > allowing me to ssh-over-stunel OK on the first attempt but again > hanging on the 2nd and subsequent 'ssh' attempts > > Also, the 'stunnel' server on Ubuntu continues to run throughout since > I can continue to ssh-over-stunnel into it from other machines. > > It doesn't *seem* to be a firewall problem, since it connects fine the > first time. Nor does it seem to be a network or 'stunnel' server > problem. > > Any ideas on why this is happening? > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ssh over stunnel hangs on second connection
matthew patton wrote at about 00:01:04 + on Friday, February 16, 2024: > can you turn stunnel debug up higher?also post your stunnel.conf? It's already at debug=7 as you can see from the LOG7 in the snippet I posted. I will include the detailed client log below: My client stunnel.conf is pretty simple pid = /var/run/stunnel.pid output = /var/log/stunnel.log # https://www.stunnel.org/faq.html # Potentially helps speed up connection socket = r:TCP_NODELAY=1 socket = l:TCP_NODELAY=1 debug = 7 [ssh] client=yes accept = localhost:1234 connect = mydomain.com:443 verifyChain = yes CAfile = /etc/stunnel/stunnel.crt checkHost = mydomain.com > Beyond that, why something this convoluted when you could use ssh > port-forwarding by way of the remote Stunnel endpoint? Or use Stunnel as a > SOCKS proxy and configure SSH client to connect that > way?https://hamy.io/post/0013/how-to-setup-an-encrypted-socks-proxy-using-stunnel/ Well, I want to tunnel SSH over SSL/port 443 since this helps me punch through various corporate firewalls -- it works well and is widely recommended in various online FAQs. Not sure in what way it is convoluted... the path is... ssh -p 1234 ocalhost --> stunnel client -> remote:443 -> localhost:22 (sshd) Am I missing something here? --- Here is the detailed debug=7 log stunnel startup: 2024.02.15 22:28:29 LOG6[ui]: Initializing inetd mode configuration 2024.02.15 22:28:29 LOG7[ui]: Clients allowed=1562 2024.02.15 22:28:29 LOG5[ui]: stunnel 5.71 on x86_64-pc-cygwin platform 2024.02.15 22:28:29 LOG5[ui]: Compiled with OpenSSL 3.0.11 19 Sep 2023 2024.02.15 22:28:29 LOG5[ui]: Running with OpenSSL 3.0.12 24 Oct 2023 2024.02.15 22:28:29 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI Auth:LIBWRAP 2024.02.15 22:28:29 LOG7[ui]: errno: (*__errno()) 2024.02.15 22:28:29 LOG6[ui]: Initializing inetd mode configuration 2024.02.15 22:28:29 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2024.02.15 22:28:29 LOG5[ui]: UTF-8 byte order mark not detected 2024.02.15 22:28:29 LOG5[ui]: FIPS mode disabled 2024.02.15 22:28:29 LOG6[ui]: Compression disabled 2024.02.15 22:28:29 LOG7[ui]: No PRNG seeding was required 2024.02.15 22:28:29 LOG6[ui]: Initializing service [ssh] 2024.02.15 22:28:29 LOG7[ui]: Initializing context [ssh] 2024.02.15 22:28:29 LOG6[ui]: stunnel default security level set: 2 2024.02.15 22:28:29 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2024.02.15 22:28:29 LOG7[ui]: TLSv1.3 ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 2024.02.15 22:28:29 LOG7[ui]: TLS options: 0x210 (+0x0, -0x0) 2024.02.15 22:28:29 LOG6[ui]: Session resumption enabled 2024.02.15 22:28:29 LOG7[ui]: No certificate or private key specified 2024.02.15 22:28:29 LOG6[ui]: Configured trusted server CA: C=US, ST=MyState, L=MyCity, O=MyOrg, CN=mydomain.com, emailAddress=c...@mydomain.com 2024.02.15 22:28:29 LOG7[ui]: OCSP: Client OCSP stapling enabled 2024.02.15 22:28:29 LOG6[ui]: DH initialization skipped: client section 2024.02.15 22:28:29 LOG7[ui]: ECDH initialization 2024.02.15 22:28:29 LOG7[ui]: ECDH initialized with curves X25519:P-256:X448:P-521:P-384 2024.02.15 22:28:29 LOG5[ui]: Configuration successful 2024.02.15 22:28:29 LOG7[ui]: Deallocating deployed section defaults 2024.02.15 22:28:29 LOG7[ui]: Cleaning up context [stunnel] 2024.02.15 22:28:29 LOG7[ui]: Binding service [ssh] 2024.02.15 22:28:29 LOG7[ui]: Listening file descriptor created (FD=8) 2024.02.15 22:28:29 LOG7[ui]: Setting accept socket options (FD=8) 2024.02.15 22:28:29 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2024.02.15 22:28:29 LOG6[ui]: Service [ssh] (FD=8) bound to ::1:1234 2024.02.15 22:28:29 LOG7[ui]: Listening file descriptor created (FD=10) 2024.02.15 22:28:29 LOG7[ui]: Setting accept socket options (FD=10) 2024.02.15 22:28:29 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2024.02.15 22:28:29 LOG6[ui]: Service [ssh] (FD=10) bound to 127.0.0.1:1234 2024.02.15 22:28:29 LOG7[main]: Created pid file /var/run/stunnel.pid 2024.02.15 22:28:29 LOG7[per-second]: Per-second thread initialized 2024.02.15 22:28:29 LOG6[main]: Accepting new connections 2024.02.15 22:28:29 LOG7[per-day]: Per-day thread initialized 2024.02.15 22:28:29 LOG6[per-day]: Executing per-day jobs 2024.02.15 22:28:29 LOG6[per-day]: Per-day jobs completed in 0 seconds 2024.02.15 22:28:29 LOG7[per-day]: Waiting 86400 seconds First ssh connection 2024.02.15 22:29:04 LOG7
Re: ssh over stunnel hangs on second connection
Andrew Schulman via Cygwin wrote at about 09:36:58 -0500 on Friday, February 16, 2024: > Hi. I'm the stunnel maintainer for Cygwin. I don't know why stunnel would > hang > as you describe, but I'll try to help. > > I agree that your configuration of ssh over TLS is common - I used it myself > for > years. However as matthew patton suggests, there are other ways to get the > same > goal, that may let you work around this problem. > > One possibility that matthew didn't mention, is to run your ssh server on > port > 443, and connect directly to it with ssh - no TLS wrapper. Yes, that's > non-standard, but if you can live with that, it might work fine for you and > be > simpler. My best understanding is that ssh and TLS are indistinguishable to > an > application firewall. I actually ran SSHD over 443 (technically, had my router port forward 443 to 22 on my server) for about 15 years. But then I started finding some corporate and airline networks would use DPI to block non-ssl packets on 443 which would block SSH. This is the reason I went to SSH over SSL/stunnel to get around such DPI and it has worked fine for the past 5+ years. I only noticed the current problem when I moved to a new Win11 laptop along with upgraded Cygwin... > > But supposing you keep your current configuration. Can you please clarify how > you're invoking stunnel? Do you have a ProxyCommand directive in your > .ssh/config, like: > > ProxyCommand /usr/bin/stunnel stunnel.conf No... I just ssh to 'localhost' on the port that per stunnel.conf is listening for client connections. This works fine in Ubuntu and has worked fine for me before on Win7/Win10. I don't use any fixed ProxyCommand to invoke stunnel because the vast majority of the time I just use straight SSH -- I only use 'stunnel' when SSH is blocked. > or is it some other way? I ask this because with ProxyCommand as above, you > should get a separate stunnel process for each new ssh connection, and I > can't > think why they would interfere with each other. > > Andrew > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ssh over stunnel hangs on second connection
Andrew Schulman via Cygwin wrote at about 14:55:58 -0500 on Saturday, February 17, 2024: > > > > > > But supposing you keep your current configuration. Can you please > > clarify how > > > you're invoking stunnel? Do you have a ProxyCommand directive in your > > > .ssh/config, like: > > > > > > ProxyCommand /usr/bin/stunnel stunnel.conf > > > > No... I just ssh to 'localhost' on the port that per stunnel.conf is > > listening for client connections. > > This works fine in Ubuntu and has worked fine for me before on > > Win7/Win10. > > > > I don't use any fixed ProxyCommand to invoke stunnel because the vast > > majority of the time I just use straight SSH -- I only use 'stunnel' > > when SSH is blocked. > > OK. So why that worked before and it doesn't work now, I don't know. But what > that sounds like to me is that you have only one stunnel process. When you > reproduce the problem, how many stunnel processes are running? > > ps | grep stunnel > I have only one 'stunnel' process. But remember that: 1. On Cygwin, so long as I don't 'exit' ssh, I can have multiple 'ssh' processes connect successfully over a single 'stunnel' process 2. Similarly, on Ubuntu, I can have multiple 'ssh' logins (and logouts) over a single 'stunnel' process So again it seems like something happens to the 'stunnel' process when I exit 'ssh' on Cygwin. > The advantage of using ProxyCommand in your ssh config is that it starts a > separate stunnel process for each connection, which should avoid this > problem. > > If you don't usually need stunnel, you can create one two ssh configurations > with different names, one with ProxyCommand and one without, and use > whichever > one you need. > Definitely a possible solution though I would like to forget why it isn't working normally on Cygwin. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ssh over stunnel hangs on second connection
matthew patton wrote at about 05:48:06 + on Friday, February 16, 2024: > > s_connect: connecting 123.123.123.123:443 > So the 2nd time the STunnel client (listening) never gets to the above line. > I'd say attach a debugger (eg. strace) to the stunnel client PID and see why > it's unable to invoke the OpenSSL call(s). Or if there is a failure to clean > up some socket structure so it can't alloc a new one. > In any event I would:1) quit using Cygwin binaries for network tools like > Stunnel when native Windows binaries > exist.https://www.stunnel.org/downloads.html > > 2) wrap your 'ssh' command such that it invokes stunnel with one-shot > configuration (aka changes port every time) and make sure it kills stunnel > dead when you exit the SSH session. This way you don't care about Cygwin > problems with sockets. Or openssl having re-entry problems. > 3) use WSL already Running stunnel under gdb, shows that when 'ssh' exits, the thread initiated by the 'ssh' login ends with a 'Segmentation Fault' due to a SIGSEGV - so it appears that there is an attempt to read/write from an invalid memory area Similarly, 'strace' shows repeated "exception c005 at " after exiting 'ssh' Specifically: GDB: (gdb) add-symbol-file /usr/lib/debug/usr/bin/cygstunnel.dll.dbg add symbol table from file "/usr/lib/debug/usr/bin/cygstunnel.dll.dbg" (y or n) y Reading symbols from /usr/lib/debug/usr/bin/cygstunnel.dll.dbg... (gdb) run Starting program: /bin/stunnel [New Thread 11260.0x17b0] [New Thread 11260.0x23dc] [New Thread 11260.0x48ec] [New Thread 11260.0xed0] [New Thread 11260.0x4f60] [Thread 11260.0x4f60 exited with code 0] 2024.02.17 23:58:11 LOG6[ui]: Initializing inetd mode configuration 2024.02.17 23:58:11 LOG7[ui]: Clients allowed=1562 2024.02.17 23:58:11 LOG5[ui]: stunnel 5.71 on x86_64-pc-cygwin platform 2024.02.17 23:58:11 LOG5[ui]: Compiled with OpenSSL 3.0.11 19 Sep 2023 2024.02.17 23:58:11 LOG5[ui]: Running with OpenSSL 3.0.13 30 Jan 2024 2024.02.17 23:58:11 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI Auth:LIBWRAP 2024.02.17 23:58:11 LOG7[ui]: errno: (*__errno()) 2024.02.17 23:58:11 LOG6[ui]: Initializing inetd mode configuration 2024.02.17 23:58:11 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf.jjk 2024.02.17 23:58:11 LOG5[ui]: UTF-8 byte order mark not detected 2024.02.17 23:58:11 LOG5[ui]: FIPS mode disabled 2024.02.17 23:58:11 LOG6[ui]: Compression disabled 2024.02.17 23:58:11 LOG7[ui]: No PRNG seeding was required 2024.02.17 23:58:11 LOG6[ui]: Initializing service [ssh] 2024.02.17 23:58:11 LOG7[ui]: Initializing context [ssh] 2024.02.17 23:58:11 LOG6[ui]: stunnel default security level set: 2 2024.02.17 23:58:11 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2024.02.17 23:58:11 LOG7[ui]: TLSv1.3 ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 2024.02.17 23:58:11 LOG7[ui]: TLS options: 0x210 (+0x0, -0x0) 2024.02.17 23:58:11 LOG6[ui]: Session resumption enabled 2024.02.17 23:58:11 LOG7[ui]: No certificate or private key specified 2024.02.17 23:58:11 LOG6[ui]: Configured trusted server CA: C=US, ST=MyState, L=MyTown, O=Myuser Consulting, CN=myuser.biz, emailAddress=c...@myuser.biz 2024.02.17 23:58:11 LOG7[ui]: OCSP: Client OCSP stapling enabled 2024.02.17 23:58:11 LOG6[ui]: DH initialization skipped: client section 2024.02.17 23:58:11 LOG7[ui]: ECDH initialization 2024.02.17 23:58:11 LOG7[ui]: ECDH initialized with curves X25519:P-256:X448:P-521:P-384 2024.02.17 23:58:11 LOG5[ui]: Configuration successful 2024.02.17 23:58:11 LOG7[ui]: Deallocating deployed section defaults 2024.02.17 23:58:11 LOG7[ui]: Cleaning up context [stunnel] 2024.02.17 23:58:11 LOG7[ui]: Binding service [ssh] 2024.02.17 23:58:11 LOG7[ui]: Listening file descriptor created (FD=8) 2024.02.17 23:58:11 LOG7[ui]: Setting accept socket options (FD=8) 2024.02.17 23:58:11 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2024.02.17 23:58:11 LOG6[ui]: Service [ssh] (FD=8) bound to ::1: 2024.02.17 23:58:11 LOG7[ui]: Listening file descriptor created (FD=10) 2024.02.17 23:58:11 LOG7[ui]: Setting accept socket options (FD=10) 2024.02.17 23:58:11 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2024.02.17 23:58:11 LOG6[ui]: Service [ssh] (FD=10) bound to 127.0.0.1: 2024.02.17 23:58:11 LOG7[ui]: Created pid file /var/run/stunnel.pid [
Re: ssh over stunnel hangs on second connection
ASSI via Cygwin wrote at about 08:35:10 +0100 on Sunday, February 18, 2024: > cygwin--- via Cygwin writes: > > Running stunnel under gdb, shows that when 'ssh' exits, the thread > > initiated by the 'ssh' login ends with a 'Segmentation Fault' due to a > > SIGSEGV - so it appears that there is an attempt to read/write from an > > invalid memory area > > Based on the location of the crash and the trace leading up to it: could > you install the latest snapshot for the Cygwin DLL and see if that fixes > this crash? > > I just tried with: cygwin 3.6.0-0.45 which was the latest I could find on setup.exe. Unfortunately did not solve the problem :( -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: tzcode, tzdata 2021b
The following packages have been upgraded in the Cygwin distribution: * tzcode2021b * tzdata2021b The Time Zone Database (often called tz, tzdb, or zoneinfo) contains data that represents the history of local time for many locations around the world, and supports conversion of UTC time to local time at those locations to allow display of those local times. It is updated periodically to reflect changes made by political bodies to daylight saving (summer time) rules, UTC offsets, and time zone boundaries. The tzcode package provides the tzselect, zdump, and zic utilities. For more information, see the announcement or below: https://mm.icann.org/pipermail/tz-announce/2021-January/65.html Release 2021b - 2021-09-24 16:23:00 -0700 Briefly: Jordan now starts DST on February's last Thursday. Samoa no longer observes DST. Merge more location-based Zones whose timestamps agree since 1970. Move some backward-compatibility links to 'backward'. Rename Pacific/Enderbury to Pacific/Kanton. Correct many pre-1993 transitions in Malawi, Portugal, etc. zic now creates each output file or link atomically. zic -L no longer omits the POSIX TZ string in its output. zic fixes for truncation and leap second table expiration. zic now follows POSIX for TZ strings using all-year DST. Fix some localtime crashes and bugs in obscure cases. zdump -v now outputs more-useful boundary cases. tzfile.5 better matches a draft successor to RFC 8536. A new file SECURITY. This release is prompted by recent announcements by Jordan and Samoa. It incorporates many other changes that had accumulated since 2021a. However, it omits most proposed changes that merged all Zones agreeing since 1970, as concerns were raised about doing too many of these changes at once. It does keeps some of these changes in the interest of making tzdb more equitable one step at a time; see "Merge more location-based Zones" below. Changes to future timestamps Jordan now starts DST on February's last Thursday. (Thanks to Steffen Thorsen.) Samoa no longer observes DST. (Thanks to Geoffrey D. Bennett.) Changes to zone name Rename Pacific/Enderbury to Pacific/Kanton. When we added Enderbury in 1993, we did not know that it is uninhabited and that Kanton (population two dozen) is the only inhabited location in that timezone. The old name is now a backward-compatility link. Changes to past timestamps Correct many pre-1993 transitions, fixing entries originally derived from Shanks, Whitman, and Mundell. The fixes include: - Barbados: standard time was introduced in 1911, not 1932; and DST was observed in 1942-1944 - Cook Islands: In 1899 they switched from east to west of GMT, celebrating Christmas for two days. They (and Niue) switched to standard time in 1952, not 1901. - Guyana: corrected LMT for Georgetown; the introduction of standard time in 1911, not 1915; and corrections to 1975 and 1992 transitions - Kanton: uninhabited before 1937-08-31 - Niue: only observed -11:20 from 1952 through 1964, then went to -11 instead of -11:30 - Portugal: DST was observed in 1950 - Tonga: corrected LMT; the introduction of standard time in 1945, not 1901; and corrections to the transition from +12:20 to +13 in 1961, not 1941 Additional fixes to entries in the 'backzone' file include: - Enderbury: inhabited only 1860/1885 and 1938-03-06/1942-02-09 - The Gambia: 1933 and 1942 transitions - Malawi: several 1911 through 1925 transitions - Sierra Leone: several 1913 through 1941 transitions, and DST was NOT observed in 1957 through 1962 (Thanks to P Chan, Michael Deckers, Alexander Krivenyshev and Alois Treindl.) Merge more location-based Zones whose timestamps agree since 1970, as pre-1970 timestamps are out of scope. This is part of a process that has been ongoing since 2013. This does not affect post-1970 timestamps, and timezone historians who build with 'make PACKRATDATA=backzone' should see no changes to pre-1970 timestamps. When merging, keep the most-populous location's data, and move data for other locations to 'backzone' with a backward link in 'backward'. For example, move America/Creston data to 'backzone' with a link in 'backward' from America/Phoenix because the two timezones' timestamps agree since 1970; this change affects some pre-1968 timestamps in America/Creston because Creston and Phoenix disagreed before 1968. The affected Zones are Africa/Accra, America/Atikokan, America/Blanc-Sablon, America/Creston, America/Curacao, America/Nassau, America/Port_of_Spain, Antarctica/DumontDUrville, and Antarctica/Syowa. Changes to maintenance procedure The new file SECURITY covers how to report security-re
32-bit cygwin 3.3.0-1 not running on Windows Server 2008
Hi everyone, I installed the new cygwin 3.3.0-1 on Windows Server 2008 (32-bit) and then I receive the following error: The procedure entry point TryAcquireSRWLockExclusive could not be located in the dynamic link library KERNEL32.dll. Can you please investigate? Many thanks! Kind regards, Rene -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Python 3.x status?
The latest Python in Cygwin, 3.9, reaches end of life in less than a year, 2025-10, according to [0]. Some packages (numpy) are dropping support for 3.9 [1]. Can we please get an update on the status of a newer Python for Cygwin? Thanks! [0] - https://devguide.python.org/versions/ [1] - https://github.com/numpy/numpy/issues/26247 On 10/3/2024 11:55 AM, Robert Terzi via Cygwin wrote: Any updates on a newer Python 3.x for Cygwin? On Dec 23rd, 2023, Marco Atzeri mentioned in an announcement email[0]: "Python 3.12 will be in the near future introduced and we will skip 3.10 and 3.11." That plan was also mentioned in the Feb 29th 2024 announcement[1] from Marco Atzeri, where the test release of Python 3.9.18 was removed. (The problem with 3.9.18 might have been related to "pip install occasionally hangs" [2]. It looks like Python 3.9.16-1 is still the most current release. Have I missed something, or can we get a status update? Thanks! 0 - https://cygwin.com/pipermail/cygwin-announce/2023-December/011437.html 1 - https://cygwin.com/pipermail/cygwin-announce/2024-February/011613.html 2 - https://cygwin.com/pipermail/cygwin/2024-February/255430.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
chmod issue on 3.1.7.
Hi all, Running this Cygwin on a Windows 10 system: 0:DESKTOP-K8055OB:~$ uname -a CYGWIN_NT-10.0-WOW DESKTOP-K8055OB 3.1.7(0.340/5/3) 2020-08-22 19:03 i686 Cygwi When a file is created, and permissions set as follows: 0:DESKTOP-K8055OB:~$ touch tempfile 0:DESKTOP-K8055OB:~$ chmod 03777 tempfile 0:DESKTOP-K8055OB:~$ ls -l tempfile -rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile Then "chmod u=" is not able to clear the owner's permissions to nothing: 0:DESKTOP-K8055OB:~$ chmod u= tempfile 0:DESKTOP-K8055OB:~$ ls -l tempfile -rwxrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile As you can see, it has no effect. The expected value is rwsrwt. I tried both with 64 and 32 bit Cygwin: same deal. This is not a problem with the chmod utility. I ran into this as a failing test case against a chmod library function in a programming language. http://www.kylheku.com/cgit/txr/tree/tests/018/chmod.tl The test cases pass until the "u=", which fails in the same way. This does not use the chmod utility. It's an issue with the chmod system call. This used to work on my older Cygwin installation, which was around 2.5. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Problem building cygwin-3_1_7-release tagged newlib.
Hi,
I'm trying to build the 3.1.7 tagged newlib. It runs into this problem:
c++wrap -O2 -g -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall
-Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin
-fmessage-length=0 -MMD -Wimplicit-fallthrough=5 -Werror
-fmerge-constants -ftracer -c -o _cygwin_crt0_common.o
../../.././winsup/cygwin/lib/_cygwin_crt0_common.cc
In file included from ../../.././winsup/cygwin/winsup.h:83,
from
../../.././winsup/cygwin/lib/_cygwin_crt0_common.cc:9:
../../.././winsup/cygwin/winlean.h:104:16: error: redefinition of
'struct _MEM_ADDRESS_REQUIREMENTS'
104 | typedef struct _MEM_ADDRESS_REQUIREMENTS
|^
In file included from /usr/include/w32api/minwindef.h:163,
from /usr/include/w32api/windef.h:9,
from /usr/include/w32api/windows.h:69,
from ../../.././winsup/cygwin/winlean.h:56,
from ../../.././winsup/cygwin/winsup.h:83,
from
../../.././winsup/cygwin/lib/_cygwin_crt0_common.cc:9:
/usr/include/w32api/winnt.h:4896:18: note: previous definition of
'struct _MEM_ADDRESS_REQUIREMENTS'
4896 | typedef struct _MEM_ADDRESS_REQUIREMENTS {
| ^
This looks like a clash between the installed toolchain header and the
one in the winsup tree?
Is this a known problem?
Maybe I shouldn't be using the native Cygwin compiler for rebuilding the
Cygwin DLL; what is the right way?
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Problem building cygwin-3_1_7-release tagged newlib.
On 2020-10-10 12:39, Ken Brown wrote:
On 10/10/2020 3:22 PM, Kaz Kylheku (Cygwin) via Cygwin wrote:
4896 | typedef struct _MEM_ADDRESS_REQUIREMENTS {
| ^
This looks like a clash between the installed toolchain header and the
one in the winsup tree?
Is this a known problem?
Yes. It was caused by a mingw-w64 update and was fixed in commit
c1f7c4d1.
Much thanks for that; it got past this stumbling block. After that there
were
a bunch of GCC-10 fixes I had to find and cherry pick, and it built.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Build spends a long time in "mkimport".
Hi All, When building the Cygwin DLL, this single step takes almost ten minutes: ../../.././winsup/cygwin/mkimport --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy \ --replace=atexit= --replace=timezone= --replace=uname=uname_x --replace=__xdrrec_getrec= [ .. SNIP ... ] --replace=truncate=_truncate64 libcygwin.a cygdll.a _cygwin_crt0_common.o \ atexit.o cygwin_attach_dll.o cygwin_crt0.o dll_entry.o dll_main.o dso_handle.o \ libcmain.o premain0.o premain1.o premain2.o premain3.o pseudo-reloc-dummy.o What's puzzling is that there is very CPU activity during this time. It's launching some objcopy commands. Is there some documentation that provides an overview of what exactly this does, other than studying its perl source code? Maybe it can be sped up? I'm going to have to cycle quite a few times on some changes, so this is frustrating. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: chmod issue on 3.1.7.
On 2020-10-10 14:51, Brian Inglis wrote: D/ACLs on the directory could restore/maintain the permissions: could we please see the output from ls -l, getfacl, and icacls on the directory and file? Thanks for your responses, Ken and Brian. See what you can make of this: 0:DESKTOP-K8055OB:~$ ls -ld . tempfile drwxr-xr-x+ 1 kaz kaz 0 Oct 11 09:07 . -rwxrwsrwt 1 kaz kaz 0 Oct 10 09:08 tempfile 0:DESKTOP-K8055OB:~$ getfacl . # file: . # owner: kaz # group: kaz user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x 0:DESKTOP-K8055OB:~$ getfacl tempfile # file: tempfile # owner: kaz # group: kaz # flags: -st user::rwx group::rwx other::rwx 0:DESKTOP-K8055OB:~$ icacls . . DESKTOP-K8055OB\kaz:(F) DESKTOP-K8055OB\kaz:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files 0:DESKTOP-K8055OB:~$ icacls tempfile tempfile NULL SID:(DENY)(Rc,S,RD,WD) DESKTOP-K8055OB\kaz:(F) DESKTOP-K8055OB\kaz:(RX,W) Everyone:(RX,W) Successfully processed 1 files; Failed processing 0 files -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
ANN: Cygnal 3.1.6.98 beta.
Hi All, I've rebased the Cygnal patches against Cygwin 3.1.7 and released a new beta. http://www.kylheku.com/cygnal/#3-6-1-98 The last time I rebased was 2.9.0; it's been a while. The Cygnal project provides a modified version of the main Cygwin DLL which allows programmers who work with Cygwin to ship their programs as Windows applications. You simply compile your executable under Cygwin with the regular Cygwin native toolchain, and then bundle it with the cygwin1.dll provided by the Cygnal project. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
On 2020-10-06 14:36, Jérôme Froissart wrote:
Here is an example C file
$ cat example.c
#include
const char *GetCommandLineA(void);
int main(int argc, char *argv[])
{
const char *s = GetCommandLineA();
printf("C=%s\n", s);
for (int i = 0; argc > i; i++)
printf("%d=%s\n", i, argv[i]);
return 0;
}
Your program's comparison seems to be based on the
hypothesis that Cygwin parses the GetCommandLineA() command line.
But this hypothesis is almost certainly wrong.
Now, let's start a Windows shell (cmd.exe)
Note that I had to copy cygwin1.dll from my Cygwin installation
directory, otherwise binary.exe would not start.
I do not know whether there is a `locale` equivalent in Windows
command prompt, so I merely ran my program.
C:\Users\Public>binary.exe "foo bar" "Jérôme"
C=binary.exe "foo bar" "J□r□me"
0=binary
1=foo bar
2="Jérôme"
The "A" command line from GetCommandLineA has "tofu"
characters: é and ô were not decoded properly.
The é and ô characters we see in the Cygwin-parsed
arguments coming into main could not have been recovered
from these "tofu" replacement characters.
What is actually being parsed must be the WCHAR command line
corresponding to what comes from GetCommandLineW().
It's necessary to show that one to get a more complete understanding.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
On 2020-10-14 14:47, Jérôme Froissart wrote: The choice of GetCommandLineA was for illustration purposes; had I used GetCommandLineW I would not be able to printf using %ls under CMD.EXE, because of code page issues. However here is a modified version of the test program that uses GetCommandLineW. [ ... ] billziss@xps:~/Projects/t$ ./cyg.exe "foo bar" "Domain\Jérôme" 0022 " 0043 C 003a : 005c \ 0055 U 0073 s 0065 e 0072 r 0073 s 005c \ 0062 b 0069 i 006c l 006c l 007a z 0069 i 0073 s 0073 s 005c \ 0050 P 0072 r 006f o 006a j 0065 e 0063 c 0074 t 0073 s 005c \ 0074 t 005c \ 0063 c 0079 y 0067 g 002e . 0065 e 0078 x 0065 e 0022 " [ ... ] C:\Users\billziss\Projects\t>cyg.exe "foo bar" "Domain\Jérôme" 0063 c 0079 y 0067 g 002e . 0065 e 0078 x 0065 e 0020 0020 0022 " 0066 f 006f o 006f o 0020 0062 b 0061 a 0072 r 0022 " 0020 0022 " 0044 D 006f o 006d m 0061 a 0069 i 006e n 005c \ 004a J 00e9 . 0072 r 00f4 . 006d m 0065 e 0022 " Aha! There is a hint of a problem here. Firstly, the command lines are obviously different. The Cygwin one starts with a quote that we did not see, wrapping the full path to the executable: "C:\Users\billziss\Projects\t\cyg.exe" It ends there. Why is that? I'm guessing that the command line was tokenized destructively; a null character was written. But under cmd.exe, we see the whole command line, without any null character having been written in it. Moreover, the program name just appears as the original relative path cyg.exe with no quotes. What a mess. :) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: chmod issue on 3.1.7.
On 2020-10-10 09:32, Kaz Kylheku (Cygwin) via Cygwin wrote: Hi all, Running this Cygwin on a Windows 10 system: 0:DESKTOP-K8055OB:~$ uname -a CYGWIN_NT-10.0-WOW DESKTOP-K8055OB 3.1.7(0.340/5/3) 2020-08-22 19:03 i686 Cygwi When a file is created, and permissions set as follows: 0:DESKTOP-K8055OB:~$ touch tempfile 0:DESKTOP-K8055OB:~$ chmod 03777 tempfile 0:DESKTOP-K8055OB:~$ ls -l tempfile -rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile Then "chmod u=" is not able to clear the owner's permissions to nothing: 0:DESKTOP-K8055OB:~$ chmod u= tempfile 0:DESKTOP-K8055OB:~$ ls -l tempfile -rwxrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile As you can see, it has no effect. The expected value is rwsrwt. I tried both with 64 and 32 bit Cygwin: same deal. This is not a problem with the chmod utility. I ran into this as a failing test case against a chmod library function in a programming language. http://www.kylheku.com/cgit/txr/tree/tests/018/chmod.tl The test cases pass until the "u=", which fails in the same way. This does not use the chmod utility. It's an issue with the chmod system call. This used to work on my older Cygwin installation, which was around 2.5. Anyone have a clue about this issue? $ icacls tempfile tempfile NULL SID:(DENY)(Rc,S,RD,WD) BLACKBOX\kaz:(F) BLACKBOX\kaz:(RX,W) Everyone:(RX,W) $ getfacl tempfile # file: tempfile # owner: kaz # group: kaz # flags: -st user::rwx group::rwx other::rwx $ ls -l tempfile -rwxrwsrwt 1 kaz kaz 0 Dec 24 13:09 tempfile $ chmod u= tempfile $ ls -l tempfile -rwxrwsrwt 1 kaz kaz 0 Dec 24 13:09 tempfile -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: chmod issue on 3.1.7.
On 2020-12-24 14:56, Ken Brown via Cygwin wrote: Could the problem be that the owner and group are the same? You can do that on unix, but I'm not sure the Windows security model allows it. For example, what happens when you remove permissions of the owner kaz while retaining the permissions of the group kaz? As far as Windows is concerned, you're talking about BLACKBOX\kaz in both cases, I think. I have no idea where that came from. All files in the Cygwin installation (/bin, /usr/bin, /lib, ...) are owned by kaz:kaz. Numerically, 197613:197613. The UID and GID are the same number. I don't see a passwd file any more in current Cygwin, but getpwent works: 4$ txr This is the TXR Lisp interactive listener of TXR 243. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. 1> (getpwent) #S(passwd name "kaz" passwd "*" uid 197613 gid 197613 gecos "U-BLACKBOX\\kaz,S-1-5-21-3442361740-4082249206-548862920-1005" dir "/home/kaz" shell "/bin/bash") 2> (getpwent) #S(passwd name "SYSTEM" passwd "*" uid 18 gid 18 gecos "U-NT AUTHORITY\\SYSTEM,S-1-5-18" dir "/home/SYSTEM" shell "/bin/bash") I have no clue where this configuration came from. Is there some prompting for these names when a new installation is made? If nobody else has this problem, I must have done something wrong. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Warning cygwin
On 2021-02-22 11:19, cygwinautoreply--- via Cygwin wrote: https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings It would be ideal if this auto-reply didn't include the Cygwin mailing list; there is no need for the mailing list to read this. Scratch that; it would be ideal if neither the original question nor the auto-reply were re-mailed. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Warning cygwin
On 2021-02-22 15:53, Brian Inglis wrote: On 2021-02-22 16:41, Kaz Kylheku wrote: On 2021-02-22 11:19, cygwinautoreply wrote: https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings It would be ideal if this auto-reply didn't include the Cygwin mailing list; there is no need for the mailing list to read this. Scratch that; it would be ideal if neither the original question nor the auto-reply were re-mailed. What if Cygwin is up to date and you see that message? Right. In that case, the message from newer Cygwin will not be accompanied by a recommendation to post to the mailing list. Instead it points to some online resources about the problem. Those resources could loudly warn the user that mailing list messages containing references to the FAST_CWD will receive a robot reply and not get posted (for he reason that old releases of Cygwin encouraged users to post reports of it, which keeps happening). -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: A problem with noacl+umask+chmod result
On 2021-04-08 21:34, Orgad Shaneh via Cygwin wrote: On Fri, Apr 9, 2021 at 4:50 AM Andrey Repin wrote: Greetings, Orgad Shaneh! > On Wed, Apr 7, 2021 at 11:47 PM Orgad Shaneh wrote: > Marco Atzeri replied to the mailing list but did not CC me, so I > didn't receive it: The expectation is that you subscribe to the list of interest. Why? If I report a bug, I'm interested in this bug, and I don't want to receive dozens of emails every day about other issues. Hi Orgad, The odd thing is that you're able to post at all. The Cygwin has an inconsistent configuration: it seems to allow posts from non-subscribers, yet it removes them from the Cc: line when remailing their posting. Basically, there are two styles of mailing list: "old school" and "modern". Old school means: no Reply-To munging or anything of the sort is performed. The mailing list is just a robot which redistributes an e-mail which it receives to subscribers. The Cc: line is kept intact. The e-mail can come from a non-subscriber. (One type of) modern: only messages from subscribers are allowed. Messages are reposted preserving the original From. The Cc: line includes nothing but the mailing list address, in order that when the recipients perform "reply all", the message goes to the list as well as to the original author. If a "modern" mailing list style allows non-member postings, that creates confusion. The post receives replies seen by everyone on the list, but not that non-member. The reason for the modern configuration is spam. Allowing only subscribers to post drastically reduces the spam, even if no other anti-spam measures are implemented. All the mailing lists which I operate, such as the txr-users list for TXR users, are old school, though. The usability of modern mailing lists is too impaired. I believe that the modernization of mailing lists is what has contributed to the diminishing popularity of mailing lists. Having to subscribe to interact with the list is a hurdle in the usability of a forum that is already in an unpopular format. Spam can be combated in other ways, like having excellent forms of other filtering, and using list-specific tools. For instance, GNU Mailman (a very popular mailing list manager) has the feature that posts from non-subscribers can be held for moderation. Every time you report a bug to a project on github/jira/whatever, you subscribe to everything in this project? Without creating a github account, how do you do anything of that sort on github? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
