Index: Makefile
===================================================================
RCS file: /cvs/ports/wayland/foot/Makefile,v
diff -u -p -r1.13 Makefile
--- Makefile 1 Nov 2025 07:42:32 -0000 1.13
+++ Makefile 12 Mar 2026 18:10:31 -0000
@@ -1,7 +1,7 @@
COMMENT = fast, lightweight and minimalistic Wayland terminal emulator
DISTNAME = foot-${V}
-V = 1.25.0
+V = 1.26.0
SITES = https://codeberg.org/dnkl/foot/archive/
DISTFILES = foot-{}${V}${EXTRACT_SUFX}
Index: distinfo
===================================================================
RCS file: /cvs/ports/wayland/foot/distinfo,v
diff -u -p -r1.8 distinfo
--- distinfo 1 Nov 2025 07:42:32 -0000 1.8
+++ distinfo 12 Mar 2026 18:10:31 -0000
@@ -1,2 +1,2 @@
-SHA256 (foot-1.25.0.tar.gz) = RCpC1Xbsct1Q8tP66opmQjCke6x53B6258kSXudsEw8=
-SIZE (foot-1.25.0.tar.gz) = 621078
+SHA256 (foot-1.26.0.tar.gz) = nvUQrcjwSkAcBP6oz86t1UiX9xItdak+i8vCcGTah28=
+SIZE (foot-1.26.0.tar.gz) = 1194812
Index: patches/patch-main_c
===================================================================
RCS file: /cvs/ports/wayland/foot/patches/patch-main_c,v
diff -u -p -r1.5 patch-main_c
--- patches/patch-main_c 31 Jul 2025 08:36:26 -0000 1.5
+++ patches/patch-main_c 12 Mar 2026 18:10:31 -0000
@@ -3,7 +3,7 @@ use NSIG for signal table
Index: main.c
--- main.c.orig
+++ main.c
-@@ -174,7 +174,7 @@ sanitize_signals(void)
+@@ -180,7 +180,7 @@ sanitize_signals(void)
struct sigaction dfl = {.sa_handler = SIG_DFL};
sigemptyset(&dfl.sa_mask);
Index: patches/patch-meson_build
===================================================================
RCS file: /cvs/ports/wayland/foot/patches/patch-meson_build,v
diff -u -p -r1.6 patch-meson_build
--- patches/patch-meson_build 31 Jul 2025 08:36:26 -0000 1.6
+++ patches/patch-meson_build 12 Mar 2026 18:10:31 -0000
@@ -12,7 +12,7 @@ Index: meson.build
libepoll = dependency('epoll-shim', required: false)
pixman = dependency('pixman-1')
wayland_protocols = dependency('wayland-protocols', version: '>=1.41',
-@@ -239,7 +239,8 @@ common = static_library(
+@@ -248,7 +248,8 @@ common = static_library(
'macros.h',
'xmalloc.c', 'xmalloc.h',
'xsnprintf.c', 'xsnprintf.h',
@@ -22,7 +22,7 @@ Index: meson.build
)
misc = static_library(
-@@ -249,6 +250,7 @@ misc = static_library(
+@@ -258,6 +259,7 @@ misc = static_library(
'misc.c', 'misc.h',
'uri.c', 'uri.h',
dependencies: [utf8proc],
@@ -30,7 +30,7 @@ Index: meson.build
link_with: [common]
)
-@@ -293,7 +295,7 @@ if get_option('b_pgo') == 'generate'
+@@ -302,7 +304,7 @@ if get_option('b_pgo') == 'generate'
'pgo',
'pgo/pgo.c',
wl_proto_src + wl_proto_headers,
@@ -39,7 +39,7 @@ Index: meson.build
link_with: pgolib,
)
endif
-@@ -327,7 +329,7 @@ executable(
+@@ -336,7 +338,7 @@ executable(
'wayland.c', 'wayland.h', 'shm-formats.h',
'xkbcommon-vmod.h',
srgb_funcs, wl_proto_src + wl_proto_headers, version,
Trivial update to the latest release of wayland/foot.
Tested running it with niri on amd64.
ok?
OpenBSD Mail Box
BTC:1BsNfN6m7xtT4PqDb9jJHnDDFBb38zS9Yi
Thursday, March 12, 2026
Re: www/ungoogled-chromium: configurable cdm pledges
Stuart Henderson <stu@spacehopper.org> wrote:
> On 2026/03/12 11:14, Theo de Raadt wrote:
> >
> > > Unveil config would be easier to work with if the file contents were
> > > _in addition_ to a compiled-in default. i.e. the binary already has what
> > > it knows is needed and you can open up some additional files/dirs if
> > > necessary.
> >
> > What do you mean "if" and "_in addition_".
> >
> > Because that is exactly how unveil works. More refined paths always create
> > enclaves inside enclaves, with the new permissions. If the paths as
> > previously specified paths, it replaces the previously specified path.
> >
> > I really don't see any reason to have these files user visible or editable.
>
> There are files/paths which are required by the software itself (which
> can be compiled-in),
Obviously.
Same as the pledges.
These unveil paths and these pledge promises are STRONGLY COUPLED with
code behaviours. This is easy to test. Go ahead delete 5 random lines
from an unveil file. Stuff breaks. Delete 1 word from a pledge file.
Stuff breaks. It is not logical to give *ROOT* the ability to change these
for chromium. In the same way, we don't have /etc/sed/unveil and /etc/sed/pledge
configuration files.
> and those required by the user or user's sysadmin.
Can you list the ones required by the user and the user's sysadmin?
But obviously not "the user", because these files are in /etc owned by root.
> The person compiling the package can't know that the user might need to
> use a browser to attach files in /some/nfsserver/docs via webmail, for
> example.
But the user cannot do that in /etc because the files are owned by root.
> On 2026/03/12 11:14, Theo de Raadt wrote:
> >
> > > Unveil config would be easier to work with if the file contents were
> > > _in addition_ to a compiled-in default. i.e. the binary already has what
> > > it knows is needed and you can open up some additional files/dirs if
> > > necessary.
> >
> > What do you mean "if" and "_in addition_".
> >
> > Because that is exactly how unveil works. More refined paths always create
> > enclaves inside enclaves, with the new permissions. If the paths as
> > previously specified paths, it replaces the previously specified path.
> >
> > I really don't see any reason to have these files user visible or editable.
>
> There are files/paths which are required by the software itself (which
> can be compiled-in),
Obviously.
Same as the pledges.
These unveil paths and these pledge promises are STRONGLY COUPLED with
code behaviours. This is easy to test. Go ahead delete 5 random lines
from an unveil file. Stuff breaks. Delete 1 word from a pledge file.
Stuff breaks. It is not logical to give *ROOT* the ability to change these
for chromium. In the same way, we don't have /etc/sed/unveil and /etc/sed/pledge
configuration files.
> and those required by the user or user's sysadmin.
Can you list the ones required by the user and the user's sysadmin?
But obviously not "the user", because these files are in /etc owned by root.
> The person compiling the package can't know that the user might need to
> use a browser to attach files in /some/nfsserver/docs via webmail, for
> example.
But the user cannot do that in /etc because the files are owned by root.
Subscribe to:
Comments (Atom)