Accepted chaosreader 0.96-3 (source) into unstable

[Joao Eriberto Mota Filho]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 16 Feb 2018 10:35:02 -0200
Source: chaosreader
Binary: chaosreader
Architecture: source
Version: 0.96-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Forensics <forensics-devel@lists.alioth.debian.org>
Changed-By: Joao Eriberto Mota Filho <eribe...@debian.org>
Description:
 chaosreader - trace network sessions and export it to html format
Closes: 890589
Changes:
 chaosreader (0.96-3) unstable; urgency=medium
 .
   * Migrated DH level to 11.
   * debian/control:
   - Added libnet-dns-perl to Depends field. (Closes: #890589)
   - Bumped Standards-Version to 4.1.3.
   - Updated VCS fields to use salsa server.
   * debian/copyright: updated packaging copyright years.
Checksums-Sha1:
 713b9c1a87a601d0d3226a588ecd4578bc89e560 1955 chaosreader_0.96-3.dsc
 64227ba71b9362342ffc0cf7a829ab09905a1fec 10224 chaosreader_0.96-3.debian.tar.xz
 bcf351dd6eebd2575df4e2d24854a63a65238414 5019 
chaosreader_0.96-3_source.buildinfo
Checksums-Sha256:
 287baa4fcdeb8d2ee4dfccaee9dce025fbf3dfd2dee056cd929290b267b3ebc4 1955 
chaosreader_0.96-3.dsc
 038e4a5d556cbe13fb8f7b450d3f2182213be9edcc88cf1a511268847b7083b5 10224 
chaosreader_0.96-3.debian.tar.xz
 be96cb1824abe8291e3170369788842f5180d0157c9db42648d27d877a985faf 5019 
chaosreader_0.96-3_source.buildinfo
Files:
 c2edc2c7bca26957f0f3b8d232adc130 1955 net optional chaosreader_0.96-3.dsc
 841a35e5426fd7a0d813ce87afef336d 10224 net optional 
chaosreader_0.96-3.debian.tar.xz
 a8e61b0c9de13c4ed08256b374e34961 5019 net optional 
chaosreader_0.96-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEENX3LDuyVoBrrofDS3mO5xwTr6e8FAlqG1o0ACgkQ3mO5xwTr
6e+wXRAAonFdUtF3Lw3yNn+qWDW6GqBPTWdwrf3rnyR/lCrLI9oBFZ/WmnuXp+yr
uT02+NPX7wcss3zKC2aSzKi0a/0HtwCXg3z/5uSHBu4aT1V43CDx9QoX98NCKMYH
GQWjTDjh+bSstGkdx3WMFYj+SnFhsIeEjeIs7jnxTZUijGK9Qw4SpkNkFSGh4NMe
T3BwBlrNX8QrzgeYn1JNtSx38P70pM6tRT3lMZB70kusuFEU1tF3LO7lmOs4eW7Z
pCmoNlZ3hdUUYk6GBcZojfgmE9mXoOwe1lUSfq8mZKv45UXOh7uwRLZt9++4mQjX
gPW/cJAXmyPD44UNGsgWr/ckuArULAIyTcnTSHFcHRotICYs1YrfrzAB+/1PAq9f
lTQiRri1jNBNkJC5F/ioheFRLJN2THx9E1qJ91rtd0uuigPOVT6liN92O3V7Hzv8
g79fgutYfRt2/ClCeTBw240DaQKvtBbkCzeDr8An6R/x2RsxHZOZ5z31Mh7NHlhu
17ooqdU90MQVk1kQLmYL6vnsxkl5KHZHkJukrIIyRdYd7ay198PdlQAKf5ID77rw
DHNpQubEWaHZGgGVg4aY10xwLlr3TEERvHbBYbz+yaz7yWJBWSrYuhVppSvM+78r
4a9wQ9uQvFAPASeLtEAtgDyjkkHqkdUsEVNN+jd3IM6y8xFITlw=
=f6//
-END PGP SIGNATURE-


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

Bug#882538: outguess: missing source for jpeg-6b-steg/configure

[Eriberto Mota]

Thanks Helmut and Paul for your messages. There are more information
about this issue in Debian Legal[1].

I tried to make a new configure.ac (or configure.in) but I had no
success. I will try again when I have more time (I hope it can be
soon).

[1] https://lists.debian.org/debian-legal/2017/11/msg00033.html

Regards,

Eriberto

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

Bug#853301: afflib: ftbfs with GCC-7

[Eriberto Mota]

Hi Matthias,

The issue was fixed in afflib/3.7.15-2, uploaded to unstable on 2017-06-25. The 
current version in unstable is 3.7.16-2.

I have a doubt about the bug. Can I close it? (The original bug text says: 
"Please keep this issue open in the bug tracker for the package it was filed 
for")

Thanks in advance.

Regards,

Eriberto

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

Bug#873374: libtsk13 4.4.2-1 crash in the dfvfs test suite

[Eriberto Mota]

Control: reassign 873374 python-tsk

Hi,

After a conversation with upstream[1] and several tests, I can confirm
the problem is being caused by python-tsk package. Rebuilding the
package will solve the problem.

[1] https://github.com/sleuthkit/sleuthkit/issues/953

Hilko, can you reupload the package?

Regards,

Eriberto

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

Bug#874773: forensics-all: Use of /var/lib/apt/lists internals

[Eriberto Mota]

Hi Julian,

Thanks for your message. I have some considerations.


2017-09-09 11:11 GMT-03:00 Julian Andres Klode :
>
> your package appears to be relying on the internal layout of 
> /var/lib/apt/lists
> and the location of that directory (which is configurable), as it matches the
> following regular expression (and a quick check did not rule out a false 
> positive):
>
> /var/lib/apt/lists/.*(Packages|Sources)
>
> For the matches found, you can have a quick look at:
>
> 
> https://codesearch.debian.net/search?q=%2Fvar%2Flib%2Fapt%2Flists%2F.*%28Packages%7CSources%29+package%3Aforensics-all
>
> APT since some time supports compressed indices using the option
> `Acquire::gzipIndexes`. Starting with 1.2, index files are stored
> with lz4 compression if that option is enabled, providing significant
> space savings at low overhead.
>
> Some platforms and users might already have these indexes compressed by 
> default
> in order to save space, and your package might not be working for them.


This is a native source that provides a metapackage. The content of
the script isn't for use by final users and this script isn't
installed by the package. The script is used by maintainers only to
aid to create a control file. After this, the new control file must be
double checked to avoid mistakes. Our machines (my machine and
Giovani's machine) and ours Debians are compliant with the script.



> Instead of relying on internals, please use the interfaces provided by
> APT 1.1 and newer:
>
> ## Command-line interfaces
> In order to get paths to index files, please use:
>
> apt-get indextargets --format '$(FILENAME)' "Created-By: $creator"
>
> where `$creator` is `Packages`, `Sources`, `Contents-deb`, `Contents-udeb`,
> or `Contents-deb-legacy`, depending on which files you need.
>
> To read the file, use
>
> /usr/lib/apt/apt-helper cat-file ...
>
> This transparently handles compression supported by apt.


It is interesting but I think that not applicable. As I said, the
script has a special goal and is not destinated to final users. We
have a strict control over the packages list, independently of
compression or other issues.

Can I close this bug?

Thanks a lot for your message.

Regards,

Eriberto

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

Bug#873374: libtsk13 4.4.2-1 crash in the dfvfs test suite

[Eriberto Mota]

2017-08-27 4:08 GMT-03:00 Adrian Bunk :
> Package: libtsk13
> Version: 4.4.2-1
> Severity: serious
> Control: affects -1 src:dfvfs python-tsk
>
> https://tests.reproducible-builds.org/debian/history/dfvfs.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dfvfs.html
>
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/build/1st/dfvfs-20170723'
> python run_tests.py
> testIterateVolumes (volume.vshadow_volume_system.VShadowVolumeSystemTest)
> Test the iterate volumes functionality. ... ok
> testIterateVolumes (volume.tsk_volume_system.TSKVolumeSystemTest)
> Test the iterate volumes functionality. ... debian/rules:23: recipe for 
> target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Floating point exception
>
>
> Program terminated with signal SIGFPE, Arithmetic exception.
> #0  0x7fa2ac0f606a in dos_load_prim_table (test=1 '\001',
> vs=0x55c56dcae270) at dos.c:821
> 821 dos.c: No such file or directory.
> (gdb) bt
> #0  0x7fa2ac0f606a in dos_load_prim_table (test=1 '\001',
> vs=0x55c56dcae270) at dos.c:821
> #1  tsk_vs_dos_open (img_info=0x7fa2a322c070, offset=0,
> test=test@entry=1 '\001') at dos.c:1064
> #2  0x7fa2ac0f3161 in tsk_vs_open (img_info=0x7fa2a322c070, offset=0,
> type=) at mm_open.c:56
> #3  0x7fa2ac3bf41e in Volume_Info_Con (self=0x55c56dcbe2f0,
> img=, type=, offset=)
> at tsk3.c:659
> #4  0x7fa2ac3b3ade in pyVolume_Info_init (self=self@entry=0x7fa2a31b4c70,
> args=args@entry=( _is_cached=True, 
> _resolver_context=  _values={u'type: OS, location: 
> /tmp/dfvfs-20170723/test_data/vsstest.qcow2\n': 
>  _is_cached=True, _resolver_context=<...>, _is_open=True, _file_object= at remote 0x7fa2a3174d20>) at remote 0x7fa2a31b4550>) at remote 
> 0x7fa2a31b4590>, u'type: OS, location: 
> /tmp/dfvfs-20170723/test_data/bdetogo.raw\n': 
> ) at remote 
> 0x7fa2a31b4bd0>}) at remote 0x7fa2a3fbad90>, 
> _file_system_cache= _values={}) at remote 0x7fa2a3fbad50>) at remote 0x7fa2a3fba390>, 
> _is_open=True, _file_object=) at remote 
> 0x7fa2a31b4890>) at remote 0x7fa2a31994b0>,), kwds=kwds@entry=0x0)
> at pytsk3.c:20444
> #5  0x55c56b688bf4 in type_call.lto_priv () at ../Objects/typeobject.c:765
> #6  0x55c56b683163 in PyObject_Call () at ../Objects/abstract.c:2547
> ...
>
> Works after downgrading libtsk13 to 4.4.0-5



Hi Adrian and all,

I think that it is an upstream problem and I will report it soon (today).

There is any workaround to mitigate this issue for now?

Regards,

Eriberto

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

Bug#852846: forensics-all: Depends on conflicting packages: crack vs crack-md5

[Eriberto Mota]

2017-01-27 17:36 GMT-02:00 Axel Beckert :
> Package: forensics-all
> Version: 1.5
> Severity: important
>
> Dear Debian Forensics Metapackages Maintainers,
>
> forensics-all depends on both, crack and crack-md5. But crack and
> crack-md5 conflict with each other.
>
> forensics-all is though still installable, but only because crack-md5
> also "Provides: crack". (Hence not "Severity: serious".) But once
> crack-md5 decides to drop that Provides, forensics-all will become
> uninstallable.
>
> So please change the dependency on "crack, crack-md5" to "crack |
> crack-md5". IMHO that's the only variant which makes sense.


Hi Axel,

Thanks a lot for your message. I will wait for Stretch release and fix
this issue.

Cheers,

Eriberto

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

Bug#853935: rephrase: No more works with gpg2 and causes one pinentry popup per guess

[Eriberto Mota]

Hi guys,

Axel, thanks a lot for your patch. I have a special interest over this
bug because it will affect forensics-all and forensics-full packages.

