http proxying can break webapi and leak capabilities (manifests as JSON decoding error in CLI tests) #1253
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#1253
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
On tahoe-dev, Yonggang Wen and Jimmy Tang reported errors with r4803 (nearly current trunk) in the following tests:
For example:
Other tests with errors also go through [line 32 of tahoe_mv.py]source:src/allmydata/scripts/tahoe_mv.py@4803#L32.
It's not clear yet whether simplejson is failing to decode valid JSON, or whether the gateway is producing JSON that is not strictly valid.
modified /Users/jtang/sandbox/allmydata-tahoe-1.8.0-r4803/src/allmydata/scripts/tahoe_mv.py by changing line 32 to:
I then did a python setup.py build and re-ran the tests as instructed. I've copied and pasted anything that failed with an ERROR below
OK, this seems to be due to a squid proxy intercepting webapi requests. Jimmy Tang's comment on tahoe-dev supports that conclusion:
Presumably this would also break actual use of the webapi, not just tests.
In theory, requests to 127.0.0.1 should either not be intercepted or should be passed through transparently, but that's not happening for this particular proxy configuration. The proxy is returning the following HTML error document, which is obviously not valid JSON:
Note that any response that starts with a '<' (or a BOM followed by '<') is likely to be HTML coming from something other than the intended gateway; we should give a better error report in that case.
JSON decoding error in CLI tests on an OS X 10.6 systemto http proxying can break webapi (manifests as JSON decoding error in CLI tests)Replying to jcftang:
Replying to davidsarah:
Please try setting the http_proxy and HTTP_PROXY variables as they were before, and the no_proxy variable to "127.0.0.1:56496".
Replying to [davidsarah]comment:4:
Oh, that probably won't work because the port is dynamic. Try setting no_proxy just to "127.0.0.1" instead.
hm, perhaps we should add an early test (i.e. alphabetically first) which just tries a simple HTTP request to self, to catch things like HTTP_PROXY? The error message on that test could look at
os.environ["HTTP_PROXY"]
and mention that it might be interfering with the self-tests, and remind users to configure their proxies to allow 127.0.0.1 to connect directly.(Foolscap has a
test*versions.py
that runs before everything else, so that its output is easier to find.. we could add atest*http_proxy.py
to Tahoe and maybe evenos.abort()
the whole test run if it fails, to avoid later confusion)in reply to comment:5, i tried setting the no_proxy variable and leaving my http_proxy (and friends) variables alone, I now get errors such as...
the end of the tests... just to be sure im pasting the correct error messages...
in response to comment:3 I will need to download the trunk from the trac interface when I'm in work tomorrow morning to test again. I've so far been testing the near trunk branch from the git repo.
Hmm, I see the problem. Most of our code uses
httplib
(which does not make use of the http_proxy or HTTP_PROXY variables) to establish HTTP connections, but tahoe_mv.py usesurllib.urllopen
[here]source:src/allmydata/scripts/tahoe_mv.py@4811#L31. That's why only the tests oftahoe mv
are failing.(There is another use of
urllib.urlopen
in source:src/allmydata/test/check_load.py, but that's not run bysetup.py test
.)This could cause capabilities (specifically, the source arguments to
tahoe mv
ortahoe ln
) to be leaked to the HTTP proxy server. The proxy server is not in our reliance diagram and therefore not supposed to be trusted.http proxying can break webapi (manifests as JSON decoding error in CLI tests)to http proxying can break webapi and leak capabilities (manifests as JSON decoding error in CLI tests)Attachment use-do-http-in-tahoe-mv.darcs.patch (16759 bytes) added
tahoe_mv.py: use do_http, not urllib.openurl, in order to avoid connecting to the webapi server via a proxy. refs #1253
Attachment test-1253.darcs.patch (19035 bytes) added
test_system.py: test for 'tahoe mv' with the http_proxy and HTTP_PROXY variables set. refs #1253
I reviewed the patches and they look good. We still need a source:NEWS entry for this ticket. Here, please review this patch that I'm about to attach that adds a NEWS entry.
Attachment news-1253.darcs.patch (16492 bytes) added
Reviewed the news patch. Looks good, but please make the changes to source:docs/configuration.rst and source:misc/simulators/hashbasedsig.py into separate patches.
In changeset:531443792e3334a7:
In changeset:01a53650510a9a4e:
In changeset:cb777ad14f12a249:
I just did a checkout of the darcs repo, and re-ran the tests in my environment that failed the last time. The tests passes now.
Fixed in changeset:01a53650510a9a4e, changeset:cb777ad14f12a249. Thank you!
There is now a test failure on zomp (Mac OS 10.6) which looks like it might be caused by these patches:
http://tahoe-lafs.org/buildbot/builders/Zooko%20zomp%20Mac-amd64%2010.6%20py2.6/builds/208/steps/test/logs/stdio
source:src/allmydata/scripts/tahoe_mv.py@4818#L31 is not
"
data = urllib.urlopen(from_url + "?t=json").read()
". That's what it wasbefore the fix.
Somehow the code being tested has the test patch changeset:01a53650510a9a4e, but not the fix patch changeset:cb777ad14f12a249.
Oh, it is testing "/Library/Python/2.6/site-packages/allmydata/scripts/tahoe_mv.py". Wrong! This looks like the issue that we fixed for the test-from-egg and test-from-prefixdir steps in #1137.
Anyway, this failure is not evidence of this ticket being unfixed, so I'm closing it and opening a new ticket for the wrong-code problem.
This (the testing-wrong-code problem) might be a duplicate of the remaining issue in #1246. Anyway, the new ticket for it is #1258.