staticweb middleware ignores acl and breaks clients

[Christian Schwede]

Two issues were found in the staticweb middleware. They might be just "normal" bugs, but I prefer to start with a private security bug first; however the impact looks rather low to me atm.

1.staticweb middleware does not check acls
The documentation says that a read-acl setting of ".r:*" must be set, however this is never checked in staticweb. At least in combination with tempauth this allows container listings without any ACL set. Note that the staticweb middleware must still be enabled on a container, and this can only done by an account owner (because it requires a POST to the container).

2. Might break clients if used before any auth module in the proxy pipeline
Actually this looks simple at first, but might be a little bit worse than #1. If an operator puts the staticweb middleware before the authentication middleware, it responds with a HTML listing for GET and HEAD requests if this is enabled on a container, even if a token is sent. In case of python-swiftclient this might lead to a situation where a user thinks there is an empty, private container but actually the container is public readable. Note: the documentation already says to put staticweb after an auth middleware in the pipeline.

For example, using master on swift and python-swiftclient on a SAIO (put staticweb before tempauth in the proxy pipeline to verify this):

# Create a new container and upload an object
vagrant@saio:~/swift$ swift upload container testobj
testobj

# Expected output
vagrant@saio:~/swift$ swift stat -v container
             URL: http://saio:8080/v1/AUTH_test/container
      Auth Token: AUTH_tk3f556ba123fe4ac5a17da69b5b99cc22
         Account: AUTH_test
       Container: container
         Objects: 1
           Bytes: 0
        Read ACL:
       Write ACL:
         Sync To:
        Sync Key:
   Accept-Ranges: bytes
X-Storage-Policy: default
     X-Timestamp: 1440746384.43528
      X-Trans-Id: txa77acfe8bd00465fadd26-0055e00b95
    Content-Type: text/plain; charset=utf-8

# Now enable listings
vagrant@saio:~/swift$ swift post -m "web-listings: true" container

vagrant@saio:~/swift$ curl http://saio:8080/v1/AUTH_test/container/
[...snipped...the html listing shown now, as expected including "testobj"]

# Now in case of python-swiftclient: 0 objects, no ACLs, no enabled web listing
vagrant@saio:~/swift$ swift stat -v container
         URL: http://saio:8080/v1/AUTH_test/container
  Auth Token: AUTH_tk3f556ba123fe4ac5a17da69b5b99cc22
     Account: AUTH_test
   Container: container
     Objects: 0
       Bytes: 0
    Read ACL:
   Write ACL:
     Sync To:
    Sync Key:
Content-Type: text/html; charset=UTF-8
  X-Trans-Id: tx233a6fd34a184c9e8d455-0055e00bb7

Note that this is still true if there is a public read acl set. Thus it is possible to list and download objects, but in case of python-swiftclient a private empty container is reported. Other clients might be affected as well (due to the HTML response).

A patch to fix both issues has been attached. Overall existing testing could be further improved; for example you can completely remove the read acl and all tests still pass on master.

[Christian Schwede (cschwede)]

Hmm, this is tricky and might affect a few more users. Not yet adding openstack/puppet-swift; however I attached a patch ready for this as well.

openstack/puppet-swift puts staticweb in front of keystone in the proxy pipeline; not sure how many operators use this module, but this might result in a much wider distribution of the problem #2.

https://github.com/openstack/puppet-swift/blob/master/manifests/proxy/staticweb.pp#L23
https://github.com/openstack/puppet-swift/blob/master/manifests/proxy/keystone.pp#L35

In fact other middlewares might be not in the correct pipeline order as well, but that seems to be a different problem:

