On Thu, Feb 9, 2012 at 11:38 AM, Marcus Meissner wrote:

On Thu, Feb 09, 2012 at 10:41:45AM -0500, Greg Freemyer wrote:

...

Security maintainers,

I've submitted a new role SR to be a maintainer of the security project since I've been pushing a bunch of DFIR packages there (Digital Forensics / Incident Response).

You don't really need to be a maintainer in the project to maintain them, you could also be a package maintainer.

(maintainers can be set per-package or per-project).

Yes, I'm already a maintainer on 5+ packages in security. But if I want to copypak anything to security, I have to be a maintainer, right? That's what drove me to do the SR. I see you accepted my SR, thanks for doing that.

...

Assuming I'm accepted, I have a few questions:

1) Is there a guideline for accepting new packages I submit?  How about patches to packages I maintain.

ie. Can I just submit them from my home and accept them with no review, or is their a concept of letting another maintainer accept my SRs?  Is that for both new packages and for updates?

That really depends on the project and the folks inside. For most, self-accepting is ok.

Okay, these are all packages I pushed to security, so I'll self-accept them for updates / patches. For new packages, I think I'll let them sit until someone else takes a look at them. I've only been packaging for about a year and it's very part time, so someone else at least taking a casual look at the specfile etc. would be good.

...

2) Several of the packages require packages from other repos to install.  That's not a problem for factory / 12.2, but what about providing packages for 11.4/12.1.  Should I just document that users need to install multiple repos?  Or should I "osc linkpac" them to security?  (If so, what's the best syntax for osc linkpac?)

Do not link into security, this will kind of break...

As security is a devel project of Factory, they should have the sources and not just links.

Better make some kind of backports repository somewhere.

It's not so much back ports, as perl / python modules that simply weren't in 11.4/12.1. They are in d:l:perl and d:l:python in general and can be installed from there, but then users have to have 3 or 4 repos added just to use these apps. There is probably a dozen or so of these secondary perl/python modules. If I copypak them into security, is that okay, or should I just create my own DFIR project. (I currently have 12 true DFIR libraries / apps in mind, plus the dozen or so perl/python modules that they depend on. I expect to be doing more in the near future, but I haven't decided which packages to do next yet.)

If the number of forensic packages is high (like above 20 or so), a subproject security:forensics might at some point in time be created.

I hope to get about 20 for 12.2 and then grow from there. I'm indifferent to putting them in security vs. security:DFIR. Now that you accepted my SR, the only issue for me is the above copypak issue.

...

3) dc3dd is currently in the archiving repo, but it makes more sense to me in the security repo.  I want to push it to factory.  Should I linkpac it to security first, then push from there?

There is no such package "dc3dd" in Archiving.

sorry, Archiving:Backup

In general the full sources are to be pushed to factory, not links. So you would copypac the sources over to security and submit them afterwards.

But! If this package is not maintained by yourself, ask the maintainer of that package (politeness ;).

I already got myself added as a maintainer and upgraded the version, but in Archiving:Backup

...

4) So far I haven't submitted any pen testing tools.  Since those can be used for both good and bad, I wanted to know if there is a established policy for that class of tool.  ie. They are encouraged? discouraged?

If they are clear hacking tools, meaning you can use them to easily crash machines, execute code or similar things on remote machines by just clicking -> Not even allowed on the OBS due to german law.

That is not overly clear to me. One example is pyrit. I have that in my home project now: home:gregfreemyer:Tools-for-forensic-boot-cd > pyrit It's for cracking wireless networks. Is that one okay in OBS? I'll treat all pen testing tools on a case by case basis going forward. Can I just email you privately to ask if they are okay, or should I post here on opensuse-factory?

Otherwise our position in general is mostly neutral to them.

...

5) I'd like to put together a wiki page that let's people know these DFIR packages exist.  Is there an existing wiki page I can add to?

I do not know, but likely not.

If no one speaks up I'll create a Portal:Digital Forensics / Incident Response page

Ciao, Marcus

Thanks Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2/9/2012 12:20 PM, Marcus Meissner wrote:

On Thu, Feb 09, 2012 at 12:08:09PM -0500, Greg Freemyer wrote:

...

That is not overly clear to me.

One example is pyrit. I have that in my home project now:

home:gregfreemyer:Tools-for-forensic-boot-cd> pyrit

It's for cracking wireless networks. Is that one okay in OBS?

...

I'll treat all pen testing tools on a case by case basis going forward. Can I just email you privately to ask if they are okay, or should I post here on opensuse-factory?

Mostly on a case by case basis :/

e.g. the metasploit framework definitely is a no-go.

As for pyrit, it seems the only purpose is cracking WPA things... I would need to check with our legal guys, but the answer might tend to be "not good". Lets just ignore that for now (and don't try to put it in Factory ;)

Not your fault of course but what a dumb law... Criminals use things like reading to gain things like knowledge to commit crimes, therefor outlaw reading and gaining knowledge. How stupid do you have to be to make it illegal merely to have/host/share such software, when that is the only way to protect _against_ such software? Like I said not your fault of course, don't mistake my purpose. The rule-makers everywhere are idiots, or at least have very opaque and probably undesirable aims, probably very often both. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 09, 2012 at 12:42:32PM -0500, Greg Freemyer wrote:

Marcus,

Thanks for accepting yara to security.

But it builds find in my home project for several repos:

home:gregfreemyer:Tools-for-forensic-boot-cd > yara

In security it is failing for all:

https://build.opensuse.org/package/show?package=yara&project=security

It looks like there are extra code quality checks in security. Is that right?

Yes, it needs to build with set RPM_OPT_FLAGS which it did not. I am fixing it ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

For anyone lurking, I did create a Portal page http://en.opensuse.org/Portal:Digital_Forensics_/_Incident_Response Please feel free to update that page if you have any relevant info / thoughts. Thanks Greg On Thu, Feb 9, 2012 at 1:19 PM, Greg Freemyer wrote:

On Thu, Feb 9, 2012 at 1:13 PM, Marcus Meissner wrote:

...

On Thu, Feb 09, 2012 at 12:42:32PM -0500, Greg Freemyer wrote:

...

Marcus,

Thanks for accepting yara to security.

But it builds find in my home project for several repos:

home:gregfreemyer:Tools-for-forensic-boot-cd > yara

In security it is failing for all:

https://build.opensuse.org/package/show?package=yara&project=security

It looks like there are extra code quality checks in security.  Is that right?

Yes, it needs to build with set RPM_OPT_FLAGS which it did not.

I am fixing it ;)

Ciao, Marcus

Thanks, I appreciate the help.

Greg

-- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo -    http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org