November 2012 - mingw - Fedora Mailing-Lists

[Bug 825557] Review Request: mingw-clucene - CLucene 2.3.3.4 built for MinGW

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=825557 --- Comment #20 from greg.hellings(a)gmail.com --- I've put up a new -5 srpm as above along with an updated .spec file that uses %{summary} in the binary packages. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

[Bug 825557] Review Request: mingw-clucene - CLucene 2.3.3.4 built for MinGW

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=825557 Kalev Lember <kalevlember(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|177841 (FE-NEEDSPONSOR) | --- Comment #19 from Kalev Lember <kalevlember(a)gmail.com> --- I've sponsored you as well, please use your new powers wisely! -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

[Bug 825557] Review Request: mingw-clucene - CLucene 2.3.3.4 built for MinGW

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=825557 Kalev Lember <kalevlember(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-review+ --- Comment #18 from Kalev Lember <kalevlember(a)gmail.com> --- Looks good. I see you've changed the summary for the source package, please edit the summary of the review ticket as well, so that they match (releng git repo creation tools check this). APPROVED -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

[Bug 825557] Review Request: mingw-clucene - CLucene 2.3.3.4 built for MinGW

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=825557 --- Comment #17 from greg.hellings(a)gmail.com --- I have addressed all of the above, I believe. The patch did not originate with me, so I don't want to be responsible for submitting it upstream. The rest of the problems which can be addressed have been. New SRPM: http://dl.thehellings.com/mingw32/clucene/mingw-clucene-2.3.3.4-4.fc17.sr... Spec still at: http://dl.thehellings.com/mingw32/clucene/mingw-clucene.spec -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

[Bug 825557] Review Request: mingw-clucene - CLucene 2.3.3.4 built for MinGW

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=825557 --- Comment #16 from Kalev Lember <kalevlember(a)gmail.com> --- Fedora review of mingw-clucene-2.3.3.4-3.fc17.src.rpm 2012-11-16 + OK ! needs attention rpmlint output: $ rpmlint mingw-clucene-2.3.3.4-3.fc18.src.rpm \ mingw32-clucene \ mingw64-clucene \ mingw32-clucene-debuginfo-2.3.3.4-3.fc18.noarch.rpm \ mingw64-clucene-debuginfo-2.3.3.4-3.fc18.noarch.rpm mingw32-clucene.noarch: E: description-line-too-long C date with Lucene 2.3.2. It contains most of the same functionality as the Java version. mingw32-clucene.noarch: E: incorrect-fsf-address /usr/share/doc/mingw32-clucene-2.3.3.4/LGPL.license mingw64-clucene.noarch: E: description-line-too-long C date with Lucene 2.3.2. It contains most of the same functionality as the Java version. mingw64-clucene.noarch: E: incorrect-fsf-address /usr/share/doc/mingw64-clucene-2.3.3.4/LGPL.license mingw-clucene.src: E: description-line-too-long C date with Lucene 2.3.2. It contains most of the same functionality as the Java version. mingw-clucene.src:70: W: setup-not-quiet mingw-clucene.src:15: W: mixed-use-of-spaces-and-tabs (spaces: line 15, tab: line 5) mingw32-clucene-debuginfo.noarch: E: debuginfo-without-sources mingw64-clucene-debuginfo.noarch: E: debuginfo-without-sources 5 packages and 0 specfiles checked; 7 errors, 2 warnings. Can you try to address these warnings where it makes sense, to cut down the noise a bit? One warning that is likely to remain is the debuginfo-without-sources: this is just a common warning with all mingw debuginfo packages, nothing wrong with this particular package. The other one you shouldn't directly fix is the incorrect-fsf-address: we aren't supposed to patch license files in downstream packages; instead, if you want to, you can file a ticket with upstream asking if they can update the LGPL.license file in the next release. + The package is named according to Fedora MinGW packaging guidelines + The spec file name matches the base package name. + The package meets the Packaging Guidelines + The package is licensed with a Fedora approved license and meets the Licensing Guidelines. + The license field in the spec file matches the actual license + The stated license is the same as the one for the corresponding native Fedora package + The package contains the license files (APACHE.license, COPYING, LGPL.license) + Spec file is written in American English + Spec file is legible + Upstream sources match sources in the srpm. md5sum: 48d647fbd8ef8889e5a7f422c1bfda94 clucene-core-2.3.3.4.tar.gz 48d647fbd8ef8889e5a7f422c1bfda94 Download/clucene-core-2.3.3.4.tar.gz + The package builds in koji n/a ExcludeArch bugs filed + BuildRequires look sane n/a locale handling n/a ldconfig in %post and %postun ! Package bundles copies of system libraries I can see copies of boost and zlib in the tarball, under src/ext/. Can you remove these in %prep to make sure the package doesn't use the bundled copies? n/a Package isn't relocatable + Package owns all directories it creates + No duplicate files in %files + Permissions are properly set + Consistent use of macros + The package must contain code or permissible content n/a Large documentation files should go in -doc subpackage + Files marked %doc should not affect package n/a Header files should be in -devel Not applicable to MinGW packages. n/a Static libraries should be in -static n/a Library files that end in .so must go in a -devel package n/a -devel must require the fully versioned base + Packages must not contain libtool .la files n/a Packages containing GUI apps must include %{name}.desktop file + Directory ownership sane + Filenames are valid UTF-8 Some minor nitpicks about the spec file: > Summary: A C++ port of Lucene Most of the mingw packages in Fedora mention mingw in their summary, often starting it with "Summary: MinGW ...". Might be nice to follow this convention here as well. > Group: Development/System The package management tools in Fedora don't make any use of the Group tag, so if you want to, all 3 Group tags here can be removed. > Patch52: mingw-clucene-core-2.3.3.4-fix-threads.patch Can you submit this upstream? > Provides: mingw32-clucene = %{version}-%{release} [...] > Provides: mingw64-clucene = %{version}-%{release} Please remove the these provides, they are now the same as the binary package names. > %setup -n %{_pkg_name}-core-%{version} Should be "%setup -qn ...", like rpmlint noted above. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

[Bug 825557] Review Request: mingw-clucene - CLucene 2.3.3.4 built for MinGW

by Red Hat Bugzilla

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=825557 --- Comment #15 from greg.hellings(a)gmail.com --- I've renamed the packages and removed the boost and pthreads dependencies. The library now builds a multi-threaded version. Spec is at the same URL as above. SRPM is at http://dl.thehellings.com/mingw32/clucene/mingw-clucene-2.3.3.4-3.fc17.sr... -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

[Bug 849693] CVE-2012-3509 libiberty: integer overflow, leading to heap-buffer overflow by processing certain file headers via bfd binary

by Red Hat Bugzilla

Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=849693 --- Comment #34 from Jan Lieskovsky <jlieskov(a)redhat.com> --- Statement: The versions of the gdb package, as shipped with Red Hat Enterprise Linux 5 and 6 are vulnerable to the original libiberty integer overflow flaw. But due the way of subsequent processing of the previously insufficiently pre-allocated libiberty buffer within gdb code, the impact of this issue is limited to crash only. Red Hat Security Response Team does not consider crash of end-user application, such as gdb, to be a security flaw. -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

[Bug 849693] CVE-2012-3509 libiberty: integer overflow, leading to heap-buffer overflow by processing certain file headers via bfd binary

by Red Hat Bugzilla

Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=849693 Bug 849693 depends on bug 860769, which changed state. Bug 860769 Summary: CVE-2012-3509 libiberty: integer overflow, leading to heap-buffer overflow by processing certain file headers via bfd binary [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=860769 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

[Bug 849693] CVE-2012-3509 libiberty: integer overflow, leading to heap-buffer overflow by processing certain file headers via bfd binary

by Red Hat Bugzilla

11 years, 5 months

1
0
0 / 0

[Bug 849693] CVE-2012-3509 libiberty: integer overflow, leading to heap-buffer overflow by processing certain file headers via bfd binary

by Red Hat Bugzilla

Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=849693 --- Comment #33 from Jan Lieskovsky <jlieskov(a)redhat.com> --- (In reply to comment #31) Hi Jan, > Jan, > is this bug therefore an "arbitrary code execution" exploitable or not? Depends on the way how you are asking: -------------------------------------- 1) If you are asking generally if CVE-2012-3509 flaw can be used for arbitrary code execution (an adversary to reach code execution under the privileges of the victim, when the victim inspects provided file remotely), then the reply would be yes. The CVE-2012-3509 flaw is believed to be able to cause arbitrary code execution. To actually reach this it would not be a trivial task though. 2) If you are asking if gdb packages (since embedding libiberty code) are prone to arbitrary code execution, then the reply would be no. The actual exploitation depends on the 'code around' processing result of bfd_alloc2() / _objalloc_alloc and from what I can tell so far for gdb case, the resulting buffer is under-allocated, but the subsequent routine is just zero-ying its content at: #2 setup_group (newsect=0x29a9bf0, hdr=0x29b2690, abfd=0x297a960) at ../../bfd/elf.c:607 routine, so explicitly for gdb this could not allow arbitrary code execution. > > IMO it is not, therefore it is a normal uninteresting crasher bug which has > been fixed upstream now and which is IMO not even worth a backport. There > are many such uninteresting invalid-input crasher bugs in GNU toolchain (see > Comment 2). See above. If we are talking about gdb case here, then yes, I agree. But for the rest of possibly affected packages the potential impact still needs to be investigated (to either confirm the danger or disprove it like in gdb case). -- You are receiving this mail because: You are on the CC list for the bug.

11 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw November 2012