IRC log of #maemo for Sunday, 2017-02-05

*** Pali has joined #maemo00:42
Sicelofreemangordon, DocScrutinizer05 ... 'solved' the problem with AGPS - *maemosec* packages from devel have problem of some sort. will report on devel thread01:08
freemangordonhmm01:12
freemangordonsome certificate problem again I guess01:12
Sicelopossibly, but 2nd N900 using CSSU-T (no devel) worked perfectly the whole time. no idea what's up with the devel ones01:13
freemangordonSicelo: https://github.com/community-ssu/maemo-security-certman/commits/master01:14
freemangordonwe should wait fo jonwil to appear01:15
freemangordonbut yeah, report the problem on cssu-devel thread01:15
Siceloi've done, https://talk.maemo.org/showpost.php?p=1522850&postcount=510   :-)01:15
freemangordonSicelo: could you try to connect with openssl instead of cmcli?01:19
freemangordonah, you already did it01:20
Siceloi did both01:20
Siceloyeah01:20
Siceloweird thing is .. exactly the same output for both devices for cmcli and openssl01:21
freemangordonmhm01:21
freemangordonI wonder why cmcli gives self-signed error01:21
freemangordonSicelo: are you sure you did cmcli on both devices?01:24
freemangordonas it does not fail on mine01:24
freemangordon"Verified OK"01:24
freemangordonfor the same command as yours01:24
Siceloyes, yes01:25
Sicelobut now that i've downgraded maemosec-certman-tools one the one to 0.2.3, it verifies ok01:25
freemangordonSicelo: what is the version on your second device?01:26
Sicelothe 2nd N900 (which has had consisted quick fixes), has 0.2.4 .. didn't downgraded, and that ones still 'sees' self-signed01:26
freemangordonweird01:26
Sicelo0.2.4 doesn't seem to be in any repo now though :-/01:26
Sicelowhat version do you have?01:27
freemangordon0.2.301:27
freemangordonSicelo: what is the output from dpkg -L maemosec-certman-common-ca | grep 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d6101:34
freemangordonon that device with 0.2.401:34
Sicelo/etc/certs/common-ca/00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem01:37
Sicelo/etc/certs/common-ca/00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem01:37
Siceloproblem is the duplicate?01:37
freemangordonno, most probably it is in the order01:37
Siceloyes .. by the way the 0.2.4 device is 'fine' :)01:38
freemangordonwhat do you mean?01:38
freemangordonif cmcli fails to verify, it is not fine01:38
freemangordonsee https://github.com/community-ssu/maemo-security-certman/commit/2cbd96e89d7529e1ce25801824fb76f39b05b83601:39
Siceloah yes .. meant from the POV of A-GPS01:39
freemangordonI suspect same/similar problem01:39
Siceloi remember those fixes back then01:39
freemangordonSicelo: but then, why cmcli fails?01:39
Siceloi really have no idea about that01:40
Sicelomaybe jonwil will have idea, but01:40
Sicelonot sure if this is related .. https://talk.maemo.org/showthread.php?t=96433 .. seems to be the only place 0.2.4 is mentioned01:41
freemangordonyep, lets wait for him to appear. If not, tomorrow I'll install the latest from -devel and will check01:41
Sicelothe thread seems to have ended without anything specific01:42
* freemangordon goes afk01:42
freemangordonnight01:42
Sicelosure .. at least you'll probably be able to understand it better than I01:42
Sicelonight01:42
*** cyphase has quit IRC01:43
*** NeKit has quit IRC01:49
*** NeKit has joined #maemo01:50
*** jonwil has joined #maemo02:02
Sicelojonwil: we were just talking about you :)02:07
jonwilhi02:07
* jonwil reads logs02:07
Sicelosee last two posts in cssu devel thread .. a-gps problem that can be attributed to maemosec-certman packages02:08
jonwilok, what exactly is the problem?02:08
jonwilSo the problem is what exactly?02:09
DocScrutinizer05maybe supl format changed and results in modem GPS engine hanging now?02:09
jonwilthat the new set of root CAs doesn't work properly for AGPS?02:09
Siceloa-gps does not work with maemo-security-certman (0.2.7)02:09
Siceloyes02:09
jonwilwhich version is the last one that works?02:10
Siceloi downgraded to 0.2.3 and i get instant fix02:10
Sicelo0.2.4 gets good fix too .. but fails cmcli verification02:10
Sicelo0.2.3 has good fix, and cmcli verifes supl.nokia.com OK02:11
*** dafox has quit IRC02:15
DocScrutinizer05sorry now that sounds like bogus heissenbug, aka unrelated02:16
DocScrutinizer05you'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 tmo02:18
*** rZr has quit IRC02:19
*** RzR has joined #maemo02:20
SiceloDocScrutinizer05: when it works - Socket to supl.nokia.com opened, fd=13, verify_res=002:20
Sicelowhen it doesn't, Socket to supl.nokia.com opened, fd=12, verify_res=1902:20
DocScrutinizer05meh, gimme tcpdump/whireshark!02:22
*** dafox has joined #maemo02:22
DocScrutinizer05even tshark02:22
DocScrutinizer05anyway, you clarified that now, so it looks less unrelated02:24
jonwilCould it be that the "02:24
jonwilthe "  Change the order of VerSign root certificates, so "newer" certificate to appear first. Fixes supl server not working." change in maemo-security-certman is related02:25
jonwilThat change was made in 0.2.302:25
jonwilIts possible my total reimport of the certificates in later versions caused the order to change again somehow02:25
Sicelomost likely, yes02:25
jonwilI have no real way to verify that though02:25
DocScrutinizer05yes02:25
jonwilspeaking of which, I need to update maemo-security-certman to the latest set of mozilla root certificates, haven't done it for a while :)02:26
Sicelo:)02:26
DocScrutinizer05of course >>Fixes supl server not working."<< is related ;-D02:26
* DocScrutinizer05 has absulute faith in Ivo fixing that02:30
DocScrutinizer05I think cert management is your daily warmup, freemangordon. Right? ;-)02:31
DocScrutinizer05~trump02:32
infobotwell, trump is NULL02:32
DocScrutinizer05wow02:32
DocScrutinizer05~factinfo trump02:32
infobottrump -- 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.02:32
DocScrutinizer05https://www.youtube.com/watch?v=zP7RbhfcV7o02:39
*** cyphase_eviltwin has joined #maemo02:50
*** xorly has quit IRC02:50
jonwilok, the root CA store is updated02:50
*** Pali has quit IRC02:50
DocScrutinizer05please keep in mind that it took quite some investigation and WTF-moments to make a _working_ cert store back when patching it02:51
DocScrutinizer05I think there are some undocumented non-intuitive (aka flaw) sequence/sortorder issues with the cert store02:52
DocScrutinizer05iirc02:52
DocScrutinizer05took 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 maemo02:53
*** florian has quit IRC02:54
jonwilin 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.02:54
DocScrutinizer05I think if that option had existed, it would have been taken back when02:54
jonwilanyhow, 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...02:55
DocScrutinizer05when 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 much02:56
DocScrutinizer05note that certs are not only relevant for supl02:56
DocScrutinizer05you have quite a few apps to check02:57
DocScrutinizer05I suggest you read the historical tickets and tmo threads regarding that stuff02:57
DocScrutinizer05or wait for fmg (and/or pali?) to chime in02:57
*** dafox has quit IRC02:58
DocScrutinizer05I really can't recall details02:59
DocScrutinizer05only kbnow it been a PITA02:59
jonwilok, so location-test-gui can definatly see satellites but it cant get a lock02:59
jonwilI wish it displayed more info about the actual connections to the supl server02:59
DocScrutinizer05hmm, such a statement is pretty generic. Did you make sure the signal of sats is OK?03:00
jonwilwireshark logs wont help since you cant wireshark an SSL connection unless you can peek into memory and get the keys03:00
DocScrutinizer05did you make sure you have correct system time?03:00
DocScrutinizer05did you reset BB5 GPS?03:00
DocScrutinizer05(SSL) right :-/03:00
jonwilsystem time is comming from network so it should be correct03:01
jonwilit says ept, eph, epv, epd, eps and epc are all NAN03:02
jonwilI am connected to both 3G and WiFi here03:02
jonwilas for resetting bb5 GPS I dont know how03:02
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 anymore03:03
jonwilIf there was a problem with GPS here in Australia I would have heard of it03:03
jonwilAbout to go outside and see if that makes a difference :)03:03
DocScrutinizer05ohmy, you expected a GPS fix indoors? :-o03:04
jonwilI have gotten such fixes before in this place03:04
DocScrutinizer05prolly not, most like was no first fix and maybe no GPS fix at all03:05
DocScrutinizer05see03:05
jonwilmaybe03:05
DocScrutinizer05~gsm-ahps03:05
DocScrutinizer05~gsm-agps03:05
infoboti 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/RRLP03:05
jonwilok, let me try this outside and see what I get.03:05
DocScrutinizer05U-TDOA is more accurate and faster than any (A)GPS03:05
DocScrutinizer05and works indoors, as long as you got a network signal03:06
DocScrutinizer05~u-tdoa03:06
infobotwell, u-tdoa is http://en.wikipedia.org/wiki/U-TDOA03:06
DocScrutinizer05standard on pretty much all 3G nowadays03:07
DocScrutinizer05note that RRLP is network layer and thus totally opaque to userland03:11
jonwilgoing outside didn't get me a lock even though I could see the sats03:12
DocScrutinizer05did they have signal?03:12
jonwillocation-test-gui didn't show me anything to suggest they did one way or the other03:12
jonwilIt said there were lots of sats visible but none in use03:12
jonwilas high as 5 visible03:13
DocScrutinizer05"sats in sight" only means what almanach tells you are supposed to be able to see under optimal conditions03:13
DocScrutinizer05it suggests you received somewhat working almanach data03:14
DocScrutinizer05*if* the sats shown as "visible" are actually correct03:14
jonwilNo idea then why its not working if I select either "GNSS" or "AGNSS" in location-test-gui03:14
DocScrutinizer05maybe because it has a totally off idea where you are?03:15
jonwilok, sounds like a reset of bb5 might help03:15
jonwilshould I try this bb5 data reset thing or should I just try a power down and reboot?03:16
DocScrutinizer05to guess what sats are visible (and thus search for them) the algo needs your position first. To some +-few 100s of miles03:16
jonwili.e. power down for a minute then reboot?03:16
DocScrutinizer05try both. Did you find that reset thing? where?03:16
jonwilI didn't find the reset thing03:16
jonwilpowered down my phone now, will wait a minute or two then power up again03:17
DocScrutinizer05remove battery03:17
jonwilI did03:17
jonwilif I get the "enter date/time" screen then I will know its reset the bb5 I guess03:17
DocScrutinizer05so modem definitely doesn't store shit in RTC or cmos storage03:17
jonwilok, that should be long enough, lets try it now03:19
jonwilsee if it resets any stuff the bb5 might be confused about03:19
jonwilok, I got welcome screen so that means things got reset03:20
jonwilalthough that didn't help03:23
jonwilI strongly suspect its a certificate problem talking to the SUPL server03:24
jonwilcmcli says "verification failed, self signed certificate"03:26
jonwildowngrading maemosec-certman-common-ca to the version with the fix in it didn't help either03:36
jonwilstill no lock03:36
jonwilNothing I do seems to get a GPS lock on my N90003:37
DocScrutinizer05even without any connectivity, GPS should get a fix after 15min the latest, as long as there's a strong enough sat signal03:39
*** cyphase_eviltwin is now known as cyphase03:40
DocScrutinizer05actually should be faster since every sat sends its own orbit data faster than the complete almanac/ephemeral03:40
DocScrutinizer05but you need a iirc 30dB higher signal than needed to *keep* a fix03:41
DocScrutinizer05and correct system time and at least country you're in will prolly also help a lot03:42
DocScrutinizer05system time is easily obtained from SAT data. Location not that easily03:43
DocScrutinizer05the better your initial guess of location, the faster TTFF03:43
DocScrutinizer05basically03:43
DocScrutinizer05and that's partially what A in AGPS is all about03:44
jonwilok 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).03:44
DocScrutinizer05when you get bogus assistance data, I'm pretty sure you're better off with none at all03:44
jonwilThis 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 anything03:45
jonwilMy gut says bogus stored data is the likely answer03:45
DocScrutinizer05you got a SIM?03:45
jonwilYep, I have a sim in the phone03:46
jonwiland it returns the correct country code03:46
DocScrutinizer05see RRLP!!!03:46
jonwiland I am connected to 3G voice03:46
jonwil"CWP" seems to have given me a lock03:47
jonwilalthough I think that's just cell tower positioning and nothing to do with GPS03:47
DocScrutinizer05yes, and cell towers send "supl"03:47
jonwilI think I need to find that tool to remove whatever crap bb5 is holding03:48
DocScrutinizer05you need to remove SIM first of all03:48
DocScrutinizer05or at least go airplane mode03:48
DocScrutinizer05though I'm still not sure if it *receives* RRLP nevertheless03:49
jonwilgone to offline mode03:49
jonwiloffline mode plus GNSS in location-test-gui should mean it uses 100% no cellmo works-like-standalone-GPS offline mode to get a lock03:50
jonwilwith nothing taken from the cellmo or networks of any kind03:50
jonwilLooks like finding that tool to erase stored GPS data in bb5 would help03:52
*** luke-jr has quit IRC03:55
*** luke-jr has joined #maemo03:57
DocScrutinizer05https://bugs.maemo.org/show_bug.cgi?id=7026#c3504:01
povbotBug 7026: Can't get a GPS lock with several satellites at view04:01
DocScrutinizer05"should mean" HAHA04:01
DocScrutinizer05please read about RRLP04:02
DocScrutinizer05~gsm-agps04:02
infobotfrom 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/RRLP04:02
DocScrutinizer05BB5 prolly has not even a means to NOT use RRLP when it's available04:02
DocScrutinizer05RRLP is 911-related and completely outside of user control04:03
DocScrutinizer05and obviously not even the Nokia maemo gurus knew about that when they made maemo504:04
DocScrutinizer05BB5 is largely opaque to them as well04:04
*** geaaru has quit IRC04:05
Juestoo_O04:06
DocScrutinizer05please 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 know04:07
DocScrutinizer05FFS!04:09
DocScrutinizer05~literal gsm-agps04:09
infobot"gsm-agps" is "<reply>see rrlp"04:09
DocScrutinizer05~literal rrlp04:09
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"04:09
DocScrutinizer05infobot: 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/RRLP04:11
infobotDocScrutinizer05: okay04:11
DocScrutinizer05>>In all known phones, RRLP operation is completely invisible to the user of the phone<<04:12
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.<<04:13
DocScrutinizer05>>Most RRLP capable phones will request GPS assistance data from the network.<<04:14
DocScrutinizer05bottom 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 mode04:17
* DocScrutinizer05 heads out coughing a bit more, and probing own Core temperature04:18
DocScrutinizer05http://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)04:26
jonwilI tried clear-gps-cache but that didn't help04:26
jonwilI do see SNR values for a bunch of satellites (as many as 6 when I stand outside away from buildings)04:27
jonwilValues ranging from the high 20s to 40+04:27
jonwilIn terms of the weather its very hot and very humid with light clouds in the sky, maybe the humidity or heat is causing interference04:27
jonwilok, wtf, I got a lock!!!04:29
jonwilon AGNSS04:29
jonwiland now of course I get a lock again straight away because my phone hasn't moved04:29
jonwilso its definatly not broken GPS hardware or bogus data stored by bb504:33
jonwilnow I need to go somewhere away and see if GPS still gets a lock or something.04:33
jonwiland how long it takes04:33
jonwilnot sure how far away I should go to be far enough away from current pos to test that04:34
DocScrutinizer0530+ is fine, should result in a fix after some time04:39
DocScrutinizer05and seems it did :-)04:40
DocScrutinizer05glad it finally worked for you04:43
DocScrutinizer05did you have SIM/network enabled?04:43
*** pagurus has quit IRC04:48
*** pagurus has joined #maemo04:49
jonwilyes I did at that point04:52
jonwilI 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.04:53
jonwilIf I move a couple km away it will invalidate any old position data GPS chip holds04:53
jonwilmaybe run the clear-gps-cache tool as well04:53
jonwiland reboot the phone to clear anything held in bb5 ram04:53
*** spiiroin has quit IRC05:05
*** M4rtinK has quit IRC05:16
*** spiiroin has joined #maemo05:18
*** lxp1 has quit IRC06:04
jonwilMy 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 link06:04
DocScrutinizer05yes06:05
DocScrutinizer05sprt 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 fix06:07
DocScrutinizer05aiui each sat sends its own orbit parameters and the current time once every 40s or somesuch06:08
DocScrutinizer05as long as the GPS chip has enough correlators to receive all possible sats concurrently, it should get a first fix in pretty short time06:09
DocScrutinizer05I almost forgot the details, GPS is complex and I last time looked into it several years ago06:10
DocScrutinizer05http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html recommended06:12
DocScrutinizer05http://www.colorado.edu/geography/gcraft/notes/gps/gps.html#SVData06:14
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 data06:15
DocScrutinizer05parameters) for the transmitting SV are sent in subframes two and three<<06:15
DocScrutinizer05full almanac however takes some 12 or 15min of glitch free reception for complete download06:21
DocScrutinizer05"full" as in "has all data of all sats for the next week or so"06:21
DocScrutinizer05aah >>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.<<06:23
DocScrutinizer05http://www.colorado.edu/geography/gcraft/notes/gps/gif/databits.gif06:24
DocScrutinizer05>>Signal acquisition time on receiver start-up can be significantly aided by the availability of current almanacs<<06:28
DocScrutinizer05only 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#06:30
DocScrutinizer05rough idea here means like +-500km and +´1min I guess06:31
*** geaaru has joined #maemo06:31
DocScrutinizer05nice:  http://www.colorado.edu/geography/gcraft/notes/gps/gif/bitsanim.gif06:32
DocScrutinizer05corellator06:32
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)****.<<06:38
DocScrutinizer05the complete almanac is 37500 bit in size06:41
DocScrutinizer05so ~5kB06:42
DocScrutinizer05it describes the orbits of all SV (aka SAT) and stays valid until reality differs from clean math06:43
DocScrutinizer05the 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 30s06:45
DocScrutinizer05so 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 <40s06:51
DocScrutinizer05unless no sufficiently good sat signals available06:51
DocScrutinizer05almanac helps to pick the right code (aka SV) and doppler correction, from estimation of point in time and space06:53
DocScrutinizer05when 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 are06:55
DocScrutinizer05it'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 position06:57
DocScrutinizer05you'll recover from that as late as seeing another random island west of you, maybe days later06:59
DocScrutinizer05in 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 by07:01
DocScrutinizer05that's why I think in certain situations disabling AGPS **and RRLP** might actually yield better results07:02
jonwilSo 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)07:03
jonwilAnd then if we really need old certs we need to add back just the one cert needed07:03
DocScrutinizer05yep07:04
DocScrutinizer05I *guess* the CA of those Nokia SUPL certs is expired or revoked, and Nokia didn't bother to get a new cert07:05
jonwilI dont know enough about certificates or SSL to know how to do this07:06
DocScrutinizer05or the cert uses an encryption or whatever that has been deprecated since07:06
jonwilI think from something I saw is one cert that uses MD2 signing (which is obsolete and07:07
jonwilobsolete and easily broken07:07
jonwilwell 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 job07:11
jonwilNeed someone who knows more about SSL (or maybe someone who knows more about VeriSign certificates in particular)07:27
*** DocScrutinizer05 has quit IRC07:37
*** DocScrutinizer05 has joined #maemo07:37
jonwilFinding someone that knows about SSL certs is going to be hard though...08:26
*** Michael_a320 has joined #maemo08:46
KotCzarnyregarding gps fix, i've just tested on my n900, cellmo: on, wifi: off, method: gnss09:49
KotCzarnyit took ~10 minutes, all sats are in 19-31dB range09:50
KotCzarnystarted with a few (1-3) now seeing 809:50
KotCzarnyaccuracy 40-140m09:51
KotCzarnystock fw09:51
Vajbbut does it differ from place to place?10:16
KotCzarnythat's a question for me?10:16
Vajbi mean are those satellites spread evenly on sky10:16
VajbKotCzarny: for no one especially10:16
Vajbmore of a rethoric q :)10:17
KotCzarnyyeah, they should be all over the globe10:17
KotCzarnybut in geostationary positions, ie. not moving tiny bit relative to earth10:18
KotCzarnywhat differs is visibility (clouds, buildings) and noise/interferences (e-m noise)10:19
*** florian has joined #maemo10:22
bencohKotCzarny: not geostationary no10:27
KotCzarnyno?10:32
bencohnope10:34
KotCzarnyfun10:35
KotCzarnyhow do they calculate their own position?10:35
KotCzarnyor is it done from earth observatories?10:35
bencohknown/corrected from earth I suppose10:43
bencohor adjusted according to star visibility/positions, or most likely both10:44
KotCzarnyperfect way to confuse receivers in case of war10:44
KotCzarny:)10:44
*** Kabouik has joined #maemo10:54
freemangordonjonwil: the naming order of certificates matter11:00
freemangordonverisign cert used by supl is in the logs ^^^11:01
freemangordonjonwil: 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d6111:01
freemangordonthere are two of those, one with -1 appended to the name11:01
freemangordonand - you don;t need sats at all to get fix when using AGPS11:02
jonwilWhat I have found is that with the latest mozilla cert store, openssl returns X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN11:02
freemangordon:nod:11:02
freemangordoncould you dump cert chain?11:03
freemangordonand pastebin it11:03
freemangordonopenssl s_client has an option to dup cert chain and certs used11:03
freemangordon*dump11:03
freemangordonjonwil: ah, it seems ilew found the missing one11:04
freemangordonjust add it back to cert store and we should be fine11:04
jonwilanyone know how to get GDB to print the address at which the binary you are debugging is actually loaded at?11:04
*** Kabouik has quit IRC11:05
*** Kabouik_ has joined #maemo11:05
freemangordonjonwil: info modules?11:05
freemangordonno, wait11:05
freemangordonit is "info something", but I cant remember that exactly11:06
freemangordonjonwil: try with "info shared"11:06
jonwilfound it, "info files" gives me the address I need11:08
freemangordonok11:08
freemangordongood to know11:08
MaxdamantusPresumably you could just look at /proc/*/maps11:08
* Maxdamantus suspects `info files` pretty much does that.11:09
freemangordonjonwil: however, may i have a cert chain dump?11:09
jonwilhow do I get a cert chain dump?11:09
freemangordonjonwil: add "-showcerts" to openssl s_client command11:10
jonwilWill do that soon and see what I get on the N90011:11
jonwilI ran nss tstclient.exe locally earlier (built NSS on my windows box) and the chain that I got from there was http://pastebin.com/RZ0z259R11:12
jonwilSo that's what supl.nokia.com servers to tstclient.exe on my w7 box11:13
jonwilThe last one in the chain implies that its signed with MD2 (very strange)11:13
jonwilI 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.11:17
jonwilGoing to run the s_client test now11:17
freemangordonjonwil: yes, this is what happens11:17
freemangordonbut, s_client test will pass on n90011:17
freemangordoniirc11:18
freemangordonas openssl is smart enough to use the correct certificate11:18
jonwilhttp://pastebin.com/TeE3jF3m11:19
jonwilThat;s the openssl certificate chain dump11:19
freemangordonmhm11:20
freemangordonbut, cmcli will fail;11:20
jonwilI wonder if its poossible to use IDA to do remote debugging on a N900 via gdb or something11:21
freemangordonyes, but you need to set sysroot11:22
freemangordonwhich means to copy rootfs to a local dir on your pc11:22
bencohand gdbserver on n900 I guess?11:22
freemangordonyes11:23
freemangordonjonwil: I guess you can use ScratchBox directories for that11:23
jonwilok, so I established the IDA remote debugger doesn't run on the N900 so that's definitely out11:26
freemangordonhmm?11:26
freemangordondo you run gdbserver on n900?11:26
jonwilI dont think I have a gdbserver binary11:26
jonwilwait I do11:26
freemangordonwell, no way then11:27
jonwilnot sure how to run it though11:27
freemangordoninstall gdbserver, and run it with --attach parameter11:27
jonwilwhat do I pass for the parameters to --attach?11:27
freemangordon"gdbserver --attach $pid :1234"11:27
freemangordon1234 is the port it listens on11:27
freemangordonchange it as you wish11:28
freemangordonjonwil: 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 binary11:29
*** TriztAway is now known as Trizt11:31
jonwilok, well that didn't tell me much other than that openssl is returning that X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN11:38
jonwili.e. it confirmed what I already knew about how the function worked11:39
freemangordonjonwil: which function?11:40
jonwilthe function I was studying was sub_CF9011:40
freemangordonwhich binary ? :)11:40
jonwillocation-proxy11:40
* freemangordon tries to find where his lication-proxy IDA db is11:41
jonwilIt looks like if SSL_get_verify_result returns non-zero, it prints the "host: %s not verified, result: %ld" error11:42
jonwilvia g_log11:42
freemangordonyes, it returns 19 (self-signed cert)11:42
jonwiland it passes 2 as the first parameter to las_socket_open_response_ntf11:42
freemangordonit is visible in the syslog11:42
jonwilotherwise it skips that error and passes 0 for the parameter to las_socket_open_response_ntf11:42
freemangordonjonwil: I suspect it is SSL_connect that fails11:43
freemangordon"Socket to %s opened, fd=%d, verify_res=%ld"11:43
jonwilok, so I am playing some more with the nss tools on Windows.11:44
freemangordonhow's that going to help?11:44
jonwilwhich btw have the same set of root CAs built into them as my n90011:44
jonwilI am playing more to see just what the chain looks like11:44
jonwiland how it validates11:44
jonwilusing 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 chain11:45
freemangordonmhm11:45
jonwilIf I then run vfychain.exe on those files and pass it just cert.000, it says the chain is bad11:45
jonwilIf I pass it cert.000 and cert.001, it says "chain is good"11:45
freemangordonjonwil: did you pass -CApath to openssl s_client command?11:46
jonwilsame if I pass it 000, 001, 00211:46
jonwilyes I did pass -CApath11:46
freemangordonand it fails?11:46
jonwilOk so we have 4 certificates in this chain11:46
jonwilsupl.nokia.com11:46
freemangordonsorry11:46
jonwilSymantec Class 3 Secure Server CA - G411:46
jonwilVeriSign Class 3 Public Primary Certification Authority - G511:47
jonwilClass 3 Public Primary Certification Authority11:47
jonwilI think that there is a new version of the cert named "VeriSign Class 3 Public Primary Certification Authority - G5" in the current root CA store11:48
freemangordonyes, there is11:48
freemangordonit seems ssl tries to verify only against the first certificate in the store11:49
freemangordonand when it is the old one, it fails11:49
jonwilI think what's happening is that in the case of this particular chain OpenSSL will only verify the last CA in the chain.11:52
jonwili.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"11:54
jonwilthen it says "do I have a match for that cert in my root CA store"11:54
jonwilsince the answer is no, it says "it must be self signed then" and returns the error11:54
freemangordonbut there is a match11:55
freemangordonok, there is a cert11:55
jonwilthere is no match for the last cert in the chain in the root CA store as of the latest Mozilla certificate set.11:55
freemangordonwhy it is removed?11:56
freemangordonor it has never been there11:57
jonwilok, I am looking at maemo-security-certman now12:01
freemangordonjonwil: if we miss a certificate, how's that related to maemo-security-certman?12:03
jonwilmaemo-security-certman contains the root CA store12:03
jonwilhence why its where I need to look12:03
jonwilok, so I am looking at the last Nokia commit to this repo and I see 2 different certificates with the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 value12:07
jonwilThey have identical values for most of the fields (including issuer and subject)12:09
jonwilThe differences are a difference in the not-after date12:09
jonwiland a difference in the serial number12:10
jonwiland a difference in the signature12:10
jonwilOne uses md2WithRSAEncryption12:10
jonwilthe other uses sha1WithRSAEncryption12:10
jonwilThe one named 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem in this particular repo revision is the md2 version12:11
jonwiland the one named 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem is the sha1 version12:11
freemangordonjonwil: you're reinventing the wheel :) https://github.com/community-ssu/maemo-security-certman/commit/2cbd96e89d7529e1ce25801824fb76f39b05b83612:11
jonwilI know about that commit, I am just chasing up the entire history of the repo12:11
freemangordonjonwil: https://talk.maemo.org/showpost.php?p=1370304&postcount=12212:12
freemangordonjonwil: it might be a bug in c_rehash actually12:13
jonwilthere 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 cert12:14
jonwilThat one is what the commit you linked to is aiming to fix12:14
jonwilor rather it fixed12:14
freemangordon:nod:12:14
jonwilThe right fix is to properly fix maemo-security-certman so it orders them correctly12:14
freemangordonmhm12:15
freemangordonjonwil: so, we should add code on top of https://github.com/community-ssu/maemo-security-certman/commit/5b66292b9d705f9e9613490aafc074bfeef6a622 right?12:16
freemangordonjonwil: also, what means "orders them correctly" do we know the rule?12:16
freemangordonthe newest should become last? or what?12:17
jonwilwhat I am trying to figure out now is how it determines whether to use the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem or the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem file12:19
freemangordonmhm12:19
freemangordonbut isn't it ssl that makes the decision, not certman?12:20
*** dafox has joined #maemo12:21
*** Pali has joined #maemo12:23
freemangordonjonwil: do you have an idea *who* decides on which cert file to use?12:23
jonwilEither 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_collect12:26
jonwilmaemosec_certman_collect just returns the contents of the storage as set up by the code in maemosec_storage.cpp12:26
freemangordonjonwil: ok, it seems I am not very helpful with my question :). Will leave you digging in it as I have to run anyways12:29
freemangordon*questions12:29
freemangordongood luck, bbl12:29
*** florian has quit IRC12:32
*** xorly has joined #maemo12:37
jonwilOk so as of now Mozilla doesn't ship either version of the 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 certificate12:40
Juestohmm12:50
Juestotoo old?12:50
*** florian has joined #maemo12:54
KotCzarnyjonwil: update cert package and let sicelo test it?12:58
Juestotbh, some things should be pushed straight away13:02
Juestolike updated system certificates, etc13:02
*** xorly has quit IRC13:08
Juestominor updates that are done so the OS is up to date13:14
Juestothings that do not affect stability13:14
Juestoor usability13:14
*** mp107 has joined #maemo13:28
SiceloJuesto: certs do affect stability though :-)13:31
Juestooh really?13:32
Siceloor usabiltiy then13:33
Juestonah13:33
Juestoby usability i mean user experience13:33
Siceloit wasn't nice to need Maps, and have to wait 10 mins for GNSS fix, as A-GNSS was broken by 'new' certs13:34
JuestoOh :/13:34
Juestowell something like a timezone update13:34
Juestoisnt a big deal either13:34
Juestobut i guess certificates is a breaker13:34
Juestosorry to hear13:35
Sicelomaemo's devs are doing super good job though :-)13:36
Juestoheh13:38
KotCzarnyyou can be a dev too!13:39
Juestowho knows13:39
JuestoDepends on your talent/skill13:39
Sicelomy skills is talking too much :p13:40
Juestoyou would serve well for reporting then13:40
Juestohehe13:40
KotCzarnyyeah, maemo needs more testers13:49
*** Michael_a320 has quit IRC13:50
Juestoi wish i have a n90013:55
Juestoreally13:55
Sicelobuy usb broken one (that has not been fixed before)13:58
Sicelothen fix yourself13:59
Juestohmm, perhaps i'll just take from oksana :)14:01
Juesto(yes she lets me)14:01
JuestoAFAIK14:01
*** mp107 has quit IRC14:45
*** mp107 has joined #maemo14:45
*** florian has quit IRC14:49
*** xorly has joined #maemo14:49
*** florian has joined #maemo15:06
*** florian has quit IRC15:15
freemangordonwell, 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 it15:27
freemangordonjonwil: if neither certs are in mozilla store, then we should add it by hand15:28
freemangordonI see no other option15:28
freemangordonmaybe we should not use mozilla, but debian15:29
KotCzarnyfmg: or make a script that will repackage what's needed15:32
freemangordonmhm15:32
KotCzarnyi would trust mozilla more than debian to be honest too15:33
freemangordonKotCzarny: hmm, actually all the certs I have on my Ubuntu are from mozilla :)15:34
freemangordonso yeah, mozilla it is15:36
Juestohehe15:39
*** pagurus has quit IRC16:11
jonwilI am testing a fix now16:40
jonwilinvolving a 2-byte patch to location-proxy and installing the certificate into a separate private certificate store.16:40
jonwilthe fix works :)16:41
jonwilhttp://talk.maemo.org/showthread.php?p=1522859&highlight=00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61#post152285916:44
freemangordonjonwil: I am not sure I like the idea of binary patching the location proxy16:48
jonwilwe binary patch libsms.so for the cell broadcast stuff already16:48
jonwilthats in CSSU16:48
*** dafox has quit IRC16:48
freemangordonthat doesn;t mean I like it :). however, see:16:48
freemangordonwhat 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 finish16:49
freemangordonthose 2 certs been there forever a month more will not do that much harm16:50
freemangordonif any16:50
freemangordonjonwil: ^^^?16:51
jonwilexcept the whole point of keeping the root CA store up to date is to not ship insecure broken certs using insecure broken cryptography16:51
freemangordonhow's that related?16:51
freemangordonthat we'll use those 2 presumably broken certs for a month or so?16:52
freemangordonjonwil: also, I don;t get it why lokation-proxy fails while openssl does not16:53
freemangordon*location-proxy16:53
freemangordonwhat is this special thing it does that makes it fail?16:54
freemangordonjonwil: any idea? ^^^16:55
jonwilno idea16:55
freemangordonbecause this is the actual problem imo. I tested openssl tu supl.nokia.com on my Ubuntu and there is no problem16:56
freemangordon*to16:56
*** M4rtinK has joined #maemo16:56
*** florian has joined #maemo16:58
jonwilThe 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 command17:15
jonwilsince openssl doesn't read certman.common-ca, it just uses whatever is in the passed in capath17:16
freemangordonjonwil: read it again - it doesn't fail *on my Ubuntu*17:16
jonwilYour ubuntu must also be shippnig the cert17:17
jonwilfor some reason17:17
freemangordonit ships the mozilla stuff17:17
jonwilwhat does the certificate chain look like on your ubuntu install?17:17
freemangordonjust a second17:17
jonwiland what openssl version is it?17:17
jonwilIts 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"17:18
freemangordonjonwil: well, lets identify it and port it to maemo then17:20
freemangordonjonwil: http://pastebin.com/EZcxfFjp17:20
jonwilWhat's the contents of /etc/ssl/certs/?17:21
freemangordonit is huge17:22
freemangordonlots of files there17:22
freemangordondo you want me to pastebin it?17:22
jonwilyes please do17:22
freemangordonok17:22
freemangordonjonwil: http://pastebin.com/b3WHxKk317:24
*** cyphase has quit IRC17:25
jonwilCan you pastebin Verisign_Class_3_Public_Primary_Certification_Authority.pem?17:26
jonwilI bet it (or Verisign_Class_3_Public_Primary_Certification_Authority_2.pem) will be the certificate from the chain17:26
jonwilthe self-signed one17:26
freemangordonit is a link to /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt so I'll pastebin the .crt file17:27
jonwilok17:27
freemangordonjonwil: http://pastebin.com/acjQ3EgK17:27
jonwilyep, just as I suspected, its exctly the root CA in question17:28
jonwilthe one with the outdated crypto17:28
jonwilthe one in the chain from supl.nokia.com\17:29
jonwiland no I dont know why its on your Ubuntu system in that place17:29
jonwilyou would have to ask the maintainer of whatever package claims ownership of the relavent files...17:29
freemangordonwell, if it is good enough for my Ubuntu, it is good enough for my Maemo as well :)17:29
freemangordonI don;t really see what is the problem with that certificate, besides weak hash17:30
*** cyphase has joined #maemo17:30
freemangordonMaintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> :)17:31
jonwilIts 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 now17:31
freemangordon1024 bit RSA is weak? O.o17:32
freemangordonjonwil: who told you that?17:32
*** louisdk has joined #maemo17:35
KotCzarnyhttps://supportforums.cisco.com/discussion/11320131/https-ssl-certificate-signed-using-weak-hashing-algorithm17:36
jonwilThe 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 browsers17:37
jonwilAnd there was a big effort to get all the old certificates retired17:37
jonwilincluding the VeriSign one at the heart of this discussion17:37
KotCzarnyfmg, see the description there and it has more reading too if you want to pursue further details17:37
jonwilThat discussion means nothing in the context of this discussion17:38
KotCzarnyit describes why weak hashing algos are bad17:38
jonwilThere is nothing wrong with the hashing algorithm of the certificate in question since its a root CA17:38
*** agomez{M} has quit IRC17:38
KotCzarnyand why it's bad to have such CAs17:38
freemangordonsee, as part of my job I am dealing with PCI-DSS stuff on a regular basis, so I have a clue17:38
jonwilin this case we are interested in why 1024-bit RSA is bad17:39
freemangordonyes, exactly17:39
*** platicus has quit IRC17:39
jonwiland why shipping a cert in the root CA store that has a 1024 bit public key is bad17:39
freemangordonjonwil: but, this is when it omes to new certificates17:39
jonwilIf 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 them17:39
freemangordon*comes17:39
jonwilAll of them got rid of 1024 bit certificates17:39
jonwiland no 1024 bit certificates (old, new or otherwise) will be treated as trusted by any of the major browsers in whatever version it is17:40
freemangordonjonwil: ever thought that it is all about the money?17:40
freemangordonthere is no evidence so far that 1024 bit RSA was ever broken17:41
KotCzarny..yet17:41
freemangordonyes, yet17:41
freemangordonjonwil: and I bet all the stable releases of all the major distribution have the certificate in question included17:42
freemangordon*distributions17:43
freemangordonso, lets not overengineer Maemo and let simply include that(those) certificate(s)17:43
DocScrutinizer05NSA will crack them easily ;-)17:46
freemangordonfrom 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.17:46
KotCzarny:)17:47
DocScrutinizer05or that, yes17:47
KotCzarnyfmg, what if they are crackable by invering in big farm?17:47
freemangordonDocScrutinizer05: I doubt breaking RSA can be kept secret for long17:47
freemangordonKotCzarny: no way17:47
KotCzarnyin similar way there are 'sploits running on black market17:48
KotCzarnyso maybe there is such black farm or more than one?17:48
freemangordonKotCzarny: afaik, anything > 512 is not feasible17:48
*** agomez{M} has joined #maemo17:48
freemangordonor maybe anything > 76817:48
DocScrutinizer051024 sounds *very* long, didn't they crack 56bit or sth, with distributed computing, in years?17:49
freemangordonyou know, exponential17:49
DocScrutinizer05yeah17:50
jonwilEven the long term stable versions of browsers like firefox have removed the 1024 bit certificates.17:50
DocScrutinizer05but how do *we* care about that?17:50
DocScrutinizer05for supl17:51
freemangordonDocScrutinizer05: the same certs are used17:51
freemangordonfor supl and www17:51
DocScrutinizer05yes, and aiui Nokia didn't update their supl cert17:51
jonwilmy point is that there IS a way to store the certificate so that it can be used by location-proxy but not by anything else17:51
*** platicus has joined #maemo17:51
DocScrutinizer05so should we, simply don't touch it17:51
freemangordonjonwil: doesn;t make sense, that cert anyway expires in 3 months17:52
DocScrutinizer05how900: makes sense17:52
DocScrutinizer05haha, ok then not17:52
DocScrutinizer05damn, jonwil^^^ - sorry how90017:53
DocScrutinizer05let's take bets what gonna gappen to Nokia SUPL in 3 months?17:54
DocScrutinizer05happen*17:54
KotCzarnyo.o17:54
*** Eezer has joined #maemo17:54
freemangordonNot After : May 15 23:59:59 2017 GMT17:54
freemangordon:)17:54
DocScrutinizer05you rather find a way to convince proxy(?) to use an expired cert17:54
KotCzarnyoh so much less traffic17:54
freemangordonthay'll fix it, all symbian devices depend on that as well17:55
KotCzarnywinwin17:55
DocScrutinizer05ooh17:55
DocScrutinizer05I don't know17:55
KotCzarnybut how would they redistribute it?17:55
freemangordonKotCzarny: distribute?!?17:55
freemangordonthis is server cert17:55
DocScrutinizer05they might not be interested in sybian anymore17:55
KotCzarnyarent ca certs part of os?17:56
freemangordononly root ones17:56
DocScrutinizer05and maybe symbian doest't care about cert expiry?17:56
freemangordonno way17:56
freemangordonthey were in the same shit as maemo when the old cert expired17:56
freemangordonthe current one is "Not Before: Feb 18 00:00:00 2016 GMT"17:57
jonwilThe root problem is that supl.nokia.com sends an obsolete VeriSign root certificate as part of its certificate chain17:57
jonwilwhy they send that obsolete certificate I haven't a clue17:57
freemangordonjonwil: could you find the mozilla bug for removing that certificate?17:57
KotCzarnyfmg, that would be probably part of the remove 1024 certs17:58
jonwilhttps://bugzilla.mozilla.org/show_bug.cgi?id=986005 is the bug where the root certificate in question was removed17:59
povbotBug 986005: was not found.17:59
jonwilor where the decision to remove it was made anyway17:59
jonwilit ultimately got removed in https://bugzilla.mozilla.org/show_bug.cgi?id=102196717:59
povbotBug 1021967: was not found.17:59
*** Eezer has quit IRC18:01
DocScrutinizer05((<jonwil> why they send that obsolete certificate I haven't a clue)) you _really_ need to guess on _why_ here?18:01
DocScrutinizer05simply same reason why maemo keys expired and thus locked nokia out to update them18:02
DocScrutinizer05nokia NEVER got cert stuff right18:02
freemangordonbecause they use some symantec intermediate which has that verisign cert in its chain18:02
freemangordonanyway, IMO we should just include those 2 until 15th of May comes and see what certificate, if any will be used after18:04
DocScrutinizer05exactly18:04
freemangordonin 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 security18:05
freemangordonjonwil: ^^^18:05
freemangordonwhat do you think18:05
DocScrutinizer05or we use jonwil's 2byte patch until you're ready then ;-)18:06
DocScrutinizer05in 3 months18:06
freemangordonthis is too hackish to my taste18:06
DocScrutinizer05oh, I love that when we have no source18:07
DocScrutinizer05did it in mce and it vanished a 4 times now18:07
*** at1as has joined #maemo18:07
bencohREed location-proxy would be great anyway18:10
jonwilI think I see whats going on18:16
jonwilWe have the certificate for supl.nokia.com18:17
jonwilthe parent of that is the Symantec Trust Network certificate18:17
freemangordonyes18:18
jonwilthen there exist 2 possible parents for that one18:18
freemangordonand it is signed by verisugn cert18:18
jonwilThe first one is what is in the current Mozilla cert set18:18
jonwilThat first one is itself a root CA18:18
jonwiland trusted by Mozilla at this point18:19
jonwilThe second parent for the Symantec cert has identical keys and things but is NOT a root CA18:19
DocScrutinizer05oh?18:19
jonwilIts the third certificate in the chain that supl.nokia.com returns18:20
jonwilThat one chains up to the old "Class 3 Public Primary Certification Authority"18:20
*** clopez has quit IRC18:21
jonwilMy 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 certificate18:22
jonwilSo Nokia has to make supl.nokia.com return a certificate chain that those old devices will trust18:22
DocScrutinizer05of course, yes. sounds 100% plausible to me18:22
freemangordonmakes sense18:22
jonwilwhich means it needs the special "VeriSign Class 3 Public Primary Certification Authority - G5" certificate that isn't a root certificate itself18:22
KotCzarnyi wonder why bother with ssl at that point18:23
DocScrutinizer05in the end it's the maintainer of the cert cache who decides what's a trusted root cert18:24
jonwilThe 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 hypothesis18:24
*** clopez has joined #maemo18:24
freemangordonjonwil: what will happen if we leave only the new cert in the store?18:24
freemangordonaren't both old and new 1024 bit?18:25
jonwilnope18:25
freemangordonah18:25
DocScrutinizer05the new isn't used by the old SUPL?18:25
jonwilWe have a certificate for supl.nokia.com with a 2048 bit key18:25
jonwilWe have the18:25
jonwilthe Symantec Trust Network cert with a 2048 bit key18:26
freemangordonso we should remove 1024bit simatec?18:26
freemangordon*symantec18:26
freemangordonor, what shall be done?18:26
jonwilWe have both versions of the VeriSign Class 3 Public Primary Certification Authority - G5 cert with an identical 2048 bit key18:26
jonwilThen we have the Class 3 Public Primary Certification Authority with the 1024 bit key18:26
jonwilThe certificates currently in maemo-security-certman repo are all fine18:27
jonwilIts what we should be shipping at this point18:27
freemangordonmaybe we should just reorder them, so the stronger cert to be used?18:27
freemangordonthe same what I did before?18:28
jonwilno18:28
freemangordonI am lost :)18:28
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 cert18:28
jonwilyeah18:28
jonwilThe 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 list18:29
freemangordonah, I see18:29
jonwili.e. VeriSign has said "do not ship that cert going forward"18:29
DocScrutinizer05the links are bottom-up by the attached signatures which point to the parent cert18:29
jonwilHence my suggestion to put that one cert that we need into the private certificate store just for location-proxy18:30
jonwilactually, I just thought of a possible fix that doesn't involve patching location-proxy18:30
jonwilLet me try something18:30
DocScrutinizer05I never heard how a cert could have two parent certs though of course it's logically possible18:30
freemangordonenv var?18:30
jonwilno18:31
DocScrutinizer05why don't we simply trust the SUPL cert itself, so we don't need to care about any friggin broken parent/root certs?18:32
freemangordonjonwil: maemosec_certman_collect("location-proxy", 1, my_cert_store); ?18:33
jonwilyeah thats it18:33
jonwilThe patch was to change the 1 into an 018:33
bencoh18: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?18:33
jonwilbut I found a way to avoid the need to do that18:33
bencoh+118:33
*** platicus has quit IRC18:33
bencohstill need to make sure trusting this cert doesn't mean trusting every cert signed by it18:33
*** agomez{M} has quit IRC18:34
freemangordonbencoh: supl cert cannot be used for signing anyways18:34
bencohwhy?18:34
freemangordonbecause it cannot, it is neither root nor ntermediate18:34
bencohhuh?18:34
jonwilFrom 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)18:35
KotCzarnywhat if they (or mitm) start sending something else?18:35
jonwili.e. if we added the cert for supl.nokia.com to the root CA store, openssl will never even see it18:35
jonwilIt 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 store18:36
DocScrutinizer05bencoh: aiui cert have certain pirposes what they can be used for, you can set this while creating them18:36
jonwilAnd yes the cert for supl.nokia.com doesn't have the flags set to allow it to be used to sign other certs18:37
jonwilanyhow, let me try the idea I have for loading the root cert in a way location-proxy can use it but other things cant18:37
bencohDocScrutinizer05: the fact is I dont remember doing anything special when generating (custom) CAs, but maybe18:37
jonwiland if that works we can ship that in another maemosec-certman-common-ca update and not need to patch lication-proxy at all18:38
jonwillocation-proxy18:38
*** dafox has joined #maemo18:38
freemangordonbencoh: http://pastebin.com/HrmRetbm18:38
jonwilnot need to patch it nor need to do anything special when updating the regular root CA store from the mozilla cert store18:39
freemangordonbencoh: "   TLS Web Server Authentication, TLS Web Client Authentication"18:39
*** geaaru has quit IRC18:40
*** agomez{M} has joined #maemo18:41
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 store18:41
jonwilno need for messing with that18:41
jonwilThe fix I have requires no patching to location-proxy18:42
*** platicus has joined #maemo18:42
DocScrutinizer05that's not messing, that's the simplest approach for a cert that expires in 3 months18:42
jonwilAll 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 it18:42
freemangordonmhm18:43
DocScrutinizer05yes, obviously18:43
freemangordonin location-proxy domain18:43
jonwilIts an easy job and assuming my test works I will do that myself18:43
jonwilyes location-proxy domain18:43
KotCzarnydo it, test it, yay for teamwork!18:43
bencohfreemangordon: oh, okay18:45
jonwilTime to reboot my phone for the billionth time today :)18:46
freemangordonreboot? why?18:47
jonwilto get the right location-proxy binary loaded and running :)18:47
freemangordonah18:47
freemangordon:)18:47
sixwheeledbeastI have no idea about certs but is it definitely the cert at fault? as per Pali's post on TMO.18:53
sixwheeledbeasthttp://talk.maemo.org/showpost.php?p=1522878&postcount=24218:56
*** at1as has quit IRC18:56
freemangordonjonwil: iiuc, we just need /etc/certs/location-proxy with the certs in there and /etc/secure/location-proxy with the hashes, right?18:58
jonwilyeah I am updating maemo-security-certman now18:59
jonwilwith the right bits18:59
freemangordoncool18:59
freemangordondid it work?18:59
jonwilbuilding new packages now19:01
jonwilthen I will test it on my phone19:01
freemangordonok19:01
*** at1as has joined #maemo19:01
jonwilunpacking new package on my phone then I test it19:05
*** Vajb_ has joined #maemo19:05
*** Vajb has quit IRC19:05
*** at1as has quit IRC19:06
jonwilhelps if I update the correct debian packaging so it will pull the right files in19:08
*** Oksanaa has joined #maemo19:10
OksanaaStrongly recommend https://github.com/Unode/firefox_decrypt for recovering forgotten passwords from MicroB. Unless there is a better one somewhere?19:11
OksanaaWorks with python2.7 ^19:11
*** louisdk has quit IRC19:15
JuestoPassword manager?19:17
Juestointeresting19:17
jonwilThe fix is up19:17
jonwilThe latest maemo-security-certman contains all the right bits19:17
jonwilas of 0.2.9 supl will work 100% with supl.nokia.com19:18
jonwilSomeone should probably stick 0.2.9 into the appropriate repos19:19
jonwilso everyone can get it19:19
jonwilI 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 :)19:21
Oksanaa:)19:21
KotCzarnysicelo: ^^^19:22
KotCzarnyjonwil: that's what scripts are for19:22
jonwil:)19:22
KotCzarnyand always were, even in middle ages19:23
KotCzarnyi wouldnt remember how to upload to extras if i didnt made the scripts19:23
*** platicus has quit IRC19:23
Oksanaamake*19:23
KotCzarny:)19:23
*** agomez{M} has quit IRC19:24
*** Oksanaa has left #maemo19:24
KotCzarnyto  be completely correct it should be: haven't made19:24
freemangordonjonwil: I will do it either later today or tomorrow19:24
jonwilnice :)19:24
freemangordonoh, you fixed changelog as well, great19:25
jonwilanyhow, its a nice elegant fix in the end (thanks to Nokia already using the location-proxy domain for certman)19:26
freemangordon:nod:19:27
freemangordonway better than patching the binary19:27
*** mp107 has quit IRC19:28
jonwilyeah I miss-understood what the code was doing19:29
jonwilbut then I figured it out19:29
*** louisdk has joined #maemo19:31
jonwilNow that we fixed this there is no reason for a location-proxy clone19:31
jonwilWe dont need one for Neo900 or other platforms either19:31
freemangordonwe need, for x86-6419:32
freemangordonbut there is no hurry19:32
*** platicus has joined #maemo19:32
jonwilno we dont, its only ever useful for a device with the N900 GPS chip19:32
jonwilit makes direct calls to liblas (low level interface to n900 bb5 gps chip)19:32
freemangordonnot sure, n900 supports BT GPS as well19:33
jonwilfor x86 or other platforms we just need to replace/clone/substitute liblocation19:33
freemangordonah, ok19:33
jonwiln900 BT GPS doesn't do supl19:33
freemangordonyep, right19:33
*** agomez{M} has joined #maemo19:33
jonwilwith the fix in place I can get <50m accuracy even with the N900 sitting on my desk in my apartment19:36
jonwiland picking up 10 or more sats with many in use19:36
jonwiland maps locks on no problems19:37
jonwilnow maps is useful again :)19:37
KotCzarnyyay?19:38
KotCzarnyi should update to cssu one day19:38
jonwilok, its nearly 4am here and I should probably get some zzz :)19:41
jonwillater :)19:41
*** jonwil has quit IRC19:41
Juestogreat19:44
Juestox86 first freemangordon19:45
*** agomez{M} has quit IRC20:04
*** platicus has quit IRC20:04
DocScrutinizer05((We dont need one [location-proxy] for Neo900 or other platforms either)) good call. need quite some discussion in devel peergrpup20:04
DocScrutinizer05oh, seems you covered it comprehensively20:05
*** agomez{M} has joined #maemo20:13
*** platicus has joined #maemo20:15
*** platicus has quit IRC20:44
*** agomez{M} has quit IRC20:44
*** agomez{M} has joined #maemo20:54
*** platicus has joined #maemo20:54
*** at1as has joined #maemo21:04
Sicelolet'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? ///21:15
Siceloi'll test 0.2.9 shortly :)21:15
*** at1as has quit IRC21:16
SiceloOksana: MicroB supports the 'address' *chrome://passwordmgr/content/passwordManager.xul*21:18
Siceloso no need for any script21:18
bencohooh, good to know21:20
Sicelo:-)21:22
Siceloof course it also means someone can steal your passwords too21:23
bencohindeed21:23
*** platicus has quit IRC21:24
Sicelobut even on my pc, the same thing applies ..21:24
*** agomez{M} has quit IRC21:24
bencohunless you use a master password21:26
Siceloah yes21:26
*** platicus has joined #maemo21:35
*** agomez{M} has joined #maemo21:35
Sicelojonwil didn't share 0.2.9 yet, did he?21:46
KotCzarnyhe have said something about being late and not thinking straight21:47
KotCzarny*has21:47
Sicelocool .. i'm in no rush .. 0.2.3 doing the job good enough for present needs21:47
*** xorly has quit IRC21:50
*** xorly has joined #maemo21:58
*** eMHa__ has quit IRC21:58
*** agomez{M} has quit IRC22:01
*** platicus has quit IRC22:02
*** dafox has quit IRC22:08
DocScrutinizer05Sicelo: you're aware Nokia basically is no more?22:12
*** platicus has joined #maemo22:12
*** spiiroin has quit IRC22:13
*** agomez{M} has joined #maemo22:14
DocScrutinizer05so >>they will most likely fix it .. they always have ..<< doesn't exactly sound right22:14
DocScrutinizer05particularly second half is incorrect22:14
DocScrutinizer05Nokia 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' fix22:16
Paliyes, they failed to resign nokia ssu apt repos with /correct/ pgp key22:17
DocScrutinizer05so no, absolutely not >>they always have ..<<22:17
Palieven they got instructions how...22:17
DocScrutinizer05they even are notorious for their simple HTTPS certs expiring before they bother about renewal22:19
Sicelowhen did those expired?22:20
Sicelobut 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't22:21
Sicelomaybe 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)22:23
Sicelos/have to/could eventually/22:24
infobotSicelo meant: maybe jonwil will could eventually 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)22:24
DocScrutinizer05any citation for any of that?22:24
Sicelocitation for?22:24
DocScrutinizer05any of that22:25
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 clone22:26
Siceloheh ... aren't we talking about what *might* happen when the cert finally expires?22:26
*** spiiroin has joined #maemo22:26
bencohapart from reducing the number of blobs in the porting process22:27
DocScrutinizer05[2017-02-05 Sun 18:31:51] <jonwil> We dont need one for Neo900 or other platforms either22:27
Sicelo... yes .. but the cert expires in May .. there won't be a Neo900 then22:28
DocScrutinizer05how's that related?22:28
* Sicelo doesn't get what DocScrutinizer05 is on about22:28
DocScrutinizer05did you get what jonwil said?22:28
Siceloyes22:28
DocScrutinizer05or how his patch works?22:28
Siceloyes to that too22:29
DocScrutinizer05so why do you think he's incorrect about no need for RE of location-proxy?22:29
Siceloi don't think that ..22:30
DocScrutinizer05o.O22:30
DocScrutinizer05sorry, I'm roo wasted from flu to continue this discussion22:31
DocScrutinizer05too*22:31
Siceloi'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 us22:31
Siceloyeah you need some rest :)22:31
DocScrutinizer05don't you tell me what I need22:31
DocScrutinizer05I also can't recall maemo per se had issues with supl.google.com22:32
*** platicus has quit IRC22:34
Sicelowell there are .. http://talk.maemo.org/showthread.php?p=1468151#post146815122:34
*** agomez{M} has quit IRC22:35
DocScrutinizer05hmm22:37
DocScrutinizer05anyway I guess it's maybe time for a supl.maemo.org service22:37
Sicelothat'd be nice .. i think someone suggested that (Ulle)22:38
DocScrutinizer05O mean, it's a pathetic 5kB of data basically22:38
DocScrutinizer05I*22:38
DocScrutinizer05we just need a GPS chipset that allows download of the almanac from sats and storing that almanac to a file22:39
DocScrutinizer05alternatively we need a data source of almanac in the intarwebs22:40
Sicelomaybe run a supl server on the N900 itself .. wonder how good/bad that would be22:41
DocScrutinizer05https://www.navcen.uscg.gov/?pageName=gpsAlmanacs maybe?22:41
bencohSicelo: not on n900 then22:42
DocScrutinizer05Sicelo: err what?22:42
bencoh(as DocScrutinizer05 said actually)22:42
Sicelook22:44
DocScrutinizer05http://git.osmocom.org/osmocom-lcs/ along that line maybe22:44
*** agomez{M} has joined #maemo22:45
DocScrutinizer05uBlox chipset allows downloading eph and alm from GPS, after receiving it from SVs22:46
*** platicus has joined #maemo22:47
DocScrutinizer05actually 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?22:47
DocScrutinizer05maybe even support for geolocation bnased on BTS cellIDs seen, AP names etc?22:48
bencohboth iirc yeah22:48
*** louisdk has quit IRC22:48
bencohhm no cellid-based geoloc doesn't depend on supl afaiu22:48
bencohbut supl client can choose to get eph in addition to alm22:49
DocScrutinizer05well, 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 data22:49
bencohthere is a commandline supl client available in extras-devel22:49
bencohabsolutely22:50
bencohand there is already an opensource supl proxy implementation out there22:50
DocScrutinizer05:-)22:50
bencohnot ready for production though, but still handy22:50
DocScrutinizer05so go ahead hackers! hack that stuff into shape and let our brilliant techstaff run it on maemo servers :-)22:51
DocScrutinizer05excellent task. very convenient testing on your own local infra, until it goes productive22:52
SiceloOT: what is a good kmz viewer for Linux?22:54
bencohI suppose marble reads kmz22:54
Sicelooh wow .. should look at that22:55
bencohsomeone recently ported gpxsee to maemo22:56
DocScrutinizer05I just fail to believe there's no official source for current almanac data from gps.gov or whatever22:58
bencohDocScrutinizer05: well ... :)22:59
DocScrutinizer05sure, maybe you need to ask for them sending it in an email, or whatever hoops they may invent to avoid DDoS attacks22:59
bencohthey probably wont provide it either23:00
DocScrutinizer05bencoh: almanac is prolly the most widespread ubiquitous data available via RF on this globe23:00
DocScrutinizer05can't think of any sane reason why it wouldn't be avaolable via internet too23:01
bencohit's available through supl servers23:02
DocScrutinizer05yes, and where from those get it?23:02
bencohgps23:02
DocScrutinizer05no way23:02
DocScrutinizer05that's insane23:02
bencohwanna bet? :p23:02
DocScrutinizer05not really, need my rear for other things ;-D23:03
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)<<23:07
DocScrutinizer05https://www.navcen.uscg.gov/?pageName=currentAlmanac&format=yuma-txt23:08
*** agomez{M} has quit IRC23:09
*** platicus has quit IRC23:09
DocScrutinizer05bencoh: really bet now? ;-)23:10
DocScrutinizer05https://www.navcen.uscg.gov/?pageName=currentAlmanac&format=sem-txt23:10
bencohhuhu, nice :)23:11
bencohand https://igscb.jpl.nasa.gov/components/prods_cb.html23:11
DocScrutinizer05ugh, what's that? a historical log?23:13
bencohnot really23:13
DocScrutinizer05Final: 12 days latency; Rapid: 17h;  UltraRapid; 8h23:14
bencohwell, kindof23:14
bencohyeah23:14
bencohnot "historical" but yeah23:14
DocScrutinizer05I'm not really interested in almanac or ephemeral of 13 days ago23:14
DocScrutinizer05UltraRapid *might* be useful, with 8h delay and 48h validity span23:15
DocScrutinizer05umm nope, 24h future, 24h past23:16
DocScrutinizer05and they are 4 times a day, so 6h delay23:16
DocScrutinizer05those are derived AIUI, (see "24h past from observation") so if not even NASA has a way to download that shite from internet... :-S23:17
*** platicus has joined #maemo23:19
*** agomez{M} has joined #maemo23:22
DocScrutinizer05http://www.igs.org/products/data >>IGS Ultra-rapid products (IGU)23:24
DocScrutinizer05To 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 the23:24
DocScrutinizer05average 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<<23:24
*** lxp has joined #maemo23:25
DocScrutinizer05the sat positions are with a precision <100cm :-)23:26
DocScrutinizer05>>Geocentric Coordinates of IGS Tracking Stations -- Final velocities: Accuracy horizontal 2 mm/yr   vertical 3 mm/yr<<  :->23:32
DocScrutinizer05hmmmm  ftp://ftp.igs.org/pub/gps/193523:40
*** Milhouse has quit IRC23:41
*** agomez{M} has quit IRC23:44
*** platicus has quit IRC23:44
DocScrutinizer05what 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.txt23:46
KotCzarnyman compress23:46
*** Milhouse has joined #maemo23:52
*** agomez{M} has joined #maemo23:55
*** platicus has joined #maemo23:55
DocScrutinizer05gzip -dkvc <(wget ftp://ftp.igs.org/pub/gps/1935/igu19350_18.sp3.Z -O -)|less23:57

Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!