Re: [EXTERNAL] Re: Strange behavior when executing programs
On Dec 12 15:29, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > The problem is that resolved paths may become longer than MAX_PATH. > > Oh... But that'd be the same on any other OS that exceeds MAX_PATH, > symlinking is going to help work around that, > if the full path resolution was requested. > > BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former, can't it > be enlarged? Cygwin handles up to 32K paths for a long time, just like the Windows kernel. It's the native tools and the Win32 ANSI file-API still using MAX_PATH as a path length restriction. Corinna -- 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: [EXTERNAL] Re: Strange behavior when executing programs
On Dec 12 15:22, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > Sorry about the earlier typos > > > (and, hence, I suppose for the purposes of the OP). > > and, hence, I suppose, *would work* for the purposes of the OP. > > > Since realpath is supposed to resolve all symlinks, > > I meant by default (the -P behavior). If -s was asked, then the output would > be corect. Options are only available in realpath(1). As for under the hood, realpath(3) has no options so it can only return one of the alternatives. Corinna -- 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: [EXTERNAL] Re: Strange behavior when executing programs
On Dec 12 14:52, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > Let's consider this problem again, but I don't see a quick and easy > > solution. > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll<== IMO the problem is actually here > > $ realpath msadox.dll > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > Both paths should start with /cygdrive/c, and then those would be identical > (and, hence, I suppose for the purposes of the OP). > > A substed drive is nothing BUT a symlink, should be treated no differently > than > /cygdrive/s -> /cygdrive/c/Program Files/Common Files/System I agree, and that was how I tried implementing it back when. The problem is that resolved paths may become longer than MAX_PATH. So people want to keep the paths with intact substituted drive prefix to run native commands from Cygwin. Corinna -- 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: Strange behavior when executing programs
On Dec 12 13:46, Frank Redeker via Cygwin wrote:
> Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen:
> > On Dec 12 11:21, Frank Redeker via Cygwin wrote:
> > > $ pwd
> > > /cygdrive/s/ado
> > >
> > > $ realpath /cygdrive/s/ado/msadox.dll
> > > /cygdrive/s/ado/msadox.dll
> > >
> > > $ realpath msadox.dll
> > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll
> > >
> > >
> > > Is there any way to restore the old behavior. Since with the new behavior
> > > my
> > > tests no longer work.
> >
> > It's not easy. If we remove the new behaviour entirely, we break
> > other scenarios which were broken in the old version. While it
> > *seems* easy to fix your specific scenario, it will break again
> > as soon as the substitution drive is used inside a native symlink.
> >
> > Virtual drive letters were always a problem and it doesn't get easier
> > with Windows functions not allowing to specify whether one wants to
> > follow symlinks or virt drives in inner path components or not.
> >
> > Let's consider this problem again, but I don't see a quick and easy
> > solution.
> >
> >
> > Corinna
> Hello Corinna, I am willing to create my own version, tailored to my needs.
Before you do that and decouple yourself from development, I'd suggest
to look for a workaround in your code, or to see if we can't patch this
behaviour in the upstream code.
> It would be nice if you could provide me with the commit that was used to
> implement the new behavior. (I guess the change is found inside the
> *git://sourceware.org/git/newlib-cygwin.git* repository)
Yes, but it's a group of patches trying to fix native symlink behaviour,
spread over a couple of iterations. If you're looking for an easy
workaround for your case, try this:
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index e7619270a269..131c7e88278f 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -3492,8 +3492,10 @@ restart:
{
/* Check if the final path is an UNC path and the incoming
path isn't. If so... */
- if (RtlEqualUnicodePathPrefix (, _u_uncp, TRUE)
- && !RtlEqualUnicodePathPrefix (, _u_uncp, TRUE))
+ if (!RtlEqualUnicodePathPrefix (, _u_uncp, TRUE)
+ && (RtlEqualUnicodePathPrefix (, _u_uncp, TRUE)
+ || towupper (upath.Buffer[4])
+!= towupper (fpath.Buffer[4])))
{
/* ...get the remote path, replace remote path
with drive letter, check again. */
However, a generic solution would be preferrable, and a local patch
to your scripts would be the better workaround for now.
Corinna
--
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: Strange behavior when executing programs
On Dec 12 11:21, Frank Redeker via Cygwin wrote: > $ pwd > /cygdrive/s/ado > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll > > $ realpath msadox.dll > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > Is there any way to restore the old behavior. Since with the new behavior my > tests no longer work. It's not easy. If we remove the new behaviour entirely, we break other scenarios which were broken in the old version. While it *seems* easy to fix your specific scenario, it will break again as soon as the substitution drive is used inside a native symlink. Virtual drive letters were always a problem and it doesn't get easier with Windows functions not allowing to specify whether one wants to follow symlinks or virt drives in inner path components or not. Let's consider this problem again, but I don't see a quick and easy solution. Corinna -- 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: Regarding EFBIG error while opening a file using catopen() function
It's somewhat rude to send such a request to everybody and the kitchen
sink.
This belong on the cygwin ML, so please keep it here.
On Dec 12 10:40, Kavita Gore via Cygwin wrote:
> Hi all,
>
> I'm getting errno 27[EFBIG] file too large while opening catalogue with
> catopen() function in the cygwin-32bit version.
>
> [...]
> #define FILENAMETEMP.CAT
>
>buffer = catopen(FILENAME, 0);
> if (buffer != (nl_catd) - 1)
> {
> printf("File open successfully");
> }
> else
> {
> printf("errno: %d\n", errno);
> }
>
> While debugging using gdb.I've found that st.st_size is 0 and As per my
> understanding struct stat.st_size is declared as off_t, which is most
> probably signed, and resolves to long (signed by default).
Since you're running gdb anyway, why don't you *ask* gdb what type
off_t is?
(gdb) ptype off_t
type = long long
> So if SIZE_T_MAX does not fit into 2^31-1 (it most probably does not) it
> will appear as negative in the comparison.
No, under implicit type conversion rules, the comparison is well
defined. size_t is 32 bit on 32 bit systems, off_t is 64 bit. So the
comparison will convert __SIZE_MAX__ losslessly to long long. On 64 bit
systems, size_t is 64 bit, off_t is 64 bit. The comparison will be
performed unsigned, thus it will never be true.
$ cat > x.c <
#include
int
main (int argc, char **argv)
{
off_t o = strtoll (argv[1], NULL, 0);
if (o > __SIZE_MAX__)
puts ("too big");
}
EOF
$ gcc -g -o x x.c
On 32 bit:
$ ./x 0
$ ./x 1
$ ./x 0x
$ ./x 0x1
too big
On 64 bit:
$ ./x 0
$ ./x 1
$ ./x 0x
$ ./x 0x1
$ ./x 0x
$ ./x 0x7fff
$
> I'd like to know the reason why I'm getting this error and How it can be
> resolved as it is a blocker in my task.
You may have to debug this a bit further.
Corinna
--
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] cygwin 3.4.2-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.2-1 * cygwin-devel-3.4.2-1 * cygwin-doc-3.4.2-1 This is a bugfix release. - Fix regression in uname(2), accidentally adding a leading dot to utsname::machine. == IMPORTANT DEPRECATION NOTES == - Cygwin 3.4 is the FIRST major version dropping support for - 32 bit Windows including WOW64 on 64 bit Windows. - Windows Vista - Windows Server 2008 - Cygwin 3.4 is the LAST major version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 - Cygwin 3.5, which will probably be release at some point in late 2023, will run on - Windows 8.1 - Windows 10 - Windows 11 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 - Windows Server 2022 -- 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] cygwin 3.4.1-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.1-1 * cygwin-devel-3.4.1-1 * cygwin-doc-3.4.1-1 This is a bugfix release. - Fix a backward incompatibility problem in the definition of the base type of the stdio type FILE. This requires that C++ binaries compiled under Cygwin 3.4.0 having a public facing interface using FILE need to be recompiled. Addresses: https://savannah.gnu.org/bugs/index.php?63480 - Fix an error introduced into the build process, resulting in `gcc -pg' becoming disfunctional. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252619.html - Fix performance degradation of non-cygwin pipe. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252628.html == IMPORTANT DEPRECATION NOTES == - Cygwin 3.4 is the FIRST major version dropping support for - 32 bit Windows including WOW64 on 64 bit Windows. - Windows Vista - Windows Server 2008 - Cygwin 3.4 is the LAST major version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 - Cygwin 3.5, which will probably be release at some point in late 2023, will run on - Windows 8.1 - Windows 10 - Windows 11 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 - Windows Server 2022 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. -- 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: [EXTERNAL] Re: gcc -pg broken after cygwin update?
On Dec 8 16:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > Sorry for pressing this, I must be slow today. > > > just won't run correctly anymore on W7/8 > > Won't or may not? Won't Corinna -- 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: [EXTERNAL] Re: gcc -pg broken after cygwin update?
On Dec 8 14:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > for 3.5 (late 2023) we announced the deprecation of Windows 7 and 8 > > since the first 3.3.0 release in October 2021. > > I saw that. It did not look alarming. It basically was like "you'll be on > your own". > > > Supporting older OSes requires to keep workarounds in the code and > > Understood. But you did not answer my question: > > > Are you saying that W7 and W8 would be actively rejected? > > and I meant by Cygwin? Not "rejected" as such. It just won't run correctly anymore on W7/8, because - the special treatment required for those OSes isn't in the DLL anymore, and - the DLL uses functions not available on these OSes. Corinna -- 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: [EXTERNAL] Re: gcc -pg broken after cygwin update?
On Dec 7 17:59, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > contains patches dropping W7 and W8 support: > > Hmm... I understood that "dropping support" was not something that > would _require_ newer OS, but that it may not work (or not guaranteed > to work, patches not checked for compatibility, etc) on the older > OSes... Are you saying that W7 and W8 would be actively rejected? Supporting older OSes requires to keep workarounds in the code and sometimes leads to the inability to implement stuff in ways only available on newer OSes. Each deprecation of older OSes in Cygwin worked like this so far, and for 3.5 (late 2023) we announced the deprecation of Windows 7 and 8 since the first 3.3.0 release in October 2021. Corinna -- 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: gcc -pg broken after cygwin update?
On Dec 7 15:05, Daniel Abrahamsson via Cygwin wrote: > > On Dec 7 12:50, Corinna Vinschen via Cygwin wrote: > > > On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote: > > > > Hi, > > > > > > > > This morning I updated cygwin, and after that gcc started producing > > > > errors like this: > > > > > > > > > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-parameter -g -pg > > > > > -DVERBOSE -c -o ../obj/.o .c > > > > > gcc -o ../bin/ ../obj/.o -pg > > > > > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: > > > > > ../obj/.o: in function `exit_eval_failure': > > > > /home/daab/dev/someproj/src/.c:17: undefined reference to > > > > `__fentry__' > > > > [...] > > > Thanks for the report. > > > > > > This is a dumb bug I introduced into the build system in 3.4.0. I fixed > > > that in the git repo, but the automated build of the matching test > > > [...] > > Automated builds have been picked up again and the Cygwin test package > > 3.5.0-0.17.g95f5b0a62036 should be available later today. You can > > install it using setup.exe, just like any other test release. > > > > Don't forget to install the matching cygwin-devel package, too, that's > > the one containing the library libgmon.a, which is what gets linked in > > with `gcc -pg'. > > I can confirm 3.5.0-0.17.g95f5b0a62036 solves the issue with the "-pg" > flag. Thank you! Thanks for your feedback! Corinna -- 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: [EXTERNAL] Re: gcc -pg broken after cygwin update?
On Dec 7 14:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > provided you run at least Windows 8.1 > > Why would that be a requirement? Test releases are created from the master branch which already bumped version to 3.5.0 and contains patches dropping W7 and W8 support: https://cygwin.com/pipermail/cygwin-announce/2022-December/010821.html Corinna -- 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: gcc -pg broken after cygwin update?
On Dec 7 12:50, Corinna Vinschen via Cygwin wrote: > On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote: > > Hi, > > > > This morning I updated cygwin, and after that gcc started producing errors > > like this: > > > > > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-parameter -g -pg > > > -DVERBOSE -c -o ../obj/.o .c > > > gcc -o ../bin/ ../obj/.o -pg > > > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: > > > ../obj/.o: in function `exit_eval_failure': > > /home/daab/dev/someproj/src/.c:17: undefined reference to > > `__fentry__' > > > > If I drop the "pg" flags from the compilation and linking stages, > > everything works. > > > > I typically update cygwin packages once per week, but now it has been > > maybe a month since I last updated. As far as I can tell from the > > cygwin-announce archives, there has not been any gcc updates in that > > period, but I do note that cygwin itself has been updated. Could that > > be related? > > Thanks for the report. > > This is a dumb bug I introduced into the build system in 3.4.0. I fixed > that in the git repo, but the automated build of the matching test > release cygwin-3.5.0-0.17.g95f5b0a62036 is currently not building due to > some hiccup on cygwin.com. I'll send a new mail as soon as this is > fixed and you can test it (provided you run at least Windows 8.1). Automated builds have been picked up again and the Cygwin test package 3.5.0-0.17.g95f5b0a62036 should be available later today. You can install it using setup.exe, just like any other test release. Don't forget to install the matching cygwin-devel package, too, that's the one containing the library libgmon.a, which is what gets linked in with `gcc -pg'. Thanks, Corinna -- 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: gcc -pg broken after cygwin update?
On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote: > Hi, > > This morning I updated cygwin, and after that gcc started producing errors > like this: > > > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-parameter -g -pg -DVERBOSE > > -c -o ../obj/.o .c > > gcc -o ../bin/ ../obj/.o -pg > > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: > > ../obj/.o: in function `exit_eval_failure': > /home/daab/dev/someproj/src/.c:17: undefined reference to > `__fentry__' > > If I drop the "pg" flags from the compilation and linking stages, everything > works. > > I typically update cygwin packages once per week, but now it has been > maybe a month since I last updated. As far as I can tell from the > cygwin-announce archives, there has not been any gcc updates in that > period, but I do note that cygwin itself has been updated. Could that > be related? Thanks for the report. This is a dumb bug I introduced into the build system in 3.4.0. I fixed that in the git repo, but the automated build of the matching test release cygwin-3.5.0-0.17.g95f5b0a62036 is currently not building due to some hiccup on cygwin.com. I'll send a new mail as soon as this is fixed and you can test it (provided you run at least Windows 8.1). Thanks, Corinna -- 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] tcsh 6.24.05-1
The following packages have been uploaded to the Cygwin distribution: * tcsh-6.24.05-1 This is a maintenance release with no functional change to the shell itself, but all additional changes from 6.24.03 (and 6.24.04, never released) have been applied to the manual page. All other changes are about the build and release processes. Downside: The conversion from the man page to HTML has been deprecated, so the HTML documentation is no longer part of this package. Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax. -- 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] cygwin 3.4.0-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.0-1 * cygwin-devel-3.4.0-1 * cygwin-doc-3.4.0-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.4 is the FIRST major version dropping support for - 32 bit Windows including WOW64 on 64 bit Windows. - Windows Vista - Windows Server 2008 - Cygwin 3.4 is the LAST major version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 - Cygwin 3.5, which will probably be release at some point in late 2023, will run on - Windows 8.1 - Windows 10 - Windows 11 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 - Windows Server 2022 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == What's new: --- - Drop support for Vista and Server 2008. - Drop support for 32 bit Windows and WOW64. - Allow to run with full ASLR enabled and enable on Cygwin DLL by default. - Remove any special handling for the .com filename suffix. It has to be used always explicitely. - Add code to handle setrlimit(RLIMIT_AS). - Add code to handle signal masks in /proc//status. - Handle UDP_SEGMENT and UDP_GRO socket options. What changed: - - The CYGWIN=pipe_byte option is now set by default, so that pipes are opened in byte mode rather than message mode. Addresses: https://cygwin.com/pipermail/cygwin/2021-March/247987.html - The stdio input functions no longer try again to read after EOF. This aligns Cygwin behavior to that of Linux. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251672.html - Treat an empty path (empty element in PATH or PATH is absent) as the current directory as Linux does. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html - The default values of FD_SETSIZE and NOFILE are now 1024 and 3200, respectively. Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html Bug Fixes - - Don't error out if getfacl(1) is called on a socket file. Partially addresses: https://cygwin.com/pipermail/cygwin/2022-July/251768.html - Make serial ioctl(TIOCMBIS/TIOCMBIC) work on USB CDC devices. Addresses: https://cygwin.com/pipermail/cygwin/2022-November/252443.html - Fix a SEGV when running a process with changed primary group. Addresses: https://cygwin.com/pipermail/cygwin-apps/2022-September/042245.html - Fix primary group handling when running a process tree containing non-Cygwin processes and with changed primary group. The Cygwin child process of a non-Cygwin process will have reverted its primary group to the default primary group erroneously. Addresses: https://cygwin.com/pipermail/cygwin-apps/2022-September/042245.html - Fix parsing Windows command line when non-ASCII chars are in the input. Addresses: https://cygwin.com/pipermail/cygwin/2022-November/252481.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
Re: [PATCH 1/2 v2] Filter newlines from BUILD_REQUIRES
On Dec 3 18:07, Jon Turney via Cygwin-apps wrote: > On 03/12/2022 16:19, Corinna Vinschen via Cygwin-apps wrote: > > From: Corinna Vinschen > > > > BUILD_REQUIRES is added verbatim to the build-depends: line in > > the *-src.hint file. If the cygport file defines BUILD_REQUIRES > > with newlines, e. g. > > > >BUILD_REQUIRES=" > > a > > b > >" > > > > The -src.hint file is broken. Avoid this by filtering out any > > newline's from BUILD_REQUIRES before using it in the subsequent > > expression building the -src.hint file. > > Thanks. > > Attached is a patch I wrote taking a slightly more general approach. Yeah, that looks much better to me. Thanks, Corinna
[PATCH 1/2 v2] Filter newlines from BUILD_REQUIRES
From: Corinna Vinschen
BUILD_REQUIRES is added verbatim to the build-depends: line in
the *-src.hint file. If the cygport file defines BUILD_REQUIRES
with newlines, e. g.
BUILD_REQUIRES="
a
b
"
The -src.hint file is broken. Avoid this by filtering out any
newline's from BUILD_REQUIRES before using it in the subsequent
expression building the -src.hint file.
Signed-off-by: Corinna Vinschen
---
lib/pkg_pkg.cygpart | 4
1 file changed, 4 insertions(+)
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 82112e1cfc79..eb06a08dd562 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -544,6 +544,10 @@ __pkg_srcpkg() {
elif [ -n "${!pkg_category_var:-${CATEGORY}}" \
-a -n
"${!pkg_summary_var:-${SUMMARY}}${!pkg_description_var:-${DESCRIPTION}}" ]
then
+ # BUILD_REQUIRES is added to the build-depends: line
+ # in the hint file written below. Convert LFs to
+ # spaces to make sure it's actually a single line.
+ BUILD_REQUIRES=$(echo -n "$BUILD_REQUIRES" | tr '\n' '
')
cat > ${distdir}/${PN}/${PN}-${PVR}-src.hint <<-_EOF
category: ${!pkg_category_var:-${CATEGORY}}
build-depends: cygport ${BUILD_REQUIRES}
--
2.38.1
[PATCH 2/2] Default to x86_64 build on non-Cygwin hosts
From: Corinna Vinschen
Given x86 has been deprecated, we only have a single target for
the time being. Default to this target for now, basically to
safe my lazy ass when building on Linux.
Signed-off-by: Corinna Vinschen
---
NEWS | 3 +++
lib/compilers.cygpart | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 976237d88d54..e3dc83c3f5a4 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+0.35.5:
+ * Default to x86_64-pc-cygwin target on Linux.
+
0.35.4:
* Replace 'egrep' with 'grep -E' throughout
* xorg: Default LICENSE to 'MIT'
diff --git a/lib/compilers.cygpart b/lib/compilers.cygpart
index f9b8c69532e2..35e6fe2886f9 100644
--- a/lib/compilers.cygpart
+++ b/lib/compilers.cygpart
@@ -213,7 +213,7 @@ case ${CBUILD} in
# https://sourceware.org/legacy-ml/cygwin-developers/2013-02/msg00132.html
x86_64-unknown-cygwin) CBUILD="x86_64-pc-cygwin" ;&
*-cygwin) CHOST="${_host_arch:-${CBUILD%%-*}}-pc-cygwin" ;;
-*) defined _host_arch || error "Either --32 or --64 flags MUST be
passed to cygport"
+*) defined _host_arch || _host_arch="x86_64"
CHOST="${_host_arch}-pc-cygwin" ;;
esac
unset _host_arch
--
2.38.1
[PATCH 1/2] Filter newlines from BUILD_REQUIRES
From: Corinna Vinschen
BUILD_REQUIRES is added verbatim to the build-depends: line in
the *-src.hint file. If the cygport file defines BUILD_REQUIRES
with spaces, e. g.
BUILD_REQUIRES="
a
b
"
The -src.hint file is broken. Avoid this by filtering out any
newline's from BUILD_REQUIRES before using it in the subsequent
expression building the -src.hint file.
Signed-off-by: Corinna Vinschen
---
lib/pkg_pkg.cygpart | 4
1 file changed, 4 insertions(+)
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 82112e1cfc79..eb06a08dd562 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -544,6 +544,10 @@ __pkg_srcpkg() {
elif [ -n "${!pkg_category_var:-${CATEGORY}}" \
-a -n
"${!pkg_summary_var:-${SUMMARY}}${!pkg_description_var:-${DESCRIPTION}}" ]
then
+ # BUILD_REQUIRES is added to the build-depends: line
+ # in the hint file written below. Convert LFs to
+ # spaces to make sure it's actually a single line.
+ BUILD_REQUIRES=$(echo -n "$BUILD_REQUIRES" | tr '\n' '
')
cat > ${distdir}/${PN}/${PN}-${PVR}-src.hint <<-_EOF
category: ${!pkg_category_var:-${CATEGORY}}
build-depends: cygport ${BUILD_REQUIRES}
--
2.38.1
Re: [BUG core?] Regression with parsing Windows’ command-line
On Dec 3 16:24, Corinna Vinschen via Cygwin wrote: > On Dec 3 19:28, Takashi Yano via Cygwin wrote: > > On Fri, 2 Dec 2022 19:40:30 -0800 > > Ilya Zakharevich wrote: > > > On Wed, Nov 16, 2022 at 04:48:25AM -0800, I wrote: > > > > De-quoting (converting the Windows’ command-line into argc/argv) does > > > > not remove double quotes if characters not fit for 8-bit (?) are > > > > present. > > > > > > > > To reproduce, do in CMD’s command line: > > > > > > > > D:\> D:\Programs\cygwin2022\bin\perl -wle "print for @ARGV" . "/i/" > > > > "/и/" . > > > > . > > > > /i/ > > > > "/и/" > > > > . > > > [...] > I pushed a patch and the test release is rebuilding while I type. This will be fixed in test release cygwin-3.4.0-0.875.g07a9a6c21ab3, which should be up in an hour or so. Corinna -- 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] tcsh 6.24.03-1
The following packages have been uploaded to the Cygwin distribution: * tcsh-6.24.03-1 This is a bugfix release. 1. Handle \c in echo properly. 2. Add a configure check for a working sbrk(). 3. Fix a test failure on busybox. Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax. -- 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: [BUG core?] Regression with parsing Windows’ command-line
On Dec 3 22:42, Takashi Yano via Cygwin wrote: > [...] > The patch above also affects __C_locale. > The patch below should be more appropriate. Looks like we had the same idea at the same time :) Corinna -- 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: [BUG core?] Regression with parsing Windows’ command-line
On Dec 3 19:28, Takashi Yano via Cygwin wrote:
> On Fri, 2 Dec 2022 19:40:30 -0800
> Ilya Zakharevich wrote:
> > On Wed, Nov 16, 2022 at 04:48:25AM -0800, I wrote:
> > > De-quoting (converting the Windows’ command-line into argc/argv) does
> > > not remove double quotes if characters not fit for 8-bit (?) are present.
> > >
> > > To reproduce, do in CMD’s command line:
> > >
> > > D:\> D:\Programs\cygwin2022\bin\perl -wle "print for @ARGV" . "/i/"
> > > "/и/" .
> > > .
> > > /i/
> > > "/и/"
> > > .
> > [...]
> This certainly seems to be a problem of cygwin1.dll.
>
> Though I am not sure this is the right thing, I have confirmed
> that the following patch solves the issue.
>
> diff --git a/newlib/libc/locale/lctype.c b/newlib/libc/locale/lctype.c
> index 644669765..732d132e1 100644
> --- a/newlib/libc/locale/lctype.c
> +++ b/newlib/libc/locale/lctype.c
> @@ -25,11 +25,20 @@
>
> #define LCCTYPE_SIZE (sizeof(struct lc_ctype_T) / sizeof(char *))
>
> +#ifdef __CYGWIN__
> +static char numsix[] = { '\6', '\0'};
> +#else
> static char numone[] = { '\1', '\0'};
> +#endif
>
> const struct lc_ctype_T _C_ctype_locale = {
> +#ifdef __CYGWIN__
> + "UTF-8",/* codeset */
> + numsix /* mb_cur_max */
> +#else
> "ASCII",/* codeset */
> numone /* mb_cur_max */
> +#endif
Good idea, but this transforms the "C" locale into the "C.UTF-8" locale
once and for all.
What we're actually missing is a matching _C_utf8_ctype_locale which can
be used by Cygwin as default locale setting, AFAICS.
I pushed a patch and the test release is rebuilding while I type.
Thanks,
Corinna
--
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] gawk 5.2.1-1
The following packages have been uploaded to the Cygwin distribution: * gawk-5.2.1-1 The gawk package contains the GNU version of awk, a text processing utility. Awk interprets a special-purpose programming language to do quick and easy text pattern matching and reformatting jobs. Install the gawk package if you need a text processing utility. Gawk is considered to be a standard Linux tool for processing text. Changes from 5.2.0 to 5.2.1 --- 1. More subtle issues with untyped array elements being passed to functions have been fixed. 2. The rwarray extension's readall() function has had some bugs fixed. 3. The PMA allocator is now supported on Linux on s/390, FreeBSD and OpenBSD. It is currently disabled on macos on M1 since there are some unsolved problems in that environment. macos on Intel works without problem. 4. There have been several minor code cleanups and bug fixes. See the ChangeLog for details. Changes from 5.1.x to 5.2.0 --- * * MPFR mode (the -M option) is now ON PAROLE. This feature is now being* * supported by a volunteer in the development team and not by the primary * * maintainer. If this situation changes, then the feature will be removed. * * For more information see this section in the manual: * * https://www.gnu.org/software/gawk/manual/html_node/MPFR-On-Parole.html* * 1. Infrastructure upgrades: Libtool 2.4.7, Bison 3.8.2. 2. Numeric scalars now compare in the same way as C for the relational operators. Comparison order for sorting has not changed. This only makes a difference when comparing Infinity and NaN values with regular numbers; it should not be noticeable most of the time. 3. If the AWK_HASH environment variable is set to "fnv1a" gawk will use the FNV1-A hash function for associative arrays. 4. The CMake infrastructure has been removed. In the five years it was in the tree, nobody used it, and it was not updated. 5. There is now a new function, mkbool(), that creates Boolean-typed values. These values *are* numbers, but they are also tagged as Boolean. This is mainly for use with data exchange to/from languages or environments that support real Boolean values. See the manual for details. 6. As BWK awk has supported interval expressions since 2019, they are now enabled even if --traditional is supplied. The -r/--re-interval option remains, but it does nothing. 7. The rwarray extension has two new functions, writeall() and readall(), for saving / restoring all of gawk's variables and arrays. 8. The new `gawkbug' script should be used for reporting bugs. 9. The manual page (doc/gawk.1) has been considerably reduced in size. Wherever possible, details were replaced with references to the online copy of the manual. 10. Gawk now supports Terence Kelly's "persistent malloc" (pma), allowing gawk to preserve its variables, arrays and user-defined functions between runs. THIS IS AN EXPERIMENTAL FEATURE! For more information, see the manual. A new pm-gawk.1 man page is included, as is a separate user manual that focuses on the feature. 11. Support for OS/2 has been removed. It was not being actively maintained. 12. Similarly, support for DJGPP has been removed. It also was not being actively maintained. 13. VAX/VMS is no longer supported, as it can no longer be tested. The files for it remain in the distribution but will be removed eventually. 14. Some subtle issues with untyped array elements being passed to functions have been fixed. 15. Syntax errors are now immediately fatal. This prevents problems with errors from fuzzers and other such things. 16. There have been numerous minor code cleanups and bug fixes. See the ChangeLog for details. -- 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
gawk 5.2.1-1
The following packages have been uploaded to the Cygwin distribution: * gawk-5.2.1-1 The gawk package contains the GNU version of awk, a text processing utility. Awk interprets a special-purpose programming language to do quick and easy text pattern matching and reformatting jobs. Install the gawk package if you need a text processing utility. Gawk is considered to be a standard Linux tool for processing text. Changes from 5.2.0 to 5.2.1 --- 1. More subtle issues with untyped array elements being passed to functions have been fixed. 2. The rwarray extension's readall() function has had some bugs fixed. 3. The PMA allocator is now supported on Linux on s/390, FreeBSD and OpenBSD. It is currently disabled on macos on M1 since there are some unsolved problems in that environment. macos on Intel works without problem. 4. There have been several minor code cleanups and bug fixes. See the ChangeLog for details. Changes from 5.1.x to 5.2.0 --- * * MPFR mode (the -M option) is now ON PAROLE. This feature is now being* * supported by a volunteer in the development team and not by the primary * * maintainer. If this situation changes, then the feature will be removed. * * For more information see this section in the manual: * * https://www.gnu.org/software/gawk/manual/html_node/MPFR-On-Parole.html* * 1. Infrastructure upgrades: Libtool 2.4.7, Bison 3.8.2. 2. Numeric scalars now compare in the same way as C for the relational operators. Comparison order for sorting has not changed. This only makes a difference when comparing Infinity and NaN values with regular numbers; it should not be noticeable most of the time. 3. If the AWK_HASH environment variable is set to "fnv1a" gawk will use the FNV1-A hash function for associative arrays. 4. The CMake infrastructure has been removed. In the five years it was in the tree, nobody used it, and it was not updated. 5. There is now a new function, mkbool(), that creates Boolean-typed values. These values *are* numbers, but they are also tagged as Boolean. This is mainly for use with data exchange to/from languages or environments that support real Boolean values. See the manual for details. 6. As BWK awk has supported interval expressions since 2019, they are now enabled even if --traditional is supplied. The -r/--re-interval option remains, but it does nothing. 7. The rwarray extension has two new functions, writeall() and readall(), for saving / restoring all of gawk's variables and arrays. 8. The new `gawkbug' script should be used for reporting bugs. 9. The manual page (doc/gawk.1) has been considerably reduced in size. Wherever possible, details were replaced with references to the online copy of the manual. 10. Gawk now supports Terence Kelly's "persistent malloc" (pma), allowing gawk to preserve its variables, arrays and user-defined functions between runs. THIS IS AN EXPERIMENTAL FEATURE! For more information, see the manual. A new pm-gawk.1 man page is included, as is a separate user manual that focuses on the feature. 11. Support for OS/2 has been removed. It was not being actively maintained. 12. Similarly, support for DJGPP has been removed. It also was not being actively maintained. 13. VAX/VMS is no longer supported, as it can no longer be tested. The files for it remain in the distribution but will be removed eventually. 14. Some subtle issues with untyped array elements being passed to functions have been fixed. 15. Syntax errors are now immediately fatal. This prevents problems with errors from fuzzers and other such things. 16. There have been numerous minor code cleanups and bug fixes. See the ChangeLog for details.
[ANNOUNCEMENT] TEST: cygwin 3.4.0-0.1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.0-0.1 * cygwin-devel-3.4.0-0.1 * cygwin-doc-3.4.0-0.1 This is the first test release of the 64 bit-only Cygwin 3.4.0. Please test. What's new: --- - Drop support for Vista and Server 2008. - Drop support for 32 bit Windows and WOW64. - Allow to run with full ASLR enabled and enable on Cygwin DLL by default. - Remove any special handling for the .com filename suffix. It has to be used always explicitely. - Add code to handle setrlimit(RLIMIT_AS). - Add code to handle signal masks in /proc//status. - Handle UDP_SEGMENT and UDP_GRO socket options. What changed: - - The CYGWIN=pipe_byte option is now set by default, so that pipes are opened in byte mode rather than message mode. Addresses: https://cygwin.com/pipermail/cygwin/2021-March/247987.html - The stdio input functions no longer try again to read after EOF. This aligns Cygwin behavior to that of Linux. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251672.html - Treat an empty path (empty element in PATH or PATH is absent) as the current directory as Linux does. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html - The default values of FD_SETSIZE and NOFILE are now 1024 and 3200, respectively. Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html Bug Fixes - - Don't error out if getfacl(1) is called on a socket file. Partially addresses: https://cygwin.com/pipermail/cygwin/2022-July/251768.html - Make serial ioctl(TIOCMBIS/TIOCMBIC) work on USB CDC devices. Addresses: https://cygwin.com/pipermail/cygwin/2022-November/252443.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
TEST: cygwin 3.4.0-0.1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.0-0.1 * cygwin-devel-3.4.0-0.1 * cygwin-doc-3.4.0-0.1 This is the first test release of the 64 bit-only Cygwin 3.4.0. Please test. What's new: --- - Drop support for Vista and Server 2008. - Drop support for 32 bit Windows and WOW64. - Allow to run with full ASLR enabled and enable on Cygwin DLL by default. - Remove any special handling for the .com filename suffix. It has to be used always explicitely. - Add code to handle setrlimit(RLIMIT_AS). - Add code to handle signal masks in /proc//status. - Handle UDP_SEGMENT and UDP_GRO socket options. What changed: - - The CYGWIN=pipe_byte option is now set by default, so that pipes are opened in byte mode rather than message mode. Addresses: https://cygwin.com/pipermail/cygwin/2021-March/247987.html - The stdio input functions no longer try again to read after EOF. This aligns Cygwin behavior to that of Linux. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251672.html - Treat an empty path (empty element in PATH or PATH is absent) as the current directory as Linux does. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html - The default values of FD_SETSIZE and NOFILE are now 1024 and 3200, respectively. Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html Bug Fixes - - Don't error out if getfacl(1) is called on a socket file. Partially addresses: https://cygwin.com/pipermail/cygwin/2022-July/251768.html - Make serial ioctl(TIOCMBIS/TIOCMBIC) work on USB CDC devices. Addresses: https://cygwin.com/pipermail/cygwin/2022-November/252443.html
[ANNOUNCEMENT] openssh 9.1p1-1
The following packages have been uploaded to the Cygwin distribution: * openssh-9.1p1-1 OpenSSH is a program for logging into a remote machine and for executing commands on a remote machine. It can replace rlogin and rsh, providing encrypted communication between two machines. Cygwin release message: WinHello support: Lots of patches to support FIDO2 keys utilizing WinHello have gone into the upstream release now. Additionally to the 9.0p1-1 Cygwin release, Biometric FIDO2 keys are now seamlessly supported as well. Please note that keys created with `-O no-touch-required' won't work, because WinHello doesn't support authenticating FIDO2 tokens without checking user presence. Official upstream release message: OpenSSH 9.1 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Changes since OpenSSH 9.0 = This release is focused on bug fixing. Security This release contains fixes for three minor memory safety problems. None are believed to be exploitable, but we report most memory safety problems as potential security vulnerabilities out of caution. * ssh-keyscan(1): fix a one-byte overflow in SSH- banner processing. Reported by Qualys * ssh-keygen(1): double free() in error path of file hashing step in signing/verify code; GHPR333 * ssh-keysign(8): double-free in error path introduced in openssh-8.9 Potentially-incompatible changes * The portable OpenSSH project now signs commits and release tags using git's recent SSH signature support. The list of developer signing keys is included in the repository as .git_allowed_signers and is cross-signed using the PGP key that is still used to sign release artifacts: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc * ssh(1), sshd(8): SetEnv directives in ssh_config and sshd_config are now first-match-wins to match other directives. Previously if an environment variable was multiply specified the last set value would have been used. bz3438 * ssh-keygen(8): ssh-keygen -A (generate all default host key types) will no longer generate DSA keys, as these are insecure and have not been used by default for some years. * ssh(1), sshd(8): add a RequiredRSASize directive to set a minimum RSA key length. Keys below this length will be ignored for user authentication and for host authentication in sshd(8). ssh(1) will terminate a connection if the server offers an RSA key that falls below this limit, as the SSH protocol does not include the ability to retry a failed key exchange. * sftp-server(8): add a "users-groups-by...@openssh.com" extension request that allows the client to obtain user/group names that correspond to a set of uids/gids. * sftp(1): use "users-groups-by...@openssh.com" sftp-server extension (when available) to fill in user/group names for directory listings. * sftp-server(8): support the "home-directory" extension request defined in draft-ietf-secsh-filexfer-extensions-00. This overlaps a bit with the existing "expand-p...@openssh.com", but some other clients support it. * ssh-keygen(1), sshd(8): allow certificate validity intervals, sshsig verification times and authorized_keys expiry-time options to accept dates in the UTC time zone in addition to the default of interpreting them in the system time zone. MMDD and YYMMDDHHMM[SS] dates/times will be interpreted as UTC if suffixed with a 'Z' character. Also allow certificate validity intervals to be specified in raw seconds-since-epoch as hex value, e.g. -V 0x1234:0x4567890. This is intended for use by regress tests and other tools that call ssh-keygen as part of a CA workflow. bz3468 * sftp(1): allow arguments to the sftp -D option, e.g. sftp -D "/usr/libexec/sftp-server -el debug3" * ssh-keygen(1): allow the existing -U (use agent) flag to work with "-Y sign" operations, where it will be interpreted to require that the private keys is hosted in an agent; bz3429 New features * ssh(1), sshd(8): add a RequiredRSASize directive to set a minimum RSA key length. Keys below this length will be ignored for user authentication and for host authentication in sshd(8). ssh(1) will terminate a connection if the server offers an RSA key that falls below this
openssh 9.1p1-1
The following packages have been uploaded to the Cygwin distribution: * openssh-9.1p1-1 OpenSSH is a program for logging into a remote machine and for executing commands on a remote machine. It can replace rlogin and rsh, providing encrypted communication between two machines. Cygwin release message: WinHello support: Lots of patches to support FIDO2 keys utilizing WinHello have gone into the upstream release now. Additionally to the 9.0p1-1 Cygwin release, Biometric FIDO2 keys are now seamlessly supported as well. Please note that keys created with `-O no-touch-required' won't work, because WinHello doesn't support authenticating FIDO2 tokens without checking user presence. Official upstream release message: OpenSSH 9.1 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Changes since OpenSSH 9.0 = This release is focused on bug fixing. Security This release contains fixes for three minor memory safety problems. None are believed to be exploitable, but we report most memory safety problems as potential security vulnerabilities out of caution. * ssh-keyscan(1): fix a one-byte overflow in SSH- banner processing. Reported by Qualys * ssh-keygen(1): double free() in error path of file hashing step in signing/verify code; GHPR333 * ssh-keysign(8): double-free in error path introduced in openssh-8.9 Potentially-incompatible changes * The portable OpenSSH project now signs commits and release tags using git's recent SSH signature support. The list of developer signing keys is included in the repository as .git_allowed_signers and is cross-signed using the PGP key that is still used to sign release artifacts: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc * ssh(1), sshd(8): SetEnv directives in ssh_config and sshd_config are now first-match-wins to match other directives. Previously if an environment variable was multiply specified the last set value would have been used. bz3438 * ssh-keygen(8): ssh-keygen -A (generate all default host key types) will no longer generate DSA keys, as these are insecure and have not been used by default for some years. * ssh(1), sshd(8): add a RequiredRSASize directive to set a minimum RSA key length. Keys below this length will be ignored for user authentication and for host authentication in sshd(8). ssh(1) will terminate a connection if the server offers an RSA key that falls below this limit, as the SSH protocol does not include the ability to retry a failed key exchange. * sftp-server(8): add a "users-groups-by...@openssh.com" extension request that allows the client to obtain user/group names that correspond to a set of uids/gids. * sftp(1): use "users-groups-by...@openssh.com" sftp-server extension (when available) to fill in user/group names for directory listings. * sftp-server(8): support the "home-directory" extension request defined in draft-ietf-secsh-filexfer-extensions-00. This overlaps a bit with the existing "expand-p...@openssh.com", but some other clients support it. * ssh-keygen(1), sshd(8): allow certificate validity intervals, sshsig verification times and authorized_keys expiry-time options to accept dates in the UTC time zone in addition to the default of interpreting them in the system time zone. MMDD and YYMMDDHHMM[SS] dates/times will be interpreted as UTC if suffixed with a 'Z' character. Also allow certificate validity intervals to be specified in raw seconds-since-epoch as hex value, e.g. -V 0x1234:0x4567890. This is intended for use by regress tests and other tools that call ssh-keygen as part of a CA workflow. bz3468 * sftp(1): allow arguments to the sftp -D option, e.g. sftp -D "/usr/libexec/sftp-server -el debug3" * ssh-keygen(1): allow the existing -U (use agent) flag to work with "-Y sign" operations, where it will be interpreted to require that the private keys is hosted in an agent; bz3429 New features * ssh(1), sshd(8): add a RequiredRSASize directive to set a minimum RSA key length. Keys below this length will be ignored for user authentication and for host authentication in sshd(8). ssh(1) will terminate a connection if the server offers an RSA key that falls below this
[ANNOUNCEMENT] cygwin 3.3.6-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.6-1 * cygwin-devel-3.3.6-1 * cygwin-doc-3.3.6-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in late 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix an issue that command "cmd /c script -c cmd" crashes if it is issued in console of Windows 7. - Fix killpg failing because the exec'ing as well as the exec'ed process are not in the pidlist for a brief moment. Addresses: https://cygwin.com/pipermail/cygwin/2022-May/251479.html - Fix mknod (64-bit only), whose definition didn't match its prototype. Addresses: https://cygwin.com/pipermail/cygwin-developers/2022-May/012589.html - Fix a regression that prevented Cygwin from starting if cygwin1.dll is in the root directory. Addresses: https://cygwin.com/pipermail/cygwin/2022-May/251548.html - Handle setting very long window title correctly in console. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251662.html - Fix a bug of poll() that it returns event which is not inquired if events are inquired in multiple pollfd entries on the same fd at the same time. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251732.html - Fix a console problem that the text longer than 1024 bytes cannot be pasted correctly. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251764.html - Fix a pty problem that pty failed to switch I/O pipe to that for native apps if *.bat or *.cmd is executed directly from cygwin shell. Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251993.html - Fix a problem that prevented some symbolic links to /cygdrive/C, /cygdrive/./c, /cygdrive//c, etc. from working. Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251994.html - Fix a path handling bug that could cause a non-existing file to be treated as the current directory. Addresses: https://cygwin.com/pipermail/cygwin/2022-August/252030.html - Fix a crash in newlocale. Addresses: https://cygwin.com/pipermail/cygwin/2022-August/252043.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
cygwin 3.3.6-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.6-1 * cygwin-devel-3.3.6-1 * cygwin-doc-3.3.6-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in late 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix an issue that command "cmd /c script -c cmd" crashes if it is issued in console of Windows 7. - Fix killpg failing because the exec'ing as well as the exec'ed process are not in the pidlist for a brief moment. Addresses: https://cygwin.com/pipermail/cygwin/2022-May/251479.html - Fix mknod (64-bit only), whose definition didn't match its prototype. Addresses: https://cygwin.com/pipermail/cygwin-developers/2022-May/012589.html - Fix a regression that prevented Cygwin from starting if cygwin1.dll is in the root directory. Addresses: https://cygwin.com/pipermail/cygwin/2022-May/251548.html - Handle setting very long window title correctly in console. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251662.html - Fix a bug of poll() that it returns event which is not inquired if events are inquired in multiple pollfd entries on the same fd at the same time. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251732.html - Fix a console problem that the text longer than 1024 bytes cannot be pasted correctly. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251764.html - Fix a pty problem that pty failed to switch I/O pipe to that for native apps if *.bat or *.cmd is executed directly from cygwin shell. Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251993.html - Fix a problem that prevented some symbolic links to /cygdrive/C, /cygdrive/./c, /cygdrive//c, etc. from working. Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251994.html - Fix a path handling bug that could cause a non-existing file to be treated as the current directory. Addresses: https://cygwin.com/pipermail/cygwin/2022-August/252030.html - Fix a crash in newlocale. Addresses: https://cygwin.com/pipermail/cygwin/2022-August/252043.html
[ANNOUNCEMENT] libfido2 1.11.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.11.0-1 * libfido2-devel-1.11.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. What's new: * Version 1.11.0 (2022-05-03) ** Experimental PCSC support; enable with -DUSE_PCSC. ** Improved OpenSSL 3.0 compatibility. ** Use RFC1951 raw deflate to compress CTAP 2.1 largeBlobs. ** winhello: advertise "uv" instead of "clientPin". ** winhello: support hmac-secret in fido_dev_get_assert(). ** New API calls: - fido_cbor_info_maxlargeblob. ** Documentation and reliability fixes. ** Separate build and regress targets. -- 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
libfido2 1.11.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.11.0-1 * libfido2-devel-1.11.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. What's new: * Version 1.11.0 (2022-05-03) ** Experimental PCSC support; enable with -DUSE_PCSC. ** Improved OpenSSL 3.0 compatibility. ** Use RFC1951 raw deflate to compress CTAP 2.1 largeBlobs. ** winhello: advertise "uv" instead of "clientPin". ** winhello: support hmac-secret in fido_dev_get_assert(). ** New API calls: - fido_cbor_info_maxlargeblob. ** Documentation and reliability fixes. ** Separate build and regress targets.
[ANNOUNCEMENT] rebase 4.6.1-1
The following packages have been uploaded to the Cygwin distribution: * rebase-4.6.1-1 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. * Make rebaseall a wrapper around /etc/postinstall/0p_000_autorebase.dash. -- 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
rebase 4.6.1-1
The following packages have been uploaded to the Cygwin distribution: * rebase-4.6.1-1 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. * Make rebaseall a wrapper around /etc/postinstall/0p_000_autorebase.dash.
[ANNOUNCEMENT] rebase 4.6.0-2
The following packages have been uploaded to the Cygwin distribution: * rebase-4.6.0-2 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. This release adds support for Compact OS and contains a couple of bugfixes of the rebasing algorithm, courtesy Christian Franke. -- 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
rebase 4.6.0-2
The following packages have been uploaded to the Cygwin distribution: * rebase-4.6.0-2 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. This release adds support for Compact OS and contains a couple of bugfixes of the rebasing algorithm, courtesy Christian Franke.
[ANNOUNCEMENT] cygwin 3.3.5-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.5-1 * cygwin-devel-3.3.5-1 * cygwin-doc-3.3.5-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in late 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix a bug that accessing UNC path mounted to a drive letter using SMB3.11 fails with error "Too many levels of symbolic links.". - Fix a console bug that escape sequence IL/DL (CSI Ps L, CSI Ps M) does not work correctly at the last line. Addresses: https://cygwin.com/pipermail/cygwin/2022-February/250736.html - Fix a problem that ENABLE_INSERT_MODE and ENABLE_QUICK_EDIT_MODE flags are cleared if cygwin is started in console. - Fix an issue that cmd.exe also is terminated along with the cygwin app started from the cmd.exe if the cygwin app is terminated by Ctrl-C. - Fix deadlock caused when keys are typed in pty while a lot of text output. - Fix a problem that the console mode for input is not set correctly when non-cygwin app is started with stdin redirected. Addresses: https://github.com/GitCredentialManager/git-credential-manager/issues/576 - Fix some problems such as: 1) If output of non-cygwin app and input of cygwin app are connected by a pipe, Ctrl-C has to be sent twice to stop apps when the cygwin app does not read stdin at the moment. 2) In cmd.exe started from cygwin shell, if output of non-cygwin app and input of cygwin app are connected by a pipe, Ctrl-C can never terminate the apps. - Fix exit code when non-cygwin app is terminated by Ctrl-C. - Fix a bug that the order of the console key inputs are occasionally swapped, especially when CPU load is high. Addresses: https://cygwin.com/pipermail/cygwin/2022-February/250957.html - Fix a problem that fsync() flushes the console input buffer unlike linux. fsync() should return EINVAL for special files such as tty. Addresses: https://cygwin.com/pipermail/cygwin/2022-March/251022.html - Fix a formatting problem in gmondump where all displayed addresses are mistakenly prefixed with "0x0x". Fix man pages for gmondump and ssp. - Fix crash on pty master close in Windows 7. Addresses: https://cygwin.com/pipermail/cygwin/2022-March/251162.html - Avoid deadlock of non-cygwin pipe writer which occurs when the other cygwin pipe writers exist if the pipe is created by system account or the pipe creator is running as service. Addresses: https://cygwin.com/pipermail/cygwin/2022-March/251097.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
cygwin 3.3.5-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.5-1 * cygwin-devel-3.3.5-1 * cygwin-doc-3.3.5-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in late 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix a bug that accessing UNC path mounted to a drive letter using SMB3.11 fails with error "Too many levels of symbolic links.". - Fix a console bug that escape sequence IL/DL (CSI Ps L, CSI Ps M) does not work correctly at the last line. Addresses: https://cygwin.com/pipermail/cygwin/2022-February/250736.html - Fix a problem that ENABLE_INSERT_MODE and ENABLE_QUICK_EDIT_MODE flags are cleared if cygwin is started in console. - Fix an issue that cmd.exe also is terminated along with the cygwin app started from the cmd.exe if the cygwin app is terminated by Ctrl-C. - Fix deadlock caused when keys are typed in pty while a lot of text output. - Fix a problem that the console mode for input is not set correctly when non-cygwin app is started with stdin redirected. Addresses: https://github.com/GitCredentialManager/git-credential-manager/issues/576 - Fix some problems such as: 1) If output of non-cygwin app and input of cygwin app are connected by a pipe, Ctrl-C has to be sent twice to stop apps when the cygwin app does not read stdin at the moment. 2) In cmd.exe started from cygwin shell, if output of non-cygwin app and input of cygwin app are connected by a pipe, Ctrl-C can never terminate the apps. - Fix exit code when non-cygwin app is terminated by Ctrl-C. - Fix a bug that the order of the console key inputs are occasionally swapped, especially when CPU load is high. Addresses: https://cygwin.com/pipermail/cygwin/2022-February/250957.html - Fix a problem that fsync() flushes the console input buffer unlike linux. fsync() should return EINVAL for special files such as tty. Addresses: https://cygwin.com/pipermail/cygwin/2022-March/251022.html - Fix a formatting problem in gmondump where all displayed addresses are mistakenly prefixed with "0x0x". Fix man pages for gmondump and ssp. - Fix crash on pty master close in Windows 7. Addresses: https://cygwin.com/pipermail/cygwin/2022-March/251162.html - Avoid deadlock of non-cygwin pipe writer which occurs when the other cygwin pipe writers exist if the pipe is created by system account or the pipe creator is running as service. Addresses: https://cygwin.com/pipermail/cygwin/2022-March/251097.html
[ANNOUNCEMENT] tcsh 6.24.01-1
The following packages have been uploaded to the Cygwin distribution: * tcsh-6.24.01-1 This is a bug fix release: 1. Fix return status of which (Jamie Landeg-Jones) 2. Fix quoting of ! characters in history recall (Kimmo Suominen) Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax. -- 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
tcsh 6.24.01-1
The following packages have been uploaded to the Cygwin distribution: * tcsh-6.24.01-1 This is a bug fix release: 1. Fix return status of which (Jamie Landeg-Jones) 2. Fix quoting of ! characters in history recall (Kimmo Suominen) Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax.
[ANNOUNCEMENT] openssh 9.0p1-1
The following packages have been uploaded to the Cygwin distribution:
* openssh-9.0p1-1
OpenSSH is a program for logging into a remote machine and for
executing commands on a remote machine. It can replace rlogin and rsh,
providing encrypted communication between two machines.
Cygwin release message:
WinHello support:
Apart from the following official upstream release message, this release
contains support for WinHello. That is, users of Windows 10 1909 or
later will now be able to uses FIDO2 tokens in conjunction with
WinHello. Create keys with one of
ssh-keygen -t ed25519-sk [-O verify-required]
ssh-keygen -t ecdsa-sk [-O verify-required]
Please note that keys created with `-O no-touch-required' won't work,
because WinHello doesn't support authenticating FIDO2 tokens without
checking user presence.
WinHello support is supposed to go upstream, but the changes didn't
make it into 9.0p1.
Official upstream release message:
OpenSSH 9.0 has just been released. It will be available from the
mirrors listed at https://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support.
Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
https://www.openssh.com/donations.html
Changes since OpenSSH 8.9
=
This release is focused on bug fixing.
Potentially-incompatible changes
This release switches scp(1) from using the legacy scp/rcp protocol
to using the SFTP protocol by default.
Legacy scp/rcp performs wildcard expansion of remote filenames (e.g.
"scp host:* .") through the remote shell. This has the side effect of
requiring double quoting of shell meta-characters in file names
included on scp(1) command-lines, otherwise they could be interpreted
as shell commands on the remote side.
This creates one area of potential incompatibility: scp(1) when using
the SFTP protocol no longer requires this finicky and brittle quoting,
and attempts to use it may cause transfers to fail. We consider the
removal of the need for double-quoting shell characters in file names
to be a benefit and do not intend to introduce bug-compatibility for
legacy scp/rcp in scp(1) when using the SFTP protocol.
Another area of potential incompatibility relates to the use of remote
paths relative to other user's home directories, for example -
"scp host:~user/file /tmp". The SFTP protocol has no native way to
expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later
support a protocol extension "expand-p...@openssh.com" to support
this.
In case of incompatibility, the scp(1) client may be instructed to use
the legacy scp/rcp using the -O flag.
New features
* ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key
exchange method by default ("sntrup761x25519-sha...@openssh.com").
The NTRU algorithm is believed to resist attacks enabled by future
quantum computers and is paired with the X25519 ECDH key exchange
(the previous default) as a backstop against any weaknesses in
NTRU Prime that may be discovered in the future. The combination
ensures that the hybrid exchange offers at least as good security
as the status quo.
We are making this change now (i.e. ahead of cryptographically-
relevant quantum computers) to prevent "capture now, decrypt
later" attacks where an adversary who can record and store SSH
session ciphertext would be able to decrypt it once a sufficiently
advanced quantum computer is available.
* sftp-server(8): support the "copy-data" extension to allow server-
side copying of files/data, following the design in
draft-ietf-secsh-filexfer-extensions-00. bz2948
* sftp(1): add a "cp" command to allow the sftp client to perform
server-side file copies.
Bugfixes
* ssh(1), sshd(8): upstream: fix poll(2) spin when a channel's output
fd closes without data in the channel buffer. bz3405 and bz3411
* sshd(8): pack pollfd array in server listen/accept loop. Could
cause the server to hang/spin when MaxStartups > RLIMIT_NOFILE
* ssh-keygen(1): avoid NULL deref via the find-principals and
check-novalidate operations. bz3409 and GHPR#307 respectively.
* scp(1): fix a memory leak in argument processing. bz3404
* sshd(8): don't try to resolve ListenAddress directives in the sshd
re-exec path. They are unused after re-exec and parsing errors
(possible for example if the host's network configuration changed)
could prevent connections from being accepted.
* sshd(8): when refusing a public key authentication request
openssh 9.0p1-1
The following packages have been uploaded to the Cygwin distribution:
* openssh-9.0p1-1
OpenSSH is a program for logging into a remote machine and for
executing commands on a remote machine. It can replace rlogin and rsh,
providing encrypted communication between two machines.
Cygwin release message:
WinHello support:
Apart from the following official upstream release message, this release
contains support for WinHello. That is, users of Windows 10 1909 or
later will now be able to uses FIDO2 tokens in conjunction with
WinHello. Create keys with one of
ssh-keygen -t ed25519-sk [-O verify-required]
ssh-keygen -t ecdsa-sk [-O verify-required]
Please note that keys created with `-O no-touch-required' won't work,
because WinHello doesn't support authenticating FIDO2 tokens without
checking user presence.
WinHello support is supposed to go upstream, but the changes didn't
make it into 9.0p1.
Official upstream release message:
OpenSSH 9.0 has just been released. It will be available from the
mirrors listed at https://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support.
Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
https://www.openssh.com/donations.html
Changes since OpenSSH 8.9
=
This release is focused on bug fixing.
Potentially-incompatible changes
This release switches scp(1) from using the legacy scp/rcp protocol
to using the SFTP protocol by default.
Legacy scp/rcp performs wildcard expansion of remote filenames (e.g.
"scp host:* .") through the remote shell. This has the side effect of
requiring double quoting of shell meta-characters in file names
included on scp(1) command-lines, otherwise they could be interpreted
as shell commands on the remote side.
This creates one area of potential incompatibility: scp(1) when using
the SFTP protocol no longer requires this finicky and brittle quoting,
and attempts to use it may cause transfers to fail. We consider the
removal of the need for double-quoting shell characters in file names
to be a benefit and do not intend to introduce bug-compatibility for
legacy scp/rcp in scp(1) when using the SFTP protocol.
Another area of potential incompatibility relates to the use of remote
paths relative to other user's home directories, for example -
"scp host:~user/file /tmp". The SFTP protocol has no native way to
expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later
support a protocol extension "expand-p...@openssh.com" to support
this.
In case of incompatibility, the scp(1) client may be instructed to use
the legacy scp/rcp using the -O flag.
New features
* ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key
exchange method by default ("sntrup761x25519-sha...@openssh.com").
The NTRU algorithm is believed to resist attacks enabled by future
quantum computers and is paired with the X25519 ECDH key exchange
(the previous default) as a backstop against any weaknesses in
NTRU Prime that may be discovered in the future. The combination
ensures that the hybrid exchange offers at least as good security
as the status quo.
We are making this change now (i.e. ahead of cryptographically-
relevant quantum computers) to prevent "capture now, decrypt
later" attacks where an adversary who can record and store SSH
session ciphertext would be able to decrypt it once a sufficiently
advanced quantum computer is available.
* sftp-server(8): support the "copy-data" extension to allow server-
side copying of files/data, following the design in
draft-ietf-secsh-filexfer-extensions-00. bz2948
* sftp(1): add a "cp" command to allow the sftp client to perform
server-side file copies.
Bugfixes
* ssh(1), sshd(8): upstream: fix poll(2) spin when a channel's output
fd closes without data in the channel buffer. bz3405 and bz3411
* sshd(8): pack pollfd array in server listen/accept loop. Could
cause the server to hang/spin when MaxStartups > RLIMIT_NOFILE
* ssh-keygen(1): avoid NULL deref via the find-principals and
check-novalidate operations. bz3409 and GHPR#307 respectively.
* scp(1): fix a memory leak in argument processing. bz3404
* sshd(8): don't try to resolve ListenAddress directives in the sshd
re-exec path. They are unused after re-exec and parsing errors
(possible for example if the host's network configuration changed)
could prevent connections from being accepted.
* sshd(8): when refusing a public key authentication request
[ANNOUNCEMENT] openssh 8.9p1-1
The following packages have been uploaded to the Cygwin distribution: * openssh-8.9p1-1 OpenSSH is a program for logging into a remote machine and for executing commands on a remote machine. It can replace rlogin and rsh, providing encrypted communication between two machines. Cygwin release message: WinHello support: Apart from the following official upstream release message, this release contains support for WinHello. That is, users of Windows 10 1909 or later will now be able to uses FIDO2 tokens in conjunction with WinHello. Create keys with one of ssh-keygen -t ed25519-sk [-O verify-required] ssh-keygen -t ecdsa-sk [-O verify-required] Please note that keys created with `-O no-touch-required' won't work, because WinHello doesn't support authenticating FIDO2 tokens without checking user presence. WinHello support is supposed to go upstream, but the changes didn't make it into 8.9p1 in time. Official upstream release message: OpenSSH 8.9 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Future deprecation notice = A near-future release of OpenSSH will switch scp(1) from using the legacy scp/rcp protocol to using SFTP by default. Legacy scp/rcp performs wildcard expansion of remote filenames (e.g. "scp host:* .") through the remote shell. This has the side effect of requiring double quoting of shell meta-characters in file names included on scp(1) command-lines, otherwise they could be interpreted as shell commands on the remote side. This creates one area of potential incompatibility: scp(1) when using the SFTP protocol no longer requires this finicky and brittle quoting, and attempts to use it may cause transfers to fail. We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug-compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol. Another area of potential incompatibility relates to the use of remote paths relative to other user's home directories, for example - "scp host:~user/file /tmp". The SFTP protocol has no native way to expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a protocol extension "expand-p...@openssh.com" to support this. Security Near Miss == * sshd(8): fix an integer overflow in the user authentication path that, in conjunction with other logic errors, could have yielded unauthenticated access under difficult to exploit conditions. This situation is not exploitable because of independent checks in the privilege separation monitor. Privilege separation has been enabled by default in since openssh-3.2.2 (released in 2002) and has been mandatory since openssh-7.5 (released in 2017). Moreover, portable OpenSSH has used toolchain features available in most modern compilers to abort on signed integer overflow since openssh-6.5 (released in 2014). Thanks to Malcolm Stagg for finding and reporting this bug. Potentially-incompatible changes * sshd(8), portable OpenSSH only: this release removes in-built support for MD5-hashed passwords. If you require these on your system then we recommend linking against libxcrypt or similar. * This release modifies the FIDO security key middleware interface and increments SSH_SK_VERSION_MAJOR. Changes since OpenSSH 8.8 = This release includes a number of new features. New features * ssh(1), sshd(8), ssh-add(1), ssh-agent(1): add a system for restricting forwarding and use of keys added to ssh-agent(1) A detailed description of the feature is available at https://www.openssh.com/agent-restrict.html and the protocol extensions are documented in the PROTOCOL and PROTOCOL.agent files in the source release. * ssh(1), sshd(8): add the sntrup761x25519-sha...@openssh.com hybrid ECDH/x25519 + Streamlined NTRU Prime post-quantum KEX to the default KEXAlgorithms list (after the ECDH methods but before the prime-group DH ones). The next release of OpenSSH is likely to make this key exchange the default method. * ssh-keygen(1): when downloading resident keys from a FIDO token, pass back the user ID that was used when the key was created and append it to the filename the key is written to (if it is not the
openssh 8.9p1-1
The following packages have been uploaded to the Cygwin distribution: * openssh-8.9p1-1 OpenSSH is a program for logging into a remote machine and for executing commands on a remote machine. It can replace rlogin and rsh, providing encrypted communication between two machines. Cygwin release message: WinHello support: Apart from the following official upstream release message, this release contains support for WinHello. That is, users of Windows 10 1909 or later will now be able to uses FIDO2 tokens in conjunction with WinHello. Create keys with one of ssh-keygen -t ed25519-sk [-O verify-required] ssh-keygen -t ecdsa-sk [-O verify-required] Please note that keys created with `-O no-touch-required' won't work, because WinHello doesn't support authenticating FIDO2 tokens without checking user presence. WinHello support is supposed to go upstream, but the changes didn't make it into 8.9p1 in time. Official upstream release message: OpenSSH 8.9 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Future deprecation notice = A near-future release of OpenSSH will switch scp(1) from using the legacy scp/rcp protocol to using SFTP by default. Legacy scp/rcp performs wildcard expansion of remote filenames (e.g. "scp host:* .") through the remote shell. This has the side effect of requiring double quoting of shell meta-characters in file names included on scp(1) command-lines, otherwise they could be interpreted as shell commands on the remote side. This creates one area of potential incompatibility: scp(1) when using the SFTP protocol no longer requires this finicky and brittle quoting, and attempts to use it may cause transfers to fail. We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug-compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol. Another area of potential incompatibility relates to the use of remote paths relative to other user's home directories, for example - "scp host:~user/file /tmp". The SFTP protocol has no native way to expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a protocol extension "expand-p...@openssh.com" to support this. Security Near Miss == * sshd(8): fix an integer overflow in the user authentication path that, in conjunction with other logic errors, could have yielded unauthenticated access under difficult to exploit conditions. This situation is not exploitable because of independent checks in the privilege separation monitor. Privilege separation has been enabled by default in since openssh-3.2.2 (released in 2002) and has been mandatory since openssh-7.5 (released in 2017). Moreover, portable OpenSSH has used toolchain features available in most modern compilers to abort on signed integer overflow since openssh-6.5 (released in 2014). Thanks to Malcolm Stagg for finding and reporting this bug. Potentially-incompatible changes * sshd(8), portable OpenSSH only: this release removes in-built support for MD5-hashed passwords. If you require these on your system then we recommend linking against libxcrypt or similar. * This release modifies the FIDO security key middleware interface and increments SSH_SK_VERSION_MAJOR. Changes since OpenSSH 8.8 = This release includes a number of new features. New features * ssh(1), sshd(8), ssh-add(1), ssh-agent(1): add a system for restricting forwarding and use of keys added to ssh-agent(1) A detailed description of the feature is available at https://www.openssh.com/agent-restrict.html and the protocol extensions are documented in the PROTOCOL and PROTOCOL.agent files in the source release. * ssh(1), sshd(8): add the sntrup761x25519-sha...@openssh.com hybrid ECDH/x25519 + Streamlined NTRU Prime post-quantum KEX to the default KEXAlgorithms list (after the ECDH methods but before the prime-group DH ones). The next release of OpenSSH is likely to make this key exchange the default method. * ssh-keygen(1): when downloading resident keys from a FIDO token, pass back the user ID that was used when the key was created and append it to the filename the key is written to (if it is not the
[ANNOUNCEMENT] tcsh 6.24.00-1
The following packages have been uploaded to the Cygwin distribution: * tcsh-6.24.00-1 Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax. -- 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
tcsh 6.24.00-1
The following packages have been uploaded to the Cygwin distribution: * tcsh-6.24.00-1 Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax.
[ANNOUNCEMENT] cygwin 3.3.4-2
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.4-2 * cygwin-devel-3.3.4-2 * cygwin-doc-3.3.4-2 This is a replacement for the broken 3.3.4-1 release, which stumbled over an installation glitch in the latest cygport release. IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix a bug in fhandler_dev_clipboard::read() that the second read fails with 'Bad address'. Addresses: https://cygwin.com/pipermail/cygwin/2021-December/250141.html - Convert UNC path prefix back to drive letter in symlink_info::check(). This solves the following issues: Addresses: https://cygwin.com/pipermail/cygwin/2021-November/250087.html https://cygwin.com/pipermail/cygwin/2021-December/250103.html - Fix a bug in pty code that input is wrongly sent to io_handle_nat rather than io_handle while neither read() nor select() is called after the cygwin app is started from non-cygwin app. Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html - Avoid a crash when NtQueryInformationProcess returns invalid handle data. Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html - Ignore INHERIT ACEs when reading the DACL of non-directory files. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250363.html - Fix an "Invalid argument" problem in posix_spawn on i686. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250453.html - Fix handling of records in Cygwin resolver code using native windows calls. Also fix various bugs in the resolver. - Fix a problem creating a dir "foo", if a file (but not a Cygwin symlink) "foo.lnk" already exists. Addresses: https://github.com/msys2/msys2-runtime/issues/81 - Fix double free for archetype, which is caused when open() fails. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250518.html - Fix a permission problem when writing DOS attributes on Samba. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250629.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
cygwin 3.3.4-2
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.4-2 * cygwin-devel-3.3.4-2 * cygwin-doc-3.3.4-2 This is a replacement for the broken 3.3.4-1 release, which stumbled over an installation glitch in the latest cygport release. IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix a bug in fhandler_dev_clipboard::read() that the second read fails with 'Bad address'. Addresses: https://cygwin.com/pipermail/cygwin/2021-December/250141.html - Convert UNC path prefix back to drive letter in symlink_info::check(). This solves the following issues: Addresses: https://cygwin.com/pipermail/cygwin/2021-November/250087.html https://cygwin.com/pipermail/cygwin/2021-December/250103.html - Fix a bug in pty code that input is wrongly sent to io_handle_nat rather than io_handle while neither read() nor select() is called after the cygwin app is started from non-cygwin app. Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html - Avoid a crash when NtQueryInformationProcess returns invalid handle data. Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html - Ignore INHERIT ACEs when reading the DACL of non-directory files. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250363.html - Fix an "Invalid argument" problem in posix_spawn on i686. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250453.html - Fix handling of records in Cygwin resolver code using native windows calls. Also fix various bugs in the resolver. - Fix a problem creating a dir "foo", if a file (but not a Cygwin symlink) "foo.lnk" already exists. Addresses: https://github.com/msys2/msys2-runtime/issues/81 - Fix double free for archetype, which is caused when open() fails. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250518.html - Fix a permission problem when writing DOS attributes on Samba. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250629.html
[ANNOUNCEMENT] cygwin 3.3.4-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.4-1 * cygwin-devel-3.3.4-1 * cygwin-doc-3.3.4-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix a bug in fhandler_dev_clipboard::read() that the second read fails with 'Bad address'. Addresses: https://cygwin.com/pipermail/cygwin/2021-December/250141.html - Convert UNC path prefix back to drive letter in symlink_info::check(). This solves the following issues: Addresses: https://cygwin.com/pipermail/cygwin/2021-November/250087.html https://cygwin.com/pipermail/cygwin/2021-December/250103.html - Fix a bug in pty code that input is wrongly sent to io_handle_nat rather than io_handle while neither read() nor select() is called after the cygwin app is started from non-cygwin app. Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html - Avoid a crash when NtQueryInformationProcess returns invalid handle data. Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html - Ignore INHERIT ACEs when reading the DACL of non-directory files. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250363.html - Fix an "Invalid argument" problem in posix_spawn on i686. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250453.html - Fix handling of records in Cygwin resolver code using native windows calls. Also fix various bugs in the resolver. - Fix a problem creating a dir "foo", if a file (but not a Cygwin symlink) "foo.lnk" already exists. Addresses: https://github.com/msys2/msys2-runtime/issues/81 - Fix double free for archetype, which is caused when open() fails. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250518.html - Fix a permission problem when writing DOS attributes on Samba. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250629.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
cygwin 3.3.4-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.4-1 * cygwin-devel-3.3.4-1 * cygwin-doc-3.3.4-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix a bug in fhandler_dev_clipboard::read() that the second read fails with 'Bad address'. Addresses: https://cygwin.com/pipermail/cygwin/2021-December/250141.html - Convert UNC path prefix back to drive letter in symlink_info::check(). This solves the following issues: Addresses: https://cygwin.com/pipermail/cygwin/2021-November/250087.html https://cygwin.com/pipermail/cygwin/2021-December/250103.html - Fix a bug in pty code that input is wrongly sent to io_handle_nat rather than io_handle while neither read() nor select() is called after the cygwin app is started from non-cygwin app. Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html - Avoid a crash when NtQueryInformationProcess returns invalid handle data. Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html - Ignore INHERIT ACEs when reading the DACL of non-directory files. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250363.html - Fix an "Invalid argument" problem in posix_spawn on i686. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250453.html - Fix handling of records in Cygwin resolver code using native windows calls. Also fix various bugs in the resolver. - Fix a problem creating a dir "foo", if a file (but not a Cygwin symlink) "foo.lnk" already exists. Addresses: https://github.com/msys2/msys2-runtime/issues/81 - Fix double free for archetype, which is caused when open() fails. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250518.html - Fix a permission problem when writing DOS attributes on Samba. Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250629.html
[ANNOUNCEMENT] libfido2 1.10.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.10.0-1 * libfido2-devel-1.10.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. -- 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
libfido2 1.10.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.10.0-1 * libfido2-devel-1.10.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols.
[ANNOUNCEMENT] file 5.41-2
The following packages have been uploaded to the Cygwin distribution: * file-5.41-2 * file-devel-5.41-2 * python3-magic-5.41-2 This update rectifies a wrong dependency to python 3.8 in the 32 bit package and removes the obsolete python2 bindings. --- With file you can obtain information on the file type of a specified file. File type recognition is controlled by the file /usr/share/file/magic which contains the classification criteria. -- 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
file 5.41-2
The following packages have been uploaded to the Cygwin distribution: * file-5.41-2 * file-devel-5.41-2 * python3-magic-5.41-2 This update rectifies a wrong dependency to python 3.8 in the 32 bit package and removes the obsolete python2 bindings. --- With file you can obtain information on the file type of a specified file. File type recognition is controlled by the file /usr/share/file/magic which contains the classification criteria.
[ANNOUNCEMENT] file 5.41-1
The following packages have been uploaded to the Cygwin distribution: * file-5.41-1 * file-devel-5.41-1 * python2-magic-5.41-1 * python3-magic-5.41-1 With file you can obtain information on the file type of a specified file. File type recognition is controlled by the file /usr/share/file/magic which contains the classification criteria. -- 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
file 5.41-1
The following packages have been uploaded to the Cygwin distribution: * file-5.41-1 * file-devel-5.41-1 * python2-magic-5.41-1 * python3-magic-5.41-1 With file you can obtain information on the file type of a specified file. File type recognition is controlled by the file /usr/share/file/magic which contains the classification criteria.
[ANNOUNCEMENT] cygwin 3.3.3-1 [with DEPRECATION NOTES]
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.3-1 * cygwin-devel-3.3.3-1 * cygwin-doc-3.3.3-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix issue that new pipe code doesn't handle size zero pipe which may be created by non-cygwin apps. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249844.html - Make sure that "X:" paths are not handled as absolute DOS paths in fstatat and other ...at calls. "X:/" still is handled as absolute path. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249837.html - Fix showing DLL version info from native Windows tools. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249867.html - Handle Unicode surrogate pairs in console. Cygwin console does not handle surrogate pairs correctly at the moment. Fix issue that running bash in Windows Terminal and inserting an emoji does not work as expected. Addresses: https://github.com/git-for-windows/git/issues/3281 - Fix long-standing problem that fchmod or facl on newly created files screw up the DOS file attributes. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249909.html - Fix issue that pipe read()/write() occasionally returns a garbage length when NtReadFile/NtWriteFile returns STATUS_PENDING in non- blocking mode. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249910.html - Fix two bugs in raise(2). Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249973.html - Fix regression in printf introduced with Cygwin 3.3.2. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249930.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
cygwin 3.3.3-1 [with DEPRECATION NOTES]
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.3-1 * cygwin-devel-3.3.3-1 * cygwin-doc-3.3.3-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.3 is the LAST major version supporting - Windows Vista - Windows Server 2008 - Cygwin 3.3 is the LAST major version supporting 32 bit installations. If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider to move to a real 64 bit Cygwin installation in the next couple of months. If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on ARM64, don't be alarmed. The current installations including all Cygwin 3.3.x versions will continue to run on your system. You just wont get any more updates starting with Cygwin 3.4.0. - Cygwin 3.4, which will probably be release at some point in 2022, will be the LAST version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == Bug Fixes - - Fix issue that new pipe code doesn't handle size zero pipe which may be created by non-cygwin apps. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249844.html - Make sure that "X:" paths are not handled as absolute DOS paths in fstatat and other ...at calls. "X:/" still is handled as absolute path. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249837.html - Fix showing DLL version info from native Windows tools. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249867.html - Handle Unicode surrogate pairs in console. Cygwin console does not handle surrogate pairs correctly at the moment. Fix issue that running bash in Windows Terminal and inserting an emoji does not work as expected. Addresses: https://github.com/git-for-windows/git/issues/3281 - Fix long-standing problem that fchmod or facl on newly created files screw up the DOS file attributes. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249909.html - Fix issue that pipe read()/write() occasionally returns a garbage length when NtReadFile/NtWriteFile returns STATUS_PENDING in non- blocking mode. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249910.html - Fix two bugs in raise(2). Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249973.html - Fix regression in printf introduced with Cygwin 3.3.2. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249930.html
[ANNOUNCEMENT] cygwin 3.3.3-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.3-1 * cygwin-devel-3.3.3-1 * cygwin-doc-3.3.3-1 Bug Fixes - - Fix issue that new pipe code doesn't handle size zero pipe which may be created by non-cygwin apps. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249844.html - Make sure that "X:" paths are not handled as absolute DOS paths in fstatat and other ...at calls. "X:/" still is handled as absolute path. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249837.html - Fix showing DLL version info from native Windows tools. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249867.html - Handle Unicode surrogate pairs in console. Cygwin console does not handle surrogate pairs correctly at the moment. Fix issue that running bash in Windows Terminal and inserting an emoji does not work as expected. Addresses: https://github.com/git-for-windows/git/issues/3281 - Fix long-standing problem that fchmod or facl on newly created files screw up the DOS file attributes. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249909.html - Fix issue that pipe read()/write() occasionally returns a garbage length when NtReadFile/NtWriteFile returns STATUS_PENDING in non- blocking mode. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249910.html - Fix two bugs in raise(2). Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249973.html - Fix regression in printf introduced with Cygwin 3.3.2. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249930.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
cygwin 3.3.3-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.3.3-1 * cygwin-devel-3.3.3-1 * cygwin-doc-3.3.3-1 Bug Fixes - - Fix issue that new pipe code doesn't handle size zero pipe which may be created by non-cygwin apps. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249844.html - Make sure that "X:" paths are not handled as absolute DOS paths in fstatat and other ...at calls. "X:/" still is handled as absolute path. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249837.html - Fix showing DLL version info from native Windows tools. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249867.html - Handle Unicode surrogate pairs in console. Cygwin console does not handle surrogate pairs correctly at the moment. Fix issue that running bash in Windows Terminal and inserting an emoji does not work as expected. Addresses: https://github.com/git-for-windows/git/issues/3281 - Fix long-standing problem that fchmod or facl on newly created files screw up the DOS file attributes. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249909.html - Fix issue that pipe read()/write() occasionally returns a garbage length when NtReadFile/NtWriteFile returns STATUS_PENDING in non- blocking mode. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249910.html - Fix two bugs in raise(2). Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249973.html - Fix regression in printf introduced with Cygwin 3.3.2. Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249930.html
Re: autoconf
On Dec 2 14:18, ASSI wrote: > Jan Nijtmans via Cygwin-apps writes: > > My 2c : Cygwin should - at least - allow people to install autoconf-2.71 > > and - as long as the packages are prepared for it - things shouldn't break. > > As I said, I haven't looked at it in any detail, but it seems that > autoconf is already multi-version, so I guess it would be possible to > introduce an autoconf2.7 package in addition to the existing two. > That's a slightly wonky way to do that when we expect to later on just > replace 2.69 with 2.71, though. Don't do that. https://lwn.net/Articles/839395/ autoconf 2.70 and later are new, backward incompatible versions, so they should go into a new-and-shiny-and-not-yet-existing autoconf2.7 package. Corinna
Re: vboxsharedfs - Too many levels of symbolic links
On Nov 30 19:04, Oskar Skog wrote: > vboxsharedfs file systems no longer work. Any attempt to access will > result in "too many levels of symbolic links". > > This only affects the VirtualBox shared folder, the Samba share works > just fine. > > Last time I updated (before today) was sometime before the 10th of > September. > > MSYS2 has the same problem, but no one seems to have reported it to > Cygwin: > https://github.com/msys2/msys2-runtime/issues/58 > > > user@DESKTOP-*** ~$ ls /cygdrive/z > ls: cannot access '/cygdrive/z': Too many levels of symbolic links > user@DESKTOP-*** ~$ mount > C:/Cygwin/bin on /usr/bin type ntfs (binary,auto) > C:/Cygwin/lib on /usr/lib type ntfs (binary,auto) > C:/Cygwin on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) > Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) > Z: on /cygdrive/z type vboxsharedfolderfs > (binary,posix=0,user,noumount,auto) > user@DESKTOP-*** ~$ uname -a > CYGWIN_NT-10.0 DESKTOP-* 3.3.2(0.341/5/3) 2021-11-08 16:55 x86_64 Cygwin Somebody will have to debug this. From the MSYS issue it looks like the GetFinalPathNameByHandleW call results in some trouble, but the MSYS guys rather just disable code instead of trying to debug it and fixing the cause. "Somebody" would have to be somebody who can reproduce the issue. I'm neither using VirtualBox, nor AFS. I probably could test this if somebody gives me temporary access to an existing AFS FS somewhere, plus a short description how to connect. I guess it starts with "Install latest OpenAFS version x.y for Windows"... Corinna -- 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: autoconf
On Dec 2 11:15, Jan Nijtmans via Cygwin-apps wrote:
> Op do 2 dec. 2021 om 10:22 schreef Corinna Vinschen via Cygwin-apps:
Nope, I didn't. Make that:
On Dec 2 08:23, ASSI wrote:
> > > Most distros still package 2.69 or even earlier and that includes some
> > > substantial rolling release distros. As long as these guys don't use
> > > the newer version it seems unlikely that we would actually need it, plus
> > > I don't see us spending time and effort debugging things that aren't
> > > even Cygwin specific.
>
> My 2c : Cygwin should - at least - allow people to install autoconf-2.71
> and - as long as the packages are prepared for it - things shouldn't break.
>
> If I install autoconf-2.71 locally, and then compile Tcl 8.6.12, which
> contained in tcl.cygport:
> src_compile() {
> cd ${S}/unix
> cygautoreconf
> ...
>
> $ cygport tcl.cygport compile
> >>> Compiling tcl-8.6.12-1.x86_64
> *** ERROR: autoconf2.5 is required to build this package
>
>
> My solution was, simply to remove the "cygautoreconf" line from the
> cygport file, then it works again.
>
> Somewhere in cygport, a check is done for the autoconf version, please
> change this check to allow autoconf 2.71 (as well as 2.59 and 2.69).
> Then I can put back the "cygautoreconf" line in tcl.cygport.
>
> Thanks!
> Jan Nijtmans
Re: autoconf
On Dec 2 08:23, ASSI wrote: > Brian Inglis writes: > >> How likely is it that they actually rely on that version already? > > > > Somewhat likely for some GNU packages and gnulib macros that specify > > version prereqs: AC_PREREQ is used in 80 packages I have sources for. > > Most distros still package 2.69 or even earlier and that includes some > substantial rolling release distros. As long as these guys don't use > the newer version it seems unlikely that we would actually need it, plus > I don't see us spending time and effort debugging things that aren't > even Cygwin specific. > > > After that version released in January, I've only had to patch one > > package so far, which specified it in August, and they later reduced > > it after discussion with distro package maintainers: > > > > $ grep 'AC_PREREQ(\[2\.[0-9]\+\])' */*.patch > > bison/bison-3.7.90-revert-autoconf-upgrade.patch:-AC_PREREQ([2.71]) > > bison/bison-3.7.90-revert-autoconf-upgrade.patch:+AC_PREREQ([2.68]) > > wget2/configure-ac.upstream.patch:-AC_PREREQ([2.67]) > > wget2/configure-ac.upstream.patch:+AC_PREREQ([2.69]) > > Xcurses/x11-aclocal-m4-libtoolize.patch:+[AC_PREREQ([2.62])dnl We use > > AC_PATH_PROGS_FEATURE_CHECK > > That's called "jumping the gun" I think. The distro package maintainers > will be in their ears immediately and we can just sit back with the > popcorn. gawk has moved to AC_PREREQ([2.71]) and the maintainer does not want to go back. I had to patch that already for Cygwin's gawk 5.1.1-1. Corinna
Re: No cancel mode for setup.exe
Hi Thorsten, On Nov 29 15:23, Fuchs, Thorsten via Cygwin wrote: > Hi, > > We are using the setup-x86_64.exe within our deployment system to > install Cygwin at the developer workstations. The setup run is > triggered automatically and all developer workstation going to be > install identically. However, when the setup window is open and the > install is in progress it is possible for the user to cancel it. > Sometimes developers interrupt the process. Would be good if this can > be avoided. When you automate the setup call, can't you also ask the automation to run the process in a hidden window? That would probably already avoid a lot of uninformed interruption... Corinna -- 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: [ATTN MAINTAINER] openssh
On Nov 28 10:53, Achim Gratz wrote: > Achim Gratz writes: > > These patches work for 32bit also and I believe they are correct, but > > that build should not be made available due to a bug in libfido2 that > > crashes when trying to free the memory associated with the WebAuthn > > payload returned. Without these patches applied you can still use the > > fallback to USB-HID when you are an administrator. > > The call into WebAuthn completely messes up the stack apparently. The > returned object looks OK once you realize it is a version 1 and thus the > extension fields are bogus, but the whole thing crashes if you do just > one more call. Gdb session: > > https://paste.c-net.org/SerumLoser > > Any ideas what that might be? For the bystanders, on a hunch I created a libfido2 patch to change the calling convention for the dynamically loaded windows functions. Let's see if Achim's testing now succeeds on 32 bit... Corinna
Re: raise(-1) has stopped returning an error recently
On Nov 27 10:43, Duncan Roe wrote: > On Wed, Nov 24, 2021 at 10:25:46AM +0100, cygwin wrote: [...] > > > > What is that "permanent restriction" in Cygwin? Is that something we > > could fix or something unfixable? Did you try to debug Cygwin in terms > > of that problem? If not, could you extract a reduced, very simple > > stand-alone testcase for further debugging? > > > The restriction is in grep/gnulib source. From > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27555#5 > > >> I've determined the cause, at least. The sole caller of mbstoupper > >> (which contained the relevant __CYGWIN__-specific > >> surrogate-pair-handling code) was removed by the improvements of > >> v2.21-63-g8a33cde, and not long after, I noticed that mbstoupper was > >> no longer used, so removed it altogether. > > I submitted a patch to save anyone else wasting time over this. So please > don't > you, Great, thanks! Corinna -- 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: raise(-1) has stopped returning an error recently
On Nov 24 11:01, Brian Inglis via Cygwin wrote: > On 2021-11-24 02:25, Corinna Vinschen via Cygwin wrote: > > > On Tue, Nov 23, 2021 at 11:18:25AM -0700, Brian Inglis wrote: > > > > Do Cygwin and/or Windows support surrogate pairs in UTF-8? > > > > You mean UTF-16. UTF-8 doesn't know surrogate pairs, UTF-16 does. > > Originally there was UCS-2, 16 bits, with only 65536 code points. > > However, Unicode left the BMP already with version 2.0 in 1996, so > > UTF-16 and surrogate pairs became necessary. Windows as well as Cygwin > > support them. > > How does Cygwin support UTF-16 locales with surrogate pairs? UTF-16 locales? There's no such thing. UTF-16 is just the 16 bit representation for Unicode, and as such, is independent of the locale. On the user side, Cygwin only supports UTF-8 as Unicode representation. Internally you can then convert them to wchar_t which is UTF-16. > Are they the "native" locales inherited from Windows if others are not > specified e.g. UTF-8, some OEM SBCS or MBCS? Just try `locale -av' and you'll see all supported locales and their respective default codeset. All of them can be used with .utf8 specifier to use UTF-8 instead of the default codeset. Some of them use UTF-8 as default codeset anyway, e. g., fa_IR or yo_NG. > > > There are 3 tests in surrogate-pair and only the 3rd one failed. So I > > > guess > > > surrogate pairs in UTF-8 "mostly work". > > > > UTF-16. The surrogate stuff is evil at times. Have a look at the > > __utf8_wctomb function in > > https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/wctomb_r.c > > Lone surrogate halfs in an input stream are a problem, for instance. > > Thus the confusion with grep surrogate pair tests which appear to be running > under a UTF-8 locale: see attached surrogate pair extract from cygport > --debug grep.cygport check. An STC in plain C might be helpful. Corinna -- 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: possible snprintf() regression in 3.3.2
On Nov 25 21:02, Takashi Yano via Cygwin wrote: > On Wed, 24 Nov 2021 10:28:13 +0100 > Corinna Vinschen wrote: > > On Nov 24 18:14, Takashi Yano via Cygwin wrote: > > > On Wed, 24 Nov 2021 17:52:04 +0900 > > > Takashi Yano wrote: > > > > The printed value is still something wrong... > > > > sqrt(2)*1e70 should be an integer value. > > > > > > I mean... > > > > > > sqrt(2)*1e70 is actually not an integer, however, double has mantissa > > > of only 52 bit. So, (double value)*(5^70*2^70) should be an integer. > > > > The conversion is a bit inexact, I guess, but that's another problem > > of this old ldto, right? > > I looked into this problem and found that: > > This problem is in principle unavoidable with current algorithms. > This is because the current algorithm uses a value of 10^n for > the conversion. When n>62, the value does not fit into the 144 > bits of the mantissa part of the internal representation in ldtoa. > This degrades the precision. Thanks for checking. Corinna -- 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: possible snprintf() regression in 3.3.2
On Nov 24 18:14, Takashi Yano via Cygwin wrote: > On Wed, 24 Nov 2021 17:52:04 +0900 > Takashi Yano wrote: > > The printed value is still something wrong... > > sqrt(2)*1e70 should be an integer value. > > I mean... > > sqrt(2)*1e70 is actually not an integer, however, double has mantissa > of only 52 bit. So, (double value)*(5^70*2^70) should be an integer. The conversion is a bit inexact, I guess, but that's another problem of this old ldto, right? Corinna -- 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: raise(-1) has stopped returning an error recently
On Nov 24 09:36, Duncan Roe wrote: > On Tue, Nov 23, 2021 at 11:18:25AM -0700, Brian Inglis wrote: > > > On Nov 23 19:27, Duncan Roe wrote: > > > > Btw to whoever maintains grep for cygwin: 'make check' should pass on > > > > next release (I patched out the surrogate-pair failre). > > > > I had no problems with test-raise last release. > > I don't remember having a problem with it even a few weeks ago. > > > I did with surrogate pairs but after spending too much time on all the test > > infrastructure around that, decided it was a low probability event, and wait > > until anyone complains to refer it upstream. > > I wasted time on that too. That's why I patched surrogate-pair to not do its > 3rd > test if 'uname -s' indicates Cygwin. > > For the full story, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27555#5 What is that "permanent restriction" in Cygwin? Is that something we could fix or something unfixable? Did you try to debug Cygwin in terms of that problem? If not, could you extract a reduced, very simple stand-alone testcase for further debugging? > > Do Cygwin and/or Windows support surrogate pairs in UTF-8? You mean UTF-16. UTF-8 doesn't know surrogate pairs, UTF-16 does. Originally there was UCS-2, 16 bits, with only 65536 code points. However, Unicode left the BMP already with version 2.0 in 1996, so UTF-16 and surrogate pairs became necessary. Windows as well as Cygwin support them. > There are 3 tests in surrogate-pair and only the 3rd one failed. So I guess > surrogate pairs in UTF-8 "mostly work". UTF-16. The surrogate stuff is evil at times. Have a look at the __utf8_wctomb function in https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/wctomb_r.c Lone surrogate halfs in an input stream are a problem, for instance. Corinna -- 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: possible snprintf() regression in 3.3.2
On Nov 24 12:40, Takashi Yano via Cygwin wrote:
> On Tue, 23 Nov 2021 10:48:21 +0100
> Corinna Vinschen wrote:
> > On Nov 23 17:34, Takashi Yano via Cygwin wrote:
> > > However, in reality, for example in the case:
> > > snprintf(buf, sizeof(buf), "%.3f", 1234567890123456.789);
> > > 'ndigits' is only 3 even though total digits will be 20.
> > >
> > > So, Tony thinks current code does not correct.
> > >
> > > However, I think something is wrong with interpretation
> > > of 'ndigits' in dltoa.c.
> > >
> > > printf("%.3f\n", sqrt(2)*1e70);
> > > printf("%.50f\n", sqrt(2)*1e70);
> > >
> > > outputs
> > >
> > > 14142135623730951759073108307330633613786387000.000
> > > 14142135623730951759073108307330633613786386978891021459448717416650727.1340279888758223149296720949629080194006476078
> > >
> > > Is this as intended?
> >
> > On Linux I see
> >
> > 14142135623730951759073108307330633613786387161811679011529922516615168.000
> > 14142135623730951759073108307330633613786387161811679011529922516615168.00
> >
> > The newlib output for .3f probably suffers from the fact that ldtoa
> > chooses the small buffer, which restricts the number of digits to 43 or
> > 44. But keep in mind that ldtoa *always* restricted the output to 42,
> > so you never got a more precise output anyway. Every digit beyond digit
> > 42 is only printed due to the bigger buffer sizes.
> >
> > So, what newlib and, in extension, Cygwin really needs at this point are
> > patches to the existing ldtoa or a change to gdtoa or equivalent.
> >
> > https://cygwin.com/acronyms/#SHTDI
> > https://cygwin.com/acronyms/#PTC
>
> The attached patch is the one which I think correct so far.
>
> With this patch:
>
> 14142135623730951759073108307330633613786386978891021459448717416650727.134
> 14142135623730951759073108307330633613786386978891021459448717416650727.1340279888758223149296720949629080194006476078
>
> Isn't this better than current behaviour?
LGTM, thanks! Can you send this as patch to the newlib ML, please?
Thanks,
Corinna
--
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: raise(-1) has stopped returning an error recently
On Nov 23 19:27, Duncan Roe wrote:
> On Mon, Nov 22, 2021 at 02:06:19PM +0100, cygwin wrote:
> > On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
> > > On Nov 22 16:20, Duncan Roe wrote:
> > > > #include
> > > > #include
> > > >
> > > > int
> > > > main (void)
> > > > {
> > > > int retcod;
> > > >
> > > > retcod = raise (-1);
> > > > printf("raise(-1) returned %d\n", retcod);
> > > > }
> > >
> > > Thanks for the STC. There are actually two long-standing problems,
> > > one in raise, calling pthread_kill even for non-threaded processes,
> > > one in pthread_kill, not checking the signal number.
> > >
> > > I'll patch them right away.
> >
> > I created a patchset:
> > https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=d54d8f173d66
> > https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=24b63eb7
> > https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=afb7c557d2af
> >
> > Please test the latest developer snapshot from http://cygwin.com/snapshots/
>
> Thanks, that fixed it.
Thanks for testing.
> Btw to whoever maintains grep for cygwin: 'make check' should pass on
> next release (I patched out the surrogate-pair failre).
Great! Brian?
Thanks,
Corinna
--
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: possible snprintf() regression in 3.3.2
On Nov 23 17:34, Takashi Yano via Cygwin wrote:
> On Tue, 23 Nov 2021 10:23:02 +1100
> Tony Cook wrote:
> > On Mon, Nov 22, 2021 at 02:04:06PM +0100, Corinna Vinschen via Cygwin wrote:
> > > On Nov 22 11:34, Corinna Vinschen via Cygwin wrote:
> > > > On Nov 21 11:16, Tony Cook wrote:
> > > > > A simple option would be to use an small auto fixed buffer for most
> > > > > conversions, but use malloc() for %f formats for numbers greater in
> > > > > magnitude than some limit, though it would also need to be adjusted
> > > > > for the precision (ndigits here), since they take extra space.
> > > > >
> > > > > This would avoid using the optional-to-implement VLA feature too.
> > > >
> > > > Good idea. I guess I create a simple fix doing just that.
> > >
> > > I created a patch:
> > > https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=68faeef4be71
> > I don't think this solves the fundamental problem.
> >
> > Simply looking at ndigits isn't enough for %f.
> >
> > For %f with a large number (like 9e99), the buffer size required is
> > ndigits plus (roughly) log10(n), which we can further estimate
> > with log2(n)*146/485 (log2(10) is 3.32 ~== 485/146)
> >
> > I think something more like:
> >
> > size_t outsize;
> > if (mode == 3) {/* %f */
> > int expon = (e[NI-1] & 0x7fff) - (EXONE - 1); /* exponent part of float
> > */
> > /* log2(10) approximately 485/146 */
> > outsize = expon * 146 / 485 + ndigits + 10;
> > }
> > else { /* %g/%e */
> > outsize = ndigits + MAX_EXP_DIGITS + 10;
> > }
> > if (outsize > NDEC_SML) {
> > outbuf = (char *)_malloc_r(ptr, outsize);
> > }
> >
> > You'll probably need to pass outsize into etoasc() rather than
> > calculating it.
> >
> > See https://github.com/Perl/perl5/blob/blead/sv.c#L13295 for code in
> > perl that calculates the buffer size needed for %f (precis aka ndigits
> > is added at line 13385).
>
> I guess Corinna thinks that 'ndigits' keeps the total number
> of digits to be printed.
No, I don't. It's the requested decimal precision.
However, the fun fact is that ldtoa in newlib is more than 20 years old,
with only minor changes in 2003. My patches don't change the basic
mechanism of ldtoa. I just don't have enough knowledge of floating
point arithmetic to do that. My patches only try to raise the number of
*possible* digits by raising the matching macro and raising the size of
the single, local digit buffer accordingly.
If the above crashed, then probably because the buffer was too small.
That should be fixed now, because the second patch fixes the buffer size
and the computation based on the buffer size. If that's not the
problem, then, in theory, the same would have occured with the old code.
If my patches are inadequate, we can revert the patches and then the
precision will be restricted to 42 digits again, as before, see the
thread https://sourceware.org/pipermail/newlib/2021/018626.html
For everything else, we either need somebody who knows how to change the
current ldtoa to "do the right thing", whatever that is, or somebody who
takes a stab at replacing ldtoa with another, better alternative.
> However, in reality, for example in the case:
> snprintf(buf, sizeof(buf), "%.3f", 1234567890123456.789);
> 'ndigits' is only 3 even though total digits will be 20.
>
> So, Tony thinks current code does not correct.
>
> However, I think something is wrong with interpretation
> of 'ndigits' in dltoa.c.
>
> printf("%.3f\n", sqrt(2)*1e70);
> printf("%.50f\n", sqrt(2)*1e70);
>
> outputs
>
> 14142135623730951759073108307330633613786387000.000
> 14142135623730951759073108307330633613786386978891021459448717416650727.1340279888758223149296720949629080194006476078
>
> Is this as intended?
On Linux I see
14142135623730951759073108307330633613786387161811679011529922516615168.000
14142135623730951759073108307330633613786387161811679011529922516615168.00
The newlib output for .3f probably suffers from the fact that ldtoa
chooses the small buffer, which restricts the number of digits to 43 or
44. But keep in mind that ldtoa *always* restricted the output to 42,
so you never got a more precise output anyway. Every digit beyond digit
42 is only printed due to the bigger buffer sizes.
So, what newlib and, in extension, Cygwin really needs at this point are
patches to the existing ldtoa or a change to gdtoa or equivalent.
https://cygwin.com/acronyms/#SHTDI
https://cygwin.com/acronyms/#PTC
Corinna
--
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: ssmtp-config fails on step 6
On Nov 22 19:04, Achim Gratz wrote: > Corinna Vinschen via Cygwin writes: > > In fact, Windows symlinks can easily be created as dangling symlinks > > as well. Try cmd's `mklink foo bar' with non-existent bar in developer > > mode or an elevated shell. > > However you need to tell it if that name points to a directory or a > file, it cannot change afterwards on the fly. Yes, but only Explorer actually cares. Nevertheless, it's one of the most annoying Windows "features" since Vista. Corinna -- 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: raise(-1) has stopped returning an error recently
On Nov 22 11:25, Corinna Vinschen via Cygwin wrote:
> On Nov 22 16:20, Duncan Roe wrote:
> > Hi,
> >
> > I stumbled across this when running 'make check' in the grep source
> > directory.
> >
> > test-raise failed when it didn't a few weeks ago.
>
> Pretty unlikely. This code didn;'t change for ages. I just checked
> against Cygwin 3.2.0 and it also returns success.
>
> > #include
> > #include
> >
> > int
> > main (void)
> > {
> > int retcod;
> >
> > retcod = raise (-1);
> > printf("raise(-1) returned %d\n", retcod);
> > }
>
> Thanks for the STC. There are actually two long-standing problems,
> one in raise, calling pthread_kill even for non-threaded processes,
> one in pthread_kill, not checking the signal number.
>
> I'll patch them right away.
I created a patchset:
https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=d54d8f173d66
https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=24b63eb7
https://sourceware.org/git?p=newlib-cygwin.git;a=commitdiff;h=afb7c557d2af
Please test the latest developer snapshot from http://cygwin.com/snapshots/
Thanks,
Corinna
--
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: possible snprintf() regression in 3.3.2
On Nov 22 11:34, Corinna Vinschen via Cygwin wrote: > On Nov 21 11:16, Tony Cook wrote: > > On Thu, Nov 18, 2021 at 09:08:40PM +, Sam Edge via Cygwin wrote: > > > I use newlib on embedded with threading libs that have predetermined > > > fixed thread stack sizes. While we tend to have more RAM than in former > > > times we also have multiple thread stacks. Use of alloca() or variable > > > length automatic arrays makes me wince especially in code I might not be > > > able to avoid calling which is often the case with XXXprintf() in > > > third-party libraries' debug output. I'd usually rather take the > > > performance hit from using heap instead of having to make all my stacks > > > bigger. > > > > A simple option would be to use an small auto fixed buffer for most > > conversions, but use malloc() for %f formats for numbers greater in > > magnitude than some limit, though it would also need to be adjusted > > for the precision (ndigits here), since they take extra space. > > > > This would avoid using the optional-to-implement VLA feature too. > > Good idea. I guess I create a simple fix doing just that. I created a patch: https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=68faeef4be71 Please test the latest developer snapshot from http://cygwin.com/snapshots/ Thanks, Corinna -- 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: possible snprintf() regression in 3.3.2
On Nov 21 11:16, Tony Cook wrote: > On Thu, Nov 18, 2021 at 09:08:40PM +, Sam Edge via Cygwin wrote: > > I use newlib on embedded with threading libs that have predetermined > > fixed thread stack sizes. While we tend to have more RAM than in former > > times we also have multiple thread stacks. Use of alloca() or variable > > length automatic arrays makes me wince especially in code I might not be > > able to avoid calling which is often the case with XXXprintf() in > > third-party libraries' debug output. I'd usually rather take the > > performance hit from using heap instead of having to make all my stacks > > bigger. > > A simple option would be to use an small auto fixed buffer for most > conversions, but use malloc() for %f formats for numbers greater in > magnitude than some limit, though it would also need to be adjusted > for the precision (ndigits here), since they take extra space. > > This would avoid using the optional-to-implement VLA feature too. Good idea. I guess I create a simple fix doing just that. Thanks, Corinna -- 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: ssmtp-config fails on step 6
On Nov 20 17:26, Ken Brown via Cygwin wrote: > On 11/19/2021 7:07 PM, Andrey Repin via Cygwin wrote: > > alternatives is known to make links to nonexistent objects. While this is > > possible on *NIX, you can only link to existing objects on Windows. > > You're talking about native Windows symlinks, not Cygwin symlinks. The > latter can point to nonexistent objects just as on *NIX. In fact, Windows symlinks can easily be created as dangling symlinks as well. Try cmd's `mklink foo bar' with non-existent bar in developer mode or an elevated shell. Corinna -- 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: raise(-1) has stopped returning an error recently
On Nov 22 16:20, Duncan Roe wrote:
> Hi,
>
> I stumbled across this when running 'make check' in the grep source directory.
>
> test-raise failed when it didn't a few weeks ago.
Pretty unlikely. This code didn;'t change for ages. I just checked
against Cygwin 3.2.0 and it also returns success.
> #include
> #include
>
> int
> main (void)
> {
> int retcod;
>
> retcod = raise (-1);
> printf("raise(-1) returned %d\n", retcod);
> }
Thanks for the STC. There are actually two long-standing problems,
one in raise, calling pthread_kill even for non-threaded processes,
one in pthread_kill, not checking the signal number.
I'll patch them right away.
Thanks,
Corinna
--
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: possible snprintf() regression in 3.3.2
On Nov 18 16:11, Noel Grandin via Cygwin wrote: > > > On 2021/11/18 3:19 pm, Corinna Vinschen via Cygwin wrote: > > My patch raised NDEC from 43 to 1023 to allow aproximately the same > > number of digits as glibc. Newlib strives to support embedded targets > > and bare metal. Some of them are lucky if they have a stack size of 1K. > > The outbuf buffer is created on the stack, so I used ndigits to save > > stack space. > > > > While that patch fixes the reported problem, it will make users of > > smaller-than-Cygwin targets pretty unhappy. > > > > A workaround would be to malloc outbuf instead. Given that printf > > printf is often performance sensitive, and using malloc there would likely be > significantly slower. > > Possibly use alloca() to allocate only the necessary amount on stack? That's kind of what the current code does. But that's apparently the problem. The necessary amount is only known to the current algorithm while populating outbuf already. So before my patch, outbuf had a constant size, but it was size restricted. > Seems unlikely that embedded systems would be printing values that needed > such large space anyway. Perhaps that's a workaround: Use a constant buffer size, but use NDEC = 1023 only on Cygwin for the time being, something like NDEC = 64 otherwise... Corinna -- 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: possible snprintf() regression in 3.3.2
On Nov 18 20:35, Takashi Yano via Cygwin wrote: > On Thu, 18 Nov 2021 11:06:49 +1100 > Tony Cook wrote: > > On Wed, Nov 17, 2021 at 01:27:55PM +0100, Corinna Vinschen via Cygwin wrote: > > > I don't have a good solution. The old ldtoa code is lacking, for > > > switching newlib to gdtoa I simply don't have the time. On the newlib > > > list was a short discussion starting at > > > https://sourceware.org/pipermail/newlib/2021/018626.html but nothing > > > came out of it yet. > > > > > > Patches gratefully accepted (except just reverting the above change). > > > > From what I can tell the problem has nothing to do with the extra > > precision, but has to do with misusing ndigits for the buffer size > > with a %f format string, leading to a buffer overflow. > > > > At entry to _ldtoa_r() ndigits is 9, but for a %f format with a large > > number the number of digits is more closely related to the magnitude > > of the number, not ndigits. > > > > With the input number (9e99) and the supplied format I'd expect 109 > > characters output, but outbuf is only: > > > >ndigits + MAX_EXP_DIGITS + 10 = 9 + 5 + 10 = 24 > > > > characters in length. > > Then, isn't the following the right thing? > > diff --git a/newlib/libc/stdlib/ldtoa.c b/newlib/libc/stdlib/ldtoa.c > index 7da61457b..826a1b2ed 100644 > --- a/newlib/libc/stdlib/ldtoa.c > +++ b/newlib/libc/stdlib/ldtoa.c > @@ -2794,6 +2794,7 @@ _ldtoa_r (struct _reent *ptr, long double d, int mode, > int ndigits, >LDPARMS rnd; >LDPARMS *ldp = >char *outstr; > + char outbuf[NDEC + MAX_EXP_DIGITS + 10]; >union uconv du; >du.d = d; > > @@ -2840,8 +2841,6 @@ _ldtoa_r (struct _reent *ptr, long double d, int mode, > int ndigits, >if (ndigits > NDEC) > ndigits = NDEC; > > - char outbuf[ndigits + MAX_EXP_DIGITS + 10]; > - >etoasc (e, outbuf, ndigits, mode, ldp); >s = outbuf; >if (eisinf (e) || eisnan (e)) Ouch. My patch raised NDEC from 43 to 1023 to allow aproximately the same number of digits as glibc. Newlib strives to support embedded targets and bare metal. Some of them are lucky if they have a stack size of 1K. The outbuf buffer is created on the stack, so I used ndigits to save stack space. While that patch fixes the reported problem, it will make users of smaller-than-Cygwin targets pretty unhappy. A workaround would be to malloc outbuf instead. Given that printf doesn't work without malloc anyway, that might be a working workaround, until somebody takes heart and provides newlib with a new ldtoa solution. Either way, this discussion should better take place on the newlib mailing list, given the embedded stakeholders on this list, ideally as reply to https://sourceware.org/pipermail/newlib/2021/018626.html If push comes to shove, we probably have to revert my patch for the time being, I guess. Thanks, Corinna -- 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: Misbehaviour of cygpath -am between versions 3.1.4 and 3.3.2
On Nov 17 19:44, Andrey Repin via Cygwin wrote: > Greetings, Wolfgang S. Kechel! > > > The command 'cygpath -am .' yields different results between > > cygwin-3.1.4-1 and cygwin-3.3.2-1 on a Windows 10 box when the current > > directory is a network share. > > > Example with V3.1.4: > > > cygpath -am . ---> P:/mytool/gbuild/wintel/libtiff > > > Example with V3.3.2-1 > > > cygpath -am . ---> //mynas.mydomain.de/product/mytool/gbuild/wintel/libtiff > > I'm pretty sure there was a discussion about it earlier. > > > This causes UNC filenames to appear and this cmd.exe is unable to start > > in those directories when started from a cygwin shell or from nmake run > > in a cygwin shell. > > cmd.exe can be configured to STFU. Apparently default starting with Windows 11... Corinna -- 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] libcbor 0.9.0-3
The following packages have been uploaded to the Cygwin distribution: * libcbor-0.9.0-3 * libcbor-devel-0.9.0-3 Rebuild, removing the DLLs and just providing a library for static linking. libcbor is a C library for parsing and generating CBOR. -- 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
libcbor 0.9.0-3
The following packages have been uploaded to the Cygwin distribution: * libcbor-0.9.0-3 * libcbor-devel-0.9.0-3 Rebuild, removing the DLLs and just providing a library for static linking. libcbor is a C library for parsing and generating CBOR.
[ANNOUNCEMENT] libfido2 1.9.0-2
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.9.0-2 * libfido2-devel-1.9.0-2 This is a rebuild, statically linked against libcbor, to avoid problems with missing binary compatibility between libcbor 0.X versions. libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. -- 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
libfido2 1.9.0-2
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.9.0-2 * libfido2-devel-1.9.0-2 This is a rebuild, statically linked against libcbor, to avoid problems with missing binary compatibility between libcbor 0.X versions. libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols.
Re: libfido2’s dependency on libcbor is dropped in setup.ini
On Nov 17 11:57, ggl329 via Cygwin wrote: > cygfido2-1.dll (from libfido2-1.9.0-1) depends on cygcbor-0.8.dll . > But the dependency is dropped in setup.ini (depends2 field). > In addition, the current libcbor-0.9.0-2 doesn’t provide cygcbor-0.8.dll but > cygcbor-0.9.dll . > Maybe, libfido2 needs to be rebuilt with libcbor-0.9 . libcbor is closely knit to libfido2 and there's fortunately no other package in the distro yet relying on libcbor. Given that the 0.X releases are not binary compatible with each other (which hopefully changes with the 1.X releases), I will change libcbor to a static library only for the time being, and rebuild libfido2 against that static lib. Thanks, Corinna -- 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: possible snprintf() regression in 3.3.2
On Nov 17 18:21, Takashi Yano via Cygwin wrote: > On Wed, 17 Nov 2021 11:37:18 +1100 > Tony Cook wrote: > > This came up from regression testing perl. > > > > Regression testing of perl @4a1b9dd524007193213d3919d6a331109608b90c > > used (from uname): > > [...] > I found the caused by the commit: > commit 4d90e5335914551862831de3e02f6c102b78435b > Author: Corinna Vinschen > Date: Thu Nov 4 11:30:44 2021 +0100 > > ldtoa: fix dropping too many digits from output > > ldtoa cuts the number of digits it returns based on a computation of > number of supported bits (144) divide by log10(2). Not only is the > integer approximation of log10(2) ~= 8/27 missing a digit here, it > also fails to take really small double and long double values into > account. > > Allow for the full potential precision of long double values. At the > same time, change the local string array allocation to request only as > much bytes as necessary to support the caller-requested number of > digits, to keep the stack size low on small targets. > > In the long run a better fix would be to switch to gdtoa, as the BSD > variants, as well as Mingw64 do. > > Signed-off-by: Corinna Vinschen > > Reverting this commit solves the problem. > > Corinna, could you please have a look? I don't have a good solution. The old ldtoa code is lacking, for switching newlib to gdtoa I simply don't have the time. On the newlib list was a short discussion starting at https://sourceware.org/pipermail/newlib/2021/018626.html but nothing came out of it yet. Patches gratefully accepted (except just reverting the above change). Corinna -- 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: Editing with vim clears Windows 10 file system archive bit.
On Nov 15 14:18, Gary Johnson wrote: > On 2021-11-15, Corinna Vinschen via Cygwin wrote: > > Changing that is actually pretty simple, just set FILE_ATTRIBUTE_ARCHIVE > > as soon as the underlying NtCreateFile is called for an open(O_CREAT). > > > > Fixed in current git. > > I had thought that this might be a bug in Vim, so did a git bisect > to find the offending commit. For the record, it was this one: > [...] > The only change I see to an open() call was removing O_TRUNC on > systems with ftruncate() and adding a later call to ftruncate() on > systems that have it. There were also some changes to the setting > of permissions (fchown(), fchmod() and chmod()). These changes were > all in the buf_write() function in fileio.c. > > That open() call had the O_CREAT flag before and after the change. You are sooo right. My bugfix appears to work, but it's fixing a non-existent bug. NtCreateFile actually sets the ARCHIVE bit all the time when creating a new file, even if it's not explicitely given as parameter. That makes a lot of sense, of course, given how the archiving mechanism works on Windows. The *real* problem is in fact that Cygwin caches the wrong file attribute bits when creating a new file, and that's where fchmod fails: It writes back the wrongly cached bits. This doesn't happen with chmod, because it re-opens the existing file and fetches the correct attributes bit at the time. I guess I'll revert my patch and create a new one which is more to the point. Thanks, Corinna -- 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: Editing with vim clears Windows 10 file system archive bit.
On Nov 15 19:54, Christian Franke wrote: > Steve Ward via Cygwin wrote: > > Description of problem: > > While using vim 8.2 on cygwin 3.3 (x86_64) on Windows 10, > > when editing an existing file with vim and saving it, the Window’s > > file system archive bit is always left cleared (not modified state). > > This happens, whether the archive bit was set (is modified) or > > clear (not modified) initially. > > The problem also occurs with 'cp' command: > > $ touch file1 > > $ /bin/cp file1 file2 > > $ /bin/cp --preserve=mode file1 file3 > > $ lsattr file? > ---a file1 > ---a file2 > file3 > > Some Cygwin functions apparently clear the archive attribute unexpectedly, > for example: > > int fd = open(filename, O_CREAT|O_TRUNC|O_WRONLY, 0644); > write(fd, "Test\n", 5); > fchmod(fd, 0644); // clears archive attribute > close(fd); > > Same with facl(., SETACL, ...). The variants chmod() and acl() are not > affected. It's funny that it took so long that somebody actually noticed this. This behaviour is present at least since 2004. Cygwin *never* actually cared for the ARCHIVE attribute explicitely. The reason for the above observation is the open call containing the O_CREAT flag. When Cygwin creates files, it sets the attributes to FILE_ATTRIBUTE_NORMAL only, not adding the FILE_ATTRIBUTE_ARCHIVE flag. Changing that is actually pretty simple, just set FILE_ATTRIBUTE_ARCHIVE as soon as the underlying NtCreateFile is called for an open(O_CREAT). Fixed in current git. Thanks, Corinna -- 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: Tcl/Tk 8.6.12
On Nov 15 13:31, Jan Nijtmans via Cygwin-apps wrote: > The following packages have been uploaded to the Cygwin distribution: > > * tcl-8.6.12-1 > * tcl-devel-8.6.12-1 > * tcl-tk-8.6.12-1 > * tcl-tk-devel-8.6.12-1 > * tcl-itcl-4.2.2-1 > * tcl-itcl-devel-4.2.2-1 > * tcl-itk-4.2.2-1 > * tcl-itk-devel-4.2.2-1 > * tcl-iwidgets-4.1.1-1 > * mingw64-i686-tcl-8.6.12-1 > * mingw64-i686-tk-8.6.12-1 > * mingw64-x86_64-tcl-8.6.12-1 > * mingw64-x86_64-tk-8.6.12-1 > > This is an update and rebuild of the Tcl/Tk stack to the latest upstream > releases. > > Regards, > Jan Nijtmans Was that supposed to go to cygwin-announce? cygport announce should do this for you. Corinna
[ANNOUNCEMENT] libfido2 1.9.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.9.0-1 * libfido2-devel-1.9.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. WINDOWS 10 hint: On Windows 1903 and newer versions, access to FIDO devices has been restricted to applications using the operating system's native WebAuthn API. This change has been included into libfido2 in the meantime, but for some reason it doesn't work with ssh yet. -- 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
libfido2 1.9.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.9.0-1 * libfido2-devel-1.9.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. WINDOWS 10 hint: On Windows 1903 and newer versions, access to FIDO devices has been restricted to applications using the operating system's native WebAuthn API. This change has been included into libfido2 in the meantime, but for some reason it doesn't work with ssh yet.
[ANNOUNCEMENT] libcbor 0.9.0-2
The following packages have been uploaded to the Cygwin distribution: * libcbor-0.9.0-2 * libcbor-devel-0.9.0-2 libcbor is a C library for parsing and generating CBOR. -- 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
libcbor 0.9.0-2
The following packages have been uploaded to the Cygwin distribution: * libcbor-0.9.0-2 * libcbor-devel-0.9.0-2 libcbor is a C library for parsing and generating CBOR.
Re: 3.3.1: Missing VersionInfo resource fields for cygwin1.dll
On Nov 12 15:49, Brian Inglis wrote:
> On 2021-11-11 12:26, Marco Atzeri via Cygwin wrote:
> > On 11.11.2021 19:47, Hiya Z via Cygwin wrote:
> > > Upgraded to 3.3.x and noticed that the VersionInfo resource fields
> > > for all binaries under bin are blank (Properties->Details from
> > > Explorer). Is this by intent or a miss?
> > > It is breaking my application installer that relied on version check for
> > > cygwin1.dll.
>
> > Binaries should not have VersionInfo, only cygwin1.dll had it.
> > Not checked on 3.3.x
>
> Confirmed missing from cygwin.dll 3.3.0 64 and 32 bit and present up to at
> least 3.2.1. Also present in some other DLLs:
> cyg{asprintf,crypto,freetype,icons,iconv,lzma,ruby,ssl,unistring,usb,z}*.dll
Yeah, the version info resource isn't copied into the DLL for some
reason. This is probably related to the changes in the build system
using automake now. Something got lost in the transition...
Corinna
--
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
