[Fingerforce-devel] Bug#502138: fprintd: changing back from ITP to RFP

[Luca Capello]

Hi Didier!

On Mon, 14 May 2012 14:29:16 +0200, Didier 'OdyX' Raboud wrote:
> Le 14.05.2012 12:35, Luca Capello a écrit :
>> It seems that the FingerForce SVN repository is no more visible on
>> anonscm.debian.org, while it is still working on my local copy:
>
> I don't mind to use SVN; it's just not really straightforward to see
> where and how one can.

No, no, use Git ;-)

>>> I plan to upload the above (after push of the packaging to collab-maint)
>>> before the end of the week; I would of course welcome co-maintainers and
>>> any comments.
>> 
>> I would prefer to keep everything under the FingerForce umbrella (the
>> fact that this team is not in the form 'pkg-fingerprint' is an
>> unfortunate effect, I would be more than welcome to rename everything!)
>> and I am perfectly fine to move from SVN to Git.
>
> Actually, the repository has Maintainer set as FingerForce, myself as
> uploader. VCS is IMHO implementation detail.

I do not agree: upstream uses Git, so there is no point is using
anything else than Git, because the Debian packaging will simply be a
Git branch.

Please note that 1) I did not checked your package beforehand, sorry,
and 2) my note above is true for any VCS, not only Git.

>> - as I told you in Real Life™, how does today's fprint works WRT PAM
>>   modules, i.e. could you use *both* fingerprint and password
>>   authentication or should you still wait for fingerprint authentication
>>   to fail to enter the password?  This was the major problem I found
>>   when testing fprintd and it is IMHO a show-stopper.
>
> This is addressed by upstream's pam/README:
>
>> * pam_fprintd doesn't support entering either the password or a
>>   fingerprint, as pam_thinkfinger does, because it's a gross hack,
>>   and could be fixed by having the login managers run 2 separate PAM
>>   stacks
>
> So although this might be seen as a showstopper, it is considered by
> upstream as a responsibility of pam, not pam_*.

How to run 2 separate PAM stacks should be at least discussed with the
PAM maintainers, thus also fixing:

  <http://bugs.debian.org/469059>

However, from my very-limited experience with PAM (especially with
libpam-ldapd) the fact that you need 2 separate PAM stacks is against
PAM design, which actually enables delegating "authority" to another
modules.  This is why the bug above is IMHO a show-stopper: I am fine if
pam_fprintd obliges you to use the fingerprint, but this should not be
the default.

>> - how does libpam-fprintd plays with fingerprint-gui (see #666990),
>>   given that the PAM configuration conflicts with it?
>
> No idea, as I haven't tried. That said, I guess they would probably
> conflict (Breaks:) as providing the same functionality and using the
> same libfprint backend.

IMHO if you add a conflict in the PAM configuration file this conflict
should be reflected in the debian/control file as well.

>> - overall, how well is fprintd integrated with the rest of the system?
>
> Gnome is supposed to have fprintd integration since 2.26 and is reported
> to work nicely in Gnome3:
>
> https://nfolamp.wordpress.com/2011/06/24/fedora-15-enabling-the-fingerprint-reader/

I read similar reports in the past (way before fprint), but then in Real
Life™ things were different.

>>   Please note that while fingerprint authentication is nice, it is in
>>   the end more problematic than useful (this is what I found out after
>>   having started with so much enthusiasm), especially considering how
>>   hardware upstream uses USB's VID/PID...
>
> I think it would be good to have a packaged way to experiment that;
> maybe we should target experimental instead.

This is how it was done in the past, but nothing moved from there.

Please do not take my comments as complaint-only: I would like to be
able to use my fingerprint reader again, but when I moved to fprint from
ThinkFinger a lot of stuff stopped working, simply because upstream
thought differently (and the PAM issue above is another example).

>> - actually, I would completely rework the Git repository (again, see
>>   lua-ldap as an example), because:
>> 
>>   1) upstream uses Git as well, thus we should simply start from there
>
> That's what is done; see upstream branch which is the master branch from
> http://cgit.freedesktop.org/libfprint/fprintd.

This is not what I intended, sorry if I was not clear.  The lua-ldap
package should clarify things: given that upstream is using Git, there
is no point in having the Debian package using 'upstream' to refer to
the upstream's 'master' branch.  So in your package 's/master/debian/'
and 's/upstream/master/' ;-)

Feel free to ask to be added to the FingerForce Alioth project!

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/fingerforce-devel/attachments/20120514/692badfa/attachment.pgp>