5 ms·
Enough of it is performance sensitive that Fil-C is not an option. Fil-C is useful for the long tail of C/C++ that no one will bother to rewrite and is still u
by dontlaugh 1y ago
Enough of it is performance sensitive that Fil-C is not an option.
Fil-C is useful for the long tail of C/C++ that no one will bother to rewrite and is still usable if slow.
- procaryote 1y agoHow is apt performance sensitive?
- kragen 1y agoApt has been painfully slow since I started using Debian last millennium, but I suspect it's not because it uses a lot of CPU, or it would be snappy by now.
- dontlaugh 1y agoIt parses formats and does TLS, I’m assuming it’d be quite bad. I don’t think you can mix and match.
- jitl 1y agostuff that talks to "the internet" and runs as "root" seems like a good thing to build with filc.
- loeg 1y agoIt probably uses OS sandboxing primitives already.
- kragen 1y agoIn normal operation, apt has to be able to upgrade the kernel, the bootloader, and libc, so it can't usefully be sandboxed except for testing or chroots.
- loeg 1y agoNo, that doesn't follow. That only means the networking and parsing functions can't be sandboxed in the same process that drops new root-owned files. C and C++ services have been using subprocesses for sandboxing risky functionality for a long time now. It appears Apt has some version of this: https://salsa.debian.org/apt-team/apt/-/blob/main/apt-pkg/contrib/fileutl.cc#L3233 https://salsa.debian.org/apt-team/apt/-/blob/main/apt-pkg/co...
- kragen 1y agoThat's true; you can't usefully sandbox apt as a whole, but, because it verifies the signatures of the packages it downloads, you could usefully sandbox the downloading process, and you could avoid doing any parsing on the package file until you've validated its signature. It's a pleasant surprise to hear that it already does something like this!
- deleted 1y ago[deleted]