Haiku bfs encryption and two factor Yubikey authentication

What a great response from my post. I did not really expect this kind of engagement.
I read through all the posts on this topic and I found some constructive feedback
and arguments.

Yes, I have included AI in all my development work.
In my own experience I found out that I am now significantly more productive. I also found out that it
is now possible for me to tackle larger projects and also things like drivers.

This application is a true example of that, here I am actually trying to push the limits what is possible. Madness? Maybe.

In less than one week on my spare time I got from an idea to a fully working application.
Just that alone is quite impressive. I really did not expect that fast pace, I thought this project
would take me some months to even reach some core functionality.

One feedback that I really agree on is that it should be easy for a potential code reviewer to know if the project/code is from an AI or not. I have made a correction on that. Now it is very clear in the README.

I also share some of the concern about security applications and AI. It raises valid questions, which is why I invested heavily in testing, security hardening, and documentation — 126 automated tests, a penetration test report, and a full security audit checklist.

Of course it needs proper reviews, external security code audits, professional pen-tests to even be considered secure. The day when Haiku reach R1, then I try to fund for an external code audit and professional pen-testers.

Another thing that was discussed in the posts:

Yes, I have read and reviewed all code myself. It is in my CI workflow. I really want to understand
the code and also learn as much as possible.

Do I really understand all the code? No (the crypto algorithm part is really hard, very tricky stuff).
That is also one of the reasons why we run so many tests on that part.

I built the application just for myself and for my own curiosity. If you find it useful, great.
If you don’t, fine. We still have some freedom of choice in this world.

In the future, we will rename Haiku to hAIku… :slight_smile: Happy coding guys, girls and AIs!

10 Likes

I disagree with you on most of this, obviously, but this I agree with. :slight_smile:

Thank you for staying engaged and posting a response.

2 Likes

What a ghastly thought.

4 Likes

One of the recent studies on the use of LLMs for coding reveals that, while developpers are more productive, the net result is writing and rewriting a lot of code in work in progress branches, but if you look at the main branch, where things land after being reviewed and tested, things actually slow down.

So, people work more, get more exhausted from doing so, and the code doesn’t meet the quality standards. So, yes, you can write code faster. In Haiku, this isn’t what we need. We already have quite a backlog of merge requests to review, and there’s no way we’re going to trust an LLM to do it for us.

Anyway, do what you want with your own project. I find attacks on Axel’s existing DriveEncryption work (not by you, but by other people here) unacceptable. Axel has already replied himbself, but I will add for completeness that his work on DriveEncryption and integrating it in a package managed Haiku led to the development of the launch daemon, as a way to give 3rd party packages more control on the boot process (previously this would be done by patching a shell script that handled the boot sequence). That is the kind of improvements that we get from trying to do things the right way, keeping the “big picture” in mind. And sometimes it doesn’t bring us where we wanted to go, and makes us takes large detours. But I would say it’s all worth it.

14 Likes