[PATCH] FTP as an install method is no more

2015-06-04 Thread Raf Czlonka
Hi all, I think I got the most obvious ones but there might still be other ones scattered among the web pages. I'm not entirely sure how does that leave the exact wording of 'ftp.html' in terms of "Download via HTTP/FTP", etc. vs. "Install via ..." so I left it unchanged for now. There's also th

Re: rtwn(4) rtl8192ce

2015-06-04 Thread Stefan Sperling
On Thu, Jun 04, 2015 at 04:13:37PM -0700, Philip Guenther wrote: > On Thu, Jun 4, 2015 at 4:01 PM, Stefan Sperling wrote: > > I'm looking for someone who has an rtl8192ce wifi card and would > > like to test the new rtwn(4) driver with it. > > Any hope for 8192SE? > > "Realtek 8192SE" rev 0x10 a

Re: rtwn(4) rtl8192ce

2015-06-04 Thread Theo de Raadt
> On Thu, Jun 4, 2015 at 4:01 PM, Stefan Sperling wrote: > > I'm looking for someone who has an rtl8192ce wifi card and would > > like to test the new rtwn(4) driver with it. > > Any hope for 8192SE? > > "Realtek 8192SE" rev 0x10 at pci2 dev 0 function 0 not configured It's a one liner for anyo

Re: rtwn(4) rtl8192ce

2015-06-04 Thread Philip Guenther
On Thu, Jun 4, 2015 at 4:01 PM, Stefan Sperling wrote: > I'm looking for someone who has an rtl8192ce wifi card and would > like to test the new rtwn(4) driver with it. Any hope for 8192SE? "Realtek 8192SE" rev 0x10 at pci2 dev 0 function 0 not configured Philip

rtwn(4) rtl8192ce

2015-06-04 Thread Stefan Sperling
I'm looking for someone who has an rtl8192ce wifi card and would like to test the new rtwn(4) driver with it. Index: if_rtwn.c === RCS file: /cvs/src/sys/dev/pci/if_rtwn.c,v retrieving revision 1.1 diff -u -p -r1.1 if_rtwn.c --- if_rt

Re: file(1): is this reasonable?

2015-06-04 Thread Nicholas Marriott
Alright. I will apply the file(1) bit so it works if already systraced but you will need to go to the ports guys to get the policy opened up. Thanks On Thu, Jun 04, 2015 at 03:44:43PM -0700, patrick keshishian wrote: > On Thu, Jun 04, 2015 at 11:37:33PM +0100, Nicholas Marriott wrote: > > file s

Re: file(1): is this reasonable?

2015-06-04 Thread patrick keshishian
On Thu, Jun 04, 2015 at 11:37:33PM +0100, Nicholas Marriott wrote: > file shouldn't need chflagsat? Yes. The chflagsat was for cp(1). I'm just combining the diff from earlier (sent to ports[1]), so it does not get lost. Thanks, --patrick [1] http://marc.info/?l=openbsd-ports&m=143340587303885&w=

Re: file(1): is this reasonable?

2015-06-04 Thread Nicholas Marriott
file shouldn't need chflagsat? Otherwise I think this is fine. On Thu, Jun 04, 2015 at 03:29:06PM -0700, patrick keshishian wrote: > On Thu, Jun 04, 2015 at 11:06:38PM +0100, Nicholas Marriott wrote: > > /usr/ports/infrastructure/db/systrace.filter has these: > > > > native-recvmsg: per

Re: file(1): is this reasonable?

2015-06-04 Thread patrick keshishian
On Thu, Jun 04, 2015 at 11:06:38PM +0100, Nicholas Marriott wrote: > /usr/ports/infrastructure/db/systrace.filter has these: > > native-recvmsg: permit > native-sendmsg: sockaddr match "/tmp" then permit > native-sendmsg: sockaddr match "/var/tmp" then permit > native-s

Re: file(1): is this reasonable?

2015-06-04 Thread Nicholas Marriott
/usr/ports/infrastructure/db/systrace.filter has these: native-recvmsg: permit native-sendmsg: sockaddr match "/tmp" then permit native-sendmsg: sockaddr match "/var/tmp" then permit native-sendmsg: sockaddr match "/tmp" then permit native-sendmsg: sockaddr

Re: file(1): is this reasonable?

2015-06-04 Thread Nicholas Marriott
Hi On Thu, Jun 04, 2015 at 03:39:45PM -0600, Theo de Raadt wrote: > > Is it just to avoid adding sendmsg to the ports systrace policy? Why not > > add it - maybe not globally but just for file? > > sendmsg with a CMSG fd passing in/out of such a jail is a bad thing. The systrace policy already a

