Perl 6 - the future is here, just unevenly distributed

IRC log for #opentreeoflife, 2015-01-14

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:07 towodo joined #opentreeoflife
01:19 towodo joined #opentreeoflife
02:45 towodo joined #opentreeoflife
04:13 kcranstn joined #opentreeoflife
07:57 mtholder joined #opentreeoflife
12:18 mtholder joined #opentreeoflife
12:32 towodo joined #opentreeoflife
13:48 kcranstn joined #opentreeoflife
14:04 towodo joined #opentreeoflife
14:31 kcranstn jimallman - did the changes that fixed that CORS issue get pushed to production?
14:36 towodo joined #opentreeoflife
14:40 kcranstn towodo - we did a push to production the other day, right?
14:40 towodo yes
14:41 kcranstn I am still getting CORS erros
14:41 towodo ot14:log/messages
14:41 towodo you still doing private browsing?
14:41 kcranstn yes
14:42 kcranstn on chrome, I am getting github authentican errors
14:42 towodo i wonder if private browsing turns off CORS, could be an attack vector
14:42 towodo don’t know how private browsing mode really works
14:44 towodo hmm.
14:44 towodo what are the urls in question?
14:44 kcranstn tree.opentreeoflife.org/curator = does not load
14:45 towodo wp: “The private browsing feature called Incognito mode prevents the browser from permanently storing any history information or cookies from the websites visited”
14:45 kcranstn the links to the studies on https://tree.opentreeoflife.org/about/references = get “there are other studies with this DOI” error
14:47 towodo can’t reproduce… more details please.  i’m trying it in chromse incognito mode
14:47 towodo s/mse/me/
14:48 kcranstn Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.opentreeoflife.org/phylesystem/v1/study/pg_389?output_nexml2json=1.0.0&auth_token=ANONYMOUS. This can be fixed by moving the resource to the same domain or enabling CORS.
14:48 towodo I wonder if anyone else on this chat has ever used the ‘ed’ editor
14:48 towodo what did you click to get that?
14:48 kcranstn https://tree.opentreeoflife.org/curator/study/view/pg_389
14:48 towodo I just did that and didn’t get that message
14:49 towodo wonder if there’s another browser setting in your browser?…
14:49 towodo under command-, settings privacy  maybe
14:51 towodo and it’s not a problem when you leave incognito mode?
14:52 towodo are you using a proxy server?
14:52 kcranstn no
14:52 towodo did you try it outside of incognito? that would test whether it’s chrome settings
14:53 towodo vs. incognito itself
14:53 kcranstn those links work in chrome
14:53 towodo which browser should I be trying this in?
14:54 kcranstn firefox
14:54 towodo can’t reproduce…
14:55 towodo so, same question.  it works for you in non-private browsing?  but not private?
14:55 kcranstn I can’t figure out how to get it to work at all
14:56 towodo so it doesn’t work in a non-private window. but it works in chrome. let’s work with that
14:57 kcranstn which would be fine, except that I am having github authentication issues in chrome
14:58 towodo foo. well one thing at a time. your ff and my ff are different somehow. we need to figure out how  (or else debug directly in firebug, or something that I don’t know how to do)
14:59 towodo quick scan of ff preferences shows nothing obvious…
15:00 towodo obviously the solution is to get a new computer and reinstall the OS
15:00 kcranstn doing that in may
15:00 kcranstn ;)
15:01 towodo googling the error message
15:03 * jimallman is here now, with coffee
15:03 towodo first stackoverflow answer would suggest our app is totally broken (content type of our POSTs is json)
15:03 jimallman kcranstn: first thing, please clear browser cache and re-try
15:04 towodo what version of ff, kcranstn?
15:04 towodo ah! of course!
15:05 kcranstn 34.0.5
15:05 towodo hmm. same as mine
15:05 kcranstn all cache cleared
15:05 kcranstn same error
15:06 jimallman odd… i’ve tried all of these URLs in FF (34.0) and Chrome, no problems here
15:06 kcranstn just a sec
15:06 jimallman incl. logging in via GitHub… will try private in FF
15:06 towodo could it be some other browser detritus, like cookies?…
15:07 kcranstn installing a clean version of ff
15:07 jimallman private FF works here as well (viewing + editing that study, logging in and out on main study list)
15:08 towodo ouch
15:08 kcranstn although it remembers settings
15:08 towodo does it still have profiles?
15:08 kcranstn ?
15:08 towodo hold down command or option when starting up
15:09 jimallman pondering other possible causes… i’d rather not nuke just yet, unless kcranstn needs a fix Right Now
15:09 towodo i forget which
15:09 towodo sounds like she’s already started down the ‘nuke’ path
15:09 jimallman agreed
15:09 kcranstn well, we could switch over to debugging my chrome issues...
15:09 towodo http://spf13.com/post/managing-multiple-firefox-profiles-in-os-x
15:10 towodo ff is more important than chrome
15:10 towodo imo
15:11 * towodo testing
15:11 kcranstn ok, deleted my ff profile
15:11 towodo . /Applications/Firefox.app/Contents/MacOS/firefox-bin --profilemanager
15:12 kcranstn now getting untrusted connection page
15:12 jimallman any chance of an intermediate proxy (stale page) here? let’s try to force the issue by adding a query string, like so:  https://tree.opentreeoflife.org/curator?foo=bar
15:12 towodo i already asked that
15:12 kcranstn untrusted connection
15:13 jimallman on what URL? all on https://tree.opentreeoflife.org?
15:13 kcranstn yes
15:13 jimallman please click the padlock (or equivalent) in the address bar, let’s see what it doesn’t like about the cert
15:14 jimallman my ff and chrome both say it’s verified..
15:14 kcranstn mine says “not specified"
15:14 jimallman !
15:15 towodo wow, this is odd
15:15 jimallman kcranstn, you’re in https though?
15:15 towodo can we look at the cert fingerprint maybe?…
15:15 kcranstn yes, https
15:15 jimallman (sanity check) we should make sure you’re hitting the same IP, no messing with /etc/hosts etc.
15:15 towodo e9:89: etc.
15:16 jimallman $ ping tree.opentreeoflife.org
15:16 jimallman PING ot14.opentreeoflife.org (54.202.84.87): 56 data bytes
15:16 kcranstn same
15:16 kcranstn PING ot14.opentreeoflife.org (54.202.84.87): 56 data bytes
15:17 jimallman same here. it almost seems like a problem with the SSL cert chain…
15:17 towodo (I can’t tell what the certificate is certifying… but that’s a different question…)
15:17 jimallman (by which we verify domain ownership)
15:18 towodo (I think it’s verifying that we’re talking to the owner of the domain name)
15:18 jimallman occasionally different browsers will add a root cert, to recognize domains. deleting a cert is rare, put possible in the event of a security breach
15:19 jimallman checking now to see if the COMODO CA cert has been changed...
15:21 towodo I don’t see how to examine the certificate change… FF only lists names… I’ll try export
15:22 towodo that wasn’t very helpful
15:23 jimallman kcranstn: is the untrusted connection on both browsers? or just ff?
15:25 kcranstn only ff, not chrome or safari
15:26 jimallman thanks. and the GitHub auth failure (just in case it’s related) is in which browsers?
15:26 kcranstn chrome
15:26 jimallman thanks
15:26 kcranstn (don’t know about ff, because can’t get to that point)
15:27 jimallman bonus question: where are you working from (physically)? NESCent, or a home network?
15:28 kcranstn home, but at nescent yesterday with same issues
15:28 jimallman ah, good to know
15:28 kcranstn Internal error
15:28 kcranstn Ticket issued: curator/98.122.179.216.2015-01-14.15-28-19.89e77bef-12b4-4fc8-955c-0ea313f6607d
15:28 kcranstn admin disabled because unable to access password file
15:28 kcranstn (when trying to log in on chrome)
15:29 kcranstn after redirection back from github
15:29 jimallman right, that’s our standard config
15:29 jimallman will chase this in the terminal. meanwhile, here’s a possible clue to the “Not specified” message you see (it suggests mixed content on the page): http://kb.siteground.com/firefox_shows_verified_by_not_specified_notice_for_my_ssl/
15:30 towodo joined #opentreeoflife
15:33 jimallman looking at the error message, it’s a failure to open a URL on the server… on phylopic.org?!
15:34 jimallman chasing this now, obviously. apparently they (phylopic.org) use a self-signed cert, but this shouldn’t affect us (we proxy these calls through our own web2py to allow safe HTTPS for phylopics)…
15:41 jimallman no answers yet. i’m able to ping and wget from phylopic.org from ot14…
15:42 jimallman i’ll need to step away for a Dryad call shortly (kcranstn too, i believe)
15:42 kcranstn yup
15:49 towodo mtholder, have spent hours trying to understand the synthesis method and still don’t.  if I’m having troubles maybe it makes sense that the reviewers do too
15:49 towodo the pcb 2013 paper is too sketchy for my taste
16:03 mtholder hi towodo. sorry I just noticed this (i was muted). I think I understood it at one point (though it was a combo of having talked to SAS and reading the paper). do you have a specific question?
16:04 towodo given a vertex, how is the set of compatible LICAs found, algorithmically? is there a search?
16:04 towodo compatibility is defined, but there’s nothing saying how they’re found
16:05 mtholder I think that all nodes point to their parent, so that it does a search by looking at ancestors until there is a LICA. So yes a search.
16:06 mtholder not sure if one can say anything about the computational complexity...
16:06 towodo i think you can, it’s just hard
16:06 towodo yesterday it looked like beta^2 alpha^3 or something like that, now I don’t know
16:07 towodo so the search could potentially go all the way to the root?…
16:07 towodo well, *a* root, of the graph
16:07 mtholder It could (AFAIK)
16:07 mtholder yes. I don't know of a bound on the number of parents for a node.
16:07 mtholder depends on how many previous ties for LICAs
16:08 towodo # of trees I suppose
16:08 mtholder yes. that would be the worst case.
16:08 towodo ok, so the search is not linear, it’s tree-like (going away from the tips)…
16:08 mtholder (I think)
16:09 towodo I think I’ll look for the place in the code where it does this
16:11 towodo on any branch in the search do you stop when you find one? or do you keep going finding all of them?
16:11 towodo I’d think one would be enough
16:11 towodo yes, has to be just one.
16:12 mtholder I thought that it made an edge to every one. I'll need to look at the code too. I've gotta sign off. I'll check in later.
16:12 mtholder bye
16:12 towodo ok
16:34 towodo “It may be the case, with partially overlapping subtensions, that a node in a set of graph nodes and its parent are both LICAs of the same source tree node. In these cases, the LICA is mapped to the shallowest node. It is also possible that multiple LICAs will be found, in which case, each will be mapped.”
17:02 jimallman hm, that suggests all will be found (no stopping at the first LICA)
17:03 towodo shallowest node  sounds like you stop when you find one on any particular branch.  each will be mapped = at most one per parent.
17:03 towodo i think.
18:09 kcranstn joined #opentreeoflife
18:35 kcranstn joined #opentreeoflife
18:41 kcranstn towodo or jimallman - can someone do me a favour?
18:41 jimallman kcranstn: sure!
18:41 jimallman (i’m still chasing the urllib2 error, by the way)
18:41 kcranstn try this in python: import requests; r = requests.get(“https://tree.opentreeoflife.org/about/references”)
18:42 jimallman requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
18:43 jimallman not sure if requests needs special handling for https… will check now.
18:43 kcranstn ok, me too
18:43 kcranstn but, strangely, it now loads in firefox without the untrusted error
18:43 jimallman (and beware of curly quotes, had to clean those up first!)
18:43 jimallman odd
18:43 kcranstn reformmated by irc
18:43 * jimallman nods
18:44 jimallman fwiw, i haven’t had any problem loading this page in either FF or Chrome
18:45 jimallman simple example from requests docs works fine:  >>> r = requests.get('https://api.github.com/events')
18:46 jimallman looking now to see what cache of root certs are used to verify…
18:46 kcranstn github url also works for me
18:47 jimallman it’s possible (likely?) that requests is using a different collection of root certs vs. the browsers
18:48 jimallman hm, looks like this is “inherited” from the installed version of openssl:
18:49 jimallman >>> import ssl
18:49 jimallman >>> ssl.OPENSSL_VERSION
18:49 jimallman 'OpenSSL 1.0.1j 15 Oct 2014'
18:50 jimallman your test works if we explicitly DON’T verify:
18:50 jimallman >>> r = requests.get("https://tree.opentreeoflife.org/about/references", verify=False)
18:50 jimallman some background here: http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification
18:50 kcranstn yeah, got that working
18:52 jimallman so is it using a bad/old cert bundle? or do we have a not-quite-valid cert chain on tree.opentreeoflife.org? i suspect the former, but will keep digging
18:52 jimallman by “it”, i mean openssl and therefore requests
18:52 kcranstn dunno
18:53 mtholder joined #opentreeoflife
18:54 towodo how old is your mac, kcranstn?
18:54 kcranstn hmmm… 2012
18:54 towodo you might have to add a new root using keychain manager
18:54 towodo (guessing)
18:55 towodo i’ll look at our root CA’s cert in keychain access…
18:57 towodo two certs, one starting 2000, the other starting 2005… so that’s probably not it… do you see addtrust in the Keychain Access app?
18:57 towodo expiring 2019 and 2020
18:58 kcranstn I see one expiring 2020
18:58 towodo but not 2019… I wonder if that has any significance
18:59 towodo our cert is based on the 2000-2020 cert, so you have that
19:00 towodo so I don’t think your root cert set is a problem.
19:00 jimallman assuming python requests (openssl?) uses the same CA certs
19:01 towodo hmm.
19:01 towodo look at source code maybe?
19:01 kcranstn I can get around the requests problem
19:02 jimallman i’m finding discussion about an additional ‘certifi’ repo that was added to requests for licensing reasons. easiest possible fix is to update requests w/ pip or similar…
19:02 jimallman but more importantly, is this relevant to the real error on our site?
19:02 jimallman or more of an interesting red herring
19:03 kcranstn which real error? because I am no longer getting the ff cert error
19:03 kcranstn I am down to CORS errors on ff and github auth errors on chrome ;)
19:03 jimallman great! i’ve been chasing your Chrome error after GitHub login
19:03 towodo what’s your immediate goal, kc, to get your setup working, or to be a proxy for all the other people who might have problems like this?
19:04 jimallman i’m now dumping the attempted phylopic URL to console, so i can try to understand why it (occasionally) fails...
19:04 kcranstn hey, look, links in ff now working
19:04 kcranstn no more CORS errors
19:05 kcranstn I don’t udnerstand
19:05 kcranstn immediate goal? resubmission of manuscript
19:05 kcranstn which lead me to 1. looking at the website and 2. making a spreadsheet of the input studies so that we can collect some more metadata
19:06 towodo ok
19:06 kcranstn 2 lead me to grabbing content from the references page
19:06 kcranstn and getting SSL errors with requests
19:06 towodo so there were 3 problems, which might or might not be related: requests, ff CORS, and github auth.
19:07 towodo you have a workaround for requests.
19:07 jimallman joy! i’m having trouble reproducing any of these! seems like transient network problems…?!
19:07 towodo CORS has gone away.
19:07 kcranstn who knows
19:07 kcranstn magic!
19:07 towodo that leaves us with github auth.
19:07 jimallman kcranstn: please try to reproduce the GitHub login problem
19:07 jimallman now that i have a new clue to examine
19:08 kcranstn still getting the error with chrome
19:08 kcranstn Ticket issued: curator/98.122.179.216.2015-01-14.19-08-11.fae9d285-6919-4b4e-8e3e-ddb1d557a3d3
19:11 jimallman ah, this is different! URL redirect mismatch after OAuth login. this, i can chase (thanks)
19:11 kcranstn woot
19:11 jimallman i thought you were logging into the main webapp (tree viewer).. does this also fail?
19:12 jimallman logging out there is not easy but this will do it: 98.122.179.216.2015-01-14.19-08-11.fae9d285-6919-4b4e-8e3e-ddb1d557a3d3
19:13 jimallman SORRY, should have been this (logout URL):   https://tree.opentreeoflife.org/user/logout
19:13 jimallman never mind, i’ll focus on the curation app login
19:46 mtholder joined #opentreeoflife
19:47 jimallman kcranstn: this is bizarre. i can’t see how you get this error (and just in Chrome!?) and we do not. assuming we’re all connecting to the same server, logging in should use the same registered app on GitHub, and therefore the same OAuth redirect URL.
19:47 jimallman can you try to reproduce in FF, now that the other bugs have magically fixed themselves?
19:48 kcranstn can log in / log out without issue in ff
19:49 jimallman from the same URL?
19:49 jimallman (same as in Chrome, i mean)
19:52 jimallman does this work for you? (i’m guessing not):  https://tree.opentreeoflife.org/curator/user/login
19:53 kcranstn yes in ff, no in chrome
19:53 kcranstn Failed to load resource: the server responded with a status of 500 (INTERNAL SERVER ERROR)
19:55 jimallman thanks, same error again. hmmm.
20:17 jimallman kcranstn: it seems one possible problem would be if your Chrome was sending an empty (or incorrect) Host: header when trying to login… if you have a minute, i can walk you through a simple test for this.
20:18 kcranstn ok
20:19 jimallman in Chrome (incognito or otherwise, shouldn’t matter)… open dev tools and Network tab.
20:19 jimallman go ahead and log out of the curation app (click “Welcome” message at upper right, choose Log out from drop-down menu)
20:20 jimallman back in the Network tab, clear this list (click gray crossbar icon) then check “Preserve log”
20:20 jimallman now navigate to https://tree.opentreeoflife.org/curator/user/login (presumably this fails)
20:21 mtholder If I click on that in my IRC client (Konversation) I get:
20:21 mtholder NO, there were errors:
20:21 mtholder The certificate authority's certificate is invalid
20:21 mtholder The root certificate authority's certificate is not trusted for this purpose
20:21 mtholder The certificate cannot be verified for internal reasons
20:21 mtholder and "
20:21 mtholder The server failed the authenticity check (tree.opentreeoflife.org).
20:21 mtholder The certificate authority's certificate is invalid
20:21 mtholder The root certificate authority's certificate is not trusted for this purpose
20:22 mtholder The certificate cannot be verified for internal reasons
20:22 mtholder "
20:22 kcranstn ok, what do you want to know from the network tab
20:22 jimallman (mtholder, i’ll come back to this in a sec)
20:22 jimallman in the Network tab, look for one or more “login” requests at the top of the list. for each, click once to see the Headers on the right, and check the request’s Host header value
20:22 kcranstn (kcranston is glad to see she isn’t the only one getting cert errors)
20:23 jimallman should be ‘tree.opentreeoflife.org’ for all login requests
20:23 mtholder (but I can get it to load by typing it in to a browser status bar)
20:24 kcranstn yes, that is correct
20:24 jimallman argh.
20:24 jimallman here’s the smoking gun (perhaps) that i see in ssl_error.log:
20:24 jimallman [error] Hostname 54.202.84.87 provided via SNI and hostname *.opentreeoflife.org provided via HTTP are different
20:25 kcranstn does this link work for people: https://tree.opentreeoflife.org/curator/study/view/curator/study/view/ot_156
20:25 kcranstn oops
20:25 kcranstn forget that
20:25 kcranstn I see the problem now that I’ve pasted it on
20:25 kcranstn in
20:26 jimallman funny enough, that works!
20:26 jimallman study doesn’t load, never mind
20:26 kcranstn but the error is about duplicate DOIs
20:26 kcranstn which is strange
20:26 jimallman (i’m reading up on SNI now… to see what it’s supposed to do)
20:27 jimallman duplicate DOIs? oh, that’s just the default text on the page (should be hidden by JS)… i’ll make a ticket to hide this stuff by default, to avoid this confusion!
20:28 towodo hmm, maybe a reverse DNS problem?… shouldn’t depend on that, but maybe it does
20:30 towodo ;; ANSWER SECTION:
20:30 towodo 87.84.202.54.in-addr.arpa. 300INPTRec2-54-202-84-87.us-west-2.compute.amazonaws.com.
20:30 jimallman SNI seems to be a way to overcome the limitation of just one secure hostname per IP.
20:31 * jimallman made the ticket mentioned above (misleading “duplicate DOI” text): https://github.com/OpenTreeOfLife/opentree/issues/546
20:31 kcranstn thanks!
20:32 towodo it’s stupid to care about IP addresses and hostnames. TSL gives you end to end security, doesn’t matter what happens in between
20:32 towodo TLS
20:33 jimallman apparently it’s a way to share a single IP across multiple domains, using headers to figure out which domain (and cert?) to use
20:34 jimallman RFC: https://tools.ietf.org/html/rfc3546#section-3.1
20:36 towodo $ hostname -A
20:36 towodo ip-10-20-129-174.us-west-2.compute.internal
20:37 jimallman seems funky, but note that other users (and kcranstn’s FF) aren’t hitting this error… i thought it was perhaps bogus headers from her version of Chrome? or maybe this error message (see ssl_error.log above) is a red herring.
20:38 towodo kcranstn, what OS are you running?
20:38 jimallman it looks like SNI is designed to fall back to older behavior (default cert, matching wildcard to hostname)
20:39 towodo OS version that is
20:39 jimallman according to https://tools.ietf.org/html/rfc3546#section-3.1, Chrome support on Mac is OS-version dependent : “Google Chrome (Vista or higher. XP on Chrome 6 or newer.[9] OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)”
20:39 kcranstn os x 10.10.1 Yosemite
20:39 jimallman (sorry, that was pasted from Wikipedia, not the RFC)  http://en.wikipedia.org/wiki/Server_Name_Indication
20:39 kcranstn Chrome 39.0.2171.95
20:39 towodo I’m running os x 10.9.5. wonder if that’s the difference
20:40 jimallman i’m also on 10.10.1, no problems here
20:40 jimallman Chrome Version 39.0.2171.95
20:40 jimallman (drat, it’s updating now)
20:42 towodo yosemite = 10.10
20:42 jimallman yes, kcranstn and i have the exact same versions of chrome and osx. but i can’t reproduce the problem.
20:43 kcranstn mine also updated as soon as I looked at the version ;)
20:44 towodo heisenberg has been busy.
20:44 kcranstn http://xkcd.com/1473/
20:45 jimallman :)
20:46 jimallman i’m trying to get a closer look at the OAuth error (https://developer.github.com/v3/oauth/#redirect-uri-mismatch2), but i don’t have access to the registered app in the GitHub OpenTreeOfLife org
20:47 jimallman if someone can take a look, i assume it’s called ‘tree.opentreeoflife.org’.. would like to know the client ID (sanity check) and the redirect_uri specified for this
20:47 towodo looking
20:49 towodo curation  or explorer?
20:49 towodo curation
20:49 towodo client id d02feed213fd327e3005
20:50 towodo callback url http://tree.opentreeoflife.org/curator/user/login
20:50 jimallman would you mind getting the same values for the curation app?
20:50 jimallman (most want to compare scheme, etc of redirect uri)
20:50 jimallman mostly
20:50 towodo that was for ‘curation tool’
20:51 jimallman right you are. the explorer app, then
21:01 mtholder I've got my Yosemite machine near me if you need me to try anything.
21:03 jimallman towodo: here are the (exactly) matching values from curator/private/config
21:03 jimallman github_client_id = d02feed213fd327e3005
21:04 jimallman github_redirect_uri = http://tree.opentreeoflife.org/curator/user/login
21:04 jimallman i have no idea what’s going wrong :-/
21:04 jimallman mtholder: in Chrome, please log out of the curator, then try https://tree.opentreeoflife.org/curator/user/login
21:05 * jimallman is reviewing your previous error msg from Konversation...
21:07 mtholder that redirected me to the curator study list (my browser remembers my password, so I did not get a prompt to authenticate)...
21:10 jimallman ok, thanks. i get the same behavior, while kcranstn is unable to authenticate. i’m going to log out of GitHub and try again..
21:11 jimallman that works for me as well. drat.
21:11 jimallman (meaning i returned to the curation app, logged out, logged back in, and was cleanly passed through the GH login and oauth)
21:15 mtholder yes. I logged out. cleared my cache and got back in.
21:16 mtholder (unrelated the study list fetching is slow...)
21:16 mtholder [presumably unrelated, that is...]
21:19 jimallman i’m tinkering with openssl, and it doesn’t seem to like one of our certs: “openssl s_client -connect tree.opentreeoflife.org:443 -debug”
21:19 jimallman “Verify return code: 21 (unable to verify the first certificate)”
21:21 jimallman but this doesn’t seem quite relevant to kcranstn’s oauth bug.
21:26 mtholder that is very similar to the complaint that I got when I clicked on the link in Konversation (mentioned above).
21:27 mtholder Is there a cURL command that we can have kcranston try to see if it is something about her network?
21:27 mtholder nm. i guess it works on ff for her...
21:28 jimallman right! but it’s possible that different browsers (and openssl itself, and python requests) are using different CA cert bundles or whatever.
21:29 jimallman very frustrating. this thread suggests we might need to directly install a root (or intermediate) cert, in case some clients can’t download them on-the-fly from their origin sources: http://stackoverflow.com/questions/7587851/openssl-unable-to-verify-the-first-certificate-for-experian-url
21:31 mtholder that does look like a good candidate for what we are running into...
21:31 kcranstn let’s not spend *too* much time on this if I am the only one
21:31 kcranstn on only one browser
21:32 kcranstn which is not my primary browser
21:32 jimallman i hear you, kcranstn. it just makes me itch!
21:32 kcranstn I know
21:35 * jimallman is backing away slowly. time for a walk, i think.

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary