You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "impetus technologies (JIRA)" <ji...@apache.org> on 2008/08/04 09:23:44 UTC
[jira] Created: (SHINDIG-491) Improper handling of Key
Improper handling of Key
------------------------
Key: SHINDIG-491
URL: https://issues.apache.org/jira/browse/SHINDIG-491
Project: Shindig
Issue Type: Bug
Environment: windows
Reporter: impetus technologies
Attachments: SigningFetcherFactory.php.patch
Hi,
In SigningFetcherFactory.php "openssl_pkey_get_private()" method should be called in case of a proper key if it is blank or not a key then it should not be called. So it should be inside the "else". I have submitted this patch previously with issue Shindig-477 on 2008-07-28. It was committed too. But I think during the cache code cleaning it was missed.
Patch is attached for the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-491) Improper handling of Key
Posted by "Chris Chabot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619438#action_12619438 ]
Chris Chabot commented on SHINDIG-491:
--------------------------------------
Hmm but then people who don't read the manual (and they never do :P) won't have a visible clue that they should in face generate a key.
I'm a bit fearful that if we make a 'default key' (which is publicly available, so anyone can use it to spoof requests with), there will be live containers that use it since they never realized they should make their own.
So from a sample container point of view i agree, but i'm to afraid that it will cause real security issues to think that that's the solution; From that point of view i think an exception is exactly what we need :)
> Improper handling of Key
> ------------------------
>
> Key: SHINDIG-491
> URL: https://issues.apache.org/jira/browse/SHINDIG-491
> Project: Shindig
> Issue Type: Bug
> Environment: windows
> Reporter: impetus technologies
> Assignee: Chris Chabot
> Attachments: SigningFetcherFactory.php.patch
>
>
> Hi,
> In SigningFetcherFactory.php "openssl_pkey_get_private()" method should be called in case of a proper key if it is blank or not a key then it should not be called. So it should be inside the "else". I have submitted this patch previously with issue Shindig-477 on 2008-07-28. It was committed too. But I think during the cache code cleaning it was missed.
> Patch is attached for the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-491) Improper handling of Key
Posted by "impetus technologies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
impetus technologies updated SHINDIG-491:
-----------------------------------------
Attachment: SigningFetcherFactory.php.patch
> Improper handling of Key
> ------------------------
>
> Key: SHINDIG-491
> URL: https://issues.apache.org/jira/browse/SHINDIG-491
> Project: Shindig
> Issue Type: Bug
> Environment: windows
> Reporter: impetus technologies
> Attachments: SigningFetcherFactory.php.patch
>
>
> Hi,
> In SigningFetcherFactory.php "openssl_pkey_get_private()" method should be called in case of a proper key if it is blank or not a key then it should not be called. So it should be inside the "else". I have submitted this patch previously with issue Shindig-477 on 2008-07-28. It was committed too. But I think during the cache code cleaning it was missed.
> Patch is attached for the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-491) Improper handling of Key
Posted by "impetus technologies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619436#action_12619436 ]
impetus technologies commented on SHINDIG-491:
----------------------------------------------
Hi Chris,
Conceptually this is correct.
But currently we don't have a default private key in our code. I have a suggestion to handle this... If we can make a dummy private key and store it in the certs folder, then we will never have a blank key in signing fetcher file Also, this way we can throw the exception when one tries to sign a request without having an actual key.
> Improper handling of Key
> ------------------------
>
> Key: SHINDIG-491
> URL: https://issues.apache.org/jira/browse/SHINDIG-491
> Project: Shindig
> Issue Type: Bug
> Environment: windows
> Reporter: impetus technologies
> Assignee: Chris Chabot
> Attachments: SigningFetcherFactory.php.patch
>
>
> Hi,
> In SigningFetcherFactory.php "openssl_pkey_get_private()" method should be called in case of a proper key if it is blank or not a key then it should not be called. So it should be inside the "else". I have submitted this patch previously with issue Shindig-477 on 2008-07-28. It was committed too. But I think during the cache code cleaning it was missed.
> Patch is attached for the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SHINDIG-491) Improper handling of Key
Posted by "Chris Chabot (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Chabot resolved SHINDIG-491.
----------------------------------
Resolution: Fixed
Assignee: Chris Chabot
Right you are, patch applied.
Though i am wondering if we shouldn't throw an exception when your trying to sign a request without having an actual key ... any thoughts on this?
> Improper handling of Key
> ------------------------
>
> Key: SHINDIG-491
> URL: https://issues.apache.org/jira/browse/SHINDIG-491
> Project: Shindig
> Issue Type: Bug
> Environment: windows
> Reporter: impetus technologies
> Assignee: Chris Chabot
> Attachments: SigningFetcherFactory.php.patch
>
>
> Hi,
> In SigningFetcherFactory.php "openssl_pkey_get_private()" method should be called in case of a proper key if it is blank or not a key then it should not be called. So it should be inside the "else". I have submitted this patch previously with issue Shindig-477 on 2008-07-28. It was committed too. But I think during the cache code cleaning it was missed.
> Patch is attached for the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-491) Improper handling of Key
Posted by "impetus technologies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619440#action_12619440 ]
impetus technologies commented on SHINDIG-491:
----------------------------------------------
Hi Chris,
For such case the only thing we can do it we can make some comments/instructions in README configuration file for PHP shindig, to manually create such keys in certs folder, if one is willing to use oauth gadget.
> Improper handling of Key
> ------------------------
>
> Key: SHINDIG-491
> URL: https://issues.apache.org/jira/browse/SHINDIG-491
> Project: Shindig
> Issue Type: Bug
> Environment: windows
> Reporter: impetus technologies
> Assignee: Chris Chabot
> Attachments: SigningFetcherFactory.php.patch
>
>
> Hi,
> In SigningFetcherFactory.php "openssl_pkey_get_private()" method should be called in case of a proper key if it is blank or not a key then it should not be called. So it should be inside the "else". I have submitted this patch previously with issue Shindig-477 on 2008-07-28. It was committed too. But I think during the cache code cleaning it was missed.
> Patch is attached for the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.