Bug#987746: unblock: rhash/1.4.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: debian-security-to...@lists.debian.org Hello Release Team, please unblock rhash 1.4.1-2 The rhash/1.4.1-1 package introduced bug #987698: 'rhash --version' incorrectly outputs 'v1.4.0' instead of 'v1.4.1'. The patch is minimal, debdiff is attached. The fix can be easily tested: $ rhash --version RHash v1.4.1 No librhash interfaces were touched, so dependent packages will work without a rebuild. Kind regards, Aleksey diff -Nru rhash-1.4.1/debian/changelog rhash-1.4.1/debian/changelog --- rhash-1.4.1/debian/changelog2021-01-08 05:03:33.0 +0300 +++ rhash-1.4.1/debian/changelog2021-03-25 02:26:02.0 +0300 @@ -1,3 +1,9 @@ +rhash (1.4.1-2) unstable; urgency=medium + + * d/patches/0001-v1.4.1.patch fix incorrectly reported version + + -- Aleksey Kravchenko Thu, 25 Mar 2021 02:26:02 +0300 + rhash (1.4.1-1) unstable; urgency=medium * New upstream version 1.4.1 diff -Nru rhash-1.4.1/debian/patches/0001-v1.4.1.patch rhash-1.4.1/debian/patches/0001-v1.4.1.patch --- rhash-1.4.1/debian/patches/0001-v1.4.1.patch1970-01-01 03:00:00.0 +0300 +++ rhash-1.4.1/debian/patches/0001-v1.4.1.patch2021-03-25 02:26:02.0 +0300 @@ -0,0 +1,14 @@ +Description: Fix the program version reported by `rhash --version` +Origin: upstream, https://github.com/rhash/RHash/commit/eb9bc3ff3f4b2003c9441f43f5cd930a8d211ceb +Last-Update: 2021-03-25 +Forwarded: not-needed + +diff --git a/version.h b/version.h +--- a/version.h b/version.h +@@ -1 +1 @@ +-#define VERSION "1.4.0" ++#define VERSION "1.4.1" +-- +2.31.0 + diff -Nru rhash-1.4.1/debian/patches/series rhash-1.4.1/debian/patches/series --- rhash-1.4.1/debian/patches/series 1970-01-01 03:00:00.0 +0300 +++ rhash-1.4.1/debian/patches/series 2021-03-25 02:26:02.0 +0300 @@ -0,0 +1 @@ +0001-v1.4.1.patch OpenPGP_signature Description: OpenPGP digital signature
Bug#987698: rhash --version outputs wrong version
Package: rhash Version: 1.4.1-1 Severity: normal Control: tag -1 fixed-upstream Control: fixed -1 1.4.1-2 RHash from the 1.4.1-1 deb package outputs wrong version 'v1.4.0' instead of expected 'v1.4.1'. Commands to reproduce: $ rhash --version RHash v1.4.0 Upstream git has commit [1], which bumps RHash version and fixes this bug. The commit mistakenly has not been included into upstream release tarball. [1] https://github.com/rhash/RHash/commit/eb9bc3ff3f4b2003c9441f43f5cd930a8d211ceb -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rhash depends on: ii libc6 2.31-11 ii librhash0 1.4.1-2 Versions of packages rhash recommends: ii libssl1.1 1.1.1k-1 rhash suggests no packages. -- no debconf information OpenPGP_signature Description: OpenPGP digital signature
Bug#901962: CVE-2018-12096, CVE-2018-12097, CVE-2018-12098 were fixed in liblnk_20180626-1
Hello, All three CVE were fixed by the upstream version liblnk-20180626 and packaged by Debian as liblnk_20180626-1. All subsequent liblnk packages contain the fixes. === More details. As pointed by [1] CVE-2018-12096 is actually bug in the upstream project libuna. Upstream and Debian distribute libuna as part of the liblnk package. CVE-2018-12096 is fixed by commits [2] and [3] (adding check into libuna/libuna_utf8_string.c). The fix was included into upstream liblnk version 20180626 and into the Debian package liblnk_20180626-1. === As pointed by [1] CVE-2018-12097 and CVE-2018-12098 are actually fixed in the upstream issue 32 [4] by commit [5]: * Corrected unicode_value_size calculation in liblnk/liblnk_location_information.c for CVE-2018-12097 * Added data_size check into liblnk/liblnk_data_block.c for CVE-2018-12098 The fix was included into upstream liblnk version 20180626 and into the Debian package liblnk_20180626-1. [1] https://github.com/libyal/liblnk/issues/33 [2] https://github.com/libyal/libuna/commit/aca678aa7e49ca628f1b27a53fdea883fa8764bb [3] https://github.com/libyal/libuna/commit/f22aca8b649afe5cef529d9268186bfe591b7f89 [4] https://github.com/libyal/liblnk/issues/32 [5] https://github.com/libyal/liblnk/commit/cb7fe0c66a5a01c19f1953fc7814c4fedfdc5785 OpenPGP_signature Description: OpenPGP digital signature
Bug#925833: Fixed upstream
Hello!
This bug duplicates upstream issue #142:
https://github.com/a2o/snoopy/issues/142
It is fixed by PR https://github.com/a2o/snoopy/pull/143
The fix commit (PR merge) is
https://github.com/a2o/snoopy/commit/360bb18e16ceaca16a22b94be9e17fd5f2184c01
I've tried to extract the patch from commit (patch attached), but
compilation started to fail with another warning:
cmdline.c: In function ‘snoopy_datasource_cmdline’:
cmdline.c:71:79: error: comparison between pointer and zero character
constant [-Werror=pointer-compare]
71 | for (cmdLineArgCount=0 ;
*(snoopy_inputdatastorage->argv+cmdLineArgCount) != '\0' ;
cmdLineArgCount++);
|
^~
cmdline.c:71:30: note: did you mean to dereference the pointer?
71 | for (cmdLineArgCount=0 ;
*(snoopy_inputdatastorage->argv+cmdLineArgCount) != '\0' ;
cmdLineArgCount++);
| ^
cc1: all warnings being treated as errors
diff -Nur a/lib/inih/dev-update.sh b/lib/inih/dev-update.sh
--- a/lib/inih/dev-update.sh
+++ b/lib/inih/dev-update.sh
@@ -7,17 +7,27 @@
set -e
set -u
GITORIGINURL="https://github.com/benhoyt/inih.git;
-GITORIGINREF="master"
+GITREF="master"
TMPGITDIR="./_tmp-inih-git"
DESTDIR="."
DESTDIRSRC="./src"
+### Parse arguments
+#
+if [ "${1:-}" != "" ]; then
+GITREF="$1"
+fi
+echo "Using gitref: $GITREF"
+
+
+
### Clone the repo
#
rm -rf $TMPGITDIR
git clone $GITORIGINURL $TMPGITDIR
+(cd $TMPGITDIR && git checkout $GITREF)
@@ -30,7 +40,7 @@
### Apply patches
#
-patch -p3 < ./patches/0001-strip-value-quotes.diff
+patch -p0 < ./patches/0001-strip-value-quotes.diff
diff -Nur a/lib/inih/patches/0001-strip-value-quotes.diff
b/lib/inih/patches/0001-strip-value-quotes.diff
--- a/lib/inih/patches/0001-strip-value-quotes.diff
+++ b/lib/inih/patches/0001-strip-value-quotes.diff
@@ -1,9 +1,7 @@
-diff --git a/lib/inih/src/ini.c b/lib/inih/src/ini.c
-index 27ca85b..2c015c8 100644
a/lib/inih/src/ini.c
-+++ b/lib/inih/src/ini.c
-@@ -149,6 +149,17 @@ int ini_parse_stream(ini_reader reader, void* stream,
ini_handler handler,
- #endif
+--- src/ini.c.orig 2018-12-26 21:08:15.289767000 +
src/ini.c 2018-12-26 21:07:25.707778000 +
+@@ -187,6 +187,17 @@
+ value = lskip(value);
rstrip(value);
+/* Strip surrounding double and single quotes */
@@ -19,4 +17,4 @@
+
/* Valid name[=:]value pair found, call handler */
strncpy0(prev_name, name, sizeof(prev_name));
- if (!handler(user, section, name, value) && !error)
+ if (!HANDLER(user, section, name, value) && !error)
diff -Nur a/lib/inih/SOURCE.txt b/lib/inih/SOURCE.txt
--- a/lib/inih/SOURCE.txt
+++ b/lib/inih/SOURCE.txt
@@ -1,3 +1,3 @@
git-origin-url = 'https://github.com/benhoyt/inih.git'
-git-origin-ref = 'tags/r36-0-g5dbf5cb'
+git-origin-ref = 'tags/r42-0-g9d1af9d'
patches-dir = 'patches/'
diff -Nur a/lib/inih/src/ini.c b/lib/inih/src/ini.c
--- a/lib/inih/src/ini.c
+++ b/lib/inih/src/ini.c
@@ -24,6 +24,12 @@
#define MAX_SECTION 50
#define MAX_NAME 50
+/* Used by ini_parse_string() to keep track of string parsing state. */
+typedef struct {
+const char* ptr;
+size_t num_left;
+} ini_parse_string_ctx;
+
/* Strip whitespace chars off end of given string, in place. Return s. */
static char* rstrip(char* s)
{
@@ -64,7 +70,7 @@
/* Version of strncpy that ensures dest (size bytes) is null-terminated. */
static char* strncpy0(char* dest, const char* src, size_t size)
{
-strncpy(dest, src, size);
+strncpy(dest, src, size - 1);
dest[size - 1] = '\0';
return dest;
}
@@ -76,8 +82,14 @@
/* Uses a fair bit of stack (use heap instead if you need to) */
#if INI_USE_STACK
char line[INI_MAX_LINE];
+int max_line = INI_MAX_LINE;
#else
char* line;
+int max_line = INI_INITIAL_ALLOC;
+#endif
+#if INI_ALLOW_REALLOC
+char* new_line;
+int offset;
#endif
char section[MAX_SECTION] = "";
char prev_name[MAX_NAME] = "";
@@ -90,14 +102,40 @@
int error = 0;
#if !INI_USE_STACK
-line = (char*)malloc(INI_MAX_LINE);
+line = (char*)malloc(INI_INITIAL_ALLOC);
if (!line) {
return -2;
}
#endif
+#if INI_HANDLER_LINENO
+#define HANDLER(u, s, n, v) handler(u, s, n, v, lineno)
+#else
+#define HANDLER(u, s, n, v) handler(u, s, n, v)
+#endif
+
/* Scan through stream line by line */
-while (reader(line, INI_MAX_LINE, stream) != NULL) {
+while (reader(line, max_line, stream) != NULL) {
+#if INI_ALLOW_REALLOC
+offset = strlen(line);
+while (offset == max_line - 1 && line[offset - 1] != '\n') {
+max_line *= 2;
+if (max_line > INI_MAX_LINE)
+max_line = INI_MAX_LINE;
+new_line = realloc(line, max_line);
+if (!new_line) {
+free(line);
+
Bug#864602: Not enough information
It seems I've reproduced the crash by running the following command on an unmounted ext4 partition: sudo ./extundelete --restore-directory /home /dev/sdb1 After recompilation of the program under clang address sanitizer: make CC=clang CXX=clang++ CFLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer" the sanitizer gave the following results: - start of stdout - NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 96 groups loaded. Loading journal descriptors ... = ==2824==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62110100 at pc 0x0050b0bc bp 0x7ffcdaf56d80 sp 0x7ffcdaf56d78 READ of size 2 at 0x62110100 thread T0 #0 0x50b0bb in be16_to_cpu(unsigned short*) /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:302:8 #1 0x5062da in journal_block_tag_to_cpu(char*, journal_superblock_s*) /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:390:2 #2 0x504f6b in init_journal(struct_ext2_filsys*, struct_ext2_filsys*, journal_superblock_s*) /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:1052:6 #3 0x525a85 in examine_fs(struct_ext2_filsys*) /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/cli.cc:287:13 #4 0x5224d8 in main /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/cli.cc:807:12 #5 0x7fd47ce2409a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) #6 0x4235d9 in _start (/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete+0x4235d9) 0x62110100 is located 0 bytes to the right of 4096-byte region [0x6210f100,0x62110100) allocated by thread T0 here: #0 0x4fa7f2 in operator new[](unsigned long) (/home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete+0x4fa7f2) #1 0x5049dc in init_journal(struct_ext2_filsys*, struct_ext2_filsys*, journal_superblock_s*) /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:990:8 #2 0x525a85 in examine_fs(struct_ext2_filsys*) /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/cli.cc:287:13 #3 0x5224d8 in main /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/cli.cc:807:12 #4 0x7fd47ce2409a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/aleksey/OTHER/EXTUNDELETE/clang_1/src/extundelete.cc:302:8 in be16_to_cpu(unsigned short*) Shadow bytes around the buggy address: 0x0c427fff9fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fff9fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fff9ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffa000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c427fffa010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c427fffa020:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==2824==ABORTING - end of stdout - So the problem is somewhere in the init_journal() function. The heap-buffer-overflow occurred at extundelete.cc:1052: journal_block_tag_to_cpu( (char *)jbt, jsb ); on the block of size 4096 bytes, allocated at extundelete.cc:990 by line: buf = new char[ EXT2_BLOCK_SIZE(jfs->super)]; Regards, Aleksey >
Bug#864602: Not enough information
Hello, this bug report is still has not enough information. To narrow down the problem, we need a stacktrace. To get it, one need to run the program under gdb with extundelete debug package installed. Such report would be much better if the program be recompiled from sources without optimization: DEB_BUILD_OPTIONS='noopt debug' debuild -uc -us and then run under gdb: sudo gdb -ex run --args ./extundelete --restore-directory /user/bin/storage /dev/sdb1 Nevertheless, I've investigated the bug a bit and here is what I found. 1. First, I've viewed the source code for the cause of the error message: > *** Error in `extundelete': double free or corruption (!prev): > 0x01a95000 *** and did not found any double deallocations, only an insignificant memory leak at cli.cc:346. So the most probable cause of the message is a *heap corruption*, due to some out-of-bounds access (buffer overrun/underrun). 2. Another suspect is the src/block.c source file: > * This file was modified from e2fsprogs lib/ext2fs/block.c and extent.c > * These modifications allow undeletion with libext2fs 1.39 to 1.42.6, > * and possibly newer versions. Unstable currently has libext2fs-dev 1.44.5, so may be extundelete is linked against incompatible version of libext2fs. 3. Since extundelete is a pretty old program (last commit is on 2013-01-03), may be it just has bad support for modern ext4. Regards, Aleksey.
Bug#716182: Root cause and patch.
Hello, the easiest way to reproduce the problem is to run `./mergebad -s`. The mergebad utility doesn't check the number of required arguments and crashes, because NULL is passed to atoll() at: mergebad.c:315:length = atoll(argv[++loop]); I've prepared the quick-fix patch [1]. With minimum changes it adds checking of arguments number. The full solution would be to use getopt(), the same way as in the recoverdm.c. [1] https://salsa.debian.org/pkg-security-team/recoverdm/blob/debian/master/debian/patches/30-fix-BTS-mergebad-crash.patch Best wishes, Aleksey
Bug#848881: Solution
The same bug in the upstream github bugtracker [1]. Upstream already has commits with the fix [2], [3]. [1] https://github.com/baruch/gpart/issues/9 [2] https://github.com/baruch/gpart/commit/0529a52485411be351bb75d628edc187a53c0e40 [3] https://github.com/baruch/gpart/commit/cbdefb633797ccfbc86ec4c6268292f20621d20f Regads, Aleksey
Bug#848881: buggy code
Hello Ingo,
You should install gpart-dbgsym* package, to get a meaningful stacktrace.
It's a luck I've found the problem from your strace log ;)
The root cause is the code gpart-0.3/src/disku.c:80:
if (ioctl(d->d_fd,HDIO_GETGEO,) == -1)
pr(FATAL,EM_IOCTLFAILED,"HDIO_GETGEO",strerror(errno));
#ifdef BLKGETSIZE
if (ioctl(d->d_fd,BLKGETSIZE,) == -1)
pr(FATAL,EM_IOCTLFAILED,"BLKGETSIZE",strerror(errno));
g.d_nsecs = nsects;
g.d_c = nsects / (hg.heads * hg.sectors); // <- BUG HERE - devide by 0
as you can see from strace:
> ioctl(3, HDIO_GETGEO, {heads=0, sectors=0, cylinders=0, start=0}) = 0
so (hg.heads * hg.sectors) is here zero.
The latest version 1:0.3-5 contains the same code.
Regards,
Aleksey
Bug#901967: CVE-2018-11723 is fixed in libpff 20180714.
The actual bug heap-buffer-overflow beneeth the CVE-2018-11723 is described in the Issue #64 [1] in the upstream bugtracker. The bug is fixed in the version 20180714 by commit [2]. See also libpff author comments [3] on this CVE-2018-11723. [1] https://github.com/libyal/libpff/issues/64 [2] https://github.com/libyal/libpff/commit/7b92bcace7e743cc9417e3cc3e4eee29abb70cf5 [3] https://github.com/libyal/libpff/issues/66
Bug#753980: RFS: rhash-bindings/1.3.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package rhash-bindings * Package name: rhash-bindings Version : 1.3.2-1 Upstream Author : Aleksey Kravchenko rhash.ad...@gmail.com * URL : http://rhash.sf.net/ * License : RHash License Section : utils It builds those binary packages: librhash-cil-dev - development files for CLI bindings of LibRHash librhash-cil-doc - documentation for the CLI bindings of LibRHash librhash-java - Java interface for LibRHash hash sums calculation library librhash-java-doc - documentation for librhash Java bindings librhash-perl - Perl interface for LibRHash hash sums calculation library librhash-php5 - RHash module for PHP 5 librhash1.0-cil - CLI interface for LibRHash hash sums calculation library monodoc-rhash-manual - monodoc manual for the CLI bindings of LibRHash python-rhash - Python interface for LibRHash hash sums calculation library ruby-rhash - Ruby interface for LibRHash hash sums calculation library To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhash-bindings Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhash-bindings/rhash-bindings_1.3.2-1.dsc More information about rhash can be obtained from http://rhash.sf.net. Changes since the last upload: * New upstream release v1.3.2 - bump Standards-Version to 3.9.5 - perl module renamed to Crypt::Rhash Regards, Aleksey Kravchenko signature.asc Description: OpenPGP digital signature
Bug#750842: rhash: Rhash with recursion can be trapped in a loop (created with a symlink) forever
Mario, thanks for the patch! It's accepted upstream with small changes [1] ;) [1] https://github.com/rhash/RHash/commit/3d00ccb67d4a4e5b3bdc969edfc7094f46fa75e7 09.06.2014 16:48, Mario B. wrote: Package: rhash Version: 1.3.1-1 Followup-For: Bug #750842 Dear Maintainer, I've added a very simple patch (for UNIX systems at least), but now symlinks are ignored. I don't know if this is the best behaviour. Regards -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable'), (550, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rhash depends on: ii libc6 2.18-7 ii librhash0 1.3.1-1 Versions of packages rhash recommends: ii libssl1.0.0 1.0.1e-2+deb7u10 rhash suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#727012: rhash: Error value too large for defined data type for big files (4 GB)
Thanks for reporting! I will look into the bug :) 21.10.2013 21:14, Mario B. wrote: Package: rhash Version: 1.2.9-8+deb7u1 Severity: normal Dear Maintainer, rhash does not work with files bigger than 4 GB, and also the version 1.3.0-2 (on testing and Sid) is affected by the same problem. Instead md5sum, sha*sum and other tools work as expected. I don't know if it is a problem of the 32-bit architecture. There is a bug report for the upstream version of this program with a similar bug, but it has been reported as closed with the version 1.2.9: sourceforge.net/p/rhash/bugs/34 Input: $ rhash bigfile.ext Output: ; Generated by RHash v1.2.9 on 2013-10-21 at 16:10.17 ; Written by Aleksey (Akademgorodok) - http://rhash.sourceforge.net/ ; RHash: bigfile.ext: Value too large for defined data type Thanks for the attention. -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable'), (550, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rhash depends on: ii libc6 2.17-93 ii librhash0 1.2.9-8+deb7u1 Versions of packages rhash recommends: ii libssl1.0.0 1.0.1e-2 rhash suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#695852: unblock: rhash/1.2.9-8
Dear release team, It's the best time to unblock current stable rhash/1.2.9-8 now [1], cause I'm going to upload RHash release 1.2.10 to NEW with new features (e.g. php bindings). After it go through NEW, the next chance for unblocking will be only after 10 day period and when all rhash* packages smoothly compile on all platforms. With best wishes, Aleksey Kravchenko Maintainer of RHash package. [1] http://bugs.debian.org/695852 signature.asc Description: OpenPGP digital signature
Bug#695063: cli-common-dev: dh_cligacpolicy reports false warning on cli-common-dev version
Package: cli-common-dev
Version: 0.8.2
Severity: normal
Tags: patch
if a package Build-Depends on cli-common-dev (= 0.8~),
then dh_cligacpolicy reports wrong warning:
Warning! No Build-Depends(-Indep) on cli-common-dev (= 0.5.7)!
The attached patch fixes the bug by replacing the condition with more proper
one.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages cli-common-dev depends on:
ii debhelper 9.20120909
ii libxml-dom-perl1.44-1
ii mono-devel [strong-name-tool] 2.10.8.1-6
ii mono-utils [cil-disassembler] 2.10.8.1-6
ii perl-modules 5.14.2-15
cli-common-dev recommends no packages.
cli-common-dev suggests no packages.
-- no debconf information
--- dh_cligacpolicy.orig 2012-12-03 23:47:23.0 +0700
+++ dh_cligacpolicy 2012-12-03 23:48:54.772722367 +0700
@@ -87,7 +87,8 @@
open(FILE, 'debian/control');
my @filedata = FILE;
close(FILE);
- if (!($filedata[0] =~ /Build-Depends(-Indep)?: .*cli-common-dev \(= 0\.5\.7\)/)) {
+ if ($filedata[0] =~ m/Build-Depends(?:\-Indep)?\:(?:.*\n\s+)*.*cli\-common\-dev\s*\(=\s*([^\)]+)\)/
+ system(dpkg, --compare-versions, $1, =, 0.5.7) != 0) {
warning(Warning! No Build-Depends(-Indep) on cli-common-dev (= 0.5.7)!);
}
}
signature.asc
Description: OpenPGP digital signature
Bug#687398: rhash: diff for NMU version 1.2.9-7.1
Gentlemen, thank you for investigating such twisted issue! When building in parallel, sometime librhash.a was created prior to librhash.so and rhash_shared binary. The command 'mv rhash_shared rhash' preserved timestamp. Then wrong static 'rhash' binary was re-built by command 'make test' (as required by Makefile dependencies) but without all necessary CFLAGS. That led to linker error. The bug can be fixed by changing 'mv rhash_shared rhash' line to 'cp rhash_shared rhash' or 'mv rhash_shared rhash touch rhash'. I'm preparing a package with the fix and will upload it to ftpmaster asap. 26.11.2012 0:09, Michael Banck wrote: Hi, On Sun, Nov 25, 2012 at 05:31:55PM +0100, Michael Banck wrote: On Fri, Nov 02, 2012 at 05:13:57PM +0100, gregor herrmann wrote: Ok, NMU cancelled until this is sorted out ... For the record, I tried a build of Gregor's NMU patch using sbuild and DEB_BUILD_OPTIONS=parallel=4 on both i386 and amd64 and they both worked fine. Ok, in an i386 chroot on my amd64 machine I can reproduce this as well, just not every time... Michael signature.asc Description: OpenPGP digital signature
Bug#671989: rhash: FTBFS: make[3]: *** No targets specified and no makefile found. Stop.
Thanks for reporting! :) The bug occurred due to parallel build. The debian/rules command $(MAKE) -C bindings configure build caused the 'make -C ruby' to run earler then Ruby Makefile was created by the 'ruby -C ruby extconf.rb' command. signature.asc Description: OpenPGP digital signature
Bug#670205: rhash: FTBFS in binary-only mode: dh: unable to load addon cli
The problem can be reproduced by 'debuild binary-arch' with cli-common-dev package uninstalled. The proper fix (building arch-dependent packages only when requested), requires complicated debian/rules (attached) with many conditionals. This complicated script is hard to read, so I'll just move mono dependencies to Build-Depends. It looks like there is another way [1] to solve the bug, which utilizes dh_listpackages: ===8=== ifeq ($(shell dh_listpackages | grep -q cil echo yes),yes) DHWITH = --with cli endif %: dh $@ $(DHWITH) ===8=== But in reality it doesn't work: when running 'debuild binary-arch' the dh_listpackages prints all packages, including ones with 'Architecture: all'. [1] http://mail-archive.com/debian-cli@lists.debian.org/msg00103.html 24.04.2012 7:55, Aaron M. Ucko wrote: Source: rhash Version: 1.2.9-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Builds of rhash in minimal environments covering only its architecture-dependent packages (with Build-Depends but not necessarily Build-Depends-Indep available) are failing: fakeroot debian/rules clean dh clean --with=python2 --with=cli dh: unable to load addon cli: Can't locate Debian/Debhelper/Sequence/cli.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at (eval 4) line 2. BEGIN failed--compilation aborted at (eval 4) line 2. make: *** [clean] Error 2 Please either move cli-common-dev to Build-Depends or arrange to pass --with=cli only when it is actually safe to do so. Thanks! #!/usr/bin/make -f # debian/rules makefile that uses debhelper. # # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 INSTALL_PROGRAM = install -p -m 755 CFLAGS = -Wall -DUSE_GETTEXT LIBCFLAGS = LIBLDFLAGS = DESTDIR = $(CURDIR)/debian/tmp LIBRHASH_INC=-I$(DESTDIR) LIBRHASH_LD=-Wl,--as-needed -L$(DESTDIR) JAVADOC_API_URL=/usr/share/doc/default-jdk-doc/api # see Debian Policy Manual - source packages ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 -DNDEBUG else CFLAGS += -O2 -DNDEBUG -fomit-frame-pointer endif ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g endif ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) endif # by default compile RHash with openssl runtime linking ifeq (,$(findstring nossl,$(DEB_BUILD_OPTIONS))) LIBCFLAGS += -DUSE_OPENSSL ifneq (,$(findstring ssldynamic,$(DEB_BUILD_OPTIONS))) LIBLDFLAGS += -lcrypto else LIBCFLAGS += -DOPENSSL_RUNTIME -rdynamic LIBLDFLAGS += -ldl endif endif # using debhelper = 8 to build the package # we use this intricate logic to allow 'debuild binary-indep' without mono packages installed build: BUILDARCH=all dh $@ --with=python2 --with=cli binary: BUILDARCH=all dh $@ --with=python2 --with=cli binary-arch: BUILDARCH=arch dh $@ # only arch-independent packages really need python2 and cli binary-indep: BUILDARCH=indep dh $@ --with=python2 --with=cli %: BUILDARCH=indep dh $@ # bindings to provide ifeq ($(BUILDARCH),all) BINDINGS = java mono perl python ruby else ifeq ($(BUILDARCH),arch) BINDINGS = java perl ruby else BINDINGS = java mono python endif ifneq ($(LD_LIBRARY_PATH),) LD_LIB=$(DESTDIR):$(LD_LIBRARY_PATH) else LD_LIB=$(DESTDIR) endif override_dh_auto_build: # Compile the package. $(MAKE) lib-static lib-shared LIBCFLAGS=$(CFLAGS) $(LIBCFLAGS) LIBLDFLAGS=$(LIBLDFLAGS) ifneq ($(BUILDARCH),indep) $(MAKE) rhash-shared CFLAGS=$(CFLAGS) SHARED_TRG=rhash endif # prepare local librhash include/lib directories mkdir -p $(DESTDIR) ln -fs $(CURDIR)/librhash $(DESTDIR)/rhash ln -fs $(CURDIR)/librhash/librhash.so.0 $(DESTDIR)/ ln -fs $(DESTDIR)/librhash.so.0 $(DESTDIR)/librhash.so # Compile language bindings. $(MAKE) -C bindings configure build JAVADOC_API_URL=$(JAVADOC_API_URL) \ LIBRHASH_INC=$(LIBRHASH_INC) LIBRHASH_LD=$(LIBRHASH_LD) BINDINGS=$(BINDINGS) ifneq ($(BUILDARCH),indep) chrpath -d bindings/perl/blib/arch/auto/Rhash/Rhash.so endif override_dh_auto_test: ifneq ($(BUILDARCH),indep) $(MAKE) test-lib test-shared CFLAGS=$(CFLAGS) \ LIBLDFLAGS=$(LIBLDFLAGS) SHARED_TRG=rhash endif $(MAKE) -C bindings test LD_LIBRARY_PATH=$(LD_LIB) BINDINGS=$(BINDINGS) override_dh_auto_install: ifneq ($(BUILDARCH),indep) # Install the program and its translation strings $(MAKE) PREFIX=/usr
Bug#654180: rhash: FTBFS with ld --as-needed
Hello! There is already a patch [1] in the upstream source tree, solving this problem. It fixes compilation on Ubuntu and allows using the --as-needed option. The upstream fix will be included in the nearest package release. [1] https://github.com/rhash/RHash/commit/1e98cb8bc2a525e7da9ef8e13505f53d1f87f20c 02.01.2012 15:33, Ilya Barygin wrote: Package: rhash Version: 1.2.8-2 Severity: normal Tags: upstream patch User: debian-...@lists.debian.org Usertags: ld-as-needed rhash fails to build when --as-needed linker option is enabled, because of incorrect order of parameters passed to ld. As a result, librhash-jni.so was underlinked and tests failed. Here's a log of failed build in Ubuntu: https://launchpad.net/ubuntu/+source/rhash/1.2.8-2/+build/3003545/+files/buildlog_ubuntu-precise-i386.rhash_1.2.8-2_FAILEDTOBUILD.txt.gz See also http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries http://wiki.mandriva.com/en/Underlinking Patch from Ubuntu attached. https://launchpad.net/ubuntu/+source/rhash/1.2.8-2ubuntu1 -- System Information: Debian Release: wheezy/sid APT prefers oneiric-updates APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 'oneiric-proposed'), (500, 'oneiric'), (100, 'oneiric-backports') Architecture: i386 (i686) Kernel: Linux 3.0.0-15-generic (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: OpenPGP digital signature
Bug#652968: debian-maintainers: Please add Aleksey Kravchenko as a Debian Maintainer
Package: debian-maintainers Severity: normal Tags: patch Please add my key to the DM keyring. See attached jetring changeset. Thanks. Aleksey Comment: Add rhash.ad...@gmail.com as a Debian Maintainer Date: Thu, 22 Dec 2011 17:36:58 +0700 Action: import Recommended-By: Kilian Krause kil...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2011/10/msg00010.html Advocates: http://lists.debian.org/debian-newmaint/2011/10/msg00029.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBE4NrSYBEACU9ljBHEZggbmOfMvfBVqtIuOX7hfT2hBb/CwjJyanGI9X5a07 ezKcoS+QcCFn9HkQ8/H1dTtLcpqjyiuume1LPQAY960sIKSHbcfcTZU+B4EQDSMP S6Gsgwzyk7vmdJsMIEYnm51J9vrT+cWT03Kgvna6NaG8zaQDsMaCEvXZEDu1BKOt vOKmi9ovo7XMAkOXvMY4Rl4cUNv1PCtkfsqcxmrMvtVnvJJJ1tdx5KK1Rox9GyO4 PuUmsoNkE8NlNHkVeRVxSafE1W8d8QvpDS2pwmMvjCB1MBoBlEcgn5iWU5HtMiq7 GbV8ydffgFSq8E+I/wEH0yiy2fn4BEtUuPOlQhj+NxpFaD4zU6p5ZeuZr4jhzeSn KO5CMkzAJYO09vQFlkVQ1y7S89hjiLmIJu8M2kF6F7yQ5ebrQcT+XoVXu4vmAmhm 6itXV1Z0ici51/DEwc6f8rWhkunHIpJSQ77PxdijMBPH36ruB330n6RFY/G6TK76 95sfA1EsZ/XCMKe5/VSWcFuCbYinss+o4bQVa0Vd1HrW90Yyn3BFqKDyephUcnwi 7Xg6278S4lG4JAy6FOCnkCoSjlG6cwX6xojCftTsHvptVa/oAXDHpYnmGe/9qnGZ jQwiS9cpj6kRKuuQz1q6hsoHvIpYdmGz9CsCYvCfsZuZKnkFszxmWGakoQARAQAB tCpBbGVrc2V5IEtyYXZjaGVua28gPHJoYXNoLmFkbWluQGdtYWlsLmNvbT6JAjcE EwEIACEFAk4NrSYCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQKnFEl+Nz Y66/GA//bp0tGf+s8eX4wduYIqeTowkHhj1HuT91CWUBe1G26ELIt48c65UwBVyQ RZGeqW/Ntxx8UbFegO8iFwqTgvqcqjYP/ac4MI4AthidwMA+qtuUg66YGOAZPXm0 HLWB6a59Az+M16hsvo4u33Lg3sJoyHdp7oo4Gol95tBmgfFcKT9zU7MCe78dme1y I0U6xj646jWr4lxM0Riz/fUilb1jELKwuj1xCZoEEqh4KOsC8JpcOVqtRkUjfRZ3 BJ1c1SaV/Y8Yy7lNdpJb3Ij03jahGDhwKNDdbt1J90DDYBwXq6kmQbUDXS+qR+Kt teU5yApwVDVJIrdk/VltLzDmRbRR168fly0JOXd51P2ra9HLRb15zYmX6CnkRV/1 q51xWTCtfUWVMIf8ICDzeSKBFUC57bHfUcyM6vYpmRvp0BuI156vXBV5D8xsmNYj +ICB76CFMoSJ4w3ImRGFeBVBrtfWz7HQdAOsb3uOySo/Cff4qkwfOXQVINn0/ITZ Bxw2EaIktBRDtSqkcUbxIq1oSom4FFTs4Jy3RjaHDeFOJkFyyaKsOmRgdEf6qkbA qiZZZ5oJwzGpXBUWKq7ECED9B0qZhoj2KIs4pNTwfeRtvTe2ag0gdgd7kSvY7RPt xtzbrLQ59eT3J4qCCmnpSPRmjLXJH+xGZFEtWTAVN+NhA9WhrfqJARwEEAECAAYF Ak5q+Z0ACgkQnjY8gMYdrN+6igf7Bm/oO/Yn1GBDMqs4xuUXjm4cKUtUNyCREMsZ mFQ5GTxRUJab/Jt/tDrwVmMnGJKPF4wCCaAd8Su5yrI+UPsq24PtTeJmNDZK+LeD MiDe7g12aApsavCpOK/OR2PUUdfCAbk/OwpLWt9lHrTREVIk8Z+/+0LI3Hfsj2p2 L1cGmuwGcZGcZMVhFaRtyzVh02YfojXgXpCXMpi9GD2CEIBv79V/0QJYkqKOPDGR JZFOjNhCCCdkINMO0+06Q/oEkZuQypcZzkbEx71Ns13/FOYB03ZIc8qQ8AZT2pMG dLdKVaEPJ/hiLkwDdTlycQBBoOP6gC64+m00nL7qqsaQZRCcjIhGBBARAgAGBQJO bafFAAoJENly8UZA95sG0ksAoIrSIWOrgTBXBj/Ol0elANhI7ZBlAKDDPnpCGjr3 4SeKOhWiWaQOh/7+OohGBBARAgAGBQJOdF0hAAoJEF+Q2XSZ9fVdaasAoKCmDSnG b9/CsSuFhSa4LiPbfDKjAKCEuitA4Ci4/y3SoUAFWMjBNUU1UIhGBBARAgAGBQJO dF14AAoJEBAQAkn9OdNy5vMAmQEo41Z9DveH0F4yqbDm1zSJ3rMGAJ0TIRaDVd00 bQrD6GY9lhyxIhMKp4kCHAQQAQIABgUCTnSzRAAKCRCdIPZQPjOIiI6AD/wIuArw z7C3pwhGDHDaXq8lCpZwHjE+YaPU1sxHqtR1wrSloUnmYDTom8nm6chibtVOiP4c +qOQpVlA61ZkyLRxMG9BPwRHHFPuvQmd3DCrRtmw3eFfFDZvmNefbbJvS3cC4MdH HBxbkMJQcfzNkwuv/QMPe1QvBm9lIUHKhcMRmHE25iIv9XcHfnzxdmv1072tYC9s GEyCxhhoMSO+/BS1+d2u5biT5VCoKo29tzbxv0mXW4QED2YNe3daJXzP8Fr+M0yW r49XcPPTsUezPbuG7bSPYH/YHxgKs3wjDp8zUy8XDCHWpBLZu/UfhGubQhVWf9wl V1OJZErO3oxeVGGuu1LJkkPRz+ltY0uqbXDks0kf60xfwHuFl5c/j5Lo3NaXkNii sBfXVRfL4nirltb0YGXH9brLshfzARHjocUa/ZeP14iUDuGHvPigdLVsMkQZYt/u m0BX3LyI3IEgOvX8kQPmHcr4uffcOmmJbl/3ndMXPfdEiZDRv6YCJ9JuB8lAKZ5s tHWzFABmkfdWXVp0OElaNuVQtOWpLI2idtrNWqOPhqD8tLOgqSwBcvzVRGiniJd6 3Vk6ifmT8btWVFJ6m41v9x6cmztINf6Z4WsnC/UiAAxt49mo68CAInksOiVOL9Wq UwfLUg8kDBOu/NIGxmWW7EgtvjeY/hodaRN6GrkCDQRODa0mARAAs7qWOytyzsLA fjqFAraCDeZ1EQfwbdioiCgXZHVbCP1JYi0bxukpvINu+lRCmH7DEQZGtKKj2Pmo KleIDIMTpAfCP+ToewoQZPaMarIkaPD7/F+2pQgfNisH/SLD2s4293FkVGIwpM/i Bqq+ryE1gYdYwGaSxRUotU/lVPhDKadcDr4raz8eI7qxGJdjmESu/jk0LnhxuFjS awETeT2djkYaOxHRfRGB0fbnZ4loO686aJR2uUNwPs1+qbaGnfXMuA2PQPSvA/kg xcsXYHwigfjm7sGmQXYCq5a9YgrSaHMqXSftaMtMlaJl2i4ZDrEP1+Xks86n7W9W KxkWVwopBjNWu4AIrpZxDYe20T9a57pmxutaTsvZcftjMpHsU/7mtvVCE4ezad+A CuES5vXTAPJVDIgfralPjmu3New2gZpuAYQYEQnDGOj8U8wcGLbn5rZAwTpzFMhP svJnUoQK2jV+ifaVZs8GcIxzYeK3r30WEZ8kLK9coYZ4iu/6/MiyCzT/lEy/vJ0U lgeHwUfbLQbUyFQ9jaAouiXx/cIiW9KFiFlv99lpyB/pevqNKZPyAwegtgtyv90Q b3z5weyjc7Tv/aQ59FJgIgnwVhX8DBPDyPepkc3kCbAGyci/USv6eIBvfRPkMNBj W7ln2WLh7LNw3mmqyZ7KndtKTrcGsqsAEQEAAYkCHwQYAQgACQUCTg2tJgIbDAAK CRAqcUSX43NjrmAeD/0RDVoRHFJJOvDRnqueA3EAKjjiuB9/j5DJftwtmgO65igc rpNs8BARb8Tssg/iYWDQ0Y4uVtjuotgF/znTvKvwvru0O5S3geHdv4+dMfKasIEA 8N/r+KA7VM3OazGNzg6sux0mE+mQWNvIqgMMpYkTJxct9Ig7UQb38FSPuYRm+Ygh YZ5QH+ql7FhUY0UlC6KUEhjDsnWsEWY61dnrM2D7alh0+RYp579LFEEqzW2FgfUv tw/0DV6ifJ8GN28/vWi2iSBYiGssZ9LIqLsop9LQQTGhDkDmRRyLf7cKA4siHnSp 5z5Uxaq3Y4pzOSxRiIAAtHMxpX37/MrBnjjnBTfqIhjYzK5M8JV+drL9KiyQ9Bf6 bMSYFlC0NBrpVyAyjxsfxAGHavcKTSUIWXl9d9OB2sA2GWrImYsbS2X5fcVDisaW 34UjJj7UXzKDowdI7idlI9xr8tNtMrlscsKtN6pf2q+3HROBL4OFx+xNeV8FperB 08544GBbj2H1dw79950LiVwZgUt/NWr53AJ0E5jTLwvw+Ia1kYppD0H8sb33t+hy
Bug#652302: python-rhash: cannot be imported
After 'apt-get upgrade' and removing some python packages I've got this error. So, thanks for reporting it! The bug is caused by python-rhash*.deb having being built without python2 support. signature.asc Description: OpenPGP digital signature
Bug#652302: python-rhash: cannot be imported
Can't reproduce the bug.
The following script perfectly works after installing
python-rhash and librhash0:
--- start of test_rhash.py ---
import rhash
hasher = rhash.RHash(rhash.CRC32, rhash.MD5)
hasher.update('Hello, ')
hasher.update('world!')
hasher.finish()
print hasher.HEX(rhash.CRC32)
print hasher.hex(rhash.MD5)
--- end of test_rhash.py ---
signature.asc
Description: OpenPGP digital signature
Bug#632280: The issue is fixed in Git
First, thanks for reporting. This issue is fixed in Git and the fix will come with v1.2.7 release. Being a bug from user's point of view, actually this issue is due to half-implemented sha256/sha512 support - without hash verification. So up to this point the issue concerns all previous RHash version. In more details. RHash up to v1.2.6 can't uniquely identify a hash function by hash length, so it supposed that all 128-bit hashes are MD5 or ED2K all 256-bit hashes are GOST R 34.11-94 hash all 512-bit hashes are Whirlpool Now the parsing of hash files and verification code was rewritten. If the program can't detect the precise hash function for say a 256-bit hash, then the program will calculate all supported 256-bit hashes and verify the hash value against all of them. To speed up verification, user can now specify exact hash function at command line. signature.asc Description: OpenPGP digital signature
