does anyone here know exactly the magnitude of the security issues that are posed by Firefox's and chromium's lack of sandboxing on FreeBSD? like is it worth taking additional measures like using completely separate browser instances for different things, like keeping banking/finance stuff separate?

separate to what? you intend to set up another computer just for checking your finances?

tm512: the practical impact is that if someone finds an exploit in the browser, they will have access to your entire Unix account, so using separate instances/profiles probably makes little difference, unless you run as a completely separate uid

finds an exploit, constructs the exploit, and lures you to visit said exploit

rtprio: and the exploit has to run on freebsd...

I think it was mentioned on one of the FreeBSD forum posts about this but I remember reading something about how the sandboxing is largely to protect processes in the firefox process tree from each other, not just isolating each process from the rest of the system

so like it would help prevent an exploit in one process from, say, reading out my paypal login token/credentials from paypal running in another tab

aiui the sandboxed process is isolated from everything, which includes other tabs as an indirect consequence

like, even without sandboxing, one tab can't just read random data from another tab, but an exploit that allowed complete access to your account (as is the case without sandboxing) would allow that since the other tab is running under your uid

alright. might just not worry about it, but just wanted to know exactly what the implications are

it makes me a bit uneasy too tbh, given how many browser exploits are discovered

I might end up setting up capsicumizer to, like, restrict FF to only accessing its configuration/cache directories, in addition to my downloads folder, but I dunno

whee :-D cgit.freebsd.org/src/commit/?id=9b7…20a12a9377b9c8227f72748ab32fbbb4822

it's a shame that there seems to be so little interest in adding sandboxing capabilities to browsers on FreeBSD. I saw that there has been *some* work done that just fizzled out

Title: src - FreeBSD source tree

tm512: browser vendors don't care about freebsd and will not support it, so adding such capability would mean effort to maintain it forever, no one cares enough i guess

the internet only runs on windows, mac and linux

i mean, Mozilla won't even support OSS *audio output* in Firefox, so the chance they will care about sandboxing is ...

if we had a browser vendor who actually cared about an open internet, perhaps they would support freebsd, but google's hostile takeover of w3c pretty much ensured that maintaining a basic web browser requires full-time commercial support by itself, so that's the situation we are in now

(in case you can't tell, i am quite bitter about this)

I thought cubeb, firefox's audio backend, has OSS support integrated even if it's not "Tier 1" support

tm512: it has tier 2 OSS support, that means Mozilla does not support it and doesn't care if it breaks

random people in "the community", i.e. you, might choose to maintain it and fix it when it breaks, Mozilla will not

now imagine that policy applied to sandboxing, one day Mozilla adds a new sandbox feature that doesn't work in capsicum, and now Firefox is completely broken on freebsd until "the community" fixes it

this whole discussion about official support is kinda describing why I mostly left BSD behind for Linux even though BSD has a special place in my heart, heh

yeah, this is why people like mozilla and google get away with this stuff... they know users care more about having an actually functional system

which is understandable, i don't blame the users

in the case of this system I'm setting up currently, it's just a laptop, gonna be my secondary machine, and I'm not gonna need it for much that BSDs struggle with like gaming

so FreeBSD is going to be a nice change of pace. also haven't checked out the OS since I was running 11-STABLE as my desktop daily-driver

hmm, so I thought this issue with things using llvmpipe was fixed, but it's actually not, and it's directly tied to running picom (at least with the glx backend, haven't tested xrender)

if I spin up picom, my system console gets flooded with "fault errors on pipe A" messages, and everything else that tries to use GL falls back to using llvmpipe

I might try the Linux 5.10 DRM drivers instead, assuming they support comet lake? I remember having issues with actual Linux 5.10 on comet lake in the past, though

what are you using now? drm-61-kmod?

I'm using the 5.15 drivers, the newest that I saw available. it looked like the 6.1 drivers needed to be compiled from source

I may give those a shot though if they support 14-STABLE

according to freshports that version is only available on 15-CURRENT :/

ah

I might try configuring Xorg to use xf86-video-intel instead of the modesetting driver, see if there's something specific to the combination of modesetting and picom that causes this issue

even though it generally seems like modesetting is the preferred driver for supported hardware nowadays

looking up this error message I'm not finding any search results that seem even remotely related to the issue I've encountered

I dunno if I'm brave enough to try 15-CURRENT in order to try out the Linux 6.1 drivers. or maybe "brave enough", but not willing enough to tolerate the higher likelihood of regressions and bugs and the inconveniences those would cause

Anyone going to BSDCan?

so downgrading to drm-510-kmod gets rid of the fault errors, but picom still breaks things, causing glxinfo to report that llvmpipe is being used

weird, now it's just working

So in /boot/loader.conf all values on the right side of the = need to be double-quoted?

CrtxReavr: no, i never bother

maybe some kinds of value need to be quoted but i haven't found one yet

i worship Daemon and that's one reason I use *BSD

Hmmm

CrtxReavr: only more complex values

numbers and single-word values are fine

if you need a symbol it'll probably shit the bed, better to quote it even if it's still technically one word

Seems like everything I set is 0 or 1

yeah, those will all be fine

I still tend to quote out of habit, but lualoader hasn't screwed this up since the earlier days of it living in the tree

I have installed `pinentry` on both FreeBSD and OpenBSD, but both tell me "復号に失敗しました: Pinentryがありません" (translation: decryption has failed: there is no Pinentry), despite having installed pinentry and pinentry-ncurses already.

Anyone know how the fuck this happened?

Nevermind, solved it.

pkill gpg-agent && gpg-agent --pinentry-program=/usr/local/bin/pinentry-curses --daemon

remiliascarlet: 👍

remiliascarlet: You can set the default pinentry-progrm in ~/.gnupg/gpg-agent.conf

Hello there

anybody alive in this channel ?

Title: Don't ask to ask, just ask

"D

ok then, is it possible to get pkg info to return list of packages origin only ?

eg pkg info -o php\* | awk '{ print $2 ; }'

never mind managed to do that by using pkg query %o ...

and it appears that even asking the question directly, helped you rubber-duck'd the problem too, so yet another reason not to ask to ask :P

Hi, has anyone tried Samba clustering with FreeBSD before? AFAIK, CTDB is not available on FreeBSD.

tmp_: I figured that out a bit later, but wasn't enough to get shit working.

And it doesn't help when Linux, Haiku, Solaris, and many other Unix systems use /usr/bin, FreeBSD and OpenBSD use /usr/local/bin, and NetBSD uses /usr/pkg/bin, and auto-sync this across one other.

Auto-sync the dotfiles.

Or have NFS home directories across multiple OS's.

remiliascarlet: FreeBSD can theoretically use /usr/pkg or /opt/foo or whatever, although it's been a while since I tried. I should try again in 14.x

with user.localbase properly set it should not be a problem

mason: redefining LOCALBASE is easy (in so far as setting it in make.conf(5), and compiling ports using poudriere, so not simple) - but I'd question what one gains from doing that, when hier(5) quite demonstrably has carved out the entire namespace of 'local' for this.

when a path is hardcoded..

Well, uh.. it isn't hard-coded, is the entire point.

debdrup: I still cling to this notion that /usr/local is for the local admin, not for packages provided by the system.

It's why I like what pkgsrc does in that regard. I understand it's a minority viewpoint here.

mason: well, the official definition for local is "local to this installation"

That kinda covers both scenarios.

debdrup: Right, but then non-ports things installed in /usr/local becomes problematic and potentially rife with conflict.

s/becomes/become/

Like, I'm not saying don't do it - but building an entire set of ports just to change LOCALBASE seems like wasting electricity.

That too.

mason: I see your point, I just don't agree with it.

One of the sites I'm supporting currently has a mix of ports and custom tools in /usr/local.

In my mind, something either belongs in the FreeBSD distribution sets, or it's local to a specific installation. If it's former, then it gets added to the distribution by the system operator, in the form of build-time, install-time, or run-time configuration via modification of the source, use of poudriere-image/bsdinstall, or ansible/chef/et al.

tmp_: there's where the ability to add custom ports/packages comes in, since you can have a whole set of custom things added that either inherit existing makefiles or build custom stuff.

Welp.

I forget what the make.conf(5) switch for adding a custom category is, right now..

debdrup: so, if I have a script starting with, say

#!/usr/local/bin/bash

user.localbase can automatically relocate it ?

babz: #!/usr/bin/env is the solution to cross-platform scripts that rely on the miscellaneous binary image activator in the kernel (which is what you're denoting with the hash-bang path).

binmiscctl(8) can also be used for some things along that line (which, for example, is how you make it possible to launch Windows PE32(+) binatires via the command-line using Wine).

Oh right, it's VALID_CATEGORIES+=bleh in make.conf(5) and then adding the 'bleh' directory in your ports copy of the ports framework (probably best done on a branch that you merge the head onto).

in an rc script, how do you hard fail? i.e., "if critical thing didn't happen" then "stop the boot process and drop into single user mode." i see things like force_depend, but curious if there's an approach for a hard stop.

markmcb, IIUC one just returns 1 from the script. So for example for service "foo" then in a function foo_prestart() { return 1; } would be a hard stop. Pretty sure.

rwp: thanks, that's quite easy

It looks like the function name might actually be defined in start_precmd="${name}_whatever" so I would name it foo_precmd() in that case. I guess.

I am looking through docs.freebsd.org/en/articles/rc-scripting

Title: Practical rc.d scripting in BSD | FreeBSD Documentation Portal

that is what i was reading that triggered the thought

And I am finding that their example is mixing the notations of prestart and precmd in ways that I wish they did not. But it seems to not matter. It seems to be whatever is declared as the function to call in start_precmd variable is used making the name arbitrary. But I still think it should be consistent.

man rc.subr documents argument_precmd and I am pretty sure "argument" is meant to be start, stop, restart, and so on.

Looking at /etc/rc.subr directly the embedded comment documentation is much better! There it is documented as "${rc_arg}_precmd n -- If set, run just before performing the ${rc_arg}_cmd method in the default operation (i.e, after checking for required bits and process (non)existence). If this completes with a non-zero exit code, don't run ${rc_arg}_cmd."

The "n" in that says it is optional.

And yes tracing through the rc.subr use of it the return from that function (ex :return 1) will propagate through and become the exit code for the entire service script. Which I presume would then be listed as a failure at boot time.

Looking at /etc/rc.d/sshd for one example that we all will have I see that it is using sshd_precmd() to do an "sshd -t" configuration test before starting. If that fails then the sshd_precmd() returns 1 (by implicit fallthrough, I do not approve, I would like to see an explicit return there) and that would exit the entire script at that point before starting the sshd.

By inspection looking at both sshd_keygen() and sshd_precmd() I think the script is playing "loose" with possible errors. Each of those lines should be "|| return 1" for pedantically correct operation. As written they currently only depend upon the return of the last command call in each of those functions.

Which obviously has been sufficient and it is not causing problems, and unlikely to have problems, but by inspection it does not seem totally correct. I could contrive an example where it would partially fail but not be reported. I think.