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

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



Hi Charles,

Charles Plessy <plessy@debian.org> wrote:
> Here, both programs have narrow and non-overlaping user bases, and are
> not installed on fresh standard Debian systems. 
> 
> This said, you made a good point that one has to consider if programs
> can be accidentally called with root priviledges, and what will
> happen in that case.
> 
> I think that it would be a good element for a checklist, rather than
> a good reason to forbid any name conflict at all.
> 
> We also have to consider that large multi-user, multi-purpose systems
> are becoming rare because it is easier to have virtual servers,
> chroots, and other container solutions.  To the practical possibility
> of needing both programs at the same time is even lower than when the
> Policy was written.
> 
> Here the surprise would come only if there were a system that is set
> up for both the purpose of bioinformatics and security port scanning,
> without the users being aware that there can be one or the other
> alternative installed.  I think that it is very unlikely.

Note that another use case, which will produce conflicts even if
neither package is installed is searching for a particular binary. Say,
I want to install the bioinformatics tool, and search for it using:
$ apt-file search bin/amap
if this search returns multiple packages providing bin/amap, I will be
a bit confused. Maybe I even think both would fit my purpose and will
install one randomly; however, I guess I will also be confused if this
search turns up /usr/bin/amap-bio and /usr/bin/amap-pt and no
/usr/bin/amap, so renaming does not necessarily help for this. So
while this is not really a point supporting always forbidding common
binary names, I just wanted to point out that two packages do not need
to be installed in order for their binary names to clash and
archive-wide operations such as apt-file have to be considered as well.

Cheers,

Mika

-- 

Attachment: signature.asc
Description: PGP signature


Reply to: