Here's my take at documenting the missing pledge promises in pledge.2
and placing them in a reasonable order with the others. Each of these
just enabled various ioctl or sysctl interfaces.
I'm unhappy with the explanation for drm, but don't know how to
explain the purpose of these ioctls, and cou
On Wed, Jun 09, 2021 at 06:01:59PM +, Klemens Nanni wrote:
> > There were three promises which are not documented in pledge(2):
> > disklabel, drm, and vmm. I've just left these at the end.
> Sounds good.
Are the undocumented promises intentional, or bugs in pledge(2)?
> Either way, a small
I was surprised to find that ps -O pledge did not list the pledge
promise names in the same order as the pledge(2) manpage. Besides
lacking consistency, this was also making it difficult to quickly find
which promises are not granted to a process which requires most of
them (e.g. chrome).
I figur
On Fri, Mar 26, 2021 at 12:22:49PM +0100, Klemens Nanni wrote:
> On Fri, Mar 26, 2021 at 07:17:26AM -0400, Dave Voutila wrote:
> > There was a follow-up diff changing some includes, but I'd like to keep
> > that cleanup separate. As i mentioned in the other reply, this change
> > works for me and I
On Thu, Apr 01, 2021 at 06:43:30PM -0500, Scott Cheloha wrote:
> On Thu, Apr 01, 2021 at 03:41:24PM -0400, Josh Rickmar wrote:
> > On Thu, Apr 01, 2021 at 03:22:00PM -0400, Josh Rickmar wrote:
> > > On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote:
> > > &
On Thu, Apr 01, 2021 at 03:22:00PM -0400, Josh Rickmar wrote:
> On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote:
> > On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote:
> > > > Feel free to share your raw data.
> > >
> > > Also incl
# dmesg | egrep -i 'tsc|clocksource'
>
> 2. Second, is there a more recent BIOS revision for this machine?
>Perhaps (assuming this is in fact a BIOS problem) Lenovo is aware
> of it and has fixed it. This is unlikely but worth a look.
>
> Long versio
On Thu, Mar 25, 2021 at 05:28:54PM -0500, Scott Cheloha wrote:
> Feel free to share your raw data.
Attached.
e485skews.tgz
Description: application/tar-gz
On Mon, Feb 01, 2021 at 08:18:53PM +, Josh Rickmar wrote:
> The kern.somaxconn sysctl was previously permitted under the inet
> pledge, which allowed pledged Go applications to listen on AF_INET and
> AF_INET6 domains.
>
> https://marc.info/?l=openbsd-tech&m=15806959
On Thu, Mar 25, 2021 at 01:18:04PM -0500, Scott Cheloha wrote:
> > On Mar 24, 2021, at 8:29 AM, Josh Rickmar wrote:
> >
> > On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote:
> >> Hi,
> >>
> >> I hit a problem which is caused by goin
On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> I hit a problem which is caused by going back of monotonic time. It
> happens on hosts on VMware ESXi.
>
> I wrote the program which repeats the problem.
>
> % cc -o monotime monotime.c -lpthread
> % ./monotime
> 194
On Fri, Mar 19, 2021 at 03:26:46PM -0400, Josh Rickmar wrote:
> I got some emails off list asking about the removal and if it affected
> them. Worth adding to current.html?
sorry for the noise, missed a
diff 0d7807046bcfacd3249f4c62031ac970d9b42ace /home/jrick/ww
I got some emails off list asking about the removal and if it affected
them. Worth adding to current.html?
diff 0d7807046bcfacd3249f4c62031ac970d9b42ace /home/jrick/www
blob - 9452b3672627fb39fa0c7ec17a17e08f57406afa
file + faq/current.html
--- faq/current.html
+++ faq/current.html
@@ -274,6 +274
On Fri, Mar 19, 2021 at 10:29:10AM -0400, Josh Rickmar wrote:
> Here's an updated version of the patch I had originally posted to
> bugs@ adding support for reading gzipped kernels (needed to boot amd64
> bsd.rd without manually decompressing first), now that the support for
>
Here's an updated version of the patch I had originally posted to
bugs@ adding support for reading gzipped kernels (needed to boot amd64
bsd.rd without manually decompressing first), now that the support for
booting a kernel discovered on a ffs filesystem in the image file is
removed.
I've kept th
The compress(3) family of utility functions return and operate on
gzFile, a typedef for void*. The extra pointer to this gzFile in
grep(1) can be removed. Other uses of these compress(3) functions in
tree (spamd, mandoc, smtpd) do not use the extra pointer.
diff 5fb603068396a80293d0f411297e6119a
David Gwynne wrote:
> I'd vote that way, but I am biased.
>
> Some test reports that it's working well for people would be nice too.=
This is working well in my testing as a replacement for bridge/vether
usage as told in the virtualization FAQ, but I was unaware that the
vport interface needed to
The kern.somaxconn sysctl was previously permitted under the inet
pledge, which allowed pledged Go applications to listen on AF_INET and
AF_INET6 domains.
https://marc.info/?l=openbsd-tech&m=158069595809463&w=2
https://marc.info/?l=openbsd-cvs&m=158081099810301&w=2
But Go will also read this sysc
On Wed, Dec 16, 2020 at 03:40:41PM -0700, Theo de Raadt wrote:
> the term "suid" includes setgid executables... so your conclusions
> are way wrong.
>
> Heck, you should give it a try. Good luck logging in afterwards.
Indeed, please disregard.
Playing around with find ${dir} -type f -perm -04000, I see that there
are no longer any more suid executables placed in /usr/libexec or
/usr/X11R6, so I believe these can be removed from install.sub. Based
on the comments, this hasn't been touched in a long while.
diff bfe4739adb21458b6ca3fc690d
Some email accounts use account names that include the @host portion,
and this broke the server and credentials parsing in smtp(1). Sometimes
I see these @ characters encoded as %40, but smtp(1) was not decoding
these url escape sequences before base64 encoding and talking with the
server.
Search
21 matches
Mail list logo