vagrant@saio:~/puppet-swift$ grep order manifests/proxy/* | sort -t ':' -k 2 | cut -f 3- -d "/"
tempauth.pp: order => '01',
swauth.pp: order => '20',
bulk.pp: order => '21',
authtoken.pp: order => '22',
cache.pp: order => '23',
catch_errors.pp: order => '24',
healthcheck.pp: order => '25',
ratelimit.pp: order => '26',
proxy_logging.pp: order => '27',
swift3.pp: order => '27',
s3token.pp: order => '28',
tempurl.pp: order => '29',
formpost.pp: order => '31',
staticweb.pp: order => '32',
ceilometer.pp: order => '33',
gatekeeper.pp: order => '34',
crossdomain.pp: order => '35',
slo.pp: order => '35',
keystone.pp: order => '79',
account_quotas.pp: order => '80',
container_quotas.pp: order => '81',

[Christian Schwede (cschwede)]

Also, please note that swift_owner_headers don't include "web-listings". Depending on the used auth middleware and implementation of a Swift owner it might be possible for a non-owner to enable web-listings, though read-acls are not editable by that user and thus leading to an information leakage.

https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L204-L207
https://github.com/openstack/swift/blob/master/swift/proxy/controllers/container.py#L182-L184

However, afair this doesn't apply to tempauth and keystoneauth.

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[clayg (clay-gerrard)]

So static-web is definitely supposed to be after auth in the pipeline - if it appears anywhere else it's a configuration bug (it sucks that pipeline configuration is so hard, but thems the knocks).

If we are able to validate there is security implications of this mis-configuration we could:

a) document them

b) think harder about making middleware capable of describing ordering requirements like "after auth"

... but I'm dubious of any effort to make static-web "work" in some sort of off-the-rails configuration? Does this *only* effect pipelines with staticweb in the wrong place?

@Christian

The patch isn't immediately obvious to me. The next if branch after your patch (that checks if it's an as of yet unauthenticated request with a token) checks to see if it *is* an authenticated request and unless web-mode is true - just call into the app directly. That seems like it should be enough to prevent staticweb from messing with the output of the container listing when called from python-swiftclient. We should understand why that is not sufficient - even if adding your check seems to make the undesirable behavior go away.

The bug report also says "static web does not check acls" - and that may be true, but it's not a bug? staticweb should *not* be in the business of authorizing requests. It should let the normal authorization do that - and on authorized responses perform translations/redirects only - if it starts to build up it's own model for auth outside of "this request will not work unless the user could have made this request anyway" - then we're asking for more bugs.

I don't understand exactly what's broken here - how is a `curl http://saio:8080/v1/AUTH_test/container/` working with an acl - how is static web *breaking* the normal authorization checks in the pipeline? Is someone not installing a default deny authorize callback like they should? Is a sub-request causing the authorize callback to be removed prematurely?

Can you validate your observed behavior on d4409c0a^ and see if maybe we accidentally broke something while fixing the other?

[Christian Schwede (cschwede)]

> So static-web is definitely supposed to be after auth in the pipeline -
> if it appears anywhere else it's a configuration bug (it sucks that
> pipeline configuration is so hard, but thems the knocks).

Yes, it's a configuration bug - however, I think we can do better and in case of
a misconfiguration issue a warning at least and possibly skip staticweb.

> The patch isn't immediately obvious to me. The next if branch after
> your patch (that checks if it's an as of yet unauthenticated request
> with a token) checks to see if it *is* an authenticated request and
> unless web-mode is true - just call into the app directly.

The if branch added by me is only required to fix the issue if staticweb is in
the pipeline before auth. If staticweb is configured as described in the
documentation, it works as expected and doesn't return html on authenticated
requests.

> The bug report also says "static web does not check acls" - and that may
> be true, but it's not a bug? staticweb should *not* be in the business
> of authorizing requests. It should let the normal authorization do that
> - and on authorized responses perform translations/redirects only - if
> it starts to build up it's own model for auth outside of "this request
> will not work unless the user could have made this request anyway" -
> then we're asking for more bugs.

I should have described this differently: "Read ACLs are not checked if
staticweb is used". staticweb uses make_pre_authed_env, thus there is no check
at all and a read_acl in the form of ".r:*, .rlistings" is not required, though
mentioned in the docs. Thus either the documentation needs a fix, or the code -
I would prefer the later, enforcing the use of set ACLs and not allowing
staticweb to pass around them.

> Can you validate your observed behavior on d4409c0a^ and see if maybe we
> accidentally broke something while fixing the other?

This is nothing new, the described behavior applies to older Swift releases as
well.

I updated the patch, and now instead of make_pre_authed_env it just uses
make_env. However, this might break deployments because it is now required to
use ".r:*,.rlistings" to make staticweb work; the docs mentioned only ".r:*"
before.

Apart from the questionable behavior, openstack/puppet-swift does put
staticweb before keystone; though there are probably quite a few
deployments out there that see this issue. Granted, that's the problem
of openstack/puppet-swift, and I'd like to submit a fix to openstack/puppet-swift
soon. IMO it's only fixing the client issues, not the acl thing; thus I think
it's safe to do this right now without any OSSA. Objections?

[John Dickinson (notmyname)]

While the additional checks in code (as Christian suggests) would be good in Swift, it doesn't seem that this is a security bug in Swift. However, we should consider submitting it as a security bug to puppet-swift. before we open this one. ie it seems responsible to give people a chance to upgrade before we just say "too bad, you shouldn't have messed up your config"

[Tristan Cacqueray (tristan-cacqueray)]

Emilien (puppet PTL) is now subscribed, let us know if you need help to manage the disclosure process

[Emilien Macchi (emilienm)]

We should consider the middleware ordering as a security issue in openstack/puppet-swift.

Draft Impact Description:

When adding ::swift::proxy::staticweb class, 'staticweb' middleware section will be added before Keystone options but the staticweb middleware needs to be put after authentication middlewares to
ensure correct functionality as documented in
http://docs.openstack.org/developer/swift/middleware.html#staticweb

Without this Swift sends a HTML response even if the request was done using a
X-Auth-Token. This might result in a faulty handling of the response on the client
side; for example, "swift stat containername" would report an empty, private container,
while the container might actually be public readable with data stored in it.

We are about to submit a patch that fix the issue and backport it until stable branches (Kilo, Juno and Icehouse).

[Emilien Macchi (emilienm)]

We would like to submit a patch in attachment. I also added Mathieu Gagne, Puppet OpenStack core developer.

[Mathieu Gagné (mgagne)]

I confirm the bug reported affects puppet-swift and the patch proposed by EmilienM fixes it.

[Emilien Macchi (emilienm)]

Title: Wrong staticweb middleware order in Swift proxy Puppet configuration
Reporter: Christian Schwede
Products: openstack/puppet-swift
Affects: Icehouse, Juno, Kilo, Trunk (Liberty)

Description:
Christian Schwede reported a vulnerability in openstack/puppet-swift by configuring puppet-swift to enable staticweb middleware. The current state of the module is that it configures the middleware in the wrong place so private Swift containers might be public readable with data stored in it.
Only setups where staticweb middleware is explicitly enabled are affected.

[Emilien Macchi (emilienm)]

Amending last comment:

Affects: 4.0, 4.1, 5.0, 4.1, 6.x and master.

4.x is icehouse, 5.x is juno and 6.x is kilo releases.

[Emilien Macchi (emilienm)]

Since Icehouse is not supported, the bug affects Juno, Kilo and Master.

Affects: 5.0, 5.1, 6.0 and master.

The patch will be fixed in master, backported to stable/juno and stable/kilo, then released in 5.2, 6.1 and 7.0 (when Liberty will be released).

[Emilien Macchi (emilienm)]

Apologizes for the last comments, it's the first time I'm doing this.
Let me summarize a last time the bug description:

Title: Wrong staticweb middleware order in Swift proxy Puppet configuration
Reporter: Christian Schwede
Products: puppet-swift
Affects: 5.0, 5.1, 6.0.

Description:
Christian Schwede reported a vulnerability in openstack/puppet-swift by configuring puppet-swift to enable staticweb middleware. The current state of the module is that it configures the middleware in the wrong place so private Swift containers might be public readable with data stored in it.
Only setups where staticweb middleware is explicitly enabled are affected.

The patch will be fixed in master, backported to stable/juno and stable/kilo, then released in 5.2, 6.1.

[Tristan Cacqueray (tristan-cacqueray)]

Thank you Emilien for following the vmt-process. Here are a few suggestions:

Title: Wrong staticweb middleware order in Swift proxy Puppet configuration
Reporter: Christian Schwede (Red Hat)
Products: puppet-swift
Affects: versions through 5.1.0 and version 6.0.0

Description:
Christian Schwede from Red Hat reported a vulnerability in puppet-swift. When the staticweb middleware is enabled, it is incorrectly configured before the keystone auth middleware, allowing anonymous access to private Swift containers. All setups configured with staticweb middleware are affected.

The next steps are:
* review and approve propose impact description draft
* submit and approve backports to Juno and Kilo
* request a CVE

[Emilien Macchi (emilienm)]

Thank you Tristan, I confirm your suggestion is the one we should use for the CVE request.

[Emilien Macchi (emilienm)]

In attachment, the patch to apply in master. This patch is fixing future liberty release.?field.comment=In attachment, the patch to apply in master. This patch is fixing future liberty release.

[Emilien Macchi (emilienm)]

In attachment, the patch for Kilo (6.0).

[Emilien Macchi (emilienm)]

In attachment, the patch for Juno (5.1).

[Mathieu Gagné (mgagne)]

I confirm the 3 proposed patches (for each version) fix the problem.

[clayg (clay-gerrard)]

ok, I really like the second patch @cschwede attached in comment #6

I think the make_pre_authed_env may actually have some dragons in there beyond what @cschwede already found when the pipeline order is wrong (if anyone bothered to try and dig).

Can we not make that patch until the puppet thing is fixed? And maybe add it like ASAP after the disclosure?

[Tristan Cacqueray (tristan-cacqueray)]

No disclosure date have been defined yet. If there is a dragon hiding in swift, we can block until this solved.

[Christian Schwede (cschwede)]

@Clay: so far I did not found any more daemons, tried a lot of ideas, but the only other thing I found is related to account acls. That doesn't mean that I found everything yet....

The following example works also with the correct pipeline order; the make_pre_auth_env is the problem here again. Users with a read-write account acl might abuse this, because the staticweb meta keys are unprivileged keys (while read acl is a privileged key and thus removed if sent from a non-owner). This might apply to other authentication middlewares as well; basically whenever non-owners can post to a container.

# Upload a dummy object. Note the 401 in the beginning; if there are objects
# stored in the container that begin with a valid http code, they could be made
# public readable without an acl. see below
echo -e "\nsomething secret\n" > 401storiesaboutasecret
swift upload mycontainer 401storiesaboutasecret

# allow read/write access to test:tester3 to containers
swift post -H 'X-Account-Access-Control: {"read-write":["test:tester3"]}'

# test:tester3 can't modify acls on the container - this is as expected
swift -U test:tester3 -K testing3 post -r ".r:*" mycontainer
swift stat -v mycontainer

# However, test:test3 can enable staticweb, and listing works without any acl
swift -U test:tester3 -K testing3 post -m "web-listings: true" mycontainer
curl http://saio:8080/v1/AUTH_test/mycontainer/

# And for the sake of it - abuse the error response
swift -U test:tester3 -K testing3 post -m "web-index: some_non_existing_objectname" mycontainer
swift -U test:tester3 -K testing3 post -m "web-error: storiesaboutasecret" mycontainer
curl http://saio:8080/v1/AUTH_test/mycontainer/

Also, we might want to improve logging; the "real" objectname only shows up in the object-server logs, not in the proxy server log, thus auditing GET requests is somewhat more difficult.

[Christian Schwede (cschwede)]

For better readability - the commands attached as a shell script.

[Tristan Cacqueray (tristan-cacqueray)]

CVE-2015-5249 have been assigned for the puppet miss-configuration of swift.

For the swift make_pre_auth_env issue, only user with r/w can abused it right ? It sounds like this can be fixed after the puppet-swift become public.

Before picking a disclosure date, are we sure other modules don't have a similar issue (as mentioned in comment #2) ?

[Emilien Macchi (emilienm)]

@tristan: only puppet-swift has this issue.

Disclosure would be in one week, Sep 9 2015

[Tristan Cacqueray (tristan-cacqueray)]

Clay, does it sounds good to you ?

[Christian Schwede (cschwede)]

Attached patch from #6 with an additional test to ensure authentication middleware is used before staticweb.

[Tristan Cacqueray (tristan-cacqueray)]

Since the swift bug does not yield a security vulnerability there is no need to have an OSSA tasks here.

[clayg (clay-gerrard)]

All the comments here make sense to me.

puppet-swift team should pick the disclosure date.

I think the swift team can add @cschwede's suggested helper/fix/cleanup in gerrit on master as soon as the puppet-swift team discloses.

[Emilien Macchi (emilienm)]

I thought I would get by e-mail a list of stackholders to inform but I haven't got any email.
So I'll wait until tomorrow and if I still have nothing, I'll disclose the bug, and submit the patchs upstream.

[Tristan Cacqueray (tristan-cacqueray)]

Emilien, I was waiting for you to find and validate a disclosure date. But considering the risk is pretty low, opening this bug tomorrow sounds like a good idea too.

[Tristan Cacqueray (tristan-cacqueray)]

Turns out the filter ordering in puppet is not actually affected. The CVE-2015-5249 is reject.

[Jeremy Stanley (fungi)]

If this has been thoroughly debunked, I recommend switching to a regular public bug.

[Emilien Macchi (emilienm)]

After discussion, there is no bug in puppet-swift, since the ordering is done by the "pipeline" parameter, which is not defaulted in puppet-swift. So it's up to installers (users of the module) to correctly set the right order.

[Jeremy Stanley (fungi)]

At this point, I recommend switching this report to a regular public bug.

[Tristan Cacqueray (tristan-cacqueray)]

Unless there is a complain, let's open this tomorrow.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/227204

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/234828

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/227204
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=a7af802497f3b86d33cbee852500df456c316685
Submitter: Jenkins
Branch: master

commit a7af802497f3b86d33cbee852500df456c316685
Author: Christian Schwede <email address hidden>
Date: Sat Aug 29 16:03:07 2015 +0000

    Do not use pre-authenticated requests in staticweb

    staticweb middleware uses make_pre_authed_env, this makes it possible to
    anonymously list containers without any read acl set if the metadata
    "web-listings: true" is set on a container. Using make_env enforces correct
    read_acl validation; however it is now also required to add ".rlistings" to the
    read acl.

    Also, if the staticweb middleware is put in the proxy pipeline before an
    authentication middleware, it broke authenticated GET and HEAD requests. This
    has some side effects in clients, because a html response is sent that might be
    parsed wrongly by the client. In case of python-swiftclient this was shown as an
    empty container without any ACL or web-listings:true meta set. This might lead
    to information leaks, because a user trusts the output from python-swiftclient
    and assumes an empty, private container even if the container contains public
    readable data. staticweb now checks if "swift.authorize" is included in the
    environ and skips itself if not.

    Closes-Bug: 1489749
    Change-Id: Icf159d7e567ac5481e710c5910db686bdcba6336
    Depends-On: Ie24bb995023c377e49796910ad80a256b00daa03

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/234828
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=9993c1f124bcb6d645254196fe43d8c4f9feae6e
Submitter: Jenkins
Branch: master

commit 9993c1f124bcb6d645254196fe43d8c4f9feae6e
Author: Alistair Coles <email address hidden>
Date: Wed Oct 14 15:49:35 2015 +0100

    Add test to verify staticweb uses auth'd subrequests

    Follow on for change Icf159d7e567ac5481e710c5910db686bdcba6336

    Related-Bug: 1489749

    Change-Id: I96920645d50322c5232bbcd6bb38b0f26795b92d

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: feature/crypto
Review: https://review.openstack.org/244249

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/244249
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=19226e4449bca399981cde3a1e9882735fed74d5
Submitter: Jenkins
Branch: feature/crypto

commit 2d85a3f6997fbadac210207f841c4ec25ff50cc4
Author: Tushar Gohad <email address hidden>
Date: Fri Oct 23 13:16:33 2015 +0000

    EC: Use best available ec_type in unittests

    To minimize external library dependencies for Swift unit
    tests and SAIO, PyECLib 1.1.1 introduces a native backend
    'liberasurecode_rs_vand.' This patch is to migrate over
    the unit tests to the new ec_type when available.

    This change will work with current pyeclib requirements
    (==1.0.7) and also future requirements (>=1.0.7).

    When we're able to raise *our* requirements to >=1.1.1 we
    should remove jerasure from the list of preferred backends.
    Related SAIO doc and example config changes should be
    included with that patch.

    Co-Authored-By: Clay Gerrard <email address hidden>
    Change-Id: Idf657f0acf0479bc8158972e568a29dbc08eaf3b

commit 66dc1eebb1db51c81891b1f7bcc3e85aef9b8c1d
Author: Bill Huber <email address hidden>
Date: Fri Oct 16 11:27:34 2015 -0500

    ObjectControllers return application errors as 499 on bad read

    In the _transfer_data method, we translate all (Exception, Timeout)
    into a 499 whereas we should consider translating them to 500 on
    particular returning error scenarios.

    This affects both ReplicatedObjectController and ECObjectControllear.

    Change-Id: I571bbc5b1451243907b094a5718c8735fd824268
    Closes-Bug: 1504299

commit 705642db4c27c34ac8eb840d40b16470b85418c8
Author: venkatamahesh <email address hidden>
Date: Tue Nov 10 19:46:31 2015 +0530

    Change stackforge repo to openstack repo

    The projects which are moved to openstack
    are corrected by replacing stackforge with openstack

    Change-Id: I65b794a7f10df617bc2a4caf2c4010477a82dbc2

commit d755f5b52024e255787d180bbca60c09192a8850
Author: John Dickinson <email address hidden>
Date: Mon Nov 9 22:03:34 2015 -0800

    suppress warning output in a unit test

    test_write_builder_after_device_removal() wasn't setting a
    default min_part_hours so a warnign was printed. Explicitly
    adding a min_part_hours suppresses the warning

    Change-Id: I6f234b72c34e066abb91f28e6eacf50e29be8842

commit 37337d5fcb0a29344381f8de7d810a9e76e10928
Author: Pradeep Kumar Singh <email address hidden>
Date: Sun May 17 13:35:58 2015 +0530

    Read the response body, if response status is greater than 300.

    internal_client was not reading response if response status is not 200.
    So proxy server treats this as client disconnect and logs 499 in log file.
    This patch fixes that by reading response if response status is greater
    than or equal to 300 and in acceptable statuses.

    Closes-Bug: #1364752

    Change-Id: I0512a25895da583956f76031e3c5de5c970bce01

commit c81f202f714c36390a25b24fa96d1b277788ade9
Author: Kota Tsuyuzaki <email address hidden>
Date: Thu Nov 5 17:37:30 2015 -0800

    Add missing docs for ring.builder.rebalance

 ...

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: feature/hummingbird
Review: https://review.openstack.org/264517

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/264517
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=93ddaffaebb620bc712d52d0267194562dce02be
Submitter: Jenkins
Branch: feature/hummingbird

commit f53cf1043d078451c4b9957027bf3af378aa0166
Author: Ondřej Nový <email address hidden>
Date: Tue Jan 5 20:20:15 2016 +0100

    Fixed few misspellings in comments

    Change-Id: I8479c85cb8821c48b5da197cac37c80e5c1c7f05

commit 79222e327f9df6335b58e17a6c8dd0dc44b86c17
Author: ChangBo Guo(gcb) <email address hidden>
Date: Sat Dec 26 13:13:37 2015 +0800

    Fix AttributeError for LogAdapter

    LogAdapter object has no attribute 'warn' but has attribute
    'warning'.

    Closes-Bug: #1529321
    Change-Id: I0e0bd0a3dbc4bb5c1f0b343a8809e53491a1da5f

commit 684c4c04592278a280032002b5313b171ee7a4c0
Author: janonymous <email address hidden>
Date: Sun Aug 2 22:47:42 2015 +0530

    Python 3 deprecated the logger.warn method in favor of warning

    DeprecationWarning: The 'warn' method is deprecated, use 'warning'
    instead

    Change-Id: I35df44374c4521b1f06be7a96c0b873e8c3674d8

commit d0a026fcb8e8a9f5475699cc56e1998bdc4cd5ca
Author: Hisashi Osanai <email address hidden>
Date: Wed Dec 16 18:50:37 2015 +0900

    Fix duplication for headers in Access-Control-Expose-Headers

    There are following problems with Access-Control-Expose-Headers.

    * If headers in X-Container-Meta-Access-Control-Expose-Headers are
      configured, the headers are kept with case-sensitive string.
      Then a CORS request comes, the headers are merged into
      Access-Control-Expose-Headers as case-sensitive string even if
      there is a same header which is not case-sensitive string.

    * Access-Control-Expose-Headers is handled by a list.
      If X-Container/Object-Meta-XXX is configured in container/object
      and X-Container-Meta-Access-Control-Expose-Headers, same header
      is listed in Access-Control-Expose-Headers.

    This patch provides a fix for the problems.

    Change-Id: Ifc1c14eb3833ec6a851631cfc23008648463bd81

commit 0bcd7fd50ec0763dcb366dbf43a9696ca3806f15
Author: Bill Huber <email address hidden>
Date: Fri Nov 20 12:09:26 2015 -0600

    Update Erasure Coding Overview doc to remove Beta version

    The major functionality of EC has been released for Liberty and
    the beta version of the code has been removed since it is now
    in production.

    Change-Id: If60712045fb1af803093d6753fcd60434e637772

commit 84ba24a75640be4212e0f984c284faf4c894e7c6
Author: Alistair Coles <email address hidden>
Date: Fri Dec 18 11:24:34 2015 +0000

    Fix rst errors so that html docs are complete

    rst table format errors don't break the gate job
    but do cause sections of the documents to go missing
    from the html output.

    Change-Id: Ic8c9953c93d03dcdafd8f47b271d276c7b356dc3

commit 87f7e907ee412f5847f1f9ffca7a566fb148c6b1
Author: Matthew Oliver <email address hidden>
Date: Wed Dec 16 17:19:24 2015 +1100

    Pass HTTP_REFERER down to subrequests

    Currently a HTTP_REFERER (Referer) header isn't passed down to
    subreq...

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/swift 2.6.0 release.