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