Tiago, I did a Team upload and I sent it to 5-day/delay queue now. If
you want, I can cancel it. Otherwise, I will wait rephrase enter in
unstable and ask to Release Team for unblock.

The changelog is:

rephrase (0.2-2) unstable; urgency=medium

  * Team upload.
  * debian/control:
  - Bumped Standards-Version to 3.9.8.
  - Updated the Vcs-Git field to use https instead of git.
  * debian/patches/02_minimal_gpg2_support.patch: added to unconditionally
call gpg with "--pinentry-mode loopback", allowing rephrase work with
GPG2. Thanks to Axel Beckert . (Closes: #853935)

I attached a debdiff.

Cheers,

Eriberto


rephrase.debdiff
Description: Binary data
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

Bug#851872: sleuthkit: New upstream version available

[Eriberto Mota]

2017-01-19 12:07 GMT-02:00 Hilko Bengen :
> Source: sleuthkit
> Version: 4.3.1-5
> Severity: wishlist
>
> Dear Maintainer,
>
> sleuthkit 4.4.0 has been released. We could still get this released with
> stretch.


Thanks. I will package it soon. Working hard over packit now. However,
TSK 4.4.0 will arrives to Stretch.

Regards,

Eriberto

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

Bug#850828: New .symbols file

[Eriberto Mota]

2017-01-14 14:37 GMT-02:00 Hilko Bengen :
> Eriberto,
>
> please take a look at the commit I pushed to
> https://anonscm.debian.org/git/forensics/sleuthkit.git, specifically
> 19ed029000b71d6900368294130c4c919aff369d. I have split the .symbols file
> into three files (common, 32bit, 64bit) and made a few classes of
> symbols optional.


Hi Hilko,

Thanks for this work. It sounds good but I prefer a simplest way to
make the maintaining easier. From 'man dpkg-gensymbols':

"When  generating  those  files,  it  uses  as  input  some symbols
provided by the maintainer."

So, I prefer keep the symbols that are common for all architectures,
doing the specific symbols be generated by build system. In other
words, my intent is remove the conflicting symbols. From now, I will
use c++filt to demangle the C++ symbols. It was a good lesson for me.

Thanks a lot for your help.

Cheers,

Eriberto

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

Bug#848881: [gpart] Floating point exception when scanning

[Eriberto Mota]

Control: severity 848881 important

Hi,

Adding Baruch (upstream) in Cc.

I downgraded the severity to important because this bug is not grave
(maybe it could be normal).

Baruch, any idea?

Regards,

Eriberto


2016-12-20 11:33 GMT-02:00 Ingo Juergensmann :
> Package: gpart
> Version: 1:0.3-3
> Severity: grave
>
> --- Please enter the report below this line. ---
> Hi!
>
> When trying to examine a volume on LVM, I get a floating point exception
> quite instantly:
>
>
> # strace -f gpart -f /dev/lv/Elite3
> execve("/usr/sbin/gpart", ["gpart", "-f", "/dev/lv/Elite3"], [/* 59 vars
> */]) = 0
>
>
> brk(NULL)   = 0x5564d0c19000
>
>
>
> access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
> directory)
>
>
> mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f959d326000
>
>
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
> directory)
>
>
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>
>
>
> fstat(3, {st_mode=S_IFREG|0644, st_size=238540, ...}) = 0
>
>
>
> mmap(NULL, 238540, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f959d2eb000
>
>
>
> close(3)= 0
>
>
>
> access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
> directory)
>
>
> open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
>
>
>
> read(3,
> "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\3\2\0\0\0\0\0"...,
> 832) = 832
>
>
> fstat(3, {st_mode=S_IFREG|0755, st_size=1685264, ...}) = 0
>
>
>
> mmap(NULL, 3791264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0x7f959cd69000
>
>
> mprotect(0x7f959cefe000, 2093056, PROT_NONE) = 0
>
>
>
> mmap(0x7f959d0fd000, 24576, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0x7f959d0fd000
>
>
> mmap(0x7f959d103000, 14752, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f959d103000
>
>
> close(3)= 0
>
>
>
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0x7f959d2e9000
>
>
> arch_prctl(ARCH_SET_FS, 0x7f959d2e9700) = 0
>
>
>
> mprotect(0x7f959d0fd000, 16384, PROT_READ) = 0
>
>
>
> mprotect(0x5564d0783000, 4096, PROT_READ) = 0
>
>
>
> mprotect(0x7f959d329000, 4096, PROT_READ) = 0
>
>
>
> munmap(0x7f959d2eb000, 238540)  = 0
>
>
>
> brk(NULL)   = 0x5564d0c19000
>
>
>
> brk(0x5564d0c3a000) = 0x5564d0c3a000
>
>
>
> sync()  = 0
>
>
>
> open("/dev/lv/Elite3", O_RDONLY)= 3
>
>
>
> lseek(3, 0, SEEK_SET)   = 0
>
>
>
> read(3,
> "\16\32R\275\217x\235v\376\377#\0\6/\0\177\377\377DDDE\35\360IHII\33\364GH"...,
> 512) = 512
>
>
> lseek(3, 0, SEEK_SET)   = 0
>
>
>
> read(3,
> "\16\32R\275\217x\235v\376\377#\0\6/\0\177\377\377DDDE\35\360IHII\33\364GH"...,
> 512) = 512
>
>
> stat("/dev/lv/Elite3", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 16),
> ...}) = 0
>
>
> ioctl(3, HDIO_GETGEO, {heads=0, sectors=0, cylinders=0, start=0}) = 0
>
>
>
> ioctl(3, BLKGETSIZE, [8388608]) = 0
>
>
>
> --- SIGFPE {si_signo=SIGFPE, si_code=FPE_INTDIV, si_addr=0x5564d057d5f0}
> ---
>
>
> +++ killed by SIGFPE +++
>
>
>
> Gleitkomma-Ausnahme
>
>
>
> --- System information. ---
> Architecture: Kernel:   Linux 4.8.0-2-amd64
>
> Debian Release: stretch/sid
>   500 unstablewww.deb-multimedia.org   500 unstable
> ftp.de.debian.org   500 unstabledownload.jitsi.org
> --- Package information. ---
> Depends  (Version) | Installed
> ==-+-===
> libc6 (>= 2.4) |
>
> Package's Recommends field is empty.
>
> Package's Suggests field is empty.
>
>
>
>
> --
> Ciao...//  Fon: 0381-2744150
>   Ingo   \X/   http://blog.windfluechter.net
> Please don't share this address with Facebook or Google!
> gpg pubkey: http://www.juergensmann.de/ij_public_key.asc
>
> ___
> forensics-devel mailing list
> forensics-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

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

Bug#846839: reglookup: Please, use jdupes instead rdfind+symlinks

[Joao Eriberto Mota Filho]

Package: reglookup
Version: 1.0.1+svn287-5
Severity: wishlist
Tags: patch

Dear Maintainer,

The jdupes (new in Debian) can substitute rdfind+symlinks, making fast and
friendly the actions over duplicate files.

I added a patch for you Giovani. There are some information here[1], if
needed.

[1] https://wiki.debian.org/dedup.debian.net

Cheers,

Eriberto
diff -Naur reglookup-1.0.1+svn287.orig/debian/control reglookup-1.0.1+svn287/debian/control
--- reglookup-1.0.1+svn287.orig/debian/control	2016-11-05 23:02:20.0 -0200
+++ reglookup-1.0.1+svn287/debian/control	2016-12-03 14:32:44.953480186 -0200
@@ -8,13 +8,12 @@
docbook2x,
doxygen,
graphviz,
+   jdupes,
libtalloc-dev,
libtalloc2,
python-all,
python3-all,
-   rdfind,
-   scons (>= 2.3),
-   symlinks
+   scons (>= 2.3)
 Standards-Version: 3.9.8
 Homepage: http://projects.sentinelchicken.org/reglookup/
 Vcs-Browser: https://anonscm.debian.org/git/forensics/reglookup.git
diff -Naur reglookup-1.0.1+svn287.orig/debian/rules reglookup-1.0.1+svn287/debian/rules
--- reglookup-1.0.1+svn287.orig/debian/rules	2016-10-10 20:38:55.0 -0300
+++ reglookup-1.0.1+svn287/debian/rules	2016-12-03 14:34:23.097480210 -0200
@@ -29,9 +29,8 @@
 	dh_install
 	# Remove unnecessary hashes
 	find $(DOCPATH) -name '*.md5' -exec rm -f {} \;
-	# Using rdfind and symlinks to transform duplicated files in softlinks
-	rdfind -makesymlinks true $(DOCPATH)
-	symlinks -cr $(DOCPATH)
+	# Using jdupes to convert duplicate files in softlinks
+	jdupes -rl $(DOCPATH)
 	# Avoid an embedded javascript library
 	rm $(DOCPATH)/pyregfi/jquery.js
 
___
forensics-devel mailing list
forensics-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

NEWS: forensics-extra and UDD

[Eriberto Mota]

Hi Forensics Team,

There are some news for us.

1. forensics-extra

Some time ago I and Giovani created the forensics-all[1] package.
forensics-all is a metapackage that install all packages provided by
Debian Forensics Team in a Debian system.

Now, we have forensics-extra[2] source which provides forensics-extra
and forensics-extra-gui metapackages. These metapackages install
several packages, not under Debian Forensics Team umbrella, but all
useful for forensics activities. So, 'apt-get install forensics-all
forensics-extra forensics-extra-gui' will prepare a desktop to be a
very good forensics station. But...

Today I sent to NEW-queue[3] a new version of the forensics-extra
which will provides the forensics-full metapackage. forensics-full
will install forensics-all, forensics-extra and forensics-extra-gui.
My inspiration was kde-full package, because I use KDE and all its
power!

Feel free to suggest new and interesting packages for forensics-extra
and forensics-extra-gui (please, read the description in each package
before to send suggestions).

[1] https://packages.qa.debian.org/f/forensics-all.html
[2] https://packages.qa.debian.org/f/forensics-extra.html
[3] https://ftp-master.debian.org/new.html


2. Forensics Team status - UDD report

We have two new sections in our daily UDD report[4]:

- Sources in Debian Sid (co-maintainer order): this section list all
packages in Forensics Team, ordered by each co-maintainer.

- Sources in Debian Sid (uploader order): this section list all
packages in Forensics Team, ordered by last people that did upload.

I think that this UDD report[4] (specially the first section - Sources
in Debian Sid sorted by upload date) is useful to act over packages
that need some attention before freeze stage.

[4] https://people.debian.org/~eriberto/udd/teams/forensics_stats.html


3. Other UDDs

Here[5] you can see other interesting UDDs produced by me.

[5] https://people.debian.org/~eriberto/udd/

Enjoy!

Regards,

Eriberto

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

Bug#795052: sleuthkit: Uses embedded copy of libexif-0.6.20

[Eriberto Mota]

2015-08-09 20:58 GMT-03:00 Scott Kitterman :
> Source: sleuthkit
> Version: 4.1.3-11
> Severity: normal
>
> Although not a must in Debian policy, the preference is to not use embedded
> copies of libraries.  sleuthkit-4.1.3/framework/modules/c_LibExifModule has
> an embedded copy of libexif-0.6.20 that is used during package build.  It
> would be better to use the system libexif.

Control: tags 795052 moreinfo


Hi Scott,

I packaged the 4.3.1 version now. I did some checks and I saw that the
upstream does not use this library.

1. Via grep, I can not see a call for the library in main program. I
think that the upstream uses the directory to generate, manually,
files for MS Windows.

2. Removing the directory framework/modules/c_LibExifModule, the
package builds fine. The config.log and sleuthkit_4.3.1-1_amd64.build
don't show any call to libexif.

I thing this bug can be closed. What is your oppinion?

Thanks for your message.

Cheers,

Eriberto

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

Re: forensics-extra_1.0_amd64.changes REJECTED

[Eriberto Mota]

2016-11-08 20:00 GMT-02:00 Thorsten Alteholz :
>
> Hi Eriberto,
>
> not all packages from your Depends:-line are in main, some are missing
> and some are in non-free. Those must be removed.
>
> Thanks!
>   Thorsten


Hi Thorsten,

Initially, thanks for your review.

Sorry for my mistake. Before upload the package in the first time I
did a check in a clean environment but I could have done a double
check. In a fresh clean Sid, I think that the package was installed
because the 'Provides:' field in some other packages. I also used
'dpkg -i package; apt-get install -f'. So, the 'apt-get install -f'
solved the issues, as not present packages. So, all existent
dependencies was installed but not forensics-extra. I was a foll, my
apologizes. Now, I did a Bash script to check each package.

Well, I reuploaded the package with the following changes:

- ascii2uni changed to uni2ascii
- exiftool changed to libimage-exiftool-perl
- pdfinfo changed to poppler-utils
- unrar (vitual) removed. unrar-free already exists. (oh my God!)
- nikto (non-free) removed.

Also:

- dislocker: now in forensics-all, already in Debian. Removed from
forensics-extra.

I also updated the date in debian/changelog . No more changes.

I hope that is all rigth now.

Thanks again.

Regards,

Eriberto

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

Bug#839754: [ADD] volatility: Incompatible with Kernel 4.7

[Eriberto Mota]

Control: forwarded 839754 
https://github.com/volatilityfoundation/volatility/issues/344

Hi,

The previous ticket in GitHub was closed. However, doing some tests in
Debian, I discovered new failures and I opened a new bug in upstream.

Cheers,

Eriberto

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

Bug#839754: volatility: Incompatible with LiME version 1.7.5

[Eriberto Mota]

Control: retitle 839754 volatility: Incompatible with Kernel 4.7

After some tests and discussions in this thread[1], the problem is the
kernel, not LiME.

[1] https://github.com/volatilityfoundation/volatility/issues/330

Regards,

Eriberto

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

Bug#839754: volatility: Incompatible with LiME version 1.7.5

[Joao Eriberto Mota Filho]

Package: volatility
Version: 2.5
Severity: important
Tags: upstream

Volatility works fine with LiME 1.3 (in Stable, Jessie). However, fails with
LiME 1.7.5 (in Testing and Jessie-Backports). There is the following message
from Volatility:

Volatility Foundation Volatility Framework 2.5
LimeAddressSpace: lime: need base
LimeAddressSpace: Invalid Lime header signature

Eriberto

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

Statistics about Debian Forensics Team

[Eriberto Mota]

Hi,

Is available here[1] a daily report about Forensics Team. I believe
that this report will be useful to help to maintain the packages in
team.

[1] https://people.debian.org/~eriberto/forensics_stats.html

Enjoy!

Regards,

Eriberto

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

Re: Retirement of rifiuti

[Eriberto Mota]

Hi Markus,

Thanks for your message.

I don't know if rifiuti can be removed now. Is rifiuti2 a full and
mature repacement for rifiuti? Can someone say about it?

The 0.7.0 version is an initial draft only (not released yet).

Regards,

Eriberto


2016-07-24 13:48 GMT-03:00 Dr. Markus Waldeck :
> Dear Debian Forensics Maintainers,
>
> I wonder why rifiuti which was updated the last time over 12 (!) years ago is 
> still provided
> while the successor rifiuti2 is also packaged.
>
> Thanks!
>
> PS: rifiuti2 version 0.7.0 is available.
>
> Dr. Markus Waldeck
>
> ___
> forensics-devel mailing list
> forensics-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

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

Bug#826633: Updating the unhide.rb Uploaders list

[Eriberto Mota]

Hi again,

2016-06-09 11:55 GMT-03:00 Mattia Rizzolo <mat...@debian.org>:
> On Wed, Jun 08, 2016 at 08:54:35PM -0300, Eriberto wrote:
>> 2016-06-08 20:49 GMT-03:00 Eriberto Mota <eribe...@debian.org>:
>> > Hi Mattia,
>> >
>> > 2016-06-07 6:14 GMT-03:00 Mattia Rizzolo <mat...@debian.org>:
>> >> Source: unhide.rb
>> >> Version: 22-2
>> >> Severity: minor
>> >> User: m...@qa.debian.org
>> >> Usertags: mia-teammaint
>> >>
>> >> Julien Valroff <jul...@debian.org> has retired, so can't work on
>> >> the unhide.rb package anymore (at least with this address).
>> >
>> >
>> > The package is inside a team and the three quoted packages are updated
>> > (rkrunter in #826631, unhide in #826632 and unride.rb in #826633).
>> >
>> > In last year:
>> >
>> > * rkrunter: 03 uploads by Francois Marier.
>> > * unhide: 01 upload in November by Giovani Augusto Ferreira
>> > * unhide.rb: 01 upload in November by Giovani Augusto Ferreira
>> >
>> > Do you checked it?
>
> I did, but whom and when did the last upload of these packages has
> nothing to do with this request :)


???

I am saying that the packages are being maintained inside the team.
There are activities around these packages.


>> > The package is inside a team. I and Giovani are planning a review over
>> > all detached packages in November to kept them in good conditions for
>> > Stretch.
>>
>>
>> Is wrong remove humans for a package, considering that don't have a
>> person to be uploader now. It will generate this problem[1].
>>
>> [1] https://lintian.debian.org/tags/no-human-maintainers.html
>
> Exactly.  (though you could ignore it, I wouldn't particularly like it
> and I think it could only make life in MIA team harder if we had to deal
> with the package, but if that doesn't happen, the X team is setting an
> example at ignoring the policy there)
>
>> I can't see any problem in listed packages. They are being maintained
>> inside a team.
>
> Being inside a team is good, because taking them over is very easy.
> Probably the best thing would be to put Giovanni in the Uploaders field
> of them; or whoever else feels like caring about the packages.
>
>
> Julien is retired, and part of the retirement process is orphaning the
> packages, the fact that this didn't happen at that time is just a flaw
> in the process :)


