Where is Haiku R1? | Haiku Project


#101

What did you mean by “Haiku without virtual packages”?


#102

Packages are extracted and installed in real file system. Than packages in “packages” directory removed, removed aditional links to the files in the packages. “non-packaged” removed. In that way Haiku not using virtual file system for installed packages (that are “virtual packages").


#103

“cache memory” is used to store data from file systems in RAM, and limit I/O access to disks. This memory can be reclaimed by any app which needs the memory for other purposes.

We implement two levels of caching:

  • A “block cache”, which stores sectors as read from block devices (ie. disks)
  • A “file cache”, which stores data from files.

The file cache is particularly relevant here, because it will be used to store file content. Because of the package filesystem, it will store them uncompressed. As a result, the decompression of package files is done much less often because the uncompressed data can be stored in RAM. And since an Haiku install is usually quite small (mine is about 3GB), and RAM on modern machines is large, it means that after some time, all the data from packages is loaded in RAM (we can do this because Haiku does not use much RAM for other things). This compensates for the extra work that would occur if we were always reading data from disk and decompressing it over and over again.


#104

Signing the package files and having the package filesystem check the signatures at boot is on the long-term roadmap. However, there is already enough pushback from users complaining that the package management get in their way for now, so this will have to wait a little. Maybe until users start to be attacked by such viruses :frowning:


#105

“Who” signs these packages?

If it’s you (haiku) alone then yes, it can be protected but then users are unable to “side-load” their system, which is a necessity to get a system moving forward.

If it’s developers only then every virus can replace a package file with a malicious one signed by some random key and getting the file up and running in the system.

Put simple you can’t prevent malicious packages to be injected while at the same time allow users to side-load their system. If side-loading is forbidden them I’m quicker gone than you can think.


#106

How is that cashed data is protected from unauthorised access from side way app?


#107

The MMU (memory management unit) protects memory between applications, like in any other recent OS design including BeOS. So an application trying to access memory it is not allowed to will just trigger a segmentation fault.


#108

The goal is certainly not to prevent installing 3rd-party packages. The whole system was designed with this in mind: allowing install of locally downloaded (or built) packages, and allowing 3rd-party repositories. These features are not going away.

I have not put a lot of thought in how the key verification would work. Maybe something like GPG, where you could individually trust developer keys. Of course this once again only moves the problem of viruses, as a virus could add its own key and then patch any key management software to make it invisible or something. We’ll have to think about this carefully and I’m not a cryptography/security expert. Also it is probably not worth doing as long as we are running everything as the root user anyway.


#109

This means, that system erases data in memory before providing it to another app or not?


#110

You can try for yourself, make an app that calls malloc() and see if you can spot anything in the returned RAM?


#111

Granted, if you are root (or baron as it has been named in BeOS :smiley: ) then anything on the system can be changed. Without user management you can not protect the system in any usable way.

The only solution that works (from a professionals point of view) is to have an own user with write access to the package directory. for changing packages the user (or an application) needs to wheel into this user to make a change to the packages directory. this way a virus can not gain access to the files unless it successfully tricked the user into wheeling into the required user, which should involve a big fat warning dialog asking to enter the root password to grant the request.


#112

Hehehe! I see all this arguing over security against viruses and malware corrupting packages and causing havok, and I keep saying… if only they listened to me…

It could be so easily stopped. But it must be stopped from the ground up. Gotta change all the rules of how the OS interacts with the users and programs. Too late for Haiku anyways, in its current incarnation. You might be able to create a workable solution, but never a truly secure one.

But never mind me… I don’t know anything. Go about yer fussing and fidgeting. Have fun. :smiley:


#113

I don’t know anything.

:+1:


#114

Thanks for this info. The ability to disable packages at boot is interesting, if I’ve understood that correctly.


#115

I can’t imagine how you think nothing has “nothing much has happened except more package management stuff”. A lot has happened even over the past 4 or 5 months.

And also… if your complaint is that nothing has happened, then why are you coming here and distracting the very busy developers with yet another useless tirade about how package management is horrible, and BeOS R5 was the best, Haiku will never be like that, etc…?


#116

My original comment was too harsh. My disappointment remains, however. It may simply be that what i wanted from this project is never going to happen and I’m sad and a little bitter about it. I was actually involved in the origins of it, but i stepped away to deal with my personal life, and i was also disgusted at how certain people were treating certain other people. When i came back, everyone i was connected to was gone and everything had changed focus.

C’est la vie.


#117

Then be my guest and enlighten us what is this “easily stopped” solution? It’s just that many think security would be so easy so why making a fuzz about it. But there’s a reason computer security fills entire university courses as topic alone.


#118

One must think outside the box of conventional wisdom. But, because it is such a radical approach, no one (working on an existing OS) ever goes to the trouble to actually implement it, because it would break everything that currently works.

The saying: “Always time to do it over, never time to do it right.” is why it’s never done. It’s easier (job security?) to “fix” the problem endlessly, rather than eliminate it completely.

I just wish I could find some people willing to actually go down this road, if they were able.

Step 1: Deconstruction


#119

So in other words you do not have a solution to give.

You were ask “What is the solution?” and all you answered was “It will require a rewrite.”.

No solution was given from you.

Please, if you have such a solution give it to us, you can’t complain that no-one will listen if you don’t start talking.


#120

From what I have been able to gather from previous comments, I think his idea is all about rewriting an OS ‘from scratch’ for optimal performance and security and “rethinking” the entire thing from how everyone else has done things since the beginning… but how exactly would that be done? Machine learning? I would be interested in welcoming and listening to new ideas.