full-disclosure - Re: Re: Re: !SPAM! Automated ssh scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: fulldisc at ultratux.org (Maarten)
Subject: Re: Re: Re: !SPAM! Automated ssh scanning

On Sunday 29 August 2004 22:41, gadgeteer@...gantinnovations.org wrote:
> On Sun, Aug 29, 2004 at 09:27:10PM +0200, Maarten (fulldisc@...ratux.org) 
wrote:
> > On Sunday 29 August 2004 00:04, gadgeteer@...gantinnovations.org wrote:
> > > On Sat, Aug 28, 2004 at 10:23:36PM +0200, Maarten
> > > (fulldisc@...ratux.org)
> >
> > wrote:
> > > > I remember well that at one time I wanted to install a SuSE system
> > > > without X, and just one package triggered 4 other packages and those
> > > > then triggered the full X eventually.  It really was a pain.  Mind
> > > > you, that was a few years back, I get the distinct impression things
> > > > have changed for the better now.
> > >
> > > I've not used yast but with rpm at least you can pass a flag to ignore
> > > dependencies.
> >
> > Yes.  But that's hardly the point, is it.  You can remove the unwanted
> > packages using 'rpm -e --nodeps' too, but you shouldn't need to.
>
> Why not?  If someone were installing X and failed to install one of
> those packages triggered by the dependencies in your example above then
> their installation would be broken.

IF you're installing X then my example doesn't apply.  My example applied to a 
scenario where one definitely _doesn't_ want X (on a server perhaps) and it 
gets installed despite, due to some obscure dependency.

Then you are tasked to remove all of X (and it's a lot) by rpm -e --nodeps. 
That is a big job... especially since you're not absolutely sure which 
packages belong to or depend on X and which do not.

> If the 'one package' were compiled to use shared libs from X it would be
> broken if you do not install those libs.  Usage without X may or may not
> induce it to actaully break but there is code in there that if executed
> expects to find those shared libs.

There is the possibility (AFAIK) to name a dependency "Optional".  That would 
be a better choice in the example(s) at hand.  SuSE's Yast doesn't have X as 
dependency since it can work without it, albeit it is looking nicer in X.
More packages should follow that.  If a package offers a ncurses mode, IMHO it 
should not depend on X (or kdelibs, or glib, or gnome-lib, etc.(*))

(*) well except if it's real base functionality depends on those.

But as I said, things already are (much) better now as they were a couple of 
years back...

> The correct thing would have to be re-compile that package to not depend
> on any of the packages not installed.

Hum, I don't fully agree but splitting up the package would be a good thing, 
akin to emacs / xemacs, thereby elegantly solving the problem.

Maarten

-- 
Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER