Re: Cloning enterprise github repo with cygwin git tries to use username/password auth, have to use Windows git
Greetings, KARR, DAVID! > I'm now trying to connect to our new enterprise Github repositories. I > have created a PAT in Github. I've verified that it works by testing it with > some code using the github rest api. Until now, I haven't attempted a clone > from the new repositories or pushing to them. When I attempt the clone > using Cygwin git, it prompts me for a username and password, which I'm > unable to supply. If I instead do the clone using Windows Git, it just does > it. It's not clear to me whether it's even using the PAT under the covers. > I'm not sure how that works. Username is your GitHub account name. Password is your private auth token. To make HTTP git connection (any HTTP git kind) easier, change remote address to https://@host/path.git Then it will reuse your auth name and only ask you for a password. To make it EVEN easier, install GCM (it comes prepackaged with GfW). https://github.com/git-ecosystem/git-credential-manager/releases/latest Download, unpack to temp. directory, rename NOTICE to NOTICE.gcm.txt (recommended), then move the files to /usr/libexec/git-core/. Run git config --global credential.helper manager git config --global credential.modalPrompt true -- With best regards, Andrey Repin Monday, February 10, 2025 18:22:08 Sorry for my terrible english... -- 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: Potential Argument Injection Issue in Cygwin's Command Line Handling
On 2025-02-03 22:15, Splitline Huang via Cygwin wrote: > Hello Cygwin team, > > I am splitline from DEVCORE research team. I recently have observed an > inconsistency > in how Cygwin handles command-line parsing compared to Microsoft’s > implementation. Hi, I maintain a small fork of the Cygwin DLL called Cygnal. https://www.kylheku.com/cygnal/ The purpose of Cygnal is to leverage Cygwin as a run-time for "native" Windows applications. It gives us a beautfiful development workflow: you simply write your program under Cygwin as a Cygwin program, compiling with the Cygwin GCC suite. You can test your program and make sure it functions as a Cygwin application. Then you can slide the cygwin1.dll under it, which brings back certain Windows-like behaviors. Test it that way and ship it to Windows users who don't know anything about POSIX or Cygwin. (And also ship it as Cygwin program to Cygwin people too!) In the Cygnal project, I /do/ care about interoperability with Windows programs. I'd like a Cygnal program to accept arguments the same way as something that calls CommandLineToArgvW, or the same way as a Visual C++ program that begins with wmain. I don't want Cygnal programs to be susceptible to the alleged argument injection when invoked by non-Cygwin applications that are following the Microsoft-recommended command line convention. Therefore, if you produce a good patch for this issue, I will likely merge it in the Cygnal project, even if Cygwin doesn't want it. The patch has to address both generation of arguments when invoking processes, as well as parsing. Quite recently, Cygwin developer Corina Vinschen pointed me (via a post in this mailing list) to where the commanda rgument parsing logic takes place. It's under the function dll_crt0_1 in the file dcrt0.cc. Here, I think: https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/dcrt0.cc#n800 This calls something called build_argv, in the same file. In the Cygnal project, I don't care for having argv[0] massaged for POSIX conventions, either. Somewhere under the exec family of functions there is code for the reverse: encoding arguments into a Windows sommand line. Cheers ... -- 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: Potential Argument Injection Issue in Cygwin's Command Line Handling
On 2025-02-09 20:48, Splitline Ng via Cygwin wrote: Windows is security deficient in this area, not Cygwin. I'll quote myself to share my opinion: https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/src/fdevent_win32.c#L543 * The Microsoft CreateProcess() interface is criminally broken. * Forcing argument strings to be concatenated into a single string * only to be re-parsed by Windows can lead to security issues. * * Above comment from 2021 was true then as now in 2025 * https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/ Yes, I agree with you, this design has always been really problematic, that was totally a bad idea. But at this point, it's probably a huge design debt, and I imagine it’s not an easy fix for Microsoft. Back to this issue, the argument parsing logic is indeed handled by Cygwin itself, not Windows. So regardless of the question of who should be held responsible for this, I think it’s still reasonable to follow the convention. At the very least, it might be a minor inconvenience for some regular users. What part of "Cygwin - Get that Linux feeling - on Windows" - do you not get? Cygwin's goals are to be as POSIX/Unix*/Linux compatible as possible by working around Windows' bugs, issues, and limitations, while supporting some interoperability with Windows programs and systems (less as we add more POSIX/Unix/Linux compatible support). Starting Windows programs with command line arguments from Cygwin programs and shells may require the runner to take account of and work around Cygwin's conventions, just as starting Cygwin programs with command line arguments from Windows programs and shells may require the runner to take account of and work around Windows' conventions. One can avoid any issues by running Cygwin programs only from other Cygwin programs, and Windows programs only from other Windows programs. *[I say Unix because while we want to be UNIX® AKA SUSV5 Core compatible, we also want to be compatible with the original Unix legacy embodied in SunOS/SysV/Solaris, and BSD releases, from which our libc newlib borrows some code with ~1500 refs in ~600 files, and Cygwin has ~600 refs in ~200 files, with *all* patches submitted under the BSD-2-Clause licence.] -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Potential Argument Injection Issue in Cygwin's Command Line Handling
On 2025-02-10 12:32, Brian Inglis via Cygwin wrote: > One can avoid any issues by running Cygwin programs only from other Cygwin > programs, and Windows programs only from other Windows programs. Microsoft has provided a documented algorithm, which is implemented in the ShellAPI function CommandLineToArgvW, and in the CRT module that prepares arguments for the main or wmain functions of Microsoft Visual C/C++ programs. I believe that the algorithm is sound in that it can round-trip any argv[] vector to string, and then back to recover an identical argv[]. (Am I correct?) If that is the case, there is no reason why a POSIX layer on Windows would not use that algorithm, since it meets its requirements for passing an argv[] from one process to another, and is compatible with recommendations from the OS vendor, with a reference implementation (for the parsing direction) present in every Windows (ShellAPI). What I've noticed in Cygwin is that it destroys the command line! When you call GetCommandLineW in a Cygwin process, you get an empty line. I recently posted here about this. That means you cannot ignore the arguments given in main() and just do it yourself. -- 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
