Re: Issues to install cygwin 3.3.6
On Mon, Nov 21, 2022 at 7:18 AM Michel Robitaille wrote: Running setup-x86_64.exe (version 3.3.6) requires an app on Windows 11 > (fully up to date). > It is looking for an app that does not exist with Microsoft Store. > What app is it requiring? -- 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: Issues to install cygwin 3.3.6
On Mon, 21 Nov 2022 at 18:20, Jim Garrison via Cygwin wrote: > > On 11/21/22 08:03, Adam Dinwoodie wrote: > > On Mon, 21 Nov 2022 at 14:19, Michel Robitaille wrote: > >> > >> Hello, > >> > >> Running setup-x86_64.exe (version 3.3.6) requires an app on Windows 11 > >> (fully up to date). > >> It is looking for an app that does not exist with Microsoft Store. > >> > >> This was not required for any of the previous version. > >> > >> Is there a solution to fix this? > >> For now I am using the previous version. > > > > I'm not seeing any problems using the latest installer, and I can't > > imagine why the installer would try to direct you to the Microsoft > > Store for any reason, let alone for an app that doesn't exist. > > > > Can you please provide some more information about exactly what you're > > doing and exactly what behaviour you're seeing? > > > > There's also a lot of guidance on useful information to include in > > problem reports at https://cygwin.com/problems.html. > > > > I just tried the new setup and see what I think is the same thing, > but the original description was munged by non-native English. > > I believe this is the "Microsoft Defender SmartScreen" warning. It > pops up a blue window saying > > Windows protected your PC > Microsoft Defender SmartScreen prevented an unrecognized app from > starting. Running this app might put your PC at risk. More info. > > The only button on this popup says "Don't run". However, if you > click "More Info", which is underlined, you get additional info > > App: setup-x86_64.exe > Publisher: Unknown publisher > > and another button "Run anyway", which allows setup-x86_64 to run. Ah, that's unfortunate but normal: SmartScreen learns what's safe to run in part based on what other folk have downloaded and run without issue. When there's a new installer released, it inherently hasn't been downloaded and run by many people yet, so SmartScreen warns about that. I *think* you can at least reduce the likelihood of getting those warnings by signing the installer, but see, e.g., https://cygwin.com/pipermail/cygwin/2022-November/252521.html for the problems with that. Otherwise, the only way to avoid that warning AFAIK is to wait until a bunch of other people have downloaded the installer and SmartScreen has learned it's probably safe. (Disclaimer: I work for Microsoft these days, but neither Cygwin nor SmartScreen are anywhere near my day job; I have no inside knowledge or influence.) -- 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: Issues to install cygwin 3.3.6
On 11/21/22 08:03, Adam Dinwoodie wrote: On Mon, 21 Nov 2022 at 14:19, Michel Robitaille wrote: Hello, Running setup-x86_64.exe (version 3.3.6) requires an app on Windows 11 (fully up to date). It is looking for an app that does not exist with Microsoft Store. This was not required for any of the previous version. Is there a solution to fix this? For now I am using the previous version. I'm not seeing any problems using the latest installer, and I can't imagine why the installer would try to direct you to the Microsoft Store for any reason, let alone for an app that doesn't exist. Can you please provide some more information about exactly what you're doing and exactly what behaviour you're seeing? There's also a lot of guidance on useful information to include in problem reports at https://cygwin.com/problems.html. I just tried the new setup and see what I think is the same thing, but the original description was munged by non-native English. I believe this is the "Microsoft Defender SmartScreen" warning. It pops up a blue window saying Windows protected your PC Microsoft Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk. More info. The only button on this popup says "Don't run". However, if you click "More Info", which is underlined, you get additional info App: setup-x86_64.exe Publisher: Unknown publisher and another button "Run anyway", which allows setup-x86_64 to run. -- Jim Garrison j...@acm.org -- 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: [ANNOUNCEMENT] Updated: setup (2.923)
On 21/11/2022 16:23, Adam Dinwoodie wrote: On Mon, 21 Nov 2022 at 12:46, Jon Turney wrote: - Add view modes "Removable" and "Unneeded" (thanks to Christian Franke) -- "Removable" shows installed packages that were selected, but can now be safely removed, as no installed package depends on them -- "Unneeded" shows packages which were automatically installed, but can now be safely removed, as no installed depends on them Thank you, everyone involved in this! I'd been lamenting cygcheck-dep not getting updated for the new dependency declaration methods, but noticed these new options when I ran the installer yesterday, and was very appreciative! - Add Ctrl-I/R/U as keyboard accelerators for install/reinstall/uninstall in the package chooser (thanks to Christian Franke) I am also very grateful for this, too – I'm a keyboard monkey and I find the current package selection process somewhat tedious – but I'm also wondering if there's a way to make it more obvious. I think a lot of folk would benefit from this function who probably aren't reading these announcements, including all the folk who sign up in future. I can think of a couple of obvious options, namely adding instructions in the grey areas above or below the chooser, or adding the shortcuts in brackets in the package selection drop-downs, but fundamentally I'd just like to have it suggested somewhere other than the mailing list archives for future users. Yeah, we went around this a bit on cygwin-apps. Marking these as accelerators in the drop-down menu is apparently problematic in some way I don't recall the details of now (and is usually hidden nowadays unless you opened the menu via a keypress). This is not the place for setup feature requests. Having probably just broken that rule, can you clarify what _is_ the place for setup feature requests? Neither https://sourceware.org/cygwin-apps/setup.html nor https://cygwin.com/lists.html seemed to suggest a better option… The intended meaning is that replies to that email are for reporting problems with that release. It's perfectly permissible to start a new email thread with a feature request for setup. Of course, the likely response is "that's an idea, but someone has to do it" :) I'll try to tweak that sentence for clarity in future. -- 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: [ANNOUNCEMENT] Updated: setup (2.923)
On Mon, 21 Nov 2022 at 12:46, Jon Turney wrote: > - Add view modes "Removable" and "Unneeded" (thanks to Christian Franke) > > -- "Removable" shows installed packages that were selected, but can now > be safely removed, as no installed package depends on them > -- "Unneeded" shows packages which were automatically installed, but can > now be safely removed, as no installed depends on them Thank you, everyone involved in this! I'd been lamenting cygcheck-dep not getting updated for the new dependency declaration methods, but noticed these new options when I ran the installer yesterday, and was very appreciative! > - Add Ctrl-I/R/U as keyboard accelerators for > install/reinstall/uninstall in the package chooser (thanks to Christian > Franke) I am also very grateful for this, too – I'm a keyboard monkey and I find the current package selection process somewhat tedious – but I'm also wondering if there's a way to make it more obvious. I think a lot of folk would benefit from this function who probably aren't reading these announcements, including all the folk who sign up in future. I can think of a couple of obvious options, namely adding instructions in the grey areas above or below the chooser, or adding the shortcuts in brackets in the package selection drop-downs, but fundamentally I'd just like to have it suggested somewhere other than the mailing list archives for future users. > This is not the place for setup feature requests. Having probably just broken that rule, can you clarify what _is_ the place for setup feature requests? Neither https://sourceware.org/cygwin-apps/setup.html nor https://cygwin.com/lists.html seemed to suggest a better option… -- 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: Issues to install cygwin 3.3.6
On Mon, 21 Nov 2022 at 14:19, Michel Robitaille wrote: > > Hello, > > Running setup-x86_64.exe (version 3.3.6) requires an app on Windows 11 (fully > up to date). > It is looking for an app that does not exist with Microsoft Store. > > This was not required for any of the previous version. > > Is there a solution to fix this? > For now I am using the previous version. I'm not seeing any problems using the latest installer, and I can't imagine why the installer would try to direct you to the Microsoft Store for any reason, let alone for an app that doesn't exist. Can you please provide some more information about exactly what you're doing and exactly what behaviour you're seeing? There's also a lot of guidance on useful information to include in problem reports at https://cygwin.com/problems.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
Issues to install cygwin 3.3.6
Hello, Running setup-x86_64.exe (version 3.3.6) requires an app on Windows 11 (fully up to date). It is looking for an app that does not exist with Microsoft Store. This was not required for any of the previous version. Is there a solution to fix this? For now I am using the previous version. Thanks in advance for your help. Regards, Michel -- 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: Adding an embedded signature on setup-x86_64.exe
On 20/11/2022 08:46, Thomas Wolff wrote: In case we ever need it, one of our setup maintainers packaged osslsigncode: https://cygwin.com/packages/summary/osslsigncode-src.html Packaging error: the binary is placed in /usr Thanks for pointing this out. It seems this was an upstream defect in the cmake conversion they did in this version. I applied the upstream patch to correct it. -- 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: Adding an embedded signature on setup-x86_64.exe
On Nov 20 13:45, Brian Inglis wrote: > On Sun, 20 Nov 2022 17:17:18 +, Jon Turney wrote: > > On 18/11/2022 21:15, Dale McCoy wrote: > > > I use Cygwin in the course of work, and while I can use the external gpg > > > signature to verify the validity of setup-x86_64.exe, my IT department > > > can't see that step. They get somewhat concerned when they see that > > > Windows > > > thinks setup-x86_64.exe is unsigned, and I certainly don't blame them. > > > Can I convince you to also embed a signature in the installer, so Windows > > > recognizes the file is signed? > > > This something I'd like to do, but unfortunately, the remaining blocking > > issues are not technical. > > > > In order to sign the code in this way, the key needs to be signed by a > > CA that participates in Microsoft Trusted Root Program. These CAs > > charge an annual fee. As the person who makes the setup releases, I'm > > not going to pay that out of my own pocket, and we currently have no > > organization to collect donations for that (or any other) purpose. > > If Cygwin becomes an SFC member, they may be able to fund Cygwin signing > certs. Good point! 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] setup regression #2
On Nov 21 13:39, ASSI wrote:
> Corinna Vinschen writes:
> > The idea is that the installation tree has POSIXy permissions and
> > administrative users have the right to change stuff. The administrators
> > group is part of the user's token if the process has been started
> > elevated, so, to me, this looks like a natural choice.
>
> As I said, I haven't thought through the implications of doing that. We
> certainly haven't done a security audit or anything like that
> w.r.t. group ownership of the Cygwin tree and permission of the
> installed files.
>
> > The other advantage is that the administrators group has a fixed SID on
> > all systems, while other groups depend on the environment. That goes
> > for the local group "None" just as well as for the "Domain Users"
> > group, etc.
>
> Yeah, a local non-domain installation currently installs as "None"
> ("Kein" in german Windows) and domain ones will have "Domain Users"
...both groups using the same RID is no accident @ MSFT :)
Corinna
Re: RE: Cygwin x86 end-of-life
On Nov 18 12:30, Brian Inglis wrote: > On Fri, 18 Nov 2022 15:51:34 +, Jon Turney wrote: > > On 14/11/2022 21:29, Jason Pyeron wrote: > > > Can I throw resources at a solution? If so what? > > > Sure, if that's what you want to do. > > According surveys, 32-bit Windows has a fraction of 1% market share, and > > declining. Our own (limited) metrics are in accord with that, so I > > basically see any time I spend on this as wasted. > > So, the first resource you'll need provide is manpower. > > The decision makes sense with those numbers. > Do we have numbers to say what the situation is with Windows mingw64-i686 > crosses? > Should we also be dropping those at the same time, if there is only 1% use > of that platform? > In which case, we should announce that, and add that to the EoL notices. A cygwin -> i686-w64-mingw32 cross is an entirely different beast. It's kind of like a cygwin -> sparc-sun-sunos4 cross, or a cygwin -> riscv-*-* cross. Either of them is a perfectly valid toolchain, hosted on Cygwin, targeting some foreign CPU/machine combination. As long as the cross toolchain has a maintainer, it's ok, isn't it? Corinna
[ANNOUNCEMENT] Updated: setup (2.923)
A new version of Setup (2.923) has been uploaded to: https://cygwin.com/setup-x86_64.exe (64 bit version) https://cygwin.com/setup-x86.exe (32 bit version) Changes compared to 2.919: - Add perpetual support for preremove scripts (thanks to Christian Franke) - Major update to libsolv (from 0.6.29 to 0.7.22). Fix a crash this causes. - Allow packages to be marked as 'self-destruct'. (This is intended for use in the rare cases where a package is obsolete, but has no direct replacement.) - Add new option '--no-write-registry', which inhibits recording the installation root directory in the registry, which may be useful for portable or temporary installs (thanks to Christian Franke) - Add view modes "Removable" and "Unneeded" (thanks to Christian Franke) -- "Removable" shows installed packages that were selected, but can now be safely removed, as no installed package depends on them -- "Unneeded" shows packages which were automatically installed, but can now be safely removed, as no installed depends on them - Add Ctrl-I/R/U as keyboard accelerators for install/reinstall/uninstall in the package chooser (thanks to Christian Franke) - Restore the ability to run on Windows 5.1 (XP/Server 2003), in conjunction with '--allow-unsupported-windows' This is not the place for setup feature requests. For instructions on obtaining and building the source code for setup, see https://sourceware.org/cygwin-apps/setup.html Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: setup (2.923)
A new version of Setup (2.923) has been uploaded to: https://cygwin.com/setup-x86_64.exe (64 bit version) https://cygwin.com/setup-x86.exe (32 bit version) Changes compared to 2.919: - Add perpetual support for preremove scripts (thanks to Christian Franke) - Major update to libsolv (from 0.6.29 to 0.7.22). Fix a crash this causes. - Allow packages to be marked as 'self-destruct'. (This is intended for use in the rare cases where a package is obsolete, but has no direct replacement.) - Add new option '--no-write-registry', which inhibits recording the installation root directory in the registry, which may be useful for portable or temporary installs (thanks to Christian Franke) - Add view modes "Removable" and "Unneeded" (thanks to Christian Franke) -- "Removable" shows installed packages that were selected, but can now be safely removed, as no installed package depends on them -- "Unneeded" shows packages which were automatically installed, but can now be safely removed, as no installed depends on them - Add Ctrl-I/R/U as keyboard accelerators for install/reinstall/uninstall in the package chooser (thanks to Christian Franke) - Restore the ability to run on Windows 5.1 (XP/Server 2003), in conjunction with '--allow-unsupported-windows' This is not the place for setup feature requests. For instructions on obtaining and building the source code for setup, see https://sourceware.org/cygwin-apps/setup.html Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com.
Re: [Bug] setup regression #2
Corinna Vinschen writes:
> The idea is that the installation tree has POSIXy permissions and
> administrative users have the right to change stuff. The administrators
> group is part of the user's token if the process has been started
> elevated, so, to me, this looks like a natural choice.
As I said, I haven't thought through the implications of doing that. We
certainly haven't done a security audit or anything like that
w.r.t. group ownership of the Cygwin tree and permission of the
installed files.
> The other advantage is that the administrators group has a fixed SID on
> all systems, while other groups depend on the environment. That goes
> for the local group "None" just as well as for the "Domain Users"
> group, etc.
Yeah, a local non-domain installation currently installs as "None"
("Kein" in german Windows) and domain ones will have "Domain Users"
> I'm not adamant about this, it was just what was looking like being the
> right thing to do at the time. Especially I was not hot to make the
> permission set more complicated than necessary for a POSIX-like system.
Agreed.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [Bug] setup regression #2
On Nov 20 20:05, Achim Gratz wrote: > Jon Turney writes: > > I believe that the intent of the code in setup is that there should > > only be two modes: > > > > USER: install "for me", with the users primary group > > As I understand it, the intention here was that the user can have a > "single user installation" in a place that they have access to (say, > their home directory) while they have no permission in one of the usual > places. In a setup where that place is a certain type of share the user > will not be able to change the group the files are owned by anyway > (standard NetApp CIFS shares are set up this way) and it may not be the > users primary group. > > > SYSTEM: install "for everyone", with the administrators primary group > > (only permitted if you are an administrator) > > I don't see why the fact the installation is meant to be used by > multiple users means that the install must be owned by group > Administrators. I'm not sure this is a good idea on Windows anyway, at > least when you don't put extra (inheritable) DACL on the install > folder. The idea is that the installation tree has POSIXy permissions and administrative users have the right to change stuff. The administrators group is part of the user's token if the process has been started elevated, so, to me, this looks like a natural choice. The other advantage is that the administrators group has a fixed SID on all systems, while other groups depend on the environment. That goes for the local group "None" just as well as for the "Domain Users" group, etc. I'm not adamant about this, it was just what was looking like being the right thing to do at the time. Especially I was not hot to make the permission set more complicated than necessary for a POSIX-like system. Corinna
Re: [PATCH] Cygwin: pty, console: Encapsulate spawn.cc code related to pty/console.
On Nov 20 18:43, Takashi Yano wrote: > - The codes related to pty and console in spawn.cc have been moved > into the new class fhandler_termios::spawn_worker, and make spawn.cc > call them. The functionality has not been changed at all. This is great, thanks! Corinna
Re: [PATCH] Cygwin: pty: Fix 'Bad address' error when running 'cmd.exe /c dir'
On Nov 18 09:23, Johannes Schindelin wrote: > Hi Corinna, > > On Mon, 24 Oct 2022, Corinna Vinschen wrote: > > > However, two points: > > > > - I'm wondering if the patch (both of yours) doesn't actually just cover > > a problem in child_info_spawn::worker(). Different runpath values, > > depending on the app path being "cmd" or "cmd.exe"? That sounds like > > worker() is doing weird stuff. And it does in line 400ff. > > > > So, if the else branch of this code is apparently working fine for > > "cmd" per Takashi's observation in > > https://cygwin.com/pipermail/cygwin-patches/2022q4/012032.html, how > > much sense is in the if branch handling "command.com" and "cmd.exe" > > specially? Wouldn't a better patch get rid of this extra if and > > the null_app_name variable instead? > > I never understood why the pcon code was allowed to be so Hydra-like as to > sprawl into corners far, far beyond `winsup/cygwin/fhandler*`. > > FWIW I would be in favor of getting rid of this special handling (unless > it causes a regression). I'm a bit surprised to read that, you should already have seen that. I did so end of October: https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=f33635ae6076 https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=213b53ed3557 Corinna
Re: [PATCH v2 1/2] Allow deriving the current user's home directory via the HOME variable
On Nov 18 09:18, Johannes Schindelin wrote: > Hi Corinna, > > On Thu, 10 Nov 2022, Corinna Vinschen wrote: > > On Nov 10 16:16, Johannes Schindelin wrote: > > > With this context in mind, I would like to ask to integrate the patch > > > as-is, including the HOMEDRIVE/HOMEPATH and USERPROFILE fall-backs. > > > > Can't do that, sorry. Two replies before I sent a necessary change, > > which needs inclusion first. > > I am a bit confused. Do you need anything from me to move this along, i.e. > are those two replies you mention some emails I failed to address yet? I didn't mean two different replies, but my second-last reply before that one, i. e. https://cygwin.com/pipermail/cygwin-patches/2022q4/012025.html Sorry if that wasn't clear. Basically your handling of $HOME was wrong and I suggested a fix. Corinna
