[opensuse-factory] A collection of new c libraries in factory
All, Joachim Metz, from Google, has written a set of c libraries to work with Microsoft files in linux. LGPLv3+ A overview is at http://code.google.com/p/libyal/wiki/Overview I have many of them now in factory with more coming. (If you see one you want that is not yet in factory, let me know.) They often include CLI tools to use the functionality. See libregf-tools - tools to parse MS registry files libevt-tools - tools to parse MS event logs in the pre-vista format libevtx-tools - tools to parse MS event logs in the vista and newer format libmsiecf-tools - tools to parse MS Internet Explorer Cache Files liblnk-tools - tools to parse MS link files. Similar to a symbolic link file libvshadow-tools (not yet submitted, find it in the filesystems repo) - tools to parse NTFS volume shadow copies libpff-tools - (not yet submitted, find it in the security repo) - tools to parse PST and OST files I am most intrigued by libvshadow. This is the only OSS tool I know of that even tries to give users access to NTFS volume shadow copies. FYI: The driving force behind me packaging most of these is that plaso is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.) I just submitted python-plaso to factory a few minutes ago, but I think all of the dependencies it needs are already there. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/24/2013 11:48 PM, Greg Freemyer wrote:
All,
Joachim Metz, from Google, has written a set of c libraries to work with Microsoft files in linux. LGPLv3+
A overview is at http://code.google.com/p/libyal/wiki/Overview
I have many of them now in factory with more coming. (If you see one you want that is not yet in factory, let me know.)
They often include CLI tools to use the functionality. See
libregf-tools - tools to parse MS registry files libevt-tools - tools to parse MS event logs in the pre-vista format libevtx-tools - tools to parse MS event logs in the vista and newer format libmsiecf-tools - tools to parse MS Internet Explorer Cache Files liblnk-tools - tools to parse MS link files. Similar to a symbolic link file libvshadow-tools (not yet submitted, find it in the filesystems repo) - tools to parse NTFS volume shadow copies libpff-tools - (not yet submitted, find it in the security repo) - tools to parse PST and OST files
I am most intrigued by libvshadow. This is the only OSS tool I know of that even tries to give users access to NTFS volume shadow copies.
FYI: The driving force behind me packaging most of these is that plaso is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)
I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.
I just submitted python-plaso to factory a few minutes ago, but I think all of the dependencies it needs are already there.
Greg
-- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Sascha Peilicke
On 04/24/2013 11:48 PM, Greg Freemyer wrote: <snip>
FYI: The driving force behind me packaging most of these is that
plaso
is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)
I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.
Hmm.. Maybe I should move it. A little background. Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives. One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface. I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it. So the architecture is: CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought. With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso? Thanks Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Greg Freemyer
Sascha Peilicke
wrote: On 04/24/2013 11:48 PM, Greg Freemyer wrote: <snip>
FYI: The driving force behind me packaging most of these is that
plaso
is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)
I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.
Hmm..
Maybe I should move it. A little background.
Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives.
One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface.
I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it.
So the architecture is:
CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection
I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought.
With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso?
Thanks Greg
I forgot to say the one package I know of that they are struggling to replace is perl-image-exiftool. Exiftool can pull timestamp related metadata from a wide variety of docs/files (including images of course). They have tried the hachoir python library, but it isn't performing fast enough for their needs so they dropped it for now. In the current alpha release of plaso, they are simply not handling a lot of these files. If anyone knows a high-performance library to do what exiftool does, I will pass it along to the devs to evaluate. It only needs to read metadata, not write it like exiftool can do. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 25 Apr 2013 13:41, Greg Freemyer
Sascha Peilicke
wrote: On 04/24/2013 11:48 PM, Greg Freemyer wrote: <snip>
FYI: The driving force behind me packaging most of these is that
plaso
is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)
I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.
Hmm..
Maybe I should move it. A little background.
Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives.
One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface.
I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it.
So the architecture is:
CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection
I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought.
With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso?
We have other similar projects, with more than one way of handling the packaging. One way would be to keep it as pyton-plaso and make a remark in the Description about the engine(plaso) and the included cli-tools, a hint about the extra gui would be nice. Or, if separate packages are absolutely wanted, pyton-plaso (engine) and plaso-tools (the cli). Third possibility would be to name it just "plaso" and give a hint about extra gui (4n6time) in Description and as "Suggestion" Personally I'm fine with keeping it as it is. This is an expert tool, not for the generic (dumbest possible) user. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2013 01:41 PM, Greg Freemyer wrote:
Sascha Peilicke
wrote: On 04/24/2013 11:48 PM, Greg Freemyer wrote: <snip>
FYI: The driving force behind me packaging most of these is that
plaso
is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)
I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.
Hmm..
Maybe I should move it. A little background.
Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives.
One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface.
I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it.
So the architecture is:
CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection
I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought.
With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso?
So if it's nowadays a mostly-Python or Python-only story, then d:l:p maybe an appropriate place. Otherwise we could at least link it to d:l:p similarly to python-qt4 and python-kde4 from KDE:Qt and KDE:Distro:Factory (AFAIR). If you want to have it über-awesome, have the base package named "plaso" and require a sub-package called python-plaso which contains everything under %{python_sitelib}. But if you don't expect anybody to ever import the Python modules, you can just go the easy route and name it plaso. d:l:p has several examples. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 25, 2013 at 8:49 AM, Sascha Peilicke
On 04/25/2013 01:41 PM, Greg Freemyer wrote:
Sascha Peilicke
wrote: On 04/24/2013 11:48 PM, Greg Freemyer wrote:
<snip>
FYI: The driving force behind me packaging most of these is that
plaso
is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)
I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.
Hmm..
Maybe I should move it. A little background.
Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives.
One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface.
I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it.
So the architecture is:
CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection
I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought.
With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso?
So if it's nowadays a mostly-Python or Python-only story, then d:l:p maybe an appropriate place. Otherwise we could at least link it to d:l:p similarly to python-qt4 and python-kde4 from KDE:Qt and KDE:Distro:Factory (AFAIR).
If you want to have it über-awesome, have the base package named "plaso" and require a sub-package called python-plaso which contains everything under %{python_sitelib}. But if you don't expect anybody to ever import the Python modules, you can just go the easy route and name it plaso. d:l:p has several examples.
The SR is revoked for now. I will resubmit when I figure out what I want to do. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2013 04:42 PM, Greg Freemyer wrote:
On Thu, Apr 25, 2013 at 8:49 AM, Sascha Peilicke
wrote: On 04/25/2013 01:41 PM, Greg Freemyer wrote:
Sascha Peilicke
wrote: On 04/24/2013 11:48 PM, Greg Freemyer wrote:
<snip>
FYI: The driving force behind me packaging most of these is that
plaso
is using them. Plaso is a new python application that parses filesystems and creates a single integrated timeline of all the activity found on the computer. It pulls events out of all of the above so the timeline can be comprehensive. (I don't think it uses libpff yet.)
I just saw that submit request, why did you call it python-plaso? If it's just an application that happens to be written in Python, you don't need (or want) the python- prefix. If it is a Python library that is potentially usable by others, you may want to submit it to devel:languages:python and develop it there.
Hmm..
Maybe I should move it. A little background.
Log2timeline was written a couple years ago in perl. It was a highly praised application in computer forensics / incident response. I packaged it in security where it still lives.
One complaint was it was too slow, so a small team rewrote it from scratch including rewriting most of the perl modules it used as the libyal collection that was the original subject of this email. Plaso itself is an engine that can be used with cli or gui front ends. A couple cli front ends are in the package. At least one addon package (4n6time) provides a gui interface.
I hesitate to call it a library because it provides so much functionality including defining/maintaining a database with all the timeline data in it.
So the architecture is:
CLI Front-ends (log2timeline.py, psort.py) GUI Front-ends (4n6time is the only one I know) The plaso engine The libyal c library collection
I pushed plaso to security because that is where log2timeline is, but I didn't give it any thought.
With the above background, do you think I should move it to d:l:python? If I leave it in security, should I change the name to plaso?
So if it's nowadays a mostly-Python or Python-only story, then d:l:p maybe an appropriate place. Otherwise we could at least link it to d:l:p similarly to python-qt4 and python-kde4 from KDE:Qt and KDE:Distro:Factory (AFAIR).
If you want to have it über-awesome, have the base package named "plaso" and require a sub-package called python-plaso which contains everything under %{python_sitelib}. But if you don't expect anybody to ever import the Python modules, you can just go the easy route and name it plaso. d:l:p has several examples.
The SR is revoked for now. I will resubmit when I figure out what I want to do.
Hehe, take your time ;-) And thanks for the detailed explanation btw. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Greg Freemyer
-
Sascha Peilicke
-
Yamaban