12-08-2015, 12:48 AM
Anyone here experienced with creating and maintaining Linux packages?
|
Packages for Linux distributions
|
12-08-2015, 12:57 AM
I am, but you knew that.
The problem with packaging hashcat right now, as dropdead and I were discussing, is that hashcat doesn't exactly adhere to the FHS. Basically the hashcat directory is a working directory, and that's rather contradictory to the FHS. Ideally before we go down the road of Linux packaging, we would re-organize the file structure, such that binaries are in /usr/bin; kernels, rule files, etc. are in /usr/share/hashcat; and user files (pot, restore, induct) are in the user's home directory, e.g. ~/.hashcat). Otherwise, we basically just have to stuff everything in /usr/share/hashcat and have the user run from that directory as root. 
12-08-2015, 01:01 AM
Yes, that's correct. I just wanted to start the discussion. I think what we need is a list of paths we'd need to change to make it more compatible.
Btw. this _maybe_ has influence on the windows port, too, but it's not a must. For windows I think people like it as it is (do everything in the installation directory).
12-08-2015, 01:41 AM
Ok, here's an example of a package manifest for oclHashcat 64bit (truncated in places where repetitive)
Code: /usr/bin/oclHashcat64.binAnd then there's some things that should go along with this, 1. Any file that hashcat writes to (potfile, session files, etc.) should go in ~/.hashcat. I think both hashcat & oclHashcat can share this directory. 2. Should also have ~/.hashcat/rules, ~/.hashcat/masks, etc. for local/user-created files. 3. Default internal search path for rules, masks, charsets, etc. including /usr/share/oclHashcat and ~/.hashcat to help keep command lines short. Can either always search the internal paths first, followed by cwd, or if we detect a file path (e.g. preceding / or ./) skip searching path/cwd. 
I think we should distinguish this task in 2 separate goals:
1. what devs of hashcat/oclHashcat need to change/do to facilitate creation of packages. 2. what the people need to do/know whose goal is to prepare the packages (aka maintainers). Maybe we should discuss this in 2+ different forum threads in the future (such that there exists a general "packaging" thread, a "package maintainer" thread and an "allow packaging" - only for changes in hashcat/oclHashcat source code - thread). Here below I only discuss what hashcat and oclHashcat need to change (not what the distro maintainers need to do, i.e. not where THEY - maintainers - need to put the files). Therefore, my discussion here is only about where oclHashcat/hashcat should try to find the files (and which one it should prefer if there are multiple options or files with same name in different locations). RULES: 1. if the binaries are being run on a non-unix system (e.g. windows. But should we limit it to Linux? what about osx ?), only use [cwd] for every path (as it was before) 2. always prefer current working directory [cwd] if the binary is directly executed from the current directory (e.g. "./oclHashcat64.bin") 3. if the user just runs "hashcat-cli64.bin" / "oclHashcat64.bin" etc (i.e. by using the PATH variable), do not search in [cwd] 4. developers should prefer to use the non-packaged version (i.e. everything is relative to [cwd]), this also implies that kernels (e.g. when disabling BINARY_KERNEL) should only be in [cwd] 5. for temporary files always prefer the /tmp/hashcat/ folder if it exists 6. a not so important but additional feature we could add is to help the user (directly by modifying the hashcat/oclHashcat source code?) to find .rule/.hcmask files etc for instance at ~/.hashcat/ with some kind of inbuilt tab-completion (or wouldn't it be better to modify /extra/tab_completion/oclHashcat64.sh to do so?) ??? 7. (what about paths on OSX with cpu hashcat?) ??? TYPE OF FOLDERS: profile_folder: - location: [cwd] or (~/.hashcat/) (or should we use ~/.hashcat/oclHashcat/ and ~/.hashcat/hashcat/) - list of files: 1. [session].pot 2. [session].log 3. [session].restore (and [session].restore.new) 4. [session].outfiles (DIR) 5. [session].induct (DIR) 6. [session].induct/loopback.[TIMESTAMP]_[RANDOM_NUMBER] 7. *.dictstat 8. *.hcstat 9. kernels/4098/*.kernel ??? packaged_file_folder: - location: [cwd] or /usr/share/hashcat/ - list of files: 1. kernels/4098/*.llvmir 2. kernels/4318/*.cubin temporary_file_folder: - location: /tmp/hashcat/ (preferred!?) or [cwd] - list of files: 1. temp files used for --remove ([hashfile].old and [hashfile].new) There might be the need to adapt this guide a little bit. Any suggestion is welcome.
12-08-2015, 07:59 PM
I agree with #1-4.
For #5, I'd much rather prefer to see ~/.hashcat/tmp over /tmp/hashcat, if for no other reason than to better enable multiple users to share the same system. I don't see a reason at this point why hashcat & oclHashcat can't share a working directory, would certainly be a lot more convenient. Suggestions from epix:
Suggestions from phil:
Some more thoughts:
Shared, those files go in /usr/share/hashcat for both hashcat and oclHashcat:
Not shared: hashcat:
The following files are for testing. I'd say we don't copy them at all, they are _only_ part of the source tree: hashcat:
Finally we need to discuss the profile folder. My suggestion:
(12-09-2015, 12:06 AM)atom Wrote: I disagree partially, we need to distinguish between hashcat and oclHashcat on /usr/share/doc/ because of colliding filenames in the docs/* folder Actually I didn't suggest that anything in /usr/share should be shared between hashcat and oclHashcat. I said I see no reason that the working directory (i.e., ~/.hashcat) cannot be shared between the two cats. Paths in /usr/share absolutely should be unique. (12-09-2015, 12:06 AM)atom Wrote: Shared, those files go in /usr/share/hashcat for both hashcat and oclHashcat: And this ties in with what I just wrote: these must not (and actually cannot) be shared at all unless you plan to break all of these things out of hashcat/oclHashcat and create an entirely separate hashcat-common package or something. You cannot have two packages that write to the same file path.
12-09-2015, 12:22 AM
Indeed well hashcat-common would be nice, but it's too much at once I think.
So here's the updated suggestion: hashcat:
oclHashcat (also oclHashcat in the folder names for cudaHashcat):
|
|
« Next Oldest | Next Newest »
|