Re: [SC-L] What is the size of this list?
Great points Karen! We can't prove a program is "secure" in the same vein. The danger I am spouting off about is the idea that we would solve the software security problem if we just take a more "scientific" or "mature" (or whatever) approach. I think those can definitely reduce the risk, but I don't think it will reach the goal. I am all for getting 50% of the way there. That is a lot better than being 0% or even 25% of the way there! I am just VERY concerned that if we try to sell management the idea that we are now taking a "scientific" approach (or whatever the term), we will end up with implied promises that will lead them to expect perfection, which won't come. They will likely ignore all our disclaimers that we are only seeking a partial solution to what we can solve, at least in the current state of thinking. Getting them to even take any action is a challenge in many companies, so some could argue my concerns are foolish. I think they are important because you want to make sure any buy-in you eventually get expects the right things. If you don't do this, you will end up in an even worse position down the road. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting "Goertzel, Karen [USA]" : Actually, we can't prove programs are bug free if by "bug" we also mean all possible anomalous behaviours. My colleagues keep pointing this out to me when I suggest that we should start leveraging the computational power of computing grids to analyze complex software the same way other researchers are using grids to develop models of the natural world, the human genome, etc. They keep quoting that bloke Kurt Gödel with his pesky little incompletness theorem as proof that 100% complete analysis of software cannot be done. Frankly, I'm beginning to think this is their excuse for not even trying to get me to the 50%. But the point is, even if you can do everything "right" in terms of building software to be vulnerability-free and behaviourally-benign, you apparently cannot achieve 100% verification that you've done so. Ergo, assurance can never be 100%. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Actually, we can't prove programs are bug free if by "bug" we also mean all possible anomalous behaviours. My colleagues keep pointing this out to me when I suggest that we should start leveraging the computational power of computing grids to analyze complex software the same way other researchers are using grids to develop models of the natural world, the human genome, etc. They keep quoting that bloke Kurt Gödel with his pesky little incompletness theorem as proof that 100% complete analysis of software cannot be done. Frankly, I'm beginning to think this is their excuse for not even trying to get me to the 50%. But the point is, even if you can do everything "right" in terms of building software to be vulnerability-free and behaviourally-benign, you apparently cannot achieve 100% verification that you've done so. Ergo, assurance can never be 100%. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Brad Andrews [andr...@rbacomm.com] Sent: Friday, August 21, 2009 11:41 AM To: sc-l@securecoding.org Subject: Re: [SC-L] What is the size of this list? I completely agree with your final statement Karen, but I see a lot more of the words aiming at the 100% mark and I think that is ultimately a bad focus since it is unachievable and therefore will waste focus and effort. While on paper we can "prove" programs are bug free (security-related or not), it doesn't work in practice. I may be biased by my experience, but you won't be able to design a perfect program anymore than you can design a "flawless" piece of handmade furniture. Flaws happen. They focus should be on minimizing them and reducing the risk that any flaws that make it through will cripple the end product, whether it be a wood table or a software program. A recent CERT podcast implied that we could reach your 100% as we matured and that has just stuck in my craw. I don't think it really is achievable, though making the case is going to take more than a quick reply on this list. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI [snippety snip] ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
I completely agree with your final statement Karen, but I see a lot more of the words aiming at the 100% mark and I think that is ultimately a bad focus since it is unachievable and therefore will waste focus and effort. While on paper we can "prove" programs are bug free (security-related or not), it doesn't work in practice. I may be biased by my experience, but you won't be able to design a perfect program anymore than you can design a "flawless" piece of handmade furniture. Flaws happen. They focus should be on minimizing them and reducing the risk that any flaws that make it through will cripple the end product, whether it be a wood table or a software program. A recent CERT podcast implied that we could reach your 100% as we matured and that has just stuck in my craw. I don't think it really is achievable, though making the case is going to take more than a quick reply on this list. -- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting "Goertzel, Karen [USA]" : Interesting. My definition of "secure" is for software is "dependable, trustworthy, and survivable (or, if you prefer, resilient)", i.e., (1) It's got to behave correctly and predictably; (2) It's got to behave non-maliciously and also not be subvertible (i.e., no weaknesses that can be exploited as vulnerabilities); (3) When it comes under attack, 1 & 2 need to hold true for as long as possible before the software's execution gracefully degrades and ultimately fails; when it does fail, it must do so in a manner that doesn't make it, its data, or its resources vulnerable to further compromise, and it must recover to an acceptable level of operation (which, obviously, needs to be specified) as quickly as possible, with as little damage as possible (and having minimised the extent of that damage). Obviously, there's very little software that can satisfy all three of these criteria 100%. But even 50% is better than 0%. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Interesting. My definition of "secure" is for software is "dependable, trustworthy, and survivable (or, if you prefer, resilient)", i.e., (1) It's got to behave correctly and predictably; (2) It's got to behave non-maliciously and also not be subvertible (i.e., no weaknesses that can be exploited as vulnerabilities); (3) When it comes under attack, 1 & 2 need to hold true for as long as possible before the software's execution gracefully degrades and ultimately fails; when it does fail, it must do so in a manner that doesn't make it, its data, or its resources vulnerable to further compromise, and it must recover to an acceptable level of operation (which, obviously, needs to be specified) as quickly as possible, with as little damage as possible (and having minimised the extent of that damage). Obviously, there's very little software that can satisfy all three of these criteria 100%. But even 50% is better than 0%. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: Peter G. Neumann [neum...@csl.sri.com] Sent: Thursday, August 20, 2009 6:50 PM To: Matt Bishop Cc: Goertzel, Karen [USA]; Secure Coding List Subject: Re: [SC-L] What is the size of this list? Let me amplify what Matt Bishop has said. I tend to deal with TRUSTWORTHINESS, which encompasses security, reliability, survivability, human safety, and anything else that you have to trust whether you like it or not. Security is only one aspect of it. Long ago Butler Lampson wrote a paper pointing out that if it is not secure, it won't be reliable, and if it is not reliable, it is may not be secure. That was applied to access controls in hardware, but it is equally applied to SYSTEMS. Also, all of those trustworthiness properties tend to be emergent properties of the entire system/enterprise/whatever. Beware of folks who tell you their crypto algorithm (for example) is 100% secure, and ignore that fact that if it badly implemented or the keys are stored in an unsecure operating system, then all bets are off and 100% secure becomes 0% secure. end of soapbox, which some of you have heard from me before. Peter ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Let me amplify what Matt Bishop has said. I tend to deal with TRUSTWORTHINESS, which encompasses security, reliability, survivability, human safety, and anything else that you have to trust whether you like it or not. Security is only one aspect of it. Long ago Butler Lampson wrote a paper pointing out that if it is not secure, it won't be reliable, and if it is not reliable, it is may not be secure. That was applied to access controls in hardware, but it is equally applied to SYSTEMS. Also, all of those trustworthiness properties tend to be emergent properties of the entire system/enterprise/whatever. Beware of folks who tell you their crypto algorithm (for example) is 100% secure, and ignore that fact that if it badly implemented or the keys are stored in an unsecure operating system, then all bets are off and 100% secure becomes 0% secure. end of soapbox, which some of you have heard from me before. Peter ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Karen, Ah, once again I expressed myself poorly. Apologies to all; it was too early in the morning to write (I'm on Pacific time). As far as I'm concerned, being able to understand English is crucial to meaningful interpretation of literature written in that language, and being able to write and speak English with mastery is crucial to effective self-expression as a critic. So English mastery is not just "incidental and important", it is absolutely vital to the success of the English major who aspires to more than mediocrity. I did not mean that it was unimportant; indeed, I very strongly agree with you. I mean that learning to express oneself is part of the focus of a good English curriculum, but not the only one. You begin with basic instruction in that (English/Rhetoric/Comp Lit 1A-1B-1C), and then take an advanced course or two on that topic, and then continue to hone your skills on courses like Shakespeare, Orwell, Milton, Steinbeck, etc. But in those later courses the primary goal is not to teach you clarity of expression; you are assumed to know how to express yourself, and your skills improve as a result of constructive criticism on what you write. And without the ability to express yourself clearly, you can't discuss themes, characterizations, and other aspects of English. I think "secure" programming should be taught similarly. The primary goal of learning to program is not to write "secure" programs. it is to learn to write good programs, designed with the appropriate amount of thought for the requirements and use. Someone specializing in analysis of algorithms will probably not delve as deeply into software engineering as someone specializing in that area, and I think that requiring the algorithmist (is there such a word?) to know software engineering at that level is inappropriate. *But* the algorithmist should know how to write good code, and that's basically what we are talking about. I hope this clarifies what I meant. Learning to write good code is incidental to one's studies in the sense that it is not the end goal, but it is a necessary skill, and an important one, for all who program. I feel the same way about software development. Writing software sloppily results in software the functional objectives of which can be subverted, either accidentally or intentionally. Such software cannot be said to satisfy those objectives, and thus it must be seen as failing, at least partially. It's only because we have accepted such partial failure for as long as there has been software that our standards for what we consider "goodness" for software are so poor. Yep; if your requirements are poorly thought out, your software may satisfy them, but it (almost certainly) won't do what it should. An observation: it's not just in software that we accept partial failures. Think of the last time you called a large company about a problem :-). Thanks, Karen! Matt ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
As far as I'm concerned, being able to understand English is crucial to meaningful interpretation of literature written in that language, and being able to write and speak English with mastery is crucial to effective self-expression as a critic. So English mastery is not just "incidental and important", it is absolutely vital to the success of the English major who aspires to more than mediocrity. I feel the same way about software development. Writing software sloppily results in software the functional objectives of which can be subverted, either accidentally or intentionally. Such software cannot be said to satisfy those objectives, and thus it must be seen as failing, at least partially. It's only because we have accepted such partial failure for as long as there has been software that our standards for what we consider "goodness" for software are so poor. If we applied the same poor standards to safety-critical mechanical systems a heck of a lot more of us would be reading this mailing list from hospital beds, nursing home rooms, or the afterlife. That's if they even have Internet access in the afterlife. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Matt Bishop [bis...@cs.ucdavis.edu] Sent: Thursday, August 20, 2009 9:27 AM To: Secure Coding List Subject: Re: [SC-L] What is the size of this list? ...So I agree with what Rob posted, and I did have one thought. Is writing good English a "minor" objective of an English major? Probably, in the sense English curricula focus on interpretation of literature, literary criticism, and other aspects of literature. But it's an essential one. So perhaps "incidental and important" describes how I feel better than "minor". Matt ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Another lurker revealing himself ... my name is Matt Bishop, and I lurk at the University of California at Davis where I teach and do research in lots of areas of computer security, including (surprise!) what is traditionally called "secure programming" and "secure software development". For what it's worth, I don't like the use of the term "secure" because it's too vague -- I'd prefer "robust" or something related to assurance, but I can't come up with a short term. Oh, well. I've been working with "secure coding" for many years. I'm particularly interested in the interaction between coding and policy, and also in how to teach this stuff. I've done some training (long ago, with SANS), but now I focus on college/university education (for the most part). I get lots of good examples and ideas from this list, and sometimes the postings challenge me to think about different perspectives. In particular, the discussions of how people use these techniques, and the ones people find the most pernicious and troubling, help me give realistic examples when I teach students how to write good code. So Ken, thank you for starting and maintaining this list -- I think you've done the community a great service. A thought about Rob Floodeen's comment: 2. How to incorporate the concept of secure coding and new techniques/tools to do so. This should be a minor objective through our academic curriculum as well. Just like advanced math skills, we should have advanced secure coding skills for Software Engineers. My own feeling is that this should be a basic skill for people who program, not just software engineers. But the level at which practitioners (for want of a better term) need to know this varies depending on what they do. An occasional programmer (a physicist, for example) probably doesn't need to know about race conditions and, indeed, about security in general -- but she would need to know how to write a program that checks its input (lest the results be invalid -- GIGO), which is "security" from her point of view. A software engineer darn well better know about race conditions, though! So I agree with what Rob posted, and I did have one thought. Is writing good English a "minor" objective of an English major? Probably, in the sense English curricula focus on interpretation of literature, literary criticism, and other aspects of literature. But it's an essential one. So perhaps "incidental and important" describes how I feel better than "minor". Matt ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
hi martin and rafael, I agree with Martin. Software security is essential in most embedded systems. Also note that there is an interesting fractal line between hardware and software in such systems that often makes for interesting security situations. Consider Java-based smart cards (which I worked on a decade ago) which were susceptible to both malicious applets and differential power analysis. Designing a secure system involved understanding both the hardware and the software. At Cigital we continue to do lots of software security work with embedded systems companies, especially in the mobile space. The OS vendors, the carriers, and the application providers all have security responsibilities (and can all screw the whole thing up). By the way, QUALCOMM was a member of the BSIMM study and has a mature software security initiative underway. See http://bsi-mm.com gem company www.cigital.com podcast www.cigital.com/silverbullet podcast www.cigital.com/realitycheck blog www.cigital.com/justiceleague book www.swsec.com On 8/20/09 5:14 AM, "Martin Gilje Jaatun" wrote: Rafael Ruiz wrote: > I am a lurker (I think), I am an embedded programmer and work at > Lowrance (a brand of the Navico company), and I don't think I can't > provide too much to security because embedded software is closed per se. > IMHO, it is very dangerous to assume that "since it is embedded, nobody has the source code". This "security through obscurity" approach was employed by the Bell telephone system in th 70's and 80's, but it turned out that there was no limit to what Phone Phreaks and their kin could dig up of supposedly secret information, including schematics and instruction manuals. In more recent times, reverse engineering of the DVD Content Scrambling System (CSS) and various RFID electronic fare cards has proven that if someone has physical access to a device, you must also assume that they can access the software. -Martin ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Rafael Ruiz wrote: I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. IMHO, it is very dangerous to assume that "since it is embedded, nobody has the source code". This "security through obscurity" approach was employed by the Bell telephone system in th 70's and 80's, but it turned out that there was no limit to what Phone Phreaks and their kin could dig up of supposedly secret information, including schematics and instruction manuals. In more recent times, reverse engineering of the DVD Content Scrambling System (CSS) and various RFID electronic fare cards has proven that if someone has physical access to a device, you must also assume that they can access the software. -Martin ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Hi everyone, I'm a victim of being a lurker, I work for Codenomicon doing blackbox security testing, research, and much more. I take interest in the SC-L to keep a fresh perspective/hone in on peoples ideas about software assurance and whitebox security. BR, Joshua Morin Security Strategist Codenomicon Ltd. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
inline On Wed, Aug 19, 2009 at 4:06 AM, Kenneth Van Wyk wrote: > The list has pretty consistently hovered around 1000 subscribers since > pretty shortly after I launched it in late 2003. Interesting. I would not have guessed that the list was so large. Guess I need to stop making inside jokes and calling people names from private jokes on the list lest I confuse the unwary. [...] > I do my best to keep my moderating light, and I welcome all perspectives > and opinions on the topics we discuss here. This list maintains a very high signal-to-noise ratio IMO. I think your moderation, if any, is effective so far. > Thanks. I've consistently found over the years that efforts like this are > worth the effort in a myriad of ways, and it's something that I gladly take > on. This list is useful and appreciated. Thanks again, -ae ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Hi SC-L, I'm a Lurker. I work for CERT | SEI | CMU and monitor the list in an attempt to keep an ear to the ground. While I'm not a professional programmer I do have an undergrad and graduate degree in CS which means I've been trained a little about programming. I'm really interested in two things with this list, 1. How do we teach secure coding from a training perspective (I develop training scenarios for CERT and I'm in the Workforce Development group, so this is exactly the kind of list that draws my attention.) 2. How to incorporate the concept of secure coding and new techniques/tools to do so. This should be a minor objective through our academic curriculum as well. Just like advanced math skills, we should have advanced secure coding skills for Software Engineers. Warm Regards, -Robert Floodeen On Wed, Aug 19, 2009 at 11:36 AM, Rafael Ruiz wrote: > Hi people, > > I am a lurker (I think), I am an embedded programmer and work at > Lowrance (a brand of the Navico company), and I don't think I can't > provide too much to security because embedded software is closed per se. > Or maybe I am wrong, is there a way to grab the source code from an > electronic equipment? That would be the only concern for embedded > programmers like me, but I just like to learn about the thinks you talk. > > Thank you. > > Greetings from Mexico. > > ___ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > ___ > ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
Arian J. Evans wrote: > I realized I tend to think of SCL as a small list of 30 people from > 2003 who are are all about 2 degrees of Kevin Bacon away from > each other. Sometimes more so than we know! I've been here for almost six years now, and until May, I had no idea that Karen used to work in the very same little department at the company that was about to lay me off, nor that we had a few other friends in common (albeit again from the software assurance community). > I am curious why I don't see many new names on SC-L. Lots of lurkers? That's probably true of any email list. I run a few where the same couple dozen or so names keep popping up in the From lines... out of thousands of members. -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume & other info. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] What is the size of this list?
On Aug 18, 2009, at 2:21 PM, Arian J. Evans wrote: Jeremiah Grossman and I were both pondering the size of the SCL recently. Is the list size public? It's not public per se, but only in the sense that the number isn't directly available--unless you ask for it. The list has pretty consistently hovered around 1000 subscribers since pretty shortly after I launched it in late 2003. I am curious why I don't see many new names on SC-L. Lots of lurkers? We do seem to have a high percentage of lurkers, but I always like to encourage newcomers as well as new active participants. I do my best to keep my moderating light, and I welcome all perspectives and opinions on the topics we discuss here. My primary moderating criteria are ensuring submissions are relevant to the list charter and keep a civil tone. Beyond that, everyone on the list is largely free to say/discuss whatever suits. Plain and simple: the list is what the members make of it. btw// SCL has always been a great place for academic and progressive-minded folks to talk about state of the art, and future ideas for secure coding. I have always recommended it to developers looking for new places to learn as a "best and brightest" haunt. So thanks for running it guys, Thanks. I've consistently found over the years that efforts like this are worth the effort in a myriad of ways, and it's something that I gladly take on. Cheers, Ken - Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
