Re: [SECURITY] lighttpd
On Thu, 2012-03-29 at 13:39 -0500, Yaakov (Cygwin/X) wrote: > On 2012-03-29 09:58, Lapo Luchini wrote: > > Yaakov (Cygwin/X) wrote: > >> BLODA? > > > > Not that I know of: > > > > WindowsDefender is deactivated (and I checked the service is not > > running), and only other stuff in the BLODA is "nVidia, some version" > > but I can't really do much to avoid that. I wonder. > > So do I, because: > > >>> configure.ac:57: error: possibly undefined macro: AC_CHECK_HEADERS > >>> configure.ac:71: error: possibly undefined macro: AC_DEFINE > >>> configure.ac:108: error: possibly undefined macro: AC_CHECK_LIB > >>> configure.ac:112: error: possibly undefined macro: AC_MSG_ERROR > >>> autoreconf-2.68: /usr/bin/autoconf-2.68 failed with exit status: 1 > >>> *** ERROR: autoreconf failed > >> > >> Then something is wrong with your installation or environment. I'll > >> need your `cygcheck -srv' output. > > > > Same goes for a fresh install on real hardware (Win7 box in my office). > > Nothing obvious in the cygcheck. But as these macros are part of > autoconf itself, if autoconf can't find them, it means that aclocal > silently failed. In any case, this is an issue with your system > (probably BLODA or rebase), not with cygport. Ping? lighttpd 1.4.31 is available now. Yaakov
Re: [SECURITY] emacs
On 8/14/2012 8:17 PM, Yaakov (Cygwin/X) wrote: Ken, A security vulnerability has been announced for GNU Emacs, details and patches for 23.4 and 24.1 here: https://bugzilla.redhat.com/show_bug.cgi?id=847698 http://pkgs.fedoraproject.org/cgit/emacs.git/plain/emacs-cve-2012-3479.patch?h=f16 http://pkgs.fedoraproject.org/cgit/emacs.git/plain/emacs-cve-2012-3479.patch?h=f17 Thanks. This is being discussed on the emacs-devel list, and emacs-24.2 is going to be released within a few days, with a fix. I'll patch emacs-23.4 at the same time. Ken
Re: [SECURITY] tiff, libpng, automake
On Tue, 2012-08-14 at 22:05 +0200, Corinna Vinschen wrote: > Chuck? > > Ping 2? > > If you don't reply I guess we have to assume you're not with us > anymore. Which would be too bad. Indeed. :-( > On Aug 3 09:58, Corinna Vinschen wrote: > > On Jul 23 16:48, Yaakov (Cygwin/X) wrote: > > > Chuck, > > > > > > Security vulnerabilities are accumulating for the tiff package > > > (CVE-2011-0192, CVE-2011-1167, CVE-2012-1173, CVE-2012-2088, > > > CVE-2012-2113, CVE-2012-3401). This can be fixed by updating to > > > 3.9.6 and applying the four patches found here: > > > > > > http://pkgs.fedoraproject.org/gitweb/?p=libtiff.git;a=tree;h=refs/heads/f17;hb=f17 > > > > > > There are also security vulnerabilities in the libpng packages > > > (CVE-2011-3026, CVE-2011-3048, and now CVE-2012-3386). These need > > > to be updated to the latest 1.4.12, 1.2.50, and 1.0.60 releases. And now there's YA: automake1.11 needs a bump to 1.11.6 for CVE-2012-3386; earlier branches are also affected, but I haven't seen any backporting patches yet. Yaakov
[SECURITY] emacs
Ken, A security vulnerability has been announced for GNU Emacs, details and patches for 23.4 and 24.1 here: https://bugzilla.redhat.com/show_bug.cgi?id=847698 http://pkgs.fedoraproject.org/cgit/emacs.git/plain/emacs-cve-2012-3479.patch?h=f16 http://pkgs.fedoraproject.org/cgit/emacs.git/plain/emacs-cve-2012-3479.patch?h=f17 TIA, Yaakov
Re: [SECURITY] exif
Jari? Ping? On Jul 26 23:13, Yaakov (Cygwin/X) wrote: > Jari, > > A security vulnerability (CVE-2012-2845) has been announced for the > outdated version of the exif package currently in the distribution. > Please update exif to 0.6.21 ASAP. > > And while I'm at it, ping: > http://cygwin.com/ml/cygwin-apps/2008-11/msg00078.html > http://cygwin.com/ml/cygwin/2012-04/msg4.html > http://cygwin.com/ml/cygwin/2012-04/msg5.html > > > Yaakov Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [SECURITY] tiff, libpng
Chuck? Ping 2? If you don't reply I guess we have to assume you're not with us anymore. Which would be too bad. On Aug 3 09:58, Corinna Vinschen wrote: > Chuck? > > Ping? Are you still with us? > > On Jul 23 16:48, Yaakov (Cygwin/X) wrote: > > Chuck, > > > > Security vulnerabilities are accumulating for the tiff package > > (CVE-2011-0192, CVE-2011-1167, CVE-2012-1173, CVE-2012-2088, > > CVE-2012-2113, CVE-2012-3401). This can be fixed by updating to > > 3.9.6 and applying the four patches found here: > > > > http://pkgs.fedoraproject.org/gitweb/?p=libtiff.git;a=tree;h=refs/heads/f17;hb=f17 > > > > There are also security vulnerabilities in the libpng packages > > (CVE-2011-3026, CVE-2011-3048, and now CVE-2012-3386). These need > > to be updated to the latest 1.4.12, 1.2.50, and 1.0.60 releases. > > > > PLEASE update these packages ASAP. > > > > > > Yaakov Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On 8/14/2012 10:51, Yaakov (Cygwin/X) wrote: > On 2012-08-12 01:49, JonY wrote: >> New w32api preliminary upload, now with mingw-w64 parts. > > Nack. Both mintty and xorg-server FTBFS with this w32api. > >> It contains the headers and win32 and win64 DLL import libraries. >> It does require multilib capable GCC to build. > > Why? What is the purpose of 64-bit libs with a 32-bit-only Cygwin GCC? > Like Corinna says, 64bit Cygwin has to start somewhere. >> Yaakov: >> Can cygport implement a new inherit where it is similar to cross, except >> it uses --prefix=/usr? Right now, I'm setting CC/CXX manually to get >> around it. > > To bootstrap, you could just unset CC/CXX and configure with > --host=x86_64-w64-mingw32. But once the new w32api is installed, if you > configure with --disable-lib64, this should be buildable with Cygwin's > native GCC. > I did not think of that, thanks. signature.asc Description: OpenPGP digital signature
Re: [ITA] w32api-3.0b_svn5368-1
2012/8/14 Corinna Vinschen: > On Aug 14 08:46, Andy Koppe wrote: >> Yep, mintty builds fine with that, and appears to work. For some >> reason it's 9K bigger than with the current w32api though. > > I think this is because the mingw-w64 libs come with a couple more > static elements built into the libs (GUIDs and stuff). > > Kai, can you explain the difference? > > > Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Btw have you checked size with debugging-information, or without? Regards, Kai
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 14 08:46, Andy Koppe wrote:
> On 14 August 2012 08:34, Corinna Vinschen wrote:
> > On Aug 14 09:29, Corinna Vinschen wrote:
> >> On Aug 14 08:25, Andy Koppe wrote:
> >> > On 14 August 2012 08:18, Corinna Vinschen wrote:
> >> > > On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
> >> > >> On 2012-08-12 01:49, JonY wrote:
> >> > >> >New w32api preliminary upload, now with mingw-w64 parts.
> >> > >>
> >> > >> Nack. Both mintty and xorg-server FTBFS with this w32api.
> >> > >
> >> > > Er... what?
> >> >
> >> > I had to look it up: Fails To Build From Source.
> >> >
> >> > /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
> >> > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
> >> >
> >> > windef.h:23: typedef unsigned __LONG32 ULONG;
> >> >
> >> > It doesn't like the __LONG32.
> >>
> >> Ok, that's fixable. Do you include windef before windows.h? If so,
> >> does it work if you switch the includes?
>
> I haven't included windows.h, but just the headers that are actually
> needed. (Yeah, I know MSDN doesn't like that, but then why do they
> bother documenting which header each function is in.)
>
> > Alternatively, can you apply this patch to windef.h and try again?
> >
> > Index: windef.h
> > ===
> > --- windef.h(revision 5370)
> > +++ windef.h(working copy)
> > @@ -14,6 +14,8 @@
> > extern "C" {
> > #endif
> >
> > +#include <_mingw.h>
> > +
> > #ifndef WINVER
> > #define WINVER 0x0502
> > #endif
>
> Yep, mintty builds fine with that, and appears to work. For some
> reason it's 9K bigger than with the current w32api though.
I think this is because the mingw-w64 libs come with a couple more
static elements built into the libs (GUIDs and stuff).
Kai, can you explain the difference?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:34, Corinna Vinschen wrote:
> On Aug 14 09:29, Corinna Vinschen wrote:
>> On Aug 14 08:25, Andy Koppe wrote:
>> > On 14 August 2012 08:18, Corinna Vinschen wrote:
>> > > On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
>> > >> On 2012-08-12 01:49, JonY wrote:
>> > >> >New w32api preliminary upload, now with mingw-w64 parts.
>> > >>
>> > >> Nack. Both mintty and xorg-server FTBFS with this w32api.
>> > >
>> > > Er... what?
>> >
>> > I had to look it up: Fails To Build From Source.
>> >
>> > /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
>> > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
>> >
>> > windef.h:23: typedef unsigned __LONG32 ULONG;
>> >
>> > It doesn't like the __LONG32.
>>
>> Ok, that's fixable. Do you include windef before windows.h? If so,
>> does it work if you switch the includes?
I haven't included windows.h, but just the headers that are actually
needed. (Yeah, I know MSDN doesn't like that, but then why do they
bother documenting which header each function is in.)
> Alternatively, can you apply this patch to windef.h and try again?
>
> Index: windef.h
> ===
> --- windef.h(revision 5370)
> +++ windef.h(working copy)
> @@ -14,6 +14,8 @@
> extern "C" {
> #endif
>
> +#include <_mingw.h>
> +
> #ifndef WINVER
> #define WINVER 0x0502
> #endif
Yep, mintty builds fine with that, and appears to work. For some
reason it's 9K bigger than with the current w32api though.
Andy
Re: [ITA] w32api-3.0b_svn5368-1
2012/8/14 Corinna Vinschen
> On Aug 14 09:29, Corinna Vinschen wrote:
>> On Aug 14 08:25, Andy Koppe wrote:
>> > On 14 August 2012 08:18, Corinna Vinschen wrote:
>> > > On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
>> > >> On 2012-08-12 01:49, JonY wrote:
>> > >> >New w32api preliminary upload, now with mingw-w64 parts.
>> > >>
>> > >> Nack. Both mintty and xorg-server FTBFS with this w32api.
>> > >
>> > > Er... what?
>> >
>> > I had to look it up: Fails To Build From Source.
>> >
>> > /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
>> > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
>> >
>> > windef.h:23: typedef unsigned __LONG32 ULONG;
>> >
>> > It doesn't like the __LONG32.
>>
>> Ok, that's fixable. Do you include windef before windows.h? If so,
>> does it work if you switch the includes?
>
> Alternatively, can you apply this patch to windef.h and try again?
>
> Index: windef.h
> ===
> --- windef.h(revision 5370)
> +++ windef.h(working copy)
> @@ -14,6 +14,8 @@
> extern "C" {
> #endif
>
> +#include <_mingw.h>
> +
> #ifndef WINVER
> #define WINVER 0x0502
> #endif
>
>
> Corinna
Fixed at rev. 5371. The include should come before the 'extern "C" {' clause.
Thanks for reporting. It might be that there are some of those issues
remaining caused by the LP64 support-changes.
Regards,
Kai
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 14 09:29, Corinna Vinschen wrote:
> On Aug 14 08:25, Andy Koppe wrote:
> > On 14 August 2012 08:18, Corinna Vinschen wrote:
> > > On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
> > >> On 2012-08-12 01:49, JonY wrote:
> > >> >New w32api preliminary upload, now with mingw-w64 parts.
> > >>
> > >> Nack. Both mintty and xorg-server FTBFS with this w32api.
> > >
> > > Er... what?
> >
> > I had to look it up: Fails To Build From Source.
> >
> > /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
> > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
> >
> > windef.h:23: typedef unsigned __LONG32 ULONG;
> >
> > It doesn't like the __LONG32.
>
> Ok, that's fixable. Do you include windef before windows.h? If so,
> does it work if you switch the includes?
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern "C" {
#endif
+#include <_mingw.h>
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 14 08:25, Andy Koppe wrote: > On 14 August 2012 08:18, Corinna Vinschen wrote: > > On Aug 13 21:51, Yaakov (Cygwin/X) wrote: > >> On 2012-08-12 01:49, JonY wrote: > >> >New w32api preliminary upload, now with mingw-w64 parts. > >> > >> Nack. Both mintty and xorg-server FTBFS with this w32api. > > > > Er... what? > > I had to look it up: Fails To Build From Source. > > /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’ > > windef.h:23: typedef unsigned __LONG32 ULONG; > > It doesn't like the __LONG32. Ok, that's fixable. Do you include windef before windows.h? If so, does it work if you switch the includes? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:18, Corinna Vinschen wrote: > On Aug 13 21:51, Yaakov (Cygwin/X) wrote: >> On 2012-08-12 01:49, JonY wrote: >> >New w32api preliminary upload, now with mingw-w64 parts. >> >> Nack. Both mintty and xorg-server FTBFS with this w32api. > > Er... what? I had to look it up: Fails To Build From Source. /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’ windef.h:23: typedef unsigned __LONG32 ULONG; It doesn't like the __LONG32. Andy
Re: [ITA] w32api-3.0b_svn5368-1
On Aug 13 21:51, Yaakov (Cygwin/X) wrote: > On 2012-08-12 01:49, JonY wrote: > >New w32api preliminary upload, now with mingw-w64 parts. > > Nack. Both mintty and xorg-server FTBFS with this w32api. Er... what? > >It contains the headers and win32 and win64 DLL import libraries. > >It does require multilib capable GCC to build. > > Why? What is the purpose of 64-bit libs with a 32-bit-only Cygwin GCC? It doesn't hurt to have the 64 bit libs already available, does it? It allows to install a cross gcc for x86_64-pc-cygwin at one point and the w32api headers are already available? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
