Hi there, it's time for the monthly report again! This report covers
hrev53338-hrev53461. It's been a busy month!
This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/pulkomandy/2019-09-07_haiku_monthly_activity_report_august_2019/
Thank you for this nice and bug report. Thank you to all people working on haiku.
Great read, felt a bit like a super star when I saw my name there, even if I only changed a few lines of code. Love this project, amazing work everyone!
Another productive month. Thanks for the write-up, @PulkoMandy, and thanks to everyone who contributed changes.
Thank you for another activity report! And thanks for all the work that’s going into Haiku!
I don’t know whether this explanation was written by Waddlesplash or Pulkomandy but it seriously undersells the importance of this change.
Rather than allowing “better” validation the change finally enables the basic checks. In all the years prior to this fix Haiku simply didn’t check names here, making all the security of SSL / TLS completely futile in all Haiku native applications such as WebPositive.
For example if you visited https://mybank.example/ you might expect that WebPositive would not accept a certificate for https://bad.example.com/ for that site, but until this fix was prompted you’d have been wrong and Haiku would give you no indication that there was any problem at all with your bank site.
Waddlesplash also got the ramfs up and running again. This is a filesystem that stores data directly into RAM. Unlike a ramdisk, it does not use a RAM-based block device and a traditional filesystem above it, which means it only uses RAM for allocated files and automatically frees it up when the files are removed.
Ooh, just like the Amiga RAM: disk? Great!
We do what we can with the stupid APIs OpenSSL provides us.
I thought we had fixed such basic issues long ago (when we implemented SNI, which is required for this to work, otherwise the server doesn’t know which certificate to send).
The OpenSSL API does not perform any validation by default and accepts everything (no certificate? That’s fine! It is not signed by a known authority? Go ahead! It doesn’t even match the website address we requested? No problem!). So it’s very easy to miss something, and since most websites are correctly configured, and such problems arise only on testing scenarios and when under attack, it is not that easy to make sure we are properly doing all the checks.
We are not the only place where you will find such issues, many Android apps are also allowing similar breaches, for example.
And as I keep saying for a few years now: this is what happens when you let a single developer take care of some part of the OS. Please do help with the code and improve such things!
Yes, and I only noticed it because I saw your comment on Hacker News. Why didn’t you file a bug about this? The fix was 2 lines, we would have done it years ago had someone noticed. Kind of annoying to find out about such a serious bug this way…
(I started doing a kernel-level security audit recently but haven’t worked my way up to this stuff yet, so I’m only fixing the known violations.)
No, we already have a ramdisk, on which you can put any conventional filesystem. This is a ramfs, a file system which needs no disk to back it.
Whats its core purpose? Back in the days while I was developing in Windows I used ReSharper to setup its temporary files (indexed source files) on a RamDisk to speed up the intellisense. Is the purpose something similiar? Files that needs to be accessed frequently and that would benifit of a speed increase?
I meant in the way that it is dynamically allocated - the Amiga RAM disk also isn’t fixed size and will consume RAM of exactly the size of the contained files.
Yes, you can use it when you don’t need the files to be persistant so you can avoid writing them to disk altogether and just store them in RAM. We could consider using it for /tmp, for example, but the user can also set it up for their own similar needs.
One nice thing about the Amiga implementation is making it possible for the RAMFS to be “resident”, that is, able to survive a reboot. I don’t know if we can do this reliably on PC, however, the BIOS and bootloader and our own memory management will likely not be careful enough to preserve RAM content in that case (or even careful to clear most of it).
HaikuPorts team should maybe consider using it as chroot, but it would take many RAM for ports like Qt.
RAM: on Amiga works like ramfs, you do not need a filesystem and it is filled up until memory is full.
RAD: on the other hand is something you need to format and survives a reset, but has always the size of one Amiga DD floppy (880k).
Given that many people are either away on holiday during August, or having to deal with kids at home, this monthly report represents an impressively large amount of work.
It’s much appreciated.
This really is quite a lot of less visible but very important fixes…
I’d like to see the virtual machine guest additions fixed for VMWare, VirtualBox (despite it’s drawbacks it is still usable). So at least mouse grab and and auto resize of the display work…
The VMware additions do work already. Dunno about auto-resize, but I use the mouse integration and shared clipboard all the time.
Ah, didn’t realize this I only use VMware at work.
BTW, do you see random Deskbar crashes due to shared clipboard? https://github.com/HaikuArchives/VMwareAddons/issues/12