sebnow / aur2 Goto Github PK

Currently any user can upload a package and potentially overwrite another user's package. Permission checks should be put into place to restrict access (based on the user's group, and whether the user is a maintainer of that package). Django does not currently support row-level permissions, so this needs to be done via other means.

The current parser sources the PKGBUILD in a shell, outputting the variables in a Python-compatible format, which is then evaluated in python. This works extremely well as far as parsing goes, but at the cost of security. Malicious code can be used, or even just a simple infinite loop could hang the server. A secure and restricted parser/interpreter should be implemented to rectify this.

Recently the PKGBUILD specification was modified to support split packages (building multiple binary packages from a single PKGBUILD). This is problematic since the database schema doesn't support "sub packages." There are two ways that I can think of to show this information. Having one package per split package, resulting in quite a bit of duplicate data in the database, however without altering the database schema. The other is to have a single package encapsulating the sub-packages (reflecting the PKGBUILD specification). This would require modification of the database schema, search logic (sub packages would need to be searched) and templates.

The first solution is definitely simpler, but a problem arises when deleting or updating a package. The split packages would appear in the listing, potentially confusing users.

The second solution is more elegant, especially to the end-user, but is an order of magnitude more complex to implement.

There is a very primitive and incomplete API implemented. This needs to be expanded to at least rival the current API implementation, and ideally implement all of the new API design.

Using Django Piston has been suggested, and it seems to be a nice library gaining popularity.

Support OpenID for authentication. This is more of a convenience than required functionality, so it is low priority. In the grand scheme of things it would be nice to have implemented since Archlinux has many different authentication systems (flyspray, punbb, aur, mailing lists, etc). Supporting it in AUR won't help until it's supported in other systems as well, but it's a step in the right direction.