**** BEGIN LOGGING AT Tue Dec 29 02:59:58 2015 Dec 29 08:31:16 meh, jonwil is offline again Dec 29 08:33:56 anyway, some of the work (porting / tracking patches) has been done for 0.9.8zf: Dec 29 08:34:03 http://repository.maemo.org/community-testing/pool/fremantle/free/source/o/openssl/ Dec 29 08:34:15 it might be a good start Dec 29 08:46:46 moin :) Dec 29 09:36:29 ttp://talk.maemo.org/showthread.php?p=1492874#post1492874 Dec 29 09:38:38 ceene: does openssl s_client work btw? Dec 29 09:39:35 i don't know yet Dec 29 09:45:49 IIRC our version of 0.9.8n is actually 0.9.8n with 0.9.8o patches applied Dec 29 09:46:11 from the changelog it's in fact 0.9.8zf :/ Dec 29 09:46:23 it's quite complex all this Dec 29 09:46:29 but i think there are no maemo patches Dec 29 09:46:36 except for thumb support, which i've just added Dec 29 09:48:13 openssll s_client works ok Dec 29 09:49:42 I remember compiling the list of CVE patches applied between 0.9.8o - 0.9.8z. Dec 29 09:50:09 The idea then was to backport due to ABI incompatibilities Dec 29 09:50:19 ceene: it is, in -testing Dec 29 09:50:53 I dont really understand why jonwil doesnt use apt-get source Dec 29 09:51:05 yeah, that's what i do Dec 29 09:51:13 most of the time at least Dec 29 09:54:38 ah this was the thread http://talk.maemo.org/showthread.php?t=93296 Dec 29 09:56:42 i've just eedited my post with what i think is the difference between maemo and debian versions Dec 29 09:56:48 that is only packaging, not code Dec 29 10:04:01 sixwheeledbeast: there's no ABI incompatibility :\ Dec 29 10:04:04 if there is, it's a bug Dec 29 10:05:27 as far as we could tell, there was none indeed Dec 29 10:08:54 what i don't think is doable is patching theclosed source bits to use new openssl Dec 29 10:09:46 We dont necessarily need to patch them Dec 29 10:09:49 how new Dec 29 10:09:50 ? Dec 29 10:10:00 we could live with two openssl versions i guess Dec 29 10:10:00 they'll happily use openssl 0.9.8zh or whatever the latest 0.9.8 is Dec 29 10:10:12 i don't think any one of us wants to write an openssl shim Dec 29 10:10:18 nope Dec 29 10:10:26 There is no reason we cant have both 0.9.8zh or whatever it is for the closed source bits and also 1.0.2 for all the FOSS bits Dec 29 10:10:34 indeed Dec 29 10:10:50 that's the way then Dec 29 10:10:59 as for what we have, CSSU is using 0.9.8zf Dec 29 10:11:21 little by little the closed bits should be getting RE if at all possible and rewritten using new libs and whatever Dec 29 10:11:25 I am only recalling the thread from last time. Dec 29 10:11:27 but that's far away i think Dec 29 10:11:47 but stock is 9.8.8n-1 from Debian with some local changes Dec 29 10:12:24 cssu is on zf Dec 29 10:12:35 and no further change was done Dec 29 10:12:49 no need to work on top of 0.9.8n Dec 29 10:14:08 If I can find the upstream Debian 0.9.8n-1 source, I can figure out exactly whats different between openssl 0.9.9n-1 from Debian and openssl 0.9.8n-1+maemo4+0m5 from Fremantle and then we can identify which of those Maemo-local changes actually matter and need to be somehow handled for any new 1.x.whatever port we may do Dec 29 10:14:15 CSSU is " Dec 29 10:14:37 cssu testing is zf, stable is still 0.9.8n-1. Dec 29 10:14:40 jonwil: fmg already "ported" those patches to zf Dec 29 10:14:44 CSSU is 0.9.8zf with bits from Debian 0.9.8n-1 and bits from Maemo 0.9.8n-1+maemo4+0m5 Dec 29 10:14:48 I know its been ported to zf Dec 29 10:14:57 so why bother with n? Dec 29 10:17:48 I want to know exactly what is different between stock Maemo PR1.3 OpenSSL and upstream Debian OpenSSL (ignoring whatever may have been done in CSSU). That information will confirm once and for all which of the changes Nokia made on top of upstream Debian are necessary in some way for Maemo (and which are just e.g. back-ports from OpenSSL > 0,9.8n or otherwise are no longer necessary with... Dec 29 10:17:49 ...the latest OpenSSL) Dec 29 10:18:46 jonwil: does it really matter? Dec 29 10:19:00 i mean, if we're going to stick with the old version for the closed source bits Dec 29 10:19:17 and we're gonna try to port open source apps to use the new lib Dec 29 10:19:28 ceene: no, we're going to "stick with" the latest openssl 0.9.8 version Dec 29 10:19:29 why do we care what was done for things that we're not going to touch? Dec 29 10:19:32 because bugs are things that exist Dec 29 10:19:48 even if nokia did some changes to openssl Dec 29 10:19:51 do we want them? Dec 29 10:20:06 i mean... it's not like openssl is something that should ever be touched without a stick Dec 29 10:20:31 I'm not even sure we'd want any 3rd-party patch, considering history :* Dec 29 10:20:37 (hey debian, we're looking at you) Dec 29 10:20:39 my guess is if they did something, chances are they are for worse Dec 29 10:20:49 yeah, that's what i'm saying :) Dec 29 10:21:06 i trust debian more than the nokia guys on this thing, and look at what debian did Dec 29 10:21:25 btw, iirc the 12_valgrind.patch we have isn't the harmful debian one Dec 29 10:21:37 but we should check chanlogs Dec 29 10:21:51 that patch is still on debian sid Dec 29 10:21:57 yeah Dec 29 10:22:07 so i don't think that's the bad one Dec 29 10:22:23 that's what we thought back then as well Dec 29 10:22:39 really, touching a library like openssl without very profound knowledge of what you are doing doesn't look like a good idea Dec 29 10:22:57 i know that i am not able to understand or asses what risks a little change might pose in ssl Dec 29 10:23:35 Specifically I am looking at 22_openssl_psk_0.9.8n-lib.dpatch for example, its a Nokia patch (its full of Nokia copyrights) and its adding something we might actually need (PSK cypersuites) Dec 29 10:23:48 thats just an example of something Nokia added that we may somehow need to care about Dec 29 10:24:23 oh, if that's added functionality then there's little workaround about that :/ Dec 29 10:24:59 Looks like https://launchpad.net/debian/+source/openssl/0.9.8n-1 is the source I want actually :) Dec 29 10:25:18 freemangordon: looks like that patch for "/revision" DT entry will not be accepted and Arnd want to see that ATAG_REVISION will be parsed in that your hook where is save_atags Dec 29 10:25:28 that's what i thought, yes Dec 29 10:25:29 freemangordon: will you extend your patch? Dec 29 10:26:39 ok, so now I will do a diff between the source from Debian and the source from Maemo and see whats different between the 2 :) Dec 29 10:30:09 wtf is a CST (20_load-cert.dpatch) ... Dec 29 10:35:57 where are the nokia patches? Dec 29 10:41:10 mixed with the others in debian/patches/ Dec 29 10:41:43 though I suspect they're the .dpatch ones :) Dec 29 10:45:52 jonwil: psk support has been added in openssl-1.0.0 Dec 29 10:46:11 ok Dec 29 10:46:45 the 2005 nokia copyright is a bit surprising Dec 29 10:48:44 well... the same copyright is present in vanilla openssl-1.0.0 Dec 29 10:49:37 and the psk code has been around in git since at least 2006 Dec 29 10:51:45 openssl commit ddac197404f585b8da58df794fc3beb9d08e8cd2, code comes from nokia Dec 29 11:00:21 hey guys, how to extract nolo from firmware image? Dec 29 11:08:32 new post made http://talk.maemo.org/showthread.php?p=1492878#post1492878 Dec 29 11:11:43 useretail: There should be a way to extract nolo via flasher-3.5 Dec 29 11:11:48 What do you want nolo for anyway? Dec 29 11:12:22 jonwil: you probably still want the CST (20_load-cert.dpatch) patch Dec 29 11:12:32 apart from that... Dec 29 11:12:45 ok, post in the thread then Dec 29 11:15:55 recently device went to reboot loop, so i'm trying to figure out how booting works Dec 29 11:16:35 how will extracting nolo help with that? Dec 29 11:17:32 i couldn't find sources for it Dec 29 11:59:02 ~bootloop Dec 29 11:59:03 i guess bootloop is when your device has broken rootfilesystem, so during reboot it fails on some service startup or kernel module load and thus reboots. This *drains* battery! And you can't reflash to stop bootloop when battery is drained. Recharge your battery by other means before reflashing. E.g. using ~rescueOS. Or external charger or BL-5J compatible other device. Dec 29 11:59:15 rule #1, charge your battery Dec 29 12:01:01 there is no source code for nolo out there btw Dec 29 12:59:18 i'm having trouble building qt4 package Dec 29 12:59:30 /tmp/N900/qt4-x11-4.7.4~git20110505+cssu11/include/QtCore/qstringlist.h:1:86: ../../../qt4-x11-4.7.4 Dec 29 12:59:33 ~git20110505\+cssu11/src/corelib/tools/qstringlist.h: No such file or directory Dec 29 12:59:34 which is false Dec 29 12:59:54 are you are you really sure? Dec 29 12:59:58 shouldn't this be straightforward? Dec 29 13:00:04 those paths can be misleading Dec 29 13:00:12 i mean, this is apt-get source'd from scratchbox Dec 29 13:00:18 it should build Dec 29 13:00:19 also, change the name of the directory from ~ to - Dec 29 13:00:22 and reconfigure Dec 29 13:00:28 yeah, i've checked Dec 29 13:00:33 apparently ~ got eaten by bash Dec 29 13:00:46 no, no, it was in the pasting Dec 29 13:00:50 that got cut out to the other line Dec 29 13:01:05 still, remove any special chars from the dir name Dec 29 13:01:13 if i go to /tmp/N900/qt4-x11-4.7.4~git20110505+cssu11/include/QtCore/, i ../../../qt4-x11-4.7.4~git20110505\+cssu11/src/corelib/tools/qstringlist.h exists Dec 29 13:01:32 but that's the name of the deb package, i mean, that should work Dec 29 13:01:35 mv /tmp/N900/qt4-x11-4.7.4~git20110505+cssu11/ /tmp/N900/qt4-x11-4.7.4_git20110505_cssu11/ Dec 29 13:01:37 and redo Dec 29 13:01:52 you may try using bash instead of bb shell Dec 29 13:03:28 same thing Dec 29 13:03:57 also, the error comes from gcc Dec 29 13:04:14 so shell shouldn't matter Dec 29 13:04:38 why would gcc print an escaped +? Dec 29 13:04:46 "~git20110505\+cssu11" Dec 29 13:05:36 dunno Dec 29 13:06:20 ceene, did you reran ./configure ? Dec 29 13:06:33 and the error msg should be different then Dec 29 13:06:57 i'm trying to build the whole package, so i use dpkg-buildpackage Dec 29 13:07:14 that's what the autobuilder is supposed to do Dec 29 13:07:17 check if patches do something weird Dec 29 13:07:20 get the source code and inke dpkg-buildpackage Dec 29 13:07:26 hardcoded stuff etc Dec 29 13:07:34 s/inke/invoke/ Dec 29 13:07:34 ceene meant: get the source code and invoke dpkg-buildpackage Dec 29 13:09:14 i'm gonna remove the + Dec 29 13:09:27 jonwil: those Nokia patches were never upstreamed iirc Dec 29 13:09:34 (openns that is) Dec 29 13:09:38 *openssl Dec 29 13:09:50 and we need them for the supl servers Dec 29 13:10:23 jonwil: BTW I think it is better to look in CSSU openssl, not in the stock Dec 29 13:15:28 i've had to edit the debian/changelog and replace the + with a - Dec 29 13:15:34 Which nokia patches? Dec 29 13:15:47 ceene, does it compile now? Dec 29 13:15:51 freemangordon: which one? Dec 29 13:16:03 *psk* ones Dec 29 13:16:08 they were Dec 29 13:16:15 bencoh: upstreamed? Dec 29 13:16:17 i can understand that some script is buggy, but i don't understand how is this compiled by the autobuilder Dec 29 13:16:24 freemangordon: yeah, see TMO Dec 29 13:16:32 KotCzarny: not yet, but it's gonna compile once i finish renaming these things Dec 29 13:16:34 https://git.openssl.org/?p=openssl.git;a=commit;h=ddac197404f585b8da58df794fc3beb9d08e8cd2 is the upstream commit for the PSK patches Dec 29 13:16:47 ceene, maybe it uses different shell/env Dec 29 13:17:13 didnt know we need it for supl though, thx for the info :) Dec 29 13:17:28 wait, what? 2006?!? Dec 29 13:17:36 yeah, kinda ... old Dec 29 13:18:05 looks like openssl didnt want to release it in the 0.9.x series Dec 29 13:18:08 but they are missing in 0.9.8 Dec 29 13:18:13 even in the latest Dec 29 13:18:24 well even in 0.9.8zf Dec 29 13:18:33 feature vs bugfix I guess Dec 29 13:18:50 hmm, yeah, makes sense Dec 29 13:19:21 BTW, AFAIK 0.9.8 and 1.0.x can coexists Dec 29 13:19:27 yes they can Dec 29 13:19:31 yeah :) Dec 29 13:19:46 hmm, dunno about headers, but libs can Dec 29 13:19:49 now it's compiling Dec 29 13:19:54 so we should not have much of a problems Dec 29 13:19:57 headers can't Dec 29 13:20:11 ceene, told ya, special chars confuse configure scripts Dec 29 13:20:13 well, it serves my purpose now, which is to get it compiling against openssl1.0.2e Dec 29 13:20:39 i want then to backport some of the ssl related things of qt5 Dec 29 13:20:45 ceene: really, qt? well, I guess if this one works, everything will, but... :D Dec 29 13:20:46 to let it support tlsv12, etc Dec 29 13:21:18 anyhow, we should now have all the info we need to have in order to complete items #1, #2 and #3 from the first post in http://talk.maemo.org/showthread.php?t=96292 Dec 29 13:21:23 ceene: we should patch (or backport from newer) qt fot it to support > tls1 Dec 29 13:21:34 freemangordon: yes, that's the idea Dec 29 13:21:47 most apps don't change default ssl options Dec 29 13:21:52 as 4.7 is aware of tls1 and ssl3 only Dec 29 13:22:08 most in maemo do, as ssl3 is no longer supported :) Dec 29 13:22:24 so probably just modifying qssl::secureprotocols or however it's called, i don't remember, would be enough for apps to use the appropriate protocol Dec 29 13:22:26 regarding curl and tlsv1, stupid thing (libcurl) will default to sslv3 unless told otherwise Dec 29 13:22:28 ant is is the default Dec 29 13:22:34 provided backporting protocol support to qt4 is doable Dec 29 13:22:40 bencoh: same for qt Dec 29 13:22:52 freemangordon: except curl wont try tslv1 by dfault Dec 29 13:22:59 qt as well :) Dec 29 13:23:02 at all Dec 29 13:23:03 ah Dec 29 13:23:40 qt sends ssl3 hello, server rejects it and that's all :) Dec 29 13:23:50 or something like that Dec 29 13:24:01 I had that problrm with FB sharing plugin Dec 29 13:24:03 ssl3 should just be removed, as far as i know Dec 29 13:24:15 yeah Dec 29 13:24:32 freemangordon: something like that with curl as well yeah Dec 29 13:24:46 Can anyone help make sure the root certificates in https://github.com/community-ssu/maemo-security-certman/commits/master are up to date with what they should be these days? Dec 29 13:24:50 unless you specify -1 (force tlsv1) Dec 29 13:24:59 but our curl should be pretty recent iirc Dec 29 13:25:06 7.26 Dec 29 13:25:09 I dont know where the good set of root certificates are these days Dec 29 13:25:14 jonwil: last time I've checked, it was fine Dec 29 13:25:18 ok Dec 29 13:25:24 but it was some 2 years ago :) Dec 29 13:25:45 where does that set of root certificates come from? Mozilla? NSS? Dec 29 13:26:01 "freemangordon committed on 30 Aug 2013" Dec 29 13:26:10 mozilla should be ok Dec 29 13:26:43 someone with time and patience should check certs if FF agains those in maemo Dec 29 13:26:48 *in FF Dec 29 13:29:13 is qt5 something desirable for maemo? Dec 29 13:29:32 wayland? Dec 29 13:29:50 or a bump to 4.8 instead of 4.7 Dec 29 13:30:01 what for? Dec 29 13:30:08 don't know, just asking Dec 29 13:38:27 I would doubt wayland is something that would be useful for maemo now Dec 29 13:46:03 not really Dec 29 13:51:10 hmmm, if I knew how all this certificate stuff in maemo-security-certman worked, I would take a look and see if its up-to-date with what it should be. Dec 29 13:51:26 I found http://mxr.mozilla.org/nss/source/lib/ckfw/builtins/certdata.txt which contains the current Mozilla root certificate set Dec 29 14:04:03 Pitty Juhani Mäkelä seems to be gone, otherwise they might be able to tell us how to update the maemo-security-certman certificates using the certdata.txt file Dec 29 14:13:04 can this certificates, can not just only be cped from a working linux workstation? Dec 29 15:23:50 sunshavi: no it needs to be in format usable for certman Dec 29 15:25:38 pali: Mmm. /etc/ssl/certs/ca-certificates.crt, is not in the required format. Then my assumption was wrong. Dec 29 15:26:31 pali: btw: some people get it from cli see: https://wiki.archlinux.org/index.php/Isync#Step_.231:_Get_the_certificates Dec 29 15:26:51 and? Dec 29 15:27:12 s_client is used for TLS via TCP Dec 29 15:27:25 that pem file is in the format required bi certman? Dec 29 15:27:44 of course you must be able to download public server cert and CA from server Dec 29 15:28:11 sunshavi: PEM format is some standard format for storing pkcs stuff Dec 29 15:28:40 certificate is just some asn structure stored either binary or base64 Dec 29 15:28:54 but certman needs some special storage Dec 29 15:29:00 some indexes or what Dec 29 15:30:36 mmm. My assumption was the ca-certificates pkg is just some base-64 encoded files. and it should be the same for all distros, like a plain text file. Am I wrong? Dec 29 15:46:12 sunshavi: each TLS library needs certificates in own format Dec 29 15:46:23 NSS, OpenSSL, GnuTLS Dec 29 15:46:26 also Certman Dec 29 15:46:41 mmm, ok Dec 29 15:46:43 Qt4 too :-) Dec 29 15:46:57 they r statically linked then Dec 29 15:47:00 oh yeah about that Dec 29 15:47:06 we should probably update that crap Dec 29 15:47:16 and align with the mozilla trust store as a reasonable default Dec 29 15:47:44 I think that fedora has some project/prgram which take list of CA certificates and generate correct format for NSS, OpenSSL and GnuTLS Dec 29 15:48:16 can't we just copy debian Dec 29 15:48:17 and go from there Dec 29 15:48:46 NSS uses sqlite or db2 for stroring certs (depends on app) Dec 29 15:48:51 firefox uses db2 Dec 29 15:48:58 chromium sqlite3 Dec 29 15:49:07 but both firefox and chromium ses NSS Dec 29 15:49:09 hmm... firefox doesnt rely on NSS for certs? Dec 29 15:49:20 chromium doesn't use NSS anymore Dec 29 15:49:29 they switched to boringssl Dec 29 15:49:36 kerio: really? Dec 29 15:49:46 and where they store user certs? Dec 29 15:49:48 i'm fairly sure they did Dec 29 15:49:50 i dunno Dec 29 15:50:40 $ readelf -d /usr/lib/chromium-browser/chromium-browser | grep -i nss Dec 29 15:50:40 0x0000000000000001 (NEEDED) Shared library: [libnss3.so] Dec 29 15:50:40 0x0000000000000001 (NEEDED) Shared library: [libnssutil3.so] Dec 29 15:50:46 $ chromium-browser --version Dec 29 15:50:46 Chromium 45.0.2454.85 Ubuntu 12.04 Dec 29 15:50:58 no, still uses NSS Dec 29 15:51:22 nothing boring Dec 29 15:51:40 https://code.google.com/p/chromium/issues/detail?id=393317 Dec 29 15:51:46 i don't know lolz Dec 29 15:52:35 $ readelf -d /usr/lib/chromium-browser/chromium-browser | grep -i ssl Dec 29 15:52:35 0x0000000000000001 (NEEDED) Shared library: [libcrssl.so] Dec 29 15:52:46 $ readelf -d /usr/lib/chromium-browser/chromium-browser | grep -i crypto Dec 29 15:52:46 0x0000000000000001 (NEEDED) Shared library: [libcrcrypto.so] Dec 29 15:52:46 0x0000000000000001 (NEEDED) Shared library: [libk5crypto.so.3] Dec 29 15:53:10 literally all the libraries Dec 29 15:53:16 /usr/lib/chromium-browser/libs/libcrcrypto.so Dec 29 15:53:25 i think libcrcrypto is boringssl's libcrypto Dec 29 15:53:30 looks like... Dec 29 15:53:34 but stil uses NSS Dec 29 15:53:46 maybe just for user cert storage? Dec 29 15:53:49 pali: then after openssl (0.9.8z) compilation on n900. I can not backport it to n800. cos finding the right certificates is going to be an issue Dec 29 15:53:54 Pali: probably as a backend Dec 29 15:54:01 chrome tends to use whatever the default for the OS is Dec 29 15:54:19 i guess that means libnss on linux Dec 29 15:54:59 kerio: you're mixing two different "NSS" Dec 29 15:55:46 network software something, right Dec 29 15:55:53 the mozilla tls library Dec 29 15:56:35 that one isn't particularly "default" on linux OSes Dec 29 15:56:50 it's, well... used in mozilla products Dec 29 15:57:55 yeah but Dec 29 15:58:00 the mozilla trust store most definetely is Dec 29 15:58:11 what else are you going to use? oracle java's? Dec 29 15:59:13 what's the "mozilla trust store" Dec 29 16:00:51 https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ Dec 29 16:04:08 most linux distrib will ship with the certs included in the mozilla "root store" Dec 29 16:04:22 but it doesn't mean they use libnss in any way Dec 29 16:04:41 think of the ca-certificates debian package for instance Dec 29 16:06:36 no libnss there, just a bunch of certs and a wrapper to openssl c_rehash Dec 29 16:08:02 we should do that thing Dec 29 16:09:39 Pali: do you know where maemosec/certman is used? Dec 29 16:10:26 bencoh: wifi (eapd), modest, paritally microb (browser) and maybe other parts Dec 29 16:11:19 does microb use it through libnss? Dec 29 16:11:45 microb links to certman libs Dec 29 16:11:53 so something is doing with it Dec 29 16:12:01 hmm Dec 29 16:13:07 well, I guess we'd need to read microb-engine source... Dec 29 16:14:56 funny ldd on browser.launc doesnt give nss Dec 29 16:15:16 because browser does not use nss Dec 29 16:15:34 it is in lower layer in eal Dec 29 16:15:57 hmm Dec 29 16:16:25 http://browser.garage.maemo.org/docs/browser_paper.html Dec 29 16:16:37 http://browser.garage.maemo.org/docs/eal/index.html Dec 29 16:16:50 right, browserd is linked against it Dec 29 16:18:11 browserd is linked against libnss3/libssl3 and openssl but not against maemosec or certman libs Dec 29 16:18:34 browser is linked against maemosec/certman stuff and openssl, but no libnss3/libssl3 Dec 29 16:20:40 Pali: certificates are in standart pem format, there is a cmdline tool to rehash them Dec 29 16:21:20 freemangordon: are you able to update certman package where are certs? Dec 29 16:21:48 just a sec Dec 29 16:23:01 Pali: https://github.com/community-ssu/maemo-security-certman/blob/master/debian/maemosec-certman-common-ca.postinst Dec 29 16:24:13 at least that's openssl-"standard" Dec 29 16:27:01 Pali: according to https://github.com/community-ssu/maemo-security-certman/commit/0be038825a98dae2d80fd411a02cb4c86ed1b36a merlin1991 should be able to change certificates as well :) Dec 29 16:27:12 I already have too much on the plate, sorry Dec 29 16:27:27 also, I don;t remember how exactly it is done Dec 29 16:30:23 freemangordon: can i get those certs on n800 and just rehash them too?, for openssl use Dec 29 16:30:40 yep Dec 29 16:31:09 though the tricky part is that you should rename the certificate after rehashing and rehash again or somesuch Dec 29 16:31:14 can;t remember exactly Dec 29 16:31:18 great, well all of we r on Merlin hands then Dec 29 16:31:31 or, you should use cmcli to import the certificate Dec 29 16:31:52 sorry, it was 2 years ago I last played with this Dec 29 16:32:45 mmm, I have compiled mbsync aka isync for n800. But i can connect to gmail I think it is a certificate issue Dec 29 16:33:10 I would need to dig a little bit about the certificates subject Dec 29 16:33:34 s/can/can't/ Dec 29 16:33:40 yeah, cmcli is the way Dec 29 16:33:56 freemangordon: thanks Dec 29 16:34:22 cmcli [- [:...]] [- ] Dec 29 16:34:22 -a ...]> -i Dec 29 16:34:22 -a to add a certificate to the given domain Dec 29 16:34:29 cmcli? is that the way you add certs in maemo? Dec 29 16:34:36 yes Dec 29 16:34:42 thx :) Dec 29 16:34:44 add/remove/etc Dec 29 16:35:27 I guess we need "-i to install a PKCS#12 container or a single private key" Dec 29 16:39:47 no cmcli on n800, which pkg is part of cmcli? Dec 29 16:40:13 maemo-security-certman Dec 29 16:40:22 let's search Dec 29 16:49:21 freemangordon: "maemo-security-certman" needs to be backported to n800 Dec 29 16:50:08 at least we r in the right path :) Dec 29 16:50:18 sunshavi: could be, but I don;t have such device, feel free to backport it https://github.com/community-ssu/maemo-security-certman Dec 29 16:51:30 nice. thanks Dec 29 16:51:58 sunshavi: though i doubt there is no similar tool on n800 Dec 29 16:52:24 DocScrutinizer05: what is used to manage ssl certs on n800? Dec 29 16:52:26 well, Pali said libcst was renamed to maemosec, so ... Dec 29 16:52:33 mmm, what would be the name?, where is that pkg right now? Dec 29 16:53:28 bencoh: libcst is a lib. So (no cli tools on lib pkg) Dec 29 16:53:47 sunshavi: what about maemosec-certman-tools Dec 29 16:54:02 yeah, but it might lead you to some other tool Dec 29 16:54:03 let's search Dec 29 16:55:25 sunshavi: what is the output of "dpkg -l | grep cst" Dec 29 16:56:37 there shoule be some *tools* or *bin* package or somesuch Dec 29 16:56:43 --8<---------------cut here---------------start------------->8--- Dec 29 16:56:44 ii libcst 1.7.20 X509 certificate manager library, dummy pack Dec 29 16:56:44 ii libcst0 1.7.20 X509 certificate manager library Dec 29 16:56:44 --8<---------------cut here---------------end--------------->8--- Dec 29 16:56:47 Dec 29 16:58:32 freemangordon: no match also on "maemosec-certman-tools" Dec 29 16:58:43 sec Dec 29 16:59:27 sunshavi: there is some closed source certificate manager Dec 29 16:59:42 check which packages depend on libcst Dec 29 17:01:51 sunshavi: http://maemo.org/development/documentation/manuals/3-x/howto_certificate_storage_bora/ Dec 29 17:02:23 or is it maemo4 Dec 29 17:02:25 ? Dec 29 17:02:48 freemangordon: no idea Dec 29 17:05:35 freemangordon: I think N8x0 had diablo Dec 29 17:05:44 not bora Dec 29 17:06:08 yes, chinook, then diablo Dec 29 17:07:29 apt-cache rdepends Dec 29 17:08:13 it seems there is no cli Dec 29 17:08:20 but UI only Dec 29 17:10:11 --8<---------------cut here---------------start------------->8--- Dec 29 17:10:11 ~ $ apt-cache rdepends libcst Dec 29 17:10:11 libcst Dec 29 17:10:11 Reverse Depends: Dec 29 17:10:14 certs Dec 29 17:10:17 --8<---------------cut here---------------end--------------->8--- Dec 29 17:10:22 bencoh: thanks Dec 29 17:10:31 what is that package certs? Dec 29 17:10:39 debian is not my main distro Dec 29 17:11:06 sunshavi: dpkg -L certs Dec 29 17:11:15 will list all the files in the package Dec 29 17:11:30