Coldfirex has quit [Remote host closed the connection]
bbjimmy_64 has quit [Quit: Vision[]: i've been blurred!]
frkzoid has joined #haiku
frkazoid333 has quit [Ping timeout: 480 seconds]
<Begasus[m]>
I am now Skipp_OSX but doesn't seem to be required anymore :)
<Begasus[m]>
morning peeps
dby has quit [Quit: Vision[]: i've been blurred!]
<janking>
morning
<Begasus[m]>
morning janking
<janking>
:)
Begasus has joined #haiku
mittwerk has quit [Quit: mittwerk]
<Begasus>
k, that worked :) grabbing cutter-2.3.4-1-x86_64.hpkg and moving it to /Share/haikuports/packages/cutter-2.3.4-1-x86_64.hpkg (without patching to find rizin) :)
freddietilley has joined #haiku
DKnoto_W2 has quit [Quit: Leaving]
mittwerk has joined #haiku
DKnoto has joined #haiku
diver has joined #haiku
diver has quit [Ping timeout: 480 seconds]
JakeSays1 has joined #haiku
JakeSays has quit [Ping timeout: 480 seconds]
janking has quit [Quit: Vision[]: i've been blurred!]
rakka has joined #haiku
DKnoto has quit [Ping timeout: 480 seconds]
DKnoto has joined #haiku
mittwerk has quit [Quit: mittwerk]
mittwerk has joined #haiku
mittwerk has quit []
mittwerk has joined #haiku
janking has joined #haiku
diver has joined #haiku
vdamewood_ has joined #haiku
vdamewood has quit [Read error: No route to host]
_yn0ga_ has joined #haiku
__Yn0ga__ has joined #haiku
diver has quit [Ping timeout: 480 seconds]
nephele has joined #haiku
<nephele>
we should port pledge()
<phschafft>
em?
<nephele>
from OpenBSD phschafft
<phschafft>
yes, yes.
<phschafft>
but I think that is like far out in terms of a security concept. ;)
<nephele>
Depends. I think it is a relatively cheap investment ;)
mmu_man has joined #haiku
<nephele>
for all those "but haiku apps run as root" issues, if the only thing those permissions affect is filesystem perms, and your app pledges it can't use any fs apis :D
<nephele>
add to that some apis like "I want to invoke a file picker", which are allowed can already massively cut down on the ammount of apps that even have the ability to screw over your FS
<nephele>
add another api for the settings, etc
<phschafft>
I think it's a bit more complicated than you think.
<phschafft>
I mean sure there are a few easy ones that can actually improve the situation.
<phschafft>
but e.g. filesystem access is complicated topic.
<phschafft>
and calling other code is as well.
<nephele>
sure. but there is no easier case than "block everything" in that regard
mittwerk has quit [Remote host closed the connection]
<phschafft>
have you also had a look at Linux's capabilities?
<nephele>
You mean SELinux or something else?
<phschafft>
no, standard Linux capabilities
<nephele>
then no
<phschafft>
they are there to allow processes to do operation that is normally only for the superuser as other users, or restrict the superuser.
<phschafft>
basically they replaced the concept of 'root has all permissions' to 'root has all capabilities set by default'
<nephele>
Is that usefull? I don't know if "root has all permissions/capabilities" is even a usefull concept. but besides that, the main thing i want to protect is user data, what is on the filesystem, from intrusion or accidental corruption
<phschafft>
there is also AppArmor, which is more like a superset of pledge().
<phschafft>
nephele: my point is that capabilities are another related concept and should be had a look at if you build something similar.
<nephele>
Sure
<phschafft>
plus it is more targeted towards more powerfull processes. which sounds like a good idea on a system that basically runs everything as root. ;)
<nephele>
apparmor, or any other things you can just turn off don't seem that usefull
<phschafft>
the point is that you can't turn things off once you're under their control. exactly like with pledge()
<nephele>
phschafft: well, I think there are severall things that should probably change. For example to not load translators into your adress space, run trackers desktop in it's own process (with the replicants) etc
<nephele>
from a users POV, something doesn't quite work, just turn off apparmor, delete some settings files with policies etc
<nephele>
sure the app itself can't turn it off, but that is beside the point
mittwerk has joined #haiku
<phschafft>
I don't think it's beside the point.
<phschafft>
if your argument is 'if the user can bypass it, it is useless' then everything is useless on a system with the user having access to things like a super user account, the sources, and a compiler.
<phschafft>
no matter how bad or complicated it is, you will always find that one article on the net that tells people to just turn it off.
<phschafft>
and that article will always be the second highest ranked on google (after sponsored stuff).
<nephele>
if you want to recompile haiku without it's security systems that is fine, for you. But patching out pledge is not really feasible for users
<nephele>
just deleting some config files certainly is
<nephele>
so, capabilities sure, make sense, something like pledge also makes sense.
<nephele>
after the fact security like selinux or apparmor not so much
<phschafft>
so looking at what AppArmor does is useless as you cannot learn anything for it for Haiku as you think it's useless on Linux?
<nephele>
strawman much?
vdamewood has joined #haiku
<phschafft>
all I said was that AppArmor on Linux is what pledge() (and friends) are on OpenBSD. and that it is worth a look at.
<nephele>
I never said you can't learn anything from it.
<phschafft>
and you responded with: na, useless!
<nephele>
No, i said not usefull
<nephele>
as in: "does creating something with an equivalent workflow on haiku seem usefull" answered with "no"
<phschafft>
now it's half full or half empty, eh?
<phschafft>
and nobody suggested that!
<nephele>
And i already explained why i don't consider it usefull
<nephele>
i didn't suggest we should burn it to the ground
vdamewood_ has quit [Ping timeout: 480 seconds]
<phschafft>
so by your own standards I could also say pledge() is useless as it cannot be turned on by the user.
<phschafft>
so let's not implement something like that on Haiku!
<nephele>
When did i say that...?
<phschafft>
you said that if the user has direct control of the switch it's 'not usefull'.
<phschafft>
I'll now start my day with something productive: help my flatmate out the door.
<nephele>
No, i said it is not usefull if the user can turn it off
<nephele>
pledge can't be turned off by the user
<nipos>
Maybe also interesting to take a look at: SerenityOS also implements pledge() inspired by OpenBSD.Not sure if it's API-compatible with the OpenBSD one,but probably it is since that would make porting stuff that already supports pledge() easier.
<phschafft>
nephele: so can the user turn of pledge() if they enjoy that. shouldn't be too complicated.
<phschafft>
and also there is way more about AppArmor then one bit of a switch.
<nephele>
Where are you going with this?
<phschafft>
that the situation is the same for all three things. and that you should be equally open minded.
<nephele>
you seem to argue against bledge on the basis that apparmor exists. that makes no sense to me
<phschafft>
just because you hate everything linux should not result in not learning from it.
<nephele>
pledge*
<nephele>
Okay... so, pointing out flaws in systems in a discussion is "hating everything linux". I will remember that for future reference
<phschafft>
I argue that it's doing the same thing and is similar in many ways. too similar to reject one without also applying the same arguments to the other.
<phschafft>
nephele: let's face it. you enjoy ranting about Linux based systems. ;)
<phschafft>
anyway. time to hold someone the door open!
<phschafft>
(again to the ops: if you feel so, feel free to kick me for my statements.)
mittwerk has quit [Remote host closed the connection]
<nephele>
I don't enjoy linux because it is a mess of different projects loosely bolted together, and all the complexity that comes with it. I don't see how you derive from that that I must hate it, or think there are no good ideas in the system
<nephele>
just as a user it is hard and complicated to use
<nephele>
Anyhow, if you think you deserve to be kicked maybe check if your discussion style was that usefull today...
<phschafft>
I don't think I deserve to be kicked. I just understand that my style is not enjoyed by all of people. _as I explained to you before_.
<nephele>
Sure, I can understand that. But then this did not seem like a typical communication style for you :) Sometimes I think voice communication is just easier
<phschafft>
nephele: if it is of any help to you: from my perspective you also seem to switch between two styles.
<phschafft>
so maybe this is kind of a feedback effect between the two of us.
* Begasus[m]
doesn't think linux is that hard to use ... (putting gasoline on the fire) ... :)
<Begasus[m]>
just stay away from plasma for a while (reading the matrix channel on the topic there) :)
<phschafft>
I would say if your ship is Haiku it's not the best plan of war to attack the ship labled GNU/Linux ;)
<nephele>
Begasus[m]: what about plasma?
<Begasus[m]>
seem to be plenty of issues with plasma latest updates nephele
<Begasus[m]>
6.2.0 was just released and 6.2.1 (bugfix) followed very fast
<nephele>
*shrug* I guess, it happens. Especially if you keep re-doing stuff because of constant framework updates
<Begasus[m]>
plasma has seem more updates then the kde frameworks
<Begasus[m]>
atleast in the 6.* range that I have seen
<Begasus[m]>
kde frameworks 6.7.0 is pretty good, brought some new features for the gear24 updates
<nephele>
I've used plasma6 briefly on manjoro linux, but other than that everything i use (including the steam deck) still has plasma5
<nephele>
hmm, webpositive has trouble scrolling the KDE site, i wonder why
<Begasus[m]>
Installed kubuntu the other day, at first also had plasma5, after upgrade it had plasma6, and already had issues boot it :)
<Begasus[m]>
kde-apps?
arjen has quit [Ping timeout: 480 seconds]
<Begasus[m]>
well, don't use much browsing in the VM here, tends to take away too much cpu power, so I copy/paste between the host and client
<Begasus[m]>
on that note, got rzghidra also build (but Cutter can't seem to find the plugin) :P
<Monni>
Begasus: Only few recipes use fixCMake() currently, some of them also use sed manually to fix the result...
<Begasus>
yeah, mostly for the headers
<Begasus>
and fixCMake has only recently been added, so no wonder it's not used much yet ;)
<Monni>
Begasus: I'm not 100% confident searching for "}/lib" and replacing it with "}/develop/lib" is safe alternative...
imrahil has joined #haiku
<Begasus>
then it should look for "librz_core.so.0.7.3"
diver has quit [Ping timeout: 480 seconds]
<Monni>
Begasus: Maybe warrants creating an issue on Haikuporter repository, or if there already is, updating it with the details why it doesn't currently work...
<Begasus>
Monni, so far this is the only one I've been fighting with for years
<Monni>
Begasus: Something is always the first... I think there is at least 7 recipes that might be affected with fixCMake not working correctly...
<Begasus>
could be, but haven't tackled/tripped over them recently I think ;)
<nekobot>
[haiku/haiku] a2cf217f8f0b - kernel/vm: Add #include <team.h> to vm_debug.cpp.
<nekobot>
[haiku/haiku] fc7456e9b1ec - fix typo in "Update keyboard.dox"
<Monni>
Begasus: Windows can load Haiku bootloader without even rebooting...
<Begasus>
not even attempting Monni :)
<Monni>
Begasus: I do it every time I need to switch between Windows, Linux, FreeBSD, NetBSD and Haiku...
<Begasus>
meanwhile, this works on 32bit "sed -i 's,\${PACKAGE_PREFIX_DIR}/lib,${PACKAGE_PREFIX_DIR}/develop/lib,g'" (the x86 was already added, so no need to further sed that)