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