Menu
▾
▴
opensc-devel — discussion of developement of OpenSC and related projects
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(26) |
Feb
(64) |
Mar
(78) |
Apr
(36) |
May
(51) |
Jun
(40) |
Jul
(43) |
Aug
(102) |
Sep
(50) |
Oct
(71) |
Nov
(42) |
Dec
(29) |
| 2014 |
Jan
(49) |
Feb
(52) |
Mar
(56) |
Apr
(30) |
May
(31) |
Jun
(52) |
Jul
(76) |
Aug
(19) |
Sep
(82) |
Oct
(95) |
Nov
(58) |
Dec
(76) |
| 2015 |
Jan
(135) |
Feb
(43) |
Mar
(47) |
Apr
(72) |
May
(59) |
Jun
(20) |
Jul
(17) |
Aug
(14) |
Sep
(34) |
Oct
(62) |
Nov
(48) |
Dec
(23) |
| 2016 |
Jan
(18) |
Feb
(55) |
Mar
(24) |
Apr
(20) |
May
(33) |
Jun
(29) |
Jul
(18) |
Aug
(15) |
Sep
(8) |
Oct
(21) |
Nov
(5) |
Dec
(23) |
| 2017 |
Jan
(3) |
Feb
|
Mar
(17) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(20) |
Sep
(17) |
Oct
(21) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(62) |
Feb
(4) |
Mar
(4) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
|
Dec
(5) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(14) |
Feb
(21) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2023 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Klas L. <kl...@yu...> - 2015-09-02 10:38:34
|
Hello, How does Yubico see the Neo being used if it has both a PIV and OpenPGP > application? > >From Yubico's (or at least my) perspective the thinking around the applications is that PIV is used through OpenSC/Windows and OpenPGP is used through gnupg. Our perspective has been that they're typically not used at the same time. > Is one default? > How is the default set? > Can the default be set on the card? > We've not thought of one of those two as default, more as options depending on what the user wants / what the application supports. There is no default selected applet on the Neo, and it can't be set. > > The Neo presents the same ATR for both. The Neo does not take advantage of > the ATR Historical bytes. > No, we've not used the ATR at all to advertise what applications are present, the ATR is also different over the contactless interface. > Are there end users who want to use both, at the same time? > There has been questions about this, not very common and we've not come up with a good solution for it. > > Has Yubico look at presenting the Neo as two devices on the UCB bus with a > different ATRs for the > OpenPGP and PIV applications? (Historical bytes including the AID?) > It's an interesting idea, I'm not sure how practical it is (due to several issues) but I'm happy to discuss possible solutions to simultaneous use. > > The OpenSC PIV drivers checks for the PIV AID. The OpenSC OpenPGP driver > has not, but issue #507 is trying to address this. > I've always found checking for AID to be more exact, but that's coming from and angle where multiple applications can be loaded and you can't really tell from the ATR exactly what applications might be found on a specific card. > > Does Yubico developers follow the OpenSC discussions? > I try to follow opensc-devel for relevant stuff and keep up to date with what happens in the code. > Do they test OpenSC with their devices? > As I wrote above our view is that the PIV parts of YubiKey devices should work with OpenSC we test that. > > > Thanks. > Thank you! /klas |
|
From: Douglas E E. <dee...@gm...> - 2015-09-01 15:59:57
|
There has been a discussion among the OpenSC developers on how to support the Neo with the PIV application and the OpenPGP applications. https://github.com/OpenSC/OpenSC/pull/507 https://github.com/OpenSC/OpenSC/issues/538 Some of the issues include: How does Yubico see the Neo being used if it has both a PIV and OpenPGP application? Is one default? How is the default set? Can the default be set on the card? The Neo presents the same ATR for both. The Neo does not take advantage of the ATR Historical bytes. Are there end users who want to use both, at the same time? Has Yubico look at presenting the Neo as two devices on the UCB bus with a different ATRs for the OpenPGP and PIV applications? (Historical bytes including the AID?) The OpenSC PIV drivers checks for the PIV AID. The OpenSC OpenPGP driver has not, but issue #507 is trying to address this. The OpenSC developer community consists mostly of individual developers or companies that are interested in only one card or application. Very few have the ability to test more then a few cards with their favorite application or how modifications to OpenSC affect other cards or other applications they don't have. Does Yubico developers follow the OpenSC discussions? Do they test OpenSC with their devices? I would like to hear from Yubico on these issues. Either on the OpenSC-devel list or via comments on the above Gihhub issues. Thanks. -- Douglas E. Engert <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2015-09-01 15:50:37
|
There has been a discussion among the OpenSC developers on how to support the Neo with the PIV application and the OpenPGP applications. https://github.com/OpenSC/OpenSC/pull/507 https://github.com/OpenSC/OpenSC/issues/538 Some of the issues include: How does Yubico see the Neo being used if it has both a PIV and OpenPGP application? Is one default? How is the default set? Can the default be set on the card? The Neo presents the same ATR for both. The Neo does not take advantage of the ATR Historical bytes. Are there end users who want to use both, at the same time? Has Yubico look at presenting the Neo as two devices on the UCB bus with a different ATRs for the OpenPGP and PIV applications? (Historical bytes including the AID?) The OpenSC PIV drivers checks for the PIV AID. The OpenSC OpenPGP driver has not, but issue #507 is trying to address this. The OpenSC developer community consists mostly of individual developers or companies that are interested in only one card or application. Very few have the ability to test more then a few cards with their favorite application or how modifications to OpenSC affect other cards or other applications they don't have. Does Yubico developers follow the OpenSC discussions? Do they test OpenSC with their devices? I would like to hear from Yubico on these issues. Either on the OpenSC-devel list or via comments on the above Gihhub issues. Thanks. -- Douglas E. Engert <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2015-09-01 13:21:32
|
There has been a discussion among the OpenSC developers on how to support the Neo with the PIV application and the OpenPGP applications. https://github.com/OpenSC/OpenSC/pull/507 https://github.com/OpenSC/OpenSC/issues/538 Some of the issues include: How does Yubico see the Neo being used if it has both a PIV and OpenPGP application? Is one default? How is the default set? Can the default be set on the card? The Neo presents the same ATR for both. The Neo does not take advantage of the ATR Historical bytes. Are there end users who want to use both, at the same time? Has Yubico look at presenting the Neo as two devices on the UCB bus with a different ATRs for the OpenPGP and PIV applications? (Historical bytes including the AID?) The OpenSC PIV drivers checks for the PIV AID. The OpenSC OpenPGP driver has not, but issue #507 is trying to address this. The OpenSC developer community consists mostly of individual developers or companies that are interested in only one card or application. Very few have the ability to test more then a few cards with their favorite application or how modifications to OpenSC affect other cards or other applications they don't have. Does Yubico developers follow the OpenSC discussions? Do they test OpenSC with their devices? I would like to hear from Yubico on these issues. Either on the OpenSC-devel list or via comments on the above Gihhub issues. Thanks. -- Douglas E. Engert <DEE...@gm...> |
|
From: Nikos M. <n.m...@gm...> - 2015-08-25 07:48:50
|
On Mon, Aug 24, 2015 at 10:05 PM, Ludovic Rousseau <lud...@gm...> wrote: >> These libraries do get quite little attention and "developer discretion" >> might be justified, but eventually developers must make their own >> judgements. >> Also, why don't you roll a new release? Whoever uses them for real life >> apps is probably the best to answer questions about usability and >> releasability. >> (The above should be read that if nobody objects and Nikos is willing, >> he should be granted release access to these two projects.) > I fully agree. > Nikos, do you volunteer as libp11 and engine_pkcs11 maintainer/release manager? No, I'll only plan and make the next release. Whether I'll be able to follow up is not clear to me. regards, Nikos |
|
From: Ludovic R. <lud...@gm...> - 2015-08-24 20:05:30
|
Hello, 2015-08-24 10:55 GMT+02:00 Martin Paljak <ma...@ma...>: > On 24/08/15 11:15, Nikos Mavrogiannopoulos wrote: >> Hello, >> These two projects had several years to have a release and as it is >> now distributions ship versions of it with various different patches >> applied each, enabling different features each. Fortunately (or not) >> there is popular software depending on engine_pkcs11 (and thus >> libp11), making these two libraries quite important. I've opened [0] >> and [1], but I'm not sure whether there is any developer active on >> these components. If there is, would it be possible to have a release >> on these components? Otherwise, would it make sense to mark these >> projects as obsolete or abandonware so that no new projects start >> depending on them? > > These libraries do get quite little attention and "developer discretion" > might be justified, but eventually developers must make their own > judgements. > > Also, why don't you roll a new release? Whoever uses them for real life > apps is probably the best to answer questions about usability and > releasability. > > (The above should be read that if nobody objects and Nikos is willing, > he should be granted release access to these two projects.) I fully agree. Nikos, do you volunteer as libp11 and engine_pkcs11 maintainer/release manager? Bye -- Dr. Ludovic Rousseau |
|
From: Ludovic R. <lud...@gm...> - 2015-08-24 20:01:23
|
2015-08-23 23:46 GMT+02:00 Martin Paljak <ma...@ma...>: > On 02/08/15 21:59, Douglas E Engert wrote: >> Github used to show both Jenkins and Travis-ci checks for a pull request. >> Today it is only showing the travis-ci. > There's also "Travis for Windows": > > https://ci.appveyor.com/ > > Adding support for this would also be great. A contributor (Alex Willmer) added support of AppVeyor to PySCard [2]. So Windows installers are built automatically [1]. No, I do not volunteer to do the same for OpenSC :-) Bye [1] https://ci.appveyor.com/project/LudovicRousseau/pyscard [2] https://github.com/LudovicRousseau/pyscard -- Dr. Ludovic Rousseau |
|
From: Martin P. <ma...@ma...> - 2015-08-24 08:55:34
|
On 24/08/15 11:15, Nikos Mavrogiannopoulos wrote: > Hello, > These two projects had several years to have a release and as it is > now distributions ship versions of it with various different patches > applied each, enabling different features each. Fortunately (or not) > there is popular software depending on engine_pkcs11 (and thus > libp11), making these two libraries quite important. I've opened [0] > and [1], but I'm not sure whether there is any developer active on > these components. If there is, would it be possible to have a release > on these components? Otherwise, would it make sense to mark these > projects as obsolete or abandonware so that no new projects start > depending on them? These libraries do get quite little attention and "developer discretion" might be justified, but eventually developers must make their own judgements. Also, why don't you roll a new release? Whoever uses them for real life apps is probably the best to answer questions about usability and releasability. (The above should be read that if nobody objects and Nikos is willing, he should be granted release access to these two projects.) Martin |
|
From: Nikos M. <n.m...@gm...> - 2015-08-24 08:15:46
|
Hello, These two projects had several years to have a release and as it is now distributions ship versions of it with various different patches applied each, enabling different features each. Fortunately (or not) there is popular software depending on engine_pkcs11 (and thus libp11), making these two libraries quite important. I've opened [0] and [1], but I'm not sure whether there is any developer active on these components. If there is, would it be possible to have a release on these components? Otherwise, would it make sense to mark these projects as obsolete or abandonware so that no new projects start depending on them? regards, Nikos [0]. https://github.com/OpenSC/libp11/issues/20 [1]. https://github.com/OpenSC/engine_pkcs11/issues/18 |
|
From: Nikos M. <n.m...@gm...> - 2015-08-24 07:40:30
|
On Sun, Aug 23, 2015 at 11:15 PM, Martin Paljak <ma...@ma...> wrote: > Hello, > I created a repository for hosting static content with Github pages and > will forward the domain as well after some discussion here. > My proposal would be to make a "landing page" for OpenSC (a visually > more appealing version of https://github.com/OpenSC/OpenSC/releases) Yes, a static web page would be much better as entry page than the current wiki pages. regards, Nikos |
|
From: Martin P. <ma...@ma...> - 2015-08-24 05:49:34
|
On 24/08/15 08:38, Petr Pisar wrote: > What will happen with all these (sometimes out-dated) pages > <https://www.opensc-project.org/opensc/wiki/TitleIndex>? They are available from Github? Trac naming, formatting and also visibility/readability is IMHO superior to what Github wiki offers (I really like Github, but IMHO the wiki sucks , not only because it comes with "aol toolbar"-grade chrome and is narrow as hell on modern wide screens). Martin |
|
From: Petr P. <pet...@at...> - 2015-08-24 05:38:19
|
On Mon, Aug 24, 2015 at 12:15:17AM +0300, Martin Paljak wrote: > Hello, > > I created a repository for hosting static content with Github pages and > will forward the domain as well after some discussion here. > > My proposal would be to make a "landing page" for OpenSC (a visually > more appealing version of https://github.com/OpenSC/OpenSC/releases) > > Any thoughts? > What will happen with all these (sometimes out-dated) pages <https://www.opensc-project.org/opensc/wiki/TitleIndex>? -- Petr |
|
From: Martin P. <ma...@ma...> - 2015-08-23 21:46:31
|
On 02/08/15 21:59, Douglas E Engert wrote: > Github used to show both Jenkins and Travis-ci checks for a pull request. > Today it is only showing the travis-ci. There's also "Travis for Windows": https://ci.appveyor.com/ Adding support for this would also be great. Martin |
|
From: Martin P. <ma...@ma...> - 2015-08-23 21:15:28
|
Hello, I created a repository for hosting static content with Github pages and will forward the domain as well after some discussion here. My proposal would be to make a "landing page" for OpenSC (a visually more appealing version of https://github.com/OpenSC/OpenSC/releases) Any thoughts? Martin |
|
From: Bruno B. <as...@as...> - 2015-08-16 12:48:55
|
On Sat 15 Aug, Jaroslav Imrich wrote: > Hello Bruno, > > please take a look at a previous discussion [0] on this topic. > > [0] http://sourceforge.net/p/opensc/mailman/message/33621883/ > > Regards, Jaroslav Thanks you very much Jaroslav! I'm now able to fix my bricked token! For information I used an usb key created with Ubuntu 12 32bits. It doesn't work on my Debian Sid. Regards > -- http://asyd.net/home/ - Home Page http://netvibes.com/asyd - Portal |
|
From: Jaroslav I. <jar...@gm...> - 2015-08-15 17:36:05
|
Hello Bruno, please take a look at a previous discussion [0] on this topic. [0] http://sourceforge.net/p/opensc/mailman/message/33621883/ Regards, Jaroslav On Sat, Aug 15, 2015 at 6:58 PM, Bruno Bonfils <as...@as...> wrote: > Hello folks, > > I just bougth some ePass2003 tokens but I screw one of them by trying to > reformat it with a SO-Pin. > > By chance, anyone have a copy of [1]? > > And by the way, the profile epass2003 in OpenSC 0.15 (Debian Sid) gave > me the following error: > > 0x7f7a6d7eb700 23:40:58.040 [pkcs15-init] profile.c:2453:parse_error: > /usr/share/opensc/epass2003.profile: No path/fileid set for parent DF > > Should I fill a bug? > > Thanks > > [1] http://download.gooze.eu/pki/feitian/epass-2003/fix_tool.tar.gz > > -- > http://asyd.net/home/ - Home Page > http://netvibes.com/asyd - Portal > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: Bruno B. <as...@as...> - 2015-08-15 16:58:58
|
Hello folks, I just bougth some ePass2003 tokens but I screw one of them by trying to reformat it with a SO-Pin. By chance, anyone have a copy of [1]? And by the way, the profile epass2003 in OpenSC 0.15 (Debian Sid) gave me the following error: 0x7f7a6d7eb700 23:40:58.040 [pkcs15-init] profile.c:2453:parse_error: /usr/share/opensc/epass2003.profile: No path/fileid set for parent DF Should I fill a bug? Thanks [1] http://download.gooze.eu/pki/feitian/epass-2003/fix_tool.tar.gz -- http://asyd.net/home/ - Home Page http://netvibes.com/asyd - Portal |
|
From: Douglas E E. <dee...@gm...> - 2015-08-02 19:05:36
|
Github used to show both Jenkins and Travis-ci checks for a pull request.
Today it is only showing the travis-ci.
The ability for a developer to submit a pull request and get a windows MSI file for testing is a big advantage to
doing self testing without having to have a full windows build environment.
What happened to the Jenkins checks?
For pull requests, it looks Jenkins was working as of July 27:
https://opensc.fr/jenkins/view/OpenSC-pull-request/
https://opensc.fr/jenkins/view/OpenSC-pull-request/job/OpenSC-pr-win64/
https://github.com/OpenSC/OpenSC/pull/483
Shows:
All checks have passed
2 successful checks
Clicking on "Show All Requests":
continuous-integration/travis-ci/pr — The Travis CI build passed Details
default — Merged build finished. Details
The last Details points at:
https://opensc.fr/jenkins/job/OpenSC-pr-master/573/
--
Douglas E. Engert <DEE...@gm...>
|
|
From: Ludovic R. <lud...@gm...> - 2015-07-28 16:03:00
|
2015-07-28 17:20 GMT+02:00 Frank Morgner <mo...@in...>: > Hi! > >> > pcsc-lite allocates some memory on the client side and also on the server side. >> > After a fork the memory on the client side is duplicated, but nothing >> > changes on the server side. >> > >> > Calling SCardReleaseContext will release the memory on 1 client and on >> > the server. >> > A second call to SCardReleaseContext will try to free resources on the >> > server side but the server will then return an error (resources >> > already freed). The memory on the client side will then NOT be freed. >> > >> > I can change the pcsc-lite code to free memory on the client side >> > first before asking the server to free its memory. With this change a >> > second call to SCardReleaseContext would still return an error but the >> > memory on the client would be freed. >> > >> > That would solve a memory leak when fork() is used. >> > I created a ticket >> > https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085 >> >> In fact I was wrong in my interpretation. >> >> pcsc-lite will NOT fail to free the memory on the client side. The >> second time SCardReleaseContext() is called it will return >> SCARD_E_INVALID_VALUE but the client side memory is _also_ released. >> >> pcsc-lite will not leak memory in this case. > > That's nice. However, it doesn't solve the problem: Since the process > which frees the handle first is the process that doesn't need the > handle. For the process that may still use its copy of the handle, the > server side is not available anymore. > > When looking at file descriptors (within a process) and file > descriptions (within the kernel) the problem has been solved by not > having any additional memory in the client. A file descriptor is simply > an integer that does not need to be deallocated. Would that be an option > for PCSC-Lite? pcscd is not aware that the client process has forked. I am not sure to know what to do with PC/SC handles in a forked process. It is the responsibility of the PC/SC application to not do unspecified things. Even a file descriptor is not a solution: - A program opens a file then fork. - Father and son can now write to the same file. Strange things will happen if father and son do not work collaboratively. Bye -- Dr. Ludovic Rousseau |
|
From: Frank M. <mo...@in...> - 2015-07-28 15:20:59
|
Hi! > > pcsc-lite allocates some memory on the client side and also on the server side. > > After a fork the memory on the client side is duplicated, but nothing > > changes on the server side. > > > > Calling SCardReleaseContext will release the memory on 1 client and on > > the server. > > A second call to SCardReleaseContext will try to free resources on the > > server side but the server will then return an error (resources > > already freed). The memory on the client side will then NOT be freed. > > > > I can change the pcsc-lite code to free memory on the client side > > first before asking the server to free its memory. With this change a > > second call to SCardReleaseContext would still return an error but the > > memory on the client would be freed. > > > > That would solve a memory leak when fork() is used. > > I created a ticket > > https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085 > > In fact I was wrong in my interpretation. > > pcsc-lite will NOT fail to free the memory on the client side. The > second time SCardReleaseContext() is called it will return > SCARD_E_INVALID_VALUE but the client side memory is _also_ released. > > pcsc-lite will not leak memory in this case. That's nice. However, it doesn't solve the problem: Since the process which frees the handle first is the process that doesn't need the handle. For the process that may still use its copy of the handle, the server side is not available anymore. When looking at file descriptors (within a process) and file descriptions (within the kernel) the problem has been solved by not having any additional memory in the client. A file descriptor is simply an integer that does not need to be deallocated. Would that be an option for PCSC-Lite? -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: Ludovic R. <lud...@gm...> - 2015-07-28 13:26:36
|
2015-07-06 9:27 GMT+02:00 Ludovic Rousseau <lud...@gm...>: > 2015-07-06 2:07 GMT+02:00 Frank Morgner <mo...@in...>: >> I think we have two problems here: >> >> 1. The only thing we should do is freeing the memory which gets copied >> into the child's address space. And that's where I think we have a >> problem in pcsc-lite: >> >> I don't know the inner workings of pcsc-lite but I suppose when >> calling SCardEstablishContext there will be some memory that can only >> be free'd by calling SCardReleaseContext. This memory will exist in >> the parent's and in the child's address space. But with David's log >> it looks like pcsc-lite has a sanity check that disallows freeing the >> same handle twice in SCardReleaseContext. > > You are right. > pcsc-lite allocates some memory on the client side and also on the server side. > After a fork the memory on the client side is duplicated, but nothing > changes on the server side. > > Calling SCardReleaseContext will release the memory on 1 client and on > the server. > A second call to SCardReleaseContext will try to free resources on the > server side but the server will then return an error (resources > already freed). The memory on the client side will then NOT be freed. > > I can change the pcsc-lite code to free memory on the client side > first before asking the server to free its memory. With this change a > second call to SCardReleaseContext would still return an error but the > memory on the client would be freed. > > That would solve a memory leak when fork() is used. > I created a ticket > https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085 In fact I was wrong in my interpretation. pcsc-lite will NOT fail to free the memory on the client side. The second time SCardReleaseContext() is called it will return SCARD_E_INVALID_VALUE but the client side memory is _also_ released. pcsc-lite will not leak memory in this case. Bye -- Dr. Ludovic Rousseau |
|
From: <J.W...@mi...> - 2015-07-16 12:10:33
|
Question remains _if_ you want to use the ssh-keys directly from openssh.... In the commercial version of openssh you seems to be able to use the entire openssl-tool chain for key's and certificates And there used to be a patch for the community version of openssh (Roumen Petrov) with the possibility of tokens/smartcards See: http://roumenpetrov.info/openssh latest patch version: 1 jul 2015, so it is still maintained. Hw -----Original Message----- From: Douglas E Engert [mailto:dee...@gm...] Sent: donderdag 16 juli 2015 13:39 To: OpenSC-devel Subject: [Opensc-devel] Fwd: Smart Card support OpenSC developers may wish to comment on this OpenSSH note. -------- Forwarded Message -------- Subject: Smart Card support Date: Thu, 16 Jul 2015 10:37:10 +0200 From: Jakub Jelen <jj...@re...> To: ope...@mi... Hi all, I was investigating openssh functionality with Smart Cards of different types from different vendors and there appeared few problems that would be great if they would be solved before 7.0 release. I filled bugs for them to keep track of them in openssh bugzilla Bug 2427 - ssh keygen is trying to read uninitialized slots on smart card (and is failing) [1] Bug 2429 - ssh-keygen ignores keys that have CKA_ID == 0 [2] Bug 2430 - ssh-keygen should allow to login before reading public key from smart card [3] Is there somebody who would be able to review the proposed changes and comment on the last one, what solution would be better? Then I can propose also some patch. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2427 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2429 [3] https://bugzilla.mindrot.org/show_bug.cgi?id=2430 Best regards, -- Jakub Jelen Security Technologies Red Hat _______________________________________________ openssh-unix-dev mailing list ope...@mi... https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Opensc-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opensc-devel ______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. |
|
From: Douglas E E. <dee...@gm...> - 2015-07-16 11:45:27
|
OpenSC developers may wish to comment on this OpenSSH note. -------- Forwarded Message -------- Subject: Smart Card support Date: Thu, 16 Jul 2015 10:37:10 +0200 From: Jakub Jelen <jj...@re...> To: ope...@mi... Hi all, I was investigating openssh functionality with Smart Cards of different types from different vendors and there appeared few problems that would be great if they would be solved before 7.0 release. I filled bugs for them to keep track of them in openssh bugzilla Bug 2427 - ssh keygen is trying to read uninitialized slots on smart card (and is failing) [1] Bug 2429 - ssh-keygen ignores keys that have CKA_ID == 0 [2] Bug 2430 - ssh-keygen should allow to login before reading public key from smart card [3] Is there somebody who would be able to review the proposed changes and comment on the last one, what solution would be better? Then I can propose also some patch. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2427 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2429 [3] https://bugzilla.mindrot.org/show_bug.cgi?id=2430 Best regards, -- Jakub Jelen Security Technologies Red Hat _______________________________________________ openssh-unix-dev mailing list ope...@mi... https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev |
|
From: Nikos M. <n.m...@gm...> - 2015-07-14 08:50:42
|
On Wed, Jul 8, 2015 at 10:58 AM, Nikos Mavrogiannopoulos <n.m...@gm...> wrote: >> In that regard your changes, Nikos, look good, though I'd prefer >> something like `sc_terminate_context` instead of >> `sc_release_context_after_fork`. This would put the focus on the >> desired action (destroy the memory NOW instead of doing some >> additional magic) instead of the circumstances (being called after >> fork). This would raise readability/maintainability, I think. > I've updated the patch for that. Hello, Any other comments related to that issue? Anything that blocks it from being merged? regards, Nikos |
|
From: Nikos M. <n.m...@gm...> - 2015-07-08 08:58:40
|
On Mon, Jul 6, 2015 at 2:07 AM, Frank Morgner <mo...@in...> wrote: > 2. We should not perform any "terminating" actions on the card when > detecting a fork. This card belongs to the parent process and we > should not touch it. That means that calling C_Finalize from > C_Initialize as currently implemented is not correct. > > In that regard your changes, Nikos, look good, though I'd prefer > something like `sc_terminate_context` instead of > `sc_release_context_after_fork`. This would put the focus on the > desired action (destroy the memory NOW instead of doing some > additional magic) instead of the circumstances (being called after > fork). This would raise readability/maintainability, I think. I've updated the patch for that. > However, your current patch still leaks gpriv in reader-pcsc.c > (because finish is not called). That was intentional. Calling finish after fork disables the card for the parent. I've committed an additional patch to eliminate that leak. regards, Nikos |
5 messages has been excluded from this view by a project administrator.
