On Mon, Jul 07, 2014 at 11:12:23PM -0700, Vincent Cheng wrote:
> On Mon, Jul 7, 2014 at 9:48 AM, costamagnagianfra...@yahoo.it
> wrote:
> >
> > Hi Steffen and all,
> >
> > today while talking with a backbox project administrator I discovered that
> > popular tools such as openvas directly calls th
Charles Plessy writes:
> 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.
I th
Hi Charles,
Quoting Charles Plessy (2014-07-08 13:24:34)
> 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 a
Hi Charles,
Charles Plessy 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 wil
Hi Lars,
thanks for your well-argumented and detailed position on this subject. The
problems that you describe can be roughly summarised by “principle of least
surprise” and “slippery slope”. In this particular case, I quite disagree with
the first, but of course can not entirely dismiss the sec
On Mon, Jul 7, 2014 at 9:48 AM, costamagnagianfra...@yahoo.it
wrote:
>
> Hi Steffen and all,
>
> today while talking with a backbox project administrator I discovered that
> popular tools such as openvas directly calls the amap binary.
>
> I never talked with them, but I don't think it is feasibl
Hi Steffen and all,
today while talking with a backbox project administrator I discovered that
popular tools such as openvas directly calls the amap binary.
I never talked with them, but I don't think it is feasible to ask to every
security tool provider to patch their code for the only debian
On Mon, 7 Jul 2014, Adam Borowski wrote:
By the way, it would be nice to have a common scheme for installing wrappers
of this kind -- especially if /bin vs /usr/bin is going to go away.
If you're open to dpkg-divert, config-package-dev lets you do this. Taking
molly-guard as an example, insta
On Mon, Jul 07, 2014 at 12:19:15AM +0200, Jakub Wilk wrote:
> * Adam Borowski , 2014-07-06, 21:04:
> >I see some legitimate scenarios for a single package to have
> >something both in $X/bin and $X/sbin, but not really across
> >package boundaries.
>
> These are deliberate:
None of your examples
On Jul 07, Jakub Wilk wrote:
> Would you call them “legitimate” or not?
I would call them "a future problem" since the world is moving to using
/usr/bin/ for everything and I expect that we will follow as well in
a couple of releases.
--
ciao,
Marco
signature.asc
Description: Digital signat
* Adam Borowski , 2014-07-06, 21:04:
I see some legitimate scenarios for a single package to have something
both in $X/bin and $X/sbin, but not really across package boundaries.
These are deliberate:
* safe-rm ships /usr/bin/rm;
* molly-guard ships /usr/sbin/{halt,poweroff,reboot,shutdown}
*
Hi!
On Sun, 2014-07-06 at 21:04:25 +0200, Adam Borowski wrote:
> On Sun, Jul 06, 2014 at 04:02:05PM +0100, Lars Wirzenius wrote:
> > The standards FHS directory layout gives us four locations in which to
> > put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
> > then have four pr
On Sun, Jul 06, 2014 at 04:02:05PM +0100, Lars Wirzenius wrote:
> The standards FHS directory layout gives us four locations in which to
> put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
> then have four providers of yoyo, but that would be very confusing.
> Even using bin vs s
On Sun, Jul 06, 2014 at 10:49:30PM +0900, Charles Plessy wrote:
> Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
> > On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> > > >
> > > > This violates the Policy's section 10.1, but it is still my
> > > > favorite solutio
> Il Domenica 6 Luglio 2014 15:51, Charles Plessy ha
> scritto:
> > Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
>
>> On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
>> > >
>> > > This violates the Policy's section 10.1, but it is still my
> favorite s
Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
> On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> > >
> > > 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,
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 highl
❦ 6 juillet 2014 10:56 +0200, Javier Fernandez-Sanguino :
> 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.
This has al
El 05/07/2014 16:47, "Ralf Treinen" escribió:
>
> On Sat, Jul 05, 2014 at 09:01:45PM +0900, Charles Plessy wrote:
> > > > Il Sabato 5 Luglio 2014 13:03, Charles Plessy
ha scritto:
> > > >
> > > > The ‘amap-align’ package version 2.2-4 install the file ‘amap’ in
‘/usr/bin’,
> > > > this is why I a
On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> >
> > 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 renamin
On Sat, Jul 05, 2014 at 09:01:45PM +0900, Charles Plessy wrote:
> > > Il Sabato 5 Luglio 2014 13:03, Charles Plessy 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
> Il Sabato 5 Luglio 2014 14:03, Charles Plessy ha scritto:
> >> > Il Sabato 5 Luglio 2014 13:03, Charles Plessy
> 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
> > Il Sabato 5 Luglio 2014 13:03, Charles Plessy 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 bo
Hi Charles
> Il Sabato 5 Luglio 2014 13:03, Charles Plessy ha scritto:
> > Le Sat, Jul 05, 2014 at 11:56:28AM +0100, Gianfranco Costamagna a écrit :
>>
>> I looked before at amap-align, but the package provided by your one is only
>> amap-align, there is no "amap" installable, hence I don't
Hi Clarles,
> Il Sabato 5 Luglio 2014 12:48, Charles Plessy ha scritto:
> > Le Fri, Jul 04, 2014 at 02:20:12PM +0100, Gianfranco Costamagna a écrit :
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Gianfranco Costamagna
>>
>> * Package name : amap
>> Version : 5.4
>>
Le Sat, Jul 05, 2014 at 11:56:28AM +0100, Gianfranco Costamagna a écrit :
>
> I looked before at amap-align, but the package provided by your one is only
> amap-align, there is no "amap" installable, hence I don't think there will be
> a clash for the packages, right?
The ‘amap-align’ package ver
26 matches
Mail list logo
