[Pkg-auth-maintainers] Bug#846359: Bug#848327: RFS: libu2f-host/1.1.3-1

[Nicolas Braud-Santoni]

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