Re: [opensc-devel] OpenSC write access to main trunk, discussion
Douglas E. Engert wrote: > change,44 below is Vicktor's, not mine. I should not have said > "I think I have to rebase the code, and do another pull request?" You can also do it! //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Ludovic, change,44 below is Vicktor's, not mine. I should not have said "I think I have to rebase the code, and do another pull request?" I was hopping you would try a +2 on: https://www.opensc-project.org/codereview/#change,237 Its parent is: 6f8dcc9172277799011d88fdbe2fabfcf3a89774 Make the Mac OS X package builder script more resilient. which is the gerrit staging branch, so it should not need to be rebased. On 2/21/2012 5:43 AM, Douglas E. Engert wrote: > > > On 2/21/2012 2:34 AM, Ludovic Rousseau wrote: >> Le 20 février 2012 22:31, Peter Stuge a écrit : >>> Douglas E. Engert wrote: I am new to Gerrit too, >>> >>> All right! I'm by no means an expert, but I have been using it in >>> several projects for a while, where I also helped with issues during >>> the migration, so please feel free to ask any questions. >>> >>> but it looks like if 2 code reviews give a +1, the code will be advanced. See: https://www.opensc-project.org/codereview/ >>> >>> Need Code Review +2 means that one "+2" review is neccessary. 2x +1 >>> is not equivalent. >> >> OK. >> Using +2 (instead of +1) now shows some progress. >> >> Example with https://www.opensc-project.org/codereview/#change,44 >> If I click on "Submit Patch Set 1" I now get the error: >> "Submit Failed >> Project policy requires all submissions to be a fast-forward. >> >> Please rebase the change locally and upload again for review." >> >> What should I do now? > > I think I have to rebase the code, and do another pull request? > >> >> It looks like gerrit worked for another patch: >> https://www.opensc-project.org/codereview/#change,2 >> The status is "Submitted, Merge Pending" >> Do I have to do something? >> Who will do the merge? >> >> Thanks >> > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 2012-02-21 18:16, Douglas E. Engert wrote: > >>> Pushing the ECDH Key Agreement to the token for use by the token >>> looks very interesting. >> > > I meant based on your slides it looks like that is what you would like > to do as a new operation. > >> I'm not sure I understand what you are trying to do here. The PIV >> specification doesn't (AFAIK...) allow you to store the result of an >> operation on the card. > > Correct. > >> I could imagine that "super-operations" like >> >> HMACSHA256 (ID-to-ECDH-priv-key-on-token, >> Other-party's-ECDH pubkey, >> KDF-Algorithm, >> KDF-Data, >> "Argument Data") >> >> could be interesting but that looks like a new token method to me. > > Based on you slides, this sounds like a version of NIST 800-56A > Section 6.1.1.2. with all the operations done on the token, > and the key (Z) stored on the token for use by other operations. You are right. My scheme does indeed store a ECDH Z-result in the token. However, this is a token management/provisioning key, rather than a "user key". For user-keys I currently have no ambitions beyond what PIV supports. I have "played" with the idea of creating a "secure stack-machine" for performing arbitrary cryptographic operations on result-data but I couldn't figure out how this would work without introducing vulnerabilities. :-( Anders > >> >> Anders >> >> >> >>> >>> Anders > > > >> >>> >>> Although PKCS #11 is good it is not particularly popular on Windows. It is essentially only Mozilla who insists on not supporting the native Windows crypto system. SUN/Oracle have managed to do 3(!) major Java releases (5,6,7) without PKCS #11 support for Win-64. They have though added support for Crypto-API. >>> >>> The same USB device could support Crypto-API primitives too. >>> >>> Regarding my token-project it has no direct ties to PKCS #11; it is closer to the NXP GP-chip which is powering Google's Wallet. The reason for this is that PKCS #11 doesn't have a interface supporting secure remote provisioning, something which absolutely necessary in the mobile phone world. >>> >>> Provisioning is indeed outside PKCS#11 and could be done in some >>> other, also convenient, way. USB is really easy to use. >>> >>> I have stretched this notion to include connected tokens as well with a hope reaching the critical mass needed for establishing a de-facto standard. >>> >>> I fear that you are ahead of your time. :\ Adam Dunkels implemented >>> the internet of things many years ago, but I don't even have IPv6. >>> Things are changing, but still slowly. >>> >>> >> it seems that NIST's PIV would be good choice > > It would be a much better candidate if there was not such a thick > layer of components involved which serve little to no purpose. If you talk about the actual card standard I have no idea what you are referring to. It looks quite simple to me. If you OTOH refer to the OpenSC implementation, this is something that PIV isn't responsible for. >>> >>> Actually neither, I refer to the entire stack of software required >>> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >>> >>> Anyway, I know that the PIV vendors verify their cards against Microsoft's driver and that is IMO the way to go. >>> >>> If there's a superior alternative Microsoft may well catch up at some >>> point. They did with USB. >>> >>> > But it would be nice to try to do even better. :) That is what my project is all about but that is hardly an alternative for Feitian at this stage. >>> >>> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >>> they do that's perfectly fine and totally awesome, but I'm keeping >>> the idea alive only because *I* think it is good and would like to >>> try it out. >>> >>> >>> //Peter >>> ___ >>> opensc-devel mailing list >>> opensc-devel@lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >> >> ___ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel >> >> > >>> >> >> > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 2/21/2012 9:53 AM, Anders Rundgren wrote: > On 2012-02-21 16:17, Douglas E. Engert wrote: >> >> >> On 2/21/2012 6:01 AM, Anders Rundgren wrote: >>> On 2012-02-20 23:22, Douglas E. Engert wrote: On 2/20/2012 3:41 PM, Anders Rundgren wrote: > On 2012-02-20 21:40, Peter Stuge wrote: >> Anders Rundgren wrote: >>> I don't know what USB P11 is, can you send me a pointer? >> >> It's my old idea of implementing PKCS#11 directly over USB. Issues >> have been pointed out, and they would have to be solved of course. > > Maybe you would like to have an STM32F215-based token? > 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES > It may happen this year. > > Anders I have not tried this, but check out this token too: http://www.goldkey.com/usb-smart-card-with-piv.html Built-in PIV Support Basic functionality and support for PIV cards and tokens already exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions. It does not say what what the Linux support is, but I bet it is OpenSC. >>> >>> Douglas, >>> I believe you have misunderstood my intentions. The idea with my >>> project is not finding a suitable PIV token but creating a new standard >>> for cryptographic modules. However, I may have to hijack some of PIV >>> stack in order to not get swamped by contra-productive middleware >>> development. >> >> OK. Note the PIV standards really define an application, and it could >> be extended or an additional application on the card could be used >> to do what you propose. > > That's correct and may very well be what I end-up with :-) > >> >>> >>> My FOSDEM 2012 presentation: >>> http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf >> >> The current PIV ECDH operations only return the ECDH keying material, >> and do not save it on the token. This is what the ECDH mods I want to get >> into OpenSC are all about. The mods return the raw keying material as a >> PKCS#11 symmetric key Session Object to the caller who could then use >> this with software based ECDH Key Agreement. The above allows for example Thunderbird to use ECDH for encrypted email, with most if the work done in software, as the derived key is not stored on the token. >> >> Pushing the ECDH Key Agreement to the token for use by the token >> looks very interesting. > I meant based on your slides it looks like that is what you would like to do as a new operation. > I'm not sure I understand what you are trying to do here. The PIV > specification doesn't (AFAIK...) allow you to store the result of an > operation on the card. Correct. > I could imagine that "super-operations" like > > HMACSHA256 (ID-to-ECDH-priv-key-on-token, > Other-party's-ECDH pubkey, > KDF-Algorithm, > KDF-Data, > "Argument Data") > > could be interesting but that looks like a new token method to me. Based on you slides, this sounds like a version of NIST 800-56A Section 6.1.1.2. with all the operations done on the token, and the key (Z) stored on the token for use by other operations. > > Anders > > > >> >> >>> >>> Anders >>> > >> >> >>> Although PKCS #11 is good it is not particularly popular on Windows. >>> It is essentially only Mozilla who insists on not supporting the >>> native Windows crypto system. SUN/Oracle have managed to do 3(!) >>> major Java releases (5,6,7) without PKCS #11 support for Win-64. >>> They have though added support for Crypto-API. >> >> The same USB device could support Crypto-API primitives too. >> >> >>> Regarding my token-project it has no direct ties to PKCS #11; it is >>> closer to the NXP GP-chip which is powering Google's Wallet. >>> >>> The reason for this is that PKCS #11 doesn't have a interface >>> supporting secure remote provisioning, something which absolutely >>> necessary in the mobile phone world. >> >> Provisioning is indeed outside PKCS#11 and could be done in some >> other, also convenient, way. USB is really easy to use. >> >> >>> I have stretched this notion to include connected tokens as well >>> with a hope reaching the critical mass needed for establishing a >>> de-facto standard. >> >> I fear that you are ahead of your time. :\ Adam Dunkels implemented >> the internet of things many years ago, but I don't even have IPv6. >> Things are changing, but still slowly. >> >> > it seems that NIST's PIV would be good choice It would be a much better candidate if there was not such a thick layer of components involved which serve little to no purpose. >>> >>> If you talk about the actual card standard I have no idea what >>> you are referring to. It looks quite simple to me. If you OTOH >>> refer to the OpenSC implementation,
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 2012-02-21 16:17, Douglas E. Engert wrote: > > > On 2/21/2012 6:01 AM, Anders Rundgren wrote: >> On 2012-02-20 23:22, Douglas E. Engert wrote: >>> >>> >>> On 2/20/2012 3:41 PM, Anders Rundgren wrote: On 2012-02-20 21:40, Peter Stuge wrote: > Anders Rundgren wrote: >> I don't know what USB P11 is, can you send me a pointer? > > It's my old idea of implementing PKCS#11 directly over USB. Issues > have been pointed out, and they would have to be solved of course. Maybe you would like to have an STM32F215-based token? 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES It may happen this year. Anders >>> >>> I have not tried this, but check out this token too: >>> >>> http://www.goldkey.com/usb-smart-card-with-piv.html >>> >>>Built-in PIV Support >>>Basic functionality and support for PIV cards and tokens already >>>exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions. >>> >>> It does not say what what the Linux support is, but I bet it is OpenSC. >> >> Douglas, >> I believe you have misunderstood my intentions. The idea with my >> project is not finding a suitable PIV token but creating a new standard >> for cryptographic modules. However, I may have to hijack some of PIV >> stack in order to not get swamped by contra-productive middleware >> development. > > OK. Note the PIV standards really define an application, and it could > be extended or an additional application on the card could be used > to do what you propose. That's correct and may very well be what I end-up with :-) > >> >> My FOSDEM 2012 presentation: >> http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf > > The current PIV ECDH operations only return the ECDH keying material, > and do not save it on the token. This is what the ECDH mods I want to get > into OpenSC are all about. The mods return the raw keying material as a > PKCS#11 symmetric key Session Object to the caller who could then use > this with software based ECDH Key Agreement. > > Pushing the ECDH Key Agreement to the token for use by the token > looks very interesting. I'm not sure I understand what you are trying to do here. The PIV specification doesn't (AFAIK...) allow you to store the result of an operation on the card. I could imagine that "super-operations" like HMACSHA256 (ID-to-ECDH-priv-key-on-token, Other-party's-ECDH pubkey, KDF-Algorithm, KDF-Data, "Argument Data") could be interesting but that looks like a new token method to me. Anders > > >> >> Anders >> >>> >>> >>> > > >> Although PKCS #11 is good it is not particularly popular on Windows. >> It is essentially only Mozilla who insists on not supporting the >> native Windows crypto system. SUN/Oracle have managed to do 3(!) >> major Java releases (5,6,7) without PKCS #11 support for Win-64. >> They have though added support for Crypto-API. > > The same USB device could support Crypto-API primitives too. > > >> Regarding my token-project it has no direct ties to PKCS #11; it is >> closer to the NXP GP-chip which is powering Google's Wallet. >> >> The reason for this is that PKCS #11 doesn't have a interface >> supporting secure remote provisioning, something which absolutely >> necessary in the mobile phone world. > > Provisioning is indeed outside PKCS#11 and could be done in some > other, also convenient, way. USB is really easy to use. > > >> I have stretched this notion to include connected tokens as well >> with a hope reaching the critical mass needed for establishing a >> de-facto standard. > > I fear that you are ahead of your time. :\ Adam Dunkels implemented > the internet of things many years ago, but I don't even have IPv6. > Things are changing, but still slowly. > > it seems that NIST's PIV would be good choice >>> >>> It would be a much better candidate if there was not such a thick >>> layer of components involved which serve little to no purpose. >> >> If you talk about the actual card standard I have no idea what >> you are referring to. It looks quite simple to me. If you OTOH >> refer to the OpenSC implementation, this is something that PIV >> isn't responsible for. > > Actually neither, I refer to the entire stack of software required > for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. > > >> Anyway, I know that the PIV vendors verify their cards against >> Microsoft's driver and that is IMO the way to go. > > If there's a superior alternative Microsoft may well catch up at some > point. They did with USB. > > >>> But it would be nice to try to do even better. :) >> >> That is what my project is all about but that is hardly an >> alternative for Feitian at this st
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 2/21/2012 6:01 AM, Anders Rundgren wrote: > On 2012-02-20 23:22, Douglas E. Engert wrote: >> >> >> On 2/20/2012 3:41 PM, Anders Rundgren wrote: >>> On 2012-02-20 21:40, Peter Stuge wrote: Anders Rundgren wrote: > I don't know what USB P11 is, can you send me a pointer? It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. >>> >>> Maybe you would like to have an STM32F215-based token? >>> 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES >>> It may happen this year. >>> >>> Anders >> >> I have not tried this, but check out this token too: >> >> http://www.goldkey.com/usb-smart-card-with-piv.html >> >>Built-in PIV Support >>Basic functionality and support for PIV cards and tokens already >>exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions. >> >> It does not say what what the Linux support is, but I bet it is OpenSC. > > Douglas, > I believe you have misunderstood my intentions. The idea with my > project is not finding a suitable PIV token but creating a new standard > for cryptographic modules. However, I may have to hijack some of PIV > stack in order to not get swamped by contra-productive middleware > development. OK. Note the PIV standards really define an application, and it could be extended or an additional application on the card could be used to do what you propose. > > My FOSDEM 2012 presentation: > http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf The current PIV ECDH operations only return the ECDH keying material, and do not save it on the token. This is what the ECDH mods I want to get into OpenSC are all about. The mods return the raw keying material as a PKCS#11 symmetric key Session Object to the caller who could then use this with software based ECDH Key Agreement. Pushing the ECDH Key Agreement to the token for use by the token looks very interesting. > > Anders > >> >> >> >>> > Although PKCS #11 is good it is not particularly popular on Windows. > It is essentially only Mozilla who insists on not supporting the > native Windows crypto system. SUN/Oracle have managed to do 3(!) > major Java releases (5,6,7) without PKCS #11 support for Win-64. > They have though added support for Crypto-API. The same USB device could support Crypto-API primitives too. > Regarding my token-project it has no direct ties to PKCS #11; it is > closer to the NXP GP-chip which is powering Google's Wallet. > > The reason for this is that PKCS #11 doesn't have a interface > supporting secure remote provisioning, something which absolutely > necessary in the mobile phone world. Provisioning is indeed outside PKCS#11 and could be done in some other, also convenient, way. USB is really easy to use. > I have stretched this notion to include connected tokens as well > with a hope reaching the critical mass needed for establishing a > de-facto standard. I fear that you are ahead of your time. :\ Adam Dunkels implemented the internet of things many years ago, but I don't even have IPv6. Things are changing, but still slowly. >>> it seems that NIST's PIV would be good choice >> >> It would be a much better candidate if there was not such a thick >> layer of components involved which serve little to no purpose. > > If you talk about the actual card standard I have no idea what > you are referring to. It looks quite simple to me. If you OTOH > refer to the OpenSC implementation, this is something that PIV > isn't responsible for. Actually neither, I refer to the entire stack of software required for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. > Anyway, I know that the PIV vendors verify their cards against > Microsoft's driver and that is IMO the way to go. If there's a superior alternative Microsoft may well catch up at some point. They did with USB. >> But it would be nice to try to do even better. :) > > That is what my project is all about but that is hardly an > alternative for Feitian at this stage. Also agree. I'm also not suggesting Feitian to pick up on my idea. If they do that's perfectly fine and totally awesome, but I'm keeping the idea alive only because *I* think it is good and would like to try it out. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >>> ___ >>> opensc-devel mailing list >>> opensc-devel@lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >>> >> > > -- Douglas E. Engert A
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 2/21/2012 1:51 AM, Anders Rundgren wrote: > On 2012-02-20 23:23, Jean-Michel Pouré - GOOZE wrote: > >> IMHO, CCID is superior as it is really plug-and-play under all systems. >> Of course, CCID is needed, but it could be installed under all systems >> by default. The last versions of libccid with udev really rocks. Pure >> plug-and-play never exists, you always need an underlying library. >> libccid is that library. > > Jean-Michel, > > I'm not following you here. CCID (as I understand it) only defines > an USB communication protocol/class, not how for example how to do > an RSA signature. When I look into my W7 installation I note that > when I attach my ePass2003 token to it, there is a driver from > "EnterSafe". That doesn't look particularly universal to me. > > In addition, in order to do something useful with the token I had to > install a specific ePass2003 management program. It worked great BTW! > > Don't get me wrong but from a *customer perspective* it would > have been much better if all this software was a part of a platform's > "smart card support". My guess is that the smart card industry can't > do that which is one of the motivations behind my SKS/KeyGen2 project. > > Upgrading ePass2003 to PIV is an intermediary step. I believe the > management part unfortunately is largely undefined in PIV but maybe > somebody else know better? Douglas? That is correct. As I understand it, the intent was to let the card vendors define this for theirs cards and allow them to market card management systems, giving them some competitive advantage for their cards. At least the end user card interface would be the same. But 800-73 does define "put data" and "generate key", which allows for some testing. It does not define a load key or any finalize commands which would be needed by a production card management system. > > > > Cheers, > Anders > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 2012-02-20 23:22, Douglas E. Engert wrote: > > > On 2/20/2012 3:41 PM, Anders Rundgren wrote: >> On 2012-02-20 21:40, Peter Stuge wrote: >>> Anders Rundgren wrote: I don't know what USB P11 is, can you send me a pointer? >>> >>> It's my old idea of implementing PKCS#11 directly over USB. Issues >>> have been pointed out, and they would have to be solved of course. >> >> Maybe you would like to have an STM32F215-based token? >> 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES >> It may happen this year. >> >> Anders > > I have not tried this, but check out this token too: > > http://www.goldkey.com/usb-smart-card-with-piv.html > > Built-in PIV Support > Basic functionality and support for PIV cards and tokens already > exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions. > > It does not say what what the Linux support is, but I bet it is OpenSC. Douglas, I believe you have misunderstood my intentions. The idea with my project is not finding a suitable PIV token but creating a new standard for cryptographic modules. However, I may have to hijack some of PIV stack in order to not get swamped by contra-productive middleware development. My FOSDEM 2012 presentation: http://webpki.org/papers/keygen2/sks-keygen2-FOSDEM-presentation.pdf Anders > > > >> >>> >>> Although PKCS #11 is good it is not particularly popular on Windows. It is essentially only Mozilla who insists on not supporting the native Windows crypto system. SUN/Oracle have managed to do 3(!) major Java releases (5,6,7) without PKCS #11 support for Win-64. They have though added support for Crypto-API. >>> >>> The same USB device could support Crypto-API primitives too. >>> >>> Regarding my token-project it has no direct ties to PKCS #11; it is closer to the NXP GP-chip which is powering Google's Wallet. The reason for this is that PKCS #11 doesn't have a interface supporting secure remote provisioning, something which absolutely necessary in the mobile phone world. >>> >>> Provisioning is indeed outside PKCS#11 and could be done in some >>> other, also convenient, way. USB is really easy to use. >>> >>> I have stretched this notion to include connected tokens as well with a hope reaching the critical mass needed for establishing a de-facto standard. >>> >>> I fear that you are ahead of your time. :\ Adam Dunkels implemented >>> the internet of things many years ago, but I don't even have IPv6. >>> Things are changing, but still slowly. >>> >>> >> it seems that NIST's PIV would be good choice > > It would be a much better candidate if there was not such a thick > layer of components involved which serve little to no purpose. If you talk about the actual card standard I have no idea what you are referring to. It looks quite simple to me. If you OTOH refer to the OpenSC implementation, this is something that PIV isn't responsible for. >>> >>> Actually neither, I refer to the entire stack of software required >>> for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. >>> >>> Anyway, I know that the PIV vendors verify their cards against Microsoft's driver and that is IMO the way to go. >>> >>> If there's a superior alternative Microsoft may well catch up at some >>> point. They did with USB. >>> >>> > But it would be nice to try to do even better. :) That is what my project is all about but that is hardly an alternative for Feitian at this stage. >>> >>> Also agree. I'm also not suggesting Feitian to pick up on my idea. If >>> they do that's perfectly fine and totally awesome, but I'm keeping >>> the idea alive only because *I* think it is good and would like to >>> try it out. >>> >>> >>> //Peter >>> ___ >>> opensc-devel mailing list >>> opensc-devel@lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >> >> ___ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel >> >> > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
On 2/21/2012 2:34 AM, Ludovic Rousseau wrote: > Le 20 février 2012 22:31, Peter Stuge a écrit : >> Douglas E. Engert wrote: >>> I am new to Gerrit too, >> >> All right! I'm by no means an expert, but I have been using it in >> several projects for a while, where I also helped with issues during >> the migration, so please feel free to ask any questions. >> >> >>> but it looks like if 2 code reviews give a +1, the code will be >>> advanced. >>> >>> See: https://www.opensc-project.org/codereview/ >> >> Need Code Review +2 means that one "+2" review is neccessary. 2x +1 >> is not equivalent. > > OK. > Using +2 (instead of +1) now shows some progress. > > Example with https://www.opensc-project.org/codereview/#change,44 > If I click on "Submit Patch Set 1" I now get the error: > "Submit Failed > Project policy requires all submissions to be a fast-forward. > > Please rebase the change locally and upload again for review." > > What should I do now? I think I have to rebase the code, and do another pull request? > > It looks like gerrit worked for another patch: > https://www.opensc-project.org/codereview/#change,2 > The status is "Submitted, Merge Pending" > Do I have to do something? > Who will do the merge? > > Thanks > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Le 20 février 2012 22:31, Peter Stuge a écrit : > Douglas E. Engert wrote: >> I am new to Gerrit too, > > All right! I'm by no means an expert, but I have been using it in > several projects for a while, where I also helped with issues during > the migration, so please feel free to ask any questions. > > >> but it looks like if 2 code reviews give a +1, the code will be >> advanced. >> >> See: https://www.opensc-project.org/codereview/ > > Need Code Review +2 means that one "+2" review is neccessary. 2x +1 > is not equivalent. OK. Using +2 (instead of +1) now shows some progress. Example with https://www.opensc-project.org/codereview/#change,44 If I click on "Submit Patch Set 1" I now get the error: "Submit Failed Project policy requires all submissions to be a fast-forward. Please rebase the change locally and upload again for review." What should I do now? It looks like gerrit worked for another patch: https://www.opensc-project.org/codereview/#change,2 The status is "Submitted, Merge Pending" Do I have to do something? Who will do the merge? Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Le 20 février 2012 22:08, Douglas E. Engert a écrit : > Ludovic, > Can you verify if you are in the Gerrit Administrator's group? > and are any of the other people listed on the "GetInvolved" page > listed as integrators, or admins? I only see 2 groups in the admin section: - Integrators: Martin and myself - Release Managers: Martin only It looks like I can add new member(s) to the Integrators group. Bye, -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
