Since I ended up commenting on this thread after it was dead for six months, figured I might as well post again to give it a thorough reply regarding the claimed merits of HAM's unique features:

I see that the big differences HAM has (vs. normal apt + dpkg) are:
1. Domains
2. Some recovery if interupted (battery falls out while updating or something)
3. Loose scriptability (independent of the underlying deb package system's preinst/postinst/prerm/postrm scripts)

I must admit, I think that point #2 is a good idea to some extent - though this is something that I think needs to be bounced around until it's well ironed out as an implementation on the upstream apt mailing list(s) or wherever they do their development decision-making, then pulled down from upstream. (I know apt / dpkg CAN try to fix broken packages, but in my experience it often doesn't know what to do when you tell it to: so I hope HAM's stuff is somehow better...)

Point #3 seems to have come from back when Nokia was planning on using Hildon (and Hildon Application Manager) as a more general-purpose tool, not as /only/ a wrapper for our apt/dpkg -based system. From the Hildon wiki page I see that they intended back in the day to use it on Symbian somehow as well. Such limited scriptability might be meritable in that context, but I don't see how it really adds anything of value to our Maemo 5 system - does any package we have even use that scriptability?

Finally, domains. This is a thing that I've seen get argued in-favor-of in this thread, almost as if it really makes things safer. For example:
And I can see that, yes, domains lower the attack surface slightly - this way, the packages that we know are /guaranteed/ to be on people's N900s are also packages that we can't /attack/ by uploading a similarly named package to extras*. Okay, fair enough.

But I don't think that that really gains us a lot. Sure, I can no longer sneak a malicious "hildon-application-manager" package into extras (but if I manage to hack into our infrastructure and just directly plop one of those into the (C)SSU repos, then HAM will still happily download and install it).

But if my modus-operandi is 'make an "updated" version of a package and sneak it into the repos' I am actually NOT realistically any more likely to be succesful if I use any other package name that I know is optional but most/many have installed.

Let's consider how packages get into the extras* repos:
0: We can trivially upload anything into extras-devel - last I checked you didn't even need to be the maintainer of the existing package. This is a pretty egregious security hole looming over everyone who regularly uses extras-devel (yes, you're not supposed to use extras-devel for day to day use, but we know people do, and we know there are legitimate reasons to)
1: Promoting from extras-devel to extras-testing is, last I checked, only the priviledge of the maintainer(s) of that package. Doable, but requires a lot more effort and windup time and preconditions for a would-be attacker.
2: Stuff only gets into extras when ten or so members of the mob that we are vote on it. We /hope/ that within the mob are competent people who /do/ watch the packages carefully, and who will vote down if there is something suspicious.

Obviously, #0 is pretty vulnerable to malicious packages, #1 is pretty easy to hit if you social-engineer right and put in the work (but now we're not in low-hanging-fruit territory), and #2 could certainly be hit if you put in even more work. There are improvements we could make across the board, which is a separate discussion we should really cover sometime soon in community meetings. I have no idea how packages get into the CSSU repos, never seen it written up, so I can't comment on that process.

But my point is that if you look at the above breakdown, sneaking a damaging package /under the name of an existing package/ is really not that easy - if the package exists in the repo already, you have to be its maintainer to get your malicious override of it out of extras-devel. And if we moved all of the system packages into the extras repository too, it would be similarly not easy to pull the same trick with them. It would be easier to sneak some system-library-named package down into extras now, simply because the namespace isn't already taken up. So part of the actual protection that HAM honoring Domains provides is self created by having (C)SSU packages in a separate repo.

Meanwhile, the actual risk of having people sneak malicious packages with the same name as 'updates' into the repos, is a deeper problem - if the chance of such sneakery is high, then the exact details of what package I do it through is irrelevant. It doesn't matter if I manage to get into position to do it with a 'system' package, or with a ubiquitous but not 'system' package, like openssh or bash or python.

In short, I can understand the benefit the HAM Domains thing brings - but I think that it is perhaps somewhat overestimated in value, and that just like having a separate system-packages repo at all, it is the product of Nokia's goals for our N900s as consumer products (to able to provide customer support, warranty, etc, on a stable set of software, rather than necessarily the best possible setup for a libre-ish phone). And I think the technically superior approach we ought to aim for in the future would be to have all the system packages in one main community repo along with all the 'extras' (I imagine using the same 'extras' repos, just renamed to something more general).

And completely independently of that we as a community ought to really try to refine how we secure the extras repos, and make another concerted go at improving the current workflow of getting stuff through the entire process - it could really use more polishing. (By the way, I think if the CSSU packages moved through the same process, especially if we made the process more effective, as the extras packages, then honestly I think that would be better in general: I think it would be nice for the CSSU to have that kind of feedback, but actually, it may even help motivate more of the community to take an active role in helping test software - we've always had a lack of motivation making things pile up at the extras/extras-testing barrier. Maybe is the CSSU moved through the same pipe people would feel more motivated to get involved, and while they did so, test and vote on another piece of software here or there...).