DokuWiki Installer


This page assists in the first time installation and configuration of Dokuwiki. More info on this installer is available on it's own documentation page.

DokuWiki uses ordinary files for the storage of wiki pages and other information associated with those pages (e.g. images, search indexes, old revisions, etc). In order to operate successfully DokuWiki must have write access to the directories that hold those files. This installer is not capable of setting up directory permissions. That normally needs to be done directly on a command shell or if you are using hosting, through FTP or your hosting control panel (e.g. cPanel).

This installer will setup your DokuWiki configuration for ACL, which in turn allows administrator login and access to DokuWiki's admin menu for installing plugins, managing users, managing access to wiki pages and alteration of configuration settings. It isn't required for DokuWiki to operate, however it will make Dokuwiki easier to administer.

Experienced users or users with special setup requirements should use these links for details concerning installation instructions and configuration settings.

For security reasons this script will only work with a new and unmodified Dokuwiki installation. You should either re-extract the files from the downloaded package or consult the complete Dokuwiki installation instructions

driven by DokuWiki powered by PHP
Handling Security Issues [Mantis Bug Tracker Wiki]

User Tools

Site Tools


This is an old revision of the document!

Handling Security Issues

This document provides guidelines to report security issues in MantisBT, and describes the process we follow to deal with them internally.

For users

If you discover a security issue or what you think could be one, please Open a new issue in our bug tracker following the guidelines below.

  • Set Category to security 1)
  • Make sure that View Status is set to Private 2) so that your report is not visible to the general public (only MantisBT developers will have access to it).
  • Set the Product Version as appropriate; if necessary (e.g. when multiple versions are affected), include additional information in the Description field.
  • Provide a descriptive Summary and clear Description of the issue
  • Do not forget detailed Steps To Reproduce to facilitate our work in analyzing and fixing the problem
  • If you already have a patch for the issue, please attach it to the issue
  • Should you wish to be credited for the finding, kindly indicate it under Additional Information or in a bug note. Your name/e-mail/company will be included in the CVE report

One of the core team members will review, reply, ask for additional information as required. We will then discuss the means of fixing the vulnerability and agree on a calendar for disclosure. Generally this discussion takes place within the issue itself, but in some cases it may happen privately.

Note: do not submit a Github Pull Request or post on the mailing list, as these are public channels which would effectively disclose the security issue.

For developers

If you are notified of a security issue directly (e.g. by e-mail), start by logging the issue in the tracker as described in the section above.

Once the issue has been logged

  1. Take ownership of the issue
    • Assign it to yourself
    • Update Priority and Severity as appropriate
    • Set Target Version to the next stable release (e.g. “1.2.x”)
    • Make sure it is indeed Private
  2. Notify the rest of the core team about the vulnerability by adding them to the email thread / issue discussion3) (use the Send Reminder feature)
  3. Propose a fix by attaching a git patch to the issue 4)
  4. The original reporter as well should test the fix to confirm resolution
  5. If possible, at least one other MantisBT developer should review and test the fix as well

Once the fix has been tested

Feedback from the Reporter and a peer review confirm that the fix addresses the issue.

  1. Agree with the reporter to a timeline for disclosure
  2. Commit the fix to both the stable and development branches, and push to Github.
  3. CVE ID5) for the issue 6) as explained in the next section
  4. Once a CVE ID has been assigned, the bugtracker issue summary must be updated
    • Prefix the Summary with the CVE ID (see ~~Mantis:16513~~ for example)
    • Make the issue Public
    • Set Fixed in version
    • Mark it as Resolved / Fixed
  5. As soon as possible after disclosure, prepare a new security release for the affected MantisBT branches

Obtaining a CVE ID

Send an e-mail to the oss-security mailing list (does not require subscription) as per the following examples 1, 2.

The request must include:

  1. description of the issue, including but not limited to
    • type, e.g. XSS, sql injection…
    • which area of Mantis are affected
    • potential consequences of exploiting the bug
    • indication on severity
  2. affected MantisBT version(s)
  3. link to MantisBT issue
  4. optionally, information about the reporter (if available and they do not refuse to be quoted)
  5. information about the patch (i.e. where it can be found, commit SHA)
  6. optionally, attach the patch itself

Usually, the CVE ID gets assigned within one business day.

1) , 2)
This field will be preset if you use the above link
Do not use the Developer's mailing list to avoid early disclosure.
It is important not to leak information about the vulnerability by pushing fixes to the public Github repositories before the disclosure.
The oss-security mailing list is public, so requesting a CVE ID de facto discloses the vulnerability
mantisbt/handling_security_problems.1410610943.txt.gz · Last modified: 2014/09/13 08:22 (external edit)