Hi there, On Fri, 27 Jan 2017 23:08:08 +0100, Nicolas Braud-Santoni wrote: > On Sun, Dec 25, 2016 at 03:29:39PM +0100, Luca Capello wrote: > > > > sorry for the late reply, the package was rejected: > > > > > > <http://lists.alioth.debian.org/pipermail/pkg-auth-maintainers/Week-of-Mon-20161212/000953.html> > > Sorry for the even-more-late reply, I was ill the last few months :( > > I built a new version of the package > that has updated copyright metadata.
Thank you.
> > However, can you first push your changes to the Git repository on
> > Alioth? I find awkward not to use it for Debian work...
>
> It is in the rfs-848327 branch on alioth.
Again, thank you, two comments not related to the udev rules:
- there are neither upstream/1.1.3 nor debian/1.1.3-1 tags on Alioth,
which BTW is still missing the upstream and pristine-tar branches, so
no new binary packages can be built from the Alioth Git repository:
<https://github.com/Yubico/libu2f-host-dpkg/branches>
- the previous rejection was because of a new license for the CLI tools,
while in the debian/changelog you actually talk about the library
itself, which has always been LGPL-2+:
<https://github.com/Yubico/libu2f-host/commit/9f53f3ccf81d3e5029eca863014714bf217914e1>
Both issues should be corrected for me to sponsor your upload.
> > > This updates brings:
> > > - - a fix for #846358, so that rules for the right udev version are
> > > installed;
> > > - - as per #846359 and #824532, this creates a new binary package,
> > > libu2f-common, containing the udev rules;
> > > - - the new upstream version brings udev rules for additional devices.
> >
> > Sorry, I still do not see the reasoning behing such a move:
> >
> > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824532#42>
>
> Well, that one is simple:
>
> - #846358 is a bug, pure and simple, and this fixes it.
As far as I know, no one has never objected to this and the fix does not
involve touching anything else WRT the current logic.
> - Before this upload, the udev rules were shipped in the libu2f-host0
> binary package, which is again wrong.
It depends, it would be OK if access to these devices was only possible
via libu2f-host0, which is not the case here:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824532#17>
> There are two options, then
>
> 1. keeping the udev rules in the libu2f-host *source* package
> 2. moving the udev rules to another source package
>
>
> I am strongly in favor of 1, if only because upstream actually maintains
> that list in this package. The alternative involves
> - repackaging libu2f-host to get rid of this
> (and patching the build/install scripts),
Sorry? No need to repack or patch anything from upstream, but simple do
not install the udev rules in a .deb package.
> - adding the udev rules to some other package,
> likely as a Debian patch,
> - and keeping the udev rules up-to-date in that other package,
> manually, forever.
>
> Moreover, in the case where the other source package is udev,
> this adds a lot of synchronisation overhead in maintaining libu2f-host
> because I can't just push the udev rules in udev's packaging repo
> and upload a new version of the package ...
Thanks to Andreas Gnau for the upstream bug:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848327#40>
<https://github.com/systemd/systemd/issues/102>
I find interesting that the end user has been waiting for more than 2
years now for the specific U2F kernel driver (and I guess/hope the right
permissions):
<http://lists.freedesktop.org/archives/systemd-devel/2014-November/024824.html>
> > Mickael or Martin (both Bcc:ed), can you elaborate a bit more, please?
> > Yes, I have read the full bug and I fully agree with Robert and Simon
> > (both Bcc:ed), moreover:
> >
> > [...]
> >
> > 2) U2F devices are becoming more and more frequent and they are
> > considered by at least Google (who, to be fair, co-developed the
> > standard) to be the more secure 2FA mechanism:
> >
> >
> > <http://arstechnica.com/security/2016/12/this-low-cost-device-may-be-the-worlds-best-hope-against-account-takeovers/>
> > <http://fc16.ifca.ai/preproceedings/25_Lang.pdf>
>
> I'm not sure I see the point there.
The point is that I am expecting more and more people using such
devices, which means that someone plugs her U2F device into a GNU/Linux
system and it can not use it in the web browser because of the missing
permissions.
Robert Norris explained very clearly where such permissions belong to:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824532#17>
> > 3) some of them are even more than that (e.g. the YubiKey 4 which also
> > contains an OpenPGP smartcard), which justify the fact that udev
> > rules do not belong to any U2F-specific package:
> >
> > <https://wiki.debian.org/Smartcards/YubiKey4#udev>
>
> If the name of the binary package is the only issue, it /could/ be
> renamed udev-rules-for-crypto-hipsterdingen (or likely some better
> name, but it is late and I'm tired).
>
>
> All in all, I do not understand what are you precise objections
> to that solution.
>
> - Is the name of the libu2f-common binary package the issue?
> If so, I will happily take better suggestions, but I would
> have rather not spent so much time on a bikeshed.
No, and I find quite interesting that you classify 'bikeshedding' a bug
that has been opened more than 2 years ago first in Ubuntu...
<https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1387908>
...then in upstream udev by a different person...
<https://github.com/systemd/systemd/issues/102>
...then fixed in Debian/Ubuntu...
<https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=09b5bcb064>
...and finally got an update on Debian:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848327#40>
> - Is it that the udev rules live in the libu2f-host source package?
> Then, I would suggest taking up the issue with upstream: the better
> solution would likely be to have a separate repository containing
> udev rules for crypto tokens.
Yes, and indeed I had already planned to talk to libu2f-host upstream
about this. Nevertheless, please note that, if not upstream, at least
another pkg-auth team member, Simon Josefsson, is not so keen in keeping
such udev rules is libu2f-host:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824532#61>
For the udev upstream, this has already been taken care of,
unsuccessfully, and nevertheless the systemd *Debian/Ubuntu* maintainers
did the right thing WRT to the end user.
> Also, I do not see why this would be a blocker for this upload:
> it doesn't create the issue (the udev rules already existed in the
> source package)
Which does not mean anything if we provide such rules elsewhere. D'oh,
this is BTW already the case since udev >= 229-6 (2016-05-12, currently
jessie-backports has 230-7~bpo8+2).
Actually, for stretch rules provided by the debpkg:udev could be
considered even better from an end user POV, since they use
systemd-logind's uaccess tag and not the plugdev group: on a standard
Debian user installation, any user sitting in front of the computer will
automatically have access to the U2F device. This is #846358.
To be fair, the only 2 devices currently missing on the debpkg:udev
rules are the Neowave AES 1e0d:f1ae and the Feitian ePass FIDO
096e:0850.
> and provides the first part in fixing it (splitting
> off the udev rules in a separate binary package).
A new binary package for one single file of less than 1kb (in part)
already shipped by a binary package installed by default.
Thx, bye,
Gismo / Luca
--
Luca Capello
Administrateur GNU/Linux
Infomaniak Network SA
signature.asc
Description: Digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