No. It is wrong. Packages that have co-maintainers or inside of teams
musn't be orphaned. The MIA team always worked following that precept.
Consequently, I still no seeing any problem in listed packages. So, if
no more considerations, these bugs should be closed.

Regards,

Eriberto

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

Bug#826631: Bug#826633: Updating the unhide.rb Uploaders list

[Eriberto Mota]

Hi Mattia,

2016-06-07 6:14 GMT-03:00 Mattia Rizzolo :
> Source: unhide.rb
> Version: 22-2
> Severity: minor
> User: m...@qa.debian.org
> Usertags: mia-teammaint
>
> Julien Valroff  has retired, so can't work on
> the unhide.rb package anymore (at least with this address).


The package is inside a team and the three quoted packages are updated
(rkrunter in #826631, unhide in #826632 and unride.rb in #826633).

In last year:

* rkrunter: 03 uploads by Francois Marier.
* unhide: 01 upload in November by Giovani Augusto Ferreira
* unhide.rb: 01 upload in November by Giovani Augusto Ferreira

Do you checked it?


> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.


The package is inside a team. I and Giovani are planning a review over
all detached packages in November to kept them in good conditions for
Stretch.

Is wrong remove humans for a package, considering that don


> (If the person is listed as Maintainer, what we are asking is to please
> step in as a new maintainer.)
>
> Thanks.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>
> ___
> forensics-devel mailing list
> forensics-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

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

Bug#824438: volatility: Reviewed manpage available

[Joao Eriberto Mota Filho]

Package: volatility
Severity: minor

There is a reviewed manpage for volatility. This manpage is being used
as an example inside txt2man package.

This is a remind to use the new manpage in next revision.

Eriberto

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

Bug#824434: chaosreader: Reviewed manpage available

[Joao Eriberto Mota Filho]

Package: chaosreader
Severity: minor

There is a reviewed manpage for chaosreader. This manpage is being used
as an example inside txt2man package.

This is a remind to use the new manpage in next revision.

Eriberto

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

Bug#759330: gpart not compiled for armhf (wheezy)

[Eriberto Mota]

tags 759330 wontfix
tags 759330 upstream
thanks

Hi,

gpart is not available to any architecture. The armhf is not included
by upstream.

I will wait 30 days to close this bug.

Regards,

Eriberto

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

Bug#802089: ext4magic: recover or examine on ext4 file system is impossible

[Eriberto Mota]

Hi Roberto,

Thanks for your report. I tested ext4magic over Debian Unstable now
and the problem also occurs.

I applied your patch and uploaded a new package to unstable. When in
testing (five days), I will upload to Jessie-Backports.

To close this bug, I will wait a final solution.

Thanks a lot in advance.

Regards,

Eriberto


2015-10-17 10:45 GMT-03:00 Roberto Maar :
> Package: ext4magic
> Version: 0.3.2-2
> Severity: normal
>
> Dear Maintainer,
>
> ext4magic has a misinterpretation of the physical block addresses and block 
> lengths of ext4 inode.
> With each call by ext4magic be other random and too large values dertermined.
> Thus, a recover from ext4 file system is not possible.
> The error is permanent and 100% reproducible (also on i386)
> Often with the additional warning: "error-NR 22 can not found file"
>
>
> Example:
>
> # ext4magic -T -I2 -x /dev/sdb1  #debian 8.2 (amd64)
> 
> Dump Inode 2 from journal transaction 0
> Inode: 2   Type: directoryMode:  0755   Flags: 0x8
> Generation: 0Version: 0x:0004
> User: 0   Group: 0   Size: 4096
> File ACL: 0Directory ACL: 0
> Links: 5   Blockcount: 8
> Fragment:  Address: 0Number: 0Size: 0
>  ctime: 1444944845:371200 -- Thu Oct 15 23:34:05 2015
>  atime: 1444944255:196800 -- Thu Oct 15 23:24:15 2015
>  mtime: 1444944845:371200 -- Thu Oct 15 23:34:05 2015
> crtime: 1444943306:00 -- Thu Oct 15 23:08:26 2015
> Size of extra inode fields: 28
> Level Entries   Logical  Physical Length Flags
>  0/ 0   1/  1   0 -   25855 89219572695840 - 89219572721695  25856
> ..
> The block length 25855 and the start block 89219572695840 are random values
> and the false block data would also be used while trying a recover.
>
>
>
> The correct output should be:  #OpenSuse 13.1 (x86-64)
> ..
> Dump Inode 2 from journal transaction 0
> Inode: 2   Type: directoryMode:  0755   Flags: 0x8
> Generation: 0Version: 0x:0004
> User: 0   Group: 0   Size: 4096
> File ACL: 0Directory ACL: 0
> Links: 5   Blockcount: 8
> Fragment:  Address: 0Number: 0Size: 0
>  ctime: 1444944845:371200 -- Thu Oct 15 23:34:05 2015
>  atime: 1444944255:196800 -- Thu Oct 15 23:24:15 2015
>  mtime: 1444944845:371200 -- Thu Oct 15 23:34:05 2015
> crtime: 1444943306:00 -- Thu Oct 15 23:08:26 2015
> Size of extra inode fields: 28
> Level Entries   Logical  Physical Length Flags
>  0/ 0   1/  1   0 -   08865 -8865  1
> 2  d  755 (2)  0  0   4096 15-Oct-2015 23:08 .
> 2  d  755 (2)  0  0   4096 15-Oct-2015 23:08 ..
>11  d  700 (2)  0  0  16384 15-Oct-2015 23:08 
> lost+found
>393217  d  755 (2)  0  0  12288 15-Oct-2015 23:04 etc
> <  131073> d  755 (2)  0  0  65536 15-Oct-2015 23:20 doc
>524289  d  755 (2)  0  0   4096 15-Oct-2015 22:51 help
> ...
>
> See also Ticket #3 on ext4magic sf.net site.
>
>
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ext4magic depends on:
> ii  e2fslibs1.42.12-1.1
> ii  libblkid1   2.25.2-6
> ii  libbz2-1.0  1.0.6-7+b3
> ii  libc6   2.19-18+deb8u1
> ii  libmagic1   1:5.22+15-2
> ii  libuuid12.25.2-6
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> ext4magic recommends no packages.
>
> ext4magic suggests no packages.
>
> -- no debconf information
>
> ___
> forensics-devel mailing list
> forensics-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

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

Bug#801872: dc3dd: buffer overflow

[Eriberto Mota]

Hi Henri,

I agree with you.

Regards,

Eriberto


2015-10-15 10:32 GMT-03:00 Henri Salo :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Package: dc3dd
> Version: 7.2.641-3
> Severity: normal
> Tags: security
>
> Buffer overflow issue was announced in Bugtraq[1] with proof-of-concept:
>
> dc3dd `perl -e 'print "A" x 9'`
>
> The tool is not supposed to be executed with this kind of input so this seems 
> to
> be minor issue. Please correct me if I am wrong. I am submitting this bug so
> that we can track the issue and make changes if needed.
>
> 1: http://seclists.org/bugtraq/2015/Oct/71
>
> - --
> Henri Salo
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBAgAGBQJWH6r3AAoJECet96ROqnV0QcAQAK9EtS7IsUPly2CVVz2SeIo9
> o/u88X5FAlwhS8WPe1ByWeIorO0hOzMfIY1kVZRV3bMBW79GLD1CFBZt8+/yn+0T
> rbVu4sI3hOUnr5hRo+NINO8vUIsYSNoe380qeHvysSRO0NNxC+anOVK585sH3N6z
> BuKkAuPR7VmBPjuHsTXMdy8meRSQVp45kcfPth7ROklQRLSlLKFk7qKWsVFVLjPS
> a72u758tD1ZoqtFO2GlkywXWvJlhoBoHwUDyrTJ0wXy05QeYj/RVy18thehqV0lX
> oUoSjh8fO+1vscaTMYHbKlt/fuB4mXOYuaox4QX03BJQmuEO028j/VYAqe7fvZKe
> a7XWBK0D1TEZi2vHv9adOZRbVmJAS0oznW3Tjox1Zj42vvesUPXW7yP87BJPX0UV
> r3HShG+P8iuwMUO+CSFu6Bs/qHsMxRPRicObdII9yRlNEyH+zrl0zwS9vi75FhSR
> XYru9kB6whRmuEtdQ/zfZpj0kYn6kvzeGZFy0cq7XpHNn93wfNGLE8QENM96Mi4c
> 8MFos7uu3rQyXfzRd8Ch6jb93m+YflCFhNvKXZI5qsXKwr1kKIWNdoHmU/1nczT0
> MdE9nKrHCNDFDZdGwU+KXYzXfBAmsJJt3MuwPsBtD3UkW5ijxNzy9Q3w1HT/tBoB
> neNrPLKlCJxZenZkrV9I
> =xQYd
> -END PGP SIGNATURE-
>
> ___
> forensics-devel mailing list
> forensics-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

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

Bug#805428: tableau-parm: fix FTBFS with ld --as-needed

[Eriberto Mota]

Hi Logan,

Thanks for your message. The new package was uploaded to 1-day/delay queue[1].

[1] https://ftp-master.debian.org/deferred.html

Regards,

Eriberto


2015-11-18 0:27 GMT-02:00 Logan Rosen :
> Package: tableau-parm
> Version: 0.2.0-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu xenial ubuntu-patch
>
> Dear Maintainer,
>
> In Ubuntu, we use ld --as-needed by default in the toolchain, and your
> package fails to build from source with that option enabled because of the
> way libraries are linked.
>
> Even though Debian doesn't use ld --as-needed by default, it is a good idea
> to make this change so that (1) we don't have to maintain a delta and (2)
> you don't need to change anything in case Debian makes this default in the
> future.
>
> You can read more about this option here:
> https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
>
> In Ubuntu, the attached patch was applied to achieve the following:
>
>   * Fix FTBFS with ld --as-needed. LP: #832758.
>
> Thanks for considering the patch.
>
> Logan Rosen
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers xenial-updates
>   APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
> 'xenial'), (100, 'xenial-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.2.0-19-generic (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> ___
> forensics-devel mailing list
> forensics-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/forensics-devel

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

Re: metacam issues

[Eriberto Mota]

Hi Henri,

Thanks for your report.

2015-03-03 4:36 GMT-03:00 Henri Salo he...@nerv.fi:

 Do we really want to have several packages in Debian, which list and/or edit
 EXIF data for JPEG files?

IMHO, yes. I don't see any problem when maintaining several similar
packages in Debian. They are alternatives and each one has particular
features. Freedom is allow that users to choice the best software for
theirs interests, not impose a software only. I am teacher in of
Digital Investigations Postgraduate Course at Catholic University of
Brasilia (Brazil). in my lessons, my students use different programs
to solve each question in proposed exercises. So, each student will
know each possible program and will can choice which will use in a
future real case. I am working now in Forensics Team to update the
packages. I want review several packages up to July. Today, the
ed2k-hash, in FTBFS stage since one year, will be uploaded. (this
package was uploaded with 1-day delay yesterday - this is a personal
habit, because I can remember some important detail after done and fix
the issue before the final target, i.e., unstable/experimental)

Cheers,

Eriberto

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

Re: rkhunter is marked for autoremoval from testing

[Eriberto Mota]

Hi Mika and all!

I am acting as new co-maintainer and team upload in some packages not
maintained since 2011 or before. I intend to adopt some packages that
was maintained by Julien and Christophe Monniez. But rkhunter is not
in my current plans. But, if needed, I can try help.

Regards,

Eriberto

2014-11-28 8:08 GMT-02:00 Michael Prokop m...@debian.org:

 Any volunteers? Otherwise I'm afraid we won't have rkhunter in
 Debian/jessie.


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

Bug#200385: metacam: fails to read exif data on powerpc

[Eriberto Mota]

tags 200385 moreinfo
thanks

Hi Kiko,

I am the new maintainer of metacam.

I need a new photo because the given URL no longer exist.

Thanks a lot in advance.

Cheers,

Eriberto

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

Bug#592199: fls: not recursive to Ext4 images

[Joao Eriberto Mota Filho]

Package: sleuthkit
Version: 3.1.3-1
Severity: normal

The fls command doesn't work recursively with images using Ext4 filesystem.
I tested it in images using Ext3 and partitions (e.g. /dev/sda1) using Ext3/4
filesystem and the fls worked fine. The problem is with Ext4 images only.

Thanks in advance.

Regards,

Eriberto - Brazil


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages sleuthkit depends on:
ii  file  5.04-4 Determines file type using magic
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libdate-manip-perl6.11-1 module for manipulating dates
ii  libgcc1   1:4.4.4-7  GCC support library
ii  libstdc++64.4.4-7The GNU Standard C++ Library v3
ii  libtsk3-3 3.1.3-1library for forensics analysis on 

sleuthkit recommends no packages.

sleuthkit suggests no packages.

-- no debconf information



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