On Mon, Jul 30, 2018 at 06:08:54PM +0200, Klemens Nanni wrote:
> These two just complicate the code. Let's defer checks whether an
> explicit mask has been specified to where it's actually set in host_*().
>
> My motivation is to reduce address family specific code and perhaps even
> merge `host_v
On Mon, Jul 30, 2018 at 06:20:21PM +0200, Mark Kettenis wrote:
> It seems that ARM SoC every vendor invents their own _HID/_CID for the
> their AHCI implementation. Instead of adding all of these to an ever
> growing list, we can match on _CLS instead which return the "PCI"
> class/subclass/interf
Hey,
A statement in the find(1) man page and a source comment in find.c are
outdated and incorrect.
The man page didn't mention that using -delete or -execdir prevents
-print from being assumed.
Similarly for a comment in find.c, but this didn't mention -delete,
-execdir, -ls or -print0.
(These
Some public ber functions sneaked in below the internal functions comment. Move
them up so the comment regains its former truthiness.
Ok?
Index: usr.bin/ldap/ber.c
===
RCS file: /cvs/src/usr.bin/ldap/ber.c,v
retrieving revision 1.14
Hey,
The man page for find(1) does not mention when the -exec primary
evaluates to true.
-exec utility ... ; evaluates to true when the utility exits with a
zero exit status, while -exec utility ... {} + always evaluates to true.
I have a patch below with my attempt at a description. I tried to
When a per-protocol attach function is called the given socket is not
yet reachable, so there's no need to lock it. So the diff below remove
the solock/sounlock dance and shows where the NET_LOCK() is required to
protect some specific global data structures.
I reordered the different blocks in al
unveil(2) is now enabled in -current.
For those who want to play along at home, here are some diffs which use
this in a variety of programs. Not all these diffs are correct or
complete yet. This is a learning experience. Based upon what we learn,
we may still change unveil(2) semantics slightly
+ for (i=0; flags[i].pledge != 0; i++)
+ if (ISSET(pledge_flags, flags[i].pledge)) {
+ SET(permissions, flags[i].unveil);
+ CLR(pledge_flags, flags[i].pledge);
+ }
Rather than iterating, can this be done as a direct look
On Mon, Jul 30, 2018 at 07:55:35AM -0600, Bob Beck wrote:
> yeah the latter will be the way to go
>
here it is.
Some notes:
- I changed flags definition from uint64_t to int
- I defined `static inline' the function that do the conversion from
pledge to unveil: having a function is more readable
On Mon, Jul 30, 2018 at 10:02:51AM -0600, Theo de Raadt wrote:
> Alexandre Ratchov wrote:
>
> > On Mon, Jul 30, 2018 at 07:56:00AM -0600, Theo de Raadt wrote:
> > > there are a lot of files in /dev ...
> > >
> > > can you make this tighter?
> > >
> >
> > Yes. I'm experimenting around this righ
Sorry, this time with the correct diff.
On 7/25/18 4:15 PM, Base Pr1me wrote:
Hi,
I discovered that the wrong server configuration is evaluated in the
server_read_http function. Only the first server in httpd.conf is checked. For
example, I have five servers setup in httpd.conf and the third se
It seems that ARM SoC every vendor invents their own _HID/_CID for the
their AHCI implementation. Instead of adding all of these to an ever
growing list, we can match on _CLS instead which return the "PCI"
class/subclass/interface that the device is compatible with.
This adds a define to pcireg.h
These two just complicate the code. Let's defer checks whether an
explicit mask has been specified to where it's actually set in host_*().
My motivation is to reduce address family specific code and perhaps even
merge `host_v4()' and `host_v6()' eventually.
Feedback? OK?
Index: pfctl_parser.c
==
Alexandre Ratchov wrote:
> On Mon, Jul 30, 2018 at 07:56:00AM -0600, Theo de Raadt wrote:
> > there are a lot of files in /dev ...
> >
> > can you make this tighter?
> >
>
> Yes. I'm experimenting around this right now. I'm looking at the
> following possibilities:
>
> (1) during initializati
On Mon, Jul 30, 2018 at 07:56:00AM -0600, Theo de Raadt wrote:
> there are a lot of files in /dev ...
>
> can you make this tighter?
>
Yes. I'm experimenting around this right now. I'm looking at the
following possibilities:
(1) during initialization, parse device names to determine paths, then
there are a lot of files in /dev ...
can you make this tighter?
Alexandre Ratchov wrote:
> A trivial diff for the sndiod "device helper" process. All this
> process does is to open the device and pass it to the main process. So
> it can be restricted to /dev.
>
> The other sndiod process has n
yeah the latter will be the way to go
On Mon, Jul 30, 2018 at 06:02 Sebastien Marie wrote:
> Hi,
>
> I think unveil_flagmatch() isn't complete and/or has not the right
> semantic.
>
> A bit of internals for starting (I will speak about ni_pledge, people
> that know what it is and how it works wi
> Date: Mon, 30 Jul 2018 15:09:58 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> Here is a diff to display color depth alongside resolution when
> attaching simplefb(4).
>
> Compile tested only, the only arm64 device I own is headless.
>
> Comments? OK?
ok kettenis@
> Index: sys/dev/fdt/sim
Hi tech@,
Here is a diff to display color depth alongside resolution when
attaching simplefb(4).
Compile tested only, the only arm64 device I own is headless.
Comments? OK?
Index: sys/dev/fdt/simplefb.c
===
RCS file: /cvs/src/sys/d
[The non-style(9) parts of this were sent previously off-list to a few.]
The diff:
- fixes error messages
- one copy/pasto
- two with old(?) syntax "use" rather than "sign with"
- applies some style(9)
- lots of "return (x);" ==> "return x;"
- a few "if (x)" ==> "if
Hi,
I think unveil_flagmatch() isn't complete and/or has not the right
semantic.
A bit of internals for starting (I will speak about ni_pledge, people
that know what it is and how it works with pledge/unveil could go to
"what is the problem" part).
unveil(2) works with the syscall annotation int
On Mon, Jul 30, 2018 at 11:26:16AM +0200, Alexandre Ratchov wrote:
>
> The other sndiod process has neither of rpath, wpath, cpath, or exec,
> so it doesn't need unveil, right?
I am just replying for this aspect of unveil/pledge.
Yes, if the process doesn't have such promises, calling unveil(2)
Hi,
thanks for your diff.
Ross L Richardson(open...@rlr.id.au) on 2018.07.30 11:25:08 +1000:
>
> [This diff is very similar to one I sent previously off-list to a few.]
>
> Just some style(9) and simple cleanup:
> - order getopt string and switch cases
commited, left f: at the end so its the s
A trivial diff for the sndiod "device helper" process. All this
process does is to open the device and pass it to the main process. So
it can be restricted to /dev.
The other sndiod process has neither of rpath, wpath, cpath, or exec,
so it doesn't need unveil, right?
Index: sndiod.c
===
works for me[tm]
OK?
NSD versions 4.1.22 and before are vulnerable in comparing TSIG
information and this can be used to discover a TSIG secret.
NSD uses TSIG to protect zone transfers. The TSIG code uses a secret
key to pr
25 matches
Mail list logo
