[jira] [Updated] (TS-3651) Eliminate proxy.config.http.share_server_sessions
[ https://issues.apache.org/jira/browse/TS-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3651: -- Fix Version/s: 6.0.0 Eliminate proxy.config.http.share_server_sessions - Key: TS-3651 URL: https://issues.apache.org/jira/browse/TS-3651 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Labels: Incompatible Fix For: 6.0.0 We deprecated proxy.config.http.share_server_sessions in v5.x, in favor of a set of more powerful configuration options. As such, it's time to remove the old configuration for 6.0.0. This is inline with our normal practice of 1) Deprecate something in version n 2) Remove that something in version n + 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3651) Eliminate proxy.config.http.share_server_sessions
[ https://issues.apache.org/jira/browse/TS-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3651: -- Assignee: Alan M. Carroll Eliminate proxy.config.http.share_server_sessions - Key: TS-3651 URL: https://issues.apache.org/jira/browse/TS-3651 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Alan M. Carroll Labels: Incompatible Fix For: 6.0.0 We deprecated proxy.config.http.share_server_sessions in v5.x, in favor of a set of more powerful configuration options. As such, it's time to remove the old configuration for 6.0.0. This is inline with our normal practice of 1) Deprecate something in version n 2) Remove that something in version n + 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567578#comment-14567578
]
ASF GitHub Bot commented on TS-3650:
Github user SolidWallOfCode commented on the pull request:
https://github.com/apache/trafficserver/pull/206#issuecomment-107638211
The chat concensus seemed to be to change this to NULL, DEFAULT, EXPLICIT,
ENV. I'll change SRC to SOURCE as well - I was tempted to have RECS which
would be more consistent with the other REC values but that seemed even worse
scanning.
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567535#comment-14567535
]
ASF GitHub Bot commented on TS-3650:
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/206#issuecomment-107628793
The ``REC_SRC`` constants scan poorly, I think I'd prefer ``REC_SOURCE``.
``REC_SRC_NONE`` should be called ``REC_SOURCE_NULL`` to be consistent with
other naming. There's some semantic confusion about what ``REC_SRC_DEFAULT``
means. When ``traffic_manager`` sets variables, I don't think they should be
considered defaults.
I am sympathetic to @sudheerv's concerns about how useful this is. The
distinction between hard-coded default and everything else is clear, but
this change is attempting to track various nuances that are much murkier.
Does ``DiagsConfig::RegisterDiagConfig`` really have to register
everything? I expect that that superfluous now?
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3651) Eliminate proxy.config.http.share_server_sessions
[ https://issues.apache.org/jira/browse/TS-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3651: -- Labels: Incompatible (was: ) Eliminate proxy.config.http.share_server_sessions - Key: TS-3651 URL: https://issues.apache.org/jira/browse/TS-3651 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Labels: Incompatible Fix For: 6.0.0 We deprecated proxy.config.http.share_server_sessions in v5.x, in favor of a set of more powerful configuration options. As such, it's time to remove the old configuration for 6.0.0. This is inline with our normal practice of 1) Deprecate something in version n 2) Remove that something in version n + 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-3650:
---
Assignee: Alan M. Carroll
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3651) Eliminate proxy.config.http.share_server_sessions
Leif Hedstrom created TS-3651: - Summary: Eliminate proxy.config.http.share_server_sessions Key: TS-3651 URL: https://issues.apache.org/jira/browse/TS-3651 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom We deprecated proxy.config.http.share_server_sessions in v5.x, in favor of a set of more powerful configuration options. As such, it's time to remove the old configuration for 6.0.0. This is inline with our normal practice of 1) Deprecate something in version n 2) Remove that something in version n + 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gancho Tenev updated TS-3649: - Attachment: TS-3649-url_sig-security_issues.patch Please find the patch attached: TS-3649-url_sig-security_issues.patch url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567579#comment-14567579
]
ASF GitHub Bot commented on TS-3650:
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/206#issuecomment-107638604
Yes, I had the same conflict about ``RECS`` ;)
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3650:
--
Description:
A configuration variable can get its value from a variety of sources. It would
be useful to be able to programmatically determine that source. At a minimum
the ability to determine if a variable was set explicitly in a configuration
file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator via
{{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal API,
primarily as a value to return if the requested variable doesn't exist (in
which case none of the previous values are reasonable).
was:
A configuration variable can get its value from a variety of sources. It would
be useful to be able to programmatically determine that source. At a minimum
the ability to determine if a variable was set explicitly in a configuration
file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator via
{{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal API,
primarily as a value to return if the requested variable doesn't exist (in
which case none of the previous values are reasonable).
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567674#comment-14567674
]
Sudheer Vinukonda commented on TS-3650:
---
Perhaps, the status *EXPLICIT* mentioned above is going to include both setting
via traffic_line/API and config file explicitly?
If that's the case, then the information is no longer very useful - Fwiw, I
liked [~jpe...@apache.org]'s suggestion on the IRC, to make use of the fact
that a missing entry in records.config may be used to identify if a config is
explicitly set (if/where it's really necessary)
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567736#comment-14567736
]
ASF GitHub Bot commented on TS-3650:
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/206#issuecomment-107664507
There's no way to know whether a metric was set by ``traffic_line``. The
best you can do is to say whether a metric was set by a specific API, but
that's complex and low value IMHO, and as you pointed out above, that
information is lost when the configuration is persisted.
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567633#comment-14567633 ] ASF GitHub Bot commented on TS-3649: GitHub user gtenev opened a pull request: https://github.com/apache/trafficserver/pull/208 TS-3649 Fix for url_sig plugin security issues (crash by HTTP request circumvent signature). You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtenev/trafficserver TS-3649_url_sig_fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/208.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #208 commit 81e2574e1007db136e0572ba438e08ecd3b7f037 Author: Gancho Tenev gtte...@gmail.com Date: 2015-06-01T17:17:40Z TS-3649 Fix for url_sig plugin security issues (crash by HTTP request, circumvent signature). url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3650) Configuration variables should track their source
[
https://issues.apache.org/jira/browse/TS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567651#comment-14567651
]
ASF GitHub Bot commented on TS-3650:
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/206#issuecomment-107653612
I don't think there was a consensus yet (at least, not from my side).
AFAIK, my question above on persisting the source as traffic_line was not
addressed and without making that information consistent, I am -1 on this PR.
Configuration variables should track their source
-
Key: TS-3650
URL: https://issues.apache.org/jira/browse/TS-3650
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
A configuration variable can get its value from a variety of sources. It
would be useful to be able to programmatically determine that source. At a
minimum the ability to determine if a variable was set explicitly in a
configuration file vs. using a built in default value would be very useful.
In addition this information should be made available to the administrator
via {{traffic_ctl}} to aid in debugging.
The proposed values are
* {{DEFAULT}} - built in default, hard wired.
* {{FILE}} - read from a configuration file.
* {{API}} - set via an API of some sort ({{traffic_line}} etc.)
* {{CLUSTER}} - set via cluster configuration
* {{ENV}} - set from an environment variable
In addition the value {{INVALID}} will be defined to use for the internal
API, primarily as a value to return if the requested variable doesn't exist
(in which case none of the previous values are reasonable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3560) Make proxy.config.http.slow.log.threshold overridable
[ https://issues.apache.org/jira/browse/TS-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567612#comment-14567612 ] ASF subversion and git services commented on TS-3560: - Commit 72d6733aa9bf39c928ede2b02761328711ce31fe in trafficserver's branch refs/heads/master from [~persiaAziz] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=72d6733 ] TS-3560: Fix regression tests Make proxy.config.http.slow.log.threshold overridable - Key: TS-3560 URL: https://issues.apache.org/jira/browse/TS-3560 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: David Carlin Assignee: Syeda Persia Aziz Fix For: 6.0.0 Please make proxy.config.http.slow.log.threshold configurable via conf_remap - we want to be able to enable it on a per-remap basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567837#comment-14567837 ] ASF subversion and git services commented on TS-3649: - Commit 3f523ea5db49e244f9a09b4752d06031e3f31130 in trafficserver's branch refs/heads/master from [~gancho] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3f523ea ] TS-3649 Fix for url_sig plugin security issues (crash by HTTP request, circumvent signature). url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3649: -- Backport to Version: 5.3.1 url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567840#comment-14567840 ] ASF GitHub Bot commented on TS-3649: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/208 url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567839#comment-14567839 ] ASF subversion and git services commented on TS-3649: - Commit 133df337c682ca2ae76a983bfbdea51e2f2ffc82 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=133df33 ] Added TS-3649. This closes #208 url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3652) During 3xx redirect follow, TS uses the redirect url as the cache key ignoring any cache key set via API
Sudheer Vinukonda created TS-3652: - Summary: During 3xx redirect follow, TS uses the redirect url as the cache key ignoring any cache key set via API Key: TS-3652 URL: https://issues.apache.org/jira/browse/TS-3652 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Sudheer Vinukonda Currently, during 3xx redirect follow, TS uses the redirect url (as received in the *Location* header of the 3xx response) as the cache key for storing the subsequent response to the redirect follow request). This works fine in most cases, since, the original client request would have cached the 3xx response and the final response would still be derived using the redirect follow url. This also allows direct requests to the redirect follow location be served from the cache efficiently. However, this is not desirable in some cases, especially when there's a TS API (plugin) modifying the cache key and wanting to store the final response against the modified cache key directly. Proposing to add a config setting to allow storing API set cache key during redirect follow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568040#comment-14568040 ] ASF subversion and git services commented on TS-3649: - Commit 7cae891870a5634dd28f2a679ff3b4f9a9fbe82b in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7cae891 ] TS-3649: Check key length during config parse url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3653) Add the ability to exclude by regex to url_sig plugin
Phil Sorber created TS-3653: --- Summary: Add the ability to exclude by regex to url_sig plugin Key: TS-3653 URL: https://issues.apache.org/jira/browse/TS-3653 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber Allow certain url's to be excluded from authentication by regular expression. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3653) Add the ability to exclude by regex to url_sig plugin
[ https://issues.apache.org/jira/browse/TS-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-3653: --- Assignee: Phil Sorber Add the ability to exclude by regex to url_sig plugin - Key: TS-3653 URL: https://issues.apache.org/jira/browse/TS-3653 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 6.0.0 Allow certain url's to be excluded from authentication by regular expression. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3653) Add the ability to exclude by regex to url_sig plugin
[ https://issues.apache.org/jira/browse/TS-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3653: Fix Version/s: 6.0.0 Add the ability to exclude by regex to url_sig plugin - Key: TS-3653 URL: https://issues.apache.org/jira/browse/TS-3653 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber Fix For: 6.0.0 Allow certain url's to be excluded from authentication by regular expression. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3653) Add the ability to exclude by regex to url_sig plugin
[ https://issues.apache.org/jira/browse/TS-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568124#comment-14568124 ] ASF subversion and git services commented on TS-3653: - Commit 9cafcee69387692b803ca5be292288ae0dc04639 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9cafcee ] TS-3653: Add the ability to exclude by regex to url_sig plugin Add the ability to exclude by regex to url_sig plugin - Key: TS-3653 URL: https://issues.apache.org/jira/browse/TS-3653 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 6.0.0 Allow certain url's to be excluded from authentication by regular expression. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3654) ASAN heap-use-after-free in cache-hosting (regression)
Leif Hedstrom created TS-3654:
-
Summary: ASAN heap-use-after-free in cache-hosting (regression)
Key: TS-3654
URL: https://issues.apache.org/jira/browse/TS-3654
Project: Traffic Server
Issue Type: Improvement
Components: Cache
Reporter: Leif Hedstrom
{code}
RPRINT Cache_vol: 1 128 Megabyte Volumes
RPRINT Cache_vol: Not enough space for 10 volume
RPRINT Cache_vol: Random Volumes after clearing the disks
RPRINT Cache_vol: volume=1 scheme=http size=128
RPRINT Cache_vol: Random Volumes without clearing the disks
RPRINT Cache_vol: volume=1 scheme=rtsp size=128
=
==3733==ERROR: AddressSanitizer: heap-use-after-free on address 0x604a2960
at pc 0xa7ce83 bp 0x7f3c7f946980 sp 0x7f3c7f946970
READ of size 8 at 0x604a2960 thread T3 ([ET_NET 2])
#0 0xa7ce82 in cplist_update ../../../../iocore/cache/Cache.cc:3230
#1 0xa7ce82 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3374
#2 0xac619e in execute_and_verify(RegressionTest*)
../../../../iocore/cache/CacheHosting.cc:994
#3 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*)
../../../../iocore/cache/CacheHosting.cc:840
#4 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
#5 0x7f3c8480b4d2 in RegressionTest::run_some()
../../../../lib/ts/Regression.cc:125
#6 0x7f3c8480b9b6 in RegressionTest::check_status()
../../../../lib/ts/Regression.cc:140
#7 0x57b5b4 in RegressionCont::mainEvent(int, Event*)
../../../proxy/Main.cc:1220
#8 0xc8b86e in Continuation::handleEvent(int, void*)
../../../../iocore/eventsystem/I_Continuation.h:145
#9 0xc8b86e in EThread::process_event(Event*, int)
../../../../iocore/eventsystem/UnixEThread.cc:128
#10 0xc8da67 in EThread::execute()
../../../../iocore/eventsystem/UnixEThread.cc:207
#11 0xc8a488 in spawn_thread_internal
../../../../iocore/eventsystem/Thread.cc:85
#12 0x7f3c84392529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
#13 0x381370022c in __clone (/lib64/libc.so.6+0x381370022c)
0x604a2960 is located 16 bytes inside of 40-byte region
[0x604a2950,0x604a2978)
freed by thread T3 ([ET_NET 2]) here:
#0 0x7f3c84aaf64f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
#1 0xabbd16 in CacheDisk::delete_volume(int)
../../../../iocore/cache/CacheDisk.cc:330
#2 0xa7bfe0 in cplist_update ../../../../iocore/cache/Cache.cc:3212
#3 0xa7bfe0 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3374
#4 0xac619e in execute_and_verify(RegressionTest*)
../../../../iocore/cache/CacheHosting.cc:994
#5 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*)
../../../../iocore/cache/CacheHosting.cc:840
#6 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
#7 0x7f3c8480b4d2 in RegressionTest::run_some()
../../../../lib/ts/Regression.cc:125
#8 0x7f3c8480b9b6 in RegressionTest::check_status()
../../../../lib/ts/Regression.cc:140
#9 0x57b5b4 in RegressionCont::mainEvent(int, Event*)
../../../proxy/Main.cc:1220
#10 0xc8b86e in Continuation::handleEvent(int, void*)
../../../../iocore/eventsystem/I_Continuation.h:145
#11 0xc8b86e in EThread::process_event(Event*, int)
../../../../iocore/eventsystem/UnixEThread.cc:128
#12 0xc8da67 in EThread::execute()
../../../../iocore/eventsystem/UnixEThread.cc:207
#13 0xc8a488 in spawn_thread_internal
../../../../iocore/eventsystem/Thread.cc:85
#14 0x7f3c84392529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
previously allocated by thread T3 ([ET_NET 2]) here:
#0 0x7f3c84aaf14f in operator new(unsigned long)
(/lib64/libasan.so.1+0x5814f)
#1 0xaba5ca in CacheDisk::create_volume(int, long, int)
../../../../iocore/cache/CacheDisk.cc:296
#2 0xa74f81 in create_volume ../../../../iocore/cache/Cache.cc:3551
#3 0xa7ca20 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3405
#4 0xac619e in execute_and_verify(RegressionTest*)
../../../../iocore/cache/CacheHosting.cc:994
#5 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*)
../../../../iocore/cache/CacheHosting.cc:840
#6 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
#7 0x7f3c8480b4d2 in RegressionTest::run_some()
../../../../lib/ts/Regression.cc:125
#8 0x7f3c8480b9b6 in RegressionTest::check_status()
../../../../lib/ts/Regression.cc:140
#9 0x57b5b4 in RegressionCont::mainEvent(int, Event*)
../../../proxy/Main.cc:1220
#10 0xc8b86e in Continuation::handleEvent(int, void*)
../../../../iocore/eventsystem/I_Continuation.h:145
#11 0xc8b86e in EThread::process_event(Event*, int)
../../../../iocore/eventsystem/UnixEThread.cc:128
#12 0xc8da67 in EThread::execute()
../../../../iocore/eventsystem/UnixEThread.cc:207
#13 0xc8a488 in spawn_thread_internal
[jira] [Commented] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568488#comment-14568488 ] ASF subversion and git services commented on TS-3649: - Commit b8ca26129da735ca704555b485667704f563437e in trafficserver's branch refs/heads/5.3.x from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b8ca261 ] TS-3649: Add to CHANGES. (cherry picked from commit 133df337c682ca2ae76a983bfbdea51e2f2ffc82) Conflicts: CHANGES url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 5.3.1, 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568487#comment-14568487 ] ASF subversion and git services commented on TS-3649: - Commit d284c9d1a65cec9a7f69aa92547a87a746eb359d in trafficserver's branch refs/heads/5.3.x from [~gancho] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d284c9d ] TS-3649 Fix for url_sig plugin security issues (crash by HTTP request, circumvent signature). (cherry picked from commit 3f523ea5db49e244f9a09b4752d06031e3f31130) url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 5.3.1, 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568489#comment-14568489 ] ASF subversion and git services commented on TS-3649: - Commit 62be18134f670c0fc1884ded025e8314faf3bccb in trafficserver's branch refs/heads/5.3.x from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=62be181 ] TS-3649: Check key length during config parse (cherry picked from commit 7cae891870a5634dd28f2a679ff3b4f9a9fbe82b) url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 5.3.1, 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3632) libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
[
https://issues.apache.org/jira/browse/TS-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568486#comment-14568486
]
ASF subversion and git services commented on TS-3632:
-
Commit 6f0e54499d0bc371a2bbfff821a342ad669414c2 in trafficserver's branch
refs/heads/5.3.x from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6f0e544 ]
TS-3632: Add to CHANGES
(cherry picked from commit b2651964fd083237e8c505c4d0d603852c339f64)
Conflicts:
CHANGES
libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
-
Key: TS-3632
URL: https://issues.apache.org/jira/browse/TS-3632
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 5.3.0
Reporter: Igor Galić
Assignee: Jean Baptiste Favre
Fix For: 5.3.1, 6.0.0
When building ATS 5.3.0 on Ubuntu 11.04[1,2] a linking failure occurs
because of the ordering of the libraries:
{code}
libtool: link: c++ -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -pipe -Wall
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-mcx16 -rdynamic -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-z
-Wl,now -o .libs/traffic_manager AddConfigFilesHere.o traffic_manager.o
StatProcessor.o StatType.o StatXML.o ../../mgmt/web2/libweb.a
../../mgmt/api/.libs/libmgmtapilocal.a
/«PKGBUILDDIR»/lib/ts/.libs/libtsutil.so -lssl -lcrypto -L/usr/lib
../../mgmt/.libs/libmgmt_lm.a ../../proxy/hdrs/libhdrs.a
../../lib/records/librecords_lm.a ../../lib/ts/.libs/libtsutil.so
../../iocore/eventsystem/libinkevent.a ../../proxy/shared/liberror.a
../../proxy/shared/libdiagsconfig.a -lresolv -ltcl8.5 -lhwloc -lm
../../lib/wccp/libwccp.a ../../lib/tsconfig/.libs/libtsconfig.so -lcap -lpcre
-lz -lcrypt -lpthread -lrt -ldl /usr/lib/x86_64-linux-gnu/libxml2.so
-Wl,-rpath -Wl,/usr/lib/trafficserver
/usr/bin/ld: ../../lib/wccp/libwccp.a(WccpMsg.o): undefined reference to
symbol 'MD5_Final@@OPENSSL_1.0.0'
/usr/bin/ld: note: 'MD5_Final@@OPENSSL_1.0.0' is defined in DSO
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so so
try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so:
could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [traffic_manager] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/cmd/traffic_manager'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/cmd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [binary-arch] Error 2
{code}
[1]
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[2] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568490#comment-14568490 ] Phil Sorber commented on TS-3642: - Any resolution to this? proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Assignee: Sudheer Vinukonda Fix For: 6.0.0 Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3632) libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
[
https://issues.apache.org/jira/browse/TS-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568485#comment-14568485
]
ASF subversion and git services commented on TS-3632:
-
Commit 41f7209a6e74957d18790780f58374feea5a6eac in trafficserver's branch
refs/heads/5.3.x from [~jbfavre]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=41f7209 ]
TS-3632: Solve 'undefined reference to symbol MD5_Final@@OPENSSL_1.0.0'.
(cherry picked from commit 442f560ac4412a6cbbba6f69b029def418c9fbe8)
libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
-
Key: TS-3632
URL: https://issues.apache.org/jira/browse/TS-3632
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 5.3.0
Reporter: Igor Galić
Assignee: Jean Baptiste Favre
Fix For: 5.3.1, 6.0.0
When building ATS 5.3.0 on Ubuntu 11.04[1,2] a linking failure occurs
because of the ordering of the libraries:
{code}
libtool: link: c++ -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -pipe -Wall
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-mcx16 -rdynamic -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-z
-Wl,now -o .libs/traffic_manager AddConfigFilesHere.o traffic_manager.o
StatProcessor.o StatType.o StatXML.o ../../mgmt/web2/libweb.a
../../mgmt/api/.libs/libmgmtapilocal.a
/«PKGBUILDDIR»/lib/ts/.libs/libtsutil.so -lssl -lcrypto -L/usr/lib
../../mgmt/.libs/libmgmt_lm.a ../../proxy/hdrs/libhdrs.a
../../lib/records/librecords_lm.a ../../lib/ts/.libs/libtsutil.so
../../iocore/eventsystem/libinkevent.a ../../proxy/shared/liberror.a
../../proxy/shared/libdiagsconfig.a -lresolv -ltcl8.5 -lhwloc -lm
../../lib/wccp/libwccp.a ../../lib/tsconfig/.libs/libtsconfig.so -lcap -lpcre
-lz -lcrypt -lpthread -lrt -ldl /usr/lib/x86_64-linux-gnu/libxml2.so
-Wl,-rpath -Wl,/usr/lib/trafficserver
/usr/bin/ld: ../../lib/wccp/libwccp.a(WccpMsg.o): undefined reference to
symbol 'MD5_Final@@OPENSSL_1.0.0'
/usr/bin/ld: note: 'MD5_Final@@OPENSSL_1.0.0' is defined in DSO
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so so
try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so:
could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [traffic_manager] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/cmd/traffic_manager'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/cmd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [binary-arch] Error 2
{code}
[1]
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[2] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3603) Debug Assert occurs in UnixNetVConnection::set_enabled when accept_threads are disabled
[ https://issues.apache.org/jira/browse/TS-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3603: Backport to Version: (was: 5.3.1) Debug Assert occurs in UnixNetVConnection::set_enabled when accept_threads are disabled --- Key: TS-3603 URL: https://issues.apache.org/jira/browse/TS-3603 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.3.1, 6.0.0 Attachments: TS-3603.diff This was found while tracking down TS-3597. The assert stack is in a comment on that bug. When you don't have a dedicated assert thread, the mutex is not locked before going into the do_io_read to process the accept event. In the dedicated thread case, you end up exercising UnixNetVConnection::acceptEvent which does grab the mutex. May be a relatively harmless error. Since this is a newly created VC, there should be no race conditions on it. But violating locking assumptions seem like a really bad idea. Especially since grabbing a lock on a supposedly uncontended object should be cheap. A 5.3.x patch is attached to this bug which solves the problem on my build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3603) Debug Assert occurs in UnixNetVConnection::set_enabled when accept_threads are disabled
[ https://issues.apache.org/jira/browse/TS-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3603: Fix Version/s: 6.0.0 5.3.1 Debug Assert occurs in UnixNetVConnection::set_enabled when accept_threads are disabled --- Key: TS-3603 URL: https://issues.apache.org/jira/browse/TS-3603 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 5.3.1, 6.0.0 Attachments: TS-3603.diff This was found while tracking down TS-3597. The assert stack is in a comment on that bug. When you don't have a dedicated assert thread, the mutex is not locked before going into the do_io_read to process the accept event. In the dedicated thread case, you end up exercising UnixNetVConnection::acceptEvent which does grab the mutex. May be a relatively harmless error. Since this is a newly created VC, there should be no race conditions on it. But violating locking assumptions seem like a really bad idea. Especially since grabbing a lock on a supposedly uncontended object should be cheap. A 5.3.x patch is attached to this bug which solves the problem on my build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3632) libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
[
https://issues.apache.org/jira/browse/TS-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568464#comment-14568464
]
ASF subversion and git services commented on TS-3632:
-
Commit b2651964fd083237e8c505c4d0d603852c339f64 in trafficserver's branch
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b265196 ]
TS-3632: Add to CHANGES
libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
-
Key: TS-3632
URL: https://issues.apache.org/jira/browse/TS-3632
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 5.3.0
Reporter: Igor Galić
Assignee: Jean Baptiste Favre
Fix For: 6.0.0
When building ATS 5.3.0 on Ubuntu 11.04[1,2] a linking failure occurs
because of the ordering of the libraries:
{code}
libtool: link: c++ -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -pipe -Wall
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-mcx16 -rdynamic -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-z
-Wl,now -o .libs/traffic_manager AddConfigFilesHere.o traffic_manager.o
StatProcessor.o StatType.o StatXML.o ../../mgmt/web2/libweb.a
../../mgmt/api/.libs/libmgmtapilocal.a
/«PKGBUILDDIR»/lib/ts/.libs/libtsutil.so -lssl -lcrypto -L/usr/lib
../../mgmt/.libs/libmgmt_lm.a ../../proxy/hdrs/libhdrs.a
../../lib/records/librecords_lm.a ../../lib/ts/.libs/libtsutil.so
../../iocore/eventsystem/libinkevent.a ../../proxy/shared/liberror.a
../../proxy/shared/libdiagsconfig.a -lresolv -ltcl8.5 -lhwloc -lm
../../lib/wccp/libwccp.a ../../lib/tsconfig/.libs/libtsconfig.so -lcap -lpcre
-lz -lcrypt -lpthread -lrt -ldl /usr/lib/x86_64-linux-gnu/libxml2.so
-Wl,-rpath -Wl,/usr/lib/trafficserver
/usr/bin/ld: ../../lib/wccp/libwccp.a(WccpMsg.o): undefined reference to
symbol 'MD5_Final@@OPENSSL_1.0.0'
/usr/bin/ld: note: 'MD5_Final@@OPENSSL_1.0.0' is defined in DSO
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so so
try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so:
could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [traffic_manager] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/cmd/traffic_manager'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/cmd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [binary-arch] Error 2
{code}
[1]
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[2] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3504) Enabling proxy.config.cache.ram_cache.use_seen_filter and reloading the config dynamically causes traffic_server to core in the ram cache code
[ https://issues.apache.org/jira/browse/TS-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3504: Fix Version/s: 5.3.1 Enabling proxy.config.cache.ram_cache.use_seen_filter and reloading the config dynamically causes traffic_server to core in the ram cache code -- Key: TS-3504 URL: https://issues.apache.org/jira/browse/TS-3504 Project: Traffic Server Issue Type: Bug Affects Versions: 5.2.0 Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.3.1, 6.0.0 Enabling proxy.config.cache.ram_cache.use_seen_filter and reloading the config dynamically causes traffic_server to core in the ram cache code. RECU_RESTART_TS is not enforced and the internal variable is initialized with a callback. The `seen` array is only allocated in the resize_table method which is called from init so it works for a restart but not on a traffic_line -x reload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3504) Enabling proxy.config.cache.ram_cache.use_seen_filter and reloading the config dynamically causes traffic_server to core in the ram cache code
[ https://issues.apache.org/jira/browse/TS-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3504: Backport to Version: (was: 5.3.1) Enabling proxy.config.cache.ram_cache.use_seen_filter and reloading the config dynamically causes traffic_server to core in the ram cache code -- Key: TS-3504 URL: https://issues.apache.org/jira/browse/TS-3504 Project: Traffic Server Issue Type: Bug Affects Versions: 5.2.0 Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.3.1, 6.0.0 Enabling proxy.config.cache.ram_cache.use_seen_filter and reloading the config dynamically causes traffic_server to core in the ram cache code. RECU_RESTART_TS is not enforced and the internal variable is initialized with a callback. The `seen` array is only allocated in the resize_table method which is called from init so it works for a restart but not on a traffic_line -x reload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3632) libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
[
https://issues.apache.org/jira/browse/TS-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3632:
Backport to Version: (was: 5.3.1)
libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
-
Key: TS-3632
URL: https://issues.apache.org/jira/browse/TS-3632
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 5.3.0
Reporter: Igor Galić
Assignee: Jean Baptiste Favre
Fix For: 5.3.1, 6.0.0
When building ATS 5.3.0 on Ubuntu 11.04[1,2] a linking failure occurs
because of the ordering of the libraries:
{code}
libtool: link: c++ -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -pipe -Wall
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-mcx16 -rdynamic -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-z
-Wl,now -o .libs/traffic_manager AddConfigFilesHere.o traffic_manager.o
StatProcessor.o StatType.o StatXML.o ../../mgmt/web2/libweb.a
../../mgmt/api/.libs/libmgmtapilocal.a
/«PKGBUILDDIR»/lib/ts/.libs/libtsutil.so -lssl -lcrypto -L/usr/lib
../../mgmt/.libs/libmgmt_lm.a ../../proxy/hdrs/libhdrs.a
../../lib/records/librecords_lm.a ../../lib/ts/.libs/libtsutil.so
../../iocore/eventsystem/libinkevent.a ../../proxy/shared/liberror.a
../../proxy/shared/libdiagsconfig.a -lresolv -ltcl8.5 -lhwloc -lm
../../lib/wccp/libwccp.a ../../lib/tsconfig/.libs/libtsconfig.so -lcap -lpcre
-lz -lcrypt -lpthread -lrt -ldl /usr/lib/x86_64-linux-gnu/libxml2.so
-Wl,-rpath -Wl,/usr/lib/trafficserver
/usr/bin/ld: ../../lib/wccp/libwccp.a(WccpMsg.o): undefined reference to
symbol 'MD5_Final@@OPENSSL_1.0.0'
/usr/bin/ld: note: 'MD5_Final@@OPENSSL_1.0.0' is defined in DSO
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so so
try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so:
could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [traffic_manager] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/cmd/traffic_manager'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/cmd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [binary-arch] Error 2
{code}
[1]
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[2] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3590) H2 fetch streams marked as internal requests incorrectly
[ https://issues.apache.org/jira/browse/TS-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568447#comment-14568447 ] Phil Sorber commented on TS-3590: - Commit 372e03077 is for backport as well. H2 fetch streams marked as internal requests incorrectly Key: TS-3590 URL: https://issues.apache.org/jira/browse/TS-3590 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Sudheer Vinukonda A bug similar to TS-2906 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3642: Fix Version/s: 6.0.0 proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Assignee: Sudheer Vinukonda Fix For: 6.0.0 Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3632) libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
[
https://issues.apache.org/jira/browse/TS-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3632:
Fix Version/s: 5.3.1
libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
-
Key: TS-3632
URL: https://issues.apache.org/jira/browse/TS-3632
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 5.3.0
Reporter: Igor Galić
Assignee: Jean Baptiste Favre
Fix For: 5.3.1, 6.0.0
When building ATS 5.3.0 on Ubuntu 11.04[1,2] a linking failure occurs
because of the ordering of the libraries:
{code}
libtool: link: c++ -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -pipe -Wall
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-mcx16 -rdynamic -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-z
-Wl,now -o .libs/traffic_manager AddConfigFilesHere.o traffic_manager.o
StatProcessor.o StatType.o StatXML.o ../../mgmt/web2/libweb.a
../../mgmt/api/.libs/libmgmtapilocal.a
/«PKGBUILDDIR»/lib/ts/.libs/libtsutil.so -lssl -lcrypto -L/usr/lib
../../mgmt/.libs/libmgmt_lm.a ../../proxy/hdrs/libhdrs.a
../../lib/records/librecords_lm.a ../../lib/ts/.libs/libtsutil.so
../../iocore/eventsystem/libinkevent.a ../../proxy/shared/liberror.a
../../proxy/shared/libdiagsconfig.a -lresolv -ltcl8.5 -lhwloc -lm
../../lib/wccp/libwccp.a ../../lib/tsconfig/.libs/libtsconfig.so -lcap -lpcre
-lz -lcrypt -lpthread -lrt -ldl /usr/lib/x86_64-linux-gnu/libxml2.so
-Wl,-rpath -Wl,/usr/lib/trafficserver
/usr/bin/ld: ../../lib/wccp/libwccp.a(WccpMsg.o): undefined reference to
symbol 'MD5_Final@@OPENSSL_1.0.0'
/usr/bin/ld: note: 'MD5_Final@@OPENSSL_1.0.0' is defined in DSO
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so so
try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so:
could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [traffic_manager] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/cmd/traffic_manager'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/cmd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [binary-arch] Error 2
{code}
[1]
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[2] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3652) During 3xx redirect follow, TS uses the redirect url as the cache key ignoring any cache key set via API
[ https://issues.apache.org/jira/browse/TS-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3652: -- Issue Type: Bug (was: Improvement) During 3xx redirect follow, TS uses the redirect url as the cache key ignoring any cache key set via API Key: TS-3652 URL: https://issues.apache.org/jira/browse/TS-3652 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Sudheer Vinukonda Currently, during 3xx redirect follow, TS uses the redirect url (as received in the *Location* header of the 3xx response) as the cache key for storing the subsequent response to the redirect follow request). This works fine in most cases, since, the original client request would have cached the 3xx response and the final response would still be derived using the redirect follow url. This also allows direct requests to the redirect follow location be served from the cache efficiently. However, this is not desirable in some cases, especially when there's a TS API (plugin) modifying the cache key and wanting to store the final response against the modified cache key directly. Proposing to add a config setting to allow storing API set cache key during redirect follow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3652) During 3xx redirect follow, TS uses the redirect url as the cache key ignoring any cache key set via API
[ https://issues.apache.org/jira/browse/TS-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568404#comment-14568404 ] Sudheer Vinukonda commented on TS-3652: --- Discussed with [~zwoop] and it seems to us that, this behavior is actually a bug to not honor the API set cache lookup key, so we will just fix this without a config setting. During 3xx redirect follow, TS uses the redirect url as the cache key ignoring any cache key set via API Key: TS-3652 URL: https://issues.apache.org/jira/browse/TS-3652 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Sudheer Vinukonda Currently, during 3xx redirect follow, TS uses the redirect url (as received in the *Location* header of the 3xx response) as the cache key for storing the subsequent response to the redirect follow request). This works fine in most cases, since, the original client request would have cached the 3xx response and the final response would still be derived using the redirect follow url. This also allows direct requests to the redirect follow location be served from the cache efficiently. However, this is not desirable in some cases, especially when there's a TS API (plugin) modifying the cache key and wanting to store the final response against the modified cache key directly. Proposing to add a config setting to allow storing API set cache key during redirect follow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3597) TLS can fail accept / handshake since commit 2a8bb593fd
[
https://issues.apache.org/jira/browse/TS-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3597:
Fix Version/s: 5.3.1
TLS can fail accept / handshake since commit 2a8bb593fd
---
Key: TS-3597
URL: https://issues.apache.org/jira/browse/TS-3597
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Priority: Critical
Fix For: 5.3.1, 6.0.0
Attachments: TS-3597.diff
At least under certain conditions (slightly unclear,but possible a race with
multiple NUMA nodes), we fail to accept / TLS handshake. I've tracked this
down to the commit from 2a8bb593fdd7ca9125efad76e27f3f17f5bca794.
The commit prior to this does not expose the problem. [~gancho] also
discovered that this problem is only triggered when accept thread is off (0).
Also from [~gancho], when this reproduces, a command like e.g. this will fail
the handshake completely (no ciphers):
{code}
openssl s_client -connect 10.1.2.3:443 -tls1 -servername some.host.com
{code}
Also, since this only happens with accept thread off (0), which implies
accept on every ET_NET thread, maybe there's some sort of race condition
going on here? That's just a wild speculation though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3597) TLS can fail accept / handshake since commit 2a8bb593fd
[
https://issues.apache.org/jira/browse/TS-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3597:
Backport to Version: (was: 5.3.1)
TLS can fail accept / handshake since commit 2a8bb593fd
---
Key: TS-3597
URL: https://issues.apache.org/jira/browse/TS-3597
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Priority: Critical
Fix For: 5.3.1, 6.0.0
Attachments: TS-3597.diff
At least under certain conditions (slightly unclear,but possible a race with
multiple NUMA nodes), we fail to accept / TLS handshake. I've tracked this
down to the commit from 2a8bb593fdd7ca9125efad76e27f3f17f5bca794.
The commit prior to this does not expose the problem. [~gancho] also
discovered that this problem is only triggered when accept thread is off (0).
Also from [~gancho], when this reproduces, a command like e.g. this will fail
the handshake completely (no ciphers):
{code}
openssl s_client -connect 10.1.2.3:443 -tls1 -servername some.host.com
{code}
Also, since this only happens with accept thread off (0), which implies
accept on every ET_NET thread, maybe there's some sort of race condition
going on here? That's just a wild speculation though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3600) Missing break; statement in background_fetch plugin
[ https://issues.apache.org/jira/browse/TS-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3600: Fix Version/s: 5.3.1 Missing break; statement in background_fetch plugin --- Key: TS-3600 URL: https://issues.apache.org/jira/browse/TS-3600 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.1, 6.0.0 This causes us to fall through in an undesirable way. Somehow, it still seems to work, but is clearly wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3600) Missing break; statement in background_fetch plugin
[ https://issues.apache.org/jira/browse/TS-3600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3600: Backport to Version: (was: 5.3.1) Missing break; statement in background_fetch plugin --- Key: TS-3600 URL: https://issues.apache.org/jira/browse/TS-3600 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.3.1, 6.0.0 This causes us to fall through in an undesirable way. Somehow, it still seems to work, but is clearly wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3649: Backport to Version: (was: 5.3.1) url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 5.3.1, 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3649) url_sig plugin security issues (crash by HTTP request, circumvent signature)
[ https://issues.apache.org/jira/browse/TS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3649: Fix Version/s: 5.3.1 url_sig plugin security issues (crash by HTTP request, circumvent signature) Key: TS-3649 URL: https://issues.apache.org/jira/browse/TS-3649 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Gancho Tenev Assignee: Gancho Tenev Fix For: 5.3.1, 6.0.0 Attachments: TS-3649-url_sig-security_issues.patch, TS-3649-url_sig-security_issues.rtf While reading the code found 2 security issues url_sig code which would allow: - Issue 1: to crash ATS which is running the url_sig plugin by using an HTTP request (segmentation fault due out-of-bounds array access) - there is a need of proper sanitation of the key index input (query parameter) - Issue 2: to gain access to protected assets by signing the URL with an empty secret key if at least one of the 16 keys is not provided in the uri_sig plugin configuration. One could scan trying all keys 0 to 15 and for the empty key the signature validation would succeed - must deny access if the key specified in the signature is not defined in the plugin config (empty). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3652) During 3xx redirect follow, TS uses the redirect url as the cache key ignoring any cache key set via API
[ https://issues.apache.org/jira/browse/TS-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3652: -- Description: Currently, during 3xx redirect follow, TS uses the redirect url (as received in the *Location* header of the 3xx response) as the cache key for storing the subsequent response to the redirect follow request. This works fine in most cases, since, the original client request would have cached the 3xx response and the final response would still be derived using the redirect follow url. This also allows direct requests to the redirect follow location be served from the cache efficiently. However, this is not desirable in some cases, especially when there's a TS API (plugin) modifying the cache key and wanting to store the final response against the modified cache key directly. Proposing to add a config setting to allow storing API set cache key during redirect follow. was: Currently, during 3xx redirect follow, TS uses the redirect url (as received in the *Location* header of the 3xx response) as the cache key for storing the subsequent response to the redirect follow request). This works fine in most cases, since, the original client request would have cached the 3xx response and the final response would still be derived using the redirect follow url. This also allows direct requests to the redirect follow location be served from the cache efficiently. However, this is not desirable in some cases, especially when there's a TS API (plugin) modifying the cache key and wanting to store the final response against the modified cache key directly. Proposing to add a config setting to allow storing API set cache key during redirect follow. During 3xx redirect follow, TS uses the redirect url as the cache key ignoring any cache key set via API Key: TS-3652 URL: https://issues.apache.org/jira/browse/TS-3652 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Sudheer Vinukonda Currently, during 3xx redirect follow, TS uses the redirect url (as received in the *Location* header of the 3xx response) as the cache key for storing the subsequent response to the redirect follow request. This works fine in most cases, since, the original client request would have cached the 3xx response and the final response would still be derived using the redirect follow url. This also allows direct requests to the redirect follow location be served from the cache efficiently. However, this is not desirable in some cases, especially when there's a TS API (plugin) modifying the cache key and wanting to store the final response against the modified cache key directly. Proposing to add a config setting to allow storing API set cache key during redirect follow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3590) H2 fetch streams marked as internal requests incorrectly
[ https://issues.apache.org/jira/browse/TS-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3590: Fix Version/s: 6.0.0 5.3.1 H2 fetch streams marked as internal requests incorrectly Key: TS-3590 URL: https://issues.apache.org/jira/browse/TS-3590 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Sudheer Vinukonda Fix For: 5.3.1, 6.0.0 A bug similar to TS-2906 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3590) H2 fetch streams marked as internal requests incorrectly
[ https://issues.apache.org/jira/browse/TS-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3590: Backport to Version: (was: 5.3.1) H2 fetch streams marked as internal requests incorrectly Key: TS-3590 URL: https://issues.apache.org/jira/browse/TS-3590 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Sudheer Vinukonda Fix For: 5.3.1, 6.0.0 A bug similar to TS-2906 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
