Re: [new] devel/efivar

On Wed, Apr 26, 2023 at 05:33:15PM +0100, Stuart Henderson wrote:
> On 2023/04/23 01:15, Sergii Dmytruk wrote:
> > Hello,
> >
> > Continuing with bringing fwupd to BSD systems [1].
> >
> > [1]: https://nlnet.nl/project/fwdup-BSD/
> >
> > Now that /dev/efi is available, efivar port with several libraries and
> > binaries can be added to make use of it. efivar itself is a dependency
> > of fwupd's uefi_capsule plugin which is used to update UEFI firmware of
> > the host.
> >
> > To address a few comments from tech@openbsd.org which are more relevant
> > here:
> >
> > Stuart Henderson wrote:
> > > I found the git repo with fwupd/libgusb/libjcat/libxmlb and have tweaked
> > > them a bit according to normal ports standards and set it up to install
> > > the /etc files for fwupd. tar attached.
> > >
> > > Might still be some things missing and I haven't tested beyond building
> > > but this might help others test things.
> >
> > Thanks for doing this. Keep in mind that the port has uefi_capsule
> > plugin disabled as kernel support for ESRT and EFI variables was missing
> > at the time porting was first attempted.
> >
> > Landry Breuil wrote:
> > > I suppose from all those things, the libexec/fwupd binary
> > > daemon will be spawned as root by systemwide dbus/messagebus to access
> > > /dev/efi ? like other needing-root daemons like upowerd & al, with
> > > access managed by polkit..
> >
> > That's one way of using it. There is also a daemon-less way (fwupdtool
> > binary). Given that EFI variables are writeable only in single-user
> > mode, fwupd daemon won't be able to initiate system's firmware update,
> > but it can be used to update other devices as well as to check for UEFI
> > firmware updates.
> >
> > efivar port attached.
> >
> > Best regards,
> > Sergii
>
> New tgz attached with tweaks:
>
> - we can't use -march=native in package builds
> - shared lib versions must be under control of the SHARED_LIBS variable
> - don't install shlib symlinks
> - use category 'sysutils' not 'devel'
>
> ports-wise I'm happy with it, but I tried running 'efivar -l' as root
> and hit a kernel panic but I am on a kernel from a couple of days ago
> and there's a hackathon on, so that might not have been directly related
> to efivar / /dev/efi and might have already been fixed, will retest on a
> newer kernel sometime later or tomorrow.
>

As normal user, I'd expect EACCES or EPERM, the current warning misleads:
$ efivar -l
efivar: error listing variables: Function not implemented

As root it also panics my box on today's snap, but stuff's broken anyway:
OpenBSD 7.3-current (GENERIC.MP) #1166: Wed Apr 26 21:25:03 MDT 2023

Port-wise, this is OK kn, but please hold off with import until we sort
out the panics, of course.

We point GH_* at the BSD fork and HOMEPAGE at Linux upstream.
Would it be better to drop HOMEAGE, i.e. stick with the fork and adjust
its description on GitHub so that actually becomes obvious from reading
the "homepage"?

Are the spaces in SHARED_LIBS intended?