[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor

2017-12-06 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1665:

Priority: Major  (was: Critical)

> Review locking - TLS / SSL thread safety with proactor
> --
>
> Key: PROTON-1665
> URL: https://issues.apache.org/jira/browse/PROTON-1665
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>  Labels: tls
> Fix For: proton-c-future
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.
> The obvious thread-safety issues were addressed by  PROTON-1620 and the use 
> of per-transport SSL objects appears to be correct and safe. However we need 
> a careful review of the use of shared OpenSSL objects (related to SSL domains 
> and certificate stores) to ensure they are being used safely and no 
> additional locks are needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor

2017-12-06 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1665:

Labels: tls  (was: )

> Review locking - TLS / SSL thread safety with proactor
> --
>
> Key: PROTON-1665
> URL: https://issues.apache.org/jira/browse/PROTON-1665
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>  Labels: tls
> Fix For: proton-c-future
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.
> The obvious thread-safety issues were addressed by  PROTON-1620 and the use 
> of per-transport SSL objects appears to be correct and safe. However we need 
> a careful review of the use of shared OpenSSL objects (related to SSL domains 
> and certificate stores) to ensure they are being used safely and no 
> additional locks are needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor

2017-12-06 Thread Justin Ross (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated PROTON-1665:

Fix Version/s: (was: proton-c-0.19.0)
   proton-c-future

> Review locking - TLS / SSL thread safety with proactor
> --
>
> Key: PROTON-1665
> URL: https://issues.apache.org/jira/browse/PROTON-1665
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Critical
> Fix For: proton-c-future
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.
> The obvious thread-safety issues were addressed by  PROTON-1620 and the use 
> of per-transport SSL objects appears to be correct and safe. However we need 
> a careful review of the use of shared OpenSSL objects (related to SSL domains 
> and certificate stores) to ensure they are being used safely and no 
> additional locks are needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor

2017-10-30 Thread Alan Conway (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated PROTON-1665:

Fix Version/s: (was: proton-c-0.18.1)
   proton-c-0.19.0

> Review locking - TLS / SSL thread safety with proactor
> --
>
> Key: PROTON-1665
> URL: https://issues.apache.org/jira/browse/PROTON-1665
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Critical
> Fix For: proton-c-0.19.0
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.
> The obvious thread-safety issues were addressed by  PROTON-1620 and the use 
> of per-transport SSL objects appears to be correct and safe. However we need 
> a careful review of the use of shared OpenSSL objects (related to SSL domains 
> and certificate stores) to ensure they are being used safely and no 
> additional locks are needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor

2017-10-30 Thread Alan Conway (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated PROTON-1665:

Description: 
ssl_domain objects are semi-global.

For example two connections simultaneously creating or releasing their own 
private pn_ssl_t objects may mess up the refcount of the shared pn_ssl_domain_t 
object leading to memory corruption or leaks.

Windows schannel is further complicated by the OS internal refcounting of its 
security context thingies.  That may get automatically solved by the above, or 
may require a separate JIRA to track.  The same may apply to openssl.

The obvious thread-safety issues were addressed by  PROTON-1620 and the use of 
per-transport SSL objects appears to be correct and safe. However we need a 
careful review of the use of shared OpenSSL objects (related to SSL domains and 
certificate stores) to ensure they are being used safely and no additional 
locks are needed.


  was:
ssl_domain objects are semi-global.

For example two connections simultaneously creating or releasing their own 
private pn_ssl_t objects may mess up the refcount of the shared pn_ssl_domain_t 
object leading to memory corruption or leaks.

Windows schannel is further complicated by the OS internal refcounting of its 
security context thingies.  That may get automatically solved by the above, or 
may require a separate JIRA to track.  The same may apply to openssl.

The obvious thread-safety issues were addressed by 



> Review locking - TLS / SSL thread safety with proactor
> --
>
> Key: PROTON-1665
> URL: https://issues.apache.org/jira/browse/PROTON-1665
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Critical
> Fix For: proton-c-0.18.1
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.
> The obvious thread-safety issues were addressed by  PROTON-1620 and the use 
> of per-transport SSL objects appears to be correct and safe. However we need 
> a careful review of the use of shared OpenSSL objects (related to SSL domains 
> and certificate stores) to ensure they are being used safely and no 
> additional locks are needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor

2017-10-30 Thread Alan Conway (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated PROTON-1665:

Description: 
ssl_domain objects are semi-global.

For example two connections simultaneously creating or releasing their own 
private pn_ssl_t objects may mess up the refcount of the shared pn_ssl_domain_t 
object leading to memory corruption or leaks.

Windows schannel is further complicated by the OS internal refcounting of its 
security context thingies.  That may get automatically solved by the above, or 
may require a separate JIRA to track.  The same may apply to openssl.

The worst thread-safety issues have been fixed with 

  was:
ssl_domain objects are semi-global.

For example two connections simultaneously creating or releasing their own 
private pn_ssl_t objects may mess up the refcount of the shared pn_ssl_domain_t 
object leading to memory corruption or leaks.

Windows schannel is further complicated by the OS internal refcounting of its 
security context thingies.  That may get automatically solved by the above, or 
may require a separate JIRA to track.  The same may apply to openssl.


> Review locking - TLS / SSL thread safety with proactor
> --
>
> Key: PROTON-1665
> URL: https://issues.apache.org/jira/browse/PROTON-1665
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Critical
> Fix For: proton-c-0.18.1
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.
> The worst thread-safety issues have been fixed with 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor

2017-10-30 Thread Alan Conway (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated PROTON-1665:

Description: 
ssl_domain objects are semi-global.

For example two connections simultaneously creating or releasing their own 
private pn_ssl_t objects may mess up the refcount of the shared pn_ssl_domain_t 
object leading to memory corruption or leaks.

Windows schannel is further complicated by the OS internal refcounting of its 
security context thingies.  That may get automatically solved by the above, or 
may require a separate JIRA to track.  The same may apply to openssl.

The obvious thread-safety issues were addressed by 


  was:
ssl_domain objects are semi-global.

For example two connections simultaneously creating or releasing their own 
private pn_ssl_t objects may mess up the refcount of the shared pn_ssl_domain_t 
object leading to memory corruption or leaks.

Windows schannel is further complicated by the OS internal refcounting of its 
security context thingies.  That may get automatically solved by the above, or 
may require a separate JIRA to track.  The same may apply to openssl.

The worst thread-safety issues have been fixed with 


> Review locking - TLS / SSL thread safety with proactor
> --
>
> Key: PROTON-1665
> URL: https://issues.apache.org/jira/browse/PROTON-1665
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Critical
> Fix For: proton-c-0.18.1
>
>
> ssl_domain objects are semi-global.
> For example two connections simultaneously creating or releasing their own 
> private pn_ssl_t objects may mess up the refcount of the shared 
> pn_ssl_domain_t object leading to memory corruption or leaks.
> Windows schannel is further complicated by the OS internal refcounting of its 
> security context thingies.  That may get automatically solved by the above, 
> or may require a separate JIRA to track.  The same may apply to openssl.
> The obvious thread-safety issues were addressed by 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org