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.patch
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
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
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
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
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
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
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]
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)
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]
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
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
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
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
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
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
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
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
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]
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
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
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
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
23 matches
Mail list logo
