Tushar Teredesai wrote:
> Every time such a topic comes up, there is a huge discussion on what
> is required or not required and finally it turns into a discussion
> about the goals of LFS.
>
> I would like to propose that before adding/removing packages from the
> book, we should formalize what
Randy McMurchy wrote:
Hi all,
Hi Randy and All. First, I want to thank all participants to this
thread for keeping it civil. I am so glad we could do that.
My opinion/vote is -1. I feel that technically speaking, Randy, your
idea is fine. It is good to have a more secure system. I also f
i'm usually just a lurker here, but as someone who remembers the first
time using the book, i would have to vote against it being added
directly, though i do strongly agree with the hint idea. to me, it
seems that it belongs more in BLFS where it already exists, but either
with a without pam note
Justin R. Knierim wrote:
However the users of the LFS system are varying. A user who built LFS
for the educational value or who wants a different password library or
who uses it on a stand-alone system, shouldn't have to install a
password library if it isn't needed/wanted/required.
I agre
Robert Russell wrote:
you finish building LFS on your computer, and decide to celebrate by
going out to eat, a thief breaks into your house and steals your
computer.
True. If the thief wants to get the data though, a strong root password
won't stop him. All he needs to do is boot knoppix or
Robert Russell wrote:
On 8/5/05, Chris Staub <[EMAIL PROTECTED]> wrote:
Randy McMurchy wrote:
Archaic wrote these words on 08/05/05 00:18 CST:
BTW, out of the 70-odd boxes I manage, I would use (and do use) cracklib
on exactly one of them. That box also uses PAM, so even it would be
moot.
On 8/4/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Something I've thought about for a long time, and now that CrackLib
> is a maintained and stable package, I would like to propose that the
> community consider adding this package to Chapter 6 in the LFS build.
>
I say go ahead a
On 8/5/05, Chris Staub <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote:
> > Archaic wrote these words on 08/05/05 00:18 CST:
> >
> >>BTW, out of the 70-odd boxes I manage, I would use (and do use) cracklib
> >>on exactly one of them. That box also uses PAM, so even it would be
> >>moot.
> >
> >
>
Matthew Burgess wrote on a possible "securing" of LFS by moving away
from the inetutils binaries and concluded:
> Whilst researching this was quite enlightening, I think that such system
> hardening really does fall into "your distro, your rules". Clients such
> as ftp and telnet are still lar
>Installing CrackLib in LFS just makes more sense to me now than when
>I came up with the idea 8 hours ago. There so far has not been one
>technical reason why we shouldn't do it.
If you consider this a technical answer then great. I think we need to look at
what level of security LFS should offe
Kev Buckley wrote:
If LFS is going to be *secure*, then personally I hope you guys get
rid of most of the inetutils clients
Well, we already remove the servers, so by removing the clients we may
as well just remove the entire package :) Seriously though, secure
versions for most of those cl
I am not a developer but,
> 6) Currently, CrackLib cannot be integrated into LFS using BLFS
> instructions without adding Linux-PAM also.
Surely that is a reason for modifying a section of BLFS.
> Even if you simply install the CrackLib package, Shadow would have
> to be recompiled to use the
Randy McMurchy wrote:
Hi all,
Something I've thought about for a long time, and now that CrackLib
is a maintained and stable package, I would like to propose that the
community consider adding this package to Chapter 6 in the LFS build.
-1.
Technical reason:
It doesn't stop international use
Archaic wrote:
But back to the original pariah
> comment, when dealing with a dependency, it can cause a less than
> friendly response when, after several attempts at finding a solution, it
> is finally realized (or mentioned) that a necessary portion of LFS was
> excluded which would have solved
Randy McMurchy wrote:
No, you must explicitly use --with-libcrack for Shadow to link against
the installed libraries.
After checking this, you are correct sir. I do believe the "./configure
--help" output is misleading, since I assumed "default if found" would
enable it if found.
Sorry,
On Fri, Aug 05, 2005 at 02:10:43AM -0500, Randy McMurchy wrote:
>
> No, Archiac, a hint doesn't serve the same purpose.
Then perhaps your purpose was flawed in that it didn't account for
people who don't want/need cracklib or for the package not being needed
for a basic development system (which
On Fri, Aug 05, 2005 at 07:59:43AM +0100, Richard A Downing wrote:
>
> I assume ( note ;-) that you use 'book' here to refer to the BLFS Book.
You assume correctly. ;)
> My point is that BLFS-Support is NOT a 'BLFS Book' support list but a
> Beyond 'LFS Book' Support list. I have NEVER seen it
Archaic wrote these words on 08/05/05 02:01 CST:
> As an optional, yes. I also concur. However, the point that you just
> don't seem to be accepting is that a hint serves exactly that purpose.
No, Archiac, a hint doesn't serve the same purpose. I am proposing
that CrackLib be added to the Chapter
Justin R. Knierim wrote these words on 08/05/05 02:04 CST:
> I didn't say anything about disabling cracklib. I said to "install
> cracklib from BLFS". If one only installs cracklib, and returns to LFS
> to continue with shadow, all is good, right?
No, you must explicitly use --with-libcrack f
Randy McMurchy wrote:
Actually, not. The BLFS shadow instructions disable CrackLib because
it is expected that Linux-PAM is installed.
I didn't say anything about disabling cracklib. I said to "install
cracklib from BLFS". If one only installs cracklib, and returns to LFS
to continue with
On Fri, Aug 05, 2005 at 01:50:16AM -0500, Randy McMurchy wrote:
>
> At this point is seems 5 people have agreed that adding CrackLib
> is a good idea. Best as I can recall now, 3 have not.
As an optional, yes. I also concur. However, the point that you just
don't seem to be accepting is that a hi
Justin R. Knierim wrote these words on 08/05/05 01:53 CST:
> I am not sure if even a hint is needed, since it would be the worlds
> shortest hint! ;) It would say "install cracklib from BLFS, install
> shadow from LFS".
Actually, not. The BLFS shadow instructions disable CrackLib because
it i
Archaic wrote:
> On Fri, Aug 05, 2005 at 07:04:32AM +0100, Richard A Downing wrote:
>
>>I don't follow this. Isn't blfs-support the place for all beyond LFS
>>support questions. It's not limited to BLFS packages, so why should
>>there be a 'complete' lfs assumption.
>
>
> Because the book assu
Justin R. Knierim wrote:
(from shadow-4.0.9 ./configure --help):
--with-libcrypt try to use libcrypt (default if found)
Opps, sorry, meant:
--with-libcrack try to use libcrack (default if found)
Justin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linu
Archaic wrote:
I have not seen anyone say that a hint would be a bad move.
I am not sure if even a hint is needed, since it would be the worlds
shortest hint! ;) It would say "install cracklib from BLFS, install
shadow from LFS".
(from shadow-4.0.9 ./configure --help):
--with-libcrypt
Archaic wrote these words on 08/05/05 01:42 CST:
> The track has ended, though. Unless someone comes up with a new POV it
> is stagnated at people's person opinions. Of the 3 opinions, 2 are
> absolute ends of the spectrum and one is not. I have not seen anyone say
> that a hint would be a bad mov
On Fri, Aug 05, 2005 at 01:33:22AM -0500, Randy McMurchy wrote:
>
> Of course, absolutely impossible to determine who would have
> "perished" and who would have not. Please, let's attempt to stay
> on track here with the discussion of CrackLib. Sorry for replying
> to something off-topic.
The tra
Randy McMurchy wrote:
However, you wear your seatbelt, I'm sure. Regardless of the law.
Because it is the *smart* thing to do.
I don't consider a optional password security package to be anywhere
near important as the possibility of saving your life in an accident.
Sorry.
It would be, IMO,
Archaic wrote these words on 08/05/05 01:27 CST:
> On Fri, Aug 05, 2005 at 01:09:05AM -0500, Randy McMurchy wrote:
>
>>However, you wear your seatbelt, I'm sure. Regardless of the law.
>>Because it is the *smart* thing to do.
>
> Perhaps statistically it is, but try telling that to the countless
Chris Staub wrote these words on 08/05/05 01:19 CST:
> Randy McMurchy wrote:
>>The choice is still up to the reader to install the package or not.
>
> That's not a valid reasoning, particulary since it was you who said
> earlier that no package in LFS should carry a "this is optional"
> disclaim
On Fri, Aug 05, 2005 at 01:09:05AM -0500, Randy McMurchy wrote:
>
> However, you wear your seatbelt, I'm sure. Regardless of the law.
> Because it is the *smart* thing to do.
Perhaps statistically it is, but try telling that to the countless
people who would have perished if they were wearing a s
On Fri, Aug 05, 2005 at 07:04:32AM +0100, Richard A Downing wrote:
>
> I don't follow this. Isn't blfs-support the place for all beyond LFS
> support questions. It's not limited to BLFS packages, so why should
> there be a 'complete' lfs assumption.
Because the book assumes it and always has. S
On Fri, Aug 05, 2005 at 12:59:37AM -0500, Randy McMurchy wrote:
>
> Why shouldn't LFS do something that has such a sound technical
> reason, with really nothing that can be said against it, other than
> "I don't want to".
This is going around in circles. Your opinions have been clearly noted.
At
Randy McMurchy wrote:
Jeremy Huntwork wrote these words on 08/05/05 00:39 CST:
The choice is still up to the reader to install the package or not.
That's not a valid reasoning, particulary since it was you who said
earlier that no package in LFS should carry a "this is optional"
disclaimer
Randy McMurchy wrote:
Chris Staub wrote these words on 08/05/05 00:40 CST:
That's right, I don't have a technical reason against it. I just have a
problem in general with forcing someone to do something (like pick a
"strong") password "for their own good". Same reason why I don't think
seatb
Chris Staub wrote these words on 08/05/05 00:40 CST:
> That's right, I don't have a technical reason against it. I just have a
> problem in general with forcing someone to do something (like pick a
> "strong") password "for their own good". Same reason why I don't think
> seatbelt laws should e
Tushar Teredesai wrote:
> The problem is that BLFS assumes that you have built *all* package in
> LFS. So if you skip a package, you are a pariah when you post to
> BLFS-support :-)
>
> That is one reason I don't prefer packages being added to LFS, it
> takes away the options.
>
I don't follow
Jeremy Huntwork wrote these words on 08/05/05 00:39 CST:
> Randy, that's hardly fair. Several times in this thread people *have*
> offered you reasons and you come back and say they aren't valid,
That is simply not true. Please, Jeremy, provide just one time someone
offered a reason, other than
Matthew Burgess wrote:
> Randy McMurchy wrote:
>
>> However, LFS history has shown that we cannot count on such a document
>> to become formalized.
>
>
> I'm not sure if a formal set of rules is in fact possible. If we
> consider the packages that are in the book at the moment, they can be
> br
Randy McMurchy wrote:
I don't think so. And I can't imagine anyone else thinking so also,
unless they simply just want to disagree with the suggestion.
And therein lies the problem. Either unable or unwilling to allow for
different thinking.
--
JH
--
http://linuxfromscratch.org/mailman/listi
Randy McMurchy wrote:
Chris Staub wrote these words on 08/05/05 00:28 CST:
Why keep them from setting their passwords to "password" if that's what
they want to do?
They still can. :-)
However, should LFS install the mechanism to provide such an absolutely
poor security model?
I don't thin
Randy McMurchy wrote:
Yet you give a -1 for the simple addition of a single little old
library (and its dictionary) to LFS. Please provide something concrete,
else I'll think you are just disagreeing for the fun of it. :-)
I was giving my honest opinion. Just because I use cracklib in all my
Randy McMurchy wrote:
Yet you give a -1 for the simple addition of a single little old
library (and its dictionary) to LFS. Please provide something concrete,
else I'll think you are just disagreeing for the fun of it. :-)
Randy, that's hardly fair. Several times in this thread people *have*
On Fri, Aug 05, 2005 at 12:24:54AM -0500, Randy McMurchy wrote:
>
> That is not a reason to not include it. The technical reason I state
> is that it provides a mechanism to enforce strong passwords on the
> system. This is the *technical* reason I'm standing for.
No, you are standing for a featu
Chris Staub wrote these words on 08/05/05 00:28 CST:
> Why keep them from setting their passwords to "password" if that's what
> they want to do?
They still can. :-)
However, should LFS install the mechanism to provide such an absolutely
poor security model?
I don't think so. And I can't imagi
Randy McMurchy wrote:
Archaic wrote these words on 08/05/05 00:18 CST:
I have already stated it. There is no *technical* reason for including
it in a base development system.
That is not a reason to not include it.
/me blinks. about:kitchensink!
I'm sorry. What keeps users from setting
Justin R. Knierim wrote these words on 08/05/05 00:23 CST:
> It is hard to give good arguments for this question. I cannot argue
> that it isn't a useful library, and I use cracklib on every LFS system I
> build,
Yet you give a -1 for the simple addition of a single little old
library (and its
Randy McMurchy wrote:
Archaic wrote these words on 08/05/05 00:18 CST:
BTW, out of the 70-odd boxes I manage, I would use (and do use) cracklib
on exactly one of them. That box also uses PAM, so even it would be
moot.
I'm sorry. What keeps users from setting their passwords to "password"?
BT
Archaic wrote these words on 08/05/05 00:18 CST:
> I have already stated it. There is no *technical* reason for including
> it in a base development system.
That is not a reason to not include it. The technical reason I state
is that it provides a mechanism to enforce strong passwords on the
syst
On Fri, Aug 05, 2005 at 12:18:09AM -0500, Randy McMurchy wrote:
>
> So what Chris, we should modify the Shadow instructions to include
> some instructions on how to compile if Linux-PAM is not installed?
Why not? BLFS is the home of optionally do this or optionally do that.
> What is the point i
Randy McMurchy wrote:
But can't the same thing be said for many of the LFS packages. :-)
Heh, you are correct sir. :)
It is hard to give good arguments for this question. I cannot argue
that it isn't a useful library, and I use cracklib on every LFS system I
build, but I install pam as we
Chris Staub wrote these words on 08/05/05 00:05 CST:
> That's what I mean - modify (or add to) the BLFS instructions so that it
> explains how to use cracklib with shadow but without PAM.
So what Chris, we should modify the Shadow instructions to include
some instructions on how to compile if Li
On Fri, Aug 05, 2005 at 12:01:16AM -0500, Randy McMurchy wrote:
>
> I respect your opinion that it isn't needed, however, it would be
> much easier to understand if you gave just *one* reason why you
> think it wouldn't be a good thing.
I have already stated it. There is no *technical* reason for
Jim Gifford wrote these words on 08/05/05 00:07 CST:
> Randy what educational value does cracklib add if it's used with Shadow
> in LFS?
Glad you asked Jim.
Installing the CrackLib library and having Shadow link against it
shows folks how to set up and use a word dictionary to guard against
weak
Randy what educational value does cracklib add if it's used with Shadow
in LFS?
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the a
Randy McMurchy wrote:
Chris Staub wrote these words on 08/04/05 19:50 CST:
Then perhaps the BLFS instructions should be modified.
No, the BLFS instruction do exactly as they are intended. To
provide instructions to recompile Shadow if Linux-PAM is installed.
My suggestion is to add CrackLi
Justin R. Knierim wrote these words on 08/04/05 23:59 CST:
> Glad to offer my opinion. Secure passwords are important, agreed.
> However the users of the LFS system are varying. A user who built LFS
> for the educational value or who wants a different password library or
> who uses it on a s
Archaic wrote these words on 08/04/05 23:52 CST:
> On Thu, Aug 04, 2005 at 11:46:46PM -0500, Randy McMurchy wrote:
>
>>There would be no link that we could offer in LFS that could assist
>>the user in configuring Shadow to work with CrackLib. BLFS does not
>>have such a configuration.
>
> If BLFS
Chris Staub wrote these words on 08/04/05 19:50 CST:
> Then perhaps the BLFS instructions should be modified.
No, the BLFS instruction do exactly as they are intended. To
provide instructions to recompile Shadow if Linux-PAM is installed.
My suggestion is to add CrackLib to LFS so that Shadow it
Randy McMurchy wrote:
There really is no choices given in LFS Chapter 5 or 6, unless you want
to consider the text in the Vim instructions to be a choice. We suggest
a build method. It is up to the reader to follow, or not follow the
suggestions.
Ok, I can see what you mean.
You are entitl
On Thu, Aug 04, 2005 at 11:46:46PM -0500, Randy McMurchy wrote:
>
> There would be no link that we could offer in LFS that could assist
> the user in configuring Shadow to work with CrackLib. BLFS does not
> have such a configuration.
If BLFS cannot create such a situation, then a hint would sure
Randy McMurchy wrote:
Chris Staub wrote these words on 08/04/05 19:30 CST:
I agree. All that's needed is to add a link to that section of BLFS in
the Shadow instructions. Besides, I thought tight security was what HLFS
existed for - the base LFS is mostly just to teach people how to create
a
Archaic wrote these words on 08/04/05 23:42 CST:
> On Thu, Aug 04, 2005 at 11:39:06PM -0500, Randy McMurchy wrote:
>
>>This can be said for many of the LFS packages. Please provide an
>>opinion on whether it should be added to the default LFS build.
>
> Link to BLFS only.
There would be no link
Chris Staub wrote these words on 08/04/05 19:30 CST:
> I agree. All that's needed is to add a link to that section of BLFS in
> the Shadow instructions. Besides, I thought tight security was what HLFS
> existed for - the base LFS is mostly just to teach people how to create
> a system that work
On Thu, Aug 04, 2005 at 11:39:06PM -0500, Randy McMurchy wrote:
>
> This can be said for many of the LFS packages. Please provide an
> opinion on whether it should be added to the default LFS build.
Link to BLFS only.
--
Archaic
Want control, education, and security from your operating system?
On Thu, Aug 04, 2005 at 11:36:46PM -0500, Randy McMurchy wrote:
>
> You are entitled to your opinion, thanks for offering it. Though I
> cannot see why you think that by installing *one* simple library, and
> the accompanying dictionary, is something that we would not want to
> suggest in the defa
Archaic wrote these words on 08/04/05 23:32 CST:
> Here is an argument, then: it isn't needed for a base development system
> as proven by 6 years of its absence. There is no valid technical reason
> to include it or exclude it. It's merely a choice.
This can be said for many of the LFS packages.
Justin R. Knierim wrote these words on 08/04/05 23:25 CST:
> I was not aware of LFS being so strict. There are cases where the user is
> given a choice, for example with regard to System-V or BSD style init (notes
> in psmisc about a symlink and 7.1 with a link to the BSD init hint). I don't
On Fri, Aug 05, 2005 at 01:14:44PM +1200, steve crosby wrote:
>
> Ah, but if you feel you have the skillset to decide if you can skip a
> package in LFS, you should also have the skillset to fix (or at least
> make intelligent comment about) issues related to skipping that
> package in BLFS ;)
Th
On Thu, Aug 04, 2005 at 09:46:03PM -0500, Randy McMurchy wrote:
>
> What I believe folks should do is too simply agree with the proposal,
> or provide an argument against it. So far, there's only been
> positives, folks sitting on the fence not contributing a rebuttal
> notwithstanding.
Here is a
Justin R. Knierim wrote:
Randy McMurchy wrote:
There is no middle ground. LFS recommends a build method. We don't
sit on the fence and say, "well, if you really don't want this
package, you don't need to install it". This would need to be
added into several of the LFS package instructions. Is t
On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Jeremy Huntwork wrote these words on 08/04/05 22:21 CST:
>
Here is some suggested text for the cracklib library package
The Cracklib library provides a mechanism to check passwords against a
dictionary, and identify if a particular passwor
Randy McMurchy wrote:
There is no middle ground. LFS recommends a build method. We don't
sit on the fence and say, "well, if you really don't want this
package, you don't need to install it". This would need to be
added into several of the LFS package instructions. Is this what
we should do?
I
Randy McMurchy wrote:
>
> What I believe this thread is about is adding this package to LFS,
> "Yes" or "No". There really is no middle ground.
>
I'm for it. As requested, a simple "YES". This is a good thing as we
get to mention login.defs and give a quick intro to what it provides.
The defa
Jeremy Huntwork wrote these words on 08/04/05 22:21 CST:
> There are already precedents in the LFS book where items are shown to be
> at least somewhat optional. Read section 7.1. Also, the entire idea
> behind LFS is to customize the system to fit your needs - to be able to
> be in full contro
Randy McMurchy wrote:
This can be applied to many of the LFS packages. It is a meaningless
suggestion, as this is not the way it is done in LFS.
Perhaps salting a baboon would be a good idea.
Now that's a meaningless suggestion. Mine however, was not.
There are already precedents in the LFS
Randy McMurchy wrote:
You say this as if the LFS book as it is, is the way it should be,
and never be enhanced or changed to become better.
I did? Hmmm. I don't recall thinking that. But nice of you to explain to
me what I meant.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
Jim Gifford wrote these words on 08/04/05 21:34 CST:
> If a package is going to be added with the note that's it's not needed
> or can be skipped, it does not belong in LFS.
Exactly. That is why I came back on Jeremy's message about this.
However, he has not replied, so I don't know what to thin
Randy McMurchy wrote:
What are you saying is not needed?
Jeremy's suggestion that the package can be skipped, or the
installation of the package altogether?
If a package is going to be added with the note that's it's not needed
or can be skipped, it does not belong in LFS.
--
--
[EMAI
Jim Gifford wrote these words on 08/04/05 21:19 CST:
> Jeremy Huntwork wrote:
>
>>Well, add it without question then. As long as the book mentions that
>>you can skip it if you want.
>>
>
> If that's the case it's not needed then.
With all due respect Jim, your contributions have so far been
wo
Jeremy Huntwork wrote:
Well, add it without question then. As long as the book mentions that
you can skip it if you want.
If that's the case it's not needed then.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/m
Jeremy Huntwork wrote these words on 08/04/05 20:03 CST:
> steve crosby wrote:
>
>>Regardless, if the end user doesn't like/want the policy, all that's
>>required is to skip this package installation, much the same as people
>>can currently skip things like gettext, module-init tools, etc.
>
> We
Nice discussion. 30 messages in just over 3 hours!
Now, this is what this list is all about!
--
Randy
rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
20:28:00 up 124 days, 20:01, 2 users, load average: 0.30, 0.38,
Tushar Teredesai wrote these words on 08/04/05 20:09 CST:
> The problem is that BLFS assumes that you have built *all* package in
> LFS. So if you skip a package, you are a pariah when you post to
> BLFS-support :-)
>
> That is one reason I don't prefer packages being added to LFS, it
> takes awa
steve crosby wrote these words on 08/04/05 20:12 CST:
> Even using --with-libcrack, if no cracklib is found, configure and
> make merrily proceed without error and build the binaries - I'm not
> able to test the resulting binaries are workable for a few hours
> however ;)
This is good to know. I
On 8/5/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote:
> On 8/4/05, steve crosby <[EMAIL PROTECTED]> wrote:
> > On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> > > Randy McMurchy wrote these words on 08/04/05 19:12 CST:
> > >
> > > > This is a stretch. To the best of my knowledge, all the Cr
On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> steve crosby wrote these words on 08/04/05 19:56 CST:
>
> > Regardless, if the end user doesn't like/want the policy, all that's
> > required is to skip this package installation, much the same as people
> > can currently skip things like gett
On 8/4/05, steve crosby <[EMAIL PROTECTED]> wrote:
> On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> > Randy McMurchy wrote these words on 08/04/05 19:12 CST:
> >
> > > This is a stretch. To the best of my knowledge, all the CrackLib
> > > library does is check that the password a user enter
On 8/4/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote:
>
> > However, LFS history has shown that we cannot count on such a document
> > to become formalized.
>
> I'm not sure if a formal set of rules is in fact possible. If we
> consider the packages that are in the book a
steve crosby wrote these words on 08/04/05 19:56 CST:
> Regardless, if the end user doesn't like/want the policy, all that's
> required is to skip this package installation, much the same as people
> can currently skip things like gettext, module-init tools, etc.
I'm not sure about that. My testi
steve crosby wrote:
Regardless, if the end user doesn't like/want the policy, all that's
required is to skip this package installation, much the same as people
can currently skip things like gettext, module-init tools, etc.
Well, add it without question then. As long as the book mentions that
On 8/4/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Is it a common enough (ie, several mainstream distros include it by
> default) package to mandate that every LFS user build and install it?
Gentoo includes it by default (i.e. no use flags when compiling shadow).
--
Tushar Teredesai
mail
Randy McMurchy wrote:
Should we only do what other Distros do? Can LFS not be innovative
and take a lead in something, and have other Distros follow us?
That's not really what I meant to imply. Of course I'm not all about
just doing what everyone else is doing - if I were I wouldn't be
associ
On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote these words on 08/04/05 19:12 CST:
>
> > This is a stretch. To the best of my knowledge, all the CrackLib
> > library does is check that the password a user enters during the
Regardless, if the end user doesn't like/want
Randy McMurchy wrote these words on 08/04/05 19:12 CST:
> This is a stretch. To the best of my knowledge, all the CrackLib
> library does is check that the password a user enters during the
> password changing routine does not match something in the user's
> entry in /etc/passwd and the password d
Zachary Kotlarek wrote these words on 08/04/05 19:04 CST:
> Another issue is that cracklib only helps you enforce whatever
> password policies cracklib likes. So if your password complexity
> policy doesn't match the one that cracklib enforces it's again just
> extra junk that gets in the wa
On Aug 4, 2005, at 6:18 PM, Jeremy Huntwork wrote:
Randy McMurchy wrote:
Are there any disadvantages to including it in the LFS book?
There's at least one -- it's extra junk that gets in the way if you
use any other library that provide password complexity checking.
After fighting to make
On 8/5/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote:
> > Hi all,
>
> Is it a common enough (ie, several mainstream distros include it by
> default) package to mandate that every LFS user build and install it?
> Are there any disadvantages to including it in the LFS book?
>
On 8/5/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Jim Gifford wrote these words on 08/04/05 18:33 CST:
> > There any many different methods for user authentication and password
> > setup. If it's just about creating a secure password, we should add
> > npasswd. http://www.utexas.edu/cc/unix/so
Jim Gifford wrote these words on 08/04/05 18:33 CST:
> There any many different methods for user authentication and password
> setup. If it's just about creating a secure password, we should add
> npasswd. http://www.utexas.edu/cc/unix/software/npasswd
Not to argue your position on this Jim, but
1 - 100 of 111 matches
Mail list logo