I'll wait for a bit more input, then I'd be happy to commit this
and bring it into release.
Theo Buehler wrote:
> On Mon, Sep 23, 2024 at 03:01:17PM -0600, Theo de Raadt wrote:
> > Does this help?
> >
> > Since we are close to release, I'm intentionally making it a seperate
> > block, and we can trust the compiler's common-subexpression-eliminatio
Does this help?
Since we are close to release, I'm intentionally making it a seperate
block, and we can trust the compiler's common-subexpression-elimination
to clean it up. If there was a 3rd entry we would make it a switch().
Index: kern_pledge.c
==
Stuart Henderson wrote:
> > Managed to capture some ktrace -di by pointing it at the running main proc
> > after startup and reloading the tab. Instead of getting killed by pledge, I
> > get a SIGILL instead, trapped by firefox's handler.
> >
> > 23282 firefox PSIG SIGILL caught handler=0xc804ce
Chaz Kettleson wrote:
> My general thought here was since I only needed wpath/cpath for pid/log
> files, and I was not going to patch for syslog (still need to write pid
> anyway), I would at least unveil for only those files. The idea of
> unveil("/", "") just seemed like a sane default from oth
I think you should give up on this.
I think by talking about "sandbox" in an abstract for what is going on,
it fails to describe the what is going on. "sandbox" is an extremely
unspecific words and everyone brings in their weird understanding.
- the program (firefox) has extremely poor "privsep"
You can try this yourself:
ping 0.0.0.0
ssh 0.0.0.0
or on a webserver machine
nc -v 0.0.0.0 80
It's the same for chrome, because it is the same for *all userland programs*
CIVINULL wrote:
> https://www.bleepingcomputer.com/news/security/18-year-old-security-flaw-in-firefox-and-chrome-exploited-in-attacks/
>
> I wonder if the sandboxing of Chromium and Firefox on OpenBSD will prevent it
> from being affected by this vulnerability.
Sorry, our sandboxing efforts do
José Maldonado wrote:
> I agree with that Theo, but that's exactly why I'm asking, to find out
> if there are any known issues, not to put pressure on it.
>
> I understand that Robert is the only one working on that port, in
> fact, I CC'd him so he can respond if there's any problem with it.
t
This is so backwards.
What do you expect to happen? Oh robert will commit it, without any
testing. Oh and only he should work on it, right? Noone else needs
to, they can just sit on the mailing list and ask "when?"
Yes there is a reason. It is one guy doing it all, and asking is
NOT ACTUALLY
Landry Breuil wrote:
> thanks, that's a start, because it makes us understand what files are
> opened by which process.
>
> But you do realize this adds lots of capacities to those process types
> that arent needed right now, thus shouldnt be added.
That is correct. What's being proposed is ve
That's quite a step backwards for pledge usage. The firefox privsep
story just keeps getting worse.
Mark Kettenis wrote:
> In general I'd say shared objects should always be linked against
> libc. But Theo will probably never agree with me.
Let's be accurate what this means.
It does not mean linking about libc.
It means encoding a specific libc.so.#.# as DT_NEEDED, which will cause
us compl
Vevy Kod wrote:
> 1. We do not need a good reason to reduce our attack surface. The
> likeliness of the scenarios we are preventing does not matter: those
> scenarios will become likely as soon as they become the easiest to
> exploit.
What is the attack surface?
> 2. It prevents unknowingly esc
or message will not be particularly hard to read; i guess if
> > someone really hits the limit, we can do something about it then?
> > we don't want to do anything in upstream harec because we want to
> > keep it to the POSIX subset.
> > On Thu, Jul 18, 2024 at 09:29:39AM -
Lorenz (xha) wrote:
> On Thu, Jul 18, 2024 at 09:50:56AM -0600, Theo de Raadt wrote:
> > Lorenz (xha) wrote:
> >
> > > On Thu, Jul 18, 2024 at 09:45:34AM -0600, Theo de Raadt wrote:
> > > > Lorenz (xha) wrote:
> > > >
> > > > >
Lorenz (xha) wrote:
> On Thu, Jul 18, 2024 at 09:45:34AM -0600, Theo de Raadt wrote:
> > Lorenz (xha) wrote:
> >
> > > the HARE_TD_ are the "typedef" files, basically the equivalent
> > > to C headers, but automatically generated by the compiler so we
Lorenz (xha) wrote:
> the HARE_TD_ are the "typedef" files, basically the equivalent
> to C headers, but automatically generated by the compiler so we can
> do resolution of types/functions/etc. in dependencies without having
> to look at the source files themselves.
>
> i doubt that anyone is e
Stuart Henderson wrote:
> On 2024/07/18 05:27, Theo de Raadt wrote:
> > This is not right.
> >
> > Only a maximum number of unveil's are allowed, before it starts returning
> > E2BIG. That amount is not a public #define, to discourage what you are
> > doin
Tobias Heider wrote:
> I think unveil might still be useful.
I don't think so.
> As I understand Theo the problem is just that calling unveil per-input file
> to grant
> read access won't work. Restricting write and create permissions to the single
> well-known output directory still makes sen
This is not right.
Only a maximum number of unveil's are allowed, before it starts returning
E2BIG. That amount is not a public #define, to discourage what you are
doing.
You are trying to shove an unbounded number of them into the kernel, based
upon getenv and argv.
When you run out, and will
Stuart Henderson wrote:
> This change won't work directly as the following lines currently need
> blocking until dhcp has fetched an address but I don't think it's worth it.
Right.
We have entered a world where dynamic address negotiation is async.
But then, it always was.
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Sat, 22 Jun 2024 06:16:03 -0600
> >
> > Mark Kettenis wrote:
> >
> > > Theo pointed out the NOBTCFI reversal here. Now the reason that we
> > > still see SIGILL despit
Mark Kettenis wrote:
> Theo pointed out the NOBTCFI reversal here. Now the reason that we
> still see SIGILL despite fixes to the assembly code is because the
> -mbranch-protection=pac-ret option added by the configure script
> actually downgrades our default of enabling both BTI and PAC to just
Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2024/05/08 01:14, Volker Schlecht wrote:
> > > aisha@ identified a rather recent problem with lang/node, as in the
> > > following
> > > would immediately crash (nevermind the node version. It'
Stuart Henderson wrote:
> On 2024/05/08 01:14, Volker Schlecht wrote:
> > aisha@ identified a rather recent problem with lang/node, as in the
> > following
> > would immediately crash (nevermind the node version. It's 100% reproducible
> > in 7.5 and -current):
> >
> > $ node
> > Welcome to Nod
Lennart Jablonka wrote:
> Quoth Landry Breuil:
> >Le Thu, Mar 28, 2024 at 02:52:52PM +, Lennart Jablonka a écrit :
> >> I’m trying to get himitsu-firefox¹ working on OpenBSD. It’s a Firefox
> >> extension that talks to a daemon² using “native messaging”: The extension
> >> calls runtime.conn
Thomas Dettbarn wrote:
> I know sir.
> My apologies.
>
> What I actually meant to say was
>
> "Please, Sirs, somebody check the port! I am not qualified enough to
> do so myself."
That is why it was mailed out. So that people could review it.
The peanut gallery who isn't going to review, has
Thomas Dettbarn wrote:
> Hello.
>
>
> Yeah... You know how the social engineering part of this xz
> backhole was done?
>
> Somebody pressured the Maintainer, that he needs to add new
> features.
>
> Afterwards, the maintainers of distributions were pressured to
> update, because there were so
With a bit of effort, the address you see:
addr=0x67cb1d220
can be compared in the ktrace to earlier mmap() operations (done by the
shared library linker ld.so); those mmap are mappings against a file descriptor,
and you can see what library file ld.so opened just previously... then we know
Crazy. Looks good.
Mark Kettenis wrote:
> This one was a bit tricky as I had to adjust the offsets used in the
> instructions. But with this lang/guile3 no longer generates SIGILL
> when running the tests.
>
> ok?
>
>
> Index: devel/libffi/Makefile
> ===
This is because the fbtab subsystem is quite broken. No good
alternative designs have come forward.
Stefan Hagen wrote:
> beecdadd...@danwin1210.de wrote (2024-02-26 22:54 CET):
> > libEGL warning: failed to open /dev/dri/card0: Permission denied
>
> You can fix it with: chown /dev/dri/card0
Christopher Zimmermann wrote:
> Thanks for your feedback guys. I tried to improve the interface by
> calling the hook for each challenge challenge individually and send
> information from acme-client via environment variables, which are
> checked against a restrictive alphabet. This makes droppin
> populated by the acme-client hook and cleared after authorization.
> nsd can reload zonefiles on SIGHUP.
Sending the signal requires privs. What's the plan?
Jonathan Schleifer wrote:
> Fixed upstream:
> https://objfw.nil.im/info/262baf76e7e66bc4
> https://objfw.nil.im/info/d73a388ecaf73b2a
>
> New release:
> https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz
> https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz.sig
>
> Am 24.02.24 um 22:17 schrieb M
That is a missing BTI instruction. Next package snapshot fixes it.
Mikhail wrote:
> core:~$ sysctl kern.version
> kern.version=OpenBSD 7.5-beta (GENERIC.MP) #22: Fri Feb 23 19:29:07 MST 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Latest packages.
>
> co
Looks good enough. (I mean good enough for those two stupid ports)
Florian Obser wrote:
> On 2024-02-20 22:32 +01, Christopher Zimmermann wrote:
> > Hi,
> >
> > this diff adds a challenge hook to acme-client. This hook can be used
> > to fulfill challenges. For example by putting the requested files onto
> > a remote http server (http-01 challenge) or by modify
Rafael Sadowski wrote:
> I see the same illegal instruction with the latest packages and latest
> base:
>
> fuckup$ hugo
> Illegal instruction (core dumped)
>
> fuckup$ dmesg | head -1
> OpenBSD 7.5-beta (GENERIC.MP) #7: Tue Feb 20 11:09:18 MST 2024
>
> ktrace:
>
> 92986 hugo CALL
> mm
t least give me that
> at least tell me is this how things stand FD-wise/limit-wise/whatever, you
> probably know the best out of all I e-mailed with
>
> no attempt yet,in future I hope,it's not a I am too lazy reason
>
> On Tue, January 30, 2024 3:58 pm, Theo de Raadt wrote:
beecdadd...@danwin1210.de wrote:
> I know system shares all resources including FDs
> as far as I know there's what kernel/OS needs and is using and the rest of
> users including but not limited to staff and daemon users/programs like i2pd
> all I was wondering is the limit or amount of FDs and ot
beecdadd...@danwin1210.de wrote:
> maybe not automatically, but having a utility that does this for you and you
> can run it once after each hardare change to find out, but I am not sure you
> say it depends on use-case, I do not understand what you mean
>
> if you read my earlier replies, you wo
that
> wouldn't cause crashes (I assume that's what happens when system runs out of
> file descriptors I read it)
>
> - best regards, didn't sleep who sleeps these days?
>
> On Sun, January 28, 2024 8:21 pm, Theo de Raadt wrote:
> > beecdadd...@danwin12
beecdadd...@danwin1210.de wrote:
> why are yo uignoring my reply? 4096 doesn't cover everyone like I said people
> can become floodfills automatically and floodfills means 8192
the 1 person who cares can change the default.
> To my understanding it's an old BSDism and it's used to implement
> isupper(3), islower(3), etc.
The names may be old BSD, but this is following a pretty strong ISO rule
that names starting with '_' are in reserved, and trying to use them
yourself is undefined.
Changing them to another name tha
I think it is funny how exceedingly precise we are being in .S files
to not place *one extra dangerous bti* instruction.
Meanwhile, the C compilers don't know what will happen, so they slam
unused bti all over the place! But that's why we hope purging these
at link time, as "mold" now does, is go
Theo Buehler wrote:
> > security/pivy configure: cannot compute sizeof (int)
>
> A function call while compiled with -fzero-call-used-regs=all runs into
> retguard. Downgrading to -fzero-call-used-regs=used makes it work.
this suggests that zero-call-used-regs is broken and to
you would need to talk to socat upstream, because in general the ports
team do not add features
Luca Di Gregorio wrote:
> I would like to set a point to point interface encapsulating packets via
> UDP.
>
> It would be like a point to point wireguard but:
> - without authentication (I can set p
+Beware this may allow the user unintended access to other hardware
+associated to the same usb(4) controller, so do this with extreme
+caution.
Can you explain what extreme caution means?
Stuart Henderson wrote:
> On 2023/11/09 11:38, Landry Breuil wrote:
> > The wordexp() use is awkward so i've replaced it by an ugly handrolled
> > lookup for configs in:
> > - $HOME/.sway{idle,lock}/config
> > - $XDG_CONFIG_HOME/sway{idle,lock}/config
> > - $HOME/.config/sway{idle,lock}/config if
On amd64, this makes no sense because we don't use stack protector.
It is retguard. So something smells, it is like their handwritten
context switcher wasn't handling the full context before. But that
might only matter if it unrolls via two seperate methods, or if a
new function above has become
Chris Narkiewicz wrote:
> TL;DR, the writing is on the wall
The writing has been on the wall a very long time that some people believe
their role in the ecosystem is to reduce software choice and push everyone
into vertical software monocultures.
Renaud Allard wrote:
> On 30/09/2023 16:32, Theo de Raadt wrote:
> > I'll try to summarize my point.
> >
> > When less-secure AND more-secure pieces of software exist in the
> > the same role/service area, I think it is valid for developers who
> > ca
I'll try to summarize my point.
When less-secure AND more-secure pieces of software exist in the
the same role/service area, I think it is valid for developers who
care about security of their userbase to *DEMOTE* the less-secure
variations.
This kind of "hide the garbage" policy needs to exist s
Right, it is not the first time.
Will it be the last time?
Doubtful.
If it won't be the last time, will the next time be just as bad?
For sure, because there is no security architecture in it.
po...@phosphorus.com.br wrote:
> Unfortunately I like/use exim for years - pretty simple config file syntax.
Yes, you like unsafe software.
> https://seclists.org/oss-sec/2023/q3/254
>
> So... I suppose those fixes were shared also with Exim's OpenBSD manteiners?
Wow. Are you not listening?
Stuart Henderson wrote:
> With OpenBSD release fast approaching and considering the lack of solid
> information about the vulnerabilities, I think we should probably mark
> mail/exim BROKEN for now.
That's almost too kind.
> And also consider whether we want to keep this in ports at all...
> Th
Thank you for locking ports.
To help prepare for this, I am now locking base + X ABI.
Mark Kettenis wrote:
> > From: Theo de Raadt
> > Date: Thu, 14 Sep 2023 01:02:14 -0600 (MDT)
> >
> > I do not think this should be enabled.
> > Our stacks work differently.
> > We don't put shit near the bottom of the main stack, because we
> >
I do not think this should be enabled.
Our stacks work differently.
We don't put shit near the bottom of the main stack, because we
reserve the space.
For pthread stacks, we allocate them randomly also so you cannot
determistically trash a specific object.
This change also make very small stacks (m
If you use unveil() without pledge(), you do not get the
special-case-file-exposures-for-libc behaviours that pledge() brings.
You are then responsible for all path exposure.
Morgan Aldridge wrote:
> On Mon, Aug 7, 2023 at 3:57 AM Landry Breuil wrote:
>
> > Le Sat, Aug 05, 2023 at 07:41:12PM
> yes, -current has it enabled now. But in order to catch those problems
> you'll need a CPU that supports it, too ... on amd64 that would be
> Tiger Lake(?) and later. I think.
it is any "laptop / desktop" cpu from gen11 onwards, which is most things
in the last 3 years
Mark Kettenis wrote:
> I'm not sure to what extent this makes IBT less effective. Can the
> retpolines be used as gadgets to bypass IBT? Should we stop enabling
> retpolines by default?
>
> What *is* obvious is that retpolines are incompatible wuth shadow
> stacks. Is there an alternative tha
Christian Weisgerber wrote:
> Mark Kettenis:
>
> > This port has some infrastructure to use an optimized function that
> > uses a function pointer. Not sure why for arm64 it actually uses that
> > infrastructure, since the only alternative is the generic C
> > implementation. But adding a BTI
Morgan Aldridge wrote:
> Since Ian mentioned devel/zeal for a USE_NOBTCFI update in -current, I
> figured I'd give it a try. Unfortunately, under OpenBSD
> amd64/6.3-stable, I get the following error when attempting to execute
> it:
>
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tm
Christian Weisgerber wrote:
> (Let's call it "IBT" because this is on amd64.)
>
> The remaining build failures in lang/* are:
>
> lang/crystal
> lang/gprolog
> lang/ldc
> lang/ocaml
> lang/racket-minimal
>
> Is anybody doing full package bulk builds on hardware that enforces
> IBT? I could gi
Brian Callahan wrote:
> On 7/10/2023 9:33 AM, Theo de Raadt wrote:
> > Brian Callahan wrote:
> >
> >> Pushed a nobtcfi fix for DMD.
> >
> > nobtcfi should never be considered a "fix". It is a workaround we make
> > available to allow
Brian Callahan wrote:
> Pushed a nobtcfi fix for DMD.
nobtcfi should never be considered a "fix". It is a workaround we make
available to allow laggard software to continue running -- nothing more.
Christian Weisgerber wrote:
> The remaining build failures are:
>
> lang/crystal
> lang/dmd
> lang/gprolog
> lang/ldc
> lang/mono
> lang/ocaml
> lang/racket-minimal
Have the upstreams been told that IBT/BTI instructions are going to
be required in all software (sometime in the future).
at g2k23 we talked about this issue for a bit. The make(1) manual
page can be confusing because it says:
-j max_processes
Specify the maximum number of processes that make may have
running at any one time.
Nope, that's wrong. It can create vast number of processes
Marc Espie wrote:
> On Mon, Jul 03, 2023 at 12:11:09AM +0200, Christian Weisgerber wrote:
> > lang/ocaml
>
> >
> > I guess for ocaml the big hammer would be to disable native code
> > compilation altogether and fall back to bytecode.
>
> How far behind are we on ocaml code releases ?
>
> Cons
amd64 snapshot contains a different IBT diff which appears to fix go.
Solène Rapenne wrote:
> On Sun, 2023-07-02 at 18:36 -0500, Edward Ahlsen-Girard wrote:
> > Has it been removed from packages? rclone-browser is still a package,
> > but it can't install. I've tried number mirrors.
> >
>
> la
Sebastien Marie wrote:
> sbcl compilation works by generating native code inside live managed memory,
> and
> permits to save the whole memory image to a file.
>
> it is why the binary currently also needs WX and RX memory (I intent to work
> a
> bit on it if possible).
>
> When generating
We know. Wait a little bit longer.
Rémi Bougard wrote:
> Hi,
>
> On the latest snapshot node (node-18.16.1v0) crash immediately after starting.
> After recompiling it from /usr/ports with USE_NOBTCFI=Yes everything works as
> before.
>
> I can provide further data if needed.
>
> All the bes
Theo Buehler wrote:
> On Mon, Jun 19, 2023 at 08:50:44AM -0600, Theo de Raadt wrote:
> > If you disable XSAVE_XSAVES, then userland IBT enforcement is also disabled.
> >
> > XSAVES is required to manage the IBT enforcement mechanism's internal state
> > ove
If you disable XSAVE_XSAVES, then userland IBT enforcement is also disabled.
XSAVES is required to manage the IBT enforcement mechanism's internal state
over a context switch.
All machines with IBT have XSAVES.
If I understand right, there are other ways of managing the state, but
this is the on
Greg Steuck wrote:
> Matthias Kilian writes:
>
> > still slacking around like hell, but I guess we need a new bootstrap
> > for lang/ghc. If so, I'll try to enable USE_NOBTCFI, build a new
> > bootstrap with it, and then use that for building the regular ghc
> > package.
>
> Yeah, sounds about
That looks right to me.
Should there perhaps be a vague mention here that the compiler defaults
have been changed, but if in doubt mention the name of the options that
cause the compiler to do so?
The compiler options are different between arm64 and amd64. Because the
teams didn't talk and convi
Stuart Henderson wrote:
> On 2023/06/11 12:56, Benjamin Stürz wrote:
> > On 11.06.23 09:34, Stuart Henderson wrote:
> > > On 2023/06/10 23:40, Benjamin Stürz wrote:
> > > > Hi,
> > > >
> > > > what should I do next?
> > > > I have at least 2 OKs now, but I don't have any commit rights.
> > >
>
For some of those, I think you have old packages.
The versions were not increased during this test.
Run pkg_add -u -Dinstalled
There is a test being run in snapshots.
We are enumerating the programs that fail.
Thank you for participating.
sprits killshot wrote:
> I'm running OpenBSD GENERIC.MP#1223 amd64 on a framework laptop.
>
> I upgraded to the latest snapshot and updated packages. Then, a bunch of
> programs fai
Vlad Meșco wrote:
> On 7 June 2023 19:25:17 EEST, Allan Streib wrote:
> >My goal is to copy from stdin to a remote system via sftp in a pipeline.
> >I thought curl would allow this with its "-T" argument by providing "-"
> >as the local filename to transfer, but the result was:
> >
> >curl: (1)
Mark Kettenis wrote:
> So as far as I can tell, only arm64 has the -mmark-bti-property
> option. On x86 there is a include file that, when included,
> emits the "right" .note.gnu.property based on preprocessor macros that
> get set based on the compiler options. As far as I can tell, this
> i
> The downside of this
> approach is that it requires modifications to every x86 assembly file.
What happens if I don't do that to an asm file included in the linux
plex client???
+.if ${MACHINE_ARCH:Maarch64}
+CONFIGURE_ENV+= ASMFLAGS=-mmark-bti-property
+.endif
For some of these diffs, it might help to consider amd64 (and i386?) at
the same time. Or, all architectures. In theory this type of thing will
eventually show up on some other architectures.
The ELF tag doesn't
Martin Schröder wrote:
> Am So., 16. Apr. 2023 um 15:49 Uhr schrieb Stuart Henderson
> :
> > At this point I think you might be better served by dumping the
> > package list, uninstalling them all, and reinstalling with 022 umask.
> >
> > Borrowing the old instructions from the 5.5 time_t flag da
> I question our wisdom of having printf() log instances of %s NULL,
> but then declaring that we can't fix the offenders and need to
> resort to intercepting arguments passed to printf().
Indeed, let's step back here.
The logging has cleaned numerous bugs in our base tree.
But ports, that's ano
Christian Weisgerber wrote:
> Landry Breuil:
>
> > I've had a quick look and got a bit lost in the maze, but my
> > understanding is that via various aliases/defines, the function called
> > is g_logv in
> > https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gmessages.c#L1291 -
> > so the code
Stuart Henderson wrote:
> > I've looked into fexecve() numerous times and I just cannot for the life
> > of me see how to avoid it becoming a component of attack methodology.
> >
> > The people who invented must be completely unaware of the dangerous
> > tooling this brings to the table.
> >
>
Christian Weisgerber wrote:
e> Theo Buehler:
>
> > devel/p5-IO-AIO
> > (?) strange mix of perl + m4
>
> The m4 part are just autoconf macros that are included by the
> top-level configure.ac. I looked over this and the syscalls are
> Linux-specific and behind #ifdef guards. On OpenBSD this
Stuart Henderson wrote:
> This port is broken; doesn't work with our Perl version. 4.79 needs
> a patch to avoid segfaults because we don't have fexecve() and with
> that fixed still doesn't work (same errors as 4.75).
I've looked into fexecve() numerous times and I just cannot for the life
of m
The question remains: why the upstream doing that.
Sometihng is missing here, and it may not just be mechanical.
Klemens Nanni wrote:
> Still waiting for pkg_add and then my build to finish, but the idea is
>
> - make the existing maros NO-OPs, align with spaces to make it obvious
> - remove
Josh Elsasser wrote:
> On Fri, Jan 27, 2023 at 05:02:33PM +0100, Christian Weisgerber wrote:
> > lang/sbcl will not work with x-only.
> >
> > I took another look at the warnings about data directives in .text.
> > In runtime/x86-64-assem.S we have snippets like these:
> >
> > GNAME(fun_end_brea
So there is an approach which can be taken for these big chunks, which
I came up with yesterday.
Put them into .openbsd.mutable section.
At program startup they will be RW, so Immediately mprotect)
PROT_EXEC|PROT_READ, and if you feel like it use mimmutable() also,
which they would have been if s
Theo Buehler wrote:
> On Sat, Jan 21, 2023 at 05:36:17PM +0100, Volker Schlecht wrote:
> > Here's a patch that builds node without USE_NOEXECONLY and without those
> > warnings, producing a working binary on amd64 ... I'm starting builds on
> > i386 and arm64, but since I'm not sure I understand
Stuart Henderson wrote:
> On 2023/01/21 17:36, Volker Schlecht wrote:
> >
> >
> > On 1/19/23 22:56, Theo Buehler wrote:
> >
> > > The trick to apply such patches is to add .diff to the
> > > github link.
>
> Or .patch, then you get a nice header to paste into the top of
> the patch file too.
onatinadr...@tutanota.com wrote:
> I have no intention to disable unveil permanently. I was just trying
> to solve a bug.
But it does not solve a bug.
It does not even identify the bugs.
If you really wanted to try to act like a developer, you would grab a
huge piece of disk and ktrace -di the
At some point you have to realize two things
- the restrictions we added to browsers inside are *intentional*
to reduce access outside of their general usage, in particular
restrictions inside your home directory
- But some libraries and applications you are trying to use are
designed to vi
> makedepend: error: out of space: increase MAXFILES
Software that demands infinite resources and will not accept and cope
with failure -- including transient and temporary failure -- on
shared-resource machines, is utterly offensive. Go back to your
one-program-at-time VIC-20 please.
How about we delete LD_PRELOAD support from ld.so?
This concept of extending programs underneath is utterly retarded,
because it is fragile in precisely this way, and there is absolutely
nothing we can or should do to help it work.
Caspar Schutijser wrote:
> Hi all,
>
> Using socksify (from t
1 - 100 of 487 matches
Mail list logo
