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

[Michael Biebl]

Am 02.06.2017 um 00:13 schrieb Nicolas Braud-Santoni:

> Since no other workable solutions were proposed, and since Michael made it 
> clear
> that this is not baggage he would carry in udev, I updated the proposed 
> upload:
> 
>   https://anonscm.debian.org/cgit/pkg-auth/libu2f-host.git/log/?h=rfs-848327
> 
> This should take care of all previous comments (and some extras from Sebastian
> Ramacher), though I regret that the bikeshedding made us miss the stretch 
> window.
> 

This is unfortunate indeed that no solution was implemented in time.
I'm willing to apply a one-time fix to udev/systemd so we don't ship
stretch with outdated rules.

Nicolas, please send me a patch against

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/extra/rules/70-debian-uaccess.rules?h=stretch

including all the entries you want to see added for Stretch. I will try
to get this into 9.0 or 9.1 then.

I plan to remove debian/extra/rules/70-debian-uaccess.rules once buster
opens for development. So please get this sorted out for buster.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Nicolas Braud-Santoni]

X-Debbugs-CC: sramac...@debian.org

Hi,

On Sun, Jan 29, 2017 at 10:21:18PM +0100, Michael Biebl wrote:
> To make this perfectly clear (again): I, as udev/systemd maintainer,
> object to maintaining that u2f udev rule as a downstream patch in udev
> and I will remove that patch from src:systemd post stretch. It's simply
> not maintainable (as proven by the outdated rule we ship).
> 
> Possible solutions for you to consider:
> 1/ get those udev rules accepted at systemd upstream (was rejected afair)
> 2/ split the rules out into a -common package which doesn't require
> libu2f-host0 to be installed
> 3/ rework u2f support so it doesn't requires those udev rules.

Since no other workable solutions were proposed, and since Michael made it clear
that this is not baggage he would carry in udev, I updated the proposed upload:

  https://anonscm.debian.org/cgit/pkg-auth/libu2f-host.git/log/?h=rfs-848327

This should take care of all previous comments (and some extras from Sebastian
Ramacher), though I regret that the bikeshedding made us miss the stretch 
window.

There are still a couple of nitpicks: I'm not sure what is the appropriate
Priority for libu2f-udev (optional?) and I need to make a few MultiArch-related
changes, which should be pushed tomorrow.


Best,

  nicoo


signature.asc
Description: PGP signature

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

[Michael Biebl]

Am 29.01.2017 um 22:07 schrieb Luca Capello:
> 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:
>>>
>>>   
>>> 
>>
>> 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:
> 
> 
> 
> - 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+:
> 
> 
> 
> 
> 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:
>>>
>>>   
>>
>> 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:
> 
>   
> 
>> 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.

To make this perfectly clear (again): I, as udev/systemd maintainer,
object to maintaining that u2f udev rule as a downstream patch in udev
and I will remove that patch from src:systemd post stretch. It's simply
not maintainable (as proven by the outdated rule we ship).

Possible solutions for you to consider:
1/ get those udev rules accepted at systemd upstream (was rejected afair)
2/ split the rules out into a -common package which doesn't require
libu2f-host0 to be installed
3/ rework u2f support so it doesn't requires those udev rules.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Luca Capello]

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



- 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+:




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

  

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

  


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):

  


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

  

> > 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:
> > 
> >  
> 
> If the name of the binary package is the only issue, it /could/ be
> renamed 

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

[Luca Capello]

reopen 848327
block 824532 by 846359
user product...@infomaniak.com
usertag 824532 + infomaniak.com-authentication
thanks

Hi there,

sorry for the late reply, the package was rejected:

  


On Fri, 16 Dec 2016 11:58:51 +0100, Nicolas Braud-Santoni wrote:
> I am looking for a sponsor for my package "libu2f-host":

Nicolas, as a (new) member of the pkg-auth team, I can sponsor you
without the need to file RFS bugs for that.

However, can you first push your changes to the Git repository on
Alioth?  I find awkward not to use it for Debian work...

  

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

  

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:

1) U2F devices are seen as *keyboards*, not a special U2F *device*
   (please anyone correct me if I am wrong), and udev already contains
   exceptions with more-specific devices like iDRACs...

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:

 

 

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:

 

FYI, IMHO this is a udev upstream bug.

Thx, bye,
Gismo / Luca

-- 
Luca Capello
Administrateur GNU/Linux

Infomaniak Network SA


signature.asc
Description: Digital signature