Users of CSLA need to have a way to be quickly and automatically notified when there is a security issue found in the framework.
Rocky needs an easy, dollar-free and labor-free way to deliver that information to us.
Perhaps he could set up a single thread (preferably that only he and hand-picked users could post to) that would be used as a master notification thread. Anyone who wants to know about security problems could enable email notifications from that thread. The actual details should be posted in other threads, just a brief description and the link to the detailed thread would suffice.
The same idea might also work for bugs and bug-fixes...
Comments?
Rocky,
I just checked your issue log.
There is a major difference between "This is a developer-oriented feature I would like to improve" and "This is a serious security issue that will let someone hack into your computer and view or destroy your data when using CSLA."
Some of us work for customers who REALLY, REALLY need to care about such issues...
I would ask that you split it up into two logs. That way, systems operation folks can subscribe to the security issue feed and developers can subscribe to both. I can assure you that most system operations staff will not want to (and therefore will not) read a log that is largely composed of developer issues. Not right, but there it is. :(
And if you say to yourself, "Gee, the above two paragraphs are somewhat contradictory, aren't they? I mean, if the system operations folks really cared, they would read up on this stuff!"
Welcome to the real world, and console yourself that with this change to your issues log your tax dollars will be better spent... :)
Please
don't ruin a great thing by placing extra demands on Rocky. I believe the original purpose of CSLA was as
a learning tool. If you decide to use it
in a production environment, the onus is on you to notify your customers of any
security issues. We should be eternally
grateful for any help that Rocky provides because he is under no obligation to
do so. You should not expect this kind
of support for something that is free. You
should have known this before you started working with CSLA. If you want more support there are commercial
products you can try.
I for one would
not like to see CSLA commercialized. I have enjoyed using CSLA since VB 5.0 and
have learned a great deal from it. I
fear that commercializing CSLA would limit the number of developers that get to
experience CSLA. This would be a shame since it
is a great framework and learning tool.
If CSLA was commercialized, I would have never learned what I had
learned from it.
malloc1024:
Please don't ruin a great thing by placing extra demands on Rocky.
I don't intend to. Rocky doesn't have to be the one to do the work. :)
My suggestion was to use this forum in a very specific way, one that does not require Rocky to do any additional work at all. I probably wasn't clear enough, so I'll try to explain.
All we need is a single thread on this site that acts as a reference to any other security-related thread. If write-access to that thread can be limited to a number of individuals, then it will stay a bit better organized, but that isn't essential. I would be happy to help keep it up-to-date.
Here's an example of what I have in mind:
We set up a thread entitled "Master Index of Security Hole Related Threads".
The first message in it is as follows:
This thread is intended to act as a master thread to raise alerts on security holes in the CSLA framework that might let a hacker gain access to an application via a CSLA framework defect.
Please read this message with your full attention before posting to this thread.
People who are interested in being notified about any CSLA framework security issues should enable an email subscription to this thread. With a subscription to this thread, you can get notified of any security holes that
Here is what this thread is NOT:
- This is NOT a thread about security issues in general. It is about security issues that are in the CSLA framework. If the problem isn't caused by the framework, we don't want to hear about it in this thread.
- This is NOT a thread to ask questions about security. Period.
- This is NOT a thread to ask questions about how to set up CSLA security.
- This is NOT, repeat NOT a thread to discuss any security issue in any amount of detail. Each message is simply a pointer to another thread about CSLA security issues.
This IS a thread to simplify finding any and all threads that discuss security flaws in the CSLA framework that might let a hacker compromise your application. There are thousands of threads in this forum, this one just lets us organize critical security notifications into a single thread.
If you have found a security hole, you should:
- Post the details in a DIFFERENT thread. (Each security issue that is found should have its own thread with all the detail needed.)
- Copy the URL for that thread's web page.
- Create a new post in this master security thread
- Paste the URL for the detailed thread in the body your post.
- Add a few words describing the general nature of the security issue. Be brief, as the full thread for that issue should have all the details.
- Make sure you mentioned the CSLA version and language you found the problem in.
- That's it, you are done with your work in this thread - at least until you find a new security flaw.
Hope that helps to clarify my intent, and to satisfy you that it doesn't have to require any additional work
Thanks for clarifying the issue. This is actually a good idea. The person that maintains the security sticky could be the person that maintains the FAQ sticky. You would want to limit the number of people that could post to that thread. Otherwise you would end up with false alarms, reducing the overall effectiveness of the thread.
I agree that this is a good idea. However, I would rather that "official" information about the framework be under www.lhotka.net. It isn't that big a deal for me to maintain the list of issues - I just have none, and so I don't see the need to create a security or infrastructure issues page that lists nothing.
Looking back, there's no doubt that the original post was intended with more humor (albiet somewhat biting), and I should have responded more in kind perhaps.
Yep, I was trying to be funny. Not even my wife likes my jokes and she loves me, so I should know better.
In any case, returning to the original topic, I am quite comfortable creating a specific security/infrastructure issues article on www.lhotka.net, and I'll gladly do that at the point I become aware of such issues.
Way cool! That makes my customers and management happier. :)
Both that you will and that there's no reason to do so yet. :)
Some of these users, or potential users, require more than a community-based forum as a means of support. And they require more formalism around things like issue tracking (dev, security, infrastructure and more) than I am willing to provide pro bono.
I think I can speak on behalf of all CSLAers by saying THANK YOU for all the hours you continue to provide pro bono. Like you, most of us have good demanding jobs... and wife and/or kids too. All that takes a huge chunk of our time on a daily basis and _you_ go beyond the call of duty by supporting CSLA every time you have a minute to spare.
For this I thank you - and most of all I thank your wife and kids. I strongly believe that they play a big role as well, without their understanding and compassion you would be not able to commit as much time as you currently are to CSLA related stuff.
I fully understand, and frankly share, the reservations around any sort of commercialization. If I did go down that road, I would most certainly do so as an option, not a requirement. I strongly believe in direct contribution to the industry and community - that's a large part of why CSLA is what it is today - and I wouldn't give that up just to serve a competing set of market requirements.
... long live the king ...
Thank you :)
I for one would not like to see CSLA commercialized.
Great minds think alike :) I too would not like to see CSLA commercialized :)
Copyright (c) Marimer LLC