Re: msyscall(2): pledge(2) operation not permitted
Hi Theo > interesting. Yes, msyscall() should probably be in the "stdio" set. > > But I've been considering deleting execpromises. It was put in as an > experiment, and I tried to make code in the base use it. I was unable > to find great usage cases, and so I am considering deleting it. Looking at my code, I noticed that pledge(), is always one of the first functions called, maybe I'm doing it wrong, but I tend to call pledge() more than once during the lifetime of a command. I think the execpromises, in my specific case, doesn't make much sense because one of the first thing I do after a fork+exec, is to call pledge() on the new program. I tried to use it because it is there, but I agree that, after checking my code, it's not that useful at all. > Andrea Biscuola wrote: > > > Hi @misc > > > > It appear the introduction of msyscall(2), broke the existing code > > of one of my projects. > > > > My code use a fork+exec model for executing different commands > > and pledge(2) is used for restricting the behavior of the child > > process using the execpromises argument. > > > > The problem is that, when a child process that was forked with > > the execpromises argument set load a new program, the process > > is killed because msyscall(2) is not permitted by the parent pledge(2). > > > > I checked in the /usr/src/sys/kern/kern_pledge.c file and it appear > > the msyscall(2) system call is not added to any category yet, thus > > not allowing me to use the execpromises argument for now. > > > > At the moment, I solved the problem by setting the execpromises > > for the pledge(2) calls to NULL. > > > > Is this expected? It's not really a problem as I'm running current > > and I know things could break and the workaround is ok (all the > > commands uses pledge(2) anyway). Is there some more work in > > progress that will solve the situation during the development > > cycle? > > > > Thank you and regards. > > -- > > Andrea > > > -- Andrea
support new
0 C iran P tehran T tehran Z 16571-67179 O CoreBOX Role-Based Hypervisor I abd.Homaei A pardis M hom...@corebox.ir U https://corebox.ir B +989195534924 X 22462158 N We are working CoreBOX hypervisor which is fully compatible with OpenBSD and FreeBSD. we also providing training course on *BSD.
Re: pinentry-tty in OpenBSD? to be used with emacs
rsyk...@disroot.org writes: December 8, 2019 5:45 PM, "Stefan Hagen" wrote: > Stefan Hagen wrote: > >> Rudolf Sykora wrote: >>> On linux, I believe, there is a pinentry-tty program, but that one is >>> not available on OpenBSD. >> >> Have you tried pinentry-curses? I'm using it on my remote machines >> to decrypt passwords in my password-store. Works well so far. > >> Well, the attached patch enables pinentry-tty in security/pinentry. I tried pinentry-curses. Now I was able to try pinentry-tty, too. However, with both I apparently have the same problem. The prompt for passphrase is just thrown somewhere into the emacs window, and I am not able to enter the password (emacs most probably doesn't know about the request for passphrase, it tries to interpret keypresses as commands). I even tried to enable pinentry-emacs in the pinentry Makefile; it is built. But when I choose it for the pinentry-program in ~/.gnupg/gpg-agent.conf, at the moment when the passphrase should be entered, I get the message gpg: problem with the agent: No pinentry. Thanks for any more help. Ruda
Re: reorder_kernel: failed
Hi misc,
I forgot to include the error while make install of a kernel:
LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
0 0 0 0 0
mv bsd bsd.gdb
ctfstrip -S -o bsd bsd.gdb
strip: bsd.gdb: File format not recognized
It looks like ld if totally failing.
-Dieter
On Sun, Dec 08, 2019 at 07:48:15PM +0100, Dieter Rauschenberger wrote:
> Hi misc,
>
> I have a reorder_kernel: failed -- see
> /usr/share/relink/kernel/GENERIC/relink.log error in todays snapshot
> (i386) Build date: 1575786572 - Sun Dec 8 06:29:32 UTC 2019
>
> $ cat /usr/share/relink/kernel/GENERIC/relink.log
> (SHA256) /bsd: OK
> LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
> ${OBJS}
> size: newbsd: not object file or archive
> *** Error 1 in /usr/share/relink/kernel/GENERIC (Makefile:1126 'newbsd':
> @size newbsd ; umask 007; echo mv newbsd newbsd.gdb; rm -f newbsd)
>
> I tried to build a GENERIC kernel on this machine, but make install
> failed at the line:
>
> ld -T ld.script -X --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS}
>
> The dmesg of this machine is:
>
> OpenBSD 6.6-current (GENERIC) #418: Sat Dec 7 23:05:40 MST 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 266682368 (254MB)
> avail mem = 246185984 (234MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 08/25/00, BIOS32 rev. 0 @ 0xe7300, SMBIOS rev. 2.3 @
> 0xf8dc6 (47 entries)
> bios0: vendor Compaq version "686P2 v2.04" date 08/25/2000
> bios0: Compaq Deskpro
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SSDT SSDT SSDT APIC SSDT SSDT SSDT SSDT SSDT SSDT SSDT
> acpi0: wakeup devices PCI0(S4) HUB_(S4) COM1(S4) COM2(S4) USB1(S3) USB2(S3)
> PBTN(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 Pentium III ("GenuineIntel" 686-class) 732 MHz, 06-08-06
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF,MELTDOWN
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 132MHz
> ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (HUB_)
> acpicpu0 at acpi0: C1(@1 halt!)
> "PNP0A03" at acpi0 not configured
> acpicmos0 at acpi0
> "PNP0003" at acpi0 not configured
> acpibtn0 at acpi0: PBTN
> bios0: ROM list: 0xc/0xa000 0xca000/0x800 0xca800/0xd800! 0xe/0x1!
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82815 Host" rev 0x02
> vga1 at pci0 dev 2 function 0 "Intel 82815 Video" rev 0x02
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> ppb0 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x02
> pci1 at ppb0 bus 2
> xl0 at pci1 dev 4 function 0 "3Com 3c905C" rev 0x78: apic 8 int 16, address
> 00:04:76:26:b5:0f
> exphy0 at xl0 phy 24: 3Com internal media interface
> fxp0 at pci1 dev 8 function 0 "Intel 82562" rev 0x01, i82562: apic 8 int 20,
> address 00:02:a5:2b:0f:43
> inphy0 at fxp0 phy 1: i82562EM 10/100 PHY, rev. 0
> ichpcib0 at pci0 dev 31 function 0 "Intel 82801BA LPC" rev 0x02
> pciide0 at pci0 dev 31 function 1 "Intel 82801BA IDE" rev 0x02: DMA, channel
> 0 wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0:
> wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0: removable
> cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
> uhci0 at pci0 dev 31 function 4 "Intel 82801BA USB" rev 0x02: apic 8 int 23
> auich0 at pci0 dev 31 function 5 "Intel 82801BA AC97" rev 0x02: apic 8 int
> 17, ICH2
> ac97: codec id 0x41445360 (Analog Devices AD1885)
> ac97: codec features headphone, Analog Devices Phat Stereo
> audio0 at auich0
> isa0 at ichpcib0
> isadma0 at isa0
> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> usb0 at uhci0: USB revision 1.0
> uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
> addr 1
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targ
Re: pinentry-tty in OpenBSD? to be used with emacs
On Mon, Dec 09, 2019 at 11:34:38AM +0100, Rudolf Sykora wrote: > Date: Mon, 09 Dec 2019 11:34:38 +0100 > From: Rudolf Sykora > To: Stefan Hagen , OpenBSD Misc Mailing List > > Cc: Pierre-Emmanuel Andre > Subject: Re: pinentry-tty in OpenBSD? to be used with emacs > > > rsyk...@disroot.org writes: > > December 8, 2019 5:45 PM, "Stefan Hagen" wrote: > > > Stefan Hagen wrote: > > > >> Rudolf Sykora wrote: > >>> On linux, I believe, there is a pinentry-tty program, but that one is > >>> not available on OpenBSD. > >> > >> Have you tried pinentry-curses? I'm using it on my remote machines > >> to decrypt passwords in my password-store. Works well so far. > > > >> Well, the attached patch enables pinentry-tty in security/pinentry. > > I tried pinentry-curses. Now I was able to try pinentry-tty, > too. However, with both I apparently have the same problem. The prompt > for passphrase is just thrown somewhere into the emacs window, and I am > not able to enter the password (emacs most probably doesn't know about > the request for passphrase, it tries to interpret keypresses as commands). > > I even tried to enable pinentry-emacs in the pinentry Makefile; it > is built. But when I choose it for the pinentry-program in > ~/.gnupg/gpg-agent.conf, at the moment when the passphrase should be > entered, I get the message > gpg: problem with the agent: No pinentry. > > > Thanks for any more help. > > Ruda > You can try to add "allow-emacs-pinentry" to your gpg-agent.conf and reconnect gpg-agent and retry. Relevant discussion on Reddit: https://www.reddit.com/r/emacs/comments/68xtx1/reliable_way_of_setting_up_gpg_password_input_in/dh2ozi2?utm_source=share&utm_medium=web2x signature.asc Description: PGP signature
VMM: crashing BIOS "hangs" vmctl start -c / cu
Hi, just a head's up / for the archives. Do more important things first :) While testing my packer-vmm port "across the board", I just noticed that bsd.rd older 5.7 will just hang in 'vmctl start -c' for.. forever? Dec 9 12:24:12 ssfnhv011 vmd[48696]: myvm: started vm 1 successfully, tty /dev/ttyp2 Dec 9 12:24:12 ssfnhv011 vmd[81215]: write_mem: failed - invalid memory range dst = 0x80f0, len = 0x1000: Invalid argument Dec 9 12:24:12 ssfnhv011 vmd[81215]: myvm: failed to load kernel or BIOS - exiting: Invalid argument Apparently omitting -c will return to prompt directly - and 'myvm' being gone (obviously). With -c there's a "dangling" '/usr/bin/cu -l /dev/ttyp2 -s 115200' around .. Maybe something for CAVEATS in vmctl.8 or cu(1) needing kinda signal that remote end hung up? ciao -- pb
-current: make release fails (rvnd0i not configured)
Hi, yesterday i've tried to make a release again...the first time in the last ~ two weeks, but it always fails with the error below. Hint: - i didn't change anything regarding my amd64 build machine - after e2k19 i've updated via snap w/o issues, ran sysmerge and updated /dev - of course /dev/rvnd0i is there # export RELEASEDIR=/release/base DESTDIR=/dest/base # cd /usr/src/etc && make release strip -R .comment -R .SUNW_ctf bsd.strip gzip -9cn bsd.strip > bsd.gz dd if=/dev/zero of=miniroot66.fs bs=512 count=9600 9600+0 records in 9600+0 records out 4915200 bytes transferred in 0.037 secs (132287931 bytes/sec) vnconfig -v miniroot66.fs > vnd vnd0: 4915200 bytes on miniroot66.fs fdisk -yi -l 9600 -b 960 -f /dest/base/usr/mdec/mbr `cat vnd` Writing MBR at offset 0. disklabel -wAT /usr/src/distrib/amd64/ramdisk_cd/template `cat vnd` newfs -t msdos /dev/r`cat vnd`i newfs_msdos: /dev/rvnd0i: Device not configured *** Error 1 in /usr/src/distrib/amd64/ramdisk_cd (Makefile:23 'miniroot66.fs') *** Error 2 in /usr/src/distrib/amd64 (:48 'all') *** Error 2 in /usr/src/distrib (:48 'all') *** Error 2 in . (Makefile:298 'distrib') *** Error 2 in . (Makefile:274 'do-release') *** Error 2 in /usr/src/etc (Makefile:257 'release') Am i missing sth? -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: groups update
Hello, please ignore this submission. The content is wrong: no such group exists in Qazvin, and the email address given on "M" line bounces. Besides, the email is a forgery and did not originate from the person given in the From: header. Yours, Ingo Faraz Vahedi wrote on Sun, Dec 08, 2019 at 09:43:15PM -0500: > 0 > C Iran > P Qazvin > T Qazvin > F Last Thursday of the month > O Qazvin BSD User Group (QBUG) > I Farid > M qaz...@irbug.org > U https://www.irbug.org > N *BSD
Re: pinentry-tty in OpenBSD? to be used with emacs
Xiyue Deng writes: > On Mon, Dec 09, 2019 at 11:34:38AM +0100, Rudolf Sykora wrote: >> Date: Mon, 09 Dec 2019 11:34:38 +0100 >> From: Rudolf Sykora >> To: Stefan Hagen , OpenBSD Misc Mailing List >> >> Cc: Pierre-Emmanuel Andre >> Subject: Re: pinentry-tty in OpenBSD? to be used with emacs >> >> >> rsyk...@disroot.org writes: >> >> December 8, 2019 5:45 PM, "Stefan Hagen" wrote: >> >> > Stefan Hagen wrote: >> > >> >> Rudolf Sykora wrote: >> >>> On linux, I believe, there is a pinentry-tty program, but that one is >> >>> not available on OpenBSD. >> >> >> >> Have you tried pinentry-curses? I'm using it on my remote machines >> >> to decrypt passwords in my password-store. Works well so far. >> > >> >> Well, the attached patch enables pinentry-tty in security/pinentry. >> >> I tried pinentry-curses. Now I was able to try pinentry-tty, >> too. However, with both I apparently have the same problem. The prompt >> for passphrase is just thrown somewhere into the emacs window, and I am >> not able to enter the password (emacs most probably doesn't know about >> the request for passphrase, it tries to interpret keypresses as commands). >> >> I even tried to enable pinentry-emacs in the pinentry Makefile; it >> is built. But when I choose it for the pinentry-program in >> ~/.gnupg/gpg-agent.conf, at the moment when the passphrase should be >> entered, I get the message >> gpg: problem with the agent: No pinentry. >> >> >> Thanks for any more help. >> >> Ruda >> > > You can try to add "allow-emacs-pinentry" to your gpg-agent.conf and > reconnect gpg-agent and retry. > > Relevant discussion on Reddit: > https://www.reddit.com/r/emacs/comments/68xtx1/reliable_way_of_setting_up_gpg_password_input_in/dh2ozi2?utm_source=share&utm_medium=web2x Thanks for the link. Although it didn't help, I finally, by trial and error, got my emacs to ask for the passphrase. In my case, I changed ~/.gnupg/gpg-agent.conf to just have: allow-emacs-pinentry inside, and in my .emacs I have: (setenv "INSIDE_EMACS" (format "%s,comint" emacs-version)) (pinentry-start) I have installed the pinentry package from M-x list-packages. And then (after pkill emacs gpg-agent ) emacs started to ask me as I wanted. I note that compiling and installing the pinentry-emacs (or pinentry-tty) within the pinentry port seems unnecessary. Furthermore, both lines in my .emacs seem to be essential. It's a pity I still do not understand how the chain really works, but at least it works somehow now. Hope it might help somebody in the future. I lost many hours with such a trivial thing. Best regards Ruda
Re: No WAF detected
Hi,
A message form assessors and further tests below.
[image: image.png]
I have configured relayd to serve a single url that accepts no parameters.
This url is blocked by relayd with error 403 Forbidden if anything is
appended to its end.
I would expect WAF detection in such a test case but this has not happened.
what other means are malicious payloads being delivered in this case?
Thanks and regards,
Kihaguru
# $OpenBSD: relayd.conf,v 1.5 2018/05/06 20:56:55 benno Exp $
#
# Relay and protocol
#
http protocol httpp {
return error
match response header remove "Server"
pass
block quick path "/cgi-bin/index.cgi" value "*command=*"
pass quick path "/net/index.html" value ""
block
}
relay httpr {
# Listen on localhost, accept diverted connections from
pf(4)
listen on 127.0.0.1 port 8080
protocol httpp
# Forward to the original target host
forward to destination
}
http protocol httpsp {
return error
match response header remove "Server"
pass
block quick path "/cgi-bin/index.cgi" value "*command=*"
pass quick path "/net/index.html" value ""
block
tls keypair example.net
}
relay httpsr {
# Listen on localhost, accept diverted connections from
pf(4)
listen on 127.0.0.1 port 8443 tls
protocol httpsp
# Forward to the original target host
forward with tls to destination
}
---
On Thu, Dec 5, 2019 at 2:11 PM Stuart Henderson wrote:
> On 2019/12/05 00:17, Kihaguru Gathura wrote:
> >
> >
> >
> > On Wed, Dec 4, 2019 at 11:58 PM Kihaguru Gathura
> wrote:
> >
> >
> >
> > >> Which is a better way to implement a WAF on OpenBSD using the
> base utilities?
> > >
> > > relayd configured in certain ways might be considered as a WAF.
> >
> >
> > All methods and all other security headers and path filters are
> coded in the web
> > application which had always been detected as a custom WAF until two
> weeks ago.
> >
> > I have now included relayd and a re-test passes all other
> requirements but does not detect
> > a WAF (please find sample configurations and test report below).
> >
> > Any hint highly appreciated
>
> I think you will need to talk to your assessors and ask what they're
> looking for.
>
>
Re: -current: make release fails (rvnd0i not configured)
use a snapshot. Mark Patruck wrote: > Hi, > > yesterday i've tried to make a release again...the first time in > the last ~ two weeks, but it always fails with the error below. > > Hint: > - i didn't change anything regarding my amd64 build machine > - after e2k19 i've updated via snap w/o issues, ran sysmerge > and updated /dev > - of course /dev/rvnd0i is there > > > # export RELEASEDIR=/release/base DESTDIR=/dest/base > # cd /usr/src/etc && make release > > strip -R .comment -R .SUNW_ctf bsd.strip > gzip -9cn bsd.strip > bsd.gz > dd if=/dev/zero of=miniroot66.fs bs=512 count=9600 > 9600+0 records in > 9600+0 records out > 4915200 bytes transferred in 0.037 secs (132287931 bytes/sec) > vnconfig -v miniroot66.fs > vnd > vnd0: 4915200 bytes on miniroot66.fs > fdisk -yi -l 9600 -b 960 -f /dest/base/usr/mdec/mbr `cat vnd` > Writing MBR at offset 0. > disklabel -wAT /usr/src/distrib/amd64/ramdisk_cd/template `cat vnd` > newfs -t msdos /dev/r`cat vnd`i > newfs_msdos: /dev/rvnd0i: Device not configured > *** Error 1 in /usr/src/distrib/amd64/ramdisk_cd (Makefile:23 'miniroot66.fs') > *** Error 2 in /usr/src/distrib/amd64 (:48 'all') > *** Error 2 in /usr/src/distrib (:48 'all') > *** Error 2 in . (Makefile:298 'distrib') > *** Error 2 in . (Makefile:274 'do-release') > *** Error 2 in /usr/src/etc (Makefile:257 'release') > > Am i missing sth? > > -Mark > > -- > Mark Patruck ( mark at wrapped.cx ) > GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 > > https://www.wrapped.cx >
Including AnonCVS mirrors in ssh_known_hosts
Would it be possible to include the default AnonCVS mirrors’ SSH fingerprints in the default ssh_known_hosts? If not, could it be included in another file in the base system? Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Including AnonCVS mirrors in ssh_known_hosts
Demi M. Obenour wrote: > Would it be possible to include the default AnonCVS mirrors’ SSH > fingerprints in the default ssh_known_hosts? There is no default ssh_known_hosts file. > If not, could it be included in another file in the base system? And teach users to trust us, rather than following best practice of doing signature checks? No way.
Re: Including AnonCVS mirrors in ssh_known_hosts
On 2019-12-09 10:33, Theo de Raadt wrote: > Demi M. Obenour wrote: > >> Would it be possible to include the default AnonCVS mirrors’ SSH >> fingerprints in the default ssh_known_hosts? > > There is no default ssh_known_hosts file. > >> If not, could it be included in another file in the base system? > > And teach users to trust us, rather than following best practice > of doing signature checks? No way. I would be more than happy to do signature checks. The problem is that I have no idea where I can find a signed list of those fingerprints, or another way of verifying them. That’s why I asked! If OpenBSD used GPG-signed Git commits or similar, I could verify that, but it does not. That isn’t meant as a criticism, BTW. It just means that if I want to follow the -current source repository, I need some way to verify the authenticity of the source code. If there is something wrong with my reasoning, I would love to know. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Including AnonCVS mirrors in ssh_known_hosts
Demi M. Obenour wrote: > On 2019-12-09 10:33, Theo de Raadt wrote: > > Demi M. Obenour wrote: > > > >> Would it be possible to include the default AnonCVS mirrors’ SSH > >> fingerprints in the default ssh_known_hosts? > > > > There is no default ssh_known_hosts file. > > > >> If not, could it be included in another file in the base system? > > > > And teach users to trust us, rather than following best practice > > of doing signature checks? No way. > > I would be more than happy to do signature checks. The problem is that > I have no idea where I can find a signed list of those fingerprints, > or another way of verifying them. That’s why I asked! > > If OpenBSD used GPG-signed Git commits or similar, I could verify > that, but it does not. That isn’t meant as a criticism, BTW. > It just means that if I want to follow the -current source repository, > I need some way to verify the authenticity of the source code. > > If there is something wrong with my reasoning, I would love to know. the project doesn't run the anoncvs servers. we are not able to provide you with a list which has more validity than your own checks.
Re: Including AnonCVS mirrors in ssh_known_hosts
On 2019-12-09 10:41, Theo de Raadt wrote: > > the project doesn't run the anoncvs servers. we are not able > to provide you with a list which has more validity than your own > checks. > I (mistakenly) considered the list on the OpenBSD website to be official. Sorry. Sincerely, Demi signature.asc Description: OpenPGP digital signature
What's up with bluhms perf tests?
Hi there misc I can see that there is a big drop in the throughput graphs, is something wrong with the data or was there a change that set performance = false? http://bluhm.genua.de/perform/results/perform.html -- Tommy
Openrsync manpage - EXAMPLES and SEE ALSO
Namaste misc,
On the openrsync manpage [1],
1) In the EXAMPLES section, the examples use "rsync".
...
% rsync -t ../src/bar ../src/baz host:dest
...
The SYNOPSIS section has the invocation as "openrsync".
Should we use "openrsync" in the EXAMPLES section?
2) In the SEE ALSO section, clicking on rsync(5) and rsyncd(5) results
in "No results found". An apropos [2] for "rsync" gives two results, one
of which is for openrsync itself.
Is there a configuration file format for rsync{d}?
Dhanyavaad,
ab
[1] - https://man.openbsd.org/openrsync
[2] -
https://man.openbsd.org/?query=rsync&apropos=1&sec=0&arch=default&manpath=OpenBSD-current
-|-|-|-|-|-|-|--
Re: What's up with bluhms perf tests?
Howdy Tommy, I think they enable some traces from time to time to assist in de-bug... also you will see a general trend downward due to all the various software mitigations for the hardware/ cpu cache / speculative execution bugs... Peace out .. Tom Smyth On Mon, 9 Dec 2019 at 15:57, Tommy Nevtelen wrote: > > Hi there misc > > I can see that there is a big drop in the throughput graphs, is > something wrong with the data or was there a change that set performance > = false? > > http://bluhm.genua.de/perform/results/perform.html > > -- > Tommy > -- Kindest regards, Tom Smyth.
Re: Openrsync manpage - EXAMPLES and SEE ALSO
Namaste Aham,
Aham Brahmasmi wrote on Mon, Dec 09, 2019 at 04:55:07PM +0100:
> On the openrsync manpage [1],
> [1] - https://man.openbsd.org/openrsync
> 1) In the EXAMPLES section, the examples use "rsync".
> ...
> % rsync -t ../src/bar ../src/baz host:dest
> ...
> The SYNOPSIS section has the invocation as "openrsync".
>
> Should we use "openrsync" in the EXAMPLES section?
I don't think so.
Ultimately, we hope to install OpenRSYNC as simply /usr/bin/rsync
rather than /usr/bin/openrsync, but it isn't quite ready for that
yet, too many features are still missing.
Until then, it can't be helped that the documentation is somewhat
messy. In particular, we don't really want to force "openrsync"
too deeply into people's finger memory.
> 2) In the SEE ALSO section, clicking on rsync(5) and rsyncd(5) results
> in "No results found". An apropos [2] for "rsync" gives two results, one
> of which is for openrsync itself.
Our source tree contains files rsync.5 and rsyncd.5 documenting the
protocols, but they are not installed. I think we should either
install these two files if they are accurate and considered relevant
or delete the two links from rsync(1).
I'm not sending a diff because i don't know which course of action
is better.
> Is there a configuration file format for rsync{d}?
Samba rsync supports rsyncd.conf(5) but OpenRSYNC does not appear
to at this time.
Yours,
Ingo
X11 on VEGA graphics
I have tried out VEGA graphics on Version 6.6 stable. Out of the box it mostly works, though there are two oddities: 1. The cursor for resizing windows (under openbox and icewm both) is wrong and misplaced, though the resize can be done. 2. Upon logging out of icewm, the confirmation screen has text missing. Very odd, this doesn't seem to occur anywhere else. I found the following fixes: For (1), turn on the software cursor. For (2), going to 2-D DRM alleviates but does not completely fix the issue. The remaining problem is that a small white rectangle overlays part of the confirmation screen. To implement these changes, the following file (10-amdgpu.conf) is placed in /etc/X11/xorg.conf.d: ection "Device" Identifier "AMDgpu" Driver "amdgpu" Option "SWcursor" "true" Option "DRI" "2" EndSection Here is the hardware segment of sysctl output: hw.machine=amd64 hw.model=AMD Ryzen 3 2200G with Radeon Vega Graphics hw.ncpu=4 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:42a97a46d649c52c,sd1:02849ec9332f0412 hw.diskcount=2 hw.sensors.ksmn0.temp0=21.70 degC hw.cpuspeed=3494 hw.setperf=100 hw.vendor=ASRock hw.product=A320M-HDV R4.0 hw.uuid=7085c2bd-52e3--- hw.physmem=7425409024 hw.usermem=7425396736 hw.ncpufound=4 hw.allowpowerdown=1 hw.perfpolicy=manual hw.smt=0 hw.ncpuonline=4 Dave Raymond -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
Re: pinentry-tty in OpenBSD? to be used with emacs
I don't know about pinentry but emacs freezes sound familiar. Have you tried using the workaround given in following site: https://omecha.info/blog/org-capture-freezes-emacs.html Timo On Sun, Dec 8, 2019, at 17:27, Rudolf Sykora wrote: > Dear list, > > > I've been using mu4e to read email, and the passwords are read using > gpg2 and the gpg-agent (both 2.2.12). Nowadays I use emacs running in a > terminal (somehow any graphical emacs keeps to freeze randomly when I > use mu4e together with the org-capture feature; terminal emacs just > works). Until recently I used to ssh -X to my box to read email (and > used a graphical window to enter my passphrase), but now I would like to > use mosh instead (so that hibernating and waking up my notebook does not > interrupt the connection). But as mosh cannot be used for X forwarding, > I need to use a non-graphical means of entering a passphrase to > gpg-agent. On linux, I believe, there is a pinentry-tty program, but > that one is not available on OpenBSD. Also I found mentions of > pinentry-emacs. I tried to install the elpa pinentry package, added > allow-emacs-pinentry to ~/.gnupg/gpg-agent.conf, but whatever I tried, I > don't see any sign that it ever does something. There is also a > pinentry-ncurses program available on OpenBSD, but that one seems to not > play well with my emacs; I see some prompt in emacs, but I cannot enter > the needed information. Can anybody help me to get some way to enter a > passphrase to be relayed to gpg-agent inside emacs running in a > terminal? > > I am using emacs 26.3 on OpenBSD 6.6. > > > Thanks for any comments! > > Rudolf Sykora > >
Re: What's up with bluhms perf tests?
On Mon, 09 Dec 2019 15:33:24 +0100, Tommy Nevtelen wrote: > I can see that there is a big drop in the throughput graphs, is > something wrong with the data or was there a change that set performance > = false? > > http://bluhm.genua.de/perform/results/perform.html That was probably the following commit: https://www.mail-archive.com/source-changes@openbsd.org/msg111985.html which has since been reverted: https://www.mail-archive.com/source-changes@openbsd.org/msg112279.html - todd
Re: Can't select files to upload in a browsers
Hi! Can I setup unveil for browsers by usergroups or login classes? пт, 6 дек. 2019 г. в 16:25, Stuart Henderson : > > On 2019-12-06, dmitry.sensei wrote: > > Firefox and Chromium browser, in the file selection window for upload, > > does not show the contents of directories other than the Downloads > > directory > > > > > > OpenBSD 6.6-current > > OpenBSD 6.6 GENERIC.MP#509 amd64 > > > > openbox-3.6.1p7 small, fast & usable window manager > > firefox-71.0Mozilla web browser > > chromium-78.0.3904.106 Chromium browser > > gtk+2-2.24.32p8 multi-platform graphical toolkit > > gtk+3-3.24.13 multi-platform graphical toolkit > > gtk+4-3.96.0p6 multi-platform graphical toolkit > > > > This is expected. > > Chromium has been using unveil(2) to restrict file access for some > time, and this has recently come to Firefox in -current. This prevents > the browser from being able to access sensitive files unless given > access (in a root-controlled file). > > See https://marc.info/?l=openbsd-ports-cvs&m=157539245010077&w=2 > and /usr/local/share/doc/pkg-readmes/firefox for more information > about how this affects Firefox. > > -- Dmitry Orlov
