Because a project patching bugs daily (that only a hand full of users are actually applying) is rated as more secure then a well tested and stable project that is not finding bugs and releasing patches...
The Star Trek economy only works with no scarcity. And while there is a surplus of labor, there is NOT a surplus or resources or energy. And energy is the big one here, as everyone keeps telling us. Sure there is solar, and wind, but they run up against some rather hard resource limitations. (Especially plastics which depend on oil...)
I was just noticing the other day that a number of emacs lisp packages I use on a regular basis hadn't had any development work in 5-10 years.
If it works, why change it? The SmallWall project was immune to all of the SSL bugs in the last year because we use an old version that does not have these new and buggy features... Of course, this rating system would ding us for that...:)
I agree that it is a very good idea. But the execution leaves a lot to be desired.
An attacker might e.g. get commit rights to several low-activity projects, insert malicious code, and wait for people to download updates and become easily exploitable.
Their rating system actually encourages this. If you have tight controls on commits, like perhaps 1 or two people who review code and actually make the commits, you are "at risk." So go ahead and give that NSA guy commit access...
What they did is getting a basic overview of which projects need most attention.
No, they have a lit of project that rate in their arbitrary definition of "risk." Have a nice and stable project that is not on the feature of the week train? High risk, because there are not enough updates. How about a hidden development svn, with a public mirror that makes all contributions look like they come from one person? Oh, that is very high risk... By their metrics, "Hello World" is the riskiest program on the planet.
Delete stuff from the Internet... Hmmm... Sounds like a wonderful idea. How?
Actually it is a terrible idea, even if it could work, because looking at how the code progressed is how you learn. Not to mention that I can patch and old version to fix the vulnerability, but not have to move to the new and incompatible version.
It got to the point we put in very large bold characters in our release notes... we work on this version of Java, if you get clever and introduce your own version of Java, we won't talk to you until you confirm the bug in the version we support.
Which is how we ended up with the management nightmare of different hardware requiring different and incompatible versions of JAVA for the "Web Client" to manage it. So, one workstation to manage Cisco. One workstation to manage EMC. One for HP. One for the phone system and a different one for the voicemail... And hope to God no one clicks "Update" on the popup before reading it!
I've been told in tens of thousands of Slashdot comments(all modded up) that Open Source software is more secure. No wonder this site is dying.
It is not more secure due to magic. It is more secure due to patches and updates. If you do not apply them, you do not get that security. It is like having locks and a car alarm, but leaving your keys on the dash.
None of these are as small as *WRT distros and they still to this day only run on x86 and x64, but you get OpenBSD's packet filter (claimed by most to be superior to Linux's) bolted onto FreeBSD (for better hardware support?) and a BSD license if that matters to you.
Also, good luck getting a *wrt to give gigabit sustained transfers.:) SmallWall and m0n0wall on modern hardware can give 900meg sustained transfers all day, and can do some hefty encryption on the side if needed for IPSEC.
As to the projects that owe allegiance to m0n0wal, and the people that learned there... This is a quick peek at some of those people... http://www.smallwall.org/histo...
I actually had missed the news that the M0n0wall project was over. But even if it is, one of its derivatives is pFsense. What is pFsense missing that makes people want to fork M0n0wall?
It is not what it is missing, but what it has... m0n0wall was (and SmallWall is) smaller, and leaner. Less services means less attack vectors. It is also easier to configure correctly for novices. But the big thing is that some people are fundamentally against "kitchen sync" appliances where everything is on one box. Sometimes, separation of jobs is a very good thing.
I am not saying pfSense is bad. It is a good system, and Chris is a good guy. But I prefer solutions where the components do one thing, and do it well.
One thing to compare is the hardware requirements for running OPNsense versus m0n0wall or SmallWall. OPNsense requires essentially a fairly modern computer, whereas I run m0n0wall currently on a 15+ year old 600Mhz P3 (which spends about 90% of its time twiddling its thumbs). I'm guessing that almost no one who was running m0n0wall is able to install OPNsense on the same hardware, as the requirements for OPNsense would be extreme overkill for m0n0wall.
That does bring up an interesting question about the MIXTPC boxes. My understanding is that m0n0wall will only use one core in a multi-core system, a few tens of MB of disk space, only and certainly won't use more than 128MB of ram. The MIXTPC boxes will still work, but even the cheapest one at $250 is way more than you'll need.
You are correct in that any modern box is overkill. But there is really no new hardware that is any cheaper... And SmallWall can use more than 128 meg of ram, as some tables live in ram and can grow large in heavy use environments. But I have seen very few boxes use more the 512 meg.
As to multi-core, that is on the roadmap. It will be easier to support when the base is moved to FreeBSD 10.1 in the future.
as announced earlier, the m0n0wall mailing list and forum are now frozen. This is the final message, and I would like to take the opportunity to thank all those who have sent me emails with kind words and expressions of gratitude. They were too numerous for me to reply to individually, but they were all very much appreciated!
There have been some questions on what the way forward is for current m0n0wall users. If you are happy with the current feature set of m0n0wall and just need a security patch, bug fix, hardware compatibility update or minor improvement now and then, there are two nascent projects started by former m0n0wall developers/users that may have something for you: SmallWall and t1n1wall.
For a more feature-rich alternative that is still based on FreeBSD and has the same roots, both pfSense and OPNsense (which is a fork of the former) are excellent choices. They have higher hardware requirements than m0n0wall, but on the other hand, a lot of new embedded hardware has recently become available, with 2 GB or more of memory and 1 GHz or faster CPUs, at a similar price as earlier platforms. It makes sense (pun intended) to use these additional resources - something that m0n0wall hasn't been particularly good at in recent times. Just keep that in mind for your next hardware upgrade.
Farewell, fellow m0n0wall enthusiasts.
- Manuel
28 February 2015
Both SmallWall and t1n1wall.com are lean, and purpose built firewalls that do only one thing. They are not kitchen sink applications. They are meant to plug into web filters, not to be web filters.
pfSense, and OPNsense are extensible firewalls with a plug in architecture. While expandable, they are more complex and heavier weight. A good example is to compare traffic shaping between them... M0n0wall, SmallWall and t1n1wall will win that contest hands down!
They have not realized that the encryption they use is purchased on the open market... Onec they realize their own secrets are at risk, this shit will change fast!
Not backdoored, just vulnerable. That happens as science progresses. That 1024 bit key that was secure a few years ago, is not secure today. What is good enough moves each year, but people and companies do not.
Slashdot Mirror
Because a project patching bugs daily (that only a hand full of users are actually applying) is rated as more secure then a well tested and stable project that is not finding bugs and releasing patches...
The Star Trek economy only works with no scarcity. And while there is a surplus of labor, there is NOT a surplus or resources or energy. And energy is the big one here, as everyone keeps telling us. Sure there is solar, and wind, but they run up against some rather hard resource limitations. (Especially plastics which depend on oil...)
"I know you have this tool that works perfectly well for what you are doing, but you should remove it now, and use my new and bloated tool instead..."
Seems to be the current "best practice" and I hate it.
NTP is actually quite solid. But pool.ntp.org could use some love. It can't work without servers...
I was just noticing the other day that a number of emacs lisp packages I use on a regular basis hadn't had any development work in 5-10 years.
If it works, why change it? The SmallWall project was immune to all of the SSL bugs in the last year because we use an old version that does not have these new and buggy features... Of course, this rating system would ding us for that... :)
An attacker might e.g. get commit rights to several low-activity projects, insert malicious code, and wait for people to download updates and become easily exploitable.
Their rating system actually encourages this. If you have tight controls on commits, like perhaps 1 or two people who review code and actually make the commits, you are "at risk." So go ahead and give that NSA guy commit access...
Why companies are throwing support behind it rather than LibreSSL is beyond me.
Because it is what they use. Porting has a non-zero cost as well.
What they did is getting a basic overview of which projects need most attention.
No, they have a lit of project that rate in their arbitrary definition of "risk." Have a nice and stable project that is not on the feature of the week train? High risk, because there are not enough updates. How about a hidden development svn, with a public mirror that makes all contributions look like they come from one person? Oh, that is very high risk... By their metrics, "Hello World" is the riskiest program on the planet.
Did you read how the derived it? Patches mean less risk (for some bizarre reason) and systemd patches hourly!
What would you call Linux with a toolbar? Unity?
At some point, someone has to make the decision. It is simply too important to be left to a comity. Design by comity leads to a real mess...
I can name 20 (or 50, or maybe 100) people with far more economic influence in the last 20 years than this douchebag.
Yet somehow you could not type one name here...
He is open source. He can not die. He will just fork. :)
Delete stuff from the Internet... Hmmm... Sounds like a wonderful idea. How?
Actually it is a terrible idea, even if it could work, because looking at how the code progressed is how you learn. Not to mention that I can patch and old version to fix the vulnerability, but not have to move to the new and incompatible version.
It got to the point we put in very large bold characters in our release notes ... we work on this version of Java, if you get clever and introduce your own version of Java, we won't talk to you until you confirm the bug in the version we support.
Which is how we ended up with the management nightmare of different hardware requiring different and incompatible versions of JAVA for the "Web Client" to manage it. So, one workstation to manage Cisco. One workstation to manage EMC. One for HP. One for the phone system and a different one for the voicemail... And hope to God no one clicks "Update" on the popup before reading it!
I've been told in tens of thousands of Slashdot comments(all modded up) that Open Source software is more secure. No wonder this site is dying.
It is not more secure due to magic. It is more secure due to patches and updates. If you do not apply them, you do not get that security. It is like having locks and a car alarm, but leaving your keys on the dash.
None of these are as small as *WRT distros and they still to this day only run on x86 and x64, but you get OpenBSD's packet filter (claimed by most to be superior to Linux's) bolted onto FreeBSD (for better hardware support?) and a BSD license if that matters to you.
Also, good luck getting a *wrt to give gigabit sustained transfers. :) SmallWall and m0n0wall on modern hardware can give 900meg sustained transfers all day, and can do some hefty encryption on the side if needed for IPSEC.
As to the projects that owe allegiance to m0n0wal, and the people that learned there... This is a quick peek at some of those people... http://www.smallwall.org/histo...
I actually had missed the news that the M0n0wall project was over. But even if it is, one of its derivatives is pFsense. What is pFsense missing that makes people want to fork M0n0wall?
It is not what it is missing, but what it has... m0n0wall was (and SmallWall is) smaller, and leaner. Less services means less attack vectors. It is also easier to configure correctly for novices. But the big thing is that some people are fundamentally against "kitchen sync" appliances where everything is on one box. Sometimes, separation of jobs is a very good thing.
I am not saying pfSense is bad. It is a good system, and Chris is a good guy. But I prefer solutions where the components do one thing, and do it well.
One thing to compare is the hardware requirements for running OPNsense versus m0n0wall or SmallWall. OPNsense requires essentially a fairly modern computer, whereas I run m0n0wall currently on a 15+ year old 600Mhz P3 (which spends about 90% of its time twiddling its thumbs). I'm guessing that almost no one who was running m0n0wall is able to install OPNsense on the same hardware, as the requirements for OPNsense would be extreme overkill for m0n0wall.
That does bring up an interesting question about the MIXTPC boxes. My understanding is that m0n0wall will only use one core in a multi-core system, a few tens of MB of disk space, only and certainly won't use more than 128MB of ram. The MIXTPC boxes will still work, but even the cheapest one at $250 is way more than you'll need.
You are correct in that any modern box is overkill. But there is really no new hardware that is any cheaper... And SmallWall can use more than 128 meg of ram, as some tables live in ram and can grow large in heavy use environments. But I have seen very few boxes use more the 512 meg.
As to multi-core, that is on the roadmap. It will be easier to support when the base is moved to FreeBSD 10.1 in the future.
"I think in general we haven't done enough to reach out and show young women that it's cool to do it [tech] and how much fun it can be,"
Actually, I think that "reaching out" is exactly why so many woman have run screaming from the industry.
Hello,
as announced earlier, the m0n0wall mailing list and forum are now frozen. This is the final message, and I would like to take the opportunity to thank all those who have sent me emails with kind words and expressions of gratitude. They were too numerous for me to reply to individually, but they were all very much appreciated!
There have been some questions on what the way forward is for current m0n0wall users. If you are happy with the current feature set of m0n0wall and just need a security patch, bug fix, hardware compatibility update or minor improvement now and then, there are two nascent projects started by former m0n0wall developers/users that may have something for you: SmallWall and t1n1wall.
For a more feature-rich alternative that is still based on FreeBSD and has the same roots, both pfSense and OPNsense (which is a fork of the former) are excellent choices. They have higher hardware requirements than m0n0wall, but on the other hand, a lot of new embedded hardware has recently become available, with 2 GB or more of memory and 1 GHz or faster CPUs, at a similar price as earlier platforms. It makes sense (pun intended) to use these additional resources - something that m0n0wall hasn't been particularly good at in recent times. Just keep that in mind for your next hardware upgrade.
Farewell, fellow m0n0wall enthusiasts.
- Manuel
28 February 2015
Both SmallWall and t1n1wall.com are lean, and purpose built firewalls that do only one thing. They are not kitchen sink applications. They are meant to plug into web filters, not to be web filters.
pfSense, and OPNsense are extensible firewalls with a plug in architecture. While expandable, they are more complex and heavier weight. A good example is to compare traffic shaping between them... M0n0wall, SmallWall and t1n1wall will win that contest hands down!
Thanks for the help! It works now.
It was up this morning... I wonder if it might be slashdotted? Try docs.m0n0.ch for another mirror.
They have not realized that the encryption they use is purchased on the open market... Onec they realize their own secrets are at risk, this shit will change fast!
Not backdoored, just vulnerable. That happens as science progresses. That 1024 bit key that was secure a few years ago, is not secure today. What is good enough moves each year, but people and companies do not.