Yeah. It most likely won't go in. From past experience and advice, not
necessarily just from a perceived lack of merit.
However, many, if not all of the arguments are based upon non-facts and
misconceptions from earlier submissions or just not understanding what the
software is doing.
The only re
Ok to remove.
--
Gabriel
Okan Demirmen writes:
> Hi,
>
> I think we've (or at least I have) mused about this for a while; a
> recent mail reminded me that this feature should go - a window manager
> doesn't need to parse the ssh known_hosts file for a menu; there are
> better tools for this.
>
i...@b3zdna.net wrote:
> > Eventually there will protocol or text side bug in xterm, and someone
> > will figure out ways to escalate beyond our other mitigations. Rather
> > than forcing them to operate inside an uncomfortable less-than-POSIX
> > pledge+unveil environment, they can reuse a simpl
> Eventually there will protocol or text side bug in xterm, and someone
> will figure out ways to escalate beyond our other mitigations. Rather
> than forcing them to operate inside an uncomfortable less-than-POSIX
> pledge+unveil environment, they can reuse a simple 1996-era shell-egg to
> execve
I’m not trying to be rude, but you don’t realize what’s going on here:
uuu is a bitmask:
‘uuu’ (or (1 << bits)-1 ) in “ret = rand_holder & uuu;“ , only puts the
lower ‘bit’ quantity of bits of rand_holder into ret, then it right shifts
rand_holder afterward to trash them every time in the loop wh
Just tested this patch and confirm it works as expected. Is there any
plan to add it to cwm?
--
Gabriel
i...@b3zdna.net wrote:
> For one me; I use it to send highlighted text in the terminal to an
> external program. This highlighted text could be a relative path to be
> opened by the external program and thus requires a cwd.
But your xterm is less secure.
Eventually there will protocol or text si
> Having looked into this, I think "exec-formatted" and "exec-selectable".
> are the kind of mis-designed anti-security features I don't want in xterm
Fair enough. If this feature is already capable of circumventing the
system security then I see why adding them in might not be a good idea.
ig0r
> There is so much regret in this feature. xterm is supposed to be as
> secure as possible so why does it need to inspect all the processes
> in the system (that is what this feature gives xterm, as soon as you
> pledge "ps").
I don't see any other way to get xterm's cwd. If there's a way to do s
Having looked into this, I think "exec-formatted" and "exec-selectable".
are the kind of mis-designed anti-security features I don't want in xterm
The idea of this is very much against the idea of priv-sep or priv-drop.
If a command is supposed to be capable of starting another fresh command
at an
On Sun, May 15, 2022 at 08:40:19PM -0500, Luke Small wrote:
> https://marc.info/?l=openbsd-tech&m=165259528425835&w=2
>
> This one (which is strongly based upon my first of two versions) which I
> submitted after Guenther correctly trashed version 2, doesn’t reuse any
> part of the sample. It picks
https://marc.info/?l=openbsd-tech&m=165259528425835&w=2
This one (which is strongly based upon my first of two versions) which I
submitted after Guenther correctly trashed version 2, doesn’t reuse any
part of the sample. It picks up a clean new bitfield upon failure.
I think Guenther didn’t, perh
There is so much regret in this feature. xterm is supposed to be as
secure as possible so why does it need to inspect all the processes
in the system (that is what this feature gives xterm, as soon as you
pledge "ps").
How about if xterm wasn't capable of doing that? Is it much of a loss?
Who is
The current implimintation of ProcGetCWD relies on procfs. The following
patch uses sysctl to instead retrieve the current working directory.
This enables the use of exec-formatted xterm function on a path relative
to the terminal's current working directory.
ig0r < ig0r [at] b3zdna [dot] net >
On Sat, 14 May 2022, Luke Small wrote:
> Look at my code. I don’t even use a modulus operator. I perform hit and
> miss with a random bitstream.
>
> How can I have a bias of something I don’t do? I return a bitstream which
> meets the parameters of being a value less than the upper bound. Much li
On Sun, 15 May 2022, Luke Small wrote:
> Do I really have to use specific terminology to make a point?
>
> I'm not educated enough on chacha20 enough to know whether, like I
> pointed out, whether choosing 5 bits from the middle of (or even from
> the tail end of one and the beginning of another)
Do I really have to use specific terminology to make a point?
I'm not educated enough on chacha20 enough to know whether, like I pointed
out, whether choosing 5 bits from the middle of (or even from the tail end
of one and the beginning of another) 32 bit pseudorandom cipher is
"correct."
...corr
On Sun, 15 May 2022, Luke Small wrote:
> The current implementation is nothing more than a naive arc4random() %
> upper_bound which trashes initial arc4random() calls it doesn’t like, then
> transforms over a desired modulus. The whole transformation by modulus of
> perfectly decent random data see
On Sun, May 15, 2022 at 08:19:47PM +1000, David Gwynne wrote:
> this is basically the same as what i did for in_pcbselsrc, and
> completely mechanical. im too tired to figure out if there's a smarter
> way to do it.
>
> lightly tested, and more eyes are welcome because of the tiredness
> thing.
O
Errata patches for kqueue in the kernel and asn1 in libcrypto have
been released for OpenBSD 7.1. Errata patches for pppoe in the
kernel have been released for OpenBSD 7.1 and 7.0.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches
The current implementation is nothing more than a naive arc4random() %
upper_bound which trashes initial arc4random() calls it doesn’t like, then
transforms over a desired modulus. The whole transformation by modulus of
perfectly decent random data seems so awkward. It’s not like it is used as
some
On 2022-05-15, Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Sat, 14 May 2022 20:23:39 -0400
> >
> > The cpu hz sensor is more accurate and updates faster than than the value
> > currently used for hw.cpuspeed. So return that value (scaled).
> >
> > This doesn't set cpuspeed directly be
On Sun, May 15, 2022 at 08:57:09AM -0300, Crystal Kolipe wrote:
> On Sun, May 15, 2022 at 11:44:29AM +0200, Otto Moerbeek wrote:
> > On Sun, May 15, 2022 at 04:27:30AM -0500, Luke Small wrote:
> > > How did someone prove the current implementation was cryptographically
> > > sound? Did they run ma
On Sun, May 15, 2022 at 11:44:29AM +0200, Otto Moerbeek wrote:
> On Sun, May 15, 2022 at 04:27:30AM -0500, Luke Small wrote:
> > How did someone prove the current implementation was cryptographically
> > sound? Did they run massive simulations which ran the gamut of the uint32_t
> > range which dem
Random generators have been analyzed for years.
Pick up "Concrete mathematics" by Don E. Knuth, read it, then come back
with actual science.
this is basically the same as what i did for in_pcbselsrc, and
completely mechanical. im too tired to figure out if there's a smarter
way to do it.
lightly tested, and more eyes are welcome because of the tiredness
thing.
Index: in6_pcb.c
==
On Sun, May 15, 2022 at 04:27:30AM -0500, Luke Small wrote:
> I have a feeling that making it threadsafe under any quantity of threads
> and still perform is likely not feasible, but if I could; or if making a
> nonthreadsafe variant was possible:
>
> Creating a mathematical proof that somehow is
I have a feeling that making it threadsafe under any quantity of threads
and still perform is likely not feasible, but if I could; or if making a
nonthreadsafe variant was possible:
Creating a mathematical proof that somehow is “simple and probably correct”
enough, would be an impossible task even
On Sun, May 15, 2022 at 10:35:43AM +0200, Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Sat, 14 May 2022 20:23:39 -0400
> >
> > The cpu hz sensor is more accurate and updates faster than than the value
> > currently used for hw.cpuspeed. So return that value (scaled).
> >
> > This doesn
> From: "Ted Unangst"
> Date: Sat, 14 May 2022 20:23:39 -0400
>
> The cpu hz sensor is more accurate and updates faster than than the value
> currently used for hw.cpuspeed. So return that value (scaled).
>
> This doesn't set cpuspeed directly because the acpi does that and it's hard
> to create
On Sun, May 15, 2022 at 01:12:28AM -0500, Luke Small wrote:
> This is version 1, which I was pretty sure was secure.
>
> I revamped it with a few features and implanted the binary search for 'bit'
>
> in most cases, which aren't intentionally worst-case, it's pretty darned
> fast!
>
> This is a
31 matches
Mail list logo
