Extra Group in lndir policy
Hi, I am using Openbsd 6.5 and noticed that the pledge policy for lndir includes wpath but I don't see why this group is necessary. I have removed the group and recompiled the binary and it seems to run fine with the test script below. #!/bin/ksh mkdir -p /home/dir1/subdir1 mkdir /home/dir2 mkdir /home/dir3 mkdir -p /home/dir4/subdir touch /home/dir1/exception ./lndir /home/dir1 /home/dir2 ./lndir -e /home/dir1/exception /home/dir1 /home/dir2 ./lndir -i /home/dir4/ /home/dir3 ./lndir -s /home/dir4/ /home/dir3 rm -r /home/dir1 /home/dir2 /home/dir3 /home/dir4 I don't see any environment variables in libc that should be toggled to do further testing. Any assistance would be appreciated but in the mean time I will continue to do testing. I have also statically analyzed lndir (including libc) and I can't find an open-write or openat-write anywhere. Regards, Shankara Pailoor
Re: Pledge Policy for Tset Binary
Thanks Theo! I am working on it right now. On Wed, Mar 4, 2020 at 9:21 AM Theo de Raadt wrote: > shankarapailoor . wrote: > > > I was looking at the pledge policy for the tset binary and I was > wondering > > why wpath is necessary. I removed the group from the pledge and did some > > basic tests with the utility and there was no error. Removing any of the > > other groups produces an error so they seem necessary. Any assistance > would > > be appreciated. > > Yeah, I can't find a open-for-write. However this calls libcurses which > is a nest of vipers. > > Since you have already begun... > > As well as trying all options, please add tests which mix in all > potential environment variables which are used by the dependent > libraries. > > A bit more effort please, and if no cause can be found, then wpath > can be removed. > -- Regards, Shankara Pailoor
Re: Wikidata:Property proposal
Hi, Christophe Poncy wrote on Thu, Mar 05, 2020 at 11:33:23PM +0100: > There is two property proposals to review on Wikidata, one related to > NetBSD and the other to OpenBSD. > > Please see: > https://www.wikidata.org/wiki/Wikidata:Property_proposal/OpenBSD_port > > Any comments are very welcome! You can also edit the proposal if you > see any mistake Thanks for the heads-up, i added an entry to the Talk page. Yours, Ingo
Wikidata:Property proposal
Hello there, There is two property proposals to review on Wikidata, one related to NetBSD and the other to OpenBSD. Please see: https://www.wikidata.org/wiki/Wikidata:Property_proposal/NetBSD_package https://www.wikidata.org/wiki/Wikidata:Property_proposal/OpenBSD_port Any comments are very welcome! You can also edit the proposal if you see any mistake… Christophe
Help: System hang/Lockup using snapshots on Intel i5 NUC?
Hi All, We've been running OpenBSD on a server for several years now and its been reliable with minimal issues, so I thought I would also like to try it as a desktop system. Thus I've been experimenting with an Intel NUC 8i5BEH running OpenBSD current snapshots and with XFCE as the Windowing system. And it all works very nicely. So well in fact that I've added an SSD, NFS mounted my old Linux box and rsynced over my home directory. OpenBSD as my main desktop system! For the most part everything has gone well, I have only noticed one serious issue so far: The complete system hangs intermittently. Which is naturally a bit of a downer :(. When this happens the mouse is frozen, the capslock LED on the (USB) keyboard doesn't light up and the system doesn't respond to ssh. To recover I have to hold down the power switch to shutoff the system, then turn it on again, reboot and examine the resulting fsck errors. I have impression this often occurs when using a Web browser. At first when I used Iridium, then Chrome, it seemed to happen every few hours. When I switched to trying Firefox, then the hangs seemed to occur less often, maybe every day or two. Perhaps I'm doing less browsing because of the hangs :). The graphics driver being used is: inteldrm0 at pci0 dev 2 function 0 "Intel Iris Plus Graphics 655" rev 0x01 I can leave the system running, sitting at the xenodm screen, for days without issue. I've also done a couple of complete memtest86 runs without error. I've even upgraded to the latest BIOS/firmware version. I've increased maxproc and maxfiles in sysctl.conf and also set ddb.panic=0 thinking that the behaviour might change to a panic+reboot instead of a hang, but this made no difference. After a hang + reboot there is nothing obvious in the log files. Any suggestions how to further debug such an issue? The OpenBSD kernel tells me that there is a serial port / UART (com0 at isa0 port 0x3f8/8 irq 4: ns16550 ...) but I've taken the NUC to pieces and I cannot see anything on the board that looks like a serial port header. The kernel does log a few of dubious messages at boot time. There are several instances of "not configured". And there is one occurrence of "mem address conflict 0xfe01/0x1000". I don't know if these are relevant, generally the system seems quite stable. Until it isn't. If you see what I mean. (See below for a complete set of boot time messages). I would be grateful for any support in debugging, or even better, resolving this issue. Cheers, Robb. mjoelnir:log 5.03 23:22:54 # dmesg OpenBSD 6.6-current (GENERIC.MP) #20: Sat Feb 29 14:38:12 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34201518080 (32617MB) avail mem = 33152389120 (31616MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7a9a4000 (77 entries) bios0: vendor Intel Corp. version "BECFL357.86A.0077.2019.1127.1452" date 11/27/2019 bios0: Intel(R) Client Systems NUC8i5BEH acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT SSDT UEFI LPIT SSDT SSDT DBGP DBG2 DMAR SSDT NHLT BGRT TPM2 WSMT acpi0: wakeup devices SIO1(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz, 9182.89 MHz, 06-8e-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz, 2194.90 MHz, 06-8e-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0,
Re: USB Printer Prebloms
On Wed, 4 Mar 2020 08:38:02 +0100 Sebastien Marie wrote: > On Tue, Mar 03, 2020 at 10:57:03PM -0700, Duncan Patton a Campbell wrote: > > > > I've had problems getting an old Brother printer to work (again) > > and have managed to locate/understand? the source of the problems. > > > > 1. ulpt must be disabled: > > # config -ef /bsd > > ukc> disable ulpt > > ukc> quit > > > > 2. modifying the kernel changes the kernel checksum so to get it to relink > > sha256 -h /var/db/kernel.SHA256 /bsd > > > > 3. relinking the kernel _re-enables_ ulpt. > > > > So I'm going to have install the build system and run thru the kernel > > patches > > after I figure out how to disable ulpt in the GENERIC.MP build. > > > > Does this sound like it will work? > > Pratical advice: > > Depending your need, you could also live without kernel relinking (KARL) in > order to keep ulpt(4) disabled using config(8). > > I would still relink after an upgrade in order to have an unique /bsd (and not > the one publicly available from internet). > > So it would be: > - after an upgrade, reboot and wait relinking to be done (a fresh /bsd will be > installed) > - run `config -ef /bsd' and disable ulpt in the new (and unique) kernel > - do *NOT* regenerate /var/db/kernel.SHA256 (so sha256 will mismatch) > - reboot again and run on the new /bsd (with ulpt disabled) > > System will complains that relinking failed, but your /bsd with ulpt disabled > will stay. > Pretty much that's where I'm at. I'm gonna try again to get ulpt to work. Thanks, Dhu > > Developer advice: > > mpi@ already pointed the right way to deal with it: make ulpt(4) and ugen(4) > to > coexist. This way you could use cupsd (using ugen) with a GENERIC kernel. > > see https://marc.info/?l=openbsd-tech=151618565000531=2 for details > > Thanks. > -- > Sebastien Marie > > -- Je suis Canadien. Ce n'est pas Francais ou Anglaise. C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-)
Re: USB Printer Prebloms
On Wed, 04 Mar 2020 08:05:08 + Xianwen Chen (陈贤文) wrote: > Dear Ducan, > > I just set up a Brother HL-5450DN Series on OpenBSD 6.6 amd64. > > > 1. ulpt must be disabled: > > # config -ef /bsd > > ukc> disable ulpt > > ukc> quit > > I studied tutorials on-line and previous discussions on @misc. I found > out that for 6.6 amd64, if I disabled ulpt(4), I would not get the > printer to work. On the contrary, I was able to get the printer to work > by using ulpt(4). > > For other bits I followed previous tutorials and discussions, that I > used footmatic-rip and so on. > > Yours sincerely, > Xianwen > > > Haven't got it to work yet with ulpt enabled but it's useful to know it's now possible. Thanks, Dhu -- Je suis Canadien. Ce n'est pas Francais ou Anglaise. C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-)
Re: pthread_mutexattr_setpshared and Apache Guacamole remote desktop gateway
On 05/03/2020 10:53 a.m., Edgar Pettijohn wrote:
On Mar 5, 2020 10:15 AM, Steve Williams wrote:
Hi,
Should this be on ports@? I'm not working on a port...
TL;DR:
Does anyone have any recommendations on how to work around not having
pthread_mutexattr_setpshared in the OpenBSD pthreads library?
Have you tried searching the ports tree patch files for mention of the
function. You may find a real world example of a workaround.
Edgar
DETAILS:
I wanted to see if Apache Guacamole would compile on OpenBSD to server
as a remote desktop gateway.
It hasn't been too hard to get it to the final linking step.
I am getting an "undefined reference to `pthread_mutexattr_setpshared'":
../../src/libguac/.libs/libguac.so.17.0: undefined reference to
`pthread_mutexattr_setpshared'
collect2: ld returned 1 exit status
*** Error 1 in src/guacenc (Makefile:565 'guacenc': @echo " CCLD
" guacenc;/bin/sh ../../libtool --silent --tag=CC --mode=link gcc -s...)
*** Error 1 in . (Makefile:556 'all-recursive')
*** Error 1 in /home/steve/src/guacamole-server-1.1.0 (Makefile:453
'all')
When I look at some of the code using pthread_mutexattr_setpshared, it's
not #ifdef'd or anything, so I think it's pretty much mandatory code.
pool.c:
guac_pool* guac_pool_alloc(int size) {
pthread_mutexattr_t lock_attributes;
guac_pool* pool = malloc(sizeof(guac_pool));
/* If unable to allocate, just return NULL. */
if (pool == NULL)
return NULL;
/* Initialize empty pool */
pool->min_size = size;
pool->active = 0;
pool->__next_value = 0;
pool->__head = NULL;
pool->__tail = NULL;
/* Init lock */
pthread_mutexattr_init(_attributes);
pthread_mutexattr_setpshared(_attributes,
PTHREAD_PROCESS_SHARED);
//^
pthread_mutex_init(&(pool->__lock), _attributes);
It looks like this is a posix (of some version) function:
https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutexattr_setpshared.html
An "appropos" search in the OpenBSD man pages for "pthread_mutexattr"
returned:
https://man.openbsd.org/man3/pthread_mutexattr.3
This function is definitely missing...
I tried to see if there was a way to use pthread_mutexattr_settype to
accomplish the same thing, but got lost in the maze of documentation.
Does anyone have any recommendations on how to work around not having
pthread_mutexattr_setpshared in the OpenBSD pthreads library?
Thanks,
Steve Williams
Hi,
Great idea to check the ports tree patch files!
I will start to look through these and see how they are handling
things. I have deleted all the lines returned for posixtestsuite port.
$ find . -type f -print0 | xargs -0 grep pthread_mutexattr_setpshared |
tee /tmp/shared.out
./databases/virtuoso/patches/patch-libsrc_Thread_sched_pthread_c: rc =
pthread_mutexattr_setpshared (&_mutex_attr, PTHREAD_PROCESS_PRIVATE);
./databases/virtuoso/patches/patch-libsrc_Thread_sched_pthread_c: rc =
pthread_mutexattr_setpshared (&_mutex_attr, PTHREAD_PROCESS_PRIVATE);
./databases/virtuoso/patches/patch-libsrc_Thread_sched_pthread_c: rc =
pthread_mutexattr_setpshared (&_attr, PTHREAD_PROCESS_PRIVATE);
./devel/lam/patches/patch-config_lam_mutex_pshared_m4: if
(pthread_mutexattr_setpshared(, PTHREAD_PROCESS_SHARED)) return(1);
./textproc/sphinx/patches/patch-src_sphinxstd_cpp:- iRes =
pthread_mutexattr_setpshared ( , PTHREAD_PROCESS_SHARED );
./textproc/sphinx/patches/patch-src_sphinxstd_cpp:- m_sError.SetSprintf
( "pthread_mutexattr_setpshared, errno = %d", iRes );
./x11/kde4/libs/files/ConfigureChecks.cmake: if
(pthread_mutexattr_setpshared(, PTHREAD_PROCESS_SHARED) == -1) {
./x11/kde4/libs/files/ConfigureChecks.cmake:
printf(\"pthread_mutexattr_setpshared failed: %s\", strerror(errno));
./x11/kde4/libs/patches/patch-kdecore_util_kshareddatacache_p_h: if
(pthread_mutexattr_setpshared(, PTHREAD_PROCESS_SHARED) == 0 &&
Cheers,
Steve Williams
Re: pthread_mutexattr_setpshared and Apache Guacamole remote desktop gateway
On Mar 5, 2020 10:15 AM, Steve Williams wrote:
>
> Hi,
>
> Should this be on ports@? I'm not working on a port...
>
> TL;DR:
> Does anyone have any recommendations on how to work around not having
> pthread_mutexattr_setpshared in the OpenBSD pthreads library?
>
Have you tried searching the ports tree patch files for mention of the
function. You may find a real world example of a workaround.
Edgar
> DETAILS:
> I wanted to see if Apache Guacamole would compile on OpenBSD to server
> as a remote desktop gateway.
>
> It hasn't been too hard to get it to the final linking step.
>
> I am getting an "undefined reference to `pthread_mutexattr_setpshared'":
>
> ../../src/libguac/.libs/libguac.so.17.0: undefined reference to
> `pthread_mutexattr_setpshared'
> collect2: ld returned 1 exit status
> *** Error 1 in src/guacenc (Makefile:565 'guacenc': @echo " CCLD
> " guacenc;/bin/sh ../../libtool --silent --tag=CC --mode=link gcc -s...)
> *** Error 1 in . (Makefile:556 'all-recursive')
> *** Error 1 in /home/steve/src/guacamole-server-1.1.0 (Makefile:453
> 'all')
>
>
> When I look at some of the code using pthread_mutexattr_setpshared, it's
> not #ifdef'd or anything, so I think it's pretty much mandatory code.
>
> pool.c:
>
> guac_pool* guac_pool_alloc(int size) {
>
> pthread_mutexattr_t lock_attributes;
> guac_pool* pool = malloc(sizeof(guac_pool));
>
> /* If unable to allocate, just return NULL. */
> if (pool == NULL)
> return NULL;
>
> /* Initialize empty pool */
> pool->min_size = size;
> pool->active = 0;
> pool->__next_value = 0;
> pool->__head = NULL;
> pool->__tail = NULL;
>
> /* Init lock */
> pthread_mutexattr_init(_attributes);
>
> pthread_mutexattr_setpshared(_attributes,
> PTHREAD_PROCESS_SHARED);
> //^
> pthread_mutex_init(&(pool->__lock), _attributes);
>
>
> It looks like this is a posix (of some version) function:
> https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutexattr_setpshared.html
>
> An "appropos" search in the OpenBSD man pages for "pthread_mutexattr"
> returned:
> https://man.openbsd.org/man3/pthread_mutexattr.3
>
> This function is definitely missing...
>
> I tried to see if there was a way to use pthread_mutexattr_settype to
> accomplish the same thing, but got lost in the maze of documentation.
>
> Does anyone have any recommendations on how to work around not having
> pthread_mutexattr_setpshared in the OpenBSD pthreads library?
>
> Thanks,
> Steve Williams
>
pthread_mutexattr_setpshared and Apache Guacamole remote desktop gateway
Hi,
Should this be on ports@? I'm not working on a port...
TL;DR:
Does anyone have any recommendations on how to work around not having
pthread_mutexattr_setpshared in the OpenBSD pthreads library?
DETAILS:
I wanted to see if Apache Guacamole would compile on OpenBSD to server
as a remote desktop gateway.
It hasn't been too hard to get it to the final linking step.
I am getting an "undefined reference to `pthread_mutexattr_setpshared'":
../../src/libguac/.libs/libguac.so.17.0: undefined reference to
`pthread_mutexattr_setpshared'
collect2: ld returned 1 exit status
*** Error 1 in src/guacenc (Makefile:565 'guacenc': @echo " CCLD
" guacenc;/bin/sh ../../libtool --silent --tag=CC --mode=link gcc -s...)
*** Error 1 in . (Makefile:556 'all-recursive')
*** Error 1 in /home/steve/src/guacamole-server-1.1.0 (Makefile:453
'all')
When I look at some of the code using pthread_mutexattr_setpshared, it's
not #ifdef'd or anything, so I think it's pretty much mandatory code.
pool.c:
guac_pool* guac_pool_alloc(int size) {
pthread_mutexattr_t lock_attributes;
guac_pool* pool = malloc(sizeof(guac_pool));
/* If unable to allocate, just return NULL. */
if (pool == NULL)
return NULL;
/* Initialize empty pool */
pool->min_size = size;
pool->active = 0;
pool->__next_value = 0;
pool->__head = NULL;
pool->__tail = NULL;
/* Init lock */
pthread_mutexattr_init(_attributes);
pthread_mutexattr_setpshared(_attributes,
PTHREAD_PROCESS_SHARED);
//^
pthread_mutex_init(&(pool->__lock), _attributes);
It looks like this is a posix (of some version) function:
https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutexattr_setpshared.html
An "appropos" search in the OpenBSD man pages for "pthread_mutexattr"
returned:
https://man.openbsd.org/man3/pthread_mutexattr.3
This function is definitely missing...
I tried to see if there was a way to use pthread_mutexattr_settype to
accomplish the same thing, but got lost in the maze of documentation.
Does anyone have any recommendations on how to work around not having
pthread_mutexattr_setpshared in the OpenBSD pthreads library?
Thanks,
Steve Williams
Re: Hardening browser
On Wed, Mar 04, 2020 at 11:38:40AM +, Ottavio Caruso wrote: > On Wed, 4 Mar 2020 at 01:06, wrote: > > > > Hi, > > in the following message: > > https://marc.info/?l=openbsd-misc=158110613210895=2 > > Theo discourages to use unveil instead of chroot. > > I asked if he suggests the same for the browser but he asked that chroot > > Probably not what you were looking for but, back in the days when I > was ultra paranoid about my web browsing, I used to use stripped down > live usb installations of Linux distros (DSL was one of them that I > remember). I ignore if OpenBSD comes with such a solution out the box, > but I'm sure it wouldn't be difficult to make your own read-only > install. Then, you could either reboot from it or run it through an > emulator. > My opinion is that in the last 10 years the world of hackers groups was deeply changed. Deface or big worms that make big damages are not in fashion anymore. Today the hackers group want just only be as hidden as they can. Then today the biggest problems are the uefi/bios malware, if you use a read only live cd or usb don't stop someone infect your firmwares. And when you reboot your machine you are hacked. Maybe with an hypervisor that can isolate processes and kernels the job is more hard. One of the biggest criticism I make to openbsd is that the everyone processes are visible to everyone. So that if you use muliple account for multiple application you don't stop an infected process to see if you run a browser, a irc session and maybe what network you are connected, if you opened pdf, if you used vim for code and what code and so on. And the last but first for importance if you are sniffing your traffic to search a covert channel. If my browser is infected with a malware the first thing I do is try to sniff the traffic to detect strange destinations, but if the infected process can see if I'm running a sniffer all my investigations are absolutely unuseful. If a very skilled hacker exploit your browser, take the root and infect your uefi, you must trash your laptop. And of course if you discover it, because if someone infect your uefi most problably you will never know it!
Re: Compiler warning in ctype.h
Todd C. Miller wrote: > On Thu, 05 Mar 2020 16:07:48 +0100, Thomas de Grivel wrote: > > > Actually I see the same problem on 6.6-stable : > > including readline/readline.h produces warnings. > > > > Any -Werror hope some day ? > > You still haven't bothered to include: > > 1) the compiler you are using > 2) the compiler flags to reproduce the problem > 3) a sample program to reproduce the problem > > The _l parameter in those inline functions already has the __unused__ > attribute set which is supposed to suppress those warnings. > > I can't reproduce this using clang (base or ports) or gcc (base or > ports) using -Wall, -Wextra and -Wunused-parameter. But since you > haven't provided any details, we just have to guess at what you are > doing. Or not guess, but simply delete the mail
Re: Compiler warning in ctype.h
On Thu, 05 Mar 2020 16:07:48 +0100, Thomas de Grivel wrote: > Actually I see the same problem on 6.6-stable : > including readline/readline.h produces warnings. > > Any -Werror hope some day ? You still haven't bothered to include: 1) the compiler you are using 2) the compiler flags to reproduce the problem 3) a sample program to reproduce the problem The _l parameter in those inline functions already has the __unused__ attribute set which is supposed to suppress those warnings. I can't reproduce this using clang (base or ports) or gcc (base or ports) using -Wall, -Wextra and -Wunused-parameter. But since you haven't provided any details, we just have to guess at what you are doing. - todd
Re: Compiler warning in ctype.h
On Wed, Mar 04, 2020 at 01:41:32PM +0100, Thomas de Grivel wrote: > With latest OpenBSD snapshot on amd64 > > In file included from /usr/include/readline/chardefs.h:26, > from /usr/include/readline/keymaps.h:36, > from /usr/include/readline/readline.h:38, > from cli.c:21: > /usr/include/ctype.h:216: warning: unused parameter '_l' > /usr/include/ctype.h:222: warning: unused parameter '_l' > /usr/include/ctype.h:228: warning: unused parameter '_l' > /usr/include/ctype.h:234: warning: unused parameter '_l' > /usr/include/ctype.h:240: warning: unused parameter '_l' > /usr/include/ctype.h:246: warning: unused parameter '_l' > /usr/include/ctype.h:252: warning: unused parameter '_l' > /usr/include/ctype.h:258: warning: unused parameter '_l' > /usr/include/ctype.h:264: warning: unused parameter '_l' > /usr/include/ctype.h:270: warning: unused parameter '_l' > /usr/include/ctype.h:276: warning: unused parameter '_l' > /usr/include/ctype.h:282: warning: unused parameter '_l' > /usr/include/ctype.h:288: warning: unused parameter '_l' > /usr/include/ctype.h:294: warning: unused parameter '_l' > > -- > Thomas de Grivel > kmx.io Are you using any particular compiler? Can you provide a tiny example that reproduces the behaviour? I can't reproduce it with the code I'm working on (which includes ctype.h from /usr/include) using clang(1) on amd64-current. It would be difficult for anyone to point out what you're doing wrong without having a look at what you're doing. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Compiler warning in ctype.h
Actually I see the same problem on 6.6-stable : including readline/readline.h produces warnings. Any -Werror hope some day ? cheers Le mer. 4 mars 2020 à 13:41, Thomas de Grivel a écrit : > > With latest OpenBSD snapshot on amd64 > > In file included from /usr/include/readline/chardefs.h:26, > from /usr/include/readline/keymaps.h:36, > from /usr/include/readline/readline.h:38, > from cli.c:21: > /usr/include/ctype.h:216: warning: unused parameter '_l' > /usr/include/ctype.h:222: warning: unused parameter '_l' > /usr/include/ctype.h:228: warning: unused parameter '_l' > /usr/include/ctype.h:234: warning: unused parameter '_l' > /usr/include/ctype.h:240: warning: unused parameter '_l' > /usr/include/ctype.h:246: warning: unused parameter '_l' > /usr/include/ctype.h:252: warning: unused parameter '_l' > /usr/include/ctype.h:258: warning: unused parameter '_l' > /usr/include/ctype.h:264: warning: unused parameter '_l' > /usr/include/ctype.h:270: warning: unused parameter '_l' > /usr/include/ctype.h:276: warning: unused parameter '_l' > /usr/include/ctype.h:282: warning: unused parameter '_l' > /usr/include/ctype.h:288: warning: unused parameter '_l' > /usr/include/ctype.h:294: warning: unused parameter '_l' > > -- > Thomas de Grivel > kmx.io -- Thomas de Grivel kmx.io
Re: Hardening browser
On 03-05 04:18, Tomasz Rola wrote: > On Wed, Mar 04, 2020 at 02:06:40AM +0100, whistlez...@riseup.net wrote: > > Hi, > > in the following message: > > https://marc.info/?l=openbsd-misc=158110613210895=2 > > Theo discourages to use unveil instead of chroot. > > I asked if he suggests the same for the browser but he asked that chroot > > is onlye for *root*. > > Then what should I do to hardening the most exposed piece of code that > > we use everyday ? > > Now I'm using unveil+chrome... > > Thank you. > [] > As of me, I use the trick with multiple users for different roles > (similar to other person who posted in this thread). I also employ > noscript in some of the roles. I just leave javascript off for usual browsing, with a tab sitting open in chromium or iridium to turn it on for the occasional temporary need, or added to the browser's exception list to allow permanently for certain sites. This partly because it seems easy, and partly since I probably won't know if a browser extension is sold to a malicious entity, or otherwise compromised (so, seems a smaller attack surface, but still usually convenient.) > Actually my browsing routine now employs more primitive browsers. Yes, sometimes, if practical. -- Luke Call My thoughts: http://lukecall.net (updated 2020-02-18)
RE: Hardening browser
Me's been following this discussion w/ some interest. Personally, meuses lynx(1) (w/o the ports patches, as they interfere w/ text field editing among other things), in image_links mode w/ feh(1). Works like a charm :) Mecan only agree with the sentiment that if something does not work in a normal (i.e. not overly bloated, and without ``backdoors'' like javashit) browser, it's the fault of the webmaster, not us as readers. Occasionally, when really pressed, meruns 'tails', a specialized Lunix distro, from a DVD on a spare craptop; at least that way, mecan get rid of the bloated, buggy shit by simply turning off the machine. Not that me's too impressed w/ 'tails': it does, but the maintainers appear to have mostly a broad, and thus not very deep, grasp of security. If me'd know of a similar, OpenBSD-based alternative, me'd of course use it. But, to me, anything is better than installing and maintaining a load of overweight, clumsy, not-very-UNIXy packages *just* to do the occasional javashit-bloated thing. Just me half-stiver :) --zeurkous. -- Friggin' Machines!
Re: 6.6 pflow IPFIX removed?
On 04/03/2020 18:35, Florian Obser wrote: > The ifconfig option parser is... special. > You must set flowdst as well as pflowproto. my bad. the problem was the src IP which was changed and the change wasn't reflected in the hostname.pflow0 sorry for the noise G
