I would like to propose some ideas in terms of improving the security of the N900 system.
1.We should look at the installed-by-default packages and where there are updates or patches out there that improve security (but which can be used on maemo without breaking things) we should bring them into cssu git repository on github and make them available. Its already being done with newer upstream versions of openssl0.9.8, zlib, libxml2 and some others).
2.we should look to bring in either the latest openssl or libressl and use it for all those packages which use openssl and for which we have source code. (there is no reason we cant keep openssl0.9.8 and something newer around side-by-side as far as I know)
3.Same for any other packages where there is a newer more-secure non-ABI-compatible upstream version we can pull in.
4.We should look at how microb does security and figure out if we can upgrade all the security and crypto and ssl bits in order to support the latest standards (like TLS1.2) so people using a N900 to browse the web are secure. This also includes modifying things where possible to disable the same depreciated algorithms and protocols and stuff that Mozilla, Google and others have disabled so they don't get used. Updating the browser engine (e.g. trying to support the latest HTML5/web 2.0 stuff etc) isn't really possible (too many things rely on it like Flash and Maps and the browser UI) but I bet we can do some things with the security stuff to improve things (including maybe even back-porting any critical patches that we can find and that are worth back-porting)
5.We should look at the installed set of root CAs and make sure its up to date with what everyone else is shipping so we aren't vulnerable
and 6.We should consider creating a "security update" for Maemo Fremantle with the criteria for what goes into it being similar to the various "long term" security updates for Linux distros like Debian and Ubuntu. In particular, it would be more conservative than even CSSU-stable and wouldn't ship any new-feature-work (like the portrait/screen rotation stuff)

http://wiki.maemo.org/Fremantle/Repositories actually proposes exactly what I suggested for #5.

Yes these are just ideas and yes it needs people who can actually do the work (I can certainly help where my time and skills allow) but its a thought on how we can make one of the best cellphones ever produced secure enough to survive out there in today's increasingly dangerous online environment.

For #2, here is a list of packages that use openssl:
adobe-flashplayer (adobe flash player, closed source)
as-daemon-0 (Microsoft ActiveSync/Mail For Exchange, closed source)
clinkc0 (UPnP AV library, open source)
connui-conndlgs-wlan (WLAN connectivity dialogs, closed source)
connui-iapsettings-wlan (WLAN configuration wizard, closed source)
connui-iapsettings (internet settings control panel, closed source)
funambol-cpp-api (SyncML stack, closed source)
libcurl3 (file transfer library for curl, open source)
liblomesa0 (low level image viewer API, closed source)
libloudmouth1-0 (jabber library, open source)
libmaemosec-certman-applet0 (maemo security certificate manager applet library, open source)
libmaemosec-certman0 (maemo security certificate manager library, open source)
libmaemosec0 (maemo security library, open source)
libsofia-sip-ua-glib3 (SIP glib bindings, open source)
libsofia-sip-ua0 (SIP library, open source)
location-proxy (daemon for communicating between cellular modem GPS hardware and SUPL server, closed source)
maemosec-certman-applet (maemo security certificate manager control panel, open source)
maemosec-certman-tools (maemo security certificate manager tools, open source)
maesync-backend (maesync backend library, closed source)
microb-eal (microb browser web engine, open source)
nokiamessaging (nokiamessaging daemon, closed source)
osso-backup (backup application, closed source)
osso-wlan-security (handles security for WiFi connections, closed source)
ota-settings (handles GPRS IAP settings sent over-the-air, closed source)
sharing-service-ovi (service for sharing on ovi, closed source)
signond0 (single sign-on daemon, closed source)
tablet-browser-ui (tablet browser main executable, closed source)
xserver-xorg-core (x.org server binary, open source)

Pulling these closed-source binaries apart and figuring out which openssl functions they are using is something I am planning to look into)

Thank you for your post.

I actually feel this is the sort of thing CSSU-Stable is for.
Stable - the "LTS" of Maemo.
I don't see the reason for the additional repository.

As long as CSSU-Stable will continue to run with the same UX as PR1.3.1 OTB, I feel another repository would be more work for little gain.

These security patches and fixes should run through the usual devel>testing>stable setup that has served us well in weeding out the bugs over the years.

As for browsing, I feel long term the stock browser would need to be replaced, from what I believe parts are closed which restrict any upgrades. As flash is phased out of sites we need a HTML5 compatible browser in the future.
In the meantime yes it is important to disable depreciated algorithms, especially as we have little alternatives to use.

ok I confirmed that yes microb-engine is using its own crypto code (NSS) and not openssl so we need to look into that.
It does however tap into the maemosec stuff for its root certificates (makes sense, that way there is only one set of root certificates for the entire device)

As for cssu-stable, does it not install extra stuff like orientationlock/rotation?
I want something that has zero no features whatsoever.

there are some packages there, sharing-service-ovi + nokiamessaging for example that afaik do nothing now that the related service is defunct. if so best security option there may just be removal.

i seem to remember an open source location-proxy, can't remember if it was maemo related or suggested as a replacement.

