Haiku Security
Suggestions for security so Haiku doesn't end up as holed as Windows:
1. Make every user create a root account and a user account at startup.
2. Try to adhere to POSIX to prevent viruses from destroying the computer.
3. How about every program has its own "virtual" memory space(I dunno if this is possible) preventing the programs from interfering with other programs and the core OS files. I.E
YYYY:YYYY - [program 2] {end of virtual space}
XXXX:XXXX - [program 1(thinks it starts at an earlier number just before a binary interpereter for requesting things the program needs)] {end of virtual space for program 1}
0000:0000 - [OS and servers who may go to any address space]
Comments
Re: Haiku Security
Just note how few participants have appeared in this thread.
The developers don't frequent these forums, so if you want to get any kind of feedback from them, you then need to ask on the [haiku] or [haiku-development] mailing list.
http://www.freelists.org/list/haiku
http://www.freelists.org/list/haiku-development
Alternatively, someone subscribed to one of those mailing lists could post a message there with a link to here...
Re: Haiku Security
Just note how few participants have appeared in this thread.
The developers don't frequent these forums, so if you want to get any kind of feedback from them, you then need to ask on the [haiku] or [haiku-development] mailing list.
http://www.freelists.org/list/haiku
http://www.freelists.org/list/haiku-development
.. and therein lies another problem.
Appreciating that 'Freelists' may be attempting to ad value in exchange for advertising, I find their lists essetially useless, as my browser has to time-out on the multiple advert feeds - all of which it blocks (and would be ignred anyway..).
I don't blame 'Freelists'. I blame the Monkeys who fund advertising-land with budgets for 'click' programs despite their abysmally low returns. As with overly intrusive radio commercials of days gone by, many try to avoid buying products or services from those who are so inconsiderate.
It would be advantageous if 'proper' advert-free MLM hosting could be found for the Haiku project.
Re: Haiku Security
Just note how few participants have appeared in this thread.
The developers don't frequent these forums, so if you want to get any kind of feedback from them, you then need to ask on the [haiku] or [haiku-development] mailing list.
http://www.freelists.org/list/haiku
http://www.freelists.org/list/haiku-development
.. and therein lies another problem.
It would be advantageous if 'proper' advert-free MLM hosting could be found for the Haiku project.
False alarm on your part, as you don't need a browser to follow the mailing lists. Just signup to the lists that are of interest to you and all emails will be *properly* delivered to your mailbox *ad-free*.
Re: Haiku Security
That functionality is already available via other means, fortunately.
Anyway - it is not the main problem.
The issue is that it is a RPITA to search the archives so as to inobtrusively get up to date on what has already been covered on a given topic / area of concern AND be able to rapidly read what the search returns, THEN move on to the next entry or topic. At present, each navigation step triggers a fresh set of adverts, hence delay.
One can, of course, pull a local copy of the entire archives periodically, so it is nuisance category - nothing more.
Re: Haiku Security
Minix 3.XX, by contrast needs only around 4,000 lines of code to implement its kernel. Not my ciup of tea, but proves fat is optional, not essential. In an age when Linux has gone so far overboard that even Linus Torvalds calls it bloated, Haiku has a clear edge.
Minix is a microkernel operating system. Haiku's kernel, like Linux, is monolithic. So you're comparing apples with oranges.
Re: Haiku Security
Minix 3.XX, by contrast needs only around 4,000 lines of code to implement its kernel. Not my ciup of tea, but proves fat is optional, not essential. In an age when Linux has gone so far overboard that even Linus Torvalds calls it bloated, Haiku has a clear edge.
Minix is a microkernel operating system. Haiku's kernel, like Linux, is monolithic. So you're comparing apples with oranges.
More accurate, perhaps to say comparing 'fruit with fruit', as - architecture aside - the kernel is the kernel - not the entire meal.
'All of the above' need external binary code to do any human-usable work.
What Linux and Minix need to implement a GUI is near-as-dammit identical - the X-Windowing infrastructure for starters, then a WM, optionally a 'toolkit', then a 'desktop' on top of all that.
Not *everything* is built in, but Haiku needs far less of that sort of external, so - despite the 'monolithic' - it ends up smaller than many 'microkernel' or hybrid (OS X) architectures, even BEFORE thye haul in their support frameworks.
A closer cousin 'philosophically' might be Plan9 - though anyone other than a Plan9 developer might have issues with Acme/Rio as a UI (... as they are really more of an IDE...).
;-)
Others include Aos bottle, Syllable, Menuet, and some others - all of which, as does Haiku, take their own 'direct' and 'in house' cohesive route to implementing a GUI rather than using a gadzillion diverse libs and tools from all over the known universe. X-Windows is like the dancing bear. The marvel of the thing isn't that it dances well, but that it manages to dance at all.
Comparing on the basis of kernel size alone is deceptive. OS/2 Warp had a 'kernel' of around 85 Kilo-bytes, and could install and run in 4 Mega-bytes of RAM or less.
(IBM Thinkpad 360C).
BUT - though I don't recall it being called a 'microkernel', Warp still had to page 80+ Mega-bytes of various classes of drivers and such through that RAM and back out to VM swap before it was ready to communicate with a user. The HDD sounded like a Singer. The sewing machine, not the minicomputer. Worked much faster once it had 20 MB, though.
NB: Just got Haiku up, and reasonably happy, on a salvaged Thinkpad X20. PIII 600 MHz, 128 MB SDRAM. No joy, however on a Kapok 200 MHz pre-MMX PII, 72 MB FPM RAM, which did run Warp Server Advanced / 4.5 & eCS or Win NT4.
Re: Haiku Security
More accurate, perhaps to say comparing 'fruit with fruit', as - architecture aside - the kernel is the kernel - not the entire meal.
No, that's quite OK, I was accurate before, you were comparing apples with oranges.
Others include Aos bottle, Syllable, Menuet, and some others - all of which, as does Haiku, take their own 'direct' and 'in house' cohesive route to implementing a GUI rather than using a gadzillion diverse libs and tools from all over the known universe. X-Windows is like the dancing bear. The marvel of the thing isn't that it dances well, but that it manages to dance at all.
Ultimately, even if you somehow ignored the fact that X is much better designed than these toy window systems you mentioned, the bottom line is that X has the developers, the drivers and the applications. This particular dancing bear is principal ballerina.
Re: Haiku Security
Ultimately, even if you somehow ignored the fact that X is much better designed than these toy window systems you mentioned,
As I've only been dealing with X for twenty years, perhaps you'll forgive me if I've missed any evidence to that effect.
X cannot yet match Presentation Manager / Workplace shell on any factor save the count of available hardware video drivers - and did not match OS/2 video driver collection 'back in the day'.
I can make X *look* better than Apple's OS X, but I cannot make it *work* better - nor even as well, unless I throw it a 2:1 heavier hardware advantage than OS X needs. Which I do.
Neither X nor even OS X can inherently 'remember' the precise size and position of a specific application window I used a month ago, let alone that I had given that one window, or its app, or its desktop, but *no others* a different theme and customized menu layout and colors than other windows. System Object Model at work. Haiku cannot do that yet - but as open source, I can see where to hook it in if I want it badly enough, and in a simple and elegant manner (DB lookup vs hard-coded attributes).
the bottom line is that X has the developers, the drivers and the applications.
..and did precious little with those resources vs the 800lb MS Gorilla until X-org took over and made what turned out to be almost a fresh start. Kudos to them, but they are not the only game in town.
This particular dancing bear is principal ballerina.
And, as with classical ballet, unfortunately, holds a miniscule share of the entertainment business.
MS Windows still holds something above 80% of the desktop and laptop market. Mac OS X has displaced 'all others combined' as the next largest single holder, arguably taking as much share from Linux as it did from MS.
Both Windows and Mac OS X have a presence on handheld phone and PDA gadgets - which by unit count now outsell desktops and laptops. X-Windows is as scarce in handhelds as it is on the desktop or laptop.
iPhone and Windows Mobile aside, more and more of the rest are using one form or another of what you have called 'toy window systems'.
Crash a GUI app badly enough to destroy the desktop on any other windowing system except OS/2 or Haiku. Then see if it lets you rebuild the desktop without losing a byte on an in-process file download. One evoked from the GUI, not the CLI under it.
If Haiku is a 'toy', then it is a toy that is worthy of respect.
Re: Haiku Security
As I've only been dealing with X for twenty years, perhaps you'll forgive me if I've missed any evidence to that effect.
Twenty years is certainly a long time to not notice the fundamentals.
As to SOM, it's not even slightly relevant to X but "everything is an object" plus native binaries results in "everything is an exploit". (For any BeOS/ Haiku fans, SOM is basically OS/2's equivalent of COM)
Crash a GUI app badly enough to destroy the desktop on any other windowing system except OS/2 or Haiku. Then see if it lets you rebuild the desktop without losing a byte on an in-process file download. One evoked from the GUI, not the CLI under it.
If Haiku is a 'toy', then it is a toy that is worthy of respect.
It's to be expected that someone who doesn't understand X would not recognise the difference between a shell and a window system. What you're doing in Haiku is restarting the shell. X doesn't really consider the shell distinct from any other client, so of course you can restart it without disturbing other clients. When people choose to have a shell in X (not everyone does) it often takes the role of session manager and sometimes also window manager. The NETWM spec explains how a window manager can even take over from a previous window manager, reparenting all the top level windows, without unduly disturbing the clients that own those windows.
This thread was originally about security, and it seems that your rambling does offer an opportunity to look back in that direction. Securing a GUI is an interesting problem, not to be underestimated.
In BeOS and Haiku there has been no attempt to address this problem, a malicious or very badly written application can seize control not merely of the window system, but the entire OS. But if you look at something like Windows NT you see steady effort, at first securing access to the window system and protecting it from client applications, and later increasingly on protecting clients from each other. With something like GNOME on Linux you see a very different approach to the same problem, proxying privileged programs so that they're not directly connected to the window system and thereby shrinking their attack profile.
Re: Haiku Security
Mea Culpa - that handle 'NoHaikuForMe' was fair enough Troll-Warning that I should not have wasted the time. And not just an average troll, either...
Giving credit where it is due, I must say that the amount of contradiction you manage to squeeze into each single sentence is only exceeded by its misinformation content.
Dr. Pauli had your number first:
'That's not right. It's not even wrong'
Re: Haiku Security
The fundamental problem with linux is that a linux system is made out of so many moving parts from different groups, and put together by many different distros, that even if some of the parts are shiny, the entire system acts like crap. Until the linux community standardizes behind a single linux platform and one 'bugzilla', I just don't see how assorted security features here and there will amount to much.
Re: Haiku Security
devs don't check the forums because they don't want to deal with all the trolls
Re: Haiku Security
devs don't check the forums because they don't want to deal with all the trolls
Well I've been checking them pretty often lately, though I'm not exactly Axel or Ingo who are some of the real heavy lifters as far as the Haiku developers are concerned. But these forums could certainly be referenced when work begins in areas being discussed, like security in this case.
As for trolls, I don't think we have too many, and I don't think NoHaikuForMe is that bad of a troll. Assuming he is male: his nickname is certainly inflammatory but his knowledge of technology is pretty good, and a lot of the critiques of Haiku he has made are fairly accurate.
My main gripe is he assumes the flaws in Haiku are permanent, like many Haiku detractors, when more than likely they are not.
Re: Haiku Security
I like the idea of keeping Haiku single user - since it is supposed to be a fast, light desktop OS and computers are more personal now than ever before.
Maybe a single optional login password for preventing just anyone from using your computer.
When it comes to a networked environment, I think there could be a UNIX daemon or 3 which act as a haiku workgroup server and allow people to log into Haiku as a workstation user.
So: single user for local machine, OR one network-user at a time, communicating with a UNIX based server daemon that manages logons / file quotas, etc. That way, Haiku remains a speedy, nimble single user desktop OS, but has a future as a workstation on a network, too.
Re: Haiku Security
I like the idea of keeping Haiku single user - since it is supposed to be a fast, light desktop OS and computers are more personal now than ever before.
'keeping' an already multi-user OS (which Haiku is) single user would require a rewrite..
Maybe a single optional login password for preventing just anyone from using your computer.
More or less what is presently imposed by developer's fiat, moreover, with the default user selection scripted, and the ability to add more than the basic few or change passwords presently locked-down. No change to that needed to suit what you are asking for.
When it comes to a networked environment, I think there could be a UNIX daemon or 3 which act as a haiku workgroup server and allow people to log into Haiku as a workstation user.
Already provided for in the form of a separate identity for the sshd daemon.
I haven't looked at what the httpd daemon runs as (PoorBoy?), but 'top' will show one that there are already separate credentials of one kind or another for several 'team' daemon-runners.
So: single user for local machine, OR one network-user at a time, communicating with a UNIX based server daemon that manages logons / file quotas, etc. That way, Haiku remains a speedy, nimble single user desktop OS, but has a future as a workstation on a network, too.
Haiku already supports multiple simultaneous ssh network sessions with different user ID's from different remotes. Some fiddling required to set up the credentials, but it works well enough. No gain is taking it back out, either.
Generally, the physical count of kbd/video/mouse is going to limit most desktops to one user 'at a time' more pragmatically than the OS.
When it comes to 'remote', even CP/M on a Z80 could handle multiuser apps - and did so. They just had to be in the app, not the executive (Point Of Sale and BBS systems).
Anyway ...
Single vs multi user *design* does not necessarily equate to speed differential or even code weight. More of that depends on how MUCH work is to be done at a given point in time than 'for whom' it is to be performed. Likewise, how much of that work is 'bound' by other-than code execution time.
Think waiting on keystrokes, mouse movements, HDD access, or network I/O. Not much work, unless your OS were to be 100% 'polling' driven...
Re: Haiku Security
My main gripe is he assumes the flaws in Haiku are permanent, like many Haiku detractors, when more than likely they are not.
Nothing is permanent, and so the opposite problem is the tendency to look at where we are now, and take that as a fixed landscape against which Haiku will evolve. I've said before and will again that it's a Red Queen's race. Every other OS is evolving too. In Redmond, Microsoft's engineers will have been working on the successor to Windows 7 for months already.
When work on Haiku began in 2001 you could have looked at the landscape at that moment and concluded that most people only use a desktop PC, they have no more than 1GiB RAM, they have AC97 audio, and they use DSL or Cable at maybe 1 Mbit/s to read blog pages and write email. Haiku today is actually not that badly equipped for such a system. But it scarcely matters, because it isn't 2001 any more.
Some detractors of the original OpenBeOS concept felt that the BeOS R5 goal was short sighted because they wouldn't have an OS until say 2010 and by then all the assumptions would change. They were shot down by people who insisted that it wouldn't take nearly that long to bring OpenBeOS to fruition.
2010 is now two months away.
But this has swung wildly off topic.
Re: Haiku Security
Bill Hacker,
Thanks for your response - to clarify my post, I was referring to having one standard user login (as now) but possibly with a single, higher-privilege workgroup settings panel (password configured at Haiku install time) for enabling authentication against a network server, providing access to shared resources for Haiku clients, etc. Since Haiku defines itself as a Desktop operating system, any server OS capable of running the daemon(s) could take care of the authentication of Haiku clients - including file share / quota provisioning, ldap settings etc for any given network user. The network users could then be defined in accounts in the server side daemon config.
Re: Haiku Security
Bill Hacker,
Thanks for your response - to clarify my post, I was referring to having one standard user login (as now) but possibly with a single, higher-privilege workgroup settings panel (password configured at Haiku install time) for enabling authentication against a network server, providing access to shared resources for Haiku clients, etc. Since Haiku defines itself as a Desktop operating system, any server OS capable of running the daemon(s) could take care of the authentication of Haiku clients - including file share / quota provisioning, ldap settings etc for any given network user. The network users could then be defined in accounts in the server side daemon config.
Aside from not (presently) requiring any login at all - which a screensaver lock can ameliorate *slightly*, AFAICS the rest is already there.
One of the first things I did with Haiku was ssh in to a Unix server.
I haven't had the need to mount smbfs or NFS, but if they are not already there, it would be trivial to import both. AFS and the like - needing kerberos or Heimdahl may be in there somwhere too. No lazy way to test those.
As you say - login based on the *server* end - so 'already here'.
Haiku makes for really nice readability, has great terminal scrollback and handy 'zoom'.
But I hope it grows into a lot more than just a better terminal than an HP-200 LX.
.. which did have password security. And file encryption.
Re: Haiku Security
Nothing is permanent, and so the opposite problem is the tendency to look at where we are now, and take that as a fixed landscape against which Haiku will evolve. I've said before and will again that it's a Red Queen's race. Every other OS is evolving too. In Redmond, Microsoft's engineers will have been working on the successor to Windows 7 for months already.
If you are a developer - there's a chance that you've seen some projects that have gone wrong. Huge, bloated, badly designed - piece by piece, very hard to maintain. Adding new features is a pain - you have to make changes all over the codebase, often using hacks, accidentaly breaking a lot of seemingly unrelated stuff in the process. Just finding what to change in order to add a simple feature can often be a daunting task. And it keeps getting worse.
Windows and Linux have all the characteristics of such projects.
There's a reason it took Microsoft so many years and manpower to get from WindowsXP to Vista (5+ years, hundreds, if not thousands of developers and for what?). There's a reason why it took the Linux desktop so many years to catch-up with Windows. And there's a reason why Haiku has managed to reach it's current state with a tiny fraction of the developers and resources that Windows and Linux needed. You can count the major Haiku contributors on the fingers of one hand. The team that was responsible for the ill-fated Vista shutdown dialog( http://tinyurl.com/y2g6ye ) was probably bigger than that.
The Haiku code is compact, efficient, easy to understand and above all - well designed as a complete, coherent and interoperable system that can be easily extended.
Re: Haiku Security
And there's a reason why Haiku has managed to reach it's current state with a tiny fraction of the developers and resources that Windows and Linux needed.
Sure, those developers did only a tiny fraction of the work. Major parts of the system (not to mention the general design) already existed and were simply imported wholesale. So while Red Hat (a major Linux distributor) has employees working on the compiler and toolchain, Haiku is content to merely re-use them with a brief credit. The FreeBSD driver developers worked from hardware documentation to create and test drivers. Haiku pastes them into a compatibility layer. Whether it is JPEG decoding, writing a line of text on the screen, connecting to a remote server, Haiku was able to have a "tiny fraction of the developers" by only doing a tiny fraction of the work.
Throughout Haiku, at least when someone remembered to leave them in, there are copyright lines or credits for thousands of other individuals and organisations which developed the software that is "Haiku".
Another way to reduce developer numbers is to cut a lot of corners. For example you could take a critical feature of the OS and just not bother implementing it. We'll see an example below.
The Haiku code is compact, efficient, easy to understand and above all - well designed as a complete, coherent and interoperable system that can be easily extended.
Security is job number one. Security mitigations are entirely absent from this "complete, coherent and interoperable" system despite being the topic of this thread. Haiku R1 alpha shipped with an unmaintained web browser. Probably some readers of this thread laugh at Windows users who run some obsolete and unpatched version of Internet Explorer - but Haiku insists that you take the same risk.
But really you can't have intended the word "complete" there as a serious point. Haiku lacks support for most of the peripherals people own, not to mention numerous little features everyone assumes a modern OS will have - even its own developers recognise that this isn't feature complete.
Re: Haiku Security
Haiku was able to have a "tiny fraction of the developers" by only doing a tiny fraction of the work.
This is definitely true, but you act as if our project is the only one to use other people's code. I'm pretty sure Linux, Mac OS X, Windows and pretty much every other OS in existence are built with some amount of "other people's code." Either way if those people did not want their code used it would not have been released open source. If we had written every bit of Haiku ourselves we wouldn't be done until 2020, if that, and you already point out how long it has taken us to get this far, even using so much other code.
Also I'm pretty sure all the Haiku developers have made a very serious effort to recognize and preserve all copyrights and licenses of the code we make use of. If you feel there is some area where this was not done properly, please speak up.
But really you can't have intended the word "complete" there as a serious point. Haiku lacks support for most of the peripherals people own, not to mention numerous little features everyone assumes a modern OS will have - even its own developers recognise that this isn't feature complete.
Indeed, that is why we released R1 ALPHA 1, not R1, or even R1 Beta. Trying to run Haiku on some various pieces of native hardware lately has been giving me quite a bit of trouble. It is frustrating, but it is development code. Linux didn't start off supporting every piece of hardware. Even Microsoft with Vista (and probably again with Win7) has had trouble supporting some pieces of hardware and older software.
I do appreciate some of your insights NoHaikuForMe, but I really do have to wonder why you waste your time here. We Haiku developers aren't just going to just throw up our hands and give up on Haiku because it isn't immediately as great as the other major operating systems (not that they are that great...let's be honest now, they all have flaws.) And clearly you don't find it to be a worthwhile project. It seems like we should just agree to disagree and part ways.
Lastly on the topic of this thread, Haiku may not be as secure as it could be. But besides the fact that it is still in development, I'm pretty sure it would take a VERY, VERY, VERY long time for Haiku to come even close to causing as much harm as Microsoft has with their crappy, insecure software. The day that there is a botnet of Haiku machines even close to the levels of Windows machines, I'll concede you have a point. But I just don't see that happening.
Now that isn't an excuse to be sloppy, but I just don't think the risk of real user harm is there. Microsoft captured that "market" years ago.
Re: Haiku Security
This is definitely true, but you act as if our project is the only one to use other people's code.
I don't think so, geleto's claim rests on the false idea that these developers have done so much with less people, and I simply showed where that argument falls apart. It's specific to Haiku only because geleto wrote about Haiku and this is a Haiku forum.
I do appreciate some of your insights NoHaikuForMe, but I really do have to wonder why you waste your time here.
I'd say you've answered your own question. In most projects this voice would be redundant but Haiku inherits from BeOS fandom an almost entirely uncritical approach. I suspect that BeOS in turn inherited it from Apple and the reality distortion field. But wherever it came from it's unhealthy.
Lastly on the topic of this thread, Haiku may not be as secure as it could be. But besides the fact that it is still in development, I'm pretty sure it would take a VERY, VERY, VERY long time for Haiku to come even close to causing as much harm as Microsoft has with their crappy, insecure software. The day that there is a botnet of Haiku machines even close to the levels of Windows machines, I'll concede you have a point. But I just don't see that happening.
Haiku won't achieve the popularity of Windows, and so according to you that means security isn't important?
I just don't think the risk of real user harm is there
What's not to get? Haiku R1 alpha ships an old unsupported browser that has known security holes. People running that browser are at hugely increased risk to have their personal data copied. In my day job I see the kind of data that's collected this way (not the actual data of course, unless something goes wrong, since it would be unethical to look at it unnecessarily) and it means people's credit card number and CVV, their name and address, email addresses and passwords. Everything people type into a web browser is being collected by organised criminals.
The message from you, and apparently Haiku, seems to be "Who cares? And by the way Microsoft suck. La la la".
In terms of absolute numbers of people, the figures are tiny. Maybe a few thousand people try Haiku and use it to buy something on the web. Maybe one of those people is unlucky and gets their identity "stolen". Compared to the millions of people still running Internet Explorer 6 with no updates, it's not significant, right? But in terms of Haiku it's huge. And while Microsoft is doing whatever they can to get their users to update, Haiku is complacent.
Re: Haiku Security
I don't think so, geleto's claim rests on the false idea that these developers have done so much with less people, and I simply showed where that argument falls apart. It's specific to Haiku only because geleto wrote about Haiku and this is a Haiku forum.
So you are showing a more critical eye toward Haiku for no reason except that this is a Haiku forum? OK. I hope in the Linux or Gnome forums you tell them how much they suck because they still haven't gotten the Linux desktop right even with thousands of developers and tons of corporate cash.
No matter what you think in your distorted world view the Haiku developers have achieved a lot with a little.
I'd say you've answered your own question. In most projects this voice would be redundant but Haiku inherits from BeOS fandom an almost entirely uncritical approach. I suspect that BeOS in turn inherited it from Apple and the reality distortion field. But wherever it came from it's unhealthy.
That's just bullshit. Obviously you are hiding here under your user name so I have no idea who you really are, but over the years on the mailing list and in various commit messages the various problems from BeOS have been discussed and sometimes fixed in Haiku. Examples include the slow and crappy userland network stack, the lack of a GUI layout system, the lack of tooltips, the slowness of the syscalls, the slow compiling of large programs, and various problems with BFS.
We are recreating BeOS so there is obviously some respect for BeOS and most of what it represents, but the developers aren't a bunch of fanboys who see no flaws. Get realistic. Just because a few users here show some typical fanboyism does not mean the whole project runs under that attitude.
Haiku won't achieve the popularity of Windows, and so according to you that means security isn't important?
Don't twist my words, security is important but regardless of popularity Haiku will never impact the world in the horrible way Windows has. I think our developers care much more about security than most Microsoft programmers, based on their respective track records. Plus Haiku is an ALPHA OS, whereas Windows is on its seventh release (really more if you count properly.)
What's not to get? Haiku R1 alpha ships an old unsupported browser that has known security holes. People running that browser are at hugely increased risk to have their personal data copied.
SNIP
And while Microsoft is doing whatever they can to get their users to update, Haiku is complacent.
So all the efforts that I and Maxime Simon have been doing to port WebKit and write a new browser for Haiku are seen by you as complacency? Whatever dude, it seems that nothing Haiku does is enough for Mr/Ms NoHaikuForMe, so I won't waste my time anymore. Haiku is an alpha OS still heavily in development and you act like it's running the space shuttle or something.
I'd like to see you rip apart all the other operating systems with a similar approach. I don't think any OS would stand up to your ridiculous standards.
Either way others reading this can see your over the top negative bias toward Haiku and you'll be written off as the troll you are.
Re: Haiku Security
So you are showing a more critical eye toward Haiku for no reason except that this is a Haiku forum? OK. I hope in the Linux or Gnome forums you tell them how much they suck because they still haven't gotten the Linux desktop right even with thousands of developers and tons of corporate cash.
Indeed critical debate is much more healthy in the communities you've mentioned. On the LKML for example you have someone like Brad Spengler. Thus an outsider voice would be redundant. The response to "Linux sucks" is not "go away troll" but "show us where and we'll fix it". The x264 author recently wrote about his experience as a non-kernel developer of showing a problem to the LKML and getting it fixed.
That's just bullshit. Obviously you are hiding here under your user name so I have no idea who you really are, but over the years on the mailing list and in various commit messages the various problems from BeOS have been discussed and sometimes fixed in Haiku. Examples include the slow and crappy userland network stack, the lack of a GUI layout system, the lack of tooltips, the slowness of the syscalls, the slow compiling of large programs, and various problems with BFS.
The network stack change was initiated by Be, not Haiku. Similarly Be had been promising a real 1990s-type layout API for some time. We're talking about an eight year period, and the big changes you can come up with from Haiku are one thing Be already did, and another they already planned to do.
Don't twist my words, security is important but regardless of popularity Haiku will never impact the world in the horrible way Windows has. I think our developers care much more about security than most Microsoft programmers, based on their respective track records. Plus Haiku is an ALPHA OS, whereas Windows is on its seventh release (really more if you count properly.)
Maybe Haiku developers care more than anyone else in human history about security, but it seems that they don't do much about it. Meanwhile Microsoft's programmers who you allege care much less, have been steadily introducing better security over the same eight year period in which you remind us that Haiku has yet to release anything but an alpha.
So all the efforts that I and Maxime Simon have been doing to port WebKit and write a new browser for Haiku are seen by you as complacency?
Haiku didn't ship your WebKit based browser, it shipped an unmaintained build of Bon Echo. Where's the warning that this is just a placeholder for a real browser and shouldn't be used, as users would expect, to check their bank balance, buy a book on Amazon etc. ?
Either way others reading this can see your over the top negative bias toward Haiku and you'll be written off as the troll you are.
That would make you the second person in this thread to announce that I'm a troll and no-one should listen to me. If it's true that negative comments about Haiku are automatically inflammatory to Haiku users then I think you've tacitly accepted my earlier point.
Re: Haiku Security
Indeed critical debate is much more healthy in the communities you've mentioned. On the LKML for example you have someone like Brad Spengler. Thus an outsider voice would be redundant. The response to "Linux sucks" is not "go away troll" but "show us where and we'll fix it". The x264 author recently wrote about his experience as a non-kernel developer of showing a problem to the LKML and getting it fixed.
I'm guessing that in these cases, constructive criticism is often utilized. Generally when providing constructive criticism, one tries to provide solutions along with the criticism (and no, "stop using this software because it sucks" is not a constructive solution). In a FOSS project, it's generally hard to make everyone happy when there is more work to do than there are volunteers to do it.
In this case, I think that you're assuming that your criticisms are constructive for the project, but to the rest of us it seems your criticisms are nothing more than attempts to frustrate the project contributors and supporters - seemingly insinuating that they are intentionally doing things wrong.
I also find it strange that you concentrate all of your criticism for Haiku here on these forums rather than on the mailing list where most of the project contributors discuss aspects of Haiku that need to be modified or changed.
In any case, I have learned over the last few years that many of your criticisms are certainly warranted, but often poorly expressed in a way that can encourage change - which is why you are often labeled as "troll" I think.
Anyhow, sorry to take this so offtopic.
Re: Haiku Security
Good points umccullough.
If NoHaikuForMe seriously wanted to provide constructive criticism and be taken seriously, then:
Basically all signs point to troll: "In Internet slang, a troll is someone who posts controversial, inflammatory, irrelevant, or off-topic messages in an online community, such as an online discussion forum, chat room or blog, with the primary intent of provoking other users into an emotional response or of otherwise disrupting normal on-topic discussion."
Also if we really wanted to shut up NoHaikuForMe and stop all debate and negative criticism about Haiku we would have banned that user name long ago. But I'm sure NoHaikuForMe has a quip to explain that away too.
So why am I wasting my time here? I really would like to see NoHaikuForMe change their approach and post his or her valid complaints about Haiku on the mailing list, where more eyes can see them and maybe some of the truly broken things can be fixed. Until I see that happen I'll always have that bad feeling of a troll when I read his or her posts here.
Re: Haiku Security
I'm guessing that in these cases, constructive criticism is often utilized. Generally when providing constructive criticism, one tries to provide solutions along with the criticism (and no, "stop using this software because it sucks" is not a constructive solution). In a FOSS project, it's generally hard to make everyone happy when there is more work to do than there are volunteers to do it.
It's pretty hard to offer something constructive to say about Haiku's security. Haiku does not have security in any meaningful sense. You have perhaps heard the story of The Emperor's New Clothes ? Every post in this thread in which Haiku's security is non-specifically praised is like a courtier exclaiming how wonderful the emperor's new suit is in the story.
If for some reason this is opaque to Haiku's developers, I'd say that's one more reason to give it a wide berth, but let's briefly spell some of it out for one tiny corner of the problem, security updates.
• Reporting. You need a reliable means to receive reports of security problems, with one or more trusted individuals responsible for receiving the information, keeping it confidential and ensuring its acted on quickly. Without such a mechanism it's only to be expected that all disclosures will be public, "zero day".
• Fixes. You need to react to reported security problems from security channels, your own security contacts and in public (e.g. via Bugtraq) by identifying a correct fix, and integrating that into the software as quickly as possible.
• Distribution. You need a mechanism to distribute fixes. It should be as easy as possible for users to get fixes, while being as hard as possible for black hats to delay, undo or subvert the update process.
• Alerting. You need a reliable method to let users know they're vulnerable. Today it would be acceptable for this means to be primarily via the Internet. Again it should be hard for black hats to block this process.
Re: Haiku Security
Its just a thought, but why don't you put your wasted breath to work by working on security then writing such long-winded comments. Its a waste of time. If you really want to troll go on 4chan and whine. I do it when I'm frustrated. Your comments suck and you're bringing nothing to the table. Also, guys, stop talking to this guy, its just pissing everyone off. NoHaikuForMe, please stop talking.
Re: Haiku Security
Here is the genuineness verification design: I, as the applicaiton designer, design it in the way that will be difficult to spoof. To do so, I add attributes to files that surely exists in the system; the attribute's data is a (big) numeric value calculated from app's version, buyer's ID, chosen system properties etc, - a number which is unique enough to identify the customer. The attribute's name is obscured to make it more difficult to find which attribute controls this data; in additional, the application adds some random numbers in attributes to other files, so the hacker won't know which attribute is the real check. (Surely enough, there may be quite a few "real" numbers, all calculated in different ways, as well as quite a few of the "barren", "vain" ones, - it's not a good idea to put all eggs in one backet). Upon startup of the application, a "real" attribute value is read (randomly chosen from the pool of "real" attributes), and corresponding value is recalculated from the available system data, they are compared. Simultaneously, the value read from the attribute is sent over the Network to a central server, which contains all "real" numbers received from the client upon installation (no user data, of course; the data that composes the numbers is not reversely calculable). Any of these checks may be performed several times upon need. After these comparisons, the program decides if it's a genuine copy or a pirately distributed one, and acts accordingly. E.g., triggers full HDD erase :-P. Just kidding. Honestly, I see only one way to break this system: edit the binary application's file and replace the "jump_if_zero" instruction representing the main decision "genuine / hacked" with "no_op" (or "unconditional jump") instruction. Surely enough, this may be checked also, e.g. by hashing the contents of the application's file, but this is well beyong the scope of this discussion.
The design of your verification application seems extraordinarily invasive. Personally, I don't want any kind of application (trusted or not) looking at my files and sending data regarding them to any external server unless I explicitly tell it to. (Like usage metrics and such)
While I agree that copy protection is important for companies who make their living selling some piece of software. Said company doesn't have the right to write random garbage (via your program) all over my files in an attempt to hide the authenticity key they're using to make sure I don't pirate the software I bought. Anything they do to protect their software from piracy has to happen within the application, in which case they can take any and all precautionary measures as they see fit.
The difference here is between "User is god" system's architecture to "User is slave". The first one is Linux way, where any process running with root's priorities can do anything, including modification of system files. The second way is Windows, where even the Administrator can't touch some places in the system. However, surprisingly Linux is much more secure then Windows. Doesn't it mean that Linux' way of action is better?
In all cases, and especially with computers, personal privacy comes before the interests of any company. Because the "User is God" and you don't write random garbage on all of God's files to protect the interests of corporations.