Annvix: Documentation/Dev/Design

From Annvix

Development Design

This is an abstract idea of how Annvix development will work.

Annvix will not, at this time and the foreseeable future provide "developer access" to servers of development machines. In fact, developers will not have a central development system on which to work. This is done for a few reasons:

Without having close proximity to the master repositories, unauthorized access is very limited
Developers should be fully testing packages on their own systems prior to submitting them to the repository

This last reason is quite important, and it will keep the quality of the repository at any given time much higher. For instance, a packaging error or faulty package will affect only the developer using this method rather than multiple users who may be syncing with the repository at a particular time. In this way, the developer can make sure their package works properly prior to submitting it to the repository.

Developers will only submit GPG-signed src.rpm packages. These packages will be validated against the developer's GPG key and then will be rebuilt in an up-to-date chroot. If the package builds completely, it will be re-signed with Annvix packaging key and uploaded to the appropriate repository and checked into CVS. Packages that fail to build will be rejected with the build output made available to the developer.

One of the first steps in creating the Annvix repository is to re-obtain all source packages (tarballs) and their associated GPG detached signatures. If a detached signature is not available, a verifiable md5sum will be used instead. A central database will be maintained with the GPG public keys for signed packages and md5sum values for those without signatures. Every time a package is built, packages will be checked against the database (detached signatures verified, md5sum values computed and compared to the database). If any package fails, it will be rejected.

Developers, when creating new patches for packages, will be required to sign the patches with their GPG key. All patches, prior to being applied to a source package, will be validated. If any patch cannot be validated, the build will be rejected.

We strongly believe that Annvix must be a secure distribution, and this means from developer activity to the building and maintenance of packages as well as just a secure operating system. Some of these steps may seem severe, however considering recent compromises and planted trojans in software, this system should prevent any compromised packages from being made available.

Note to software developers: Sign your tarballs! It really is not that difficult of a process and is of great benefit to users.

Personal tools

Search

Toolbox

From Annvix

Views

Home Recent changes Donations Page Index About Annvix Project Goals Development Team News Developer's Blog Resources User Guide Documentation Release Notes Changelog Mailing Lists Download Annvix Development Tools View Subversion CIA Project Page Ohloh Project Page Search Toolbox What links here Related changes Special pages Printable version	/Documentation/Dev/Design From Annvix Development Design This is an abstract idea of how Annvix development will work. Annvix will not, at this time and the foreseeable future provide "developer access" to servers of development machines. In fact, developers will not have a central development system on which to work. This is done for a few reasons: Without having close proximity to the master repositories, unauthorized access is very limited Developers should be fully testing packages on their own systems prior to submitting them to the repository This last reason is quite important, and it will keep the quality of the repository at any given time much higher. For instance, a packaging error or faulty package will affect only the developer using this method rather than multiple users who may be syncing with the repository at a particular time. In this way, the developer can make sure their package works properly prior to submitting it to the repository. Developers will only submit GPG-signed src.rpm packages. These packages will be validated against the developer's GPG key and then will be rebuilt in an up-to-date chroot. If the package builds completely, it will be re-signed with Annvix packaging key and uploaded to the appropriate repository and checked into CVS. Packages that fail to build will be rejected with the build output made available to the developer. One of the first steps in creating the Annvix repository is to re-obtain all source packages (tarballs) and their associated GPG detached signatures. If a detached signature is not available, a verifiable md5sum will be used instead. A central database will be maintained with the GPG public keys for signed packages and md5sum values for those without signatures. Every time a package is built, packages will be checked against the database (detached signatures verified, md5sum values computed and compared to the database). If any package fails, it will be rejected. Developers, when creating new patches for packages, will be required to sign the patches with their GPG key. All patches, prior to being applied to a source package, will be validated. If any patch cannot be validated, the build will be rejected. We strongly believe that Annvix must be a secure distribution, and this means from developer activity to the building and maintenance of packages as well as just a secure operating system. Some of these steps may seem severe, however considering recent compromises and planted trojans in software, this system should prevent any compromised packages from being made available. Note to software developers: Sign your tarballs! It really is not that difficult of a process and is of great benefit to users. Retrieved from "http://annvix.org/Documentation/Dev/Design" Category: Development
	Views Page Discussion View source History This page was last modified on 10 February 2007, at 17:57. About Annvix Disclaimers