Bug#874418: libdislocker0.7: fails to upgrade from 'stretch' - trying to overwrite /usr/lib/libdislocker.so

2017-09-05 Thread Andreas Beckmann
Package: libdislocker0.7
Version: 0.7.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libdislocker0.7.
  Preparing to unpack .../libdislocker0.7_0.7.1-2_amd64.deb ...
  Unpacking libdislocker0.7 (0.7.1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libdislocker0.7_0.7.1-2_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/libdislocker.so', which is also in package 
libdislocker0.6 0.6.1-7
  Errors were encountered while processing:
   /var/cache/apt/archives/libdislocker0.7_0.7.1-2_amd64.deb

Why is this .so link in the shared library package and not in
the -dev package?

And please get rid of the insane idea of a libdislocker0.6
transitional package in sid.


cheers,

Andreas


libdislocker0.6=0.6.1-7_libdislocker0.7=0.7.1-2.log.gz
Description: application/gzip
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

Bug#873679: dislocker: libdislocker* renamed without transition packages

2017-09-05 Thread Andreas Beckmann
On Wed, 30 Aug 2017 00:31:15 -0300 Giovani Augusto Ferreira
<giov...@debian.org> wrote:
> The libdislocker* packages were renamed without following
> the guidelines at https://wiki.debian.org/RenamingPackages
> and this will cause failures during upgrade.

WTF? Transitional packages for shared libraries are an insane idea.
That's what we have library transitions for.


Andreas

___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel


Bug#872132: gpart: fdisk build-dependency needed (for tests)

2017-08-14 Thread andreas
Source: gpart
Version: 1:0.3-3
Severity: important
User: util-li...@packages.debian.org
Usertags: fdisk-recommends-suggests

Hello,

As recently announced on debian-devel-announce[1] packages who need
any of sfdisk, cfdisk or fdisk will need to add a dependency on the
new fdisk package.

Your package gpart showed up on codesearch.debian.net and a very
quick analysis suggested you might not want to use a strict depends
but rather a recommends or suggests (and/or build-dependency if you
use it at build-time, eg. tests).

Please use the backwards-compatible way of specifying the
relationship as suggested in the debian-devel-announce mail:

fdisk | util-linux (<< 2.29.2-3~)

(and if only for tests you might want to add the build profile
)

Please reassign this bug report to the binary package shipping the
affected part of your source.

If your more detailed analysis shows this relationship should not be
needed at all please just close this bug report stating the results
of your analysis (and if so sorry for bothering you).

Regards, Andreas Henriksson

[1]:
https://lists.debian.org/debian-devel-announce/2017/08/msg5.html 

___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel


Bug#866373: rkhunter: /dev/null is recognized as an ASCII file

2017-06-29 Thread Andreas Schwarz
Package: rkhunter
Version: 1.4.2-6
Severity: normal

Dear Maintainer,

we get strange warnings from rkhunter on debian stretch.
Minimal command to reproduce: rkhunter --check --enable filesystem

Result: 
Info: Starting test name 'filesystem'
Performing filesystem checks
Info: SCAN_MODE_DEV set to 'THOROUGH'
  Checking /dev for suspicious file types [ Warning ]
Warning: Suspicious file types found in /dev:
 /dev/null?: ASCII text

Debug Output (--debug):
[...]
+ /usr/bin/find /dev ! -type d -a ! -type l
+ [ 0 -eq 1 ]
+ echo /dev/null^M
+ grep /\.[^/]*$
+ test -z 
+ do_dev_whitelist_check
+ /usr/bin/file /dev/null^M
+ awk -F: { print $NF } 
+ cut -c2-
+ FTYPE=ASCII text
+ echo ASCII text
+ grep universal binary
+ [ 0 -eq 1 -a -n  ] 
+ echo ASCII text
+ egrep -v (character special|block special|socket|fifo \(named pipe\)|symbolic 
link to|empty|directory|/MAKEDEV:)
+ [ -z ASCII text ]
+ echo /dev/null^M
+ sed -e s/\([.$*?\]\)/\\\1/g; s/\[/\\[/g; s/\]/\\]/g
+ FNAMEGREP=/dev/null^M
+ echo  
+ grep ^/dev/null^M$
+ [ -n  ] 
+ FOUNDFILES=
/dev/null^M: ASCII text
[...]

Manual check:
/usr/bin/file /dev/null
/dev/null: character special (1/3)

/usr/bin/file /dev/null|awk -F: '{ print $NF }'|cut -c2-
character special (1/3)

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/16 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rkhunter depends on:
ii  binutils   2.28-5
ii  debconf [debconf-2.0]  1.5.61
ii  file   1:5.30-1
ii  lsof   4.89+dfsg-0.1
ii  net-tools  1.60+git20161116.90da8a0-1
ii  perl   5.24.1-3
ii  ucf3.0036

Versions of packages rkhunter recommends:
pn  bsd-mailx | mailutils | heirloom-mailx | mailx  
ii  curl7.52.1-5
ii  iproute24.9.0-1
ii  postfix [mail-transport-agent]  3.1.4-7
ii  unhide  20130526-1
ii  unhide.rb   22-2
ii  wget1.18-5

Versions of packages rkhunter suggests:
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
pn  powermgmt-base  

-- Configuration Files:
/etc/rkhunter.conf changed [not included]

-- debconf information excluded

___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel


Bug#863460: hashrat: Seems to produce wrong results on big files

2017-05-27 Thread Andreas Moog
Package: hashrat
Version: 1.8.3+dfsg-2
Priority: important

Hi there,

there's something wonky going on when using hashtag's sha512 hash for big
files (10 Gig in this case):

$ fallocate -l 10G sha512test
$ sha512sum sha512test 
0a9ed4396868700784918a83a595845d70e582eb0e625c48ace24f4ee94e705247e210339c5f5a55e597f00d2c3217b0c0797e1bfc617161e00de96eaee2d068
  sha512test

$ hashrat -sha512 sha512test 
hash='sha512:cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e'
 type='file' mode='100644' uid='1000' gid='1000' size='10737418240' 
mtime='1495871799' inode='12058626' path='sha512test'

$ echo 1 >> sha512test 
$ sha512sum sha512test 
ae6565b7a9761d6524262738fe252121393aa3fc4987794f5f10175407e212ca81cf04edca949b0316947342e85eca4902dbd445cd53b703c316e5b2979cc976
  sha512test

$ hashrat -sha512 sha512test 
hash='sha512:cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e'
 type='file' mode='100644' uid='1000' gid='1000' size='10737418242' 
mtime='1495871852' inode='12058626' path='sha512test'

It looks like some sort of caching is going on, despite the "-cache" option
is not being used.

For small files it works as expected:

$ fallocate -l 1M sha512-1M-test
$ hashrat sha512-1M-test -sha512
hash='sha512:d6292685b380e338e025b3415a90fe8f9d39a46e7bdba8cb78c50a338cefca741f69e4e46411c32de1afdedfb268e579a51f81ff85e56f55b0ee7c33fe8c25c9'
 type='file' mode='100644' uid='1000' gid='1000' size='1048576' 
mtime='1495872206' inode='12058627' path='sha512-1M-test'

$ echo 1 >> sha512-1M-test 
$ hashrat sha512-1M-test -sha512
hash='sha512:5fc50c214f3928dcdec8f4e3d7c765aadd08cf6de9d65c64f68d4945d4a9e320bae56437a637ded05788b6aedbf074fdc73969c5f513b3938da72ce0efba3728'
 type='file' mode='100644' uid='1000' gid='1000' size='1048578' 
mtime='1495872221' inode='12058627' path='sha512-1M-test'

Let me know if I should provide any more information.

Cheers,
 Andreas

-- 
PGP-encrypted mails preferred
PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624


signature.asc
Description: PGP signature
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

Google Alert

2017-02-27 Thread Andreas Mosor
Sehr geehrter Google User,

Wir waren überrascht, eine E-Mail mit einer Gewinnaussage zu erhalten, von 
Herrn Larry, dem Direktor von Google, der in Großbritannien lebt, dass Ihre 
E-Mail unter den zwölf ausgewählten glücklichen Gewinnern der Summe von 950.000 
Tausend Pfund für den Google Webbrowser Won ist .
Ihre gewinnende Identitätsnummer ist GFSP / 4877/7782 / UK

Füllen Sie diese Informationen aus

(1) Voller Name:
(2) Land:
(3) Beruf:
(4) Mobilnummer:


Beachten Sie, dass Sie nur auf diese Nachricht antworten können, wenn Sie der 
rechtmäßige Eigentümer dieser E-Mail-Adresse sind.

 Ihr Gewinn dokument wird Ihnen so schnell wie möglich weitergeleitet

 Grüße
Andreas Mosor
Google Team
Europa
Kopieren; 2017 Google Corporation.
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

Bug#794045: hashdeep: fails to upgrade from md5deep/experimental

2015-07-29 Thread Andreas Beckmann
Package: hashdeep
Version: 4.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'md5deep' in 'experimental' to hashdeep in sid.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

From the attached log (scroll to the bottom...):

  Selecting previously unselected package md5deep.
  Preparing to unpack .../md5deep_4.3-3_amd64.deb ...
  Unpacking md5deep (4.3-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/md5deep_4.3-3_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/hashdeep.1.gz', which is also in 
package hashdeep 4.4-1
  Errors were encountered while processing:
   /var/cache/apt/archives/md5deep_4.3-3_amd64.deb

(that log is in the opposite direction, but it clearly indicates missing
Breaks and Replaces. Currently there are

Package: hashdeep
Version: 4.4-1
Replaces: md5deep ( 4.3-3~)
Provides: md5deep
Breaks: md5deep ( 4.3-3~)

but experimental has md5deep 4.3-3 which is not covered.


cheers,

Andreas


hashdeep=4.4-1_md5deep=4.3-3.log.gz
Description: application/gzip
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

Bug#788273: lime-forensics-dkms: fails to build for Linux 4.0

2015-06-09 Thread Andreas Beckmann
Package: lime-forensics-dkms
Version: 1.4-2
Severity: serious
Tags: sid stretch
User: debian...@lists.debian.org
Usertags: piuparts

from make.log:

DKMS make.log for lime-forensics-1.4-2 for kernel 4.0.0-2-586 (x86_64)
Tue Jun  9 21:18:17 UTC 2015
make: Entering directory '/usr/src/linux-headers-4.0.0-2-586'
  LD  /var/lib/dkms/lime-forensics/1.4-2/build/built-in.o
  CC [M]  /var/lib/dkms/lime-forensics/1.4-2/build/tcp.o
/var/lib/dkms/lime-forensics/1.4-2/build/tcp.c: In function 'write_vaddr_tcp':
/var/lib/dkms/lime-forensics/1.4-2/build/tcp.c:133:9: error: unknown field 
'msg_iov' specified in initializer
  struct msghdr msg  = { .msg_iov = iov, .msg_iovlen = 1 };
 ^
/var/lib/dkms/lime-forensics/1.4-2/build/tcp.c:133:9: error: unknown field 
'msg_iovlen' specified in initializer
/usr/src/linux-headers-4.0.0-2-common/scripts/Makefile.build:263: recipe for 
target '/var/lib/dkms/lime-forensics/1.4-2/build/tcp.o' failed
make[3]: *** [/var/lib/dkms/lime-forensics/1.4-2/build/tcp.o] Error 1
/usr/src/linux-headers-4.0.0-2-common/Makefile:1407: recipe for target 
'_module_/var/lib/dkms/lime-forensics/1.4-2/build' failed
make[2]: *** [_module_/var/lib/dkms/lime-forensics/1.4-2/build] Error 2
Makefile:145: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make: *** [all] Error 2
make: Leaving directory '/usr/src/linux-headers-4.0.0-2-586'


Andreas

___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel


Bug#762118: Install fails on tr_TR.UTF-8 locale

2014-09-18 Thread Andreas Moog
Package: rkhunter
Version: 1.4.0-3
Severity: normal

Hi there,

when installing rkhunter with LANG=tr_TR.UTF-8 the installation fails,
but it succeeds when using LANG=C or LANG=de_DE.UTF-8:

(sid-amd64)root@anubis:~# LANG=tr_TR.UTF-8 apt-get install rkhunter 
--no-install-recommends
Paket listeleri okunuyor... Bitti
Bağımlılık ağacı oluşturuluyor   
Durum bilgisi okunuyor... Bitti  
Önerilen paketler:
  bsd-mailx mailutils heirloom-mailx mailx tripwire libdigest-whirlpool-perl 
liburi-perl libwww-perl powermgmt-base
Tavsiye edilen paketler:
  default-mta mail-transport-agent wget curl links elinks lynx unhide.rb unhide 
lsof
Aşağıdaki YENİ paketler kurulacak:
  rkhunter
0 paket yükseltilecek, 1 yeni paket kurulacak, 0 paket kaldırılacak ve 0 paket 
yükseltilmeyecek.
0 B/248 kB arşiv dosyası indirilecek.
Bu işlem tamamlandıktan sonra 897 kB ek disk alanı kullanılacak.
Paketler önyapılandırılıyor ...
Selecting previously unselected package rkhunter.
(Reading database ... 13021 files and directories currently installed.)
Preparing to unpack .../rkhunter_1.4.0-3_all.deb ...
Unpacking rkhunter (1.4.0-3) ...
E: Sub-process /usr/bin/dpkg returned an error code (1)
(sid-amd64)root@anubis:~# LANG=C apt-get install rkhunter 
--no-install-recommends
Reading package lists... Done
Building dependency tree   
Reading state information... Done
rkhunter is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up rkhunter (1.4.0-3) ...
(sid-amd64)root@anubis:~# 

Let me know if I can do anything to help resolving this issue.

Cheers,
  Andreas

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (650, 'unstable'), (450, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

Bug#713364: libewf transition and #713364

2013-11-30 Thread Andreas Beckmann
Hi Andreas,

On Saturday, 9. November 2013 23:10:04 Andreas Moog wrote:
 I have taken the 2 patches from upstream that I mailed in September to
 the bugreport and made a debdiff for a NMU upload. I don't have upload
 rights though so I would need a sponsor to actually upload to Debian.

thanks for preparing the NMU.
I added some symbol updates and uploaded this to DELAYED/2.

The two commits can be found (soon - waiting for an alioth cronjob to create 
some symlinks) in the sid branch on 

git://git.debian.org/users/anbe/tmp/sleuthkit.git
git+ssh://git.debian.org/git/users/anbe/tmp/sleuthkit.git

I'll push a signed tag there once the package got into sid.


Andreas

___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel


Re: libewf transition and #713364

2013-11-09 Thread Andreas Moog
On 08.11.2013 22:35, Niels Thykier wrote:

   However, sleuthkit suffers from #713364 which is a FTBFS bug, so I
 have no reason to believe a binNMU will be successful.
[...]
 Comments welcome, a fix for #713364 in sid (or deferred) even more so.

I have taken the 2 patches from upstream that I mailed in September to
the bugreport and made a debdiff for a NMU upload. I don't have upload
rights though so I would need a sponsor to actually upload to Debian.

-- 
Andreas Moog, Berliner Str. 29, 36205 Sontra/Germany
Ubuntu Developer
PGP-encrypted mails preferred (Key-ID: 74DE6624)
PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624
diff -Nru sleuthkit-3.2.3/debian/changelog sleuthkit-3.2.3/debian/changelog
--- sleuthkit-3.2.3/debian/changelog2011-10-14 19:52:37.0 +0200
+++ sleuthkit-3.2.3/debian/changelog2013-11-09 22:58:23.0 +0100
@@ -1,3 +1,12 @@
+sleuthkit (3.2.3-2.1) unstable; urgency=low
+
+  * Non-maintainer upload
+  * d/patches/95_fix-libewf2-detection.patch, 96_fix_build_libewf2.patch:
+- Add 2 patches from upstream git to fix detection and build against 
+  libewf2 (Closes: #713364)
+
+ -- Andreas Moog am...@ubuntu.com  Sat, 09 Nov 2013 22:55:04 +0100
+
 sleuthkit (3.2.3-2) unstable; urgency=low
 
   * Team upload.
diff -Nru sleuthkit-3.2.3/debian/patches/95_fix-libewf2-detection.patch 
sleuthkit-3.2.3/debian/patches/95_fix-libewf2-detection.patch
--- sleuthkit-3.2.3/debian/patches/95_fix-libewf2-detection.patch   
1970-01-01 01:00:00.0 +0100
+++ sleuthkit-3.2.3/debian/patches/95_fix-libewf2-detection.patch   
2013-11-09 22:54:25.0 +0100
@@ -0,0 +1,17 @@
+Description: Fix detection of libewf v2 API.
+Author: Joachim Metz
+Origin: upstream, 
https://github.com/sleuthkit/sleuthkit/commit/ee5515215c1f618bf966d175ace1270fea7c5d4b
+Bug: http://sourceforge.net/p/sleuthkit/bugs/208/
+Last-Update: 2013-08-29
+
+--- sleuthkit-3.2.3.orig/configure.ac
 sleuthkit-3.2.3/configure.ac
+@@ -121,7 +121,7 @@ AS_IF([test x$with_libewf != xno],
+ )]
+ # Check for the header file first to make sure they have the dev install
+ [AC_CHECK_HEADERS([libewf.h], 
+-  [AC_CHECK_LIB([ewf], [libewf_open],[
++  [AC_CHECK_LIB([ewf], [libewf_get_version],[
+ AC_SUBST([LIBEWF_LIBS],[-lewf])
+ AC_DEFINE([HAVE_LIBEWF],[1],[Define to have libewf header included.])
+   ])]
diff -Nru sleuthkit-3.2.3/debian/patches/96_fix_build_libewf2.patch 
sleuthkit-3.2.3/debian/patches/96_fix_build_libewf2.patch
--- sleuthkit-3.2.3/debian/patches/96_fix_build_libewf2.patch   1970-01-01 
01:00:00.0 +0100
+++ sleuthkit-3.2.3/debian/patches/96_fix_build_libewf2.patch   2013-11-09 
22:54:25.0 +0100
@@ -0,0 +1,840 @@
+Description: Fix build with libewf2
+Author: Omar Choudary
+Origin: upstream, 
https://github.com/sleuthkit/sleuthkit/commit/7dcf7863b449f6058952489b0367cf0c1fbd0964
+Bug: http://sourceforge.net/p/sleuthkit/feature-requests/73/
+Last-Update: 2013-08-30
+
+Index: sleuthkit-3.2.3/tsk3/img/ewf.c
+===
+--- sleuthkit-3.2.3.orig/tsk3/img/ewf.c2013-08-31 10:13:21.397922919 
+
 sleuthkit-3.2.3/tsk3/img/ewf.c 2013-08-31 11:05:10.793936030 +
+@@ -14,67 +14,160 @@
+ #include tsk_img_i.h
+ 
+ #if HAVE_LIBEWF
++
+ #include ewf.h
+ 
+-static ssize_t
+-ewf_image_read(TSK_IMG_INFO * img_info, TSK_OFF_T offset, char *buf,
+-size_t len)
++#define TSK_EWF_ERROR_STRING_SIZE 512
++
++static \
++ssize_t ewf_image_read(
++ TSK_IMG_INFO *img_info,
++ TSK_OFF_T offset,
++ char *buffer,
++ size_t size )
+ {
+-ssize_t cnt;
+-IMG_EWF_INFO *ewf_info = (IMG_EWF_INFO *) img_info;
++#if defined( HAVE_LIBEWF_V2_API )
++  char error_string[ TSK_EWF_ERROR_STRING_SIZE ];
+ 
+-if (tsk_verbose)
+-tsk_fprintf(stderr,
+-ewf_read: byte offset: % PRIuOFF  len: % PRIuSIZE \n,
+-offset, len);
+-
+-if (offset  img_info-size) {
+-tsk_error_reset();
+-tsk_errno = TSK_ERR_IMG_READ_OFF;
+-snprintf(tsk_errstr, TSK_ERRSTR_L,
+-split_read - % PRIuOFF, offset);
+-return -1;
+-}
++  libewf_error_t *ewf_error = NULL;
++#endif
+ 
+-cnt = libewf_read_random(ewf_info-handle, buf, len, offset);
+-if (cnt  0) {
+-tsk_error_reset();
+-// @@@ Add more specific error message
+-tsk_error_reset();
+-tsk_errno = TSK_ERR_IMG_READ;
+-snprintf(tsk_errstr, TSK_ERRSTR_L,
+-ewf_read - offset: % PRIuOFF  - len: % PRIuSIZE  - %s,
+-offset, len, strerror(errno));
+-return -1;
+-}
++  IMG_EWF_INFO *ewf_info= (IMG_EWF_INFO *) img_info;
++  ssize_t read_count= 0;
++  if( tsk_verbose != 0 )
++  {
++  tsk_fprintf(
++   stderr,
++   ewf_read: byte offset: % PRIuOFF  len: % PRIuSIZE \n,
++   offset

Bug#713364: Patch to build with libewf2

2013-09-01 Thread Andreas Moog
Control: tags -1 patch

Hello Lucas, Hello Debian Forensics Team,

I grabbed 2 patches from upstream to fix the build failure against
libewf2, please find them attached. Note that the package will still
FTBFS because libewf2 doesn't declare a dependency to libbfio-dev, see
http://bugs.debian.org/721427

Cheers,
  Andreas
Description: Fix detection of libewf v2 API.
Author: Joachim Metz
Origin: upstream, https://github.com/sleuthkit/sleuthkit/commit/ee5515215c1f618bf966d175ace1270fea7c5d4b
Bug: http://sourceforge.net/p/sleuthkit/bugs/208/
Last-Update: 2013-08-29

--- sleuthkit-3.2.3.orig/configure.ac
+++ sleuthkit-3.2.3/configure.ac
@@ -121,7 +121,7 @@ AS_IF([test x$with_libewf != xno],
 )]
 # Check for the header file first to make sure they have the dev install
 [AC_CHECK_HEADERS([libewf.h], 
-  [AC_CHECK_LIB([ewf], [libewf_open],[
+  [AC_CHECK_LIB([ewf], [libewf_get_version],[
 AC_SUBST([LIBEWF_LIBS],[-lewf])
 AC_DEFINE([HAVE_LIBEWF],[1],[Define to have libewf header included.])
   ])]
Description: Fix build with libewf2
Author: Omar Choudary
Origin: upstream, https://github.com/sleuthkit/sleuthkit/commit/7dcf7863b449f6058952489b0367cf0c1fbd0964
Bug: http://sourceforge.net/p/sleuthkit/feature-requests/73/
Last-Update: 2013-08-30

Index: sleuthkit-3.2.3/tsk3/img/ewf.c
===
--- sleuthkit-3.2.3.orig/tsk3/img/ewf.c	2013-08-31 10:13:21.397922919 +
+++ sleuthkit-3.2.3/tsk3/img/ewf.c	2013-08-31 11:05:10.793936030 +
@@ -14,67 +14,160 @@
 #include tsk_img_i.h
 
 #if HAVE_LIBEWF
+
 #include ewf.h
 
-static ssize_t
-ewf_image_read(TSK_IMG_INFO * img_info, TSK_OFF_T offset, char *buf,
-size_t len)
+#define TSK_EWF_ERROR_STRING_SIZE	512
+
+static \
+ssize_t ewf_image_read(
+ TSK_IMG_INFO *img_info,
+ TSK_OFF_T offset,
+ char *buffer,
+ size_t size )
 {
-ssize_t cnt;
-IMG_EWF_INFO *ewf_info = (IMG_EWF_INFO *) img_info;
+#if defined( HAVE_LIBEWF_V2_API )
+	char error_string[ TSK_EWF_ERROR_STRING_SIZE ];
 
-if (tsk_verbose)
-tsk_fprintf(stderr,
-ewf_read: byte offset: % PRIuOFF  len: % PRIuSIZE \n,
-offset, len);
-
-if (offset  img_info-size) {
-tsk_error_reset();
-tsk_errno = TSK_ERR_IMG_READ_OFF;
-snprintf(tsk_errstr, TSK_ERRSTR_L,
-split_read - % PRIuOFF, offset);
-return -1;
-}
+	libewf_error_t *ewf_error = NULL;
+#endif
 
-cnt = libewf_read_random(ewf_info-handle, buf, len, offset);
-if (cnt  0) {
-tsk_error_reset();
-// @@@ Add more specific error message
-tsk_error_reset();
-tsk_errno = TSK_ERR_IMG_READ;
-snprintf(tsk_errstr, TSK_ERRSTR_L,
-ewf_read - offset: % PRIuOFF  - len: % PRIuSIZE  - %s,
-offset, len, strerror(errno));
-return -1;
-}
+	IMG_EWF_INFO *ewf_info= (IMG_EWF_INFO *) img_info;
+	ssize_t read_count= 0;
+	if( tsk_verbose != 0 )
+	{
+		tsk_fprintf(
+		 stderr,
+		 ewf_read: byte offset: % PRIuOFF  len: % PRIuSIZE \n,
+		 offset,
+		 size );
+	}
+	if( offset  img_info-size )
+	{
+		tsk_error_reset();
+
+		tsk_errno = TSK_ERR_IMG_READ_OFF;
+
+		snprintf(
+		 tsk_errstr,
+		 TSK_ERRSTR_L,
+		 split_read - % PRIuOFF,
+		 offset );
+
+		return( -1 );
+	}
+#if defined( HAVE_LIBEWF_V2_API )
+	read_count = libewf_handle_read_random(
+	  ewf_info-handle,
+	  buffer,
+	  size,
+	  offset,
+	  ewf_error );
+
+	if( read_count  0 )
+	{
+		tsk_error_reset();
+
+		tsk_errno = TSK_ERR_IMG_READ;
+
+		if( libewf_error_backtrace_sprint(
+		 ewf_error,
+		 error_string,
+		 TSK_EWF_ERROR_STRING_SIZE ) == -1 )
+		{
+			snprintf(
+			 tsk_errstr,
+			 TSK_ERRSTR_L,
+			 ewf_read - offset: % PRIuOFF  - len: % PRIuSIZE  - %s,
+			 offset,
+			 size,
+			 strerror( errno ) );
+		}
+		else
+		{
+			snprintf(
+			 tsk_errstr,
+			 TSK_ERRSTR_L,
+			 ewf_read - offset: % PRIuOFF  - len: % PRIuSIZE \n%s,
+			 offset,
+			 size,
+			 error_string );
+		}
+libewf_error_free(
+ ewf_error );
 
-return cnt;
+		return( -1 );
+	}
+#else
+	read_count = libewf_read_random(
+	  ewf_info-handle,
+	  buffer,
+	  size,
+	  offset );
+
+	if( read_count  0 )
+	{
+		tsk_error_reset();
+
+		tsk_errno = TSK_ERR_IMG_READ;
+
+		snprintf(
+		 tsk_errstr,
+		 TSK_ERRSTR_L,
+		 ewf_read - offset: % PRIuOFF  - len: % PRIuSIZE  - %s,
+		 offset,
+		 size,
+		 strerror( errno ) );
+
+		return( -1 );
+	}
+#endif
+	return( read_count );
 }
 
-static void
-ewf_image_imgstat(TSK_IMG_INFO * img_info, FILE * hFile)
+static \
+void ewf_image_imgstat(
+  TSK_IMG_INFO *img_info,
+  FILE * hFile )
 {
 IMG_EWF_INFO *ewf_info = (IMG_EWF_INFO *) img_info;
 
-tsk_fprintf(hFile, IMAGE FILE INFORMATION\n);
-tsk_fprintf(hFile

Bug#721427: libewf-dev misses a Depends: on libbfio-dev

2013-08-31 Thread Andreas Moog
Package: libewf-dev
Version: 20130416-2
Severity: Serious
Justification: Policy 7.2

Hello Christophe, Pierre and the Debian Forensics team,

in order to use the file libewf.h from libewf-dev, libbfio-dev has to be
installed on the system, but it isn't listed as a dependency:

(sid-amd64)root@incubator:~# gcc test.c
In file included from test.c:1:0:
/usr/include/libewf.h:35:21: fatal error: libbfio.h: No such file or
directory
 #include libbfio.h
 ^
compilation terminated.
(sid-amd64)root@incubator:~# cat test.c
#include libewf.h

Please add the package libbfio-dev to the Depends-line for libewf-dev.

Cheers,
  Andreas



signature.asc
Description: OpenPGP digital signature
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

Bug#713711: Bug reported on libewf

2013-08-31 Thread Andreas Moog
Hello Michael,

I reported http://bugs.debian.org/721427 against libewf concerning the
missing depends on libbfio-dev. Is there any news from upstream about
adapting guymager to the libewf v2 API?

Cheers,
  Andreas



signature.asc
Description: OpenPGP digital signature
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

Bug#720301: rkhunter: some shipped files are not included in md5sums

2013-08-20 Thread Andreas Beckmann
Package: rkhunter
Version: 1.4.0-3
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package does not include
md5sums for all the files it ships:

  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/backdoorports.dat
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/cn
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/de
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/en
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/zh
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/i18n/zh.utf8
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/mirrors.dat
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/programs_bad.dat
  rkhunter: FILE WITHOUT MD5SUM /var/lib/rkhunter/db/suspscan.dat

If these files are intended to be modified, they should be managed by
maintainer scripts instead of being shipped.
Currently they will be overwritten on every upgrade.


Andreas

___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel


Bug#694368: libfuzzy{2, -dev}: missing Breaks+Replaces: ssdeep ( 2.6)

2012-12-06 Thread Andreas Tille
Hi,

I considered NMUing ssdeep to fix this bug.  When debcheckout-ing the
packaging repository I noticed that there is a changelog entry

* Adding the missing Breaks+Replaces (Closes: #694368).

for a not yet released version 2.9-1.

Could you please confirm that you understood that you can not upload a
new version but just need to apply the smallest possible change to the
package currently in testing?  Please tell me if you have some trouble
with uploading / sponsering - I'd volunteer to help fixing this RC bug.

Kind regards

  Andreas.

-- 
http://fam-tille.de

___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel