Copyright (C) 2003-2007 The Frugalware Developer Team.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".

1. Security support

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

  1. The security team opens a new task in the BTS, with a [SEC] prefix.

  2. 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.

  3. 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.

  4. 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?

  1. Check if the backport is ready (the binary packages should be uploaded for each arch).

  2. Update the frugalware/xml/security.xml file in the homepage-ng repo and check if the mail is sent to the frugalware-security list. If not, then ask on -devel what can be the problem.

1.4. How to notice security issues

  1. Subscribe to Secunia Security Advisories List at http://secunia.com/secunia_security_advisories/ page. This is the best place to notice issues.

  2. Read the mails one-by-one and check if the advisory affects -current or -stable.

  3. Open a task in BTS if necessary. Please fill in the form correctly, provide a patch if you can.

You can also read other mailing list, like https://lists.grok.org.uk/mailman/listinfo/full-disclosure, but secunia monitors them, so you won't miss anything. (You just notice things later.)

1.5. How to get patches

Secunia announces sec issues days after they released so there is a good chance to find a patch.

  1. First of all sometimes upstream fixes it with a new version.

  2. Fixed in cvs/svn/whatever and you are able to find the patch (unlike PHP)

  3. 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.

  4. 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.

2. Handling git repositories

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

chmod g+w .git

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:

  1. Update the file .git/description inside the repo with a short (less than 80 chars) description.

  2. Create the file .git/owner inside the repo containing your name, without your email address.

  3. 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.

  1. If you want CIA notification.

  2. If you want sending mails to the Frugalware-git mailing list.

  3. 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!)

For the last one:

chmod +x .git/hooks/post-update

For the others:

ln -sf /home/ftp/pub/other/git-hooks/git-hooks.py .git/hooks/post-receive

3. This is a small tutorial for those who want to contribute to Frugalware

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:

# pacman-g2 -S git

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

Now you can make your changes. When finished run

$ git diff

in the repository.

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

$ git commit -a

to commit all your changes.

If you want to cherry-pick hunks from your changes:

$ dg record

or using native git commands:

$ git add -p; git commit

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

$ git log

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).

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:

What you should do:

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.

$ repoman push

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

Then you can use

$ git push

to send in your changes.

Note
 The dg push wrapper does exactly this for you.

4. GNOME Bump HOWTO

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:

  1. Download the new version's tarball and extract it

  2. 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.

  3. Check for dependencies that are no longer needed and remove them from the FrugalBuild

  4. Check GConf schemas. Sometimes they have been renamed, or new ones have been added Not doing this can cause a lot of problems.

  5. Check the Changelog and NEWS file for the package. Sometimes there may be API/ABI changes that need to be considered before bumping.

  6. Check if _F_gnome_{scrollkeeper,mime,desktop} are needed in the new version.

  7. 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)

  8. Build the package and push.

5. Frugalware Release HOWTO

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

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

STABLE = true
  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

5.8. Announcement

5.9. For the next release

Done!

6. Table of user / group ids used in Frugalware

Table: Users and groups that are added with a specific uid/gid
ID User Package Group Package
000 root shadow root shadow
001 bin shadow bin shadow
002 daemon shadow daemon shadow
003 adm shadow sys shadow
004 lp shadow adm shadow
005 sync shadow tty shadow
006 shutdown shadow disk shadow
007 halt shadow lp shadow
008 mail shadow mem shadow
009 news shadow kmem shadow
010 uucp shadow wheel shadow
011 operator shadow floppy shadow
012 syncpkgd pacman-tools mail shadow
013 news shadow
014 ftp shadow uucp shadow
015 man shadow
016 cdrom shadow
017 scanner shadow
018 privoxy privoxy privoxy privoxy
019 fst pacman audio shadow
020 nx freenx games shadow
021 slocate slocate
022 utmp shadow
023 camera shadow
024 video shadow
025 smmsp shadow smmsp shadow
026 clamav clamav clamav clamav
027 mysql shadow mysql shadow
028 rsyncd rsync rsyncd rsync
029 _ntp openntpd _ntp openntpd
030 storage shadow
031 pgdb postgresql pgdb postgresql
032 rpc shadow rpc shadow
033 sshd shadow sshd shadow
034 scponly scponly scponly scponly
035 sbox scratchbox
036 rlocate rlocate
037 netdev shadow
038 messagebus dbus messagebus dbus
039 hald hal hald hal
040 amavis amavisd-new amavis amavisd-new
041 ejabberd ejabberd ejabberd ejabberd
042 gdm shadow gdm shadow
043 shadow shadow
044 beagleindex beagle beagleindex beagle
045 partimag partimage partimag partimage
046 sabayon sabayon sabayon sabayon
047 munin munin and munin-node munin munin and munin-node
048 ccache ccache
049
050 ftp shadow
051 telnetd shadow
052
053
054
055
056
057
058
059
060 grsec_procview kernel-grsec
061 grsec_audit kernel-grsec
062 grsec_tpe kernel-grsec
063 grsec_s_all kernel-grsec
064 grsec_s_client kernel-grsec
065 grsec_s_server kernel-grsec
066
067
068
069
070
071
072
073 postfix postfix postfix postfix
074
075 postdrop postfix
076
077 dspam dspam dspam dspam
078
079
080 mailman mailman mailman mailman
081
082
083
084 avahi avahi avahi avahi
085 firebird firebird firebird firebird
086
087
088
089
090 pop shadow pop shadow
091
092
093
094
095
096
097
098 nobody shadow
099 nobody shadow nogroups shadow
100 shadow users shadow
101 shadow console shadow
102
103
104 distccd distcc distccd distcc
105
106
107
108
109 postgrey postgrey
110
111
112
113 logcheck logcheck logcheck logcheck
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397