On Thu, Feb 9, 2012 at 11:38 AM, Marcus Meissner <meissner@suse.de> 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