Re: file(1): is this reasonable?

2015-06-04 Thread Theo de Raadt
> Is it just to avoid adding sendmsg to the ports systrace policy? Why not > add it - maybe not globally but just for file? sendmsg with a CMSG fd passing in/out of such a jail is a bad thing. However. It is likely that a ports configure test may try to test this interface. Not just CMSG, but se

Re: file(1): is this reasonable?

2015-06-04 Thread Nicholas Marriott
On Thu, Jun 04, 2015 at 02:29:50PM -0700, patrick keshishian wrote: > On Thu, Jun 04, 2015 at 10:20:35PM +0100, Nicholas Marriott wrote: > > Hi > > > > I think having two different main()s is silly. Why not keep the privsep > > and everything else but just skip the systrace bits? > > Well, part o

Re: file(1): is this reasonable?

2015-06-04 Thread patrick keshishian
On Thu, Jun 04, 2015 at 10:20:35PM +0100, Nicholas Marriott wrote: > Hi > > I think having two different main()s is silly. Why not keep the privsep > and everything else but just skip the systrace bits? Well, part of the problem is to avoid the imsg interface between parent and child. Theo's sugg

Re: file(1): is this reasonable?

2015-06-04 Thread Nicholas Marriott
Why not just do this? Index: sandbox.c === RCS file: /cvs/src/usr.bin/file/sandbox.c,v retrieving revision 1.7 diff -u -p -r1.7 sandbox.c --- sandbox.c 29 May 2015 15:58:34 - 1.7 +++ sandbox.c 4 Jun 2015 21:27:32 - @@

Re: file(1): is this reasonable?

2015-06-04 Thread Theo de Raadt
> I think having two different main()s is silly. Why not keep the privsep > and everything else but just skip the systrace bits? Right. Do the ioctl early on. If it flags that systrace is on, then simply do direct-calls to the file checking code. Try a few more approaches, try to make it simple

Re: file(1): is this reasonable?

2015-06-04 Thread Nicholas Marriott
Hi I think having two different main()s is silly. Why not keep the privsep and everything else but just skip the systrace bits? On Thu, Jun 04, 2015 at 02:09:43PM -0700, patrick keshishian wrote: > On Thu, Jun 04, 2015 at 12:46:14PM -0600, Theo de Raadt wrote: > > > Trying to get file to work un

Re: file(1): is this reasonable?

2015-06-04 Thread patrick keshishian
On Thu, Jun 04, 2015 at 12:46:14PM -0600, Theo de Raadt wrote: > > Trying to get file to work under systrace(1). > > > > Is this a reasonable patch? > > Semi-reasonable. > > I think if the ioctl fails, it should be entirely silent. > > > file(1) still fails with systrace because of sendmsg(2),

Re: file(1): is this reasonable?

2015-06-04 Thread Theo de Raadt
> Trying to get file to work under systrace(1). > > Is this a reasonable patch? Semi-reasonable. I think if the ioctl fails, it should be entirely silent. > file(1) still fails with systrace because of sendmsg(2), any > help with correcting systrace.policy for this case would be > appreciated.

file(1): is this reasonable?

2015-06-04 Thread patrick keshishian
Trying to get file to work under systrace(1). Is this a reasonable patch? According to systrace(4) ioctl(STRIOCATTACH) can fail for one of five reasons. In context of file(1), the only possible one is number "3. It's being traced already". file(1) still fails with systrace because of sendmsg(2)

Re: RTF_LOCAL and permanent ARP

2015-06-04 Thread mxb
Yes, "incomplete" is gone as well as "arpresolve: unresolved and rt_expire == 0". //mxb On 2015-06-04 12:19, Martin Pieuchot wrote: I'd like to put the link-layer address back into the gateway field of RTF_LOCAL addresses. The problem is that RTF_LOCAL routes are also marked as RTF_LLINFO a

RTF_LOCAL and permanent ARP

2015-06-04 Thread Martin Pieuchot
I'd like to put the link-layer address back into the gateway field of RTF_LOCAL addresses. The problem is that RTF_LOCAL routes are also marked as RTF_LLINFO and a lot of code assume (correctly) that such routes contain valid ARP or ND information. I believe we decided to use an ``empty'' lladdr

systrace patch for chflagsat

2015-06-04 Thread patrick keshishian
Hi, With the cp(1) change to use chflagsat(), systrace needs to be taught about chflagsat syscall. databases/db/v4 port fails with USE_SYSTRACE=Yes due to a "$(CP) -pr" use during install_docs. Could someone look over these changes and correct any mistakes. I am not 100% sure it is correct; speci