Re: 4k display on integrated Intel graphics?

[Bryan Vyhmeister]

On Fri, Jun 29, 2018 at 11:04:12PM +0200, Maximilian Pichler wrote:
> Thanks for explaining. Some shaking could be lived with...

I went ahead and bought a Plugable USB-C to DisplayPort cable to confirm
that there are no issues. I unplugged my mDP to DP cable from the
NUC6i7KYK and the HP Z27s 3840x2160 monitor and replaced it with the
USB-C to DP cable and everything works exactly as before. Running xrandr
reports that I am running on DP-2 at 3840x2160 at 60Hz.

> I just realized that some monitors (e.g. LG 27UD88) can connect via
> USB-C directly, whilest serving as a USB hub and power source. Would
> this be expected to work as well?

This type of thing should work fine as the other poster said also. This
charging functionality is not OS-dependent and should work because of
device firmware. USB-C can carry different types of signals that have
been around a while and can be quite convenient as a result.

Bryan

Re: Daily insecurity output on valid users using key with valid shell and without password.

[Daniel Ouellet]

Hi Stuart,

The counting to 13 was actually a sarcastic joke. (:

But thanks never the less.

Daniel



On 7/1/18 5:54 PM, Stuart Henderson wrote:
> On 2018-07-01, Daniel Ouellet  wrote:
>> Ha the old man page.
>>
>> Not good to read to quickly. (:
>>
>> Sorry for the noise.
>>
>> Now I just need to learn to count up to 13.
> 
> Edit in vi, '13i*^[' or '13i*'
> 
> 

Re: Daily insecurity output on valid users using key with valid shell and without password.

[Stuart Henderson]

On 2018-07-01, Daniel Ouellet  wrote:
> Ha the old man page.
>
> Not good to read to quickly. (:
>
> Sorry for the noise.
>
> Now I just need to learn to count up to 13.

Edit in vi, '13i*^[' or '13i*'

Re: Daily insecurity output on valid users using key with valid shell and without password.

[Mohamed Fouad]

Set VERBOSESTATUS to 0 in /etc/daily.local

Source: absolute openbsd 2nd edition, chapter 15 "System Maintenance"

Havent done it myself but I hope its a good clue!

On Sun, 1 Jul 2018, 8:47 pm Remco,  wrote:

> Op 07/01/18 om 19:22 schreef Daniel Ouellet:
> > I find this annoying and sometime I over look this because I always get
> > the example:
> >
> > ==
> > Running security(8):
> >
> > Checking the /etc/master.passwd file:
> > Login share is off but still has a valid shell and alternate access
> files in
> >home directory are still readable.
> > Login xxx is off but still has a valid shell and alternate access files
> in
> >home directory are still readable.
> > =
> >
> > Is there a better or different way to do this?
> >
> > I always disable the login password on users with * oppose to password
> > in the master.passwd file after keys are installed as I DO NOT want to
> > allow login password when ssh keys are use, but still get the above
> > warning daily on multiples servers & users.
> >
> > The Running security(8): is nice as you see possible changes done by sys
> > admin and you get the feedback, but getting daily warning for the same
> > things sometime will get overlook because of noise.
> >
> > Is there a better way to disable login and not get these warning for ssh
> > key users and keep the valid idea and use of the cronjob as is?
> >
> > Daniel
> >
> >
>
> I think you need to use 13 asterisks for the password, passwd(5) has a
> brief mentioning of this.
>
>

Re: Daily insecurity output on valid users using key with valid shell and without password.

[Daniel Ouellet]

Ha the old man page.

Not good to read to quickly. (:

Sorry for the noise.

Now I just need to learn to count up to 13.

Daniel


By convention,
 accounts that are not intended to be logged in to (e.g. bin, daemon,
 sshd) only contain a single asterisk in the password field.  Note that
 there is nothing special about `*', it is just one of many characters
 that cannot occur in a valid encrypted password (see crypt(3)).
 Similarly, login accounts not allowing password authentication but
 allowing other authentication methods, for example public key
 authentication, conventionally have 13 asterisks in the password field.



On 7/1/18 2:44 PM, Remco wrote:
> Op 07/01/18 om 19:22 schreef Daniel Ouellet:
>> I find this annoying and sometime I over look this because I always get
>> the example:
>>
>> ==
>> Running security(8):
>>
>> Checking the /etc/master.passwd file:
>> Login share is off but still has a valid shell and alternate access
>> files in
>>  home directory are still readable.
>> Login xxx is off but still has a valid shell and alternate access
>> files in
>>  home directory are still readable.
>> =
>>
>> Is there a better or different way to do this?
>>
>> I always disable the login password on users with * oppose to password
>> in the master.passwd file after keys are installed as I DO NOT want to
>> allow login password when ssh keys are use, but still get the above
>> warning daily on multiples servers & users.
>>
>> The Running security(8): is nice as you see possible changes done by sys
>> admin and you get the feedback, but getting daily warning for the same
>> things sometime will get overlook because of noise.
>>
>> Is there a better way to disable login and not get these warning for ssh
>> key users and keep the valid idea and use of the cronjob as is?
>>
>> Daniel
>>
>>
> 
> I think you need to use 13 asterisks for the password, passwd(5) has a
> brief mentioning of this.

Re: Daily insecurity output on valid users using key with valid shell and without password.

[Remco]

Op 07/01/18 om 19:22 schreef Daniel Ouellet:

I find this annoying and sometime I over look this because I always get
the example:

==
Running security(8):

Checking the /etc/master.passwd file:
Login share is off but still has a valid shell and alternate access files in
 home directory are still readable.
Login xxx is off but still has a valid shell and alternate access files in
 home directory are still readable.
=

Is there a better or different way to do this?

I always disable the login password on users with * oppose to password
in the master.passwd file after keys are installed as I DO NOT want to
allow login password when ssh keys are use, but still get the above
warning daily on multiples servers & users.

The Running security(8): is nice as you see possible changes done by sys
admin and you get the feedback, but getting daily warning for the same
things sometime will get overlook because of noise.

Is there a better way to disable login and not get these warning for ssh
key users and keep the valid idea and use of the cronjob as is?

Daniel




I think you need to use 13 asterisks for the password, passwd(5) has a 
brief mentioning of this.

Re: Daily insecurity output on valid users using key with valid shell and without password.

[Stefan Johnson]

>From passwd(5) :
Similarly, login accounts not allowing password authentication but allowing
other authentication methods,
for example public key authentication, conventionally have 13 asterisks in
the password field.

I believe security(8) will stop barking about these accounts if you set the
encrypted password to 13
asterisks, instead of just one.

Sorry for top post.  Gmail gets squirrelly sometimes when I try to properly
respond in body.




On Sun, Jul 1, 2018 at 12:22 PM, Daniel Ouellet  wrote:

> I find this annoying and sometime I over look this because I always get
> the example:
>
> ==
> Running security(8):
>
> Checking the /etc/master.passwd file:
> Login share is off but still has a valid shell and alternate access files
> in
>  home directory are still readable.
> Login xxx is off but still has a valid shell and alternate access files in
>  home directory are still readable.
> =
>
> Is there a better or different way to do this?
>
> I always disable the login password on users with * oppose to password
> in the master.passwd file after keys are installed as I DO NOT want to
> allow login password when ssh keys are use, but still get the above
> warning daily on multiples servers & users.
>
> The Running security(8): is nice as you see possible changes done by sys
> admin and you get the feedback, but getting daily warning for the same
> things sometime will get overlook because of noise.
>
> Is there a better way to disable login and not get these warning for ssh
> key users and keep the valid idea and use of the cronjob as is?
>
> Daniel
>
>

Daily insecurity output on valid users using key with valid shell and without password.

[Daniel Ouellet]

I find this annoying and sometime I over look this because I always get
the example:

==
Running security(8):

Checking the /etc/master.passwd file:
Login share is off but still has a valid shell and alternate access files in
 home directory are still readable.
Login xxx is off but still has a valid shell and alternate access files in
 home directory are still readable.
=

Is there a better or different way to do this?

I always disable the login password on users with * oppose to password
in the master.passwd file after keys are installed as I DO NOT want to
allow login password when ssh keys are use, but still get the above
warning daily on multiples servers & users.

The Running security(8): is nice as you see possible changes done by sys
admin and you get the feedback, but getting daily warning for the same
things sometime will get overlook because of noise.

Is there a better way to disable login and not get these warning for ssh
key users and keep the valid idea and use of the cronjob as is?

Daniel

Broken Libreoffice (missing menu) and Anki (core dumped) in "current branch"?

[mogin]

Hi all,I am running several desktops on "current". After 1 year without 
problems I am now stuck and my desktop is not fully usable now (my workflow 
strongly depends on both apps - Anki & Libreoffice). 
I can't remember exact date when it broked but it surely worked with "current" 
until recently.
After several days of googling,  of trials and errors I would ask if you 
observed similar issues? Or could you give me some hints to solve the issue or 
where/how to dig deeper?
My assumption: probably only coincidence with these apps and no common root 
cause. Libreoffice problem maybe related to gtk+3 issues as reported here 
https://marc.info/?l=openbsd-misc=151053047925572=2 
. 

Ad versions of third party sw
- amd64 packages from latest snapshot 2018-07-01 (but both issues occurred 
earlier):anki-2.0.48p1libreoffice-6.0.3.2p0v0

Ad the outputs I  got- see at the bottom

Ad reproducing the problem:- install and run Anki and Libreoffice on "current"- 
at last I tried to isolate the issue with clean (new installation) "current" 
(no additional window managers or packages, only pure base) in Virtualbox and 
installing only Anki and Libreoffice - (un)fortunately the same error messages 
as from my "current" desktops
- Also tested again on clean "6.3 release" and both apps worked as expected.
Thanks

Regards,M.


--- Anki error --Trace/BPT trap (core dumped)
-- Libreoffice errors --(soffice:65238): 
GLib-GObject-WARNING **: 18:27:09.361: gsignal.c:3492: signal name 
'selection_changed' is invalid for instance '0x7862930' of type 
'OOoAtkObjCompTxt'** (soffice:65238): CRITICAL **: 18:27:10.828: void 
g_lo_menu_insert_section(GLOMenu *, gint, const gchar *, GMenuModel *): 
assertion 'G_IS_LO_MENU (menu)' failed(soffice:65238): Gtk-CRITICAL **: 
18:27:10.829: gtk_menu_bar_new_from_model: assertion 'G_IS_MENU_MODEL (model)' 
failed(soffice:65238): Gtk-CRITICAL **: 18:27:10.829: 
gtk_widget_insert_action_group: assertion 'GTK_IS_WIDGET (widget)' 
failed(soffice:65238): Gtk-CRITICAL **: 18:27:10.829: gtk_widget_set_hexpand: 
assertion 'GTK_IS_WIDGET (widget)' failed(soffice:65238): Gtk-CRITICAL **: 
18:27:10.829: gtk_grid_attach: assertion 'GTK_IS_WIDGET (child)' 
failed(soffice:65238): GLib-GObject-WARNING **: 18:27:10.829: invalid (NULL) 
pointer instance(soffice:65238): GLib-GObject-CRITICAL **: 18:27:10.829: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' 
failed(soffice:65238): GLib-GObject-WARNING **: 18:27:10.829: invalid (NULL) 
pointer instance(soffice:65238): GLib-GObject-CRITICAL **: 18:27:10.829: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed** 
(soffice:65238): CRITICAL **: 18:27:16.425: void 
g_lo_menu_insert_section(GLOMenu *, gint, const gchar *, GMenuModel *): 
assertion 'G_IS_LO_MENU (menu)' failed(soffice:65238): Gtk-CRITICAL **: 
18:27:16.426: gtk_menu_bar_new_from_model: assertion 'G_IS_MENU_MODEL (model)' 
failed(soffice:65238): Gtk-CRITICAL **: 18:27:16.427: 
gtk_widget_insert_action_group: assertion 'GTK_IS_WIDGET (widget)' 
failed(soffice:65238): Gtk-CRITICAL **: 18:27:16.427: gtk_widget_set_hexpand: 
assertion 'GTK_IS_WIDGET (widget)' failed(soffice:65238): Gtk-CRITICAL **: 
18:27:16.427: gtk_grid_attach: assertion 'GTK_IS_WIDGET (child)' 
failed(soffice:65238): GLib-GObject-WARNING **: 18:27:16.427: invalid (NULL) 
pointer instance(soffice:65238): GLib-GObject-CRITICAL **: 18:27:16.427: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' 
failed(soffice:65238): GLib-GObject-WARNING **: 18:27:16.427: invalid (NULL) 
pointer instance(soffice:65238): GLib-GObject-CRITICAL **: 18:27:16.427: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

Re: Owner and group of a newly created file

[Philip Guenther]

On Sun, Jul 1, 2018 at 6:23 AM Thomas Levine <_...@thomaslevine.com> wrote:

> I was just reading about the effect of Set-user-Id and Set-group-Id bits
> on file creation, as they seem like they would be useful for me.
> Unfortunately, most of the documentation I have managed to find is
> related to GNU systems, and this could easily be different in OpenBSD.
>
> https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html


This goes back to a split in behavior between the BSD-derived and
USG-derived ("Unix Systems Group", spun off from AT) systems.
BSD-derived systems always gave new files the group of the directory in
which they were created, while USG-derived systems used the effective
group-id of the process that created the file.  Vendors realized the BSD
behavior is more useful for actual groups of people, but they presumably
didn't feel like they could change the behavior of their existing systems
so they added this "setgid on the directory means follow BSD rules"
behavior.  Linux has always had a more USG/Sys5 flavor to it, so they
followed that rule instead of just making the behavior the Right Thing.



> It appears that they have no effect on file creation. Rather, they a
> only "on execution", as specified in the manual.
> https://man.openbsd.org/chmod


Correct: those bits are ignored by OpenBSD on anything but executable
normal files.



> Very conveniently for me, this behaviour (u-s,g+s in GNU) is the mode
> that I want. Perhaps this is by design.
>

Yep.

Philip Guenther

Owner and group of a newly created file

[Thomas Levine]

I was just reading about the effect of Set-user-Id and Set-group-Id bits
on file creation, as they seem like they would be useful for me.
Unfortunately, most of the documentation I have managed to find is
related to GNU systems, and this could easily be different in OpenBSD.
https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

It appears that they have no effect on file creation. Rather, they a
only "on execution", as specified in the manual.
https://man.openbsd.org/chmod

FreeBSD similarly seems to ignore these settings.
https://www.freebsd.org/doc/handbook/permissions.html

Perhaps this is why there is only GNU documentation on this feature;
it seems that it does not exist in OpenBSD. Am I correct in my
conclusion that files created in OpenBSD are always owned by the creator
and group-owned by the directory's group? That is, a GNU system would
mimic this behaviour when u-s,g+s (6000) is set on the directory?

Suppose, for example, I run this as root.

  mkdir /test
  chown root:wheel /test
  chmod a+rwx,u-s,g-s /test

And then this as tlevine

  touch /test/a

This is the result.

  $ ls -lhd /test{,/a}
  drwxrwxrwx  2 root wheel   512B Jul  1 12:46 /test
  -rw-r--r--  1 tlevine  wheel 0B Jul  1 12:46 /test/a

I repeat the process, except that I set the user and group id this time. As 
root,

  rm -R /test
  mkdir /test
  chown root:wheel /test
  chmod a+rwx,u-s,g-s /test

As tlevine,

  touch /test/a

The resulting /test/a has the same owner and group as before.

  $ ls -lhd /test{,/a}
  drwsrwsrwx  2 root wheel   512B Jul  1 12:48 /test
  -rw-r--r--  1 tlevine  wheel 0B Jul  1 12:48 /test/a

Very conveniently for me, this behaviour (u-s,g+s in GNU) is the mode
that I want. Perhaps this is by design.

Re: State of Yubikey/U2F support on OpenBSD

[Eric Augé]

Hello Rickard,

On Sun, Jul 1, 2018 at 12:30 PM, Rickard von Essen
 wrote:
> Hi Eric,
>
> Thanks for replying. If I can sort out most ykman issues I'll create a port
> for it, which hopefully will make it easier for more people to use
> YubiKeys with OpenBSD.
>
>> A) CCID worked out of the box with a yubikey 4, with pcscd and gpg
>> works fine with it for me, IIRC you can even make it work with GPG
>> without pcscd, but I'd need to verify again.
>
> I have several YubiKey NEO and 4 Nano, but neither of them work with
> CCID, they fails to connect. I'm very interested to see which versions
> you have installed of ykman and dependencies.
>
> I can run OTP commands and "ykman list"
>

I do not use ykman, so I cannot speak about ykman.
ykpers and ykclient were already packaged and worked fine for my use.


> $ ykman list
> YubiKey 4 [OTP+FIDO+CCID] Serial: 5977032
>
> But when I try to list oaths it doesn't connect:
>
> $ ykman -l DEBUG oath list
>
> 2018-07-01T11:43:43+0200 INFO [ykman.logging_setup.setup:59]
> Initialized logging for ykman version: 0.7.1-dev
> 2018-07-01T11:43:43+0200 DEBUG
> [ykman.descriptor.Descriptor.open_device:75] transports: 0x4,
> self.mode.transports: 0x7
> 2018-07-01T11:43:43+0200 DEBUG [ykman.descriptor.open_device:80]
> Opening driver for serial: None, type: YUBIKEY.YK4, mode:
> OTP+FIDO+CCID
> [...]
> 2018-07-01T11:43:47+0200 DEBUG [ykman.descriptor.open_device:82]
> Attempt 10 of 10
> 2018-07-01T11:43:47+0200 DEBUG [ykman.descriptor.open_device:101]
> Sleeping for 1.00 s
> 2018-07-01T11:43:48+0200 DEBUG [ykman.descriptor.open_device:103] No
> matching device found
> Usage: ykman [OPTIONS] COMMAND [ARGS]...
>
> Error: Failed connecting to the YubiKey.
>
> These are the versions I have:
>
> $ ykman version
>
> YubiKey Manager (ykman) version: 0.7.1-dev
> Libraries:
> libykpers 1.18.1
> libusb 1.0.21
>
> $ pkg_info pcscd
>
> Information for inst:pcsc-lite-1.8.22p1
> [...]

Do you run pcscd while running your attempts?

Try shutting it down when you want direct access to the yubikey?
pcscd get a hold of the USB device and AFAIR I cannot use ykpers or
ykclient while pcscd is running, so I'd expect the same with ykman.

HTH,
Eric.

>
> $ pip3.6 show yubikey-manager
>
> Name: yubikey-manager
> Version: 0.7.1.dev0
> Summary: Tool for managing your YubiKey configuration.
> Home-page: https://github.com/Yubico/yubikey-manager
> Author: Dain Nilsson
> Author-email: d...@yubico.com
> License: BSD 2 clause
> Location: 
> /home/rickard/.local/lib/python3.6/site-packages/yubikey_manager-0.7.1.dev0-py3.6.egg
> Requires: six, pyscard, pyusb, click, cryptography, pyopenssl, fido2
>
> $ pip3.6 show pyscard six pyusb click cryptography pyOpenSSL fido2
>
> Name: pyscard
> Version: 1.9.7
> Summary: Smartcard module for Python.
> Home-page: https://github.com/LudovicRousseau/pyscard
> Author: Ludovic Rousseau
> Author-email: ludovic.rouss...@free.fr
> License: UNKNOWN
> Location: 
> /home/rickard/.local/lib/python3.6/site-packages/pyscard-1.9.7-py3.6-openbsd-6.3-amd64.egg
> Requires:
> ---
> Name: six
> Version: 1.11.0
> Summary: Python 2 and 3 compatibility utilities
> Home-page: http://pypi.python.org/pypi/six/
> Author: Benjamin Peterson
> Author-email: benja...@python.org
> License: MIT
> Location: /home/rickard/.local/lib/python3.6/site-packages
> Requires:
> ---
> Name: pyusb
> Version: 1.0.2
> Summary: Python USB access module
> Home-page: http://walac.github.io/pyusb
> Author: Wander Lairson Costa
> Author-email: wander.lair...@gmail.com
> License: BSD
> Location: /home/rickard/.local/lib/python3.6/site-packages
> Requires:
> ---
> Name: click
> Version: 6.7
> Summary: A simple wrapper around optparse for powerful command line utilities.
> Home-page: http://github.com/mitsuhiko/click
> Author: Armin Ronacher
> Author-email: armin.ronac...@active-4.com
> License: UNKNOWN
> Location: /home/rickard/.local/lib/python3.6/site-packages
> Requires:
> ---
> Name: cryptography
> Version: 2.2.2
> Summary: cryptography is a package which provides cryptographic
> recipes and primitives to Python developers.
> Home-page: https://github.com/pyca/cryptography
> Author: The cryptography developers
> Author-email: cryptography-...@python.org
> License: BSD or Apache License, Version 2.0
> Location: /usr/local/lib/python3.6/site-packages
> Requires: idna, asn1crypto, six, cffi
> ---
> Name: pyOpenSSL
> Version: 18.0.0
> Summary: Python wrapper module around the OpenSSL library
> Home-page: https://pyopenssl.org/
> Author: Hynek Schlawack
> Author-email: h...@ox.cx
> License: Apache License, Version 2.0
> Location: /home/rickard/.local/lib/python3.6/site-packages
> Requires: six, cryptography
> ---
> Name: fido2
> Version: 0.3.0
> Summary: Python based FIDO 2.0 library
> Home-page: https://github.com/Yubico/python-fido2
> Author: Dain Nilsson
> Author-email: d...@yubico.com
> License: UNKNOWN
> Location: /home/rickard/.local/lib/python3.6/site-packages
> Requires: six, cryptography
>
> // Rickard
> 

Re: Backup of OpenBSD under VMware

[Bruno Flueckiger]

On 30.06.18 14:23, Paolo Aglialoro wrote:
> Hello,
> 
> the scenario is a cluster of ESXi nodes on which OpenBSD should run as a VM.
> 
> Currently the cluster is being backed up by Veeam, I tried to insert th
> obsd VM inside the backup job but no success, with following "Error: An
> error occurred while saving the snapshot: Failed to quiesce the virtual
> machine.". This looks strange to me because the open-vm-tools implemented
> inside the kernel are usually functional to ESXi hosts.
> 
> Questions:
> 1. has anybody found a way to use Veeam to backup OpenBSD VMs?
> 2. are there any other suggested softwares to perform a similar task?
> 
> Thanks

At $dayjob I use dump(8) and store the files on a Windows file server we
use to store backup files. Then we run Veeam to backup the file server.
The file server is used by my colleagues from the DBA team too to store
database backups on it.

Cheers,
Bruno

Re: State of Yubikey/U2F support on OpenBSD

[Rickard von Essen]

Hi Eric,

Thanks for replying. If I can sort out most ykman issues I'll create a port
for it, which hopefully will make it easier for more people to use
YubiKeys with OpenBSD.

> A) CCID worked out of the box with a yubikey 4, with pcscd and gpg
> works fine with it for me, IIRC you can even make it work with GPG
> without pcscd, but I'd need to verify again.

I have several YubiKey NEO and 4 Nano, but neither of them work with
CCID, they fails to connect. I'm very interested to see which versions
you have installed of ykman and dependencies.

I can run OTP commands and "ykman list"

$ ykman list
YubiKey 4 [OTP+FIDO+CCID] Serial: 5977032

But when I try to list oaths it doesn't connect:

$ ykman -l DEBUG oath list

2018-07-01T11:43:43+0200 INFO [ykman.logging_setup.setup:59]
Initialized logging for ykman version: 0.7.1-dev
2018-07-01T11:43:43+0200 DEBUG
[ykman.descriptor.Descriptor.open_device:75] transports: 0x4,
self.mode.transports: 0x7
2018-07-01T11:43:43+0200 DEBUG [ykman.descriptor.open_device:80]
Opening driver for serial: None, type: YUBIKEY.YK4, mode:
OTP+FIDO+CCID
[...]
2018-07-01T11:43:47+0200 DEBUG [ykman.descriptor.open_device:82]
Attempt 10 of 10
2018-07-01T11:43:47+0200 DEBUG [ykman.descriptor.open_device:101]
Sleeping for 1.00 s
2018-07-01T11:43:48+0200 DEBUG [ykman.descriptor.open_device:103] No
matching device found
Usage: ykman [OPTIONS] COMMAND [ARGS]...

Error: Failed connecting to the YubiKey.

These are the versions I have:

$ ykman version

YubiKey Manager (ykman) version: 0.7.1-dev
Libraries:
libykpers 1.18.1
libusb 1.0.21

$ pkg_info pcscd

Information for inst:pcsc-lite-1.8.22p1
[...]

$ pip3.6 show yubikey-manager

Name: yubikey-manager
Version: 0.7.1.dev0
Summary: Tool for managing your YubiKey configuration.
Home-page: https://github.com/Yubico/yubikey-manager
Author: Dain Nilsson
Author-email: d...@yubico.com
License: BSD 2 clause
Location: 
/home/rickard/.local/lib/python3.6/site-packages/yubikey_manager-0.7.1.dev0-py3.6.egg
Requires: six, pyscard, pyusb, click, cryptography, pyopenssl, fido2

$ pip3.6 show pyscard six pyusb click cryptography pyOpenSSL fido2

Name: pyscard
Version: 1.9.7
Summary: Smartcard module for Python.
Home-page: https://github.com/LudovicRousseau/pyscard
Author: Ludovic Rousseau
Author-email: ludovic.rouss...@free.fr
License: UNKNOWN
Location: 
/home/rickard/.local/lib/python3.6/site-packages/pyscard-1.9.7-py3.6-openbsd-6.3-amd64.egg
Requires:
---
Name: six
Version: 1.11.0
Summary: Python 2 and 3 compatibility utilities
Home-page: http://pypi.python.org/pypi/six/
Author: Benjamin Peterson
Author-email: benja...@python.org
License: MIT
Location: /home/rickard/.local/lib/python3.6/site-packages
Requires:
---
Name: pyusb
Version: 1.0.2
Summary: Python USB access module
Home-page: http://walac.github.io/pyusb
Author: Wander Lairson Costa
Author-email: wander.lair...@gmail.com
License: BSD
Location: /home/rickard/.local/lib/python3.6/site-packages
Requires:
---
Name: click
Version: 6.7
Summary: A simple wrapper around optparse for powerful command line utilities.
Home-page: http://github.com/mitsuhiko/click
Author: Armin Ronacher
Author-email: armin.ronac...@active-4.com
License: UNKNOWN
Location: /home/rickard/.local/lib/python3.6/site-packages
Requires:
---
Name: cryptography
Version: 2.2.2
Summary: cryptography is a package which provides cryptographic
recipes and primitives to Python developers.
Home-page: https://github.com/pyca/cryptography
Author: The cryptography developers
Author-email: cryptography-...@python.org
License: BSD or Apache License, Version 2.0
Location: /usr/local/lib/python3.6/site-packages
Requires: idna, asn1crypto, six, cffi
---
Name: pyOpenSSL
Version: 18.0.0
Summary: Python wrapper module around the OpenSSL library
Home-page: https://pyopenssl.org/
Author: Hynek Schlawack
Author-email: h...@ox.cx
License: Apache License, Version 2.0
Location: /home/rickard/.local/lib/python3.6/site-packages
Requires: six, cryptography
---
Name: fido2
Version: 0.3.0
Summary: Python based FIDO 2.0 library
Home-page: https://github.com/Yubico/python-fido2
Author: Dain Nilsson
Author-email: d...@yubico.com
License: UNKNOWN
Location: /home/rickard/.local/lib/python3.6/site-packages
Requires: six, cryptography

// Rickard
On Sat, 30 Jun 2018 at 12:32, Eric Augé  wrote:
>
> Hello Rickard,
>
> A) CCID worked out of the box with a yubikey 4, with pcscd and gpg
> works fine with it for me, IIRC you can even make it work with GPG
> without pcscd, but I'd need to verify again.
> B) same, chromium crashes, I started investigating but lack the
> knowledge in chromium and I am a bit lost, there are several tickets
> open on chromium side as you mentioned.
> C) I have not tried.
>
> HTH,
> Eric.
>
> On Fri, Jun 29, 2018 at 11:41 AM, Rickard von Essen
>  wrote:
> >
> > I've been experimenting with switching over one of my laptops to OpenBSD, 
> > but
> > there is one main problem stopping me from switching. The support for 
> > Yubikeys
> > and