Re: secrets and lies
2000-11-14-16:37:06 Lipscomb, Al: > Open Source is often used to describe software that has its source > code available regardless of the license involved. Could be, people use words as they wish. But if you'll take a visit to http://www.opensource.org/>, you'll find that the term was very specifically drafted by a group of people with an agenda, and they've produced a branding service based on an Open Source Definition, which definitely excludes weirdo licenses like djb's. > "Free Software" as promoted by the Free Software Foundation (FSF) > is a different thing. I belive that the DJB software is Open > Source, but not free. Unlike Open Source, the phrase "free software" strongly predates the Free Software Foundation and they've made no attempt at branding it; rather, they pursue branding the GNU General Public License (GPL), which is stricter than (but compatible with) the Open Source Definition. > Based on the FSF definition it is not the cost, but what you are > allowed to do with it that is the issue. The FSF and the Open Source Initiative (OSI) are in pretty close agreement in a lot of these basics, and neither of them would endorse djb's license; he chooses to prohibit his users from making unrestricted use of the code he writes: they aren't allowed to distributed modified versions. That restriction is what leaves qmail and djbdns a bit off the main stream of the free software movement as it's crusading these days; people believe that that ability contributes in a basic and important way to preserving their investment in the time and effort required to become really expert in a package. If ever djb decides to stop maintaining his software, it stagnates, because while individuals may do so for their own benefit, the community as a whole cannot work together to do so --- redistribution of modified versions is critical for that sort of collaboration. Heck, even doing standards-compliant software packaging of his software is prohibited. It's not free software or open source in a fairly important way. This doesn't matter to djb, but it's important and this distinction shouldn't be glossed over. -Bennett PGP signature
Re: secrets and lies
2000-11-14-16:24:36 Adam McKenna: > Bruce Scheiner is a god, [...] It's possible you're being sarcastic, but there are those who would very nearly agree with you. While he may not actually be a god, he is certainly the single most important contributor to getting really top notch crypto out of research and into engineering; he's been teaching a lot of us the basic principles of sound design with crypto for a decade or more. -Bennett PGP signature
Re: secrets and lies
2000-11-14-15:11:55 Adam McKenna: > But you have to realize that this is the same argument put forward > by many people pushing closed source solutions over open source > ones (that it has been analyzed by "experts"), and invariably many > security holes are found anyway. Again, it helps to understand his particular background on the matter. He's very very specifically criticising "hack me" challenges, as contrasted with open audits of the design, and this is right out of his crypto roots. > Cases in point, [...] MS's shoddy PPTP implementation, [...] of which Bruce Schneier is the most vocal and respected critic, always cited in disputes over the merits or demerits of the protocol design and implementation. See http://www.counterpane.com/pptp.html>, the leading reference on PPTP's insecurity. What is more interesting to me is that Bruce has distinctly waffled on the topic of full disclosure re security problems. If you want to attack his views, I recommend looking there:-). -Bennett PGP signature
Re: secrets and lies
2000-11-14-15:11:43 Paul Jarc: > Only the "select few" will be able to audit it well, regardless of > the license, and they can afford to charge a hefty fee, regardless > of the license. They certainly can. They do not always choose to do so, however. If enough people really wanted to get a determined and thorough audit of qmail done, and they included some reasonably skilled programmers, I expect that we could borrow the missing auditing expertise from the big name-brand squadron of open source code auditors, the OpenBSD team. -Bennett PGP signature
Re: secrets and lies
2000-11-14-15:07:28 [EMAIL PROTECTED]: > [Bruce Schneier is] the author of perhaps the most popular book on > computer security that's available to the public. Which book are you referring to? "Secrets and Lies"? While it's a powerful contribution in the way of standing back and re-examining the big picture from a different direction, and has some important thoughts on limitations of what can be achieved, I'm not sure I'd cite it as the most popular book on computer security. It's hard to say what that might be, but I'd be more inclined to nominate Practical Unix and Internet Security. If you mean Applied Cryptography, it's certainly the most valuable and popular book on applied crypto available to the public, it approaches being the final and definitive work on the topic, and if he keeps updating it to track developing crypto technology (as he's uniquely qualified to do) it may hold that role for some time. But cryptography is only loosely related to computer security; it's a tool which can sometimes be used to help with some security problems, is all. > He's generally well regarded - though having sendmail 8.8.8 on > the secondary MX of his domain doesn't make you feel super > confident :> As a computer security generalist (as opposed to a cryptanalyst), his major thrust seems to be an argument that it's impossible to really secure systems, and after perhaps some superficial efforts to knock out the biggest problems, the place to concentrate your efforts is on monitoring and risk management. With that as a given, I expect he runs sendmail and BIND; things like qmail and djbdns are for those of us who haven't given up on really completely securing our systems:-). -Bennett PGP signature
Re: secrets and lies
2000-11-14-15:01:07 Charles Cazabon: > However, as far as qmail goes: all the crackers in the world have > had access to the qmail source code and design documentation for > years, and none have yet found an exploitable security hole. You > could consider that a fairly thorough audit-by-fire. And a case could be made that the charming and personable way qmail has been represented in various public fora makes this audit-by-fire even better: at this point, there are enough people around the world who hate djb's guts and would never touch anything that he even advocated much less wrote, just because of how much they like his way of carrying on discussions in public mailing lists, that I kinda expect more than one person has gone wading through qmail with blood in his eye, desperately hoping to wipe the smug grin off djb's face and get him to knock off the damned gloating already. Hasn't happened yet. _That's_ trial by fire. In a backwards kind of way this reminds me of a funny I heared referenced recently, apparently some exceptionally unnaturally clueless spammer harvested _bugtraq_. Makes me feel all warm and snuggly just thinking about it:-). Hmm. Wonder if he was located in the mid-east, maybe all this news about a "cyber-war" there is just bystanders being taken out by the schrapnel thrown from the smoking hole where that spammer used to reside. -Bennett PGP signature
Re: secrets and lies
> > >So has any expert ever audited qmail or djbdns? > > > > No. Any audit worth doing would be prohibitively expensive for a > > freeware project. $1000 wouldn't even begin to cover it, at > > least for qmail. Whoa, sure, it'd cost a load if you paid someone to do it, but open source has other routes. A team can be formed. I betcha if someone could get a dozen or so volunteers who were serious programmers who were willing to invest serious time on the project, that they could approach the folks at OpenBSD, who have been doing a perpetual on-going security audit with _great_ results for some years now, and get a lot of assistence and instruction in exchange for some good press. > Not to mention that the whole point of freeware and open source > software in general is to give everyone the ability to audit the > software, not just a select few. So if we want to try and pursue an audit it might be more harmonious with our whole approach if we did so using a volunteer effort coordinated over the internet and open to anybody with the necessary resources to donate. > It sounds like the author of this book is a M$-type weenie. I'm afraid that doesn't follow at all. Bruce Schneier has some very strong opinions, and his long-standing dislike of these "challenges" is very well defended in its setting. Bruce is also a vocal proponent of open source in security-critical settings, and a really vicious critic of Microsoft. The view that you dispute (that the only way to get a good security audit is to pay a bazillion dollars to a company for a commercial one) isn't a view that I'd expect Bruce to advocate, and in fact really hasn't been expressly advocated by anyone here, it's more of an implication that you sorta tripped over. Neither Bruce nor dsill are what you'd call Microsoft drones:-). -Bennett PGP signature
Re: Arguments in favor of djbdns?
2000-08-01-10:50:58 Ben Beuchler: > Sometime in the near future we will be a djbdns shop. It will > take some arm twisting of the other admins, but it will happen. That's good. You'll be glad. I'll tell you how I made the transition, not that this is the only way or anything, but it worked really well for me. I started by setting it up on my own workstation. First I ran myself a dnscache. Then I scripted some stuff (which I've published, it's my little packet of helper scripts, available from dnscache.org) to make it easy for me to set up "secondaries", tinydns servers that poll other servers via zone xfer to get the authoritative data that they'll serve. I set up one of them on my workstation, polling from my company's authoritative nameserver to pick up the company zones. As my own workstation doesn't have a static IP addr, I ended up putting my dnscache on 127.0.0.1, and my tinydns on 127.0.0.2. Then I told my dnscache to reference my tinydns for the zones that tinydns was tracking. Now I had a standalone nameservice of my own, with tinydns pumping out the zones our company is authoritative for, and could experiment and learn how it worked. My next step was to start rolling out dnscache installs. I started with servers; any box that wants to be able to do DNS lookups, and that can run dnscache, I tried to install it. I got the major servers anyway. That bought an instant security and performance improvement, with no visible changes; this was just switching server at a time to using 127.0.0.1 in /etc/resolv.conf and running a local dnscache. That went perfectly, no problems at all. Then I got the company's secondary running tinydns, with my mirroring scripts pulling via zone xfer from our primary. That worked fine too, and enabled the other SAs to see what a working tinydns install looks like, and to look over the config and satisfy themselves that they'd find it maintainable and supportable. That was also painless, since secondaries normally don't get manually maintained, and since I'd already tested out the scripting that brought it up accurately and correctly the first time. Finally we set up a new tinydns server to be the authoritative master for our zones. We had it mirroring via zone xfers, with my scripts, from our primary. We then had the registrars switch the zones to the new server. Then a week or so later, when we were sure nobody would still be thinking about the old one, we simply switched it off, and started hand-maintaining the new tinydns master. In between those two, when the new primary was up and mirroring properly and before switching off the old BIND master, we switched the secondary so it got its updates via rsync-over-ssh from the new tinydns primary rather than via zone xfer from the old one. It may seem kinda roundabout, but I found this a low-stress, painless way to ease on into the new way of doing things, and I haven't been lynched by my fellow SAs yet. I did take some care to talk through what I wanted to do, and why, and what visible changes would appear at each step, and how they'd need to administer things, so everybody felt informed and felt like they had a chance to object if I was about to gore their ox somehow. -Bennett PGP signature
