Bug#848327: [Pkg-auth-maintainers] Bug#848327: RFS: libu2f-host/1.1.3-1
Hi,
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.
> 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.
> > 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.
- Before this upload, the udev rules were shipped in the libu2f-host0
binary package, which is again wrong. 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),
- 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 ...
> 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.
> 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.
- 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.
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) and provides the first part in fixing it (splitting
off the udev rules in a separate binary package).
Best,
nicoo
Reply to: