[ALL] New showroom for Openmoko apps

Markus Törnqvist mjt at nysv.org
Tue Aug 25 21:33:47 CEST 2009

On Mon, Aug 24, 2009 at 11:56:19PM +0100, Joao Pinto wrote:

>I don't have a diagram for the APT-Portal database model, actually I
>find more important the the rational used on it.

It's pretty clear still :)

Any pointers for the list on how to hack this thing?

>On my perspective there are 3 key groups of information that you need
>for a software portal:
>Back-End - Repository/Archive
>This describes the organization of the software components and it's
>relations on the archive, on my case there was nothing special to
>define, APT has already a clear structure, there is a URL which points
>to a repository , the repository is described by a "Release" file and
>the contents of that repository/component is described at a Packages
>Because such repository is already defined as part of the distribution
>system, I have just developed a script which imports data from a
>generic APT repository to the database, the data on the repository
>tables is populated from the "upstream" repository - there was an
>exception introduced later, a package can either provide : m - main
>package (provides an application). o - optional package (provides an
>optional package for an application, like -server for a game) and i -
>inter package (for data libraries etc), such classification is
>directly related to packages and is not present on the repository,
>this is the single human inpurt field introduced on this group.

Ok, that's good to know, about the classification. Thanks :)

After adding the user as an admin, there's a new link called
Packages, which lets you edit these, and set the states for the

>Front-End - Application/Application Category
>This provides the core information about an application, like
>description, name, homage, description translations, screenshots,
>youtube demos, etc.
>There is no enforced reference (foreign key) to the repository group,
>however there is a "source_package" field which identifies a source
>package that (if available) provides the main and optional packages
>for the application.

Could/should this be a null foreign key?

For some games at least source packages may be unavailable and thus
the use case redundant for you, but for moko it would be really good
to have streamlined support for sources.

>Management - Who can do what
>This provides the user and groups information, groups provide
>privileges to manage both the repository and applications, so far we
>are using a single group "admin" which can both defined/edit
>application entries and issue repository management commands (remove,
>copy from testing to stable)

This is cool.

>If you want to check the current tables definition just browse:
>Now talking about security, because that is specially key requirement
>for any public site.
>General - apt-portal can easily be run using an appamor profile,
>generic traversal, file retrieval/creation could be possible with code
>exploits but are limited according to the strictness of the appamor


>SQL Injection - we are using SQLAlchemy and bind parameters, sql
>injection is not possible
>XSS Exploit - can be prevented by using Mako's templating engine
>built-in html or url  filtering on dynamic parts on the templates

Yeah, these two belong in the nineties.

>Please give a try to APT-Portal, I do not know if it can cover your
>requirements, if it does it would be a great collaboration
>opportunity, working on the back-end requires specific knowledge on
>repository the technology used, bout the front-end and management
>could easily be shared across different projects.

We need to discuss about source packages at least,
and how to do different distributions, and probably code layout where
all the paths live (I haven't really done cherrypy before ;)

Anyway, I've seen worse starts than this, I say we proceed from here :)



More information about the community mailing list