Bug 122357 - sys-auth/pam_pkcs11 - handle fork correctly
|
Bug#:
122357
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: crypto@gentoo.org
|
Reported By: alonbl@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: sys-auth/pam_pkcs11 - handle fork correctly
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-02-10 04:58 0000
|
Hello,
Congratulations for adding this ebuild!!! I posted an ebuild a long time ago
(bug#95962).
Reported this issue to upstream long ago...
Please consider to add attached patch:
After fork, PKCS#11 should be reinitialized, this is stated explicitly in
PKCS#11 standard.
Best Regards,
Alon Bar-Lev.
One last comment...
I believe that pam_pkcs11 should be placed in a different branch, since it is
not a development tool.
The move is now done, it was already requested actually.
Removing pam-bugs from CC as this package is under crypto herd and the change
doesn't seem to relate to PAM itself.
Alon, whenever you post a patch you should identify it's origin. Who wrote it,
where did it come from? They should be credited in the changelog entry that
goes along with the commit, so the information needs to be available on the
bug.
Ideally the patch should already be included in the upstream development tree -
whenever it is the case then the ebuild maintainer doesn't really have to think
twice about including it in Gentoo - its quality is confirmed. So, if this
patch has come from upstream, say so.
If it hasn't, have you sent it there? It's usually best to send it upstream
before getting it included in Gentoo, or maybe doing both at the same time.
Personally I always wait for patches to be accepted upstream before adding
them, but that's just me. If you send it to a public mailing list, it's also a
good idea to post the URL to the thread.
(In reply to comment #5)
> Alon, whenever you post a patch you should identify it's origin. Who wrote it,
Me.
> where did it come from?
My mind :)
> They should be credited in the changelog entry that
> goes along with the commit, so the information needs to be available on the
> bug.
OK.
> Ideally the patch should already be included in the upstream development tree -
> whenever it is the case then the ebuild maintainer doesn't really have to think
> twice about including it in Gentoo - its quality is confirmed. So, if this
> patch has come from upstream, say so.
No.
Upstream is not receptive.
In the past pam_pkcs11 was a separate component, I've mailed the developered
this patch, but no reply.
Then pam_pkcs11 became hosted on opensc project. I thought someone will take it
over.
Then they redo the site and added ticket system, so I've open a ticket.
http://www.opensc-project.org/pam_pkcs11/ticket/14
And nothing.
> If it hasn't, have you sent it there? It's usually best to send it upstream
> before getting it included in Gentoo, or maybe doing both at the same time.
> Personally I always wait for patches to be accepted upstream before adding
> them, but that's just me. If you send it to a public mailing list, it's also a
> good idea to post the URL to the thread.
I agree...
This is what I am doing.
But if upstream is not receptive, I think major issues like this one should be
fixed.
There is no question that what they are doing violates PKCS#11 standard.
They have some more major problems in the slotevent component... But people can
live with it.
fixed. Thanks for being persistent.
