| 00:02.38 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 00:07.15 | Sicelo | jonwil: we were just talking about you :) |
| 00:07.21 | jonwil | hi |
| 00:07.32 | jonwil | reads logs |
| 00:08.34 | Sicelo | see last two posts in cssu devel thread .. a-gps problem that can be attributed to maemosec-certman packages |
| 00:08.35 | jonwil | ok, what exactly is the problem? |
| 00:09.13 | jonwil | So the problem is what exactly? |
| 00:09.44 | DocScrutinizer05 | maybe supl format changed and results in modem GPS engine hanging now? |
| 00:09.46 | jonwil | that the new set of root CAs doesn't work properly for AGPS? |
| 00:09.51 | Sicelo | a-gps does not work with maemo-security-certman (0.2.7) |
| 00:09.56 | Sicelo | yes |
| 00:10.14 | jonwil | which version is the last one that works? |
| 00:10.14 | Sicelo | i downgraded to 0.2.3 and i get instant fix |
| 00:10.36 | Sicelo | 0.2.4 gets good fix too .. but fails cmcli verification |
| 00:11.03 | Sicelo | 0.2.3 has good fix, and cmcli verifes supl.nokia.com OK |
| 00:16.10 | DocScrutinizer05 | sorry now that sounds like bogus heissenbug, aka unrelated |
| 00:18.31 | DocScrutinizer05 | you're aware BB5 probably stores ephem/alm internally too? there been even a tiny tool to clear that stuff in modem, back when. sorry can't spot it anymore, I *think* it was an attachment by our Nokia FOSS ambassador to tmo |
| 00:20.36 | *** join/#maemo RzR (~RzR@82.236.136.171) |
| 00:20.38 | Sicelo | DocScrutinizer05: when it works - Socket to supl.nokia.com opened, fd=13, verify_res=0 |
| 00:20.59 | Sicelo | when it doesn't, Socket to supl.nokia.com opened, fd=12, verify_res=19 |
| 00:22.01 | DocScrutinizer05 | meh, gimme tcpdump/whireshark! |
| 00:22.43 | *** join/#maemo dafox (~dafox@ip3e8380c8.speed.planet.nl) |
| 00:22.48 | DocScrutinizer05 | even tshark |
| 00:24.38 | DocScrutinizer05 | anyway, you clarified that now, so it looks less unrelated |
| 00:24.56 | jonwil | Could it be that the " |
| 00:25.11 | jonwil | the " Change the order of VerSign root certificates, so "newer" certificate to appear first. Fixes supl server not working." change in maemo-security-certman is related |
| 00:25.16 | jonwil | That change was made in 0.2.3 |
| 00:25.33 | jonwil | Its possible my total reimport of the certificates in later versions caused the order to change again somehow |
| 00:25.45 | Sicelo | most likely, yes |
| 00:25.49 | jonwil | I have no real way to verify that though |
| 00:25.49 | DocScrutinizer05 | yes |
| 00:26.36 | jonwil | speaking of which, I need to update maemo-security-certman to the latest set of mozilla root certificates, haven't done it for a while :) |
| 00:26.44 | Sicelo | :) |
| 00:26.55 | DocScrutinizer05 | of course >>Fixes supl server not working."<< is related ;-D |
| 00:30.24 | DocScrutinizer05 | has absulute faith in Ivo fixing that |
| 00:31.33 | DocScrutinizer05 | I think cert management is your daily warmup, freemangordon. Right? ;-) |
| 00:32.21 | DocScrutinizer05 | ~trump |
| 00:32.26 | infobot | well, trump is NULL |
| 00:32.27 | DocScrutinizer05 | wow |
| 00:32.46 | DocScrutinizer05 | ~factinfo trump |
| 00:32.46 | infobot | trump -- created by fungus <fungus@delta.myfungus.net> at Tue Aug 9 22:29:09 2016 (179 days); it has been requested 5 times, last by DocScrutinizer05, 20s ago. |
| 00:39.50 | DocScrutinizer05 | https://www.youtube.com/watch?v=zP7RbhfcV7o |
| 00:50.26 | *** join/#maemo cyphase_eviltwin (~cyphase@unaffiliated/cyphase) |
| 00:50.37 | jonwil | ok, the root CA store is updated |
| 00:51.33 | DocScrutinizer05 | please keep in mind that it took quite some investigation and WTF-moments to make a _working_ cert store back when patching it |
| 00:52.54 | DocScrutinizer05 | I think there are some undocumented non-intuitive (aka flaw) sequence/sortorder issues with the cert store |
| 00:52.59 | DocScrutinizer05 | iirc |
| 00:53.53 | DocScrutinizer05 | took the one who meddled with it (fmg?) quite a bit of trial&error to 'fix a perfectly correct cert store' so it works with some broken apps/libs in maemo |
| 00:54.10 | jonwil | in that case we should modify the maemosec-certman tools and stuff to correctly order the certs rather than try and manually patch the store every time. |
| 00:54.39 | DocScrutinizer05 | I think if that option had existed, it would have been taken back when |
| 00:55.17 | jonwil | anyhow, let me see what I get now with maemo-security-certman 0.2.8 on my phone when I try to access the various supl servers out there... |
| 00:56.29 | DocScrutinizer05 | when a closed process fails on your absolutely corect data, based on mystery criteria (moon phase and md5sum of all words with a prime number of chars) then you can't fix much |
| 00:56.54 | DocScrutinizer05 | note that certs are not only relevant for supl |
| 00:57.05 | DocScrutinizer05 | you have quite a few apps to check |
| 00:57.33 | DocScrutinizer05 | I suggest you read the historical tickets and tmo threads regarding that stuff |
| 00:57.55 | DocScrutinizer05 | or wait for fmg (and/or pali?) to chime in |
| 00:59.01 | DocScrutinizer05 | I really can't recall details |
| 00:59.15 | DocScrutinizer05 | only kbnow it been a PITA |
| 00:59.16 | jonwil | ok, so location-test-gui can definatly see satellites but it cant get a lock |
| 00:59.46 | jonwil | I wish it displayed more info about the actual connections to the supl server |
| 01:00.06 | DocScrutinizer05 | hmm, such a statement is pretty generic. Did you make sure the signal of sats is OK? |
| 01:00.14 | jonwil | wireshark logs wont help since you cant wireshark an SSL connection unless you can peek into memory and get the keys |
| 01:00.19 | DocScrutinizer05 | did you make sure you have correct system time? |
| 01:00.27 | DocScrutinizer05 | did you reset BB5 GPS? |
| 01:00.57 | DocScrutinizer05 | (SSL) right :-/ |
| 01:01.53 | jonwil | system time is comming from network so it should be correct |
| 01:02.17 | jonwil | it says ept, eph, epv, epd, eps and epc are all NAN |
| 01:02.40 | jonwil | I am connected to both 3G and WiFi here |
| 01:02.52 | jonwil | as for resetting bb5 GPS I dont know how |
| 01:03.13 | DocScrutinizer05 | 'not getting a fix' might be everything from cloudy sky to hickup in hardware that needs power down & battery out for 60s, to wrong system time, to Trolland Dump deciding not to share GPS to Europe anymore |
| 01:03.35 | jonwil | If there was a problem with GPS here in Australia I would have heard of it |
| 01:03.49 | jonwil | About to go outside and see if that makes a difference :) |
| 01:04.29 | DocScrutinizer05 | ohmy, you expected a GPS fix indoors? :-o |
| 01:04.43 | jonwil | I have gotten such fixes before in this place |
| 01:05.03 | DocScrutinizer05 | prolly not, most like was no first fix and maybe no GPS fix at all |
| 01:05.07 | DocScrutinizer05 | see |
| 01:05.11 | jonwil | maybe |
| 01:05.16 | DocScrutinizer05 | ~gsm-ahps |
| 01:05.20 | DocScrutinizer05 | ~gsm-agps |
| 01:05.20 | infobot | i guess rrlp is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP |
| 01:05.42 | jonwil | ok, let me try this outside and see what I get. |
| 01:05.59 | DocScrutinizer05 | U-TDOA is more accurate and faster than any (A)GPS |
| 01:06.42 | DocScrutinizer05 | and works indoors, as long as you got a network signal |
| 01:06.57 | DocScrutinizer05 | ~u-tdoa |
| 01:06.57 | infobot | well, u-tdoa is http://en.wikipedia.org/wiki/U-TDOA |
| 01:07.21 | DocScrutinizer05 | standard on pretty much all 3G nowadays |
| 01:11.14 | DocScrutinizer05 | note that RRLP is network layer and thus totally opaque to userland |
| 01:12.01 | jonwil | going outside didn't get me a lock even though I could see the sats |
| 01:12.20 | DocScrutinizer05 | did they have signal? |
| 01:12.40 | jonwil | location-test-gui didn't show me anything to suggest they did one way or the other |
| 01:12.57 | jonwil | It said there were lots of sats visible but none in use |
| 01:13.04 | jonwil | as high as 5 visible |
| 01:13.09 | DocScrutinizer05 | "sats in sight" only means what almanach tells you are supposed to be able to see under optimal conditions |
| 01:14.29 | DocScrutinizer05 | it suggests you received somewhat working almanach data |
| 01:14.48 | DocScrutinizer05 | *if* the sats shown as "visible" are actually correct |
| 01:14.57 | jonwil | No idea then why its not working if I select either "GNSS" or "AGNSS" in location-test-gui |
| 01:15.28 | DocScrutinizer05 | maybe because it has a totally off idea where you are? |
| 01:15.45 | jonwil | ok, sounds like a reset of bb5 might help |
| 01:16.15 | jonwil | should I try this bb5 data reset thing or should I just try a power down and reboot? |
| 01:16.21 | DocScrutinizer05 | to guess what sats are visible (and thus search for them) the algo needs your position first. To some +-few 100s of miles |
| 01:16.23 | jonwil | i.e. power down for a minute then reboot? |
| 01:16.53 | DocScrutinizer05 | try both. Did you find that reset thing? where? |
| 01:16.58 | jonwil | I didn't find the reset thing |
| 01:17.11 | jonwil | powered down my phone now, will wait a minute or two then power up again |
| 01:17.25 | DocScrutinizer05 | remove battery |
| 01:17.28 | jonwil | I did |
| 01:17.36 | jonwil | if I get the "enter date/time" screen then I will know its reset the bb5 I guess |
| 01:17.43 | DocScrutinizer05 | so modem definitely doesn't store shit in RTC or cmos storage |
| 01:19.35 | jonwil | ok, that should be long enough, lets try it now |
| 01:19.51 | jonwil | see if it resets any stuff the bb5 might be confused about |
| 01:20.37 | jonwil | ok, I got welcome screen so that means things got reset |
| 01:23.55 | jonwil | although that didn't help |
| 01:24.11 | jonwil | I strongly suspect its a certificate problem talking to the SUPL server |
| 01:26.09 | jonwil | cmcli says "verification failed, self signed certificate" |
| 01:36.48 | jonwil | downgrading maemosec-certman-common-ca to the version with the fix in it didn't help either |
| 01:36.50 | jonwil | still no lock |
| 01:37.00 | jonwil | Nothing I do seems to get a GPS lock on my N900 |
| 01:39.25 | DocScrutinizer05 | even without any connectivity, GPS should get a fix after 15min the latest, as long as there's a strong enough sat signal |
| 01:40.52 | DocScrutinizer05 | actually should be faster since every sat sends its own orbit data faster than the complete almanac/ephemeral |
| 01:41.44 | DocScrutinizer05 | but you need a iirc 30dB higher signal than needed to *keep* a fix |
| 01:42.33 | DocScrutinizer05 | and correct system time and at least country you're in will prolly also help a lot |
| 01:43.07 | DocScrutinizer05 | system time is easily obtained from SAT data. Location not that easily |
| 01:43.31 | DocScrutinizer05 | the better your initial guess of location, the faster TTFF |
| 01:43.35 | DocScrutinizer05 | basically |
| 01:44.01 | DocScrutinizer05 | and that's partially what A in AGPS is all about |
| 01:44.38 | jonwil | ok so the only explanations I have are bogus data being held somewhere (e.g. bb5), that I cant see any sats even when outside (for some reason, there are clouds but they are light clouds and not the heavy stuff that gets in the away) or that the n900 is doing something wrong somewhere (e.g. wrong library version being a problem). |
| 01:44.48 | DocScrutinizer05 | when you get bogus assistance data, I'm pretty sure you're better off with none at all |
| 01:45.22 | jonwil | This is after trying it for ages with "GNSS" selected in location-test-gui and disconnected from wifi/cellular data to make sure its not trying to download anything |
| 01:45.31 | jonwil | My gut says bogus stored data is the likely answer |
| 01:45.54 | DocScrutinizer05 | you got a SIM? |
| 01:46.04 | jonwil | Yep, I have a sim in the phone |
| 01:46.08 | jonwil | and it returns the correct country code |
| 01:46.10 | DocScrutinizer05 | see RRLP!!! |
| 01:46.14 | jonwil | and I am connected to 3G voice |
| 01:47.02 | jonwil | "CWP" seems to have given me a lock |
| 01:47.22 | jonwil | although I think that's just cell tower positioning and nothing to do with GPS |
| 01:47.51 | DocScrutinizer05 | yes, and cell towers send "supl" |
| 01:48.11 | jonwil | I think I need to find that tool to remove whatever crap bb5 is holding |
| 01:48.28 | DocScrutinizer05 | you need to remove SIM first of all |
| 01:48.50 | DocScrutinizer05 | or at least go airplane mode |
| 01:49.11 | DocScrutinizer05 | though I'm still not sure if it *receives* RRLP nevertheless |
| 01:49.19 | jonwil | gone to offline mode |
| 01:50.43 | jonwil | offline mode plus GNSS in location-test-gui should mean it uses 100% no cellmo works-like-standalone-GPS offline mode to get a lock |
| 01:50.59 | jonwil | with nothing taken from the cellmo or networks of any kind |
| 01:52.52 | jonwil | Looks like finding that tool to erase stored GPS data in bb5 would help |
| 01:57.56 | *** join/#maemo luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 02:01.02 | DocScrutinizer05 | https://bugs.maemo.org/show_bug.cgi?id=7026#c35 |
| 02:01.04 | povbot | 04Bug 7026: Can't get a GPS lock with several satellites at view |
| 02:01.43 | DocScrutinizer05 | "should mean" HAHA |
| 02:02.13 | DocScrutinizer05 | please read about RRLP |
| 02:02.23 | DocScrutinizer05 | ~gsm-agps |
| 02:02.24 | infobot | from memory, rrlp is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP |
| 02:02.56 | DocScrutinizer05 | BB5 prolly has not even a means to NOT use RRLP when it's available |
| 02:03.23 | DocScrutinizer05 | RRLP is 911-related and completely outside of user control |
| 02:04.02 | DocScrutinizer05 | and obviously not even the Nokia maemo gurus knew about that when they made maemo5 |
| 02:04.22 | DocScrutinizer05 | BB5 is largely opaque to them as well |
| 02:06.04 | Juesto | o_O |
| 02:07.01 | DocScrutinizer05 | please understand that CWP and SUPL etc is basically only userland, with a defined API to send the SUPL data to modem aka GPS chip. But that modem-GPS-chip has its own "SUPL" (called RRLP) and maemo devels didn't know |
| 02:09.07 | DocScrutinizer05 | FFS! |
| 02:09.22 | DocScrutinizer05 | ~literal gsm-agps |
| 02:09.22 | infobot | "gsm-agps" is "<reply>see rrlp" |
| 02:09.31 | DocScrutinizer05 | ~literal rrlp |
| 02:09.32 | infobot | "rrlp" is "the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP" |
| 02:11.26 | DocScrutinizer05 | infobot: no, rrlp is <reply>RRLP is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://osmocom.org/projects/security/wiki/RRLP |
| 02:11.26 | infobot | DocScrutinizer05: okay |
| 02:12.32 | DocScrutinizer05 | >>In all known phones, RRLP operation is completely invisible to the user of the phone<< |
| 02:13.38 | DocScrutinizer05 | >> Contrary to the user-plane based SUPL, RRLP works entirely in the signaling plane of the network. As such, the RRLP protocol level is not accessible to user applications on a phone.<< |
| 02:14.42 | DocScrutinizer05 | >>Most RRLP capable phones will request GPS assistance data from the network.<< |
| 02:17.50 | DocScrutinizer05 | bottom line: when your cellular carrier sends bogus "assistance data" via RRLP, there's nothing you could do about it and your GPS will mist likely fail. You _probably_ could cure this by removing the SIM all together or by at least switching to airplane mode |
| 02:18.55 | DocScrutinizer05 | heads out coughing a bit more, and probing own Core temperature |
| 02:26.00 | DocScrutinizer05 | http://maemo.cloud-7.de/maemo5/usr/local/sbin/clear-gps-cache but also see http://maemo.cloud-7.de/maemo5/usr/sbin/cmt-reset (NFC what that does) |
| 02:26.31 | jonwil | I tried clear-gps-cache but that didn't help |
| 02:27.01 | jonwil | I do see SNR values for a bunch of satellites (as many as 6 when I stand outside away from buildings) |
| 02:27.21 | jonwil | Values ranging from the high 20s to 40+ |
| 02:27.52 | jonwil | In terms of the weather its very hot and very humid with light clouds in the sky, maybe the humidity or heat is causing interference |
| 02:29.04 | jonwil | ok, wtf, I got a lock!!! |
| 02:29.07 | jonwil | on AGNSS |
| 02:29.48 | jonwil | and now of course I get a lock again straight away because my phone hasn't moved |
| 02:33.11 | jonwil | so its definatly not broken GPS hardware or bogus data stored by bb5 |
| 02:33.48 | jonwil | now I need to go somewhere away and see if GPS still gets a lock or something. |
| 02:33.57 | jonwil | and how long it takes |
| 02:34.38 | jonwil | not sure how far away I should go to be far enough away from current pos to test that |
| 02:39.33 | DocScrutinizer05 | 30+ is fine, should result in a fix after some time |
| 02:40.30 | DocScrutinizer05 | and seems it did :-) |
| 02:43.25 | DocScrutinizer05 | glad it finally worked for you |
| 02:43.53 | DocScrutinizer05 | did you have SIM/network enabled? |
| 02:49.29 | *** join/#maemo pagurus (~user@p4FDC3AFC.dip0.t-ipconnect.de) |
| 02:52.27 | jonwil | yes I did at that point |
| 02:53.06 | jonwil | I suspect the way to be sure whats going on is to head a couple km away from where I am now and try it again and see what happens. |
| 02:53.24 | jonwil | If I move a couple km away it will invalidate any old position data GPS chip holds |
| 02:53.33 | jonwil | maybe run the clear-gps-cache tool as well |
| 02:53.45 | jonwil | and reboot the phone to clear anything held in bb5 ram |
| 03:18.52 | *** join/#maemo spiiroin (~spiiroin@178-55-107-97.bb.dnainternet.fi) |
| 04:04.42 | jonwil | My guess is that with the cert issues preventing connectivity to the supl server it takes many minutes to get a lock because it has to download full data from sats over slow link |
| 04:05.52 | DocScrutinizer05 | yes |
| 04:07.13 | DocScrutinizer05 | sprt of, though I learned a *good* GPS driver (like we finally had in Neo Freerunner) can download the relevant data from sats it actually receives in less than 60s and then get a first fix |
| 04:08.07 | DocScrutinizer05 | aiui each sat sends its own orbit parameters and the current time once every 40s or somesuch |
| 04:09.34 | DocScrutinizer05 | as long as the GPS chip has enough correlators to receive all possible sats concurrently, it should get a first fix in pretty short time |
| 04:10.17 | DocScrutinizer05 | I almost forgot the details, GPS is complex and I last time looked into it several years ago |
| 04:12.00 | DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html recommended |
| 04:14.11 | DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gps.html#SVData |
| 04:15.40 | DocScrutinizer05 | >>The GPS Navigation Message consists of time-tagged data bits marking the time of transmission of each subframe at the time they are transmitted by the SV. A data bit frame consists of 1500 bits divided into five 300-bit subframes. A data frame is transmitted every thirty seconds. Three six-second subframes contain orbital and clock data. SV Clock corrections are sent in subframe one and precise SV orbital data sets (ephemeris data |
| 04:15.41 | DocScrutinizer05 | parameters) for the transmitting SV are sent in subframes two and three<< |
| 04:21.11 | DocScrutinizer05 | full almanac however takes some 12 or 15min of glitch free reception for complete download |
| 04:21.48 | DocScrutinizer05 | "full" as in "has all data of all sats for the next week or so" |
| 04:23.02 | DocScrutinizer05 | aah >>Subframes four and five are used to transmit different pages of system data. An entire set of twenty-five frames (125 subframes) makes up the complete Navigation Message that is sent over a 12.5 minute period.<< |
| 04:24.02 | DocScrutinizer05 | http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif |
| 04:28.24 | DocScrutinizer05 | >>Signal acquisition time on receiver start-up can be significantly aided by the availability of current almanacs<< |
| 04:30.17 | DocScrutinizer05 | only useful when you already have a rough idea of where you are and what's the time, otherwise you don't know which sats are visible and on which doppler shift, even with absolutely complete and up-to-date almanac# |
| 04:31.08 | DocScrutinizer05 | rough idea here means like +-500km and +´1min I guess |
| 04:31.58 | *** join/#maemo geaaru (~geaaru@host67-212-dynamic.5-87-r.retail.telecomitalia.it) |
| 04:32.36 | DocScrutinizer05 | nice: http://www.colorado.edu/geography/gcraft/notes/gps/gif/bitsanim.gif |
| 04:32.44 | DocScrutinizer05 | corellator |
| 04:38.20 | DocScrutinizer05 | >>Receiver position is computed from the SV positions, the measured pseudo-ranges (corrected for SV clock offsets, ionospheric delays, and relativistic effects), ****and a receiver position estimate (usually the last computed receiver position)****.<< |
| 04:41.58 | DocScrutinizer05 | the complete almanac is 37500 bit in size |
| 04:42.14 | DocScrutinizer05 | so ~5kB |
| 04:43.01 | DocScrutinizer05 | it describes the orbits of all SV (aka SAT) and stays valid until reality differs from clean math |
| 04:45.22 | DocScrutinizer05 | the ephem are obviously per SV and describe its current position, so this is all a GPS chip needs when actually receiving the SV. Those are sent every 30s |
| 04:51.07 | DocScrutinizer05 | so with 4 corellators locked to 4 sats (which are sufficiently distant from each other) you should get a first fix in 30s. Locking to a sat depends on using the right code and right doppler frequency shift, and given both are correct it shouldn't take longer than a second or 2 maybe. so with an unlimited number of corellators so you can search for all possibe sats/codes at all possible doppler shifts, you always get TTFF <40s |
| 04:51.46 | DocScrutinizer05 | unless no sufficiently good sat signals available |
| 04:53.37 | DocScrutinizer05 | almanac helps to pick the right code (aka SV) and doppler correction, from estimation of point in time and space |
| 04:55.16 | DocScrutinizer05 | when your almanac is bogus or your time or location guess is totally off, and the GPS chip has no smart handling of that, you might find the chip trying forever to receive SVs that don't exist where amd when you are |
| 04:57.51 | DocScrutinizer05 | it's like staring west on a ship heading north, to find that island, and you never will see it since you're a tad further to the west than you thought you were and the island shows up in the east of your position |
| 04:59.54 | DocScrutinizer05 | you'll recover from that as late as seeing another random island west of you, maybe days later |
| 05:01.40 | DocScrutinizer05 | in case of GPS it never will recover since it not only looks for any island but for a very particular one, and it ignores resp doesn't even see any others that come by |
| 05:02.41 | DocScrutinizer05 | that's why I think in certain situations disabling AGPS **and RRLP** might actually yield better results |
| 05:03.28 | jonwil | So it looks like we need to find out just what certs supl.nokia.com actually needs and why it needs old/obsolete certs that Mozilla no longer ships or whatever (or if there is something else going on) |
| 05:03.51 | jonwil | And then if we really need old certs we need to add back just the one cert needed |
| 05:04.27 | DocScrutinizer05 | yep |
| 05:05.20 | DocScrutinizer05 | I *guess* the CA of those Nokia SUPL certs is expired or revoked, and Nokia didn't bother to get a new cert |
| 05:06.50 | jonwil | I dont know enough about certificates or SSL to know how to do this |
| 05:06.52 | DocScrutinizer05 | or the cert uses an encryption or whatever that has been deprecated since |
| 05:07.49 | jonwil | I think from something I saw is one cert that uses MD2 signing (which is obsolete and |
| 05:07.54 | jonwil | obsolete and easily broken |
| 05:11.08 | jonwil | well the certificate for supl.nokia.com is current and valid from Feb 18 2016 to May 15 2017 so its definitely not some old obsolete job |
| 05:27.28 | jonwil | Need someone who knows more about SSL (or maybe someone who knows more about VeriSign certificates in particular) |
| 05:37.21 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 06:26.35 | jonwil | Finding someone that knows about SSL certs is going to be hard though... |
| 06:46.20 | *** join/#maemo Michael_a320 (d31f1b25@gateway/web/freenode/ip.211.31.27.37) |
| 07:49.51 | KotCzarny | regarding gps fix, i've just tested on my n900, cellmo: on, wifi: off, method: gnss |
| 07:50.15 | KotCzarny | it took ~10 minutes, all sats are in 19-31dB range |
| 07:50.34 | KotCzarny | started with a few (1-3) now seeing 8 |
| 07:51.01 | KotCzarny | accuracy 40-140m |
| 07:51.56 | KotCzarny | stock fw |
| 08:16.04 | Vajb | but does it differ from place to place? |
| 08:16.28 | KotCzarny | that's a question for me? |
| 08:16.32 | Vajb | i mean are those satellites spread evenly on sky |
| 08:16.54 | Vajb | KotCzarny: for no one especially |
| 08:17.13 | Vajb | more of a rethoric q :) |
| 08:17.59 | KotCzarny | yeah, they should be all over the globe |
| 08:18.19 | KotCzarny | but in geostationary positions, ie. not moving tiny bit relative to earth |
| 08:19.20 | KotCzarny | what differs is visibility (clouds, buildings) and noise/interferences (e-m noise) |
| 08:22.10 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 08:27.34 | bencoh | KotCzarny: not geostationary no |
| 08:32.53 | KotCzarny | no? |
| 08:34.05 | bencoh | nope |
| 08:35.06 | KotCzarny | fun |
| 08:35.16 | KotCzarny | how do they calculate their own position? |
| 08:35.30 | KotCzarny | or is it done from earth observatories? |
| 08:43.38 | bencoh | known/corrected from earth I suppose |
| 08:44.05 | bencoh | or adjusted according to star visibility/positions, or most likely both |
| 08:44.11 | KotCzarny | perfect way to confuse receivers in case of war |
| 08:44.12 | KotCzarny | :) |
| 08:54.08 | *** join/#maemo Kabouik (~quassel@65.76.93.92.rev.sfr.net) |
| 09:00.43 | freemangordon | jonwil: the naming order of certificates matter |
| 09:01.01 | freemangordon | verisign cert used by supl is in the logs ^^^ |
| 09:01.24 | freemangordon | jonwil: 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 |
| 09:01.44 | freemangordon | there are two of those, one with -1 appended to the name |
| 09:02.11 | freemangordon | and - you don;t need sats at all to get fix when using AGPS |
| 09:02.24 | jonwil | What I have found is that with the latest mozilla cert store, openssl returns X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN |
| 09:02.32 | freemangordon | :nod: |
| 09:03.06 | freemangordon | could you dump cert chain? |
| 09:03.12 | freemangordon | and pastebin it |
| 09:03.26 | freemangordon | openssl s_client has an option to dup cert chain and certs used |
| 09:03.30 | freemangordon | *dump |
| 09:04.04 | freemangordon | jonwil: ah, it seems ilew found the missing one |
| 09:04.19 | freemangordon | just add it back to cert store and we should be fine |
| 09:04.58 | jonwil | anyone know how to get GDB to print the address at which the binary you are debugging is actually loaded at? |
| 09:05.33 | *** join/#maemo Kabouik_ (~quassel@65.76.93.92.rev.sfr.net) |
| 09:05.44 | freemangordon | jonwil: info modules? |
| 09:05.48 | freemangordon | no, wait |
| 09:06.09 | freemangordon | it is "info something", but I cant remember that exactly |
| 09:06.45 | freemangordon | jonwil: try with "info shared" |
| 09:08.03 | jonwil | found it, "info files" gives me the address I need |
| 09:08.28 | freemangordon | ok |
| 09:08.34 | freemangordon | good to know |
| 09:08.48 | Maxdamantus | Presumably you could just look at /proc/*/maps |
| 09:09.01 | Maxdamantus | suspects `info files` pretty much does that. |
| 09:09.06 | freemangordon | jonwil: however, may i have a cert chain dump? |
| 09:09.24 | jonwil | how do I get a cert chain dump? |
| 09:10.02 | freemangordon | jonwil: add "-showcerts" to openssl s_client command |
| 09:11.17 | jonwil | Will do that soon and see what I get on the N900 |
| 09:12.35 | jonwil | I ran nss tstclient.exe locally earlier (built NSS on my windows box) and the chain that I got from there was http://pastebin.com/RZ0z259R |
| 09:13.03 | jonwil | So that's what supl.nokia.com servers to tstclient.exe on my w7 box |
| 09:13.33 | jonwil | The last one in the chain implies that its signed with MD2 (very strange) |
| 09:17.07 | jonwil | I suspect whats going on is that one of the 3 VeriSign certs in the chain has been replaced with something newer that has the same public key and name and that somehow openssl (which is what location-proxy uses to do its SSL) is using the old version in the certificate chain rather than the newer version in the root CA store. |
| 09:17.25 | jonwil | Going to run the s_client test now |
| 09:17.36 | freemangordon | jonwil: yes, this is what happens |
| 09:17.51 | freemangordon | but, s_client test will pass on n900 |
| 09:18.01 | freemangordon | iirc |
| 09:18.18 | freemangordon | as openssl is smart enough to use the correct certificate |
| 09:19.51 | jonwil | http://pastebin.com/TeE3jF3m |
| 09:19.58 | jonwil | That;s the openssl certificate chain dump |
| 09:20.19 | freemangordon | mhm |
| 09:20.29 | freemangordon | but, cmcli will fail; |
| 09:21.28 | jonwil | I wonder if its poossible to use IDA to do remote debugging on a N900 via gdb or something |
| 09:22.19 | freemangordon | yes, but you need to set sysroot |
| 09:22.40 | freemangordon | which means to copy rootfs to a local dir on your pc |
| 09:22.57 | bencoh | and gdbserver on n900 I guess? |
| 09:23.00 | freemangordon | yes |
| 09:23.20 | freemangordon | jonwil: I guess you can use ScratchBox directories for that |
| 09:26.11 | jonwil | ok, so I established the IDA remote debugger doesn't run on the N900 so that's definitely out |
| 09:26.29 | freemangordon | hmm? |
| 09:26.39 | freemangordon | do you run gdbserver on n900? |
| 09:26.51 | jonwil | I dont think I have a gdbserver binary |
| 09:26.56 | jonwil | wait I do |
| 09:27.00 | freemangordon | well, no way then |
| 09:27.03 | jonwil | not sure how to run it though |
| 09:27.20 | freemangordon | install gdbserver, and run it with --attach parameter |
| 09:27.35 | jonwil | what do I pass for the parameters to --attach? |
| 09:27.37 | freemangordon | "gdbserver --attach $pid :1234" |
| 09:27.53 | freemangordon | 1234 is the port it listens on |
| 09:28.03 | freemangordon | change it as you wish |
| 09:29.09 | freemangordon | jonwil: also, if the process you want to debug is started via maemo-launcher, make sure to attach to the pid with larger id, from the bothe you have for the same binary |
| 09:38.54 | jonwil | ok, well that didn't tell me much other than that openssl is returning that X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN |
| 09:39.04 | jonwil | i.e. it confirmed what I already knew about how the function worked |
| 09:40.06 | freemangordon | jonwil: which function? |
| 09:40.20 | jonwil | the function I was studying was sub_CF90 |
| 09:40.36 | freemangordon | which binary ? :) |
| 09:40.54 | jonwil | location-proxy |
| 09:41.23 | freemangordon | tries to find where his lication-proxy IDA db is |
| 09:42.06 | jonwil | It looks like if SSL_get_verify_result returns non-zero, it prints the "host: %s not verified, result: %ld" error |
| 09:42.09 | jonwil | via g_log |
| 09:42.22 | freemangordon | yes, it returns 19 (self-signed cert) |
| 09:42.22 | jonwil | and it passes 2 as the first parameter to las_socket_open_response_ntf |
| 09:42.35 | freemangordon | it is visible in the syslog |
| 09:42.37 | jonwil | otherwise it skips that error and passes 0 for the parameter to las_socket_open_response_ntf |
| 09:43.20 | freemangordon | jonwil: I suspect it is SSL_connect that fails |
| 09:43.56 | freemangordon | "Socket to %s opened, fd=%d, verify_res=%ld" |
| 09:44.19 | jonwil | ok, so I am playing some more with the nss tools on Windows. |
| 09:44.33 | freemangordon | how's that going to help? |
| 09:44.35 | jonwil | which btw have the same set of root CAs built into them as my n900 |
| 09:44.44 | jonwil | I am playing more to see just what the chain looks like |
| 09:44.47 | jonwil | and how it validates |
| 09:45.19 | jonwil | using vftserv.exe from those tools I get 4 certificate files (cert.000, cert.001, cert.002, cert.003) which match the 4 certs in our chain |
| 09:45.28 | freemangordon | mhm |
| 09:45.43 | jonwil | If I then run vfychain.exe on those files and pass it just cert.000, it says the chain is bad |
| 09:45.54 | jonwil | If I pass it cert.000 and cert.001, it says "chain is good" |
| 09:46.05 | freemangordon | jonwil: did you pass -CApath to openssl s_client command? |
| 09:46.07 | jonwil | same if I pass it 000, 001, 002 |
| 09:46.13 | jonwil | yes I did pass -CApath |
| 09:46.18 | freemangordon | and it fails? |
| 09:46.52 | jonwil | Ok so we have 4 certificates in this chain |
| 09:46.53 | jonwil | supl.nokia.com |
| 09:46.54 | freemangordon | sorry |
| 09:46.59 | jonwil | Symantec Class 3 Secure Server CA - G4 |
| 09:47.13 | jonwil | VeriSign Class 3 Public Primary Certification Authority - G5 |
| 09:47.25 | jonwil | Class 3 Public Primary Certification Authority |
| 09:48.38 | jonwil | I think that there is a new version of the cert named "VeriSign Class 3 Public Primary Certification Authority - G5" in the current root CA store |
| 09:48.46 | freemangordon | yes, there is |
| 09:49.30 | freemangordon | it seems ssl tries to verify only against the first certificate in the store |
| 09:49.42 | freemangordon | and when it is the old one, it fails |
| 09:52.57 | jonwil | I think what's happening is that in the case of this particular chain OpenSSL will only verify the last CA in the chain. |
| 09:54.22 | jonwil | i.e. it sees the last cert in the chain (the one with issuer "OU=Class 3 Public Primary Certification Authority,O="VeriSign, Inc.",C=US" and subject "OU=Class 3 Public Primary Certification Authority,O="VeriSign, Inc.",C=US" |
| 09:54.34 | jonwil | then it says "do I have a match for that cert in my root CA store" |
| 09:54.55 | jonwil | since the answer is no, it says "it must be self signed then" and returns the error |
| 09:55.05 | freemangordon | but there is a match |
| 09:55.09 | freemangordon | ok, there is a cert |
| 09:55.36 | jonwil | there is no match for the last cert in the chain in the root CA store as of the latest Mozilla certificate set. |
| 09:56.55 | freemangordon | why it is removed? |
| 09:57.09 | freemangordon | or it has never been there |
| 10:01.48 | jonwil | ok, I am looking at maemo-security-certman now |
| 10:03.31 | freemangordon | jonwil: if we miss a certificate, how's that related to maemo-security-certman? |
| 10:03.48 | jonwil | maemo-security-certman contains the root CA store |
| 10:03.57 | jonwil | hence why its where I need to look |
| 10:07.24 | jonwil | ok, so I am looking at the last Nokia commit to this repo and I see 2 different certificates with the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 value |
| 10:09.46 | jonwil | They have identical values for most of the fields (including issuer and subject) |
| 10:09.58 | jonwil | The differences are a difference in the not-after date |
| 10:10.05 | jonwil | and a difference in the serial number |
| 10:10.10 | jonwil | and a difference in the signature |
| 10:10.16 | jonwil | One uses md2WithRSAEncryption |
| 10:10.23 | jonwil | the other uses sha1WithRSAEncryption |
| 10:11.01 | jonwil | The one named 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem in this particular repo revision is the md2 version |
| 10:11.10 | jonwil | and the one named 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem is the sha1 version |
| 10:11.27 | freemangordon | jonwil: you're reinventing the wheel :) https://github.com/community-ssu/maemo-security-certman/commit/2cbd96e89d7529e1ce25801824fb76f39b05b836 |
| 10:11.45 | jonwil | I know about that commit, I am just chasing up the entire history of the repo |
| 10:12.28 | freemangordon | jonwil: https://talk.maemo.org/showpost.php?p=1370304&postcount=122 |
| 10:13.21 | freemangordon | jonwil: it might be a bug in c_rehash actually |
| 10:14.08 | jonwil | there are 2 different issues here, the first has to do with the order in which certificates appear when there are multiple versions of the same cert |
| 10:14.19 | jonwil | That one is what the commit you linked to is aiming to fix |
| 10:14.24 | jonwil | or rather it fixed |
| 10:14.39 | freemangordon | :nod: |
| 10:14.42 | jonwil | The right fix is to properly fix maemo-security-certman so it orders them correctly |
| 10:15.01 | freemangordon | mhm |
| 10:16.04 | freemangordon | jonwil: so, we should add code on top of https://github.com/community-ssu/maemo-security-certman/commit/5b66292b9d705f9e9613490aafc074bfeef6a622 right? |
| 10:16.49 | freemangordon | jonwil: also, what means "orders them correctly" do we know the rule? |
| 10:17.33 | freemangordon | the newest should become last? or what? |
| 10:19.50 | jonwil | what I am trying to figure out now is how it determines whether to use the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem or the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem file |
| 10:19.59 | freemangordon | mhm |
| 10:20.23 | freemangordon | but isn't it ssl that makes the decision, not certman? |
| 10:21.58 | *** join/#maemo dafox (~dafox@ip3e8380c8.speed.planet.nl) |
| 10:23.18 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 10:23.23 | freemangordon | jonwil: do you have an idea *who* decides on which cert file to use? |
| 10:26.37 | jonwil | Either the code in maemosec_storage.cpp decides when it builds the file list or the file list contains both and therefore both get passed to SSL_CTX_set_cert_store from maemosec_certman_collect |
| 10:26.55 | jonwil | maemosec_certman_collect just returns the contents of the storage as set up by the code in maemosec_storage.cpp |
| 10:29.32 | freemangordon | jonwil: ok, it seems I am not very helpful with my question :). Will leave you digging in it as I have to run anyways |
| 10:29.37 | freemangordon | *questions |
| 10:29.49 | freemangordon | good luck, bbl |
| 10:37.23 | *** join/#maemo xorly (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 10:40.30 | jonwil | Ok so as of now Mozilla doesn't ship either version of the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 certificate |
| 10:50.22 | Juesto | hmm |
| 10:50.54 | Juesto | too old? |
| 10:54.27 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 10:58.18 | KotCzarny | jonwil: update cert package and let sicelo test it? |
| 11:02.02 | Juesto | tbh, some things should be pushed straight away |
| 11:02.10 | Juesto | like updated system certificates, etc |
| 11:14.27 | Juesto | minor updates that are done so the OS is up to date |
| 11:14.36 | Juesto | things that do not affect stability |
| 11:14.41 | Juesto | or usability |
| 11:28.32 | *** join/#maemo mp107 (~mp107@PC-109-125-232-42.wegrow.domtel.com.pl) |
| 11:31.45 | Sicelo | Juesto: certs do affect stability though :-) |
| 11:32.43 | Juesto | oh really? |
| 11:33.05 | Sicelo | or usabiltiy then |
| 11:33.15 | Juesto | nah |
| 11:33.27 | Juesto | by usability i mean user experience |
| 11:34.03 | Sicelo | it wasn't nice to need Maps, and have to wait 10 mins for GNSS fix, as A-GNSS was broken by 'new' certs |
| 11:34.22 | Juesto | Oh :/ |
| 11:34.29 | Juesto | well something like a timezone update |
| 11:34.32 | Juesto | isnt a big deal either |
| 11:34.41 | Juesto | but i guess certificates is a breaker |
| 11:35.08 | Juesto | sorry to hear |
| 11:36.38 | Sicelo | maemo's devs are doing super good job though :-) |
| 11:38.29 | Juesto | heh |
| 11:39.04 | KotCzarny | you can be a dev too! |
| 11:39.21 | Juesto | who knows |
| 11:39.35 | Juesto | Depends on your talent/skill |
| 11:40.04 | Sicelo | my skills is talking too much :p |
| 11:40.46 | Juesto | you would serve well for reporting then |
| 11:40.47 | Juesto | hehe |
| 11:49.58 | KotCzarny | yeah, maemo needs more testers |
| 11:55.08 | Juesto | i wish i have a n900 |
| 11:55.10 | Juesto | really |
| 11:58.52 | Sicelo | buy usb broken one (that has not been fixed before) |
| 11:59.05 | Sicelo | then fix yourself |
| 12:01.18 | Juesto | hmm, perhaps i'll just take from oksana :) |
| 12:01.29 | Juesto | (yes she lets me) |
| 12:01.36 | Juesto | AFAIK |
| 12:45.36 | *** join/#maemo mp107 (~mp107@user-94-254-225-27.play-internet.pl) |
| 12:49.58 | *** join/#maemo xorly (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 13:06.17 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 13:27.51 | freemangordon | well, the package that broke certs in is cssu-dev, so everything is as it should be - we devs screw something in unstable repo, users test and report, we fix it |
| 13:28.28 | freemangordon | jonwil: if neither certs are in mozilla store, then we should add it by hand |
| 13:28.33 | freemangordon | I see no other option |
| 13:29.08 | freemangordon | maybe we should not use mozilla, but debian |
| 13:32.07 | KotCzarny | fmg: or make a script that will repackage what's needed |
| 13:32.47 | freemangordon | mhm |
| 13:33.31 | KotCzarny | i would trust mozilla more than debian to be honest too |
| 13:34.28 | freemangordon | KotCzarny: hmm, actually all the certs I have on my Ubuntu are from mozilla :) |
| 13:36.17 | freemangordon | so yeah, mozilla it is |
| 13:39.55 | Juesto | hehe |
| 14:40.16 | jonwil | I am testing a fix now |
| 14:40.47 | jonwil | involving a 2-byte patch to location-proxy and installing the certificate into a separate private certificate store. |
| 14:41.48 | jonwil | the fix works :) |
| 14:44.05 | jonwil | http://talk.maemo.org/showthread.php?p=1522859&highlight=00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61#post1522859 |
| 14:48.09 | freemangordon | jonwil: I am not sure I like the idea of binary patching the location proxy |
| 14:48.24 | jonwil | we binary patch libsms.so for the cell broadcast stuff already |
| 14:48.26 | jonwil | thats in CSSU |
| 14:48.50 | freemangordon | that doesn;t mean I like it :). however, see: |
| 14:49.59 | freemangordon | what about including those 2 certs until I RE location-proxy. anyway I will do it sooner or later, because of the fremantle porting. it is some 30k binary I guess I'll need a month or less to finish |
| 14:50.31 | freemangordon | those 2 certs been there forever a month more will not do that much harm |
| 14:50.40 | freemangordon | if any |
| 14:51.20 | freemangordon | jonwil: ^^^? |
| 14:51.35 | jonwil | except the whole point of keeping the root CA store up to date is to not ship insecure broken certs using insecure broken cryptography |
| 14:51.53 | freemangordon | how's that related? |
| 14:52.27 | freemangordon | that we'll use those 2 presumably broken certs for a month or so? |
| 14:53.47 | freemangordon | jonwil: also, I don;t get it why lokation-proxy fails while openssl does not |
| 14:53.57 | freemangordon | *location-proxy |
| 14:54.27 | freemangordon | what is this special thing it does that makes it fail? |
| 14:55.29 | freemangordon | jonwil: any idea? ^^^ |
| 14:55.33 | jonwil | no idea |
| 14:56.13 | freemangordon | because this is the actual problem imo. I tested openssl tu supl.nokia.com on my Ubuntu and there is no problem |
| 14:56.18 | freemangordon | *to |
| 14:56.22 | *** join/#maemo M4rtinK (~M4rtinK@ip-78-45-144-165.net.upcbroadband.cz) |
| 14:58.42 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 15:15.55 | jonwil | The reason openssl works is because at some point you had the relavent root CA (the old insecure one) in your CA store but now you dont anymore.. Its no longer in /etc/secure/s/certman.common-ca and wont be used by anything that uses libmaemosec-certman0 to get certificates (including NSS and location-proxy) but will still be found by openssl when you pass -CApath in the verify command |
| 15:16.23 | jonwil | since openssl doesn't read certman.common-ca, it just uses whatever is in the passed in capath |
| 15:16.52 | freemangordon | jonwil: read it again - it doesn't fail *on my Ubuntu* |
| 15:17.00 | jonwil | Your ubuntu must also be shippnig the cert |
| 15:17.06 | jonwil | for some reason |
| 15:17.14 | freemangordon | it ships the mozilla stuff |
| 15:17.35 | jonwil | what does the certificate chain look like on your ubuntu install? |
| 15:17.42 | freemangordon | just a second |
| 15:17.47 | jonwil | and what openssl version is it? |
| 15:18.25 | jonwil | Its possible that you have a newer version of something somewhere that properly says "hey, dont use this old root CA in the certificate chain, use the newer correct replacement in the root CA store" |
| 15:20.09 | freemangordon | jonwil: well, lets identify it and port it to maemo then |
| 15:20.17 | freemangordon | jonwil: http://pastebin.com/EZcxfFjp |
| 15:21.55 | jonwil | What's the contents of /etc/ssl/certs/? |
| 15:22.06 | freemangordon | it is huge |
| 15:22.13 | freemangordon | lots of files there |
| 15:22.31 | freemangordon | do you want me to pastebin it? |
| 15:22.51 | jonwil | yes please do |
| 15:22.54 | freemangordon | ok |
| 15:24.04 | freemangordon | jonwil: http://pastebin.com/b3WHxKk3 |
| 15:26.09 | jonwil | Can you pastebin Verisign_Class_3_Public_Primary_Certification_Authority.pem? |
| 15:26.24 | jonwil | I bet it (or Verisign_Class_3_Public_Primary_Certification_Authority_2.pem) will be the certificate from the chain |
| 15:26.38 | jonwil | the self-signed one |
| 15:27.14 | freemangordon | it is a link to /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt so I'll pastebin the .crt file |
| 15:27.23 | jonwil | ok |
| 15:27.56 | freemangordon | jonwil: http://pastebin.com/acjQ3EgK |
| 15:28.44 | jonwil | yep, just as I suspected, its exctly the root CA in question |
| 15:28.54 | jonwil | the one with the outdated crypto |
| 15:29.01 | jonwil | the one in the chain from supl.nokia.com\ |
| 15:29.13 | jonwil | and no I dont know why its on your Ubuntu system in that place |
| 15:29.25 | jonwil | you would have to ask the maintainer of whatever package claims ownership of the relavent files... |
| 15:29.42 | freemangordon | well, if it is good enough for my Ubuntu, it is good enough for my Maemo as well :) |
| 15:30.07 | freemangordon | I don;t really see what is the problem with that certificate, besides weak hash |
| 15:30.40 | *** join/#maemo cyphase (~cyphase@unaffiliated/cyphase) |
| 15:31.07 | freemangordon | Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> :) |
| 15:31.20 | jonwil | Its the fact that its using a very weak 1024 bit RSA key, something that all the browser vendors and other sane people have stopped shipping for ages now |
| 15:32.07 | freemangordon | 1024 bit RSA is weak? O.o |
| 15:32.30 | freemangordon | jonwil: who told you that? |
| 15:35.30 | *** join/#maemo louisdk (~louisdk@5.103.130.65) |
| 15:36.43 | KotCzarny | https://supportforums.cisco.com/discussion/11320131/https-ssl-certificate-signed-using-weak-hashing-algorithm |
| 15:37.02 | jonwil | The CAB forum (which sets rules that CAs need to follow if they want to be in the major browsers) has declared that all CAs must use RSA keys of at least 2048 bits if they want to remain in the browsers |
| 15:37.11 | jonwil | And there was a big effort to get all the old certificates retired |
| 15:37.25 | jonwil | including the VeriSign one at the heart of this discussion |
| 15:37.32 | KotCzarny | fmg, see the description there and it has more reading too if you want to pursue further details |
| 15:38.15 | jonwil | That discussion means nothing in the context of this discussion |
| 15:38.35 | KotCzarny | it describes why weak hashing algos are bad |
| 15:38.37 | jonwil | There is nothing wrong with the hashing algorithm of the certificate in question since its a root CA |
| 15:38.48 | KotCzarny | and why it's bad to have such CAs |
| 15:38.59 | freemangordon | see, as part of my job I am dealing with PCI-DSS stuff on a regular basis, so I have a clue |
| 15:39.01 | jonwil | in this case we are interested in why 1024-bit RSA is bad |
| 15:39.15 | freemangordon | yes, exactly |
| 15:39.20 | jonwil | and why shipping a cert in the root CA store that has a 1024 bit public key is bad |
| 15:39.38 | freemangordon | jonwil: but, this is when it omes to new certificates |
| 15:39.42 | jonwil | If all the major CAs AND all the major browser vendors all say that a 1024 bit RSA key is too weak, I am inclined to trust them |
| 15:39.42 | freemangordon | *comes |
| 15:39.48 | jonwil | All of them got rid of 1024 bit certificates |
| 15:40.27 | jonwil | and no 1024 bit certificates (old, new or otherwise) will be treated as trusted by any of the major browsers in whatever version it is |
| 15:40.36 | freemangordon | jonwil: ever thought that it is all about the money? |
| 15:41.04 | freemangordon | there is no evidence so far that 1024 bit RSA was ever broken |
| 15:41.32 | KotCzarny | ..yet |
| 15:41.57 | freemangordon | yes, yet |
| 15:42.53 | freemangordon | jonwil: and I bet all the stable releases of all the major distribution have the certificate in question included |
| 15:43.03 | freemangordon | *distributions |
| 15:43.48 | freemangordon | so, lets not overengineer Maemo and let simply include that(those) certificate(s) |
| 15:46.48 | DocScrutinizer05 | NSA will crack them easily ;-) |
| 15:46.57 | freemangordon | from the CAs POV it looks like - dammit, we've issued root certs that expire in more than 10 years from now...hmm...how to fill the budget for the next couple of years? aah, BINGO, lets tell them that all the 1024 bit certs have to be replaced because in a couple of years quantum computers most probably will be powerful enough to factor 1024bit RSA. |
| 15:47.20 | KotCzarny | :) |
| 15:47.42 | DocScrutinizer05 | or that, yes |
| 15:47.42 | KotCzarny | fmg, what if they are crackable by invering in big farm? |
| 15:47.53 | freemangordon | DocScrutinizer05: I doubt breaking RSA can be kept secret for long |
| 15:47.58 | freemangordon | KotCzarny: no way |
| 15:48.08 | KotCzarny | in similar way there are 'sploits running on black market |
| 15:48.30 | KotCzarny | so maybe there is such black farm or more than one? |
| 15:48.38 | freemangordon | KotCzarny: afaik, anything > 512 is not feasible |
| 15:48.49 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 15:48.51 | freemangordon | or maybe anything > 768 |
| 15:49.14 | DocScrutinizer05 | 1024 sounds *very* long, didn't they crack 56bit or sth, with distributed computing, in years? |
| 15:49.15 | freemangordon | you know, exponential |
| 15:50.00 | DocScrutinizer05 | yeah |
| 15:50.18 | jonwil | Even the long term stable versions of browsers like firefox have removed the 1024 bit certificates. |
| 15:50.57 | DocScrutinizer05 | but how do *we* care about that? |
| 15:51.04 | DocScrutinizer05 | for supl |
| 15:51.16 | freemangordon | DocScrutinizer05: the same certs are used |
| 15:51.29 | freemangordon | for supl and www |
| 15:51.38 | DocScrutinizer05 | yes, and aiui Nokia didn't update their supl cert |
| 15:51.42 | jonwil | my point is that there IS a way to store the certificate so that it can be used by location-proxy but not by anything else |
| 15:51.47 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 15:51.56 | DocScrutinizer05 | so should we, simply don't touch it |
| 15:52.07 | freemangordon | jonwil: doesn;t make sense, that cert anyway expires in 3 months |
| 15:52.14 | DocScrutinizer05 | how900: makes sense |
| 15:52.30 | DocScrutinizer05 | haha, ok then not |
| 15:53.00 | DocScrutinizer05 | damn, jonwil^^^ - sorry how900 |
| 15:54.02 | DocScrutinizer05 | let's take bets what gonna gappen to Nokia SUPL in 3 months? |
| 15:54.14 | DocScrutinizer05 | happen* |
| 15:54.32 | KotCzarny | o.o |
| 15:54.33 | *** join/#maemo Eezer (~Flare@apn-37-7-184-58.dynamic.gprs.plus.pl) |
| 15:54.41 | freemangordon | Not After : May 15 23:59:59 2017 GMT |
| 15:54.43 | freemangordon | :) |
| 15:54.43 | DocScrutinizer05 | you rather find a way to convince proxy(?) to use an expired cert |
| 15:54.58 | KotCzarny | oh so much less traffic |
| 15:55.02 | freemangordon | thay'll fix it, all symbian devices depend on that as well |
| 15:55.03 | KotCzarny | winwin |
| 15:55.20 | DocScrutinizer05 | ooh |
| 15:55.27 | DocScrutinizer05 | I don't know |
| 15:55.30 | KotCzarny | but how would they redistribute it? |
| 15:55.39 | freemangordon | KotCzarny: distribute?!? |
| 15:55.44 | freemangordon | this is server cert |
| 15:55.46 | DocScrutinizer05 | they might not be interested in sybian anymore |
| 15:56.10 | KotCzarny | arent ca certs part of os? |
| 15:56.19 | freemangordon | only root ones |
| 15:56.19 | DocScrutinizer05 | and maybe symbian doest't care about cert expiry? |
| 15:56.24 | freemangordon | no way |
| 15:56.45 | freemangordon | they were in the same shit as maemo when the old cert expired |
| 15:57.04 | freemangordon | the current one is "Not Before: Feb 18 00:00:00 2016 GMT" |
| 15:57.30 | jonwil | The root problem is that supl.nokia.com sends an obsolete VeriSign root certificate as part of its certificate chain |
| 15:57.38 | jonwil | why they send that obsolete certificate I haven't a clue |
| 15:57.57 | freemangordon | jonwil: could you find the mozilla bug for removing that certificate? |
| 15:58.29 | KotCzarny | fmg, that would be probably part of the remove 1024 certs |
| 15:59.09 | jonwil | https://bugzilla.mozilla.org/show_bug.cgi?id=986005 is the bug where the root certificate in question was removed |
| 15:59.11 | povbot | 04Bug 986005: was not found. |
| 15:59.17 | jonwil | or where the decision to remove it was made anyway |
| 15:59.53 | jonwil | it ultimately got removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1021967 |
| 15:59.54 | povbot | 04Bug 1021967: was not found. |
| 16:01.32 | DocScrutinizer05 | ((<jonwil> why they send that obsolete certificate I haven't a clue)) you _really_ need to guess on _why_ here? |
| 16:02.20 | DocScrutinizer05 | simply same reason why maemo keys expired and thus locked nokia out to update them |
| 16:02.41 | DocScrutinizer05 | nokia NEVER got cert stuff right |
| 16:02.41 | freemangordon | because they use some symantec intermediate which has that verisign cert in its chain |
| 16:04.02 | freemangordon | anyway, IMO we should just include those 2 until 15th of May comes and see what certificate, if any will be used after |
| 16:04.17 | DocScrutinizer05 | exactly |
| 16:05.29 | freemangordon | in the meanwhile I will be hopefully ready with location-proxy RE, so we'll be able to use whatever cert store needed, without compromising the browser security |
| 16:05.32 | freemangordon | jonwil: ^^^ |
| 16:05.38 | freemangordon | what do you think |
| 16:06.28 | DocScrutinizer05 | or we use jonwil's 2byte patch until you're ready then ;-) |
| 16:06.40 | DocScrutinizer05 | in 3 months |
| 16:06.45 | freemangordon | this is too hackish to my taste |
| 16:07.08 | DocScrutinizer05 | oh, I love that when we have no source |
| 16:07.20 | DocScrutinizer05 | did it in mce and it vanished a 4 times now |
| 16:07.30 | *** join/#maemo at1as (~at1as@24-231-230-53.static.trcy.mi.charter.com) |
| 16:10.05 | bencoh | REed location-proxy would be great anyway |
| 16:16.53 | jonwil | I think I see whats going on |
| 16:17.12 | jonwil | We have the certificate for supl.nokia.com |
| 16:17.33 | jonwil | the parent of that is the Symantec Trust Network certificate |
| 16:18.17 | freemangordon | yes |
| 16:18.29 | jonwil | then there exist 2 possible parents for that one |
| 16:18.36 | freemangordon | and it is signed by verisugn cert |
| 16:18.37 | jonwil | The first one is what is in the current Mozilla cert set |
| 16:18.55 | jonwil | That first one is itself a root CA |
| 16:19.02 | jonwil | and trusted by Mozilla at this point |
| 16:19.33 | jonwil | The second parent for the Symantec cert has identical keys and things but is NOT a root CA |
| 16:19.57 | DocScrutinizer05 | oh? |
| 16:20.19 | jonwil | Its the third certificate in the chain that supl.nokia.com returns |
| 16:20.26 | jonwil | That one chains up to the old "Class 3 Public Primary Certification Authority" |
| 16:22.01 | jonwil | My guess is that there are devices out there talking to supl.nokia.com that were shipped with the "Class 3 Public Primary Certification Authority" (issued 1996) in their root CA stores but NOT the newer issued-2006 "VeriSign Class 3 Public Primary Certification Authority - G5" root certificate |
| 16:22.36 | jonwil | So Nokia has to make supl.nokia.com return a certificate chain that those old devices will trust |
| 16:22.41 | DocScrutinizer05 | of course, yes. sounds 100% plausible to me |
| 16:22.45 | freemangordon | makes sense |
| 16:22.51 | jonwil | which means it needs the special "VeriSign Class 3 Public Primary Certification Authority - G5" certificate that isn't a root certificate itself |
| 16:23.58 | KotCzarny | i wonder why bother with ssl at that point |
| 16:24.00 | DocScrutinizer05 | in the end it's the maintainer of the cert cache who decides what's a trusted root cert |
| 16:24.10 | jonwil | The fact that both "VeriSign Class 3 Public Primary Certification Authority - G5" certificates (the one that chains up to the older root CA and the one that itself is a root CA) have identical start dates supports this hypothesis |
| 16:24.44 | *** join/#maemo clopez (~tau@neutrino.es) |
| 16:24.57 | freemangordon | jonwil: what will happen if we leave only the new cert in the store? |
| 16:25.18 | freemangordon | aren't both old and new 1024 bit? |
| 16:25.24 | jonwil | nope |
| 16:25.32 | freemangordon | ah |
| 16:25.34 | DocScrutinizer05 | the new isn't used by the old SUPL? |
| 16:25.46 | jonwil | We have a certificate for supl.nokia.com with a 2048 bit key |
| 16:25.52 | jonwil | We have the |
| 16:26.03 | jonwil | the Symantec Trust Network cert with a 2048 bit key |
| 16:26.18 | freemangordon | so we should remove 1024bit simatec? |
| 16:26.26 | freemangordon | *symantec |
| 16:26.38 | freemangordon | or, what shall be done? |
| 16:26.39 | jonwil | We have both versions of the VeriSign Class 3 Public Primary Certification Authority - G5 cert with an identical 2048 bit key |
| 16:26.59 | jonwil | Then we have the Class 3 Public Primary Certification Authority with the 1024 bit key |
| 16:27.10 | jonwil | The certificates currently in maemo-security-certman repo are all fine |
| 16:27.16 | jonwil | Its what we should be shipping at this point |
| 16:27.48 | freemangordon | maybe we should just reorder them, so the stronger cert to be used? |
| 16:28.11 | freemangordon | the same what I did before? |
| 16:28.11 | jonwil | no |
| 16:28.23 | freemangordon | I am lost :) |
| 16:28.38 | DocScrutinizer05 | "we have" isn't relevant. cert-c has a attached crypto-signature by owner of cert-B. Cert-B then has a signature made by cert-ALPA. And Cert-ALPHA has no / selfsigned signature and is in cert store of browsers as trusted root cert |
| 16:28.55 | jonwil | yeah |
| 16:29.38 | jonwil | The one you re-ordered before was the "Class 3 Public Primary Certification Authority" and neither version of that cert exists anymore in Mozilla trust store or any VeriSign "these are the root certificates we want people to actually ship" official list |
| 16:29.52 | freemangordon | ah, I see |
| 16:29.53 | jonwil | i.e. VeriSign has said "do not ship that cert going forward" |
| 16:29.59 | DocScrutinizer05 | the links are bottom-up by the attached signatures which point to the parent cert |
| 16:30.22 | jonwil | Hence my suggestion to put that one cert that we need into the private certificate store just for location-proxy |
| 16:30.48 | jonwil | actually, I just thought of a possible fix that doesn't involve patching location-proxy |
| 16:30.50 | jonwil | Let me try something |
| 16:30.56 | DocScrutinizer05 | I never heard how a cert could have two parent certs though of course it's logically possible |
| 16:30.58 | freemangordon | env var? |
| 16:31.08 | jonwil | no |
| 16:32.21 | DocScrutinizer05 | why don't we simply trust the SUPL cert itself, so we don't need to care about any friggin broken parent/root certs? |
| 16:33.00 | freemangordon | jonwil: maemosec_certman_collect("location-proxy", 1, my_cert_store); ? |
| 16:33.07 | jonwil | yeah thats it |
| 16:33.16 | jonwil | The patch was to change the 1 into an 0 |
| 16:33.20 | bencoh | 18:32 < DocScrutinizer05> why don't we simply trust the SUPL cert itself, so we don't need to care about any friggin broken parent/root certs? |
| 16:33.21 | jonwil | but I found a way to avoid the need to do that |
| 16:33.23 | bencoh | +1 |
| 16:33.54 | bencoh | still need to make sure trusting this cert doesn't mean trusting every cert signed by it |
| 16:34.16 | freemangordon | bencoh: supl cert cannot be used for signing anyways |
| 16:34.25 | bencoh | why? |
| 16:34.44 | freemangordon | because it cannot, it is neither root nor ntermediate |
| 16:34.56 | bencoh | huh? |
| 16:35.01 | jonwil | From what I have seen in the openssl source code it will only look in the trust store when it finds a self-signed cert at the end of the chain (in which case it looks for an exact match) or when it finds a certificate where the issuer is not in the chain (in which case it looks for that issuer in the root CA store) |
| 16:35.05 | KotCzarny | what if they (or mitm) start sending something else? |
| 16:35.38 | jonwil | i.e. if we added the cert for supl.nokia.com to the root CA store, openssl will never even see it |
| 16:36.14 | jonwil | It will see that the first certificate in the chain has a parent that is also in the chain and never check the supl.nokia.com cert against the root CA store |
| 16:36.45 | DocScrutinizer05 | bencoh: aiui cert have certain pirposes what they can be used for, you can set this while creating them |
| 16:37.06 | jonwil | And yes the cert for supl.nokia.com doesn't have the flags set to allow it to be used to sign other certs |
| 16:37.39 | jonwil | anyhow, let me try the idea I have for loading the root cert in a way location-proxy can use it but other things cant |
| 16:37.49 | bencoh | DocScrutinizer05: the fact is I dont remember doing anything special when generating (custom) CAs, but maybe |
| 16:38.15 | jonwil | and if that works we can ship that in another maemosec-certman-common-ca update and not need to patch lication-proxy at all |
| 16:38.19 | jonwil | location-proxy |
| 16:38.51 | *** join/#maemo dafox (~dafox@ip3e8380c8.speed.planet.nl) |
| 16:38.53 | freemangordon | bencoh: http://pastebin.com/HrmRetbm |
| 16:39.01 | jonwil | not need to patch it nor need to do anything special when updating the regular root CA store from the mozilla cert store |
| 16:39.38 | freemangordon | bencoh: " Â TLS Web Server Authentication, TLS Web Client Authentication" |
| 16:41.39 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 16:41.45 | DocScrutinizer05 | ((supl cert cannot be used for signing)) that's a good thing then and we should simply set dupl cert to "trsuted" in cert store |
| 16:41.56 | jonwil | no need for messing with that |
| 16:42.06 | jonwil | The fix I have requires no patching to location-proxy |
| 16:42.07 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 16:42.28 | DocScrutinizer05 | that's not messing, that's the simplest approach for a cert that expires in 3 months |
| 16:42.52 | jonwil | All that is needed (assuming my test works) is to put the missing root cert (the insecure one) into maemosec-certman-common-ca in the right place so location-proxy will find it |
| 16:43.06 | freemangordon | mhm |
| 16:43.16 | DocScrutinizer05 | yes, obviously |
| 16:43.21 | freemangordon | in location-proxy domain |
| 16:43.23 | jonwil | Its an easy job and assuming my test works I will do that myself |
| 16:43.29 | jonwil | yes location-proxy domain |
| 16:43.43 | KotCzarny | do it, test it, yay for teamwork! |
| 16:45.42 | bencoh | freemangordon: oh, okay |
| 16:46.17 | jonwil | Time to reboot my phone for the billionth time today :) |
| 16:47.31 | freemangordon | reboot? why? |
| 16:47.47 | jonwil | to get the right location-proxy binary loaded and running :) |
| 16:47.54 | freemangordon | ah |
| 16:47.55 | freemangordon | :) |
| 16:53.49 | sixwheeledbeast | I have no idea about certs but is it definitely the cert at fault? as per Pali's post on TMO. |
| 16:56.23 | sixwheeledbeast | http://talk.maemo.org/showpost.php?p=1522878&postcount=242 |
| 16:58.23 | freemangordon | jonwil: iiuc, we just need /etc/certs/location-proxy with the certs in there and /etc/secure/location-proxy with the hashes, right? |
| 16:59.04 | jonwil | yeah I am updating maemo-security-certman now |
| 16:59.05 | jonwil | with the right bits |
| 16:59.12 | freemangordon | cool |
| 16:59.17 | freemangordon | did it work? |
| 17:01.03 | jonwil | building new packages now |
| 17:01.10 | jonwil | then I will test it on my phone |
| 17:01.23 | freemangordon | ok |
| 17:01.23 | *** join/#maemo at1as (~at1as@24-231-230-53.static.trcy.mi.charter.com) |
| 17:05.13 | jonwil | unpacking new package on my phone then I test it |
| 17:05.21 | *** join/#maemo Vajb_ (~Vajb@85-76-48-184-nat.elisa-mobile.fi) |
| 17:08.34 | jonwil | helps if I update the correct debian packaging so it will pull the right files in |
| 17:10.02 | *** join/#maemo Oksanaa (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 17:11.06 | Oksanaa | Strongly recommend https://github.com/Unode/firefox_decrypt for recovering forgotten passwords from MicroB. Unless there is a better one somewhere? |
| 17:11.40 | Oksanaa | Works with python2.7 ^ |
| 17:17.14 | Juesto | Password manager? |
| 17:17.16 | Juesto | interesting |
| 17:17.30 | jonwil | The fix is up |
| 17:17.46 | jonwil | The latest maemo-security-certman contains all the right bits |
| 17:18.33 | jonwil | as of 0.2.9 supl will work 100% with supl.nokia.com |
| 17:19.24 | jonwil | Someone should probably stick 0.2.9 into the appropriate repos |
| 17:19.27 | jonwil | so everyone can get it |
| 17:21.08 | jonwil | I would do it but I dont think its a good idea to try and upload packages to repos when its 3:30am in the morning and you need to spend ages remembering how the hell you put packages in the repos :) |
| 17:22.00 | Oksanaa | :) |
| 17:22.24 | KotCzarny | sicelo: ^^^ |
| 17:22.38 | KotCzarny | jonwil: that's what scripts are for |
| 17:22.45 | jonwil | :) |
| 17:23.00 | KotCzarny | and always were, even in middle ages |
| 17:23.25 | KotCzarny | i wouldnt remember how to upload to extras if i didnt made the scripts |
| 17:23.47 | Oksanaa | make* |
| 17:23.59 | KotCzarny | :) |
| 17:24.13 | *** part/#maemo Oksanaa (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 17:24.21 | KotCzarny | to be completely correct it should be: haven't made |
| 17:24.30 | freemangordon | jonwil: I will do it either later today or tomorrow |
| 17:24.46 | jonwil | nice :) |
| 17:25.39 | freemangordon | oh, you fixed changelog as well, great |
| 17:26.46 | jonwil | anyhow, its a nice elegant fix in the end (thanks to Nokia already using the location-proxy domain for certman) |
| 17:27.24 | freemangordon | :nod: |
| 17:27.42 | freemangordon | way better than patching the binary |
| 17:29.49 | jonwil | yeah I miss-understood what the code was doing |
| 17:29.52 | jonwil | but then I figured it out |
| 17:31.10 | *** join/#maemo louisdk (~louisdk@5.103.130.65) |
| 17:31.41 | jonwil | Now that we fixed this there is no reason for a location-proxy clone |
| 17:31.51 | jonwil | We dont need one for Neo900 or other platforms either |
| 17:32.10 | freemangordon | we need, for x86-64 |
| 17:32.23 | freemangordon | but there is no hurry |
| 17:32.33 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 17:32.36 | jonwil | no we dont, its only ever useful for a device with the N900 GPS chip |
| 17:32.56 | jonwil | it makes direct calls to liblas (low level interface to n900 bb5 gps chip) |
| 17:33.34 | freemangordon | not sure, n900 supports BT GPS as well |
| 17:33.34 | jonwil | for x86 or other platforms we just need to replace/clone/substitute liblocation |
| 17:33.44 | freemangordon | ah, ok |
| 17:33.46 | jonwil | n900 BT GPS doesn't do supl |
| 17:33.56 | freemangordon | yep, right |
| 17:33.59 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 17:36.21 | jonwil | with the fix in place I can get <50m accuracy even with the N900 sitting on my desk in my apartment |
| 17:36.43 | jonwil | and picking up 10 or more sats with many in use |
| 17:37.08 | jonwil | and maps locks on no problems |
| 17:37.17 | jonwil | now maps is useful again :) |
| 17:38.22 | KotCzarny | yay? |
| 17:38.35 | KotCzarny | i should update to cssu one day |
| 17:41.00 | jonwil | ok, its nearly 4am here and I should probably get some zzz :) |
| 17:41.02 | jonwil | later :) |
| 17:44.53 | Juesto | great |
| 17:45.24 | Juesto | x86 first freemangordon |
| 18:04.51 | DocScrutinizer05 | ((We dont need one [location-proxy] for Neo900 or other platforms either)) good call. need quite some discussion in devel peergrpup |
| 18:05.54 | DocScrutinizer05 | oh, seems you covered it comprehensively |
| 18:13.03 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 18:15.13 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 18:54.27 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 18:54.57 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 19:04.16 | *** join/#maemo at1as (~at1as@24-231-230-53.static.trcy.mi.charter.com) |
| 19:15.06 | Sicelo | let's take bets what gonna gappen to Nokia SUPL in 3 months? <<<< FMG is right. they will most likely fix it .. they always have .. it's not 1st time that it 'expires' /// < KotCzarny> i wonder why bother with ssl at that point <<< because the protocol (or clients) require it? /// |
| 19:15.21 | Sicelo | i'll test 0.2.9 shortly :) |
| 19:18.43 | Sicelo | Oksana: MicroB supports the 'address' *chrome://passwordmgr/content/passwordManager.xul* |
| 19:18.50 | Sicelo | so no need for any script |
| 19:20.04 | bencoh | ooh, good to know |
| 19:22.36 | Sicelo | :-) |
| 19:23.15 | Sicelo | of course it also means someone can steal your passwords too |
| 19:23.30 | bencoh | indeed |
| 19:24.07 | Sicelo | but even on my pc, the same thing applies .. |
| 19:26.10 | bencoh | unless you use a master password |
| 19:26.31 | Sicelo | ah yes |
| 19:35.00 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 19:35.31 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 19:46.39 | Sicelo | jonwil didn't share 0.2.9 yet, did he? |
| 19:47.04 | KotCzarny | he have said something about being late and not thinking straight |
| 19:47.12 | KotCzarny | *has |
| 19:47.28 | Sicelo | cool .. i'm in no rush .. 0.2.3 doing the job good enough for present needs |
| 19:58.02 | *** join/#maemo xorly (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 20:12.24 | DocScrutinizer05 | Sicelo: you're aware Nokia basically is no more? |
| 20:12.29 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 20:14.16 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 20:14.35 | DocScrutinizer05 | so >>they will most likely fix it .. they always have ..<< doesn't exactly sound right |
| 20:14.52 | DocScrutinizer05 | particularly second half is incorrect |
| 20:16.29 | DocScrutinizer05 | Nokia failed apically to update the repo keys while they still could, and they failed to make use of alternative ways/keys the community (Pali iirc) found for them, to fix the issue after it's been too late for 'normal' fix |
| 20:17.25 | Pali | yes, they failed to resign nokia ssu apt repos with /correct/ pgp key |
| 20:17.30 | DocScrutinizer05 | so no, absolutely not >>they always have ..<< |
| 20:17.35 | Pali | even they got instructions how... |
| 20:19.30 | DocScrutinizer05 | they even are notorious for their simple HTTPS certs expiring before they bother about renewal |
| 20:20.30 | Sicelo | when did those expired? |
| 20:21.59 | Sicelo | but yes, it's not first time the supl cert expires (as FMG also noted) ... of course i can't know for sure if they will fix it this time (hence "most likely"), nor can anyone say for sure that they won't |
| 20:23.48 | Sicelo | maybe jonwil will have to hack liblocation-proxy after all .. or FMG RE's it .. then we can possibly use supl.google.com (which for some reason doesn't work so well for N900) |
| 20:24.15 | Sicelo | s/have to/could eventually/ |
| 20:24.22 | DocScrutinizer05 | any citation for any of that? |
| 20:24.51 | Sicelo | citation for? |
| 20:25.04 | DocScrutinizer05 | any of that |
| 20:26.10 | DocScrutinizer05 | [2017-02-05 Sun 18:26:46] <jonwil> anyhow, its a nice elegant fix in the end (thanks to Nokia already using the location-proxy domain for certman) Now that we fixed this there is no reason for a location-proxy clone |
| 20:26.49 | Sicelo | heh ... aren't we talking about what *might* happen when the cert finally expires? |
| 20:26.56 | *** join/#maemo spiiroin (~spiiroin@178-55-78-55.bb.dnainternet.fi) |
| 20:27.00 | bencoh | apart from reducing the number of blobs in the porting process |
| 20:27.25 | DocScrutinizer05 | [2017-02-05 Sun 18:31:51] <jonwil> We dont need one for Neo900 or other platforms either |
| 20:28.12 | Sicelo | ... yes .. but the cert expires in May .. there won't be a Neo900 then |
| 20:28.27 | DocScrutinizer05 | how's that related? |
| 20:28.35 | Sicelo | doesn't get what DocScrutinizer05 is on about |
| 20:28.50 | DocScrutinizer05 | did you get what jonwil said? |
| 20:28.54 | Sicelo | yes |
| 20:28.57 | DocScrutinizer05 | or how his patch works? |
| 20:29.06 | Sicelo | yes to that too |
| 20:29.47 | DocScrutinizer05 | so why do you think he's incorrect about no need for RE of location-proxy? |
| 20:30.06 | Sicelo | i don't think that .. |
| 20:30.14 | DocScrutinizer05 | o.O |
| 20:31.08 | DocScrutinizer05 | sorry, I'm roo wasted from flu to continue this discussion |
| 20:31.13 | DocScrutinizer05 | too* |
| 20:31.16 | Sicelo | i'm just saying that if supl.nokia.com every completely stops working for us (due to cert of whatever else), maybe RE can help us with other SUPL servers ... will it really help? i don't know, but that's a maybe. curently supl.google.com doesn't really work for us |
| 20:31.25 | Sicelo | yeah you need some rest :) |
| 20:31.49 | DocScrutinizer05 | don't you tell me what I need |
| 20:32.49 | DocScrutinizer05 | I also can't recall maemo per se had issues with supl.google.com |
| 20:34.37 | Sicelo | well there are .. http://talk.maemo.org/showthread.php?p=1468151#post1468151 |
| 20:37.40 | DocScrutinizer05 | hmm |
| 20:37.58 | DocScrutinizer05 | anyway I guess it's maybe time for a supl.maemo.org service |
| 20:38.23 | Sicelo | that'd be nice .. i think someone suggested that (Ulle) |
| 20:38.24 | DocScrutinizer05 | O mean, it's a pathetic 5kB of data basically |
| 20:38.29 | DocScrutinizer05 | I* |
| 20:39.11 | DocScrutinizer05 | we just need a GPS chipset that allows download of the almanac from sats and storing that almanac to a file |
| 20:40.16 | DocScrutinizer05 | alternatively we need a data source of almanac in the intarwebs |
| 20:41.35 | Sicelo | maybe run a supl server on the N900 itself .. wonder how good/bad that would be |
| 20:41.38 | DocScrutinizer05 | https://www.navcen.uscg.gov/?pageName=gpsAlmanacs maybe? |
| 20:42.24 | bencoh | Sicelo: not on n900 then |
| 20:42.46 | DocScrutinizer05 | Sicelo: err what? |
| 20:42.53 | bencoh | (as DocScrutinizer05 said actually) |
| 20:44.37 | Sicelo | ok |
| 20:44.44 | DocScrutinizer05 | http://git.osmocom.org/osmocom-lcs/ along that line maybe |
| 20:45.11 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 20:46.03 | DocScrutinizer05 | uBlox chipset allows downloading eph and alm from GPS, after receiving it from SVs |
| 20:47.00 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 20:47.47 | DocScrutinizer05 | actually I'm not sure if SUPL is supposed to provide more than just almanac, maybe also ephemeris for the location the client asked for in supl request? |
| 20:48.15 | DocScrutinizer05 | maybe even support for geolocation bnased on BTS cellIDs seen, AP names etc? |
| 20:48.17 | bencoh | both iirc yeah |
| 20:48.51 | bencoh | hm no cellid-based geoloc doesn't depend on supl afaiu |
| 20:49.15 | bencoh | but supl client can choose to get eph in addition to alm |
| 20:49.23 | DocScrutinizer05 | well, for a first quick and dirty approach, supl.maemo.org could be a proxy asking supl.google.com and whatnot else to gather the needed data |
| 20:49.55 | bencoh | there is a commandline supl client available in extras-devel |
| 20:50.06 | bencoh | absolutely |
| 20:50.25 | bencoh | and there is already an opensource supl proxy implementation out there |
| 20:50.33 | DocScrutinizer05 | :-) |
| 20:50.35 | bencoh | not ready for production though, but still handy |
| 20:51.05 | DocScrutinizer05 | so go ahead hackers! hack that stuff into shape and let our brilliant techstaff run it on maemo servers :-) |
| 20:52.17 | DocScrutinizer05 | excellent task. very convenient testing on your own local infra, until it goes productive |
| 20:54.13 | Sicelo | OT: what is a good kmz viewer for Linux? |
| 20:54.56 | bencoh | I suppose marble reads kmz |
| 20:55.49 | Sicelo | oh wow .. should look at that |
| 20:56.36 | bencoh | someone recently ported gpxsee to maemo |
| 20:58.18 | DocScrutinizer05 | I just fail to believe there's no official source for current almanac data from gps.gov or whatever |
| 20:59.07 | bencoh | DocScrutinizer05: well ... :) |
| 20:59.12 | DocScrutinizer05 | sure, maybe you need to ask for them sending it in an email, or whatever hoops they may invent to avoid DDoS attacks |
| 21:00.15 | bencoh | they probably wont provide it either |
| 21:00.24 | DocScrutinizer05 | bencoh: almanac is prolly the most widespread ubiquitous data available via RF on this globe |
| 21:01.03 | DocScrutinizer05 | can't think of any sane reason why it wouldn't be avaolable via internet too |
| 21:02.18 | bencoh | it's available through supl servers |
| 21:02.32 | DocScrutinizer05 | yes, and where from those get it? |
| 21:02.36 | bencoh | gps |
| 21:02.40 | DocScrutinizer05 | no way |
| 21:02.47 | DocScrutinizer05 | that's insane |
| 21:02.50 | bencoh | wanna bet? :p |
| 21:03.08 | DocScrutinizer05 | not really, need my rear for other things ;-D |
| 21:07.40 | DocScrutinizer05 | >> Almanacs, Operational Advisories, and NANUs are available for download in two formats: the original format in which the files are produced (.alm, .al3., .nnu, and .oa1) plain text (txt)<< |
| 21:08.37 | DocScrutinizer05 | https://www.navcen.uscg.gov/?pageName=currentAlmanac&format=yuma-txt |
| 21:10.04 | DocScrutinizer05 | bencoh: really bet now? ;-) |
| 21:10.36 | DocScrutinizer05 | https://www.navcen.uscg.gov/?pageName=currentAlmanac&format=sem-txt |
| 21:11.39 | bencoh | huhu, nice :) |
| 21:11.48 | bencoh | and https://igscb.jpl.nasa.gov/components/prods_cb.html |
| 21:13.05 | DocScrutinizer05 | ugh, what's that? a historical log? |
| 21:13.56 | bencoh | not really |
| 21:14.01 | DocScrutinizer05 | Final: 12 days latency; Rapid: 17h; UltraRapid; 8h |
| 21:14.02 | bencoh | well, kindof |
| 21:14.05 | bencoh | yeah |
| 21:14.17 | bencoh | not "historical" but yeah |
| 21:14.53 | DocScrutinizer05 | I'm not really interested in almanac or ephemeral of 13 days ago |
| 21:15.36 | DocScrutinizer05 | UltraRapid *might* be useful, with 8h delay and 48h validity span |
| 21:16.03 | DocScrutinizer05 | umm nope, 24h future, 24h past |
| 21:16.24 | DocScrutinizer05 | and they are 4 times a day, so 6h delay |
| 21:17.33 | DocScrutinizer05 | those are derived AIUI, (see "24h past from observation") so if not even NASA has a way to download that shite from internet... :-S |
| 21:19.53 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 21:22.18 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 21:24.07 | DocScrutinizer05 | http://www.igs.org/products/data >>IGS Ultra-rapid products (IGU) |
| 21:24.08 | DocScrutinizer05 | To reduce the age of the prior, discontinued Predicted orbits, the IGS started the Ultra-rapid products officially week 1087 in November 2000 (see IGSMAIL-3088) . Like the former IGS Predicted products, the Ultra-rapid products are available for real time and near real time use. The Ultra-rapid products are released four times per day, at 03:00, 09:00, 15:00, and 21:00 UTC. (Until week 1267 they were released twice daily.) In this way the |
| 21:24.10 | DocScrutinizer05 | average age of the predictions is reduced to 6 hours (compared to 36 hours for the old IGS Predicted products and 9 hours for the twice-daily Ultra-rapids). The shorter latency should lead to significantly improved orbit predictions and reduced errors for user application<< |
| 21:25.14 | *** join/#maemo lxp (~lxp@unaffiliated/lxp) |
| 21:26.41 | DocScrutinizer05 | the sat positions are with a precision <100cm :-) |
| 21:32.57 | DocScrutinizer05 | >>Geocentric Coordinates of IGS Tracking Stations -- Final velocities: Accuracy horizontal 2 mm/yr vertical 3 mm/yr<< :-> |
| 21:40.24 | DocScrutinizer05 | hmmmm ftp://ftp.igs.org/pub/gps/1935 |
| 21:46.39 | DocScrutinizer05 | what damn compression/archive format is .Z? like in ftp://ftp.igs.org/pub/gps/1935/igu19350_18.sp3.Z Doesn't look like it's plain text as (aiui) suggested in ftp://igs.org/pub/data/format/sp3c.txt |
| 21:46.58 | KotCzarny | man compress |
| 21:52.26 | *** join/#maemo Milhouse (~Milhouse@kodi/staff/milhouse) |
| 21:55.19 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 21:55.49 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 21:57.55 | DocScrutinizer05 | gzip -dkvc <(wget ftp://ftp.igs.org/pub/gps/1935/igu19350_18.sp3.Z -O -)|less |
| 22:04.39 | Pali | DocScrutinizer05: gunzip can unpack .Z files |
| 22:05.50 | DocScrutinizer05 | Pali: yeah, see my last line |
| 22:06.28 | Pali | my gzip does not support -k |
| 22:08.20 | Pali | DocScrutinizer05: .Z files should be compressed by LZW compression, that one used in GIF images |
| 22:08.48 | *** join/#maemo xes (~xes@unaffiliated/xes) |
| 22:09.21 | Pali | (in past there were problem with that compression because of patents) |
| 22:11.00 | DocScrutinizer05 | <PROTECTED> |
| 22:12.35 | DocScrutinizer05 | http://paste.opensuse.org/19770638 |
| 22:14.21 | DocScrutinizer05 | funny detail: the original ftp download was mode 200 |
| 22:15.10 | DocScrutinizer05 | jr@saturn:~> ll /home/jr/tmp/igu19350_18.sp3.Z |
| 22:15.11 | DocScrutinizer05 | --w------- 1 jr users 185183 5. Feb 21:15 /home/jr/tmp/igu19350_18.sp3.Z |
| 22:16.35 | *** join/#maemo xes (~xes@unaffiliated/xes) |
| 22:17.03 | DocScrutinizer05 | well, actually ftp://ftp.igs.org/pub/gps/1935/igu19350_18.sp3.Z is mode 0000 |
| 22:22.03 | DocScrutinizer05 | I just fail to grok why igs.org seems to not provide almanac data |
| 22:23.31 | DocScrutinizer05 | well, maybe NASA to the rescue then? https://www.navcen.uscg.gov/?pageName=currentAlmanac&format=sem-txt |
| 22:29.00 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 22:30.02 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 22:31.17 | DocScrutinizer05 | to help with background: the ephemeral contains data about the exact coordinates of a SV at a particular point in time, while almanac contains the orbital data which allows calculation of such coordinates for any random point in time |
| 22:31.48 | DocScrutinizer05 | at least that's what I see |
| 22:34.55 | DocScrutinizer05 | hmm, not that sure anymore: http://www.colorado.edu/geography/gcraft/notes/gps/ephclock.html |
| 22:35.08 | DocScrutinizer05 | maybe eph contains both |
| 22:36.55 | DocScrutinizer05 | >>Ephemeris data parameters describe SV orbits for short sections of the satellite orbits. Normally, a receiver gathers new ephemeris data each hour, but can use old data for up to four hours without much error. The ephemeris parameters are used with an algorithm that computes the SV position for any time within the period of the orbit described by the ephemeris parameter set.<< and >>Almanacs are approximate orbital data parameters |
| 22:36.56 | DocScrutinizer05 | for all SVs. The ten-parameter almanacs describe SV orbits over extended periods of time (useful for months in some cases) and a set for all SVs is sent by each SV over a period of 12.5 minutes (at least).<< |
| 22:40.30 | DocScrutinizer05 | so alm tells receiver which sats to look for (visible), while eph tells about precise position of a particular sat in next 4h so a decent fix can get calculated |
| 22:42.45 | DocScrutinizer05 | a SUPL server prolly won't send alm when receiver asks for eph applicable to current position estimate, rather the server uses alm locally to determine which eph data to provide to receiver, based on where the receiver currently is located |
| 22:43.34 | DocScrutinizer05 | (my uneducated guess) |
| 22:44.02 | *** join/#maemo at1as (~at1as@24-231-230-53.static.trcy.mi.charter.com) |
| 22:44.07 | DocScrutinizer05 | whould read RFC:SUPL |
| 22:44.32 | DocScrutinizer05 | ~rfc supl |
| 22:44.57 | DocScrutinizer05 | ~ping |
| 22:44.57 | infobot | ~pong |
| 22:45.01 | DocScrutinizer05 | o.O |
| 22:53.46 | DocScrutinizer05 | bencoh: (( hm no cellid-based geoloc doesn't depend on supl afaiu )) http://www.openmobilealliance.org/release/SUPL/V3_0-20140916-C/OMA-AD-SUPL-V3_0-20110920-C.pdf |
| 22:58.50 | DocScrutinizer05 | SUPL V3: Additional positioning methods supported: ⢠SET Based Enhanced Cell/Sector ID |
| 23:00.09 | DocScrutinizer05 | ⢠Sensors |
| 23:00.15 | DocScrutinizer05 | :-o |
| 23:03.06 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 23:03.48 | jonwil | hi |
| 23:04.23 | DocScrutinizer05 | sensors like magnetic compass vs accelerometer to determine geographic latitude? Ambient Light to find if day or night? microphone to detect known acoustic fingerprints? |
| 23:05.28 | DocScrutinizer05 | barometer and temperature for altitude and possibly northern/southern hemisphere? |
| 23:05.45 | *** join/#maemo platicus (~matrixirc@fanzine.igalia.com) |
| 23:06.24 | *** join/#maemo agomez{M} (~agomeziga@fanzine.igalia.com) |
| 23:12.37 | DocScrutinizer05 | for any supl.maemo.org service consider employing >> Security model for non-UICC devices using client certificates stored on the device << |
| 23:13.20 | DocScrutinizer05 | incl an app that updates such client certificate when maemo.org publishes a new one |
| 23:14.21 | DocScrutinizer05 | I guess the latter is easily accomlished via HAM (being that app) |
| 23:18.11 | DocScrutinizer05 | jonwil: you seen?: http://www.openmobilealliance.org/release/SUPL/V3_0-20140916-C/OMA-AD-SUPL-V3_0-20110920-C.pdf |
| 23:23.55 | jonwil | The specs for SUPL aren't really relavent except maybe a few pieces of it if you were cloning location-proxy (which would be wasted effort IMO) |
| 23:24.55 | jonwil | Most of the interesting work is done by the bb5 |
| 23:31.14 | DocScrutinizer05 | huh? we're considering supl.maemo.org |
| 23:31.25 | DocScrutinizer05 | ROTFL @ http://wstaw.org/m/2017/02/06/plasma-desktopV17764.png |
| 23:31.29 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 23:36.15 | DocScrutinizer05 | wow, this goes on like that: http://wstaw.org/m/2017/02/06/plasma-desktopV17764_1.png |
| 23:37.41 | DocScrutinizer05 | you may assume Nokia adhered to the requirements in all BB5 and possibly even in maemo closed blobs like csd |
| 23:38.05 | jonwil | oh I didn't know you were considering running a supl server for maemeo, that is a cool idea |
| 23:38.19 | DocScrutinizer05 | :-) |
| 23:39.53 | DocScrutinizer05 | jonwil: gzip -dkvc <(wget ftp://ftp.igs.org/pub/gps/1935/igu19350_18.sp3.Z -O -)|less; # https://www.navcen.uscg.gov/?pageName=currentAlmanac&format=sem-txt |
| 23:42.18 | DocScrutinizer05 | hates having the 'choice' between supl.nokia.com prone to die, and supl.google.com prolly rogue and often changing API |
| 23:43.35 | jonwil | FYI the header file for the GPS part of bb5 is available and out there. Although no-one has produced a header file for the liblas library that does the low level talking to the GPS part of bb5 |
| 23:45.03 | jonwil | Only things I know of that talk to liblas though are location-daemon, location-proxy and that clear tool |
| 23:45.55 | DocScrutinizer05 | you're aware that BB5 is a OMAP A8 (iirc) system of its own? |
| 23:46.41 | jonwil | yes I am aware |
| 23:46.53 | jonwil | I mean the GPS ISI messages |
| 23:47.14 | jonwil | the interface to the GPS code in the bb5 |
| 23:47.30 | jonwil | liblas is a wrapper around libisi to send isi messages to GPS bits on bb5 |
| 23:47.43 | DocScrutinizer05 | :nod: |
| 23:50.11 | jonwil | but since no device other than the N900 likely has the same GPS hardware, there is no real benefit reverse engineering too much of this stuff or cloning it |
| 23:50.40 | jonwil | There are things far more useful to clone out there (pulseaudio blobs for one :) |
| 23:51.18 | DocScrutinizer05 | of course |
