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-bi
