Re: Trouble using keepassxc-proxy with iridium/chromium
On Sun, 22 May 2022 19:27:19 +0200 Antoine Jacoutot wrote: > On Sun, May 22, 2022 at 07:17:49PM +0200, Joel Carnat wrote: > > Hello, > > > > From a brand new 7.1/amd64 installation, I'm trying to use > > keepassxc-proxy with Iridium. As I did for Firefox-ESR, I added > > "/usr/local/bin/keepassxc-proxy rx" to /etc/iridium/unveil.main. > > But it never connects to the database. > > I think you also need: > /usr/local/bin r > Yep, it solves both Iridium & Chromium issues. Thanks a lot. > > > > Using Firefox-ESR, it works ok. > > Using "iridium --disable-unveil", it works ok. > > Using Chromium, it doesn't work either. When disabling unveil, it > > works. > > > > I've tried looking at ktrace/kdump but I don't really know what to > > look for. When searching for "NAMI.*keepassxc", I could only find > > calls that seem to end properly (RET 0). > > > > Anyone knows what to add to unveil.main to have keepassxc-proxy? > > What should I be looking for in kdump to identify what fails? > > > > ktrace.out is a bit more 100MB but I can make it available online > > if it helps. > > > > Thanks, > > Joel C. > > >
Re: Trouble using keepassxc-proxy with iridium/chromium
On Sun, May 22, 2022 at 07:17:49PM +0200, Joel Carnat wrote: > Hello, > > From a brand new 7.1/amd64 installation, I'm trying to use > keepassxc-proxy with Iridium. As I did for Firefox-ESR, I added > "/usr/local/bin/keepassxc-proxy rx" to /etc/iridium/unveil.main. But it > never connects to the database. I think you also need: /usr/local/bin r > > Using Firefox-ESR, it works ok. > Using "iridium --disable-unveil", it works ok. > Using Chromium, it doesn't work either. When disabling unveil, it works. > > I've tried looking at ktrace/kdump but I don't really know what to > look for. When searching for "NAMI.*keepassxc", I could only find calls > that seem to end properly (RET 0). > > Anyone knows what to add to unveil.main to have keepassxc-proxy? > What should I be looking for in kdump to identify what fails? > > ktrace.out is a bit more 100MB but I can make it available online if it > helps. > > Thanks, > Joel C. > -- Antoine
Trouble using keepassxc-proxy with iridium/chromium
Hello, >From a brand new 7.1/amd64 installation, I'm trying to use keepassxc-proxy with Iridium. As I did for Firefox-ESR, I added "/usr/local/bin/keepassxc-proxy rx" to /etc/iridium/unveil.main. But it never connects to the database. Using Firefox-ESR, it works ok. Using "iridium --disable-unveil", it works ok. Using Chromium, it doesn't work either. When disabling unveil, it works. I've tried looking at ktrace/kdump but I don't really know what to look for. When searching for "NAMI.*keepassxc", I could only find calls that seem to end properly (RET 0). Anyone knows what to add to unveil.main to have keepassxc-proxy? What should I be looking for in kdump to identify what fails? ktrace.out is a bit more 100MB but I can make it available online if it helps. Thanks, Joel C.
Re: booting OpenBSD on Raspberry pi4 without using sdcard for UEFI
It also mentions how to put console on the framebuffer. -- Sent from a phone, apologies for poor formatting. On 22 May 2022 16:33:53 Sandeep Gupta wrote: Yes, the document does mention: - standard miniroot supports boot without additional firmware - by default, the kernel output is on console On Sat, May 21, 2022 at 2:53 PM Stuart Henderson wrote: On 2022-05-20, Sandeep Gupta wrote: Hello, This post here ( http://matecha.net/posts/openbsd-on-pi-4-with-full-disk-encryption/) claims its possible to boot OpenBSD directly from USB without the need for UEFI on sdcard. I tried today but couldn't get it to work. I got a blank screen during the installation process. What I did was 1) updated the eeprom (bootloader) 2) set boot to usb 3) wrote install71.img onto ssd. The boot process did start but I got a blank screen. I was wondering if anyone has tried and has had success with booting OpenBSD directly from USB. See "ibstall on Raspberry Pi" in the INSTALL.arm64 file. -- Please keep replies on the mailing list.
Re: booting OpenBSD on Raspberry pi4 without using sdcard for UEFI
Yes, the document does mention: - standard miniroot supports boot without additional firmware - by default, the kernel output is on console On Sat, May 21, 2022 at 2:53 PM Stuart Henderson wrote: > On 2022-05-20, Sandeep Gupta wrote: > > Hello, > > > > This post here ( > > http://matecha.net/posts/openbsd-on-pi-4-with-full-disk-encryption/) > claims > > its possible to > > boot OpenBSD directly from USB without the need for UEFI on sdcard. > > I tried today but couldn't get it to work. I got a blank screen during > the > > installation process. What I did was > > 1) updated the eeprom (bootloader) > > 2) set boot to usb > > 3) wrote install71.img onto ssd. > > > > The boot process did start but I got a blank screen. I was wondering if > > anyone has tried and has had success with booting > > OpenBSD directly from USB. > > See "ibstall on Raspberry Pi" in the INSTALL.arm64 file. > > -- > Please keep replies on the mailing list. > >
Re: mutt fetch-mail ssl error
On Sun, May 22, 2022 at 10:15:35AM +1200, Avon Robertson wrote: > On Fri, May 20, 2022 at 10:25:39PM +1200, Avon Robertson wrote: > > On Fri, May 20, 2022 at 10:47:12AM +0200, Theo Buehler wrote: > > > On Fri, May 20, 2022 at 04:08:25PM +1200, Avon Robertson wrote: > > > > I have been unable to fetch mail with mutt on this host using either the > > > > currently installed snapshot and mutt package, or the snapshot and mutt > > > > package that had been installed 2-3 days previously. > > > > > > > > I have been able to send mail using mutt in conjuction with msmtp from > > > > this host. > > > > > > > > mutt's error-history command displays > > > > > > > > Reading /home/aer/var/mail/inbox... > > > > Reading /home/aer/var/mail/inbox... 0 > > > > Looking up pop3.xtra.co.nz... > > > > Connecting to pop3.xtra.co.nz... > > > > SSL failed: error:14007086:SSL routines:CONNECT_CR_CERT:certificate > > > > +verify failed > > > > Error connecting to server: pop3.xtra.co.nz > > > > > > There is a good chance that this is a bug I introduced by adding a more > > > stringent check when rewriting ASN1_STRING_to_UTF8(). This can now fail > > > if passed an uninitialized pointer. This bug should be fixed via > > > x509_utl.c r1.3 and a_string.c r1.11 which add initialization and relax > > > the check again. > > > > > > X509_verify_cert() > > > x509_verify() > > > x509_verify_cert_hostname() > > >X509_check_host() > > > do_x509_check() > > > do_check_string() > > > ASN1_STRING_to_UTF8() > > > > > > If this is the problem, you can fix this by checking out very current > > > sources and rebuilding libcrypto > > > > > > cd /usr/src/lib/libcrypto > > > make obj > > > doas make includes > > > make > > > doas make install > > > > > > or you can wait for a new snapshot including this fix and try again. > > > > Thank you for your response Theo. It past my bed time tonight. Tomorrow > > I will do what you have suggested above. > > > > Regards > > -- > > aer > > > > The latest snapshot from mirror.aaarnet.edu.au was installed near > midday the following day on the affected host and all packages were > updated. The host was then powered down. Unfortunately, when it was > later powered on I found that the power supply had died and that I would > have to buy a replacement. > > So, this morning one day later, I installed the latest snapshot from > the above mirror on a Dell M6600 laptop and updated all installed > packages. The kernel and mutt versions are now: > > kern.version=OpenBSD 7.1-current (GENERIC.MP) #537: Fri May 20 22:45:40 MDT > 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > drwxr-xr-x 2 root wheel 512 May 21 18:41 mutt-2.2.5v3-gpgme-sasl > > Alas, the same mutt error occurs as shown above. Later today if time > permits, else tomorrow; I will build libcrypto on the laptop and see if > this fixes the error. > > Regards > -- > aer > The libcrypto build and install as outlined above by Theo was completed without error a few minutes ago on the Dell M6600. It was then rebooted and mutt's G command was invoked to fetch mail from pop3.xtra.co.nz. Sadly the attempt failed and mutt's error-history command displayed the same error as above. So perhaps mutt's fetch-mail error is unrelated to libcrypto's recent bug. Any hints or advice to resolve this issue? Regards -- aer
