Differences between revisions 3 and 69 (spanning 66 versions)
Revision 3 as of 2007-09-19 22:08:07
Size: 3988
Editor: DannFrazier
Comment: create a troubleshooting section, and add an entry for binNMUs
Revision 69 as of 2021-08-07 18:43:02
Size: 11834
Editor: ?SalvatoreBonaccorso
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
<<TableOfContents()>>

= Allocating a DSA Number =
The procedure for allocating a unique DSA number is to add an entry to `data/DSA/list` in the security-tracker repository. The `gen-DSA` script in the security-tracker repository takes care of this for you (see below). Please do this ''before'' releasing a DSA to avoid accidental duplication. In this commit you may also want to include the version number of the fixed package. For example:
{{{
 [squeeze] - libxml2 2.7.8.dfsg-2+squeeze2
 [lenny] - libxml2 2.6.32.dfsg-5+lenny5
}}}

Line 2: Line 12:
There now follows a worked example of issuing DSA-2156-1 for "pcsc".
Line 3: Line 14:
There now follows a worked example of issuing DSA-1317-1 for "tinymux". Always enter a screen first. The installation process runs for about 20 minutes, and it shouldn't be interrupted. If, for any reason, the command is terminated (disconnect, ^C, kill, etc.) '''archive breakage will occur'''.
Line 5: Line 16:
Run ``new-security-install``:
skx@klecker:$ cd /org/security.debian.org/queue/embargoed
skx@klecker:$ dak new-security-install DSA-1317 tinymux_2.4.3.31*etch1*.changes
Run `dak new-security-install`:
Line 9: Line 18:
Once this runs you'll be presented with a simple menu. There are two things you need to here - firstly press "E" to edit the advisory, making any changes you like, then press "A" to "accept" the packages. The advisory created with the "E"dit advisory step will be saved in /org/security.debian.org/advisories/drafts/dsa-1317. This is a location from which you should be able to edit the draft, but not rename it or move it. {{{
skx@seger:~$ screen
skx@seger:~$ cd /srv/security-master.debian.org/queue/embargoed/
Line 11: Line 22:
Note that the above editing feature isn't ready for production yet. This will hopefully be fixed soon. skx@seger:/srv/security-master.debian.org/queue/embargoed$ dak new-security-install pcsc*.changes
Non-dak user: skx
Would create ['/srv/security-master.debian.org/queue/embargoed/COMMENTS/ACCEPT.pcsc_1.2.3-4+squeeze1'] now and then go on to accept this package, if you allow me to.
Press Enter to continue
Locking unchecked
Installing accepted packages into security archive
Domination
Updating Packages and Sources files... This may take a while, be patient
Updating Release files...
Triggering security mirrors... (this may take a while)
...long pause...
Triggering metadata export for packages.d.o and other consumers
Lock released.
}}}

If you had the globbing incorrect you can still Ctrl-C at the "Press Enter to continue" prompt.

To generate the advisory:

{{{
user@host:~/security-tracker$ bin/gen-DSA 1317-1 tinymux "buffer overflow" CVE-2007-1655 417539
[The advisory text is previewed]

user@host:~/security-tracker$ bin/gen-DSA --save 1317-1 tinymux "buffer overflow" CVE-2007-1655 417539
[The advisory text is now saved in ./DSA-1317-1 and the data/DSA/list entry added]
}}}

If the DSA id has been used before the script will refuse to continue.
The script relies on the DEBFULLNAME and DEBEMAIL env vars that are used by devscripts. If you omit the DSA number the script will pick one for you.
The script will ask you for any of the fixed version numbers.

There's also `gen-DSA.py` which is similar. It obtains information from the queues and hence some parts need to be run on security-master. Check its documentation for the gory details.
Line 14: Line 57:
=== "Multiple advisories selected" ===
You might see errors which are related to a DSA already being used, this will manifest itself in errors like "Multiple advisories selected". To fix this run:
dak new-security-install --drop-advisory DSA-1234 package*.changes
=== Stable and oldstable sharing the same upstream tarball ===
Line 18: Line 59:
=== binNMUs ===
When doing binNMUs to fix a build-issue with a security update, you also need to do a --drop-advisory. For example, for DSA-1364 we needed to upload new builds for alpha, mips, and mipsel:
The first upload (and only the first upload) of any given fixed package to the security build system should include the upstream source (e.g. `dpkg-buildpackage -sa` or `pdebuild --debbuildopts -sa`). Use rmadison to find out whether the source is already in the security build archive.

If you have to upload which is new both for oldstable-security and stable-security and furthermore has the same orig tarball, special care needs to be applied when uploading the package. The first one you upload should be built with `-sa` to include the orig tarball. The second upload for the second suite then should not include the orig tarball in the upload.

Following this, both `dak new-security-install` and the subsequent upload to ftp.upload.debian.org will work.

=== Packages end up in security-master NEW queue ===

The built packages may end up in security-master's NEW queue instead of the (un)embargoed queues. This is the case when the package has a udeb.

You need to ask ftp-master to approve the packages from NEW. However, note that plainly approving them will install them into the security archive directly which is not what's normally desired. Ftp-master can add the override manually and then reprocess it through unchecked. Then it ends up in the embargoed queue like other packages.

=== There's an error in the advisory text ===

If after sending the DSA an error is discovered in the advisory text, it can be dealt with according to the severity of the error. In any case, it can always and should be corrected on the web version of the DSA. Commit an update to the www repository (or ask debian-www) as per the instructions below. If the error is significant, a clarification can be sent to debian-security@lists.debian.org. If it's really confusing, an updated advisory may be sent to the security announce list.

=== Fix was incomplete or introduced regressions ===

The released package did not (fully) fix the issue, or caused regressions. Create new flawless packages and have them built. Send out a new advisory with DSA-XXXX-1 replaced by DSA-XXXX-2. Use the first paragraph of the free form text to explain the regression and the fix, followed by "For reference, the original advisory text follows", followed by the original advisory text (for reference).

In data/DSA/list, -2 updates only get added if they have security impact (incomplete fix), not if it was a regression fix, because the latter doesn't change the fact that the actual vulnerability was fixed in the version released in -1.

=== The DSA refers to TEMP issues (issues with no CVE id assigned) ===

When the DSA report includes fixes to issues without CVE id assigned, the security tracker cannot build the cross-reference to `DSA/list`. Therefore, the information that the security upload fixes CVE-XXXX issues (a.k.a. TEMP issues) needs to be included manually. For example, DSA 3547-1 announces that imagemagick_8:6.7.7.10-5+deb7u4 fixes a vulnerability without an CVE id. The following line in `CVE/list` should be added manually:
Line 22: Line 86:
dannf@klecker:/org/security.debian.org/queue/embargoed$ dak new-security-install --drop-advisory vim_6.3-071+1sarge2+b1_alpha.changes vim_6.3-071+1sarge2+b1_mipsel.changes vim_6.3-071+1sarge2+b1_mips.changes
Non-dak user: dannf
Advisory: missing-archs-36
Changes:
 vim_6.3-071+1sarge2+b1_mips.changes
Packages:
 vim 1:6.3-071+1sarge2+b1 (mips)
Add vim_6.3-071+1sarge2+b1_alpha.changes to missing-archs-36? y
Add vim_6.3-071+1sarge2+b1_mipsel.changes to missing-archs-36? y
Advisory: missing-archs-36
Changes:
 vim_6.3-071+1sarge2+b1_mips.changes
 vim_6.3-071+1sarge2+b1_alpha.changes
 vim_6.3-071+1sarge2+b1_mipsel.changes
Packages:
 vim 1:6.3-071+1sarge2+b1 (alpha, mips, mipsel)
dannf@klecker:/org/security.debian.org/queue/embargoed$ dak new-security-install DSA-1364-2 vim_6.3-071+1sarge2+b1_alpha.changes vim_6.3-071+1sarge2+b1_mipsel.changes vim_6.3-071+1sarge2+b1_mips.changes
Non-dak user: dannf
Create new advisory DSA-1364-2? y
Advisory: DSA-1364-2
Changes:
 vim_6.3-071+1sarge2+b1_alpha.changes
 vim_6.3-071+1sarge2+b1_mipsel.changes
 vim_6.3-071+1sarge2+b1_mips.changes
Packages:
 vim 1:6.3-071+1sarge2+b1 (alpha, mips, mipsel)
Approve, [E]dit advisory, Disembargo, Show advisory, Reject, Quit? a
Advisory: DSA-1364-2
Changes:
 vim_6.3-071+1sarge2+b1_mipsel.changes
 vim_6.3-071+1sarge2+b1_alpha.changes
 vim_6.3-071+1sarge2+b1_mips.changes
Packages:
 vim 1:6.3-071+1sarge2+b1 (alpha, mips, mipsel)
Advisory in /org/security.debian.org/advisories/drafts/DSA-1364-2
Accepting packages...
Updating file lists for apt-ftparchive...
Updating Packages and Sources files...
Updating Release files...
Triggering security mirrors...
Uploading files to ftp-master.debian.org...
Uploading in the background
 CVE-2016-XXXX [Multiple minor security issues]
        - imagemagick 8:6.8.9.9-7 (bug #811308)
+ [wheezy] - imagemagick 8:6.7.7.10-5+deb7u4
        NOTE: CVE Request: http://www.openwall.com/lists/oss-security/2016/02/22/4
Line 66: Line 92:
= Sending out the announcement to debian-security-announce =
Mail the advisory template file to debian-security-announce@lists.debian.org with an appropriate subject.

It must satisfy the following conditions, or it may be silently dropped:
 * Subject "[DSA XXXX-1] xxx security update"
 * The template must be "gpg --clearsign"d
 * The signer must be a Debian Developer in the "security" group.
 * There is a signature cache to prevent replay attacks, so you need to make a new signature in case of an error.
 * The text "Mailing-List: debian-security-announce@lists.debian.org" must be in the body text.

If you use bin/gen-dsa to generate your DSA template, the following snippet can be used to send the mail, providing you have a correctly configured local MTA:

{{{
bin/sign-advisory.sh DSA-2498-1
/usr/lib/sendmail -ti < DSA-2498-1.signed
}}}

Note that if the advisory contains non-ASCII characters like in first or last names for credits, we need to send it as UTF-8. In this case the following two lines need to be added to the DSA text headers before signing the advisory with `sign-advisory.sh`:
 {{{
Content-Transfer-Encoding: 8bit
Content-type: text/plain; charset=UTF-8
}}}
Due to the announce list only accepting inline signed mails, it is though still recommended to only use ASCII in DSA announcements, and thus changing names of people to ASCII variants. It is known that Sylpheed has a bug that might sometimes result in wrong signature reported for users using non-UTF-8 locales (DebianBug:580896).

Make sure your MTA does not relay directly to gmail or another provider implementing DKIM: lists.debian.org rewrites the subject, and this breaks the DKIM signature.

If you send a DSA sponsoring a text prepared by someone else, make sure to set the `From:` to the person you are sending the mail on behalf of and the `Sender: ` to the address of the person actually sending and signing the mail.

= Tips for the DSA body text =

 * The description of the issues shouldn't be taken from MITRE, they have too much irrelevant detail (for our users) in their data. Better look at the patch and make sure you fully understand the issue and are able to write a text on your own, that's usually simpler and better
 * Try to give credit to the discoverer where it's known, e.g. "John Woo discovered that an integer overflow...". When they belong to an organisation or company, the company might need to be mentioned (e.g. "John Doe from IT corp".)
Line 67: Line 126:
Every announce is also published as a [[http://www.debian.org/security/#DSAS|webpage]]. Usually the website part is taken by a Debian website team member.
Line 68: Line 128:
Once the template has been created run parse-advisory.pl to create the approriate WML files:
skx@klecker:~/webwml/english/security$ ./parse-advisory.pl ~/dsa-1317-1
..
..
In order to create and upload this website page on your own, you have to be in the [[https://salsa.debian.org/webmaster-team/webwml|webwml project]]. If you are not, you can request to join it. The www team is happy when we upload our own web pages.
Line 73: Line 130:
Add the two new files to the CVS repository:
cvs add 2007/dsa-1317.wml 2007/dsa-1317.data
The relevant directory is [[https://salsa.debian.org/webmaster-team/webwml/tree/master/english/security|english/security/]], where you can find useful scripts and one directory for each year.
Line 76: Line 132:
See TODO for details on working with the Debian website and using WML generally. You will need commit access to issue advisories. Over the output of ./bin/gen-DSA (or the mail), you have to run [[ https://salsa.debian.org/webmaster-team/webwml/blob/master/english/security/parse-advisory.pl|parse-advisory.pl]] to create the appropriate WML files:
{{{
skx@klecker:~/webwml/english/security$ ./parse-advisory.pl ~/dsa-1317-1 .. ..
}}}
Line 78: Line 137:
TODO: Mention dsa-www script. Add the two new files to the Git repository:
{{{
git add 2007/dsa-1317.wml 2007/dsa-1317.data
}}}
Line 80: Line 142:
= Sending out the announcement to the debian-security-announce = And commit, using the advisory subject as message: {{{
git commit -m '[DSA 2510-1] extplorer security update'
}}}
and push it {{{
git push origin master
}}}.
Line 82: Line 149:
Mail the advisory template file to debian-security-announce@lists.debian.org with an appropriate subject. = Rejecting =
Line 84: Line 151:
The subject should be "[DSA XXXX-1] new xxx packages fix yyy". The advisory should also be saved into /org/security.debian.org/advisories/DSA for future reference. `dak new-security-install` does not support rejecting, you need an
{{{
echo NOTOK > COMMENTS/REJECT.package_version
}}}
in the queue directory.
For example, to reject ffmpeg-debian 0.svn20080206-18+lenny2:
Line 86: Line 158:
Note: The template must be "gpg --clearsign"d, or the mail to the list will not be accepted. {{{
echo NOTOK > /srv/security-master.debian.org/queue/embargoed/COMMENTS/REJECT.ffmpeg-debian_0.svn20080206-18+lenny2
}}}
After recieving the REJECTED mail a fixed upload might reuse the original version since dak on security masters performs the required cleanups (In former times this required a roundtrip to notify wb-team@buildd.d.o which is not needed anymore).

= BinNMUs =

Occasionally an issue can be fixed via binNMUs, e.g. if a source package has been fixed and another package has that package in its Built-Using field.

Note that the package to be binNMUed needs to be already in the security archive. Otherwise, a (no-change) sourceful upload is required.

They will end up in the policy queue as long as no package with the same version number has been accepted yet (which can happen with binNMU version skew between architectures). In the latter case, you just have to make sure there are no ACCEPT(ED) comments for the uploads.

Example used to reschedule the binNMU for `libxrender` after the fix for `libx11` for [[https://www.debian.org/security/2015/dsa-3224|DSA-3224-1]]:
{{{
user@buildd:$ wb nmu libxrender . ANY . wheezy-security . -m 'Rebuild against fixed libx11 for DSA 3224' --extra-depends 'libx11-dev (>= 2:1.5.0-1+deb7u2)'
}}}

Access to wb needs to be setup separately from security group membership. More details can be found at https://lists.debian.org/debian-wb-team/2015/05/msg00001.html.

{{{#!wiki warning
'''Warning'''

For multiarch enabled packages this possiblity is currently blocked by DebianBug:782596
}}}

= Give-Backs =
If a build fails (temporarily) you might want to give back the build and let try the buildds to build the binary package again. This can be done with the same syntax as described in [[https://release.debian.org/wanna-build.html|wanna-build]]:
{{{
user@buildd:$ wb gb iceweasel . armhf . -d wheezy-security
}}}

Allocating a DSA Number

The procedure for allocating a unique DSA number is to add an entry to data/DSA/list in the security-tracker repository. The gen-DSA script in the security-tracker repository takes care of this for you (see below). Please do this before releasing a DSA to avoid accidental duplication. In this commit you may also want to include the version number of the fixed package. For example:

 [squeeze] - libxml2 2.7.8.dfsg-2+squeeze2
 [lenny] - libxml2 2.6.32.dfsg-5+lenny5

Releasing an update

There now follows a worked example of issuing DSA-2156-1 for "pcsc".

Always enter a screen first. The installation process runs for about 20 minutes, and it shouldn't be interrupted. If, for any reason, the command is terminated (disconnect, ^C, kill, etc.) archive breakage will occur.

Run dak new-security-install:

skx@seger:~$ screen
skx@seger:~$ cd /srv/security-master.debian.org/queue/embargoed/

skx@seger:/srv/security-master.debian.org/queue/embargoed$ dak new-security-install pcsc*.changes
Non-dak user: skx
Would create ['/srv/security-master.debian.org/queue/embargoed/COMMENTS/ACCEPT.pcsc_1.2.3-4+squeeze1'] now and then go on to accept this package, if you allow me to.
Press Enter to continue
Locking unchecked
Installing accepted packages into security archive
Domination
Updating Packages and Sources files... This may take a while, be patient
Updating Release files...
Triggering security mirrors... (this may take a while)
...long pause...
Triggering metadata export for packages.d.o and other consumers
Lock released.

If you had the globbing incorrect you can still Ctrl-C at the "Press Enter to continue" prompt.

To generate the advisory:

user@host:~/security-tracker$ bin/gen-DSA 1317-1 tinymux "buffer overflow" CVE-2007-1655 417539
[The advisory text is previewed]

user@host:~/security-tracker$ bin/gen-DSA --save 1317-1 tinymux "buffer overflow" CVE-2007-1655 417539
[The advisory text is now saved in ./DSA-1317-1 and the data/DSA/list entry added]

If the DSA id has been used before the script will refuse to continue. The script relies on the DEBFULLNAME and DEBEMAIL env vars that are used by devscripts. If you omit the DSA number the script will pick one for you. The script will ask you for any of the fixed version numbers.

There's also gen-DSA.py which is similar. It obtains information from the queues and hence some parts need to be run on security-master. Check its documentation for the gory details.

Troubleshooting

Stable and oldstable sharing the same upstream tarball

The first upload (and only the first upload) of any given fixed package to the security build system should include the upstream source (e.g. dpkg-buildpackage -sa or pdebuild --debbuildopts -sa). Use rmadison to find out whether the source is already in the security build archive.

If you have to upload which is new both for oldstable-security and stable-security and furthermore has the same orig tarball, special care needs to be applied when uploading the package. The first one you upload should be built with -sa to include the orig tarball. The second upload for the second suite then should not include the orig tarball in the upload.

Following this, both dak new-security-install and the subsequent upload to ftp.upload.debian.org will work.

Packages end up in security-master NEW queue

The built packages may end up in security-master's NEW queue instead of the (un)embargoed queues. This is the case when the package has a udeb.

You need to ask ftp-master to approve the packages from NEW. However, note that plainly approving them will install them into the security archive directly which is not what's normally desired. Ftp-master can add the override manually and then reprocess it through unchecked. Then it ends up in the embargoed queue like other packages.

There's an error in the advisory text

If after sending the DSA an error is discovered in the advisory text, it can be dealt with according to the severity of the error. In any case, it can always and should be corrected on the web version of the DSA. Commit an update to the www repository (or ask debian-www) as per the instructions below. If the error is significant, a clarification can be sent to debian-security@lists.debian.org. If it's really confusing, an updated advisory may be sent to the security announce list.

Fix was incomplete or introduced regressions

The released package did not (fully) fix the issue, or caused regressions. Create new flawless packages and have them built. Send out a new advisory with DSA-XXXX-1 replaced by DSA-XXXX-2. Use the first paragraph of the free form text to explain the regression and the fix, followed by "For reference, the original advisory text follows", followed by the original advisory text (for reference).

In data/DSA/list, -2 updates only get added if they have security impact (incomplete fix), not if it was a regression fix, because the latter doesn't change the fact that the actual vulnerability was fixed in the version released in -1.

The DSA refers to TEMP issues (issues with no CVE id assigned)

When the DSA report includes fixes to issues without CVE id assigned, the security tracker cannot build the cross-reference to DSA/list. Therefore, the information that the security upload fixes CVE-XXXX issues (a.k.a. TEMP issues) needs to be included manually. For example, DSA 3547-1 announces that imagemagick_8:6.7.7.10-5+deb7u4 fixes a vulnerability without an CVE id. The following line in CVE/list should be added manually:

 CVE-2016-XXXX [Multiple minor security issues]
        - imagemagick 8:6.8.9.9-7 (bug #811308)
+       [wheezy] - imagemagick 8:6.7.7.10-5+deb7u4
        NOTE: CVE Request: http://www.openwall.com/lists/oss-security/2016/02/22/4

Sending out the announcement to debian-security-announce

Mail the advisory template file to debian-security-announce@lists.debian.org with an appropriate subject.

It must satisfy the following conditions, or it may be silently dropped:

  • Subject "[DSA XXXX-1] xxx security update"
  • The template must be "gpg --clearsign"d
  • The signer must be a Debian Developer in the "security" group.
  • There is a signature cache to prevent replay attacks, so you need to make a new signature in case of an error.
  • The text "Mailing-List: debian-security-announce@lists.debian.org" must be in the body text.

If you use bin/gen-dsa to generate your DSA template, the following snippet can be used to send the mail, providing you have a correctly configured local MTA:

bin/sign-advisory.sh DSA-2498-1
/usr/lib/sendmail -ti < DSA-2498-1.signed

Note that if the advisory contains non-ASCII characters like in first or last names for credits, we need to send it as UTF-8. In this case the following two lines need to be added to the DSA text headers before signing the advisory with sign-advisory.sh:

  • Content-Transfer-Encoding: 8bit
    Content-type: text/plain; charset=UTF-8

Due to the announce list only accepting inline signed mails, it is though still recommended to only use ASCII in DSA announcements, and thus changing names of people to ASCII variants. It is known that Sylpheed has a bug that might sometimes result in wrong signature reported for users using non-UTF-8 locales (580896).

Make sure your MTA does not relay directly to gmail or another provider implementing DKIM: lists.debian.org rewrites the subject, and this breaks the DKIM signature.

If you send a DSA sponsoring a text prepared by someone else, make sure to set the From: to the person you are sending the mail on behalf of and the Sender:  to the address of the person actually sending and signing the mail.

Tips for the DSA body text

  • The description of the issues shouldn't be taken from MITRE, they have too much irrelevant detail (for our users) in their data. Better look at the patch and make sure you fully understand the issue and are able to write a text on your own, that's usually simpler and better
  • Try to give credit to the discoverer where it's known, e.g. "John Woo discovered that an integer overflow...". When they belong to an organisation or company, the company might need to be mentioned (e.g. "John Doe from IT corp".)

Creating website pages

Every announce is also published as a webpage. Usually the website part is taken by a Debian website team member.

In order to create and upload this website page on your own, you have to be in the webwml project. If you are not, you can request to join it. The www team is happy when we upload our own web pages.

The relevant directory is english/security/, where you can find useful scripts and one directory for each year.

Over the output of ./bin/gen-DSA (or the mail), you have to run parse-advisory.pl to create the appropriate WML files:

skx@klecker:~/webwml/english/security$ ./parse-advisory.pl ~/dsa-1317-1 .. ..

Add the two new files to the Git repository:

git add 2007/dsa-1317.wml 2007/dsa-1317.data

And commit, using the advisory subject as message:

git commit -m '[DSA 2510-1] extplorer security update'

and push it

git push origin master

.

Rejecting

dak new-security-install does not support rejecting, you need an

echo NOTOK > COMMENTS/REJECT.package_version

in the queue directory. For example, to reject ffmpeg-debian 0.svn20080206-18+lenny2:

echo NOTOK > /srv/security-master.debian.org/queue/embargoed/COMMENTS/REJECT.ffmpeg-debian_0.svn20080206-18+lenny2

After recieving the REJECTED mail a fixed upload might reuse the original version since dak on security masters performs the required cleanups (In former times this required a roundtrip to notify wb-team@buildd.d.o which is not needed anymore).

BinNMUs

Occasionally an issue can be fixed via binNMUs, e.g. if a source package has been fixed and another package has that package in its Built-Using field.

Note that the package to be binNMUed needs to be already in the security archive. Otherwise, a (no-change) sourceful upload is required.

They will end up in the policy queue as long as no package with the same version number has been accepted yet (which can happen with binNMU version skew between architectures). In the latter case, you just have to make sure there are no ACCEPT(ED) comments for the uploads.

Example used to reschedule the binNMU for libxrender after the fix for libx11 for DSA-3224-1:

user@buildd:$ wb nmu libxrender . ANY . wheezy-security . -m 'Rebuild against fixed libx11 for DSA 3224' --extra-depends 'libx11-dev (>= 2:1.5.0-1+deb7u2)'

Access to wb needs to be setup separately from security group membership. More details can be found at https://lists.debian.org/debian-wb-team/2015/05/msg00001.html.

Warning

For multiarch enabled packages this possiblity is currently blocked by 782596

Give-Backs

If a build fails (temporarily) you might want to give back the build and let try the buildds to build the binary package again. This can be done with the same syntax as described in wanna-build:

user@buildd:$ wb gb iceweasel . armhf . -d wheezy-security