On 3/13/14 2:39 AM, Loganaden Velvindron wrote:
> I'm not a mentor, but I'd be happy to help you in any way I can.
> You can send mails to tech@ for testing your diffs.
Any chance you'd like to review my bootloader patch from last month then?
http://marc.info/?l=openbsd-tech&m=139408992902933
I
On Thu, Mar 13, 2014 at 10:08 AM, Jean-Philippe Ouellet
wrote:
> On 3/12/14 11:15 PM, Loganaden Velvindron wrote:
>> I've read about the file vulnerability, and capsicumization also
>> came to mind. However, there was also a discussion when i was
>> playing with capsicum and openssh, about the lim
On 3/12/14 11:15 PM, Loganaden Velvindron wrote:
> I've read about the file vulnerability, and capsicumization also
> came to mind. However, there was also a discussion when i was
> playing with capsicum and openssh, about the limits of capsicum.
> Capsicum doesn't prevent DoS, and we still need rl
On Thu, Mar 13, 2014 at 1:01 AM, Jean-Philippe Ouellet
wrote:
> On 3/12/14 4:58 AM, tuchalia wrote:
>> Should l try to port also the Casper daemon to OpenBSD, or
>> only work in the kernel implementation?
>
> Based on more private mail, I figured it'd be a good idea to make what I
> plan to work
On Wed, Mar 12, 2014 at 10:49 PM, Jean-Philippe Ouellet
wrote:
> On 3/12/14 4:58 AM, tuchalia wrote:
>> Hi all,
>>
>> I'm really interested in this possibility of porting the Capsicum framework
>> to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or
>> only work in the kernel im
On Wed, Mar 12, 2014 at 11:09:14PM +0100, Ingo Schwarze wrote:
> I don't really like the warnx(3) call from the bye() ALRM handler
> either, but that's a separate matter.
Me neither.
Maybe something like this instead? (although maybe the done check should
be someplace else?)
Index: lock.c
==
Hi,
the analysis and the patch are correct.
Besides, even though hi() does not contain anything that isn't
signal safe on OpenBSD, it is still nice to have that lengthy
function no longer be a signal handler.
I don't really like the warnx(3) call from the bye() ALRM handler
either, but that's a
The recent "inteldrm suspend/resume regression" thread pointed out
that suspend/resume was quite horribly broken and only worked somewhat
if you didn't heavily use the "3D" acceleration stuff. Here's a diff
that should fix most of the problems, by making sure userland programs
are properly blocked
On 3/12/14 4:58 AM, tuchalia wrote:
> Should l try to port also the Casper daemon to OpenBSD, or
> only work in the kernel implementation?
Based on more private mail, I figured it'd be a good idea to make what I
plan to work on public in case there are others interested so we can
avoid stepping o
Hello,
When lock(1) receives SIGINT, SIGQUIT, or SIGTSTP, it calls hi()
twice, once because it's the signal handler, and once after
readpassphrase() errors because the read was interrupted.
Since hi() gets called when readpassphrase() fails anyway, this
patch ignores the signals instead of using
Em 12-03-2014 16:33, sven falempin escreveu:
> On Wed, Mar 12, 2014 at 2:01 PM, Stuart Henderson wrote:
>> On 2014/03/12 13:47, sven falempin wrote:
You might do better with qemu socket network devices (or the L2TPv3
support that was recently added to qemu head), which should allow a
>>>
On Wed, Mar 12, 2014 at 2:01 PM, Stuart Henderson wrote:
> On 2014/03/12 13:47, sven falempin wrote:
>> > You might do better with qemu socket network devices (or the L2TPv3
>> > support that was recently added to qemu head), which should allow a
>> > "direct" connection between the virtual interf
On 3/12/14 4:58 AM, tuchalia wrote:
> Also, do we have any IRC channel to discuss al this?
I've been wondering about that too, although I was never really active
on any of the channels.
Mindcry is dead, subcult is mostly non-english, freenode and efnet are
mostly whiners. I vaguely remember some
On 3/12/14 4:58 AM, tuchalia wrote:
> Hi all,
>
> I'm really interested in this possibility of porting the Capsicum framework
> to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or
> only work in the kernel implementation?
>
> I've used Capsicum during the last summer, but I on
On 2014/03/12 13:47, sven falempin wrote:
> > You might do better with qemu socket network devices (or the L2TPv3
> > support that was recently added to qemu head), which should allow a
> > "direct" connection between the virtual interfaces, rather than using
> > a bridge device that exists outside
On Wed, Mar 12, 2014 at 11:44 AM, Stuart Henderson wrote:
> On 2014/03/12 10:41, sven falempin wrote:
>> Hello, does someone knows about this and how to fix it or workaround ?
>> Best Regards,
>>
>> >Synopsis: LACP TRUNK IS NOT WORKING AS EXPECTED
>> >Category: system
>> >Environment:
>>
Now that we have KMS, giving userland access to AGP through /dev/agp0
is no longer necessary. As far as I can tell none of the drivers we
ship in xenocara still use this. A possible exception is Intel's
first generation of integrated graphics (the i810 and i815 chipsets),
but I believe support fo
On 2014/03/12 10:41, sven falempin wrote:
> Hello, does someone knows about this and how to fix it or workaround ?
> Best Regards,
>
> >Synopsis: LACP TRUNK IS NOT WORKING AS EXPECTED
> >Category: system
> >Environment:
> System : OpenBSD 5.4
> Details : OpenBSD
Hello, does someone knows about this and how to fix it or workaround ?
Best Regards,
>Synopsis: LACP TRUNK IS NOT WORKING AS EXPECTED
>Category: system
>Environment:
System : OpenBSD 5.4
Details : OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
dera...@i
On 11 March 2014 23:43, Lawrence Teo wrote:
> This changes a few malloc()+memset() calls to calloc().
>
> OK?
>
>
> Index: gencode.c
> ===
> RCS file: /cvs/src/lib/libpcap/gencode.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 gen
On Wed, Mar 12, 2014 at 12:58 PM, tuchalia wrote:
> Hi all,
>
> I'm really interested in this possibility of porting the Capsicum framework
That's awesome !
> to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or
> only work in the kernel implementation?
Capsicum is a huge pro
perhaps, you should try to send a message to the project mentors, as
pointed out in the foundation/gsoc page:
http://www.openbsdfoundation.org/gsoc2014.html#capsicum
-a
On Wed, Mar 12, 2014 at 09:58:24AM +0100, tuchalia wrote:
> Hi all,
>
> I'm really interested in this possibility of porting
Hi all,
I'm really interested in this possibility of porting the Capsicum framework
to OpenBSD. Should l try to port also the Casper daemon to OpenBSD, or
only work in the kernel implementation?
I've used Capsicum during the last summer, but I only worked with the
syscall API, that is, no Casper
On Mon, Feb 17, 2014 at 12:02:15AM -0800, Philip Guenther wrote:
> On Sun, Feb 16, 2014 at 2:57 AM, Mark Kettenis
> wrote:
> > This adds support for a few more instruction patterns that are
> > apparentl needed by gcc 4.8. Taken from binutils 2.17. Not sure if
> > adding NoRex64 to the existing
24 matches
Mail list logo
