Re: [bugfix] xterm(1) needs "cpath" pledge(2)

On Sun, Jul 29, 2018 at 07:28:19AM +0200, Sebastien Marie wrote: > Hi, > > First, thanks to (trying) to search for solve the problem you encountered. > > On Sat, Jul 28, 2018 at 10:08:04PM +0300, Leonid Bobrov wrote: > > Hi! > > > > Like I said yesterday, I don't know how to reproduce this bug,

Re: [bugfix] xterm(1) needs "cpath" pledge(2)

On Sun, Jul 29 2018 07:28:19 +0200, Sebastien Marie wrote: > personally, I like to know that xterm is unable to create a file. At least this feature will create files (accessible through the context menu through ctrl-left click): Print-All Immediately (resource print-immediate) Inv

[diff] acme-client - improve printing of alt names (with -n)

Simple diff so that instead of printing ... alternative names { httpd.example.com, secure.example.com} ... we get ... alternative names { httpd.example.com, secure.example.com } ... Ross Index: parse.y ===

Re: [bugfix] xterm(1) needs "cpath" pledge(2)

Hi, First, thanks to (trying) to search for solve the problem you encountered. On Sat, Jul 28, 2018 at 10:08:04PM +0300, Leonid Bobrov wrote: > Hi! > > Like I said yesterday, I don't know how to reproduce this bug, it just > happened to me and I got this dmesg(1): > xterm[90461]: pledge "cpath",

Re: [diff] acme-client - remove NULL checks before _free() calls

On Sat, Jul 28, 2018 at 05:09:50PM +0200, Theo Buehler wrote: >[...] > I'll commit this tomorrow if no-one commits it earlier with my ok. > > > [Note that the behaviour of X509_REQ_free(NULL) and X509_NAME_free(NULL) > > is not documented in the man pages, so those calls in keyproc.c are not > > m

Re: rasops(9): Remove rasops4 functions?

On Tue, Jul 24, 2018 at 05:42:32PM +0200, Mark Kettenis wrote: > > Date: Sun, 22 Jul 2018 15:12:09 +0200 > > From: Frederic Cambus > > > > Hi tech@, > > > > Nothing uses the rasops4 (4-bit color depth) functions anymore. > > > > It seems unlikely that any future new platform will ever need them

Re: [bugfix] xterm(1) needs "cpath" pledge(2)

I didn't realize you were using coloured cursors. You make me sad. You don't know what the bug is. You don't know how to reproduce it. You don't have a plausible call path. You grep, and yet don't dig deeper to see if that code you find is initialization phase or activated later during runtime

[bugfix] xterm(1) needs "cpath" pledge(2)

Hi! Like I said yesterday, I don't know how to reproduce this bug, it just happened to me and I got this dmesg(1): xterm[90461]: pledge "cpath", syscall 5 Right now I quickly grep(1)'ed xterm(1)'s source code: mazocomp$ egrep "mkdir\(|unlink\(|rmdir\(" -R . -n ./misc.c:760: && mkdir(fil

Increase the number of supported rdomains supported in the generic OpenBSD Kernels

Hello, I was wondering what is the impact of increasing the number of VRFs / Rdomains that the generic kernels are capable of supporting, I believe it is a constant determined prior to compile, I was just wondering if it could be increased from 256 to 65536 ? what is the impact on kernel memory u

unveil: unused ps_uvactive in process

Hi, The field ps_uvactive in `struct process` is unused. Generally, for checking if unveil is active, checks are done on (ps_uvvcount != 0) or (ps->ps_uvpaths != NULL). I assume the field is a left over from previous developpment. The kernel still build fine without it. Thanks. -- Sebastien M

Re: unveil(2) man page clarification about path type (is a directory or not)

On Sat, Jul 28, 2018 at 09:16:39AM +0200, Sebastien Marie wrote: > Hi, > > I think some reorganisation in unveil(2) man page could be good for > comprehension. > > The diff belows makes the man page follow the structure for paragraphs: > > DESCRIPTION > ??1. global description (unveil removes

Chromium/Iridium Buildbot for -stable?

landry@ provides a buildbot for mozill-firefox but core development is focused on privilege separation: pledge(2), unveil(2), Chromium/Iridium are able to utilize privilege separation while mozilla-firefox does not. This raises questions about a buildbot for Chromium and/or Iridium. Would it be

Re: Add PCIe requester ID API

On Sat, Jul 28, 2018 at 01:46:07PM +0200, Mark Kettenis wrote: > For some arm64-related interrupt controller work I need to be able to > compose a PCIe requester ID. Since this is a generic PCIe concept > that might be useful on other architectures (for example for IOMMU > support), I propose to a

Re: [diff] acme-client - remove NULL checks before _free() calls

On Sat, Jul 28, 2018 at 10:56:08PM +1000, Ross L Richardson wrote: > > The diff below just removes NULL checks before various LibreSSL *_free() > calls, on the assumption that that's the preferred usage where it's > documented that *_free(NULL) is safe. Thanks, diff looks good. I'll commit this

[diff] acme-client - remove NULL checks before _free() calls

The diff below just removes NULL checks before various LibreSSL *_free() calls, on the assumption that that's the preferred usage where it's documented that *_free(NULL) is safe. [Note that the behaviour of X509_REQ_free(NULL) and X509_NAME_free(NULL) is not documented in the man pages, so those

Add PCIe requester ID API

For some arm64-related interrupt controller work I need to be able to compose a PCIe requester ID. Since this is a generic PCIe concept that might be useful on other architectures (for example for IOMMU support), I propose to add a function to the MI PCI code. ok? Index: dev/pci/pci.c =

unveil(2) man page clarification about path type (is a directory or not)

Hi, I think some reorganisation in unveil(2) man page could be good for comprehension. The diff belows makes the man page follow the structure for paragraphs: DESCRIPTION §1. global description (unveil removes visibility of the entire filesystem...) §2. unveil locking §3. flags description