Ken,
I'm trying not to take your response as a "stay-away" message. I understand
the concerns are varied and complex. I appreciate the well-wishing at the end,
and I felt I ought to acknowledge that first. :) Admittedly, I am confused by
some of the remarks. More inline....
Q
On Oct 17, 2011, at 9:42 PM, Ken Moffat wrote:
> On Mon, Oct 17, 2011 at 08:58:07PM -0700, Qrux wrote:
>>
>> At the end of the day, if you're absolutely forced to link your stuff with
>> X, and have to build it--or, you don't mind deploying X to your server, then
>> that's your call. I don't care. I'm not suggesting there's no use case.
>> I've had to admin servers that happened to have X on them. I'm not saying
>> it doesn't exist. I don't think it should be there--and you seem to be
>> saying the same. I'm not sure what your gripe is.
>>
>
> BLFS is about many things. Looking at questions on support, I get
> the impression that most users are putting it on desktops. If I
> thought otherwise, I would be even more worried about the lack of
> interest in vulnerabilities (see my posts on -dev about why I
> stopped contributing, probably at the beginning of this year).
Perhaps. But, being "everything to everyone" is probably contributing to the
fall-off of maintenance. That may be the case, that it's about many things,
but maybe that's part of the problem.
You have a view of the users that I don't, since I'm not looking at the support
issues. OTOH...There is such a thing as a vocal minority. And, given the
complexity of the X-and-friends build (this is a sign of respect for the
complexity of X/KDE/Gnome/etc, not a sign of derision) I would suspect there
would be support issues. Heck, even with LFS, there are a fair number of folks
asking questions that just aren't reading the book carefully enough. I could
only imagine for X. Plus, if someone is learning Linux, and finds the idea of
building a whole setup from source, aren't the chances pretty high that that
person is going to run into issues?
As for why you stopped contributing...It seems like a variant of the issue
we've been discussing. If there were a smaller "Core", wouldn't it be easier
to track the vulnerabilities? It would at least be easier to say: "Well, we've
'audited' this subset. It seems okay."
>> I'm also not saying to remove X from BLFS. I'm suggesting that there's an
>> area of overlap (this is getting to be a unfortunately repost, essentially,
>> of a prior message) between both desktop users (yes, this is a legitimate
>> use, I never said it wasn't; I've used X on my desktop before) and server
>> users, and that there ought to be an identifiable "Core" that's usable by
>> both modalities.
>>
> The common ground between desktops and servers is, in my opinion,
> regrettably tiny: pkg-config (when not in LFS), which or a variant,
> maybe pcre, maybe cd/dvd writing, openssl, openssh (server vs
> client), perhaps pcre, ntp, maybe mail, maybe rsync, maybe nfs,
> and perhaps docbook and python. There are other things I always
> build, but many of them don't really belong on *production* servers
> (e.g. strace etc - essential for an editor expecting things to break
> when the toolchain is updated, but probably yet another attack
> vector on a production server).
> So, I don't think that putting these, plus the other packages you
> care about, into a 'core' is helpful.
Well, "production server" means many things to many people. For some, (and I
might infer you're in this category), they might think of the ideal as being a
mathematically-provably secure machine with exactly no more attackable surface
area than the application/port/protocol/IP/MAC you've defined, with provably
secure code everywhere else. For us mere mortals, we typically have to rely on
commercial distributors to update their software, whether it's a commercial
Linux distributor or a Win/Mac/Other situation, or we are Linux admins, and try
to do our day jobs while still trying to keep our machines from being totally
porous.
Admittedly, being a system you build from source, an LFS/BLFS user is *able* to
audit the entire source tree of what he deploys...OTOH, no one I know audits
their code (that I'm aware of), and we rely on the community and some
common-sense safeguards like verifying checksums and using "released" or
"stable" versions.
This gets us back to where I would like to see "Core"...Which is to be some
identified subset of the current BLFS that has careful attention paid to
several issues, dependencies (and mayhaps security) among them. And, to give
the comfort to users of this "Core" by taking the step cut a release. Even
stronger, if those released lined up reasonably well with LFS releases, that
would further lower the risk (or perceived risk) of using such a system. Even
the small subset you mentioned would go a great distance. In fact, just having
the packaged you mentioned--SSL/SSH/NTP/MTA/rsync/NFS--would at least make a
system bootable with secure remote login while maintaining a small attack
surface area (well, maybe not NFS on a public network or an open-MTA-relay).
So, yes, even if the subset is small, (I have a feeling my vision of "Core" is
a bit smaller than Bruce's vision of "Base" but maybe a bit larger than what
you would like), I still think it's worthwhile. It gets people able to log
into their system securely, have accurate time, be able to perform backups and
snapshots, and possibly send mail. That's a pretty big step up from "Oh-hey--I
compiled that kernel that boots!" So, I disagree that it's not helpful, from
the perspective of someone trying to get a server running. In fact, if you
take into your concerns about security, a smaller "Core" seems to have the
obvious benefit of being easier to "audit" and keep "secure". And, a smaller
system would be more tolerant of security-based dependencies.
>>> And no, I don't think that xorg has any place on a server, but even
>>> those of us using minimalist desktops (I prefer icewm) expect a bit
>>> more than what you are offering.
>>
>>> In case it isn't obvious, I don't see how your "minimalist server"
>>> build is going to satisfy most BLFS users.
>>
>> No one is asking you to run just the "Core". I was proposing a subset of
>> BLFS be identified as "this subset is sorta cruft-free". Then, you can pile
>> on as many layers of X, then Y, then Z, that you want to have, over it. I,
>> OTOH, will probably just install Xen or LAMP over THAT SAME "Core",
>> depending on whether it's in DomU or Dom0.
>>
> But, your core already appears to contain things that I have no
> interest in, nor need for. The strength of BLFS has always been
> that you can pick the things you want. The idea of a 'core' implies
> it should always be built.
What's the big deal? Just take out what you don't want. You're the one
inferring "always". I'm saying "this is a useful subset". You read it as:
"You must use these things." No one is saying that.
I think Bruce made the point succinctly when he said that even with LFS, you're
free to strip out packages when you're done building. You're free to take
things out of "Core", if you're even more minimalist. It's not like using
"Core" is a contract that says you can't use '/bin/rm' or maintain the system
however you want. I'm not sure what the complaint is. I'm just talking about
identifying a subset of the book that could make the claim: "Hey--if you build
these things, you get a hugely more usable system, even as a bootstrap to build
the apps or services you need, because...umm...you can log into it from another
machine, have accurate civilian time-keeping, be able to basic network-y
things, share files, and make backups." This is not worthless.
Yes. The idea of a "Core" is that you SHOULD build it. And, along with that,
it will provide features. I think we covered that twice. Just like with LFS,
you should build a bunch of it, if not all of it. Do you have to keep it?
Nope. Do you have to keep what's in this "Core"? No.
>> I mean, I assume (perhaps tacitly, given your concerns) you're building LFS
>> before BLFS. Why not think of it as a 3 stage process, (something like LFS,
>> BLFS "Core", BLFS-everything-else, where some folks can choose to get off
>> after "Core" and do their own thing? Is that so onerous?
>
> Perhaps people would prefer a recipe that says "build a+b+c, then
> your choice of k,l,m,n,o and x+y+z".
Yes, that is exactly the case. When you download new software that you haven't
compiled before, and your goal is to use it...Do you read every line of the
source first, then the build system? Or, do you look for a README/INSTALL
file? Yes, most folks who are in the camp of "I want to get this done, because
I need it to perform a task--not only because it's an exercise in their ability
to understand things, which is a brilliant side effect, but not their primary
goal--probably do like recipes. FFS, LFS and BLFS are recipes. How would you
characterize BLFS Section II.3? How would you characterize most of LFS? It's
not really a "pick-and-choose" section. It could be...But, if you don't have
devices, users, or startup files, you're going to have a really funky setup.
Is it still your choice? Yes. Don't confuse "suggestions" with "demands".
For experts, you can read a suggestion that says "build a+b+c" (e.g., LFS) and
decide that you don't need gettext and remove it. For the "learners", yes,
they ought to stick to it rigorously. What is they say in the LFS forum when
someone is obviously doing something wrong? RBBG? I suspect when new folks
build BLFS and encounter errors, the BLFS folks--like any sane people trying to
help--want to know what state the help-requester's build is in. So, you'd
probably prefer that they can tell you: "Well, I did a+b+c, then x+y+E+z," so
you can say: "Well, E looks out of place, and maybe you did that wrong. Let's
start there." Even more to the point, if they say: "Well, I did a+c, and
skipped 'b', because I don't need Devices, right?" you can say: "Hmm...well,
that might be an issue."
> For myself, packages which
> don't earn their keep drop out of my builds - I'm around 400 packages
> on my desktops (of which the parts of xorg that I build, and the
> parts of gnome I use or need for certain applications, are the main
> constituents). So, adding anything to the basic list of packages is
> not something I'll lightly do. For me, it doesn't actually matter how the
> book develops - I'll go my own way whenever I have to - but
Not sure what point you're making here...I can't help but feel a bit trolled
here...which is unfortunate, since I'm making a genuine effort (is that not
cool these days?) to understand the issues that BLFS is having. Who is adding
anything? ATM, I don't think the proposal is more than a reorganization of the
packages so that those not building Desktop platforms can have a set of
packages that's divorced from X. If you're building a Desktop...Who cares?
Run 4,000 packages. Or 400. Or 40.
As for things in my vision of "Core" that you don't want...Fine--you drop
things out you don't like. I've echoed that sentiment several times,
particularly on "downstream" packages. I'm just unsure of where you're
positioning your POV. Sometimes it's from the POV of the BLFS users needing
support on desktop-related compiles. Sometimes, it's about the principle of
keeping BLFS secure--or the lack of attention the previous maintainers paid to
it. Now, you seem to be talking about your own servers, and the last sentence
implies that you don't really give a damn where the book goes, because you'll
do what you need to do.
I'm not exactly sure how this contributes to making BLFS a more
maintainable/releaseable project.
> I'm concerned whenever changes seem to make it something it can't
> really be (e.g. suitable for production servers - fine, if you
> monitor security issues, but for the moment very dangerous if you
> don't), or to limit its general usefulness.
Who is limiting anything? It's not like you can boot LFS without a kernel. Is
it a removable component? No. Is LFS "limiting its general usefulness by
demanding it?" No. Is readline strictly necessary on a provably-correct
"production server"? No. Does that matter? No. Is it still useful for
people to have, especially when bash is their shell? Yes. Is it limiting to
include it? Is it valuable to suggest that people include it? Yes. Don't
confuse your own autonomy with the usefulness or benefit of the book's
suggestions.
Could a "common stable subset" be useful to people who want the ability to log
into their newly-built machine? Probably. Does that make it "limiting" to
say: "If you install a+b+c", you'll get these features. We have a feeling
these features are widely used by a large swath of users."? No. Is it clear
that what's implied is: "OTOH, if you're so pro you don't need a, b, or c,
remove it."? Yes. I think you're mistaking suggestions with limitation on
your autonomy. There's nothing wrong with BLFS talking about devices. Sure,
you might be able to skip that. But you'd have one hell of a tricky machine to
work with. Are most people going to follow the "suggestions" given? Yes. Is
it wrong to make that suggestion no? Does it need a disclaimer? Maybe...Is
all this fuss over a disclaimer?
Similarly, is there use to having SSHd installed by default? Yes. Do you have
to have it? No. Does it make it limiting to suggest to most people that they
install it? No. Does suggesting it somehow impair your autonomy to remove it?
No.
Come on...This is pedantry.
As for the comment about trying to make "[BLFS] into something it can't really
be"--yes, I think this is incredibly valid. Yet, I think that's putting the
cart before the horse. I appreciate that it's probably important to provide a
disclaimer: "Hey--just because we said this is useful doesn't necessarily mean
you should use it unwisely." OTOH...This is a little like the woman suing
McDonald's because the cup didn't properly warn her that "Hey--stuff inside is
hot." No one said "Core" is going to be FIPS-secure or an Orange Book-A
classified setup. Right now, we're just trying to piece together what that
subset would look like. I appreciate your suggestions in that regard. But,
let's not get ahead of ourselves. If and when a disclaimer needs to be made, I
have no doubt you'll lead the charge, and get it exactly right.
In particular, I think a "Core" would make security concerns *possible* to
address, and it will do that by being smaller. It's less to look over. If it
comes to a point where a disclaimer is needed (right now, though, I think
you're the only one in the hypothetical space that "Core" is about a
super-secure setup, then it's easy enough to say: "Hey--you still need to know
what you're doing mm-kay? This is still Linux, and if you connect up the
Interwebnetz, then you assume some risk. We've done our best, as a collection
of unpaid volunteers on an open source project to try to make this not a
complete sieve. Still, exercise caution." Out of curiosity...Does BLFS have a
disclaimer like this? Does LFS? Is anyone using LFS/BLFS under the mistaken
impression that's it's Fort Knox (or an NSA secure room)? Why are we so far
down this hypothetical road?
If the answer to that question is because you find my usage of the phrase
"production server" to be objectionable, then let's find a phrase you're okay
with to signify the class of servers out there that are deployed without a hot
lady-admin that spends her day looking over CERT reports and applying OS
patches and rebuilding application services on every new release, well-versed
in the theories of elliptic curves and asymmetric cryptography and
computational complexity and provably-correct algorithms, and is so efficient
at her work that she also has time to prove each line of all the code in her
servers by translating it all into Z--all while modeling environmentally
conscious lingerie in her copious spare time between NSA consulting gigs--but,
rather the set of servers that are deployed with good intentions and a modicum
of common sense with knowledgeable--but not omnipotent--admins. While a
security expert might throw up in his mouth a bit, I believe there's some
common g
round that might justify a subset of BLFS being useful, even to those who are
deploying a "live server". Does that phrase sit better?
In addition, like I said earlier, doesn't making a smaller subset both make it
easier to maintain, and easier to track its vulnerabilities? I feel like
you're going in a circle saying: "No--it's vulnerable unless you should a lot
of vigilance!" while saying: "No, a smaller subset wouldn't be useful, even
though it would have a smaller attack footprint!" and also saying: "No, I don't
need the packages you've identified in common, even though we agree on many of
packages, but simply because I disagree with a few of the other packages."
There's value to a "Core" subset because it's easier to maintain, has a smaller
attack footprint, and because it would be shared by a lot of users, so any
attention paid to it would benefit almost everyone. Having that "Core" be on a
release schedule that's more tightly integrated with LFS seems like it would be
a very useful tool, not to mention that it would simply "feel better" for those
who want a "Core" to deploy their applications on, who want--or need--to take
on the task of admin'ing their own server, because they'll know that the "Core"
they started with is a "release", rather than a never-ending-moving-target.
I'm going to go out on a limb, and guess that you're not reading the Discrete
Cosine Transform code in libjpeg from version to version to make sure there
aren't any vulnerabilities there. Guess what? That's okay. You're human.
But, you're taking "reasonable precautions", by verifying checksums, and using
their RELEASES, right. Does it come with a guarantee? No. But, does it make
you feel better? Yes. Would it be even better if you knew there was someone
who had those security concerns in mind? Yes. So, why not just volunteer to
be that person for "Core"? Furthermore, I think your security concerns give
even more weight to the argument to having a smaller "Core", because less code
is...less. Which makes it easier to audit and maintain from a security
standpoint.
I'm still trying to piece together what your specific objections are in the
context of having a subset of BLFS be identified as "Core", for the purpose of
being a "shared common subset" usable by "90% of the BLFS user community", on
top of which their application could be built, regardless of whether it's a
desktop KDE workstation, a mail-server or a full-blown web-app-server or even a
scientific research supercomputing cluster.
> BTW - please don't treat this as an attempt to deter you from
> editing BLFS, I've spent enough time on that unpleasant task, suffer
> it if you wiah ;-)
It's already proven to be an interesting exercise just to understand why it's
fallen into disarray (i.e., from the standpoint of having "released" marked
"stable"), with the amount of random noise and the constant wandering into OT
space...
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