regarding microb replacement, I've been looking at netsurf 3.1. gtk2 support, currently uses old mozjs component but is being replaced with duktape. hit an issue with dependency on libffi6. it build on stock gcc but fails tests, on thumb it just..well it's got lots of errors.

I agree with sixwheeledbeast. cssu-stable cherry picks updates from testing. orientation lock is optional seperate package in testing.

with your recent work in cssu-devel, is the plan to replace connui-* packages eventually?

Yes we should remove any services that dont work anymore (I would advocate removing activesync/mailforechange too except that there are people who may actually be using it...

Not sure about location-proxy, I have described various inner workings in the past but I am unaware of any open source clone (and I cant find one with Google either). Its probably not that hard to clone though if you could figure out the handful of liblas calls it makes and know how to talk to a SUPL server properly)

as for microb, if you make the new browser implement the microb interfaces (e.g. for bookmark stuff and for starting a web page via dbus) and you keep the old browser engine around for use by rtcom-messaging-api, tutorial-home-applet and nokia maps (which FYI still works just fine and shouldn't be removed or depreciated) then the only real issue with a newer browser would be adobe-flashplayer, libssoautologin, tablet-browser-mediaplayer-plugin and tablet-browser-default-plugin (dont know what libssoautologin is for or how important it is and I bet you could write replacements for tablet-browser-mediaplayer-plugin and tablet-browser-default-plugin without massive amounts of work)

Unless I am reading things wrong, http://repository.maemo.org/communit...antle/install/ shows status-area-applicationlock-applet as being part of community-stable.

An for connui-* and systemui-* and things, my aim is to just clone whatever I feel like cloning and whatever I am able to clone, I am currently halfway though reverse engineering libcodelockui (UI for the device and SIM pin lock number pad screens) with plans to clone it at some point along with osso-systemui-devlock and osso-applet-devicelock and maybe libdevlock

I'm using MfE Do keep thinking of switching it to IMAP now hotmail/live/outlook/new-name-for-same-service supports it but it didn't want to update correctly last time I tried it.

Regarding location-proxy, I think I may have been thinking of http://sourceforge.net/projects/supl/. Whether it is of an use or valuable as a reference during a RE/rewrite project who knows.

status-area-orientationlock-applet is part of CSSU but it is not installed by default. https://talk.maemo.org/showpost.php?...04&postcount=5.

The idea of a CSSU-Security as mentioned in your link seems sound enough but it needs a little expansion. Due to devices running thumb, would we require security and security-thumb or do we use it as a, excuse the wording, fast push/release on discovering an issue and then push a thumb specific build later. Another idea would be to keep it purely to what it says in your link, just maintaining the infrastructure, in which case would it be better referring to as CSSU-Infrastructure?

Any plans I have on looking at browser are currently dependant on what I can actually get working before looking at maintaining compatibility. For Netsurf, libffi6 is failing tests related to unwind.cc on stock gcc. I also need libmozjs185 which is way out of date (IIRC Firefox 8 era) and not sure if I can use a newer version. Upstream is testing DukTape as an alternative which *looks* pretty straight forward to build. Debian lists the arm depends as libgcc-4.4 on a lot of the packages. Flash support, given the age and probable security issues, is very low on my list of requirements. I would ditch it on all devices if it weren't for a few mainstream sites still using it.

libcodelockui will be of great use to me for my GTK3 port of the control panel. I'm currently building without any MAEMO_TOOLS support. libsystemui related packages are one of the big hurdles preventing me using some of our RE'd packages at the moment hence the use of those from Nemo.

The idea is that all security fixes would end up in cssu-devel, cssu-testing, cssu-thumb, AND cssu-stable/cssu-security/whatever.
Anyone running Thumb is going to be somewhat bleeding-edge anyway because you need a new kernel and some other "riskier" parts.

Also what else beyond libcodelockui is going to help you with your gtk3 work?

For the people developing clutter to pick an idea and stick to it! I mean some of the animation code has had to be adapted to a new API before it can be adapted to a replacement for that API. Even better, this "new" API is hardly used by anyone, they're all still using deprecated functions. The animation code for the task switcher for example is using a ClutterTimeline to keep everything in sync and activates it when it wants. New clutter automatically animates, have to be removed from an object before they can be reapplied....

Joking aside, if, or more like when, I need help with a particular element I'll post online. It's still a pet project at the moment to investigate what's possible.

The problem comes with any closed source elements that are referred to by the open source replacements. If I can't build some of the libsystemui elements I don't think I can use Fremantle mce. Then again, it might be more preferable to use Nemo bits so that some one else is maintaining them and possibly open it up to more devices.

For the most part I'm able to adapt/remove the Maemo specific stuff. HildonPannableArea was pretty much a reworked GtkScrolledWindow with touch support. As GTK3 has touch, all I did was rework it to extend GtkScrolledWindow with scroll_to() etc.

I'm currently working on an issue with button width allocations, been putting it off whilst I get some other bits going but now I need to look at it. Date and Time buttons also cause segfault. As you can see from the images, tick box is missing from check buttons and widths are not taking into account there containers limits. I think it's probably minimum-size being set rather than natural but I'll find out when I look at it. Button heights seem fine though.