[ANNOUNCEMENT] [SECURITY] Updated: subversion-1.9.7-1
SECURITY: This is a stable security release of the Apache Subversion open source version control system. It fixes one security issue: CVE-2017-9800: Arbitrary code execution on clients through malicious svn+ssh URLs in svn:externals and svn:sync-from-url http://subversion.apache.org/security/CVE-2017-9800-advisory.txt NEWS: = Please see the release notes http://subversion.apache.org/docs/release-notes/1.9.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.9.6/CHANGES for more details about the changes in 1.9.7. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: subversion-1.8.19-1
NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.19/CHANGES for more details about the changes in 1.8.19. This release changes mod_dav_svn to no longer map requests to the local filesystem. Administrators of mod_dav_svn servers should read the section about this in the release notes: http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org "Well hello there Charlie Brown, you blockhead." -- Lucy Van Pelt -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[SECURITY] Updated: subversion-1.9.7-1
SECURITY: This is a stable security release of the Apache Subversion open source version control system. It fixes one security issue: CVE-2017-9800: Arbitrary code execution on clients through malicious svn+ssh URLs in svn:externals and svn:sync-from-url http://subversion.apache.org/security/CVE-2017-9800-advisory.txt NEWS: = Please see the release notes http://subversion.apache.org/docs/release-notes/1.9.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.9.6/CHANGES for more details about the changes in 1.9.7. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org
Updated: subversion-1.8.19-1
NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.19/CHANGES for more details about the changes in 1.8.19. This release changes mod_dav_svn to no longer map requests to the local filesystem. Administrators of mod_dav_svn servers should read the section about this in the release notes: http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org "Well hello there Charlie Brown, you blockhead." -- Lucy Van Pelt
Re: calm does not recognize gambas3 3.10.0
Jon Turney writes: > calm had stopped running on the 10th, due to an unusual error state > which required some manual intervention to fix. > > I've restarted it and it seems to have picked up gambas 3.10.0-1 now. Confirmed. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: calm does not recognize gambas3 3.10.0
On 13/08/2017 22:12, Bastian Germann wrote: I uploaded a new version of gambas3 two days ago, but although the !ready file is in place, calm does not care about the files. I do not get any error emails to the address in !mail. What is the problem? Thanks for drawing attention to this. calm had stopped running on the 10th, due to an unusual error state which required some manual intervention to fix. I've restarted it and it seems to have picked up gambas 3.10.0-1 now. Sorry for the inconvenience.
RE: gawk 4.1.4: CR separate char for CRLF files
On Wed, 9 Aug 2017 10:38 +, Jannick wrote: --- snip --- > Now I can see the following *easy* solutions to the very situation here > (input only for now): > > 1 - Inserting the BEGIN section as you suggested into more than 1k scripts > (not feasible due to additional regression test workload) > > 2 - Calling 'gawk -vRS=\r\n -vORS=\r\n' instead of 'gawk' (hack to turn back > the additional the latest gawk's complexity, wrapper needed) > > 3 - Wrapping a d2u/u2d pipe solution (additional app and wrapper needed again) > > 4 - Using another compiled version of gawk which does *not* disable the > out-of-the-box gawk feature to swallow CRs (cf., e.g., > http://git.savannah.gnu.org/cgit/gawk.git/tree/awkgram.y#n3543), i.e. > without the artificial obstacle to now know the EOL type of the input file > ahead of running gawk. > >> It works in all my cases. The only disadvantage: you have to know what kind > >... plus the disadvantage to systematically amend all the scripts instead of >having an external solution > >> of files you want to handle in the awk script. The same awk script >> will not >> work for DOS files as well as for linux files. > >... another issue originated by the change and which didn't exist before. > >> Best >> >> Roger > > Please don't get me wrong, but this raises a real issue here and I am not > sure which rationale other than 'let's get more of the Linux-feel' drove the > decision. > > All the best, > J. --- snip --- Another solution which we have been using for many years now, though it might not be feasible for you: We very rarely update Cygwin. We have been using Cygwin for some 15+ years now. We use tools like gawk (hundreds of scripts), head, tail, sort, etc. that we are using in shell scripts running under cmd.exe (no Unix shells involved). I soon realized that upgrades of Cygwin may cause troubles with existing scripts, so we only update if we really need to (e.g.: New functionality that would be important, 32 to 64 bit shift, eventually new Windows versions, bugs we needed to be fixed). I have followed the discussions about the CR/LF behaviour changes in the past attentively and decided not to update in near future, because that would lead to a massive problem with many hundreds of scripts - hoping that sometimes there will be a change in gawk again. What is Unix-like or OS-like or Posix-like behaviour in that context? You could argue that gawk interprets line endings like the underlying OS does (i. e., gawk reads LF in Unix and CR/LF in Win), or it interprets line endings in a Unix-style no matter of the underlying OS used. That's a developer's decision in my opinion. But since with pipes or output redirection gawk used to write no CRs even in previous versions, we already had the problem that gawk had to accept *both* inputs, LF with or without CR. That worked widely fine so far, since most Windows and other application SW we use accept both record formats, fortunately (we had issues with SW upgrades of other vendors no longer accepting pure LF, but that only concerned a very small number of scripts). With the new approach in Cygwin that seems to be broken, so we did not upgrade Cygwin since then (we currently use gawk 4.1.3). Of course the reason for that really annoying CR/LF thing is the arrogance and ignorance of MS, which caused innumerable of useless developers' hours when I think of the endless discussions and changes in Cygwin; but MS is the one who defines the standards because of its very market power, so we have to deal with it, if we like or not. I'd definitely prefer to use Unix for its powerful tools, but most of the SW we use is simply not available for Unix, and MS does not provide gawk etc. So we have to deal with that CR/LF issue in a pragmatic rather than in a more, say, philosophical approach: We need to run our scripts with as little changes as possible. So that's why we upgrade Cygwin as seldom as possible. It is a "living system", yes, which is great on the one side - but can be annoying in everyday practice. In my opinion there should be at least an option for gawk to accept both LF and CR/LF line endings equally, preferably with a system variable so that there is no need to change the command line call of gawk at all. That's what I vote for. Kind regards, Wolfgang -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
httping requires libfftw3_3 (cygcheck report)
Hi httping is not working without libfftw3_3 (cygcheck /bin/httping.exe fail) libfftw3_3 needs to be in requires list (I have to install it manually) @ httping sdesc: "Ping-like program for http-requests" ldesc: "Show how long it takes to connect to a hostname or remote url; send a request and retrieve the reply (only the headers)." category: Web requires: libgcc1 libopenssl100 version: 2.4+20151029+gitb1521a6-1 @ libfftw3_3 sdesc: "Fast Fourier transforms C library - runtime" ldesc: "Fast Fourier transforms C library" category: Libs Math requires: cygwin version: 3.3.6-pl1-1 cygwin setup 2.881 (64 bit) best regards, Mit -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Security update: Git v2.14.1-1
Version 2.14.1-1 of Git has been uploaded and should be coming soon to a mirror near you. This update includes the following packages: - git - git-cvs - git-debuginfo - git-email - git-gui - gitk - git-p4 - git-svn This is an update to the latest upstream release, which specifically fixes CVE-2017-1000117, where a malicious "ssh://..." URL, including one specified in a .gitmodules file and thus parsed as part of `git clone --recurse-submodules` or similar, could result in an arbitrary executable being run on the client system. For a full list of the upstream changes in this release, please refer to the upstream changelogs: https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/ https://github.com/gitster/git/tree/master/Documentation/RelNotes Enjoy! Adam -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Security update: Git v2.14.1-1
Version 2.14.1-1 of Git has been uploaded and should be coming soon to a mirror near you. This update includes the following packages: - git - git-cvs - git-debuginfo - git-email - git-gui - gitk - git-p4 - git-svn This is an update to the latest upstream release, which specifically fixes CVE-2017-1000117, where a malicious "ssh://..." URL, including one specified in a .gitmodules file and thus parsed as part of `git clone --recurse-submodules` or similar, could result in an arbitrary executable being run on the client system. For a full list of the upstream changes in this release, please refer to the upstream changelogs: https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/ https://github.com/gitster/git/tree/master/Documentation/RelNotes Enjoy! Adam
Re: Signal delivered while blocked (2)
On 2017-08-14 08:03, Houder wrote: On Fri, 4 Aug 2017 00:44:45, Noah Misch wrote: --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The attached demonstration program blocks signals (with sigprocmask()) to achieve mutual exclusion between signal handlers. It aborts upon receipt of a blocked signal. On "CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64", signals regularly arrive despite being blocked. Essential parts of the program include handling two signal numbers and having handlers run for at least 1-2ms; this problem goes away if I remove one of those attributes. GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3) 2013-12-09 11:57 i686" never deliver a blocked signal to this program. I think this Cygwin behavior is non-conforming. Hi Noah, I do not think that Cygwin is the problem here; your code is the problem here, I believe. [snip] You cannot use SIG_SETMASK in that context. You cannot use SIG_SETMASK in that context in the way you do. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: calm does not recognize gambas3 3.10.0
Bastian Germann writes: > I uploaded a new version of gambas3 two days ago, but although the > !ready file is in place, calm does not care about the files. I do not > get any error emails to the address in !mail. What is the problem? You shouldn't announce a package update before you've got confirmation from calm that everything went OK and have checked that it's active on cygwin.com so the mirrors will pick it up over time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: Signal delivered while blocked
On Fri, 4 Aug 2017 00:44:45, Noah Misch wrote: > --UugvWAfsgieZRqgk > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > The attached demonstration program blocks signals (with sigprocmask()) to > achieve mutual exclusion between signal handlers. It aborts upon receipt of a > blocked signal. On "CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64", > signals regularly arrive despite being blocked. Essential parts of the > program include handling two signal numbers and having handlers run for at > least 1-2ms; this problem goes away if I remove one of those attributes. > GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3) 2013-12-09 11:57 > i686" never deliver a blocked signal to this program. I think this Cygwin > behavior is non-conforming. Hi Noah, I do not think that Cygwin is the problem here; your code is the problem here, I believe. Please, study, for example, chapters 20 and 21 of LPI (Linux Programming Interface by Michael Kerrisk). (20.10 The Signal Mask (Blocking Signal Delivery) (20.13 Changing Signal Dispositions: sigaction()) You cannot use sigprocmask() like you do; you cannot use SIG_SETMASK as a parameter in sigprocmask() within the context of a handler. Cygwin exhibits misbehaviour in case of your code, because it is slower than Linux; however, the code is also wrong for Linux. The misbehaviour occurs as result of nested interrupts in case of your code (yes, nested interrupts are possible with Linux/Unix!). However your code does not experience nesting under Linux, because, as I said, Linux is faster than Cygwin. - The simplest way to exclude one signal from another, is to specify the signal (or signals) in the sa_mask of the sigaction parameter ... see sigaction() - However if you desire 'control' during the execution of a handler, you have to resort to sigprocmask(), and use SIG_BLOCK and SIG_UNBLOCK, in order to add and remove a specific signal to/from the mask. see sigprocmask() You cannot use SIG_SETMASK in that context. Regards, Henri = -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
