I think we should go with Josh's original diff, without the commentary.
I'll commit.
As for the entries not documented in the manual page, the process goes
like this:
1. grep the tree for the programs that use it
2. read kern_pledge.c or lower-level code to find out what operations
are permitt
> From: "Theo de Raadt"
> Date: Thu, 10 Jun 2021 16:11:57 -0600
>
> I would argue for deleting that code.
Here's the diff for that.
>
> A flag for el_set which *allows it* might work for me, but I anticipate
> this is a crazy feature that programs using the library would not expect,
> and the ri
Leon Fischer wrote:
> On the other hand, users could also bind it themselves in ~/.editrc and
> trigger pledge(2) violations in programs not designed for it. It won't
> be obvious to them why their shiny feature wouldn't work.
Let me explain the future.
Pledge is now almost 6 years old, and it
tls_config_set_ca_file(3) and tls_config_set_cert_file(3) do not just
set the file paths (like tls_config_set_ca_path(3) does), they do load
the given file into memory directly using tls_config_load_file().
This distinction is important because it means a later tls_connect(3)
will not do any file
I would argue for deleting that code.
A flag for el_set which *allows it* might work for me, but I anticipate
this is a crazy feature that programs using the library would not expect,
and the risks of abuse are clear.
Leon Fischer wrote:
> The editline(7) library has a little known feature: vi-
The editline(7) library has a little known feature: vi-histedit.
When invoked, the command creates a file in /tmp and spawns vi(1) to
edit it. This behavior is unaccounted for in the pledge(2) promises of
bc(1) and fsdb(8).
Steps to reproduce:
$ echo "bind -v" >> ~/.editrc
$ bc
Abort trap (core
Mike Larkin writes:
> Sorry for the delay. ok mlarkin@ with one comment below.
Committed. Fixed the comment to clarify the two expected message
types. Thanks.
-dv
Hi,
I have seen this crash trace on a 6.6 based system, but I think the
bug exists still in -current. It happened when an ixl(4) interface
was removed from trunk(4).
uvm_fault(0xfd8739dc6558, 0x0, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 81012a86 cs 8 rfl
On Thu, Jun 10, 2021 at 09:19:45AM -0400, Dave Voutila wrote:
>
> Still looking for an OK or feedback on the below. This is finishing work
> to fixes made previously to vmd(8)/vmctl(8) regarding vm
> stopping/running state corruption when using vmctl(8) to wait for a vm
> to stop.
>
Sorry for the
On Wed, Jun 09, 2021 at 10:35:48PM -0700, Mike Larkin wrote:
> On Thu, Jun 10, 2021 at 03:19:43PM +1000, Jonathan Gray wrote:
> > Ilya Voronin sent a diff to misc to limit MSR_INT_PEN_MSG use to
> > < AMD family 17h prompted by a problem with an AWS t3a instance.
> >
> > https://marc.info/?l=openbs
On Thu, Jun 10, 2021 at 01:28:36PM +0100, Stuart Henderson wrote:
> On 2021/06/10 13:05, Theo Buehler wrote:
> > On Thu, Jun 10, 2021 at 11:39:46AM +0100, Stuart Henderson wrote:
> > > I was just reminded of the Apple cert problem with GeoTrust Global CA
> > > and checked and they're using better i
Still looking for an OK or feedback on the below. This is finishing work
to fixes made previously to vmd(8)/vmctl(8) regarding vm
stopping/running state corruption when using vmctl(8) to wait for a vm
to stop.
Dave Voutila writes:
> ping
>
> Dave Voutila writes:
>
>> Dave Voutila writes:
>>
>>>
On 2021/06/10 13:05, Theo Buehler wrote:
> On Thu, Jun 10, 2021 at 11:39:46AM +0100, Stuart Henderson wrote:
> > I was just reminded of the Apple cert problem with GeoTrust Global CA
> > and checked and they're using better intermediates for api.push.apple.com
> > now. OK to sync up with Mozilla's
> Date: Wed, 9 Jun 2021 23:05:40 +0200
> From: Tobias Heider
>
> Hi,
>
> the diff below adds DT_FA_PROFILE and DT_FA_STATIC defines for arm64
> to skip the probe context frames.
>
> Here is how a typical arm64 stack trace looks with and without diff:
>
> dt_pcb_ring_get+0x130
> dt_prov_profile
On Thu, Jun 10, 2021 at 11:39:46AM +0100, Stuart Henderson wrote:
> I was just reminded of the Apple cert problem with GeoTrust Global CA
> and checked and they're using better intermediates for api.push.apple.com
> now. OK to sync up with Mozilla's CA bundle again, including removal
> of GeoTrust
I was just reminded of the Apple cert problem with GeoTrust Global CA
and checked and they're using better intermediates for api.push.apple.com
now. OK to sync up with Mozilla's CA bundle again, including removal
of GeoTrust Global CA?
Changes in the list first; diff below:
-AC Camerfirma S.A.
-
16 matches
Mail list logo
