[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters



Hi Javier,

thanks for your hint!

That was my first thoght, I'm upstream developer and DM of ettercap and we already install in sbin some of the binaries.

The problem is:
what does it happen when the user have both amap installed on the system and runs "amap" from the bash?

This might be highly confusing for the end user, and needs to force the path to both .desktop files (if they provide. them)

Thanks to all for your suggestions, I think I'll rename the binary in amap-thc, avoiding this kind of troubles (and maybe also moving in /sbin).

I need to prior check how many packages needs it and how they run it, bt seems the most trivial task to do.

I'm on smartphone, I'll answer to everybody asap, I would like to avoid top posting.
(I answered to this first since I'm pretty sure having two different binaries with the same filename on the PATH can lead to confusion, but I might be wrong somewhere)

Thanks for clarifying

Gianfranco
Sent from Yahoo Mail on Android



From: Javier Fernandez-Sanguino <jfs@debian.org>;
To: debian-devel <debian-devel@lists.debian.org>; 753704@bugs.debian.org <753704@bugs.debian.org>;
Subject: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters
Sent: Sun, Jul 6, 2014 8:56:13 AM


El 05/07/2014 16:47, "Ralf Treinen" <treinen@free.fr> escribió:
>
> On Sat, Jul 05, 2014 at 09:01:45PM +0900, Charles Plessy wrote:
> > > > Il Sabato 5 Luglio 2014 13:03, Charles Plessy <plessy@debian.org> ha scritto:
> > > >
> > > > The ‘amap-align’ package version 2.2-4 install the file ‘amap’ in ‘/usr/bin’,
> > > > this is why I am worried about clashes.
> >
> > Le Sat, Jul 05, 2014 at 12:11:37PM +0100, Gianfranco Costamagna a écrit :
> > >
> > > According to both popcons, and according to the fact that both of them are
> > > really niche packages and in really different environments (one for
> > > penetration testing and the other for med science) how do you feel about
> > > making them non-coinstallable?
> >
> > This violates the Policy's section 10.1, but it is still my favorite solution
> > for the reason that you explained above.
>
> I don't agree, packages should not be in conflict when it can be easily avoided
> by renaming files.

>

Renaming binaries is confusing for end users.

Since 'amap' (the scanner)  probably needs permission to make raw sockets to work properly (just like nmap) for some scans, why not install it in /usr/sbin/? That way there would be no conflict with the other package.

Regards

Javier



Reply to: