Bug#856932: Fwd: Bug#856932: hashcat dependency problem

[Phil]

Yeah, the problem here is different.

The dependencies are just incorrect (neither Mesa, nor Pocl are officially
recommended by hashcat and there is no such dependency for the hashcat
project) and the user needs to understand what s/he needs to do to get
hashcat working (a guide like the one I posted above) and why s/he needs to
do all these steps.

We can't just invent/pick some (random) dependencies that will trigger a
warning when hashcat is started. We also should make it much easier for the
user to get it running, e.g. without the need to change kernel versions,
struggling with the boot manager, downloading huge new packages (new
kernels, new headers etc), etc.

Also one shouldn't need to update the whole distro/kernels/headers, just to
install the drivers... the correct headers should always be present within
the repo (not "only" for the newest version).

There is actually no need to run the .run files, because Kali already has
some packages (for Nvidia and AMD at least, maybe also for the Intel
OpenCL? I didn't test yet).
The problem I experience when I tried to install the proprietary drivers is
that you can't do it at all, unless you update the whole kernel, distro,
because of the missing kernel headers. The packages were successfully
installed, but they didn't work! It said something like ... skipping module
build because of missing headers... and after that the user has the
impression that everything should be working, but nothing was correctly
build/installed instead.

Yeah, I also think that we should allow a manual installation... but the
current state is the opposite! We have the (incorrect) dependency on
Mesa/Pocl, when the user tries to uninstall it, hashcat will be uninstalled
too etc. So this is exactly what you said we should avoid, e.g. that the
user can install/uninstall some drivers without messing up with the hashcat
package.

My suggestion remains, we need to have some sort combination of *correct*
dependencies and a lightweight wrapper that warns the user if he doesn't
have installed the AMD/Nvidia/Intel proprietary drivers yet.

Thanks

On Wed, Mar 8, 2017 at 10:28 AM, Gianfranco Costamagna <
locutusofborg at debian.org> wrote:

> Hi,
>
>
>
>
>
> >Well, as said, the only correct way would be that the "hashcat" package
> directly depends on NVidia drivers, AMD drivers or Intel drivers.
> >
> >But as far as I understood this can't be enforced because otherwise the
> hashcat package can't be installed by default (and debian has the policy
> which doesn't allow >non-free packages to be shipped by default).
> >
> >Yeah, it would make sense to have a dependency tree like this:
> >hashcat depends on hashcat-nvidia | hashcat-amd | hashcat-intel
> >hashcat-nvidia depends on [proprietary Nvidia driver], hashcat-base
> >hashcat-amd depends on [proprietary AMD driver], hashcat-base
> >hashcat-intel depends on [proprietary Intel driver], hashcat-base
> >
> >(where "|" means "or"  and the [] denotes the correct drivers from
> nvidia.com, support.amd.com and software.intel.com correspondingly).
>
>
> I tried to do something really similar to boinc, shipping cuda packages [1]
>
> unfortunately this approach is not scaling too much for:
> - Debian derivatives (they call graphical packages a little bit differently
> - Custom drivers (e.g. download from the official repo the .run binary and
> install it, no deb involved
> - ISO where you can't install all the drivers just because you can :p
>
> I would be very upset about the system forcing me to install a driver
> because it can't detect my custom-built downloaded one.
>
>
> [1] https://sources.debian.net/src/boinc/7.6.33%2Bdfsg-6exp1/
> debian/control/
>
> (I know this is not applying completely to this bug report, but I wanted
> to give my .02$ about the topic)
>
> (runtime warnings are probably the best thing we can do at this point)
>
> cheers,
>
> G.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-security-team/attachments/20170314/f9229030/attachment.html>