Vlad from Infatica to cygwin's team | App Monetization
Hi cygwin's team! Upon reviewing your app, it became apparent that you may benefit from additional source of motetization for your application. We at Infatica are currently expanding our network of 50+ partners who are already working with our proven solution to monetize traffic. Could it be relevant to you? Best regards, Vlad Khrinenko Proxy and data expert at Infatica.io -- 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
Please update keychain to 2.8.5 (Updated .cygport file attached)
Hi all, Cygwin's keychain package is very old and doesn't work at all with the latest openssh. I've updated keychain.cygport for the latest version of keychain. Please find the attached file. Could you include this in the cygwin package repository and release a new version? Regards, Ken Takata keychain.cygport Description: Binary data -- 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
ftp.acc.umu.se domain move
Hi! The contact information, and preferably the host/mirror name, for the mirror provided by Academic Computer Club (ACC) needs to be changed as ACC is moving to a new domain. To verify the validity of this message, point a web browser towards https://ftp.acc.umu.se/ and notice that the top-level redirects to https://mirror.accum.se/. Also notice the text about acc.umu.se at the top of the page. Background: Umeå University has decided that non-official services are no longer allowed to exist as a sub domain to umu.se. As a consequence of this we are moving all services from the acc.umu.se domain. Contact email: Changes from ftp-...@acc.umu.se to ftp-...@accum.se. The old email address will stop working sometime in the future. File archive host name: Official name changes from ftp.acc.umu.se to mirror.accum.se. The old host name will continue to work for quite some time (years), but new deployments should move to using a non-acc.umu.se name. Since we are lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain and lots of aliases so ftp.ac2.se also works. If you have references to other acc.umu.se services (for example www.acc.umu.se), replace the domain part with accum.se (ie www.accum.se). Remove mention of Umeå University: Where appropriate, refer to us as: Academic Computer Club in Umeå, Sweden ie removing any mention of Umeå University. Available bandwidth: While not related to the domain move, we'd like to inform you that the file archive now enjoys 200 Gbps connectivity to SUNET. Our servers can't handle this quite yet, but we're looking at scaling up by refreshing server hardware etc. On behalf of the ACC file archive admins, /Nikke -- 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
Your order update WMBLYA9158572082
cygwin, The Orders via 9158572082 must be filled out in their entirety. InvoiceEKJW9158572082.pdf Description: Binary data -- 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
Potential Bug: Created files list owner/user exec until Windows reorders permissions
TL;DR: Weird permissions behavior in a Cygwin installation where permissions have been changed over time. I can't reproduce it on a clean install so that's how I'm working around it, but I thought it might be worth capturing what details I have in case it helps others or helps identify a bug. After creating a file for the first time under a Cygwin bash shell, Cygwin lists it as executable by the owner/user: $ ls -ld /foo-0.txt ls: cannot access '/foo-0.txt': No such file or directory $ touch /foo-0.txt && ls -ld /foo-0.txt -rwxrw-r--+ 1 xen xen 0 May 21 18:18 /foo-0.txt Changing it's mode in Cygwin reports success but Cygwin still lists it as executable: $ chmod -c u-x /foo-0.txt && ls -ld /foo-0.txt mode of '/foo-0.txt' changed from 0764 (rwxrw-r--) to 0664 (rw-rw-r--) -rwxrw-r--+ 1 xen xen 0 May 21 18:18 /foo-0.txt Note that the resulting Windows DACLS do indeed seem confused about whether the owner should be granted or denied execution: $ icacls "$(cygpath -w ./foo-0.txt)" foo-0.txt NULL SID:(DENY)(Rc,WEA,X,DC) MEDIA\xen:(R,W,D,WDAC,WO) MEDIA\xen:(DENY)(X) NT AUTHORITY\Authenticated Users:(DENY)(X) NT AUTHORITY\SYSTEM:(DENY)(X) BUILTIN\Administrators:(DENY)(X) BUILTIN\Users:(DENY)(X) MEDIA\me:(DENY)(X) MEDIA\xen:(RX) NT AUTHORITY\Authenticated Users:(RX,W) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) BUILTIN\Users:(RX) MEDIA\me:(RX,W) Everyone:(R) Successfully processed 1 files; Failed processing 0 files After opening the file's properties in the Windows GUI, I let Windows reorder the DACLs to canonical order by clicking the `Advanced` button on the `Security` tab, clicking the `Reorder` button in the resulting modal, and then clicking the `Apply` button. After that, Cygwin lists the permissions as expected: $ ls -ld /foo-0.txt -rw-rw-r--+ 1 xen xen 0 May 21 18:18 /foo-0.txt I don't have much experience with the Windows security model, nor any depth of technical understanding of either Windows or Cygwin, but this sure seems to contradict [the in-depth "File permissions" description concerning how Cygwin orders the DACLs](https://cygwin.com/cygwin-ug-net/ntsec.html) to reconcile the POSIX and Windows security models as best as possible. I've also done a bunch of other reading from Google searches, mostly the Cygwin mailing list and Stack Exchanges, and much of that is regarding the executable permission but I didn't find anything regarding this specific behavior. Of course, I didn't read everything that might match this, there are just too many hits. Finally, I fired up [the Windows 11 developer VirtualBox appliance VM image](https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/), and installed Cygwin. I chose the chocolatey package because its Cygwin version is more current than wget's. I could *not* reproduce this behavior in that clean Cygwin installation, so I opted to workaround the issue by re-installing. The Windows permissions in the Cygwin installation that exhibits the above behavior have been changed over time, though I don't recall the specifics. In particular, when compared to the clean install, I noted that the Cygwin root folder had been set to inherit it permissions from `C:\` and that those inherited DACLs differed from the clean install.. FWIW, when I disabled inheritance and copied the inherited permissions to the Cygwin root, I could still reproduce this behavior: $ icacls "$(cygpath -w ./)" .\ NT AUTHORITY\Authenticated Users:(OI)(CI)(M) NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Administrators:(OI)(CI)(F) MEDIA\me:(OI)(CI)(F) BUILTIN\Users:(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files Hope this helps someone somehow ;-) Ross -- 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
sethostname does not reject a too long hostname
The sethostname() system call is not standardized by POSIX, only by the LSB:
https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/baselib-sethostname-2.html
In particular, it should fail with EINVAL if
"len is negative or larger than the maximum allowed size".
In Cygwin 3.5.3, a too long hostname is not rejected.
Witness: The test program below, when run on the Cygwin 3.5.3 machines
on GitHub (under a user account that is in the Administrators group),
fails with the message "setting a too long hostname succeeded."
The implementation is in winsup/cygwin/net.cc line 773.
Bruno
== Test program essentially =
#include
#include
/* for HOST_NAME_MAX */
#include
/* for strlen */
#include
#include
#include
#define TESTHOSTNAME "gnulib-hostname"
/* mingw and MSVC 9 lack geteuid, so setup a dummy value.
On Cygwin, geteuid() may return non-zero even for user accounts with
administrator privileges, so use a dummy value as well. */
#if defined __CYGWIN__
# define geteuid() 0
#endif
int
main (int argc, char *argv[])
{
char origname[HOST_NAME_MAX];
char newname[HOST_NAME_MAX];
char longname[HOST_NAME_MAX + 2];
int rcs, i;
/* skip the tests if we don't have root privilege. this does not
consider things like CAP_SYS_ADMIN (linux) or PRIV_SYS_ADMIN
(solaris), etc. systems without a working geteuid (mingw, MSVC
9) will always skip this test. */
if (geteuid () != 0)
{
fprintf (stderr, "Skipping test: insufficient permissions.\n");
return 77;
}
/* we want to ensure we can do a get/set/get check to ensure the
change is accepted. record the current name so it can be restored
later */
assert (gethostname (origname, sizeof (origname)) == 0);
/* try setting a valid hostname. if it fails -1/ENOSYS, we will
skip the test for long names as this is an indication we're using
the stub function that doesn't do anything on this platform. */
rcs = sethostname (TESTHOSTNAME, strlen (TESTHOSTNAME));
if (rcs != 0)
{
if (rcs == -1 && errno == ENOSYS)
{
fprintf (stderr,
"Skipping test: sethostname is not really implemented.\n");
return 77;
}
else if (rcs == -1
&& (errno == EPERM
|| errno == EACCES)) /* Cygwin */
{
fprintf (stderr, "Skipping test: insufficient permissions.\n");
return 77;
}
else
{
fprintf (stderr, "error setting valid hostname.\n");
return 1;
}
}
else
{
assert (gethostname (newname, sizeof (newname)) == 0);
/* On Windows, a hostname change becomes effective only after
a reboot. */
#if !(defined _WIN32 || defined __CYGWIN__)
/* if we don't get back what we put in, there is no need to
restore the original name as we will assume it was not
properly changed. */
if (strcmp (newname, TESTHOSTNAME) != 0)
{
fprintf (stderr, "set/get comparison failed.\n");
return 1;
}
#endif
}
/* glibc does allow setting a zero length name, so the lower bound
needs no test. validate that we are constrained by
HOST_NAME_MAX */
for (i = 0; i < (HOST_NAME_MAX + 1); i++)
longname[i] = 'a';
longname[i] = '\0';
rcs = sethostname (longname, (HOST_NAME_MAX + 1));
if (rcs != -1)
{
/* attempt to restore the original name. */
assert (sethostname (origname, strlen (origname)) == 0);
fprintf (stderr, "setting a too long hostname succeeded.\n");
return 1;
}
/* restore the original name. */
assert (sethostname (origname, strlen (origname)) == 0);
return 0;
}
--
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
multithreading broken in Cygwin 3.5.3
Hi,
In Cygwin 3.5.3, on different machines, I see 3 Gnulib tests failing by
timeout that worked perfectly fine in Cygwin 3.4.6 and older:
FAIL: test-call_once2.exe
FAIL: test-lock.exe
FAIL: test-pthread-once2.exe
Find here attached a simplified version of test-pthread-once2.c.
Compile and run:
$ x86_64-pc-cygwin-gcc -Wall foo.c
$ ./a
Expected behaviour: Termination within 1 minute.
Actual behaviour: Terminates by timeout after 10 minutes.
When I change
#define ENABLE_DEBUGGING 0
to
#define ENABLE_DEBUGGING 1
the test does lots of output and terminates within 20 seconds.
Therefore I can't really tell where the problem comes from.
But I do see some changes in
$ git diff cygwin-3.4.6 cygwin-3.5.3 winsup/cygwin/thread.cc
$ git diff cygwin-3.4.6 cygwin-3.5.3 winsup/testsuite/winsup.api/pthread
Bruno
/* Whether to enable locking.
Uncomment this to get a test program without locking, to verify that
it crashes. */
#define ENABLE_LOCKING 1
/* Whether to help the scheduler through explicit sched_yield().
Uncomment this to see if the operating system has a fair scheduler. */
#define EXPLICIT_YIELD 1
/* Whether to print debugging messages. */
#define ENABLE_DEBUGGING 0
/* Number of simultaneous threads. */
#define THREAD_COUNT 10
/* Number of operations performed in each thread.
This is quite high, because with a smaller count, say 5000, we often get
an "OK" result even without ENABLE_LOCKING (on Linux/x86). */
#define REPEAT_COUNT 5
#include
#include
#include
#include
#include
#include
#include
#include
#if EXPLICIT_YIELD
# include
#endif
#if ENABLE_DEBUGGING
# define dbgprintf printf
#else
# define dbgprintf if (0) printf
#endif
#if EXPLICIT_YIELD
# define yield() sched_yield ()
#else
# define yield()
#endif
/* Returns a reference to the current thread as a pointer, for debugging. */
#define pthread_self_pointer() ((void *) (uintptr_t) pthread_self ())
/* Test once-only execution */
/* Test once-only execution by having several threads attempt to grab a
once-only task simultaneously (triggered by releasing a read-write lock). */
static pthread_once_t fresh_once = PTHREAD_ONCE_INIT;
static int ready[THREAD_COUNT];
static pthread_mutex_t ready_lock[THREAD_COUNT];
#if ENABLE_LOCKING
static pthread_rwlock_t fire_signal[REPEAT_COUNT];
#else
static volatile int fire_signal_state;
#endif
static pthread_once_t once_control;
static int performed;
static pthread_mutex_t performed_lock;
static void
once_execute (void)
{
assert (pthread_mutex_lock (&performed_lock) == 0);
performed++;
assert (pthread_mutex_unlock (&performed_lock) == 0);
}
static void *
once_contender_thread (void *arg)
{
int id = (int) (intptr_t) arg;
int repeat;
for (repeat = 0; repeat <= REPEAT_COUNT; repeat++)
{
/* Tell the main thread that we're ready. */
assert (pthread_mutex_lock (&ready_lock[id]) == 0);
ready[id] = 1;
assert (pthread_mutex_unlock (&ready_lock[id]) == 0);
if (repeat == REPEAT_COUNT)
break;
dbgprintf ("Contender %p waiting for signal for round %d\n",
pthread_self_pointer (), repeat);
#if ENABLE_LOCKING
/* Wait for the signal to go. */
assert (pthread_rwlock_rdlock (&fire_signal[repeat]) == 0);
/* And don't hinder the others (if the scheduler is unfair). */
assert (pthread_rwlock_unlock (&fire_signal[repeat]) == 0);
#else
/* Wait for the signal to go. */
while (fire_signal_state <= repeat)
yield ();
#endif
dbgprintf ("Contender %p got the signal for round %d\n",
pthread_self_pointer (), repeat);
/* Contend for execution. */
assert (pthread_once (&once_control, once_execute) == 0);
}
return NULL;
}
static void
test_once (void)
{
int i, repeat;
pthread_t threads[THREAD_COUNT];
/* Initialize all variables. */
for (i = 0; i < THREAD_COUNT; i++)
{
pthread_mutexattr_t attr;
ready[i] = 0;
assert (pthread_mutexattr_init (&attr) == 0);
assert (pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_NORMAL) == 0);
assert (pthread_mutex_init (&ready_lock[i], &attr) == 0);
assert (pthread_mutexattr_destroy (&attr) == 0);
}
#if ENABLE_LOCKING
for (i = 0; i < REPEAT_COUNT; i++)
assert (pthread_rwlock_init (&fire_signal[i], NULL) == 0);
#else
fire_signal_state = 0;
#endif
#if ENABLE_LOCKING
/* Block all fire_signals. */
for (i = REPEAT_COUNT-1; i >= 0; i--)
assert (pthread_rwlock_wrlock (&fire_signal[i]) == 0);
#endif
/* Spawn the threads. */
for (i = 0; i < THREAD_COUNT; i++)
assert (pthread_create (&threads[i], NULL,
once_contender_thread, (void *) (intptr_t) i)
== 0);
for (repeat = 0; repeat <= REPEAT_COUNT; repeat++)
{
/* Wait until every thread is ready. */
dbgprintf ("Main thread before synchronizing for round %d\n"
Re: Team Cymru mirror link update
On 22/05/2024 16:38, Tom Ludwig via Cygwin wrote: Greetings! My name is Tom and I'm a Systems administrator at Team Cymru. Please update our mirror link from http to https://mirror.team-cymru.com/cygwin/ I have updated this in our mirror list. Thanks for providing a cygwin mirror! -- 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
an mbrtoc32 bug
In Cygwin 3.5.3, the attached program has an assertion failure in line 24:
bytes is not (size_t)-2.
How to reproduce:
$ gcc -Wall foo.c
$ ./a
I think this is a bug, because
- ISO C 23 § 7.30.1.5 talks about "completing" a character, not
"representing" an (entire) character.
- The test passes on glibc, musl libc, FreeBSD 14.0, Solaris 11.4.
Bruno
#include
#include
#include
#include
#include
#include
#include
int main ()
{
assert (setlocale (LC_ALL, "en_US.UTF-8") != NULL);
mbstate_t state;
memset (&state, 0, sizeof (state));
char32_t uc = 0xDEADBEEF;
size_t bytes;
/* \360\237\220\203 = U+0001F403 */
bytes = mbrtoc32 (&uc, "\360", 1, &state);
assert (bytes == (size_t)-2);
bytes = mbrtoc32 (&uc, "\237", 1, &state);
assert (bytes == (size_t)-2);
bytes = mbrtoc32 (&uc, "\220", 1, &state);
assert (bytes == (size_t)-2);
bytes = mbrtoc32 (&uc, "\203", 1, &state);
assert (bytes == 1);
assert (uc == 0x0001F403);
}
/* Works in: glibc, musl libc, FreeBSD 14.0, Solaris 11.4
Fails in: Cygwin 3.5.3
*/
--
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: an mbrtoc32 bug
The test case that I sent uses UTF-8 encoding.
Here's another test case, that uses GB18030 (supposedly supported
since Cygwin 3.5.0). It fails as well, in line 26.
On glibc systems, this test works.
#include
#include
#include
#include
#include
#include
#include
int main ()
{
assert (setlocale (LC_ALL, "zh_CN.GB18030") != NULL);
mbstate_t state;
memset (&state, 0, sizeof (state));
char32_t uc = 0xDEADBEEF;
size_t bytes;
/* \224\071\311\067 = U+0001F403 */
bytes = mbrtoc32 (&uc, "\224", 1, &state);
assert (bytes == (size_t)-2);
bytes = mbrtoc32 (&uc, "\071", 1, &state);
assert (bytes == (size_t)-2);
bytes = mbrtoc32 (&uc, "\311", 1, &state);
assert (bytes == (size_t)-2);
bytes = mbrtoc32 (&uc, "\067", 1, &state);
assert (bytes == 1);
assert (uc == 0x0001F403);
}
/* Works in: glibc
Fails in: Cygwin 3.5.3
*/
--
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
