1.1. Introduction
This document documents the work of the Frugalware Security Team. Primarily
it's for new developers or for existing developers who started to work in the
Security Team.
1.2. Handling security bugs
-
The security team opens a new task in the BTS, with a [SEC] prefix.
-
The maintainer fixes the issue in -current and decides if the issue needs
fixing in -stable or not. If yes, then changes the status of the task to "Fixed
in -current", otherwise closes the task.
-
If there is no patch for the issue yet, then set the status to "Researching".
This indicates that you, the maintainer knows the problem, just you don't have
enough resources to fix it.
-
The security team regularly searches for "Fixed in -current" bugs, fixes the
issue in -stable and releases a new FSA.
1.3. How to release an FSA?
-
Check if the backport built by syncpkgd is ready (the binary packages
should be uploaded for each arch).
-
Open the -stable Changelog file of the package. There you can see the
vulnerable and unaffected versions of the package.
-
Add a new entry to the frugalware/xml/security.xml file in the
homepage-ng repo.
-
Commit, push. The commit hook will check if the xml is valid, so most
common errors can be avoided. In rare cases, the announcement may not
appear on the frugalware-security list. If this is the case, then ask
on -devel about what the problem can be.
-
Close the task in the BTS, filing in FSAxxx in the closure message.
1.4. How to notice security issues
-
Subscribe to Secunia Security Advisories List at
http://secunia.com/secunia_security_advisories/ page. This is the best place
to notice issues.
-
Read the mails one-by-one and check if the advisory affects -current or
-stable.
-
Open a task in BTS if necessary. Please fill in the form correctly, provide a
patch if you can.
1.5. How to get patches
Secunia announces sec issues days after they released so there is a good chance to find a patch.
-
First of all sometimes upstream fixes it with a new version.
-
Fixed in cvs/svn/whatever and you are able to find the patch (unlike PHP)
-
If these two fails, there is http://security.ubuntu.com/ubuntu/pool. Secunia
also mails you if the bug fixen in ubuntu, so steal the patch from them :) You
only need the $package-$pkgver.diff.gz. There is a changelog in it, where you
can find the filename of the fix.
-
It's also a good idea to take a look on redhat/gentoo bugzilla. They attach fixes most the time.
So it's good to read the secunia mails carefully as you'll always know when the patch is available.
1.6. Versioning
We use integers in pkgrels for normal packages, but -stable updates are
different. Here are the cases:
-
If you do a version bump (we refer to them as secfix bump usually in
-stable commit messages), then you need to set pkgrel to 1kalgan1.
-
If you add a security patch, and pkgrel was an integer (let's say 1), then
you should increment pkgrel to 2kalgan1.
-
If you add a security patch when the pkgrel was already in an XkalganY form,
increment it to XkalganY+1. (Alternatively, you can use X+1kalganY if there
is already a newer version in -current.)
(Replace kalgan with the current release name, later.)
This ensures the followings:
-
The version of the security update will be larger than the one in -stable, so
that the package will be upgraded when the user does a pacman-g2 -Syu on
-stable.
-
The version of the security update will be smaller than the one in -current,
so that the package will be upgraded when the user upgrades to a new version
(current or new stable).
2.1. Introduction
This document is for developers who want to publish a git repository on the
Frugalware FTP Server and on the Frugalware Gitweb Interface.
2.2. Location of the repository
Since a repository consists of plain files, we can and should place them on the ftp
server (/home/ftp). To prevent further problems, always use the server name
"git.frugalware.org", currently it's an alias of genesis.frugalware.org.
First decide if it's a personal repository or a team one. For example if you
create a repository to update to a newer python version, then probably you will
do all the work, create it under /pub/other/people/nick/reponame. Simply
create a dir, issue git init and push at least one commit to there.
If you want to allow others to push to your repo, then you want to allow them
to lock your repo. This requires
Now anyone can git clone it, using a full mirror, for example
ftp://ftp12.frugalware.org/mirrors/ftp.frugalware.org/pub/.
2.3. Registering for the gitweb interface
If the repository is a team one, then create it under /pub/other. In this case
probably you want the gitweb interface, too. To use it:
-
Update the file .git/description inside the repo with a short (less than 80
chars) description.
-
Create the file .git/owner inside the repo containing your name, without
your email address.
-
Push a relative symlink to the homepage-ng repository, see the existing
ones as a reference.
After some time (a maximum of 30 minutes) it should appear at
http://git.frugalware.org/.
2.4. Enabling hooks for your repository
Currently you need hooks for the following reasons:
. If you don't use bare repositories, then the content outside .git won't
be updated automatically, you need a hook to do so.
-
If you want CIA notification.
-
If you want sending mails to the Frugalware-git mailing list.
-
If you want to let other be able to clone your repository via dumb
protocols like http or rsync. (This means that if you disable this hook, it
won't be accessible anonymously!)
chmod +x .git/hooks/post-update
ln -sf /home/ftp/pub/other/git-hooks/git-hooks.py .git/hooks/post-receive
3.1. Ways of contributing
There are many different ways to contribute to Frugalware. You can write
documentation, translate the existing ones to your native language (or
any other language you want to) maintain packages or making them better
whith adding features whatever.
If you are a programmer you can help us in developing our applications.
These are: pacman-g2, gfpm, fwlive, frugalwareutils, setup etc. See
git.frugalware.org for different project
repositories.
You can also start new projects. If you show some code we can surely host
your project too if it's frugalware related. For example you want to write
kfpm :)
|
Important
|
After each title in brackets you can find the target audience. |
3.1.1. Translations (translators)
You can read the details on our Translations
documentation page.
3.1.2. Necessary documentation (packagers, coders)
In the first part i will cover the necessary informations for those who
do not have developer status yet.
In the second part we will set up the necessary config files.
First of all, we ask you to read the following documentations carefully.
If you do not want to deal with packages, just want to code it's usually
enough to read the git documentation as we store our code in git
repositories.
I know, it is boring reading documentation, but you have to know that
writing them is even worse so do not ask questions when there is the
answer in the documentation. If you can not understand something
feel free to join #frugalware@irc.freenode.net and ask.
3.1.3. Downloading and setting up the repositories
Getting the frugalware-current repo (packagers)
The frugalware-current repo is the development repo for the packages.
When you want to get it you need the git package. Let's get it:
Now create a git directory where you can hold all your repos. You can
choose any other name of course.
$ mkdir -p ~/git
$ cd ~/git
Now clone the repo with git:
$ git clone git://git.frugalware.org/pub/frugalware/frugalware-current current
$ cd current
Now be patient while git clones all the objects and then checks out the files.
Also you can use other mirrors as well.
Getting pacman-g2 and other code (coders)
First of all you need the repo of the program. In this example i will use
pacman-g2, but the steps are very similar.
NOTE: Most of our programs need the translations repo to compile)
$ mkdir -p ~/git
$ cd ~/git
$ git clone git://git.frugalware.org/pub/other/translations (optional)
$ git clone git://git.frugalware.org/pub/other/pacman-g2/pacman-g2
$ cd pacman-g2
Setting up the repository and sending patch via email (packagers, coders)
Now you should setup up your identity.
$ git config --global user.name "Your Name"
$ git config --global user.email email@addr.ess
$ git config branch.master.rebase true
Now you can make your changes. When finished run
|
Tip
|
You can also use git diff . (note the dot in the end). In
that case git will show the changes recursively in the current directory.
It is very handy when you have lot of uncommitted changes in your repo. |
If you satisfied with the changes run
to commit all your changes.
If you want to cherry-pick hunks from your changes:
or using native git commands:
Without committing your changes you can not send nor
push (just developers) it.
|
Tip
|
With frugalware-* repos it's recommended to use repoman rec
which is a wrapper for dg record. It sets up the patch name properly
so you only need to deal with the details. |
Here comes the final step. Send in the patch(es)!
$ git format-patch <hash>
$ git send-email --to frugalware-devel@frugalware.org .
<hash> is the sha1 of the last patch you do not want to submit. Run
and you'll see the hash. Also, you can just use your existing mail client and
send the patch(es) as an attachment.
If everything goes fine your patch should show up on the
frugalware-devel
mailing list soon.
|
Note
|
You have to subscribe to the
frugalware-devel
mailing list and set up your SMTP server properly (if you use git send-email). |
Not really belongs to here but I want to document it somewhere. If you are a
developer and want to apply such a patch, you need:
Subject: [PATCH] powwow-1.2.13-1-i686
* new package
Subject: [PATCH] powwow-1.2.13-1-i686
* new package
$ cat 0002-powwow-1.2.13-1-i686.patch | git am
You should do this in the root directory of the repository.
3.1.4. Further options for those who have developer account (packagers, coders)
Once you get a developer account, you have the right to request the
following services:
-
BTS access (so that we can assign tasks to you)
-
git write access (you'll always get this, except if you are working
on the artwork or so)
-
voice on the #frugalware.dev channel
-
a @frugalware.org mail address (with imaps/pop3s access)
-
Public and private devspace. The first is in the /pub/other/people/nick dir
and this is mirrored (you must not put private stuff to there). The later is
your ~/public_html dir: it is not mirrored and there is no backup for it.
Though you may temporarily put private stuff to there.
-
a @frugalware.org jabber account if you want one
-
You should read the frugalware-devel mailing list. When you're asked,
please try to respond.
-
If you push patches to git, you should subscribe to the
frugalware-git mailing list. This is list has a big traffic since a
new mail is sent for each patch. If you don't have time to read it,
subscribe then set the "I would like to receive no mail" option.
Also take care that your subscribing email equals to the one you set using git
config user.email
-
It's good if you can join the user and developer channel when you're
online.
-
Maintain your packages. Try to resolve your assigned bugs, try to keep
your packages up to date, and if you needed patches for packages, send
them upstream. If you don't have anything to do for a week that's
usually a bad sign. It's - of course - OK when you go for vacation a few
times a year, but then please announce it on the developer mailing list
so that we won't wait for you when fixing urgent problems, etc.
-
Document yourself. The documentation worth nothing if it's outdated.
Ideally one who never contacted use should be able to understand every
detail of Frugalware, just from documentation. No secrets! We are not
kids.
-
If you have time, try to read the mailing lists ( frugalware-users*@ )
and the forums. If you prefer reading the forums from your mail
client, there is a bi-directional gateway on the frugalware-forums@
list, use it.
Let us see what you should set up to get it work. I will also give some tips
which can make your life easier.
Read this page, we collected a set of
tricks when we converted from darcs to git.
Setting up the frugalware-* repos and repoman (packagers)
It is time to set up some necessary things. We start with the frugalware-current
repo. Make sure that you are in the root of the frugalware-current repo. Also
do not forget to change the username to your login name on git.frugalware.org.
$ git config remote.origin.url 'username@git.frugalware.org:/home/ftp/pub/frugalware/frugalware-current'
$ git config remote.origin.receivepack "sudo -u vmiklos git-receive-pack"
|
Important
|
Do not edit the second line! So that vmiklos have to be vmiklos.
It's because he is the current owner of that repo. |
As you will use repoman to upload the packages (and many other things as you'll see)
we should set it up now. This step is also necessary. Open ~/.repoman.conf with
your favourite editor and add the following lines:
fst_root=~/git
current_servers=("username@git.frugalware.org:/home/ftp/pub/frugalware/frugalware-current")
stable_servers=("username@git.frugalware.org:/home/ftp/pub/frugalware/frugalware-stable")
stable_pushonly="y"
Where fst_root is the directory where you store your git repos. Username
is your login on git.frugalware.org. For details see man repoman.
As from now use the following command from package's directory to push
your changes.
It will check the FrugalBuild using fblint, then records your changes,
pushes them, uploads the fpms and finally creates the changelog, updates
the fdb etc. So you are done if there was no error message.
Setting up other repos (coders)
In repo's main directory:
$ git config remote.origin.url 'username@git.frugalware.org:/home/ftp/pub/other/pacman-g2/pacman-g2'
$ git config remote.origin.receivepack "sudo -u owner git-receive-pack"
Do not forget to change the username and repository path.
For paths refer to the gitweb interface.
|
Note
|
The owner for pacman-g2, frugalwareutils, pacman-tools is usually vmiklos. |
You should always review what you would push before you perform the action:
$ git fetch
$ git rebase origin/master
$ git log origin/master..master
|
Note
|
The dg push wrapper does exactly this for you. |
You MUST follow this HOWTO when bumping GNOME to a new version (even a minor
version).
To start, packages must be compiled in the order listed below (if you find a
change that needs making to this list, poke AlexExtreme). If it is a major bump
(2.14 to 2.16, for example), it is wise to rebuild most of the GNOME packages.
4.1. GNOME compile order
(*) - don't use Fsplit on this package.
|
Note
|
all *sharp and all bindings need to be split |
4.2. Bumping individual packages
Never, i repeat, NEVER bump a version without doing the following:
-
Download the new version's tarball and extract it
-
Run ./configure —help and look in configure.in to check for new dependencies
(even optional ones) and consider whether to use them or not. Consult all
devels about whether it is a good idea to use the optional dependencies.
-
Check for dependencies that are no longer needed and remove them from the
FrugalBuild
-
Check GConf schemas. Sometimes they have been renamed, or new ones have been
added Not doing this can cause a lot of problems.
-
Check the Changelog and NEWS file for the package. Sometimes there may be
API/ABI changes that need to be considered before bumping.
-
Check if _F_gnome_{scrollkeeper,mime,desktop} are needed in the new version.
-
When all this has been done, update the FrugalBuild with new sha1sums,
pkgver, depends, GConf schemas and _F_gnome_* values (add gnome-scriptlet to
Finclude if necessary)
-
Build the package and push.
5.1. Introduction
The aim of this howto is to show what's the procedure of a stable Frugalware
release. The to-be-created release in this howto is 0.5, the previous release
is 0.4.
5.2. A testing release
Just because I don't know where to document this, here is the command line what
I use to sync changes from -current to -testing before a release:
$ rsync -avP --delete-after frugalware-current/ frugalware-testing/
5.3. Preparing
-
send a mail to -devel about "please stop version and release bumps"
-
check if the artwork has been updated completely. see
this
mail from Nadfoka on what items should be checked
-
ask someone to update the screenshots
-
sync the archs, checkpkgs shouldn't have any red pkg in it's output
-
run gensync to rebuild the fdbs
-
generate isos and test if everything is ok
(ie. install from cd1-cd2 on i686, and start kde, or something)
-
tag the release using git tag
5.4. Creating the stable tree
Copy the full tree on genesis:
$ cd /home/ftp/pub/frugalware
$ cp -av frugalware-current frugalware-0.5
5.5. Updating the -current tree
Now one have two tree. All what one should do in -current is to bump
—from-tag version to 0.5 in tools/genpkgs.
5.6. Updating the -stable tree
in the Makefile
- s/-current// in tools/mkpkglst
- update VERSION in docs/Makefile
- update `\.git/description`
- update kernel FrugalBuild to hardwire the kernel release (`\_F_kernel_rel`)
- update `/source/include/kernel-module.sh` (s/=/>=/) and rebuild the fdbs
again
- run the just modified genpkgs to regenerate the ChangeLog.txt to start from
the 0.4 tag to the 0.5 tag
- update pacman{,-tools} so that -stable will be the default on -Syu / repoman
upd, not -current
- upload the fdbs to the mysql db using fpm2db, just run all2db.sh from the
/tools dir
- create a new chroot tarball for each arch
5.7. Testing
-
generate isos, test all of them (net,cd,dvd for each arch)
-
create an usb stick installer tarball for each arch
-
create an tftp boot image for each arch
-
check if the upgrade from 0.4→0.5 works or not, probably a simple -Syu is
not enough, then write a howto and rebuild the manual
5.8. Announcement
-
put the isos online and wait at least 24h so that the mirrors will be in
sync at release time
-
create torrents for the isos and make sure at least one machine seeds them
-
add the new version to the bts
-
write an announcement, put it out to somewhere and ask Alex or LGee to
spellcheck it
-
push it to the homepage-ng repo
-
mark the release as "done" in /frugalware/xml/roadmap.xml (homepage-ng repo)
and add the proper newsid value
-
update the topic of #frugalware
-
update the freshmeat entry
5.9. For the next release
-
find a codename
-
update roadmap.xml
6.1. Introduction
This document details the requirements that must be met by all artwork
if it is to be accepted into the official Frugalware gallery.
6.2. The rules
-
All artwork must be licensed under the Free Art License 1.3
(full details).
-
Where the Frugalware logo appears, only the officially approved logo
may be used. Refer
here for the logo.
-
Artwork must be submitted in either SVG or XCF (The Gimp) format as
this allows for derivative works to be made without affecting the impact
of the original artwork. Examples of derivative works include wallpapers
in various sizes and height/width ratios, and/or KDM/GDM/SLiM themes.
To suit the varying sizes and ratios of monitors, any wallpaper must be
a minimum 1600 pixels wide and provided in both 4:3 and 16:9 ratios.
-
All artwork must be submitted together with any associated source
files - i.e. files which are required by the graphics editor used by
the entrant to reproduce and/or edit the artwork.
-
Only FLOSS software may be used to create the wallpaper.
-
Neither the release's version number, nor code-name are to appear in
artwork, or there should be a version without them for later use when
a given release is no longer supported.