Initial conversion pass

227 files changed, 23105 insertions, 0 deletions

diff --git a/raw-wiki-dump/ASICImplementations.md b/raw-wiki-dump/ASICImplementations.md
new file mode 100644
index 0000000..dc21bf9
--- /dev/null
+++ b/raw-wiki-dump/ASICImplementations.md
@@ -0,0 +1,106 @@
+# Development of a Cryptech ASIC Implementation
+
+## Introduction
+The aim of the Cryptech project is to develop an open, free, and
+auditable HSM.  The Cryptech HSM includes both SW and HW parts.  In at
+least the first iteration of the Cryptech HSM, the HW parts are
+implemented using FPGA devices.  However, the ability to implement the
+HW parts in a Cryptech ASIC device in a future iteration is anticipated
+in the design.  This text provides a short description of what the HW
+part of the Cryptech HSM contains, the design style used, and what would
+have to change in order to implement the HW part in an ASIC.
+
+
+## General digital functions and internal memories
+The Cryptech digital functionality cores, such as the SHA-256 core, are
+written in generic RTL (Register Transfer Level) Verilog code.  The code
+is written in a fairly conservative coding style and use language
+features from IEEE 1364-2001 (aka Verilog 2001).
+
+All RTL code is divided into modules that contain one process for register updates and reset (*reg_update*), one or more combinational processes for datapath and support logic such as counters. Finally if needed, each module has a separate process that implements the logic for the final state machine that controls the behaviour of the module.
+
+All cores are divided into a core, for example *sha256_core.v* and a number of submodules the core instantiates. The core provides raw, wide ports (256 bit wide key for AES for example) that is not suitable to use in a stand alone system. Instead each core comes with a top level wrapper, for example *sha256.v*. This top level wrapper contains all registers and logic needed to provide all functionality of the core via a simple 32-bit memory like interface. If the core is going to be used as a tightly integrated submodule, the wrapper can be discarded. Similarly, if the core is going to be used in a bus system that use a specific bus standard such as AMBA AHB, CoreConnect or WISHBONE, only the top level wrapper will be needed to be replaced or modified to match the desired bus standard.
+
+The RTL code does not explicitly instantiate any hard macros such as
+memories, multipliers, etc.  Instead all such functions are left to the
+synthesis tool to infer based on the code. All memories are placed in separate modules to allow easy modification of the design. In an ASIC setting any memories not automatically mapped will be replaced by instantiation of specific macros.
+
+Some of the memories in the designs have combinational read (i.e the read
+data is not locked by an output register, which infers a one cycle read
+latency). For some FPGA technologies these memories are not compatible with the available physical memories. The synthesis tools therefor implement these memories
+using separate registers rather than selecting a memory instance.  In an ASIC
+implementation these memories would likely become real memory macros to allow for a faster and more compact implementation.
+
+
+## Interfaces
+External interfaces such as GPIO, Ethernet GMII, UART, etc., will always
+require some modification for the Cryptech design to be implemented in a
+given technology, whether it is a specific FPGA type or an ASIC.  The
+important thing is that the Cryptech design does not use technology
+specific macros to implement the interfaces.  But pin assignments,
+timing, and electrical requirements will always require adjustment and
+work.
+
+
+## Clocking and reset
+The design style used in the Cryptech Verilog code currently follows the
+guidelines from the FPGA vendors Altera and Xilinx.  This means that we
+use synchronous reset.  For an ASIC implementation this will also work,
+even though asynchronous reset is far more common in ASIC designs.  Changing
+to asynchronous reset is not a very big undertaking however, as the
+register reset and update clocking are separated into easily
+identifiable processes (*reg_update*) in the modules.
+
+Most if not all registers in the Cryptech Verilog code have a defined
+reset state.  Most registers also have a write enable signal that
+controls the update.  This corresponds well with the registers available
+in FPGA technologies from Altera and Xilinx and their recommended design strategy from the vendors. This is also in line with common
+and good design styles for ASICs, which allows for compact code and low
+power implementations. The design is currently not use any clock gating. In future revisions this might be added if power consumption needs to be reduced and does not add side channel issues.
+
+
+## External memories
+The Cryptech hardware design will use external persistent memories for
+protected key storage as well as external SRAM for protected master key
+storage.  In an ASIC implementation the master key memory would probably
+be integrated to further enhance security.
+
+Just like other external interfaces (see above), the interfaces for the
+external memories do not use any explicitly instantiated hard macros in
+the FPGAs.
+
+
+## Entropy sources
+The current Cryptech design contains two separate physical entropy
+sources.
+
+1: An avalanche noise based entropy source placed outside the FPGA.  The
+entropy source signal is sampled by the FPGA using a flank detection
+mechanism.
+
+An ASIC implementation would be able to use the external entropy source just like the FPGA. Furthermore, depending on the process options, it might be
+possible to have an internal avalanche diode based on ESD structures commonly used in I/O pin implementations. In a power management capable process, functionality available in step-up converters might also be possible to use as internal avalanche noise source.
+
+Note that integrating the avalanche noise source does not mean that an off-chip noise source is excluded. The Cryptech RNG is modular and having both an internal and an external avalanche noise source is quite possible.
+
+2: A ring oscillator based entropy source placed inside the FPGA. The ring oscillator used in the FPGA is based on carry chain feedback through adders. An ASIC implementation of this ring oscillator should work and produce noise with similar characteristics. However the specific circuit will have to be characterized with explicit layout and qualified for the given process.
+
+
+## Toolchain
+Crypech currently use Verilog simulators for functional verification and commercial FPGA tools for implementation including time analysis.
+
+An ASIC implementation will require several new tools including tools for synthesis, place & route and static time analysis that is acceptable as sign-off tool by the chip process vendor.
+
+
+## Conclusions
+The HW designed for the first iteration of Cryptech is not specifically
+designed for FPGA implementation, but is in fact designed in a generic
+way to allow for easy implementation using different technologies such
+as ASICs.
+
+There are however parts of the design that will have to be updated or
+modified in order to create a good ASIC implementation.  The Cryptech
+project is confident that we know what those parts are and what they
+would entail.
+
+Developing an ASIC will however require new tools which will incur costs.
diff --git a/raw-wiki-dump/AlphaBoard.md b/raw-wiki-dump/AlphaBoard.md
new file mode 100644
index 0000000..9dd7fee
--- /dev/null
+++ b/raw-wiki-dump/AlphaBoard.md
@@ -0,0 +1,36 @@
+# Alpha Board
+
+## Rev 02
+
+### Components
+
+
+- ARM Processor:  [STM32F429](http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series/stm32f429-439.html)
+- FPGA: [Xilinx Artix-7 XC7A200T-1](http://www.xilinx.com/products/silicon-devices/fpga/artix-7.html)
+- Tamper Circuit: [ATtiny828](http://www.atmel.com/devices/ATTINY828.aspx)
+
+
+
+
+### Status LEDs
+
+| ID | Color | Meaning |
+|---|---|---|
+| 01 | Green  | ARM LED 2                             |
+| 02 | Red    | ARM LED 4                             |
+| 03 | Blue   | ARM LED 1                             |
+| 04 | Yellow | ARM LED 3                             |
+| 05 | Yellow | Application Access USB UART Rx        |
+| 06 | Green  | Application Access USB UART Tx        |
+| 07 | Yellow | Management Access USB UART Rx         |
+| 08 | Green  | Management Access USB UART Tx         |
+| 09 | Green  | AVR LED 2                             |
+| 10 | Red    | AVR LED 4                             |
+| 11 | Blue   | AVR LED 1                             |
+| 12 | Yellow | AVR LED 3                             |
+| 13 | Red    | FPGA Config NOT DONE                  |
+| 14 | Red    | FPGA LED 3                            |
+| 15 | Green  | FPGA LED 1                            |
+| 16 | Yellow | FPGA LED 2                            |
+| 17 | Blue   | FPGA LED 0. [Toggles with sys_clk when FMC is active.](https://trac.cryptech.is/browser/core/comm/fmc/src/rtl/fmc_indicator.v) |
+| 18 | Green  | Power OK                              |
diff --git a/raw-wiki-dump/AlphaBoardComponents.md b/raw-wiki-dump/AlphaBoardComponents.md
new file mode 100644
index 0000000..ba8ba53
--- /dev/null
+++ b/raw-wiki-dump/AlphaBoardComponents.md
@@ -0,0 +1,308 @@
+# CrypTech Alpha Board BOM and PCB design requirement sketch
+This document contains a list of component level description and requirements for the Crypteh Alpha board.[[BR]]
+The document is to be used as a BOM (Bill Of Materials) and PCB design requirement description for discussing with PCB designers on what we want to have designed.[[BR]]
+The block diagram for the Alpha board can be seen at: [wiki:Hardware]
+
+The Alpha board basically consists of three major sub systems:[[BR]]
+1. **The FPGA Sub System**[[BR]]
+   Used to implement CrypTech crypto/security cores accessible by the CPU as coprocessors.[[BR]]
+
+2. **The CPU Sub System**[[BR]]
+   Talks to host systems and handles incoming commands. Basically implements the application interface.
+   Controls the FPGA Sub System. The CPU Sub System is heavily inspired/based on the CPU parts of the Novena and the iMX6 Rex boards.[[BR]]
+
+3. **The Tamper Detect Sub System**[[BR]]
+   Responsible for implementing tamper detection and control/alarm as a separate functionality from the CPU.
+   On the Alpha board this system is fairly simplistic. But we want to at least have a minor MCU that can run
+   independently on battery power and control the Master Key Memory (MKM). detect external events and generate
+   alarms. This allows us to start developing and reason about tamper detection and monitoring separately from the CPU.
+
+The Alpha board should preferably be a single board with all three sub systems on the same board.
+
+We are currently using the [Novena] board, and the Alpha board CPU Sub System functionality from is based on the Novena. We also have a trust in the [http://www.imx6rex.com/ "iMX6 Rex"](http://www.kosagi.com/w/index.php?title=Novena_Main_Page) board. Using the the Novena and/or iMX6 Rex as basis for the Alpha board design might (should) be a good way forward.
+
+
+### Authors and timeline/revision history
+Joachim Strömbergson, Fredrik Thulin
+
+
+* 2015-03-25: Updates from group and maillist discussions. Sync with the diagram.
+* 2015-03-16: Updates from group discussions.
+* 2015-03-09: Work started. Initial versions with headers for all blocks.
+
+
+
+# FPGA Sub System
+
+###  FPGA
+The board should be equipped with a Xilinx Artix-7 200T FPGA device, more specifically XC7A200T FBG484 speed grade -3.
+
+* [Xilinx Artix-7 XC7A200T FBG484.][[BR]](http://www.xilinx.com/products/silicon-devices/fpga/artix-7.html)
+* [Product family overview][[BR]](http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf)
+
+
+The FPGA pad layout should be compatible with the Xilinx Artix-7 FGG484 used by XC7A100T and XC7A75T.
+
+
+### FPGA Clocking and Reset
+
+* There should be a separate clock, fpga_clk, for the FPGA that starts providing a clock signal at power up. The base frequency for fpga_clk should be 50 MHz.
+* There should be a separate reset circuitry for the FPGA that resets the FPGA at power up and make the FPGA read the configuration from the confguration memory.
+* The ARM CPU should be able to reset the FPGA to force it reload the confiuration from configuration memory. The CPUY should be able to reset the FPGA by asserting a GPIO. The ability of the CPU to force reset should be possible to remove by removing a jumper.
+
+
+
+### FPGA CPU Interface
+
+* The FPGA is connected to the CPU using the i.MX6 EIM interface.
+* The data width is 16 bits.
+* The address width is 24 bits.
+* The data bus and address bus should be separate buses between the CPU and the FPGA.
+* The clock frequency of the EIM interface layout should support 66 MHz clock frequency.
+* There should be at least three separate digital signals connected between the FPGA and GPIOs on the CPU to be able to send interrupt/events from the FPGA to the CPU. Things like RSA operation completed to internal alarms. (Slow signals.)
+
+
+
+### FPGA Debug Interface
+
+* The FPGA JTAG interface should be available on a header. The header shall be compatible with the [Xilinx Platform Cable USB II](http://www.xilinx.com/support/documentation/data_sheets/ds593.pdf).
+
+
+
+### FPGA Extras
+
+* 8 LEDs connected to output pins on the FPGA. For general debug uses.
+* 4 LEDs connected to output pins on the FPGA. For heartbeat and status signalling.
+* 100-mil header with VCC+GND+8 pins connected to pins on the FPGA for general input/output. Slow speed, 3v3 TTL. Some ESD protection would be considered good.
+
+
+
+### FPGA Configuration and Configuration Memory
+
+* The FPGA should read it's bitstream from the FPGA config memory by itself (Master mode).
+* The FPGA is connected to the config memory with an SPI interface.
+
+
+
+* The ARM CPU should be able to download a bitstream into config memory by stealing the SPI interface.
+* The ability to steal the SPI interface is implemented using a transparent MUX controlled by the CPU. The MUX control and the SPI interface to the MUX from the CPU should be possible to remove by removing jumper for the signals mux_ctrl, MISO, MOSI, MCLK.
+
+
+
+* Suggestion for FPGA config memory is ["M25P128 EEPROM from Micron"](http://www.micron.com/parts/nor-flash/serial-nor-flash/m25p128-vme6gb), with a jumper controlling the write-enable pin.
+* Suggested MUX is the Quad 2-channel Analog Switch: ON Semi. MC14551B [http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF](http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF)
+
+
+
+### External RAM and Flash
+No external RAM or Flash memories for FPGA application functionality shall be present and is connected to the FPGA on the Alpha board.
+
+
+### Master Key Memory
+
+* The Master Key Memory (MKM) is a serial SRAM memory.
+* The MKM is connected to the FPGA with a SPI interface.
+
+  The MKM is connected to the Tamper Sub System with the same SPI interface.
+
+* The FPGA can read and write to the memory.
+* The Tamper Sub System controller can read and writeto the memory. Optionally the MISO input wire to the Tamper Sub System can be tied low by setting using a jumper. This should cause the tamper controller to only read zeros from the memory and thus only be able to write to the memory. The Tamper Sub System Controller has strict priority over the CPU. Basically an external switch between the memory, the controller and CPU.
+* The MKM is powered by a separate power supply using a CR2032 cell battery. The VCC pin connected to the battery should be under control from the Tamper Sub System controller. A transistor or analog switch controlled by the Tamper Sub System controller.
+
+
+Suggested components for the MKM and the switch:
+
+* Memory: Microchip serial SRAM. 23A640, 8 kByte, 8-TSSOP or 8-SOIC
+
+[http://ww1.microchip.com/downloads/en/DeviceDoc/22127a.pdf][[BR]](http://ww1.microchip.com/downloads/en/DeviceDoc/22127a.pdf][[BR])
+
+
+* Quad 2-channel Analog Switch: ON Semi. MC14551B
+
+[http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF](http://www.onsemi.com/pub_link/Collateral/MC14551B-D.PDF)
+
+
+### Entropy Sources
+
+* The avalanche noise entropy source should be implemented according to [attachment:alpha_board_noise_source.pdf existing schematics].
+* The noise source should have a shielding can and suitable ground plane etc. to keep radiation of entropy bits as low as possible.
+* The "12-15v stable" VCC should be controllable by the FPGA (enable/disable  controlled by output pin on FPGA) to increase life time of components.
+
+  Power requirements for this VCC is < 100 mA (needs measuring, but probably < 50 mA).
+
+
+# Processor Sub System
+
+### CPU
+The main CPU is a ST Microelectronics STM32F429BIT6 Cortex-M4 based MCU running at 180 MHz. The package used is the 208 pin LQFP.
+
+* [Reference Manual](http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/DM00031020.pdf) (pdf)
+* [Product Specification](http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00077036.pdf) (pdf)
+* [Data Sheet](http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00077036.pdf) (pdf)
+
+
+
+### Host Interface
+
+* USB interface. USB 2.0 Full Speed compliant.
+* USB interface implemented using an external USB-UART interface chip connected to a high speed (3 Mbps capable) UART interface on the CPU.
+* Suggested USB-UART component:
+* http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf
+* LQPF48 packaging
+
+
+
+### Authenticator, Management and Backup Interface
+
+* USB interface. USB 2.0 Full Speed compliant.
+* USB interface implemented using an external USB-UART interface chip connected to a high speed (3 Mbps capable) UART interface on the CPU.
+* Suggested USB-UART component:
+* http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf
+* LQPF48 packaging
+
+
+
+### External Storage
+
+* SD Card connected as Micro SD card with 4 bit data interface (like the Novena.)
+* Support for at least 2 GByte.
+
+
+
+### External RAM
+The STM32 CPU supports two separate SDRAM banks. We use both of them with as big SDRAM chips we can find for each bank. The chip used is 64 MByte for a total of 128 Mbyte RAM.
+
+* ["ISSI IS45S32160F 64 MByte SDRAM with 32 bit data interface"](http://www.issi.com/WW/pdf/42-45R-S-32160F.pdf)
+
+
+
+### Real Time Clock
+
+* Battery backed RTC with calendar/date information.
+
+  Connected to the CPU via serial, SPI or other interface.
+
+* Suggested chip: Microchip MCP79411 or MCP79412 connected to the CPU via I2C.
+
+  [http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP79411][[BR]](http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP79411][[BR])
+  [http://ww1.microchip.com/downloads/en/DeviceDoc/20002266G.pdf][[BR]](http://ww1.microchip.com/downloads/en/DeviceDoc/20002266G.pdf][[BR])
+  This chip requires an external 32 kHz crystal.
+
+* Note: these chips contain per chip unique IDs as well as small EEPROM memory that can be memory protected.
+
+
+
+### Keystore
+
+* The keystore memory is a non volatile memory (NVRAM, EEPROM, Flash) with size of at least 8 MByte
+* The keystore memory is connected to the CPU via a separate SPI interface.
+
+
+
+### CPU Debug port
+
+* CPU JTAG on header.
+
+
+
+### CPU Misc
+
+* Four LEDs conneced to the GPIOs on the CPU to allow heartbeat as well as status and debug signalling.
+* We want 8 general I/Os with direction controlled by the CPU. The I/O:s should be present on a header. One purpose for these I/O:s is to connect:
+* Keypad and LCD display
+* Smartcart reader via I2C
+* Bitbanged serial port for debugging
+
+
+We may implement this keypad, smartcard reader and display using a simple MCU based board.
+
+
+### CPU Interfaces Needed
+SPI Interfaces
+
+* FPGA Config memory
+* Key storage memory
+* Master Key memory
+
+
+FPGA Interface
+
+* EIM interface
+
+
+Asynch serial ports (UARTs)
+
+* Host interface (high speed)
+* Management interface (high speed)
+* Tamper Sub System
+
+
+Memory Interfaces
+
+* DDR3
+* External SD Flash memory
+
+
+GPIOs
+
+* 3 signals from FPGA to CPU for signalling
+* 1 signal from CPU to FPGA reset circuit to force reset
+* 1 signal from CPU to FPGA confgig mem mux for control
+* 3 signals from Tamper Sub System controller to CPU
+
+
+
+# Tamper Sub System
+The Tamper Sub System on the Alpha Board is simplistic and does not do a lot of detection. But the sub system should be there to allow us to test and develop tamper detection mechanisms.
+
+### Tamper Sub System Controller
+
+* A simple 8-bit MCU. Atmel AVR.
+* Suggested chip: ATTINY828R-AU. Has 28 GPIOs which is definitely more than we've used for this design.
+* The Tamper Detection Sub System Controlller may need a separate 32 kHz crystal for periodical wake up.
+
+  (The MCU should be able to wake up based on internal clock source.)
+
+* The JTAG interface for debug and firmware download should be accessible via a header.
+* The MCU should at least have four LEDs under GPIO control to allow heartbeat, status and debug signalling.
+
+
+
+### CPU interface
+
+* A simple serial (UART) interface between the CPU and the controller. The serial interface can be removed by removing jumpers.
+* One or a couple separate signals for event signalling from the Tamper Detection Sub System to the CPU Sub System. Slow speed 3V3 LVTTL.
+
+
+
+### Tamper Detection Mechanisms
+
+* A separate push button connected to the controller.
+* Possibly using the internal temperature detection in the MCU.
+* At least four digital input pins on a header for four different digital (HIGH) tamper detection mechanisms.
+* At least two digital output pins on a header for four different digital (HIGH) tamper alarms.
+
+
+
+### Tamper Power Supply
+
+* Battery backed. CR2032 cell battery.
+
+
+
+# Board Form Factor and Power Supply
+## Form factor
+Reasonable small to easily fit all functionality
+Holes to allow mounting the boards using board distances.
+
+## Power Supply
+Power Supply similar to the Power Supply on the Novena.
+7-19V nominal range. 2.5A typical. Max 3A at 12V.
+
+The board is powered from 18V (or 24V) DC from a standard external power supply.
+It should be possible to power the board with a external 110V AC at 60 Hz and 230V AC at 50 Hz.
+
+The on board power supply block should provide a number of voltage supplies needed by the board. We need at least 5V, 3.3V, 2.5V 1.8V, 1.375V.
+We also need a stable, low noise 12V voltage supply to power the Cryptech Avalanche noise source.
+
+The board designer should provide information about the power consumtion for the board. What is the current required at 12V?
diff --git a/raw-wiki-dump/AlphaBoardPictures.md b/raw-wiki-dump/AlphaBoardPictures.md
new file mode 100644
index 0000000..08c7d68
--- /dev/null
+++ b/raw-wiki-dump/AlphaBoardPictures.md
@@ -0,0 +1,12 @@
+
+## High resolution pictures of the Alpha board
+
+Attached to this page are high resolution pictures.
+
+The current revision of the Alpha board is rev03.
+
+rev01 was the board known as the 'dev-bridge'.
+rev02 was functionally the same as the rev03, but in another form factor.
+
+[[Image(Alpha_rev03_top_med.jpg)]]
+[[Image(Alpha_rev03_bottom_med.jpg)]]
diff --git a/raw-wiki-dump/AlphaBoardReview.md b/raw-wiki-dump/AlphaBoardReview.md
new file mode 100644
index 0000000..98b3d33
--- /dev/null
+++ b/raw-wiki-dump/AlphaBoardReview.md
@@ -0,0 +1 @@
+## Alpha board Layout review
diff --git a/raw-wiki-dump/AlphaBoardStrategy.md b/raw-wiki-dump/AlphaBoardStrategy.md
new file mode 100644
index 0000000..e7f36a2
--- /dev/null
+++ b/raw-wiki-dump/AlphaBoardStrategy.md
@@ -0,0 +1,57 @@
+# The Cryptech Alpha Board
+
+## Goal
+Develop a first, custom HSM board that can be used to support a first set of applications as well as being used for further development of new functionality as well as security mechanisms such as tamper detection and protection, key storage etc. Deadline is to produce palpable results before summer, 2015.
+
+
+* The use cases and requirements for the alpha board are specified on the [Dashboard](http://trac.cryptech.is/wiki/Dashboard).
+* The basic blocks of the Alpha board is [wiki:Hardware "shown here"].
+* The [wiki:AlphaBoardComponents "BOM and component requirements"].
+* The detailed ["Alpha board functional drawing"](http://trac.cryptech.is/browser/doc/design/Alpha_board_drawing.pdf).
+
+
+
+## Plan
+1. Choose FPGA and ARM (done)
+2. Develop BOM, requirements and functional diagram (done-ish).
+3. Develop complete [wiki:AlphaSchematics "schematics"] (almost done).
+4. Develop dev-board ouorselves to connect chosen ARM to FPGA on Novena, to do some early development and testing in parallell with step 5.
+5. Get professional designer to do many-layer PCB from schematics.
+6. Manufacture a couple of boards (~10).
+7. Bug fix hardware+software.
+8. Make beta design.
+9. Manufacture more boards (~50).
+
+
+## Way forward
+
+We currently use the Novena as a dev-board. It has a ["Freescale i.MX6 CPU (ARM Cortex A9)"], and a Xilinx Spartan-6 LX45 CSG324-packaged FPGA.[[BR]](http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&tab=Documentation_Tab&pspll=1&SelectedAsset=Documentation&ProdMetaId=PID/DC/i.MX6Q&fromPSP=true&assetLockedForNavigation=true&componentId=2&leftNavCode=1&pageSize=25&Documentation=Documentation/00610Ksd1nd%60%60Data%20Sheets&fpsp=1&linkline=Data%20Sheets)
+
+We want to over-size rather than under-size the FPGA on the Alpha board. The biggest FPGA from Xilinx/Altera that does not require tools with a commercial license that we've found is the ​Xilinx Artix-7 XC7A200T FBG484.
+
+We've only considered ARM CPUs. Either about the size of Cortex M3 / M4 (or future M7) or Cortex A8 / A9.[[BR]]
+A design with an A8/A9 turned out to be unattractive from a complexity and price point of view, so we're going to use one of the biggest M4 we could find. STM32F429.
+
+
+We are currently using a Freescale proprietary interface called EIM between the ARM and the FPGA on the Novena. EIM is not available with microcontrollers from ST, so we will use a similar interface made for connecting the ARM to external memory (called FMC). This interface runs at speeds up to 90 MHz, which is more than we are going to be using with our current FPGA cores.
+
+
+
+## Risks at this point
+
+1. Taking too long deciding on what the Alpha board should contain.
+2. Ordering PCB design and manufacturing boards that just does not work for our purposes.
+3. Getting Alpha boards that require too much time to get working.
+
+
+## Conclusion
+
+Use a high-end Cortex-M4 ARM.[[BR]]
+There is a huge difference in complexity between M4 and A9, mainly because of the DDR3 memory used with A9. An M4 design will both be easier to design, cheaper to both design and build and will be fast enough for all our early use cases anyways.
+
+
+Do not use the exact same FPGA, as it is too small to fit everything we need.[[BR]]
+
+
+Develop full schematics in-house.[[BR]]
+It turned out to be hard, costly or both, to outsource this part. We will probably spend less time developing the schematics ourselves than we would spend explaining what to develop to a third party.
diff --git a/raw-wiki-dump/AlphaReviewLog.md b/raw-wiki-dump/AlphaReviewLog.md
new file mode 100644
index 0000000..2d49480
--- /dev/null
+++ b/raw-wiki-dump/AlphaReviewLog.md
@@ -0,0 +1,282 @@
+# Review feedback of the Alpha schematics
+
+## Power subsystem
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|The LTS3060ITS8 is a 8-lead device but the symbol shows only 6 (there are 3 GND leads). | \
+|Kent | \
+|ft to correct mapping of pins between symbol and package | \
+|Done |
+|The output capacitor C13 can have higher capacitance. The 2.2 uF is the lowest recommended value and since this is a X7R/25V type it may well fall below that. I recommend 4.7uF to add some margin. C7 may also be changed to 4.7uF. | \
+|Kent | \
+|Updated schematics | \
+|Done |
+|LMZ13608 has 11 pins plus an exposed pad (must be connected to pin 5) but only 9 pins are shown in the schematic symbol. | \
+|Kent | \
+|Will change symbol to show both name and pin number(s) | \
+|Done |
+|The output voltage for LMZ13608 is calculated as 0.795 V * (1 + R8/R9) which is 4.93 V. It is a bit low for a 5.0 V supply. | \
+|Kent | \
+|5 volts not used, just an intermediate voltage. No change required. | \
+|Done |
+|I don't see any SH pin in the datasheet for the LMZ13608 device. Is it the one called NC? | \
+|Kent | \
+|ft check symbol, then ask Pavel to review | \
+|ft done, pavel |
+|What form factor and main power supply should we use for the Alpha? | \
+|ft | \
+|Try to find drawing with dimensions for NUC computers, to see if we can use that form factor and power supplies | \
+|Pavel |
+
+
+
+## Entropy source
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|Add optocoupler as per Jacob's suggestion on tech@ 2015-07-24? The suggestion is to add a fast optocoupler to really isolate AGND from GND. | \
+|Jacob W | \
+| As this appears to require a bigger digitizer, which in turn might require another 3V3 regulator, we don't want to add that to this otherwise quite well tested part of the circuitry for the Alpha. | \
+|Done |
+
+
+
+## STM32
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|The JTAG port is not connected. For debug puposes, it could be good to have access to the JTAG port, at least at the prototype board. | \
+|Kent | \
+|We don't know of a reason to add the full JTAG, when we have SWD. At least not if we keep the LQFP package because then we don't think we need to be able to do boundary scan. | \
+|Done |
+|The capacitors C22-C25 are connected between VCAP1/2 and VCCO_3V3. According to the datasheet as well as AN4488 they shall be connected to GND. It should be enough with one 2.2uF capacitor for each pin. | \
+|Kent | \
+|Yes, change to GND instead of 3V3. Our interpretation is that we actually should have 2x2.2 for both VCAP1 and VCAP2. We also prefer 2x2.2 over  1x4.7 so not changing that.| \
+|Done |
+
+
+
+## 2x512 Mbit SDRAM for the ARM
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|U6 has no speed grade specified. TSOP-II package is selected. The BGA package is much smaller and easier to handle in production. | \
+|Kent | \
+|We will investigate packages and speed | \
+|Pavel |
+
+
+
+## Keystore memory, 128 Mbit
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|Hard to see which resistor is R17 and R18. What is R17 (the left one) intended for? | \
+|Kent | \
+|Fixed the resistors. CS should be connected to ARM, default is "not enabled" through pull-up. | \
+|Done |
+
+
+
+## RTC
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|From where is 3V3_BATT supplied? Is it an external power source from connector JP3? Or the JP4 jumper? | \
+|Kent | \
+|Yes, external power source connected to JP4. | \
+|Done |
+|Do we need a separate RTC chip at all? | \
+|Jacob W | \
+|Keeping it for the Alpha since it is already there. | \
+|Done |
+
+
+
+## Micro SD card
+
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|Which connector to use? Haven't found a good one with Eagle symbol. Some different kinds available. | \
+|ft | \
+|Remove SD card. | \
+|Done |
+|Novena seems to have card reset capability (power control from MCU). Do we want the same? | \
+|ft | \
+|Remove SD card. | \
+|Done |
+|Novena has two SD slots, and list power at 200mA. Do we need a separate power regulator for the SD card, or can we use VCCO_3V3? | \
+|ft | \
+|Remove SD card. | \
+|Done |
+
+
+## 2x USB UARTs for management and application access
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|Should we add an EEPROM for FTDI USB related settings or not? | \
+|ft | \
+|Not adding anything not strictly necessary to the schematics. | \
+|Done |
+|LED6 is the same type as LED1 at page 4 but they have different values at their resistors (220/330 ohm). | \
+|Kent | \
+|Went with 330 for consistency. | \
+|Done |
+|The recommended protection devices on D+ and D- are missing. | \
+|Kent | \
+|Pavel to look for reference | \
+|pavel |
+|Hard to see what reference designators that belong to which component in some places. | \
+|Kent | \
+|Fredrik will improve clarity | \
+|Done |
+
+
+
+## AVR Tiny Tamper Detect MCU
+Fredrik to verify if Kent had comments about AVR
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+| | \
+| | \
+| |
+
+
+
+## Analog switch controlling access to the MKM
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|Suggest changing this chip to an 74AC244 like the one used for the FPGA config memory. | \
+|Pavel | \
+|Will change. | \
+|Done |
+
+
+
+## FPGA configuration
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|The mode signals are fixed to SPI Master mode. If more flexibility is needed, see next comment, jumpers may be added.| \
+|Kent | \
+|This is intentional. | \
+|Done |
+|One-bit data us for the configuration memory makes the configuration rather slow. If higher speed is preferable the SPI memory supports 4-bit data. | \
+|Kent | \
+|Bitstream is around 65 MBit, takes 4-5 seconds to load using single bit (@ 15MHz). We think that should be good enough. | \
+|Done |
+
+
+
+## FPGA I/O
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|A lot of the FPGA I/Os are unused. For debug purposes some of these can be made available by connecting them to a pin header. Unconnected BGA balls are very hard to use. | \
+|Kent | \
+|Added two more GPIOs from AVR to FPGA and two more from AVR to ARM. Remaining question is how many we should add from FPGA to ARM. | \
+|Pavel |
+|A zero ohm resistor at the oscillator output can simplify debug. | \
+|Kent | \
+|Fredrik will add zero ohm resistor | \
+|Done |
+|Joachim suggests, that we may want to have some high-speed extension interface for debugging and dumping large amounts of data. For example, we can implement GMII or RGMII using external GbE PHY and GPIO header(s). In that sense, at least one of the GPIO header pins should be connected to clock-capable (MRCC) FPGA pin. | \
+|Pavel | \
+|Pavel will finalize notes in schematics to enable this. | \
+|pavel |
+
+
+
+## FPGA voltage regulators
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|U14 and U15 have 38 pins but only 11 are visible in the schematic symbol. No pin numbers are visible. The NC pins must not be connected which should be shown.| \
+|Kent | \
+|Fredrik will update symbol to show pins. | \
+|Done |
+|I am not familiar with the EN6347Q device so I would add ferrite cores on the outputs, for debug and measurement. Maybe that's what the zero ohm resistors are intended for? | \
+|Kent | \
+|Will change 0-ohm to ferrites. Pavel will look up part number, Fredrik will update schematics. | \
+|pavel, ft|
+
+
+
+## FPGA power regulators
+|Comment |Who |Resolution |Status |
+|---|---|---|---|
+|The EN5364 device has 68 pins and 2 exposed pads but the symbol only shows 19 pins, without pin number.| \
+|Kent | \
+|Fredrik will update symbol to show pins | \
+|Done |
+
+
+
+
+### Additional comments from Kent
+I have reviewed the schematic drawings for 'Cryptech Alpha board', rev 02
+(12/28/15), together with the block diagram, rev 0.010 (2015-05-27). I
+have spent 8 hours on this review.
+
+
+#### General
+
+The block diagram does not comply with the schematics:
+
+|Analog switch replaced by line driver (IC2) | \
+|---|
+|Kent | \
+| |
+|There is no reset block to the Tamper Detect CPU (U10) in the schematics | \
+|Kent | \
+| |
+|I can't find any Reset_n signal to the FPGA (U13) nor any FPGA reset block (maybe it is supposed to indicate the FPGA configuration?). | \
+|Kent | \
+| |
+|Interfaces for Smart Card and display/control seems to be missing in the schematics JTAG port for the ARM (U4) is not present in the schematics | \
+|Kent | \
+| |
+|JTAG port for the Tamper Detect CPU (U10) is not present in the schematics | \
+|Kent | \
+| |
+|Master Key Memory (U12) type is different (23A640 vs 23K640) | \
+|Kent | \
+| |
+|Power supply voltages does not comply with the schematics | \
+|Kent | \
+| |
+|The battery near the RTC on the block diagram is not present in the schematics | \
+|Kent | \
+| |
+|Minor differences in component names (suggestion: remove details from block diagram) | \
+
+
+|The header information should be updated with design name/ID and author. | \
+|---|
+|Kent | \
+| |
+|Some components in the schematic (U1, U2, U14, U15, Q3) doesn't show pin numbers which make it harder to review | \
+|Kent | \
+| |
+|The sheets seems to have different sizes (1-13 differs from 14-26) and origo is placed in different positions in different pages. Not important but looks a bit odd. | \
+|Kent | \
+| |
+|Eagle doesn't seem to have a symbol for unconnected pins. If nothing else, a comment would be good so it is obvious that the pin shall be unconnected and is not forgotten. | \
+|Kent | \
+| |
+|On prototype boards it can sometimes be beneficial to insert zero ohm resistances on certain nets, typical clock and reset signals, to simplify debug. Typical places can be voltage regulator outputs and signals that are buried in the PCB. | \
+|Kent | \
+| |
+|The selected package for the CPU (U4) is LQFP208. The size is 30x30 mm compared to the TFBGA216 package that is only 13x13 mm. Also, the pitch is 0.5 mm for the LQFP208 while the TFBGA216 package has a ball pitch of 0.8 mm. | \
+|Kent | \
+|Joachim and ft thinks LQFP package makes sense for the Alpha - gives 208 "test points" and physical size not that important |
+|For debug purposes it is recommended to place test points for signals that are hard to reach, to simplify measurement. | \
+|Kent | \
+| |
+
+
+
+#### Not Reviewed
+
+A one day review doesn't allow a thorough design review. Some
+prioritizations are necessary. I have not reviewed:
+
+| FPGA pinout. The FPGA vendor tool (Vivado) does some of the checks. It checks that clock signals are placed at clock pins, that selected I/O types are compatible with the bank structure. Vivado can also check that not to much I/O switching power per bank is used and can also calculate power consumption (with correct user input). |
+|---|
+|Power calculations. The FPGA power is heavily dependent on how it is used. This can be estimated with the Vivado tool. |
+|Supply voltage quality. This requires simulations that are out of scope for this review. |
+|Power sequencing. |
+|Physical properties like PCB symbols, layout issues, thermal design and board area use. |
+|Production test or optimization for production. |
diff --git a/raw-wiki-dump/AlphaSchematics.md b/raw-wiki-dump/AlphaSchematics.md
new file mode 100644
index 0000000..7d20880
--- /dev/null
+++ b/raw-wiki-dump/AlphaSchematics.md
@@ -0,0 +1,9 @@
+The Alpha schematics are almost finished!
+
+PDF and Eagle files available for download here in the [[source:/hardware/eagle/alpha/rev02 | hardware]] repository.
+
+`https://wiki.cryptech.is/browser/hardware/eagle/alpha/rev02`
+
+The schematics are based on the dev-bridge board that we made in the summer of 2015, which is why it is called rev02.
+
+We are currently seeking review of the schematics to finalize them before starting layout. A log of various peoples review comments is kept [wiki:AlphaReviewLog here].
diff --git a/raw-wiki-dump/AlphaSealedBags.md b/raw-wiki-dump/AlphaSealedBags.md
new file mode 100644
index 0000000..e99dbca
--- /dev/null
+++ b/raw-wiki-dump/AlphaSealedBags.md
@@ -0,0 +1,62 @@
+
+## Chain of custody
+
+At present, we can't make any statements at all about the integrity of the hardware before it reached us - assembled and ready.
+
+We test and program the Alphas using a dedicated computer, but not in a secure facility by any means.
+A concerned user is advised to reprogram the firmware with binaries built from source.
+
+To provide some assurance the devices have not been tampered with after they have been programmed we put them in sealed bags with individual serial numbers.
+
+As the model of bags might change over time, we will publish photos of the bags used here as well as PGP signed statements for what serial numbers can be expected.
+At this time, we do not keep records of which exact unit was sent to whom.
+
+
+
+This is a picture of the currently used bags:
+
+[[Image(Alpha_tamper_bag_2016-12-16.png, 640px)]]
+
+
+
+```
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+At 2016-12-16, I put Cryptech Alpha units into sealed bags with the
+following serial numbers:
+
+  26 0 027 233 507
+  26 0 027 233 508
+  26 0 027 233 509
+  26 0 027 233 510
+  26 0 027 233 511
+  26 0 027 233 512
+  26 0 027 233 513
+  26 0 027 233 514
+  26 0 027 233 515
+  26 0 027 233 516
+  26 0 027 233 517
+  26 0 027 233 518
+  26 0 027 233 519
+  26 0 027 233 520
+  26 0 027 233 521
+  26 0 027 233 522
+  26 0 027 233 523
+  26 0 027 233 524
+  26 0 027 233 525
+  26 0 027 233 526
+
+/Fredrik
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQEcBAEBCgAGBQJYU/MVAAoJEBmMGv1QUVLd+2gH/jLZ7aUGlZ+Iwj6b746Hh6u1
+2JAZ+2tk5tRooTwNb4A5P3ewRcbjA0jPJQQlpVqZcxdt0DDjS16AR0LEaH2rWL++
+sj/OtBm5rqAmVcf1NNvzpC8f8WWgRYhx4nNhWKnEcTBQXT9NbFQhQY0WH3ebupnn
+8PK0mX8PpfsjM/3vxtVVLmi+vBsxv0hBcdl+t4IPw/UbzozicF6jZpxRXxVujTE6
+WLGXaCnySS4T1zgtpewfgVMOMouGScUw5n2yHRZJpissGUVJtuPrOEmNFvDz7LRD
+i00Rc4i2emsKTgKrkMIKyQWSqFIQ1nBUQ5B5ES1Q50432cppbyEW2rJJZjAuxgM=
+=s2D5
+-----END PGP SIGNATURE-----
+```
diff --git a/raw-wiki-dump/AssuredTooChain.md b/raw-wiki-dump/AssuredTooChain.md
new file mode 100644
index 0000000..89ea7d9
--- /dev/null
+++ b/raw-wiki-dump/AssuredTooChain.md
@@ -0,0 +1,16 @@
+# Issues of an Assured Tool-Chain
+
+We do not have any assurance that our basic tools are not compromised.
+
+* Compilers
+* Operating Systems
+* Hardware Platforms
+* Verilog and Other Tools to Produce Chips
+
+
+At the base, is the compiler.  The fear was first formally expressed in
+Ken Thompson's 1984 Turing Award Lecture
+[Reflections on Trusting Trust](http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf).
+
+David A. Wheeler's PhD thesis, [Fully Countering Trusting Trust through Diverse Double-Compiling](http://www.dwheeler.com/trusting-trust/)
+outlines how we might deal with the compiler trust conundrum.
diff --git a/raw-wiki-dump/BerlinWorkshop.md b/raw-wiki-dump/BerlinWorkshop.md
new file mode 100644
index 0000000..0c7da32
--- /dev/null
+++ b/raw-wiki-dump/BerlinWorkshop.md
@@ -0,0 +1,63 @@
+# CRYPTECH Workshop Agenda
+### 15-16 July 2016
+
+Intercontinental Berlin
+Budapest Str. 2
+10787 Berlin, Germany
+
+Meeting Room: Köpenick III
+
+Cost of attendance: None
+
+Alpha Board cost: if you are an alpha tester and plan to take an alpha board home with you, we would like to recover cost for these boards from you. We are asking for 800USD. We plan to collect the money through [crowdsupply](https://www.crowdsupply.com/cryptech/open-hardware-security-module).
+
+## Draft Agenda
+
+### Friday 15 July
+| 0830 | Coffee
+|---|
+| 0930 | Introductions, setup
+| 1000 | Presentation of the cryptech alpha device
+|      | - cryptech overview (attachment:2016-07-15-berlin-main.pdf)
+|      | - overall hardware architecture (attachment:2016-07-15-berlin-hw.pdf)
+|      | - the FPGA (attachment:2016-07-15-berlin-fpga.pdf)
+|      | - HSM software architecture, CLI, and RPC mechanism (attachment:2016-07-15-berlin-sw.pdf)
+|      | - PKCS11, client-side software, how to configure the board (attachment:2016-07-15-berlin-fw.pdf)
+| 1100 | Break
+| 1130 | Hands-on testing
+|      | - get binary packages running on participants' own laptops ([[BinaryPackages]])
+|      | - [[OpenDNSSEC]] is a guide for how to initialize a rev03 board and use it to sign a zone using OpenDNNSSEC - use as a baseline for own testing and experimentation with PKCS11-based applications.
+| 1230 | Buffet lunch
+| 1330 | Hands-on testing continues
+| 1500 | Coffee break
+| 1530 | Hands-on testing continues
+| 1700 | Finish day one
+
+
+### Saturday 16 July
+| 0900 | Hands-on testing continues
+|---|
+| 1030 | Coffee break
+| 1100 | Workshop wrap-up
+|      | - outstanding questions
+|      | - feedback from the participants
+|      | - opportunity to articulate what participants will need that isn't readily available
+| 1300 | Finish
+
+
+## What you need to bring
+During the workshop you will have access to the cryptech platform using
+a PKCS11 interface (reviewing PKCS11 might be a good way to prepare for
+the workshop). We will use OpenDNSSEC (using PKCS11) as a reference
+use case but you are encouraged to think about other applications that
+use PKCS11 you want to test. We will be there to help and will do our
+best to fix stuff that breaks along the way.
+
+Bring a laptop with 2 USB 2.0 ports free (or a USB hub) running either
+MacOS or Debian Linux. We will provide client PKCS11 software
+packages for Debian Jessie and Ubuntu Xenial, and Homebrew for MacOS. You
+will use one USB port for PKCS11 and one USB port for admin CLI access
+to the cryptech device.
+
+For admin access you will find useful some form of serial console application
+capable of handling 921600 bps line speed.
diff --git a/raw-wiki-dump/BinaryPackages.md b/raw-wiki-dump/BinaryPackages.md
new file mode 100644
index 0000000..632299b
--- /dev/null
+++ b/raw-wiki-dump/BinaryPackages.md
@@ -0,0 +1,154 @@
+[[PageOutline]]
+
+# Binary Packages for Cryptech Software and Firmware
+
+The Cryptech Project maintains APT and Homebrew repositories
+containing packaged software for the Cryptech Alpha board for Debian
+and Ubuntu Linux and for Mac OS X.  The binary packages also include
+pre-compiled images for the Alpha Board's Artix-7 FPGA, Cortex M4 ARM
+CPU, and AVR ATtiny828 MCU.
+
+## How to get APT packages for Debian Stretch, Debian Buster, Ubuntu Xenial, or Ubuntu Bionic
+
+
+* Fetch and validate the repository key.  Presumably you're security
+
+  concious (otherwise, why are you installing this stuff?), so you may
+  want to pay attention to what `gpg --check-sig` says here.
+
+  ```
+  $ id=37A8E93F5D7E7B9A
+  $ wget https://apt.cryptech.is/apt-gpg-key.gpg
+  $ gpg --recv-key $id
+  $ gpg --check-sig $id
+  ```
+
+
+* Install the repository key.  We used to use `apt-key(8)` for this,
+
+  these days the cool kids use the `/etc/apt/trusted.gpg.d/` directory:
+
+  ```
+  $ sudo chown root:root apt-gpg-key.gpg
+  $ sudo mv apt-gpg-key.gpg /etc/apt/trusted.gpg.d/cryptech.gpg
+  ```
+
+
+* Configure apt to use the repository.  You need to add a couple of
+
+  entries to `/etc/apt/source.list.d/`; which entries you need to add
+  depends on which distribution you're running.
+
+    * For Debian Stretch, do:
+    ```
+    $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.stretch.list
+
+    ```
+
+    * For Debian Buster, do:
+    ```
+    $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.buster.list
+
+    ```
+
+    * For Ubuntu Xenial, do:
+    ```
+    $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.xenial.list
+
+    ```
+
+    * For Ubuntu Bionic, do:
+    ```
+    $ sudo wget -q -O /etc/apt/sources.list.d/cryptech.list http://apt.cryptech.is/sources.bionic.list
+
+    ```
+
+
+
+* Update the package index.
+
+
+  ```
+  $ sudo apt-get update
+  ```
+
+
+* Install the `cryptech-alpha` package.
+
+
+  ```
+  $ sudo apt-get install cryptech-alpha
+  ```
+
+## Updating APT packages
+
+Once you've performed the steps above you should be able to upgrade to newer
+version of the code using the normal APT upgrade process:
+
+```
+$ sudo apt-get update
+$ sudo apt-get upgrade
+```
+
+## How to get Homebrew packages for Mac OS X
+
+
+* Fetch and validate the repository key.  Presumably you're security
+
+  concious (otherwise, why are you installing this stuff?), so you may
+  want to pay attention to what `gpg --check-sig` says here.
+
+  ```
+  $ id=37A8E93F5D7E7B9A
+  $ gpg --recv-key $id
+  $ gpg --check-sig $id
+  ```
+
+
+* Configure Homebrew to use the repository.
+
+
+  ```
+  $ brew tap cryptech/sw https://brew.cryptech.is/tap
+  ```
+
+
+* Update the package index.
+
+
+  ```
+  $ brew update
+  ```
+
+
+* Check the commit signature on the cryptech-alpha package formula.
+
+  This is optional (Homebrew doesn't care whether you do this), but if
+  you want to know whether the formula was signed by the Cryptech
+  project, this is how to check.
+
+  ```
+  $ brew log --max-count=1 --show-signature cryptech-alpha
+  ```
+
+
+* Install the `cryptech-alpha` package.  At the moment, this is only
+
+  available as a Homebrew source package due to licensing issues in
+  the MacOS Xcode SDK, so the installation will probably take several
+  minutes, as some of the libraries are a bit slow to compile (sorry...).
+
+  ```
+  $ brew install cryptech-alpha
+  ```
+
+## Updating Homebrew packages
+
+Once you've performed the steps above you should be able to upgrade to newer
+version of the code using the normal Homebrew upgrade process:
+
+```
+$ brew update
+$ brew upgrade
+$ brew cleanup
+```
diff --git a/raw-wiki-dump/BuildingFromSource.md b/raw-wiki-dump/BuildingFromSource.md
new file mode 100644
index 0000000..8f2a4fd
--- /dev/null
+++ b/raw-wiki-dump/BuildingFromSource.md
@@ -0,0 +1,229 @@
+[[PageOutline]]
+
+# Building Cryptech Software/Firmware/Bitstream From Source
+
+Everything you need to build our software, firmware, and FPGA
+bitstreams from source yourself is publicly available, but the process
+is a bit complicated.  Overall, there are two methods, one of which
+our developers use while writing this stuff, the other of which we use
+for the automated reproducible builds which go into our binary
+distributions.  Both methods eventually boil down to "get the source
+code then run make", but the details differ.
+
+## What developers do
+
+We check out copies of all the several dozen separate repositories and
+carefully arrange them in a tree structure which matches the official
+naming scheme.  Yes, really.  It's tedious, but we have
+[export:/user/sra/build-tools/https-sync-repos.py a script to automate this].
+Be warned that this script is a kludge which relies on parsing
+XML from this Wiki; this is nasty, but reasonably stable, because the
+XML itself is generated by another script.
+
+Once you have this tree, you can hop around within it, building
+whichever bits are of interest to you.  So if you want to rebuild just
+the HSM firmware (the C code that runs on the ARM), you would go to
+`sw/stm32` and run `make` there.
+
+## What we do for reproducible builds
+
+Reproducible builds use the same tree structure (as they must for the
+various Makefiles to work properly), but the entire tree is embedded
+in a git "superrepository" which also contains the release engineering
+goo necessary to make the whole thing work.  Do `git help submodule`
+for an introduction to git's submodule mechanism.
+
+With this model, one just checks out a copy of
+[source:/releng/alpha the superrepository],
+runs `make` in its top directory, and eventually
+the complete package pops out the other side.
+
+```
+git clone https://git.cryptech.is/releng/alpha.git
+cd alpha
+make
+```
+
+That's the good news.  The bad news is that this process has higher
+demands on its build environment: it expects to find the a complete
+tool set, including the XiLinx synthesis tools, the several different
+cross compilers for the firmware, and the `pbuilder` system for
+building clean room packages for Ubuntu and Debian.
+
+As a compromise, one can use this source tree as if it were the
+development source tree described above: just use the supermodule to
+pull down everything else, but then ignore the supermodule and build
+individual pieces as if you'd checked out all the repositories by
+hand.
+
+## Skip all this git mess and just download a tarball
+
+There's another alternative, which is simpler than any of the above:
+just download the source tarball.  Since the only build environments
+we support at the moment are Debian Jessie and Ubuntu Xenial, which
+also happen to be environments for which we build binary packages, you
+can just use APT:
+
+```
+apt-get source cryptech-alpha
+```
+
+Which will give you the same tree structure, but without all the git fun.
+
+## Build environment
+
+Our software and firmware developers use the Debian and Ubuntu Linux
+distributions.  Our current build box for binary packages runs Debian
+Jessie.
+
+Our Verilog developers use various environments and have been known to
+use graphical tools, but synthesis of the bitstreams that go in our
+binary packages is done via the XiLinx command line tools on the same
+Debian Jessie machine as the software and firmware builds.
+
+Which tools you need will of course depend on exactly what you're
+trying to do.
+
+Most of the tools work on either 32-bit or 64-bit machines, but if you
+intend to run the full binary package build script, you'll need a
+64-bit machine (or VM) because the tools won't build 64-bit binaries
+on a 32-bit machine.
+
+Basic tool set (not all required for every purpose, but they're all
+supported Debian packages so it's usually easier just to install them
+all and not worry about it):
+
+```
+  apt-get install git pbuilder ubuntu-dev-tools rsync sudo
+  apt-get install python-yaml python-serial python-crypto python-ecdsa
+  apt-get install gcc-arm-none-eabi gdb-arm-none-eabi
+  apt-get install gcc-avr binutils-avr avr-libc
+  apt-get -t jessie-backports install debootstrap distro-info-data
+  apt-get install reprepro ubuntu-archive-keyring
+```
+
+This is not an exhaustive list, because some of the other packages we
+use are pulled in by these as dependencies.
+
+You will also need a copy of the XiLinx tools, which is tedious enough
+that it's described in a separate section, below.
+
+Once you have all the tools installed, you'll need a copy of the
+source tree, as explained in the preceeding sections.
+
+pbuilder requires a bit of setup (you can skip this if you're not
+trying to do the full binary package build):
+
+```
+for code in jessie xenial; do for arch in i386 amd64; do pbuilder-dist $code $arch create; done; done
+ln -s jessie_result ~/pbuilder/jessie-amd64_result
+ln -s xenial_result ~/pbuilder/xenial-amd64_result
+```
+
+## Installing the XiLinx tools
+
+XiLinx tools setup is a bit involved.  You can skip this section if
+you don't intend to build FPGA bitstreams.
+
+We use the command line versions of the XiLinx tools, but installing
+them requires a graphical environment, because the XiLinx installer
+and license manager are GUI tools.  If you're running this on a server
+and don't already have a graphical environment installed, you can get
+away with something fairly minimal.  For example, if you have a VNC
+viewer such as "Chicken of the VNC" on your laptop, you can get away
+with a fairly minimal X11 toolset:
+
+```
+apt-get install tightvncserver xterm icewm
+```
+
+If you're already running X11 on your laptop and are comfortable with
+extruding that to the build machine, eg, via `ssh -Y`, you can just
+use that (not recommended for long-haul use, eg, if the laptop is in
+Boston and the server is in Reykjavik).
+
+You'll need to start by using a web browser to download the
+[Xilinx ​ISE Design Suite](http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html).
+
+XiLinx only supports specific versions of Red Hat and Suse Linux, but
+their tools do run on Debian and Ubuntu.  A few  caveats:
+
+
+* Debian and Ubuntu symlink `/bin/sh` to `/bin/dash`, which can't handle
+
+  some of the syntax used in XiLinx's shell scripts, so you'll need to
+  change that symlink to point to `/bin/bash`.
+
+
+* Although the XiLinx software can be installed as user or root, by
+
+  default it wants to install into /opt/Xilinx, so you need to install
+  as root if you want to do that.
+
+
+* The XiLinx tools are disk hogs, so if you're building a VM for this,
+
+  you'll probably want to give it at least 30-40 GB of disk space.
+
+Step-by-step installation:
+
+1. Unpack `Xilinx_ISE_DS_Lin_14.7_1015_1.tar` (or whatever version you have).
+2. In an X11 environment, cd to `Xilinx_ISE_DS_Lin_14.7_1015_1`, and run `sudo ./xsetup`
+3. Click through two screens of license agreements.
+4. Select `ISE WebPACK`.
+5. Unselect (or leave unselected) Install Cable Drivers.
+6. Go!
+
+Well, not quite.  You'll need to convince the ISE tools that you have
+a valid license to use the ISE tools.  Go to
+http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm,
+click the `Licensing Solutions` link.  On the page to which that takes
+you, expand the section `Obtain a license for Free or Evaluation
+product`.  To download the ISE Webpack, you should have created an
+account, so now you can go to the Licensing Site and use that account
+to create a Certificate Based License.
+
+You do not need to go through the HostID dance, just say Do It. You
+will then receive a certificate in email (not an X.509 certificate)
+which you will be able to use. Then start the ISE Webpack by issuing
+the command `ise`.  Go to the Help menu and Manage Licenses. Use the
+resulting new License Manager window to install the `.lic` file.  This
+process is complex and flakey.
+
+Here's
+[another description of installing ISE on Ubuntu](http://www.armadeus.com/wiki/index.php?title=ISE_WebPack_installation_on_Linux).
+
+The `ise` binary referred to above is in `/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise`
+(or in `.../lin/ise`, but the pbuilder setup requires a 64-bit build machine).
+
+When running this remotely under tightvncserver, setup looks something like this:
+
+```
+vncserver :0 -geometry 1280x768 -depth 16 -localhost
+export DISPLAY=:0 XAUTHORITY=~/.Xauthority
+icewm&
+```
+
+Then, either in the same shell as the above or in an xterm in the new display
+
+```
+cd Xilinx_ISE_DS_Lin_14.7_1015_1
+sudo ./xsetup
+
+cd
+/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise
+```
+
+It turns out you don't really need to run the whole `ise` tool to
+get to the license manager, you can just run
+
+```
+/opt/Xilinx/14.7/ISE_DS/common/bin/lin64/xlcm -manage
+```
+
+But you do have to source the appropriate settings file first, none of
+the XiLinx tools work properly without that:
+
+```
+. /opt/Xilinx/14.7/ISE_DS/settings64.sh
+```
diff --git a/raw-wiki-dump/CamelCase.md b/raw-wiki-dump/CamelCase.md
new file mode 100644
index 0000000..935ce27
--- /dev/null
+++ b/raw-wiki-dump/CamelCase.md
@@ -0,0 +1,28 @@
+# CamelCase
+
+New wiki links are automatically created when concatenating capitalized words, such that for example the word 'Camel' and the word 'Case' concatenated form a link to this CamelCase page.
+
+CamelCase is the original wiki convention for creating hyperlinks, with the additional requirement that the capitals are followed by a lower-case letter; hence "AlabamA" and "ABc" will not be links.
+
+## Customizing the Wiki behavior
+
+While Trac remains faithful to the original Wiki style, it provides a number of ways to accommodate users with different preferences:
+
+    * To prevent the creation of a new link of a camel-cased word, prefix with an exclamation mark (`!`): `CamelCase`.
+    * To ignore links to missing pages when the link is written using the CamelCase style, that word can instead be replaced by a gray link followed by a question mark. This is useful in cases when CamelCase style is used to name code artefacts like class names and there is no corresponding page for them. This option can be set in `ignore_missing_pages` in the [wiki:TracIni#wiki-section "[wiki]"] section of TracIni.
+    * To automatically insert space characters between the words of a CamelCase link when rendering the link, use `split_page_names` in the [wiki:TracIni#wiki-section "[wiki]"] section of TracIni.
+    * Creation of explicit Wiki links is also easy, see WikiPageNames for details.
+    * Wiki formatting can be disabled completely in some places, for example when rendering commit log messages. See `wiki_format_messages` in the [wiki:TracIni#changeset-section "[changeset]"] section of TracIni.
+
+
+See TracIni for more information on the available options.
+
+## More information on CamelCase
+
+
+    * http://c2.com/cgi/wiki?WikiCase
+    * http://en.wikipedia.org/wiki/CamelCase
+
+
+----
+See also: WikiPageNames, WikiNewPage, WikiFormatting, TracWiki
diff --git a/raw-wiki-dump/ConfigureFPGA.md b/raw-wiki-dump/ConfigureFPGA.md
new file mode 100644
index 0000000..8a4beab
--- /dev/null
+++ b/raw-wiki-dump/ConfigureFPGA.md
@@ -0,0 +1 @@
+*Page Under Development*
diff --git a/raw-wiki-dump/CoretestHashesC5G.md b/raw-wiki-dump/CoretestHashesC5G.md
new file mode 100644
index 0000000..7cc2e30
--- /dev/null
+++ b/raw-wiki-dump/CoretestHashesC5G.md
@@ -0,0 +1,534 @@
+# How to start using coretest_hashes on the TerasIC C5G Board
+This is a writeup on how to setup, build and testrun the coretest_hashes
+Cryptech subsystem on a TerasiC C5G Cyclone V GX Starter Kit FPGA
+development board [1].
+
+
+## Introduction
+### Test Setup
+The test setup consists of:
+
+- A development computer running the Altera Quartus II FPGA development software. This computer will be building the FPGA comfiguration image (a sof-file) and then use the Altera USB-blaster to load the image into the FPGA on the TerasIC board. This computer shall therefore be connected to the USB-blaster port on the TerasIC board.
+
+
+
+- A host computer that runs the hash_tester application that communicates with the FPGA design downloaded into the FPGA and perform tests on the hash functions. The host computer is connected to the USB-serial port on the TerasIC board.
+
+
+
+- The TerasIC Cyclone 5 GX Starter Kit (C5G) board.
+
+
+[[Image(http://www.terasic.com.tw/attachment/archive/830/image/image_74_thumb.jpg)]]
+
+*The TerasIC Cyclone 5 GX Starter Kit board.*
+
+The USB ports are the shown in the upper left corner. These are USB type B ports. The port to the left is the USB-blaster port. The port to the right is the USB-serial port. In the bottom right corner there is a row of buttons and just above them 8 LEDs. These will also be used by the coretest_hashes subsystem. There is a HDMI port on the C5G board but it will not be used. All communication is done in CLI on the host computer.
+
+**NOTE: You don't actually need two separate computers. You can use one computer with one or two USB ports. If you only have one USB port you will need to switch from connecting to the USB-Blaster port to the USB-serial port on the C5G board once the coretest_hashes FPGA configuration has been downloaded to the board.**
+
+My personal setup is a laptop with two USB ports which allows me to have connections to both USB ports on the C5G boards simultaneously.
+
+
+### Coretest_hashes
+The coretest_hashes is a subsystem that is a FPGA design that contains Cryptech application cores as well as support cores used to run tests of the
+SHA-1 and SHA-256 hash functions from a host computer via a serial
+interface connected to a FPGA device. The subsystem consists of:
+
+
+- [browser:/core/sha1 "sha1"]: A HW implementation of the SHA-1 hash function.
+
+
+
+- [browser:/core/sha256 "sha56"]: A HW implementation of the SHA-256 hash function.
+
+
+
+- [browser:/core/coretest "coretest"]: A command parser that accepts read/write commands from a
+
+  host, executes the commands and sends the response.
+
+
+- [browser:/core/usrt "uart"]: A simple serial interface that connects coretest to the host.
+
+
+
+- [browser:/core/coretest_hashes "coretest_hashes"]: A top level wrapper that connects all the cores as
+
+  well as connecting the rxd and txd ports on the uart to external pins as well as clk and reset. This core repo also contains the Python command line program hash_tester we will be using to talk to coretester and perform tests of the sha1 and sha256 cores.
+
+[[Image(coretest_hashes.png)]]
+
+*The coretest_hashes subsystem with sha1 and sha256 cores. The system is connected to a host computer via a serial interface.*
+
+## SW and system requirements
+You need to download and install the Altera Quartus II Web Edition
+software [2]. There are versions of Quartus II Web Edition for Windows and Linux. I'm using the Windows version, but Linux **should** work too.
+
+You will probably also install drivers for the Altera USB-blaster in order to program the FPGA on the development board. For instructions on how to install the driver, please see the Altera page for USB-blaster [7].
+
+For communication with the coretest_hashes in the FPGA we will be using the USB-serial device on the development board. The USB-serial chip on the
+board is a FTDI FT232R [3]. If your host OS does not have support for this device you will need to install drivers. For Windows the correct file to download seems to be a VCP file [7].
+
+Finally, in order to talk to coretest_hashes from the host there is application SW. This SW is written in Python and uses the Pyserial[5] library. If you don't have Python and/or Pyserial installed you will need to install that too.
+
+**NOTE: Python and Pyserial does not have to be installed in the same OS as Quartus II but can be run from a separate system and OS.**
+
+(I'm using Quartus II 13.1 64-bit version running in Win8.1 in a VM in Parallels Desktop in OX 10.9.2 during this writeup. And I use Python and Pyserial in an iTerm in OSX for the serial communication.)
+
+With all this SW installed you should be ready to proceed to create the
+coretest_hashes project.
+
+**I also recommend that you download the TerasIC C5G User Manual [4]. It is a really good document that describes the boards with all functions, pins etc.**
+
+
+## Downloading the cores
+Create a project directory. I'm using test_coretest_hashes. In it I add
+a core directory and a toolruns directory:
+
+```
+#> ls test_coretest_hashes
+cores/    toolruns/
+```
+
+The cores we need to build the subsystem must be downloaded from the
+Cryptech server. The cores we need are:
+
+
+- sha1
+- sha256
+- uart
+- coretest
+- coretest_hashes
+
+
+```
+#> cd cores
+#> ssh git@git.cryptech.is
+hello <FOO>, this is git@cryptech running gitolite3 v3.5.2-0-g926bd5f on git 1.9.0
+
+ R   C	[a-zA-Z0-9].*
+ R W	core/coretest
+ R W	core/coretest_hashes
+ R W	core/coretest_test_core
+ R W	core/sha1
+ R W	core/sha256
+ R W	core/test_core
+ R W	core/uart
+ R W	doc/presentations
+ R  	gitolite-admin
+Connection to cryptech.is closed.
+```
+
+We can see the relevant cores and check them out one by one:
+```
+#> git clone git@git.cryptech.is:core/sha1.git
+#> git clone git@git.cryptech.is:core/sha256.git
+#> git clone git@git.cryptech.is:core/uart.git
+#> git clone git@git.cryptech.is:core/coretest.git
+#> git clone git@git.cryptech.is:core/coretest_hashes.git
+```
+
+We should now have a cores directory like this:
+```
+#> ls
+coretest/  coretest_hashes/  sha1/  sha256/  uart/
+```
+
+In each of these cores there are RTL and testbenches needed to simulate
+and build each of them. For example the sha1 core contains:
+```
+#> cd sha1
+#> ls
+LICENSE.txt  README.md  src/  toolruns/
+```
+
+The sha1 RTL source is in src/rtl. Lets take a look:
+```
+#> cd src/rtl
+#> ls
+sha1.v  sha1_core.v  sha1_w_mem.v
+```
+
+These files are:
+
+- sha1.v: A top level wrapper that provides an interface to the core. In
+
+  this case a 32-bit memory like interface.
+
+
+- sha1_core.v: The actual SHA-1 hash function core.
+
+
+
+- sha1_w_mem.v: The W memory including sliding window functionality used
+
+  by the core.
+
+The other cores follows a similar pattern with a top level wrapper named
+<core_name>.v, the main functionality in <core_name>_core.v and then one
+or more submodules.
+
+
+## Creating the project in Quartus
+
+- Start Quartus and select file/new... and select New Quartus II
+
+  Project.
+
+
+- Select destination directory to be toolruns/ in your project
+
+  directory.
+
+
+- Set 'coretest_hashes' as name of the project
+
+
+
+- Set 'coretest_hashes' as nem of the top level design entity. (Should be
+
+  done automatically when entering the name of the project.)
+
+
+- Press next.
+
+
+
+- You should now be on the 'Add Files' page. Press '...'.
+
+
+
+- Navigate to test_coretest_hashes/cores/coretest/src/rtl.
+
+
+
+- Select coretest and press 'Open'. (Note: Quartus seems to sometimes omit the .v suffix
+
+  for the files depending on Windows/OS version.)
+
+
+- Back on the 'Add Files' page. Press Add to actually add coretest to
+
+  the project.
+
+
+- Press '...' again and navigate to the rtl directory in
+
+  coretest_hashes. Add it like you did with coretest.
+
+
+- Navigate to test_coretest_hashes/cores/sha1/src/rtl and add the files sha1, sha1_core,
+
+  sha1_w_mem. This time you don't need to press 'Add' on the 'Add
+  Files'. It is done automatically when adding more than one file at a
+  time.
+
+
+- Navigate to test_coretest_hashes/cores/sha256/src/rtl and add the files sha256, sha256_core,
+
+  sha256_k_constants, sha256_w_mem. Do **NOT** add the file wb_sha256. This file contains an alternative top level wrapper to the one in sha256.v that instead provides a ["WISHBONE"](http://opencores.org/opencores,wishbone) interface. This interface is not used in the coretest_hashes design.
+
+
+- Finally navigate to test_coretest_hashes/cores/uart/src/rtl and add uart, uart_core.
+
+
+Back on the 'Add Files page you should now see a list of source files:
+```
+../cores/uart/src/rtl/uart_core.v
+../cores/uart/src/rtl/uart.v
+../cores/sha256/src/rtl/sha256_w_mem.v
+../cores/sha256/src/rtl/sha256_k_constants.v
+../cores/sha256/src/rtl/sha256_core.v
+../cores/sha256/src/rtl/sha256.v
+../cores/sha1/src/rtl/sha1_w_mem.v
+../cores/sha1/src/rtl/sha1_core.v
+../cores/sha1/src/rtl/sha1.v
+../cores/coretest_hashes/src/rtl/coretest_hashes.v
+../cores/coretest/src/rtl/coretest.v
+```
+
+Press 'Next' to get to the 'Family & Device Settings' page.
+
+
+- In 'Device Family', 'Family' list select 'Cyclone V (E/GX/GT/SX/SE/ST)'.
+
+
+
+- In 'Device Family', 'Devices' list select 'Cyclone V GX Extended Features'
+
+
+
+- In the 'Available Devices' list select: 5CGXFC5C6F27C7.
+
+
+Press 'Finish'.
+
+
+## Setting up and building the FPGA design
+You should now be in the main Quartus II window. In the project
+navigator you can see all files, open the source files etc.
+
+You could now just press 'Start Compilation' button in the menue row
+(the purple play/triangle button.) This will build the complete
+subsystem for the type of device selected. But the generated FPGA configuration image will not map to the correct pins on the C5G board. But this build should go through without errors or warnings related to problems in the source files. It is therefore a good test to see that all files has been included.
+
+The result from this generic build should be a FPGA configuration that
+uses 3666 registers, 2846 ALMs, 12 pins and can run at 88.3 MHz in worst
+case temperature and timing.
+
+You now need to define the correct pins and define the clock to allow
+Quartus to create a FPGA configuration for our board.
+
+All pins needed are described in the C5G manual. To save time there is
+also a pin list available in the coretest_hashes directory.
+
+
+- Navigate to test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g
+
+
+
+- The file coretest_hashes.qsf contains assignments for a project like
+
+  the one we are setting up. It contains the pin assignments. The
+  follwing list is a slightly cleaned up version of the pin assignments:
+
+```
+set_location_assignment PIN_R20 -to clk
+set_location_assignment PIN_P11 -to reset_n
+set_location_assignment PIN_M9 -to rxd
+set_location_assignment PIN_L9 -to txd
+set_location_assignment PIN_L7 -to debug[0]
+set_location_assignment PIN_K6 -to debug[1]
+set_location_assignment PIN_D8 -to debug[2]
+set_location_assignment PIN_E9 -to debug[3]
+set_location_assignment PIN_A5 -to debug[4]
+set_location_assignment PIN_B6 -to debug[5]
+set_location_assignment PIN_H8 -to debug[6]
+set_location_assignment PIN_H9 -to debug[7]
+set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to clk
+set_instance_assignment -name IO_STANDARD "1.2 V" -to reset_n
+set_instance_assignment -name IO_STANDARD "2.5 V" -to txd
+set_instance_assignment -name IO_STANDARD "2.5 V" -to rxd
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[0]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[1]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[2]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[3]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[4]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[5]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[6]
+set_instance_assignment -name IO_STANDARD "2.5 V" -to debug[7]
+```
+
+As you can see, for each pin we want to use we need to define the actual
+pin in the FPGA (PIN_R20 for example) and the I/O standard the pin
+should use/support.
+
+In this design I've mapped the reset signal to the button 'KEY0' on the
+board which you can find in the lower right corner. There is also a
+debug port that in the coretest_hashes design is connected to the debug
+port in the uart. This allows us to see byte values received by the
+uart. This debug port is connected to pins that control the green LEDs
+just above the row of buttons that includes 'KEY0'.
+
+In order to enter the pin assignments select 'Assignments' in the
+Quartus top level menue bar. The select 'Assignment Editor'. Then either
+manually enter each of the assignments above. This will require two rows
+for each pin. For example for the clock ('clk') we would enter:
+
+
+- Row 1: 'To': clk, 'Assignment name': Location, 'Value': PIN_R20
+- Row 2: 'To': clk, 'Assignment name': I/O Standard, 'Value': 3.3-V LVTTL
+
+
+An easier way is to open up the file coretest_hashes.qsf in test_coretest_hashes/cores/coretest_hashes/toolruns/quartus/terasic_c5g and add the pin assignment from that file to your qsf file in test_coretest_hashes/toolruns. If you then open up the Assignments Editor the same definitions should be shown.
+
+We now need to define the clock. Under 'Assignments' in the top level
+menue select 'TimeQuest Timing Analyzer Wizard'. Press 'Next' to get
+from the 'Intro' page.
+
+Under 'Specify base clock settings' enter 'clk' as 'Clock Name' and
+'Input Pin'. Enter '20' in 'Period' and note that 'ns' is selected as
+time scale. In the 'Equivalent SDC Commands' you should see:
+
+```
+  create_clock -name "clk" -period 20.000ns [get_ports {clk}]
+```
+
+Now press 'Next' four times to get to the final page and then press
+'Finish' to complete the clock setup. If we now look in the
+test_coretest_hashes/toolruns directory there should be a file called
+coretest_hashes.sdc that contains the SDC command above.
+
+Now we are ready to build the real FPGA configuration. Press the purple
+'Start Compilation' button again. After build we should now have an FPGA
+configuration that requires 2852 ALMs, 3666 registers, 12 pins and meets
+timing. The max clock frequency for the design should be about 72 MHz.
+
+Time to load the design onto the board.
+
+
+## Configuring the FPGA on the C5G board
+If you haven't turned on the C5G board and connected the board to the
+computer Quartus is installed on, do so now. You should see the
+7-segment displays and LEDs start flashing in a simple sequence. This
+shows that the default configuration in the FPGA has been loaded and the
+board works.
+
+In Quartus now locate the 'Programmer' menue button (it looks like a
+chip with waves). Alternatively Select 'Tools' in the top level Menue
+and then 'Programmer'.
+
+In the Programmer window if everything is working magically we should
+see a list view with toolruns/output_files/coretest_hashes.sof
+selected. And below this list a graphic that shows a 'TDI' arrow
+pointing to an Altera 5CGXFC5C6F27C7 device with a 'TDO' going out from
+the device.
+
+If the graphic is not showing (probably), you need to press 'Hardware
+Setup'. In the Window you should see 'USB-blaster'. If not you need to
+fix the drivers for the USB-blaster in your OS. If the USB-blaster is
+present make sure it is selected and then press 'Close'.
+
+If the file is not showing, in the main Programmer window, select 'Add
+File' and navigate and to toolruns/output_files in the project
+directory. Select 'coretest_hashes.sof' and press 'Open'.
+
+In the main Programmer window now press 'Start' to start
+programming. When this has been completed (See 'Progress' in the upper
+right hand corner in the Programmer board) the LEDs etc should have
+stopped blinking. We should now have coretest_hashes alive on the
+development board. Time for host communication and testing!
+
+
+## Talking to coretest_hashes and test of SHA-1 and SHA-256
+There is a (currently rather ugly) test program for
+coretest_hashes. Navigate to test_coretest_hashes/cores/coretest_hashes/src/sw
+
+```
+#> ls
+hash_tester.py
+```
+
+This is a Python2.x program that uses Pyserial [5] to open up a serial
+port and talk to coretest via the uart. The command and response format
+used is a very simple byte oriented format. For more info, see the
+README.md in [browser:/core/coretest "the top of coretest"].
+
+The program hash_tester.py needs to know which serial interface to
+use. This is defined in the main() function (yes, VERY ugly). You will
+need to edit the program source to point to the serial interface
+connected to the USB-serial chip on the C5G board. For me that device
+is:
+
+```
+  ser.port='/dev/cu.usbserial-A801SA6T'
+```
+
+If everthing is working properly you should now just have to do:
+```
+  python hash_tester.py
+```
+
+If the communication has been set up properly you should now see:
+```
+  TC1-1: Reading name, type and version words from SHA-1 core.
+  READ_OK. address 0x1000 = 0x73686131.
+  READ_OK. address 0x1001 = 0x20202020.
+  READ_OK. address 0x1002 = 0x302e3530.
+  ...
+```
+
+That is the first test case that reads from specific registers in the
+SHA-1 core. If we look in sha1/src/rtl/sha1.v there are some defines:
+```
+  parameter CORE_NAME0     = 32'h73686131; // "sha1"
+  parameter CORE_NAME1     = 32'h20202020; // "    "
+  parameter CORE_VERSION   = 32'h302e3530; // "0.50"
+```
+
+As we can see those hex values matches what is being read from the FPGA
+and is the name and version strings in the core.
+
+Moving on, hash_tester.py also performs single block message hash tests
+of both the SHA-1 and SHA-256 core. The message is "abc" padded to the
+correct block size for SHA-1 and SHA-256. These tests are defined by
+NIST including the expected result in [6]. The block is written as a
+sequence of 32-bit words to addresses mapped to the block registers in
+the sha1 core.
+
+Finally we set the init_flag in the control register in
+sha1 to one which should make the sha1 core initialize and then process
+the first (of possible several) message block. This takes in total 82
+cycles for the core. This means that by the time the host gets the
+'WRITE_OK. address 0x1008.' message, the core is done since many cycles
+ago. We therefore check status and try to extract the digest.
+
+Looking at the output from hash_tester.py we see:
+```
+  TC1-3: Reading SHA-1 status and digest.
+  READ_OK. address 0x1009 = 0x00000003.
+  READ_OK. address 0x1020 = 0xa9993e36.
+  READ_OK. address 0x1021 = 0x4706816a.
+  READ_OK. address 0x1022 = 0xba3e2571.
+  READ_OK. address 0x1023 = 0x7850c26c.
+  READ_OK. address 0x1024 = 0x9cd0d89d.
+```
+
+Address 0x1009 corresponds to address 0x09 in the SHA-1 core. This
+address contains the status of the core. 0x03 means that the data in the
+digest is valid and that the core is ready to accept now commnands.
+
+The digest generated by the sha1 core is in MSB format which means that
+the digest generated is:
+```
+  0xa9993e36 0x4706816a 0xba3e2571 0x7850c26c 0x9cd0d89d
+```
+
+If we compare that to the expected result in [6] we can see that this is
+correct. Similarly, for SHA-256 we get:
+```
+  TC2-3: Reading SHA-256 status and digest.
+  READ_OK. address 0x2009 = 0x00000003.
+  READ_OK. address 0x2020 = 0xba7816bf.
+  READ_OK. address 0x2021 = 0x8f01cfea.
+  READ_OK. address 0x2022 = 0x414140de.
+  READ_OK. address 0x2023 = 0x5dae2223.
+  READ_OK. address 0x2024 = 0xb00361a3.
+  READ_OK. address 0x2025 = 0x96177a9c.
+  READ_OK. address 0x2026 = 0xb410ff61.
+  READ_OK. address 0x2027 = 0xf20015ad.
+```
+
+The digest generated is thus:
+```
+  0xba7816bf 0x8f01cfea 0x414140de 0x5dae2223
+  0xb00361a3 0x96177a9c 0xb410ff61 0xf20015ad
+```
+
+Which again matches what is specified in [6]
+
+
+## Summary
+We have now set up a complete development and verification environment
+for Cryptech. We have setup and built the coretest_hashes subsystem for
+the TerasIC C5G board. Finally we have connected to coretest_hashes from
+SW in the host and verified that we can write to and receive response
+needed to perform SHA-1 and SHA-256 hash operations and get correct
+digest back.
+
+If you have not been able to complete this, please contact me (Joachim Strömbergson).
+
+Happy Hashing!
+
+
+## References
+
+- [1]: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=830
+- [2]: http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html
+- [3]: http://www.ftdichip.com/Products/ICs/FT232R.htm
+- [4]: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=830&PartNo=4
+- [5]: http://pyserial.sourceforge.net/
+- [6]: http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA_All.pdf
+- [7]: http://www.ftdichip.com/Drivers/VCP.htm
+- [8]: http://www.altera.com/download/drivers/usb-blaster/dri-usb-blaster-vista.html
diff --git a/raw-wiki-dump/CoretestHashesNovena.md b/raw-wiki-dump/CoretestHashesNovena.md
new file mode 100644
index 0000000..6bc9c2a
--- /dev/null
+++ b/raw-wiki-dump/CoretestHashesNovena.md
@@ -0,0 +1,260 @@
+# How to start using coretest_hashes on the Novena PVT1
+
+This is a writeup on how to setup, build and testrun the coretest_hashes
+Cryptech subsystem on a Novena PVT1 development board.
+
+## Getting started with Novena
+
+[Novena](http://www.kosagi.com/w/index.php?title=Novena_Main_Page) is an open hardware and F/OSS-friendly computing platform.
+
+[[Image(http://bunniefoo.com/novena/pvt1_release/novena_pvt1e_top_sm.jpg)]]
+
+It is a small single-board Linux PC, which happens to include a Xilinx [Spartan-6 FPGA]. This, together with the TerasIC [http://trac.cryptech.is/wiki/CoretestHashesC5G Cyclone 5 GX](http://www.xilinx.com/products/silicon-devices/fpga/spartan-6/lx.html), is what we are using to develop and test the Cryptech cores.
+
+The Novena includes an HDMI adapter and two USB ports, so you can plug in a monitor, keyboard, and mouse, and have a graphical desktop environment. However, I prefer to run it headless, and ssh to it. To ssh to the Novena, you need to know its IP address, which means you need to either statically configure it, or you need to assign it an address in your DHCP server.
+
+If you go the DHCP route, be aware that Novena doesn't used a fixed hardware address, so you'll have to statically configure **that**.
+Open `/etc/network/interfaces`, and add something like the following lines:
+```
+allow-hotplug eth0
+iface eth0 inet dhcp
+  hwaddress ether 00:0e:c6:87:72:01
+```
+
+
+
+* The specific CPU on the Novena is the Freescale i.MX6 MCIMX6Q5EYM12AC device. A quad core, ARM A9 device running at 1.2 GHz.
+* The specific FPGA on the Novena is the Xilinx Spartan-6 XC6SLX45-3CSG324C device.
+* Here are ["the schematics for the Novena PVT2 board"](http://bunniefoo.com/novena/pvt2_release/novena_pvt2.PDF).
+
+
+
+### Coretest_hashes
+
+The coretest_hashes is a subsystem that is a FPGA design that contains
+Cryptech application cores as well as support cores used to run tests
+of the SHA-1 and SHA-2 hash functions from the host computer via an
+I2C serial bus. The subsystem consists of:
+
+
+- [browser:/core/sha1 sha1]: A HW implementation of the SHA-1 hash function.
+
+
+
+- [browser:/core/sha256 sha256]: A HW implementation of the SHA-256 hash
+
+  function.
+
+
+- [browser:/core/sha512 sha512]: A HW implementation of the SHA-512 hash
+
+  function.
+
+
+- [browser:/core/coretest coretest]: A command parser that accepts read/write
+
+  commands from a host, executes the commands and sends the response.
+
+
+- [browser:/core/i2c i2c]: A serial interface that connects coretest to the
+
+  host.
+
+
+- [browser:/core/novena novena]: A top-level wrapper that connects all
+
+ the cores, and connects i2c to external pins as well as clk and
+ reset. This repo also contains userland software that talks to
+ coretest and performs tests of the sha1, sha256, and sha512 cores.
+
+## Software and system requirements
+
+You need to download and install the Xilinx
+[ISE Design Suite](http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html).
+
+Note: this software runs on a Windows or x86 Linux host, **not** on the Novena.
+
+### Installing on Linux
+
+The Windows install is pretty straight-forward. So is the Linux
+install, but with a few extra notes:
+
+
+- Xilinx only supports specific versions of Red Hat and Suse Linux, but it does run on Ubuntu, with the following caveat: Ubuntu symlinks `/bin/sh` to `dash`, which can't handle `if [ ]` syntax in shell scripts, so I symlinked `/bin/sh` to `bash` instead.
+
+
+
+- ISE Design Suite uses a graphical installer, so has to be installed
+
+  on a desktop edition, not a server edition.
+
+
+- Although the software can be installed as user or root, by default
+
+  it wants to install into `/opt/Xilinx`, so you need to install as root
+  if you want to do that.
+
+
+- The Xilinx tools are disk hogs, so if you're building a VM for this, you'll probably want to give it at least 30-40 GB of disk space.
+
+
+Step-by-step installation:
+1. Unpack Xilinx_ISE_DS_Lin_14.7_1015_1.tar (or whatever version you have).
+2. `cd` to Xilinx_ISE_DS_Lin_14.7_1015_1, and run `sudo ./xsetup`
+3. Click through two screens of license agreements.
+4. Select `ISE WebPACK`.
+5. Unselect (or leave unselected) `Install Cable Drivers`.
+6. Go!
+
+Well, not quite.  You will need to convince the ISE that you have a license.
+
+On the page [http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm](http://www.xilinx.com/products/design-tools/ise-design-suite/ise-webpack.htm) click on the `Licensing Solutions` link.  On the resulting page, expand the section `Obtain a license for Free or Evaluation product`.  To download the ISE Webpack, you should have created an account, so now you can go to the Licensing Site and use that account to create a Certificate Based License.
+
+You do not need to go through the HostID dance, just say Do It.  You will then receive a certificate in email (not an X.509 certificate) which you will be able to use.  Then start the ISE Webpack by issuing the command `ise`.  Go to the Help menu and `Manage Licenses`.  Use the resulting new License Manager window to install the .lic file.  This process is complex and flakey.
+
+Here is a more detailed description of ["installing ISE in Ubuntu."](http://www.armadeus.com/wiki/index.php?title=ISE_WebPack_installation_on_Linux)
+
+Platforms on which at least one person has done this succesfully:
+
+
+* ISE 14.7 on a 32-bit Debian Wheezy VM running under VirtualBox on MacOSX.
+* ISE 14.7 on a 64-bit Debian Jessie VM running under virsh/kvm.
+* ISE 14.7 on 32-bit Debian Jessie on a Shuttle XS36V.
+
+
+## Downloading the cores
+
+Create a project directory, e.g. `coretest/core`.
+
+The cores we need to build the subsystem must be downloaded from the
+Cryptech server. Check them out one by one:
+```
+#!sh
+git clone http://git.cryptech.is/core/sha1.git
+git clone http://git.cryptech.is/core/sha256.git
+git clone http://git.cryptech.is/core/sha512.git
+git clone http://git.cryptech.is/core/i2c.git
+git clone http://git.cryptech.is/core/coretest.git
+git clone http://git.cryptech.is/core/novena.git
+```
+
+If you are a cryptech core member, use the ssh method, e.g.
+```
+git clone git@git.cryptech.is:core/sha1.git
+```
+
+## Building the cores
+
+### Building in Linux command-line
+
+Go to `novena/synth` and run `make`.
+
+Depending on your version of ISE Design Suite, where you installed it,
+and whether you're running it on 32-bit or 64-bit hardware, you may
+have to change the `isedir` and `xil_env` values in `Makefile`.
+
+### Building in the ISE application
+
+On Windows, open the Project Navigator link.
+
+On Linux, run e.g. `/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise`
+
+a. Create the project:
+   Select `File` > `New Project`
+
+    -  Name: novena
+    -  Location: .../toolruns (automatically appends "novena")
+    -  Family: Spartan6
+    -  Device: XC6SLX45
+    -  Package: CSG324
+    -  Speed: -3
+
+
+b. Add files to the project:
+
+    - coretest/src/rtl/coretest.v
+    - coretest_test_core/src/rtl/coretest_test_core.v
+    - i2c/src/rtl/i2c.v
+    - i2c/src/rtl/i2c_core.v
+    - novena/src/rtl/coretest_hashes.v
+    - novena/src/rtl/novena_fpga.v
+    - novena/synth/coretest-novena.ucf
+    - sha1/src/rtl/sha1.v
+    - sha1/src/rtl/sha1_core.v
+    - sha1/src/rtl/sha1_w_mem.v
+    - sha256/src/rtl/sha256.v
+    - sha256/src/rtl/sha256_core.v
+    - sha256/src/rtl/sha256_k_constants.v
+    - sha256/src/rtl/sha256_w_mem.v
+    - sha512/src/rtl/sha512.v
+    - sha512/src/rtl/sha512_core.v
+    - sha512/src/rtl/sha512_h_constants.v
+    - sha512/src/rtl/sha512_k_constants.v
+    - sha512/src/rtl/sha512_w_mem.v
+
+
+c. Set some non-default options:
+
+   *Note: these are derived from other Novena projects, and I'm not sure
+   what they mean, but they don't make things blow up.*
+
+
+    - In the `Process` window, right-click on `Generate Programming File`, select `Process Properties...`.
+        - In `Configuration Options`, find `-g UnusedPin`, and change it from `Pull Down` to `Float`.
+        - In `Startup Options`, find `-g DriveDone`, and check the box.
+
+
+d. Build the project
+
+   Select `Process` > `Implement Top Module`
+
+
+The expected build time should be something like 5 and 10 minutes, depending on the computer used.
+Some measured build times for the design:
+
+
+    - 5,30 minutes on MacbookPro 2013 with tools in 64-bit SUSE Linux in VM
+    - 9,20 minutes on AMD A10-6800K with tools in Windows 7 in Virtualbox VM with one CPU core and 4 GByte RAM.
+
+
+
+## Running coretest on the Novena
+
+`scp` the built `coretest-novena.bit` to the Novena.
+
+Fetch
+[devmem2.c](https://github.com/xobs/novena-scope-drivers/blob/master/userspace/devmem2.c)
+and compile it on the Novena.
+
+`scp` the following files from `novena/src/sw` to the Novena:
+
+- configure.sh
+- hash_tester.py
+
+
+To configure the coretest image into the FPGA, run
+```
+#!sh
+./configure.sh coretest-novena.bit
+```
+
+This should light a small green LED (labeled "fpga") next to the high-speed
+expansion connector. The console log should be:
+
+```
+Setting export of reset pin
+setting reset pin to out
+flipping reset
+configuring FPGA
+11597+1 records in
+11597+1 records out
+1484509 bytes (1.5 MB) copied, 2.34345 s, 633 kB/s
+turning on clock to FPGA
+/dev/mem opened.
+Memory mapped at address 0x76f51000.
+Value at address 0x20C8160 (0x76f51160): 0x40B
+Written 0xD2B; readback 0xD2B
+```
+
+Run `hash_tester.py` to go through the full test suite.
+
diff --git a/raw-wiki-dump/DNSSEC%2FRequirements.md b/raw-wiki-dump/DNSSEC%2FRequirements.md
new file mode 100644
index 0000000..36b1152
--- /dev/null
+++ b/raw-wiki-dump/DNSSEC%2FRequirements.md
@@ -0,0 +1,99 @@
+# DNSSEC Requirements
+
+## Questions
+
+
+- Should we even support SHA-1?
+- GOST?
+
+
+## Must implement
+
+Target DNSSEC Algorithms:
+
+
+- RSA/SHA-256 (RFC 5702)
+- RSA/SHA-512 (RFC 5702)
+
+
+Algorithms:
+
+
+- Hash: SHA-256
+- Hash: SHA-512
+- Sign: RSA
+
+
+Required PKCS11 Mechs:
+
+
+- CKM_RSA_PKCS_KEY_PAIR_GEN
+- CKM_SHA256_RSA_PKCS
+- CKM_SHA512_RSA_PKCS
+- CKM_RSA_PKCS (possible cross-check hash with CKM_SHA256 and CKM_SHA512 before signing)
+- CKM_SHA256
+- CKM_SHA512
+
+
+## Should implement
+
+Target DNSSEC Algorithms:
+
+
+- ECDSA/P-256/SHA-256 (RFC 6605)
+- ECDSA/P-384/SHA-384 (RFC 6605)
+
+
+Algorithms:
+
+
+- Hash: SHA-256
+- Hash: SHA-384
+- Sign: P-256
+- Sign: P-384
+
+
+Required PKCS11 Mechs:
+
+
+- CKM_EC_KEY_PAIR_GEN
+- CKM_ECDSA_SHA256
+- CKM_ECDSA_SHA384
+- CKM_ECDSA (possible cross-check hash with CKM_SHA256 and CKM_SHA512 before signing)
+- CKM_SHA256
+- CKM_SHA384
+
+
+## May implement
+
+Target DNSSEC Algorithms:
+
+
+- RSA/SHA-1 (RFC 3110)
+- GOST (RFC 5933)
+
+
+Algorithms:
+
+
+- Hash: SHA-1
+- Sign: RSA
+
+
+
+- Hash: GOST R 34.11-94 (RFC5831)
+- Sign: GOST R 34.10-2001 (RFC5832)
+
+
+Required PKCS11 Mechs:
+
+
+- CKM_RSA_PKCS_KEY_PAIR_GEN
+- CKM_RSA_PKCS (possible cross-check hash with CKM_SHA_1)
+- CKM_SHA1_RSA_PKCS
+- CKM_SHA_1
+
+
+
+- CKM_GOSTR3410_KEY_PAIR_GEN
+- CKM_GOSTR3410_WITH_GOSTR3411
diff --git a/raw-wiki-dump/DNSSEC.md b/raw-wiki-dump/DNSSEC.md
new file mode 100644
index 0000000..4d57d27
--- /dev/null
+++ b/raw-wiki-dump/DNSSEC.md
@@ -0,0 +1,4 @@
+# DNSSEC
+
+
+- [wiki:DNSSEC/Requirements DNSSEC Requirements]
diff --git a/raw-wiki-dump/Dashboard.md b/raw-wiki-dump/Dashboard.md
new file mode 100644
index 0000000..ca2c512
--- /dev/null
+++ b/raw-wiki-dump/Dashboard.md
@@ -0,0 +1,96 @@
+# Project Status Dashboard
+
+## Product Component Requirements
+
+| State | Component    | DNSsec Signing | Let's Encrypt | Tor Consensus | Internal | Ticket |
+|---|---|---|---|---|---|---|
+| Done    | AES / KEY WRAP |                  |                 |                 | Wrap/Bkup | #17      |
+|         | ECDSA p256     | secondary      |     Yes       |                 |            |          |
+|         | ECDSA p384     | secondary      |      ?        |                 |            |          |
+| Testing | PKCS!#11       |      Yes       |     Yes       |     Yes       | Yes        | #14      |
+| Done    | RSA            |      Yes       |     Yes       |     Yes       |            | #16      |
+| Done    | SHA-1          |                  |                |     Yes       |            |          |
+| Done    | SHA-256        |      Yes       |     Yes       |     Yes       |            |          |
+| Done    | SHA-384        |      Yes       |     ?         |                 |            |          |
+| Done    | TRNG           | padding        | padding       | padding       | KeyGen    | #15      |
+
+
+
+## Novena Alpha - DNSsec Only
+
+| Component           | Who        | About When    | Ticket   |
+|---|---|---|---|
+|RSA                    | Pavel, Rob   | Done            | #16        |
+|AES/KEY WRAP           | Rob          | Done            | #17        |
+|SHA-256                | Joachim      | Done            |            |
+|TRNG                   | FT           | Done            | #15        |
+|PKCS!#11               | Rob          | Late May        |            |
+|PKCS!#11 PIN           | Rob          | Mid June        | #14        |
+|Packaging              | Paul, Rob    | Done            |            |
+
+
+
+## Hardware cores
+
+### Hash Functions
+
+| Component       | Status    | Repository                                           | Comment                                               |
+|---|---|---|---|
+| SHA-1             | Done        | [[GitRepositories/core/hash/sha1| core/hash/sha1]]     |                                                         |
+| SHA-256           | Done        | [[GitRepositories/core/hash/sha256| core/hash/sha256]] |                                                         |
+| SHA-512           | Done        | [[GitRepositories/core/hash/sha512| core/hash/sha512]] | Support all four SHA-512/x modes defined in FIPS 180-4. |
+| SHA-3 (Keccak )   | Started     | [[GitRepositories/core/hash/sha3| core/hash/sha3]]     |                                                         |
+| GOST R 34.11-2012 | Started     |                                                        |                                                         |
+
+
+
+### Symmetric Crypto
+
+| Component | Status | Repository                                               | Comment                                                     |
+|---|---|---|---|
+| AES         | Done     | [[GitRepositories/core/cipher/aes| core/cipher/aes]]       | AES cipher core with support for 128 and 256 bit keys.        |
+| ChaCha     | Done     | [[GitRepositories/core/cipher/chacha| core/cipher/chacha]] | High speed stream cipher. Based on the Salsa20 stream cipher. |
+
+
+
+### Asymmetric Crypto
+
+| Component         | Status    | Repository                                                    | Comment                 |
+|---|---|---|---|
+| ModExp -8192 (RSA) | Done        | [[GitRepositories/core/math/modexps6| core/math/modexps6]]      |                           |
+| Curve25519          | Started     |                                                                 |                           |
+| Ed25519             | Not started |                                                                 |                           |
+| P-256, P-384 ECDSA  | Started     |                                                                 |                           |
+| GOST R 34.10-2001   | Started     | [[https://trac.cryptech.is/browser/user/shatov/gost/streebog]]([https://trac.cryptech.is/browser/user/shatov/gost/streebog])  | Core in provisional repo. Will be moved to the the hash core section.|
+
+
+
+### Random Number Generators
+
+| Component                | Status | Repository                                                               | Comment                      |
+|---|---|---|---|
+| TRNG                       | Done     | [[GitRepositories/core/rng/trng| core/rng/trng]]                           | Depends on SHA-512 and ChaCha |
+| External Avalanche Entropy | Done     | [[GitRepositories/core/rng/avalanche_entropy| core/rng/avalanche_entropy]] | [[GitRepositories/user/ft/stm32-avalanche-noise| Hardware]] and stand-alone PoC |
+| Internal Ring Oscillator   | Done     | [[GitRepositories/core/rng/rosc_entropy| core/rng/rosc_entropy]]           |                                |
+
+
+
+### Key wrapping and Cipher Modes
+
+| Component       | Status    | Repository | Comment                                                                                              |
+|---|---|---|---|
+| KEY WRAP          | Done        |              | Key wrapping mode. Will be used for key storage. See ["rfc 3394"](https://tools.ietf.org/html/rfc3394). #17 |
+| GCM               | Not started |              | Galois Counter Mode. AEAD cipher.                                                                      |
+| CTR and CBC       | Not started |              | Basic block cipher modes.                                                                              |
+
+
+
+### Support Functionality
+
+| Component | Status | Repository                                               | Comment                                                                             |
+|---|---|---|---|
+| Coretest    | Done     | [[GitRepositories/core/comm/coretest| core/comm/coretest]] | Command-response based core tester for HW accelerated core verification.              |
+| UART        | Done     | [[GitRepositories/core/comm/uart| core/comm/uart]]         | Serial interface module used on the TerasIC C5G development board.                    |
+| I2C         | Done     | [[GitRepositories/core/comm/i2c| core/comm/i2c]]           | I2C interface module used on the Novena board.                                        |
+| EIM         | Done     | [[GitRepositories/core/comm/eim| core/comm/eim]]           | Interface for the Freescale EIM memory interface used on the Novena board.            |
+| FMC         | Done     | [[GitRepositories/core/comm/fmc| core/comm/fmc]]           | Interface for the STM32 FMC memory interface used on the dev-bridge and Alpha boards. |
diff --git a/raw-wiki-dump/DevBridgeBoard.md b/raw-wiki-dump/DevBridgeBoard.md
new file mode 100644
index 0000000..f4dde47
--- /dev/null
+++ b/raw-wiki-dump/DevBridgeBoard.md
@@ -0,0 +1,40 @@
+[[PageOutline]]
+
+# dev-bridge board
+In the process of developing the [wiki:AlphaBoardComponents] design, the project has made what is known as the "dev-bridge board".
+
+This is a board, 100x70 mm, with about 2/3 of the components intended to be on the Alpha design. What is missing is basically the FPGA and it's supporting circuits.
+
+To date, the dev-bridge board has been used to implement and validate the FMC based interface that will be used to connect the ARM and the FPGA on the Alpha.
+
+Schematics and layouts are at [user/ft/stm32-dev-bridge/hardware/rev01](https://wiki.cryptech.is/browser/user/ft/stm32-dev-bridge/hardware/rev01).
+
+High resolution pictures of rev01 of the dev-bridge board are attached at the bottom of this page, but the following should be more than sufficient to read the silkscreens.
+
+[[Image(dev-bridge_rev01_front_medium.jpg​)]]
+
+[[Image(dev-bridge_rev01_back_medium.jpg​)]]
+
+Here is the board mounted on the Novena, attached to the programmer:
+
+[[Image(IMG_9983s.jpg)]]
+
+Note that it's rather bigger than the Netgear enclosure I use to transport the Novena. (Not only does it protect the board, but I have this superstition that TSA is more comfortable with a home gateway than a bare motherboard.)
+
+Also note that the dev-bridge board is connected to the Novena by the
+high-speed expansion connector, which forms a bit of a pivot point.
+As Pavel says, "High speed and mechanical reliability are not very good
+friends usually."
+
+For that reason, I highly recommend stabilizing the board by bolting it to
+the Novena with a 5mm spacer. There are two through-holes that line up
+with mounting holes on the Novena, one at the corner and one next to the
+wifi connector.  I've found that even one bolt is enough to stabilize the
+board.
+
+Finally note that the board traces come rather close to the through-holes, so
+you want to avoid scraping them with the bolt head or the nut. I happen to
+be using a countersink-head bolt, which is beveled toward the shaft, but
+it's probably even better to use a nylon washer.
+
+All the software, as well as flashing instructions, are at [wiki:GitRepositories/sw/stm32].
diff --git a/raw-wiki-dump/DevelopersGuide.md b/raw-wiki-dump/DevelopersGuide.md
new file mode 100644
index 0000000..bbb0f1e
--- /dev/null
+++ b/raw-wiki-dump/DevelopersGuide.md
@@ -0,0 +1,22 @@
+*Page Under Development*
+
+# Developers Guide
+
+## Architecture
+
+* OpenCryptoChip
+* NoisyDiode
+* AlphaBoard
+
+
+## Known Limitations
+
+* AssuredTooChain
+
+
+
+* EDAToolchainSurvey"
+
+
+## Building the Bitstream
+
diff --git a/raw-wiki-dump/DisasterRecovery.md b/raw-wiki-dump/DisasterRecovery.md
new file mode 100644
index 0000000..9c0e56f
--- /dev/null
+++ b/raw-wiki-dump/DisasterRecovery.md
@@ -0,0 +1,45 @@
+# Disaster Recovery
+
+This page covers a few likely (hopefully unlikely) oh-noes.
+
+## Oh no, I bricked my device
+
+### Recovering from a bad firmware install
+
+You can upload new firmware through the bootloader. On power-up or reset,
+the bootloader flashes the blue LED for 10 seconds. During that time, start
+`cryptech_upload`:
+
+```
+$ cryptech_upload --firmware --user wheel
+PIN: <your-wheel-pin>
+```
+
+### Recovering from a bad bootloader install
+
+Well, now you've done it. You'll need to buy an ST-LINK programmer.
+See [wiki:UsingSTLink].
+
+## Oh no, I'm locked out of my device
+
+If you're staring at this thing for the first time, or if you ran
+`keystore erase`, then you have no PIN. Believe it or not, this is the
+best case scenario. Log in as wheel with the default PIN
+`YouReallyNeedToChangeThisPINRightNowWeAreNotKidding`, and you should be
+able to reset the PINs.
+
+If you forgot the PIN, I feel sorry for you. The only way out of this is
+via [wiki:UsingSTLink ST-LINK]. The easiest way is to debug with `gdb`, set a breakpoint on
+`hal_rpc_login`, and issue the gdb command `return 0`.
+
+## Oh no, I forgot (or reset) the master key
+
+As shipped, the Alpha doesn't include a battery backup for the Master Key
+Memory. So if power is interrupted, the MKM is wiped. (Also, if we had
+tamper protection more sophisticated than a Panic Button, it would wipe
+the MKM when you opened the case to install the ST-LINK cable.)
+
+Sorry, there's nothing that can be done about that. All your keys are
+still in flash memory, but encrypted with the KEK, which is now gone.
+(Unless you used the `masterkey unsecure set` command to store the KEK in
+unprotected flash memory, but you wouldn't do that, would you?)
diff --git a/raw-wiki-dump/DocMeet.md b/raw-wiki-dump/DocMeet.md
new file mode 100644
index 0000000..b49ec5d
--- /dev/null
+++ b/raw-wiki-dump/DocMeet.md
@@ -0,0 +1,12 @@
+# Documents, Meetings, etc.
+
+## Meetings
+
+* At IETF88 an open lunch meeting was held with maybe 30-40 people.  Minutes will be posted here shortly.
+* An invitation-only initial exploratory and team-building meeting will be hosted by SUNET in Stockholm in December.  Invitations are in process.  Dress in layers.  Anything useful that comes out of the meeting will be published on this wiki.
+
+
+## Documents
+
+* [attachment:140109.cryptech.pdf 140109.cryptech.pdf Presentation - Overview of Project with Funding Requests]
+* [attachment:141002.cryptech-iij.pdf 141002.cryptech-iij.pdf CrypTech Presentation at Open IIJ Seminar]
diff --git a/raw-wiki-dump/Documents.md b/raw-wiki-dump/Documents.md
new file mode 100644
index 0000000..77593fd
--- /dev/null
+++ b/raw-wiki-dump/Documents.md
@@ -0,0 +1,21 @@
+# Presentations and Design Documents
+
+```
+#!comment
+
+Remember that links from this page to files in git repositories should use the "export:" tag, eg:
+
+[export:/doc/blarg.pdf "An interesting presentation about Blargs"]
+
+```
+
+[RandomnessTesting Randomness Testing Tools][[BR]]
+
+[AlphaBoardStrategy Alpha board strategy]
+
+[export:/doc/design/Alpha_board_drawing.pdf "Alpha board drawing"]
+
+[AlphaBoardPictures Alpha board pictures]
+
+Placeholder until somebody fills this in with something else interesting.
+
diff --git a/raw-wiki-dump/EDAToolchainSurvey%22.md b/raw-wiki-dump/EDAToolchainSurvey%22.md
new file mode 100644
index 0000000..5516a29
--- /dev/null
+++ b/raw-wiki-dump/EDAToolchainSurvey%22.md
@@ -0,0 +1,18 @@
+**Note: this page has been replaced by wiki:EDAToolchainSurvey**
+
+The major issue is finding tools that allows a designer, user to verify that the RTL source code (in Verilog or VHDL) matches what is generated at the physical level. As part of the project we need to investigate the current status of open tools in the toolchain for implementation and verification of hardware. This includes RTL simulation, synthesis, place & route, netlist verification, timing analysis and configuration file generation and analysis. (This implies that the target is an FPGA.). If there are no open tools we need to find ways of verifying pre- and post-functionality to check that the black box tool does not alter (subvert) the design in ways not intended.
+
+The basic action flow is:
+
+* Finding open EDA tools and assess their status
+* Settling for Closed
+* Strategy to Develop Trust in Tools
+* Validation Methods for Output
+
+
+Some tools and frameworks worth investigating are:
+
+* ["OpTiMSoC"](http://www.optimsoc.org/index.html) - An open System on Chip (SoC) framework built around the OpenRISC CPU.
+* ["Icarus Verilog"](http://iverilog.icarus.com/) - An open Verilog event driven simulator that supports Verilog 2001, 2005 and SystemVerilog.
+* ["gEDA"](http://www.geda-project.org/) - A project that aims at developing GNU based EDA tools.
+* ["gplEDA"](http://www.gpleda.org/) - A collection of GPL licensed EDA tools. Points to gEDA.
diff --git a/raw-wiki-dump/EDAToolchainSurvey.md b/raw-wiki-dump/EDAToolchainSurvey.md
new file mode 100644
index 0000000..ffd40e6
--- /dev/null
+++ b/raw-wiki-dump/EDAToolchainSurvey.md
@@ -0,0 +1,16 @@
+The major issue is finding tools that allows a designer, user to verify that the RTL source code (in Verilog or VHDL) matches what is generated at the physical level. As part of the project we need to investigate the current status of open tools in the toolchain for implementation and verification of hardware. This includes RTL simulation, synthesis, place & route, netlist verification, timing analysis and configuration file generation and analysis. (This implies that the target is an FPGA.). If there are no open tools we need to find ways of verifying pre- and post-functionality to check that the black box tool does not alter (subvert) the design in ways not intended.
+
+The basic action flow is:
+
+* Finding open EDA tools and assess their status
+* Settling for Closed
+* Strategy to Develop Trust in Tools
+* Validation Methods for Output
+
+
+Some tools and frameworks worth investigating are:
+
+* ["OpTiMSoC"](http://www.optimsoc.org/index.html) - An open System on Chip (SoC) framework built around the OpenRISC CPU.
+* ["Icarus Verilog"](http://iverilog.icarus.com/) - An open Verilog event driven simulator that supports Verilog 2001, 2005 and SystemVerilog.
+* ["gEDA"](http://www.geda-project.org/) - A project that aims at developing GNU based EDA tools.
+* ["gplEDA"](http://www.gpleda.org/) - A collection of GPL licensed EDA tools. Points to gEDA.
diff --git a/raw-wiki-dump/ExternalProjects.md b/raw-wiki-dump/ExternalProjects.md
new file mode 100644
index 0000000..d07eb4c
--- /dev/null
+++ b/raw-wiki-dump/ExternalProjects.md
@@ -0,0 +1,4 @@
+External projects using [CrypTech](https://cryptech.is/) technology.
+
+
+* [wiki:ExternalProjectsTorHSM TorHSM]
diff --git a/raw-wiki-dump/ExternalProjectsTorHSM.md b/raw-wiki-dump/ExternalProjectsTorHSM.md
new file mode 100644
index 0000000..9dd8b7c
--- /dev/null
+++ b/raw-wiki-dump/ExternalProjectsTorHSM.md
@@ -0,0 +1,90 @@
+# External project TorHSM
+
+## Problem
+
+The [Tor network](https://www.torproject.org/about/overview.html.en) is defined by a small number, about ten, of special relays called Directory Authorities (DAs).
+
+Directory Authorities sign the critical `status votes` and `consensus status` documents using SHA-1 and SHA-256 together with RSA-2048 or RSA-3072 once per hour, using medium-term on-line `authority signing keys` signed by their individual off-line long-term `authority identity keys`. Authority signing keys typically have a lifetime of three to twelve months.
+
+Authority signing keys are currently kept on the same general purpose computer that runs the Directory Authority and are thus subject to a large number of network threats.
+
+## Proposed solution
+
+Move `authority signing keys` away from the general purpose computer onto an external device which can sign the consensus document without exposing key material to the networked computer system.
+
+The CrypTech project has created an open source (BSD licensed) `Alpha` hardware which would be especially suitable, because the open software and hardware offers unprecedented transparency while also enabling a simple, efficient and legacy-free solution.
+
+### Current typical key roll-over procedure
+
+
+* Generate new `authority signing key` on offline system
+* Sign new key using `authority identity key` on offline system
+* Save new `authority signing key` and `key certificate` on USB stick
+* Transfer new `authority signing key` and `key certificate` to DA system via network
+
+
+### The key roll-over procedure becomes
+
+
+* Use administrative tool from this project on DA system to generate new `authority signing key` on HSM
+    * The new `authority signing key` initially remains inactive and unavailable for use
+    * The public part of new `authority signing key` is exported from HSM onto the DA system
+* Transfer new public part of `authority signing key` to USB stick
+* Sign new public key using `authority identity key` on offline system
+* Save `key certificate` on USB stick
+* Transfer `key certificate` to DA system via network and make available to DA
+* (Optional?) Use administrative tool from this project on DA to present `key certificate` to HSM
+* Activate key (automatic on verified `key certificate`, manual without `key certificate` verification)
+
+
+## Milestones
+
+The minimum viable product (MVP) at MS3 is a system where the authority signing key is no longer accessible by the DA system while not making any part of the process worse from a security perspective.
+
+The system at MS6 (to MS8) does not make any part of the process worse from a //usability// perspective (subjective) and also adds rate limiting.
+
+### MS1 -- PoC using OpenSSL `PKCS#11` engine
+
+* tor using openssl p11 engine; no key management or rate-limiting
+* useful for test and verification
+
+
+### MS2 -- Using CrypTech RPC instead of OpenSSL
+
+* function declarations in `sw/libhal/hal.h`, definitions in `sw/libhal/rpc_*.c`
+* TODO: daemon
+
+
+### MS3 (MVP) -- HSM configuration I
+
+* "HSM configuration" is aka "key management"
+* administrator connected to MGMT can make HSM
+    * generate a MK based on passphrase
+    * print public part of MK
+* administrator connected to USER can make HSM
+    * generate a new authority signing key pair, wrap the secret part in MK, store both parts in flash memory and export the public part
+
+
+### MS4 -- HSM configuration II
+
+* rate limiting
+* enforcing key validity
+
+
+### MS5 -- Enforcing key validity HSM side
+
+### MS6 -- Rate limiting of signatures
+
+### MS7 -- New Shiny Crypto Hardware API using CrypTech RPC
+
+### MS8 -- Getting entropy from HSM
+
+### MS9 -- Support for more protocols in New Shiny Crypto Hardware API
+
+## References
+
+
+* [Tor directory protocol, version 3](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt)
+* [CrypTech Alpha system](https://www.crowdsupply.com/cryptech/open-hardware-security-module)
+
+
diff --git a/raw-wiki-dump/GettingStartedNovena.md b/raw-wiki-dump/GettingStartedNovena.md
new file mode 100644
index 0000000..66f220c
--- /dev/null
+++ b/raw-wiki-dump/GettingStartedNovena.md
@@ -0,0 +1,147 @@
+[[PageOutline]]
+
+# Getting Started on the Novena
+
+## The Novena Board
+
+[[Image(http://bunniefoo.com/novena/pvt1_release/novena_pvt1e_top_sm.jpg)]]
+
+[Novena](http://www.kosagi.com/w/index.php?title=Novena_Main_Page) is an open hardware and F/OSS-friendly computing platform. It is a small single-board Linux PC, with a Freescale i.MX6 (ARM
+Cortex-A9) CPU and a Xilinx Spartan-6 LX45 FPGA.
+
+It is available in limited quantities through [crowd supply](https://www.crowdsupply.com/sutajio-kosagi/novena).
+
+### Setting up the Novena
+
+The Novena PVT-2 requires some initial setup. You will need to attach a USB keyboard and HDMI monitor.
+
+Once this is done, most of us prefer to run it headless, and ssh in.
+
+You may also want to bring the packages up to date:
+
+```
+$ sudo apt-get update
+$ sudo apt-get upgrade
+```
+
+## The Avalanche Noise Board
+
+[[Image(rev03-on-novena.jpg, 40%)]]
+
+The avalanche noise board is a Novena daughter board that contains a zener-diode noise circuit that can be read directly by the FPGA.
+
+*(More information from FT: block diagram, schematics, ...)*
+
+It is available in limited quantities directly from Fredrik Thulin, and will be distributed at the PrahaWorkshop.
+
+## Binary Packages
+
+Cryptech maintains an ```apt``` repository, with two binary packages for the Novena:
+
+* a bitstream, to be configured into the FPGA
+* software, to run on the CPU
+
+
+### How to get them
+
+All commands are run on the Novena.
+
+1. First, get the hactrn CA certificate:
+
+```
+$ wget http://www.hactrn.net/cacert.asc
+```
+
+Get the key used to sign the CA certificate.
+
+```
+$ gpg --recv-keys 2DC6FF82
+```
+
+Validate the CA certificate
+
+```
+$ gpg cacert.asc
+```
+
+Install the CA certficiate.
+
+```
+$ sudo mkdir /usr/share/ca-certificates/hactrn.org
+$ sudo mv cacert /usr/share/ca-certificates/hactrn.org/cacert.crt
+$ sudo dpkg-reconfigure ca-certificates
+```
+
+2. Get the repository key.
+
+```
+$ wget https://apt.cryptech.is/novena/apt-gpg-key.asc
+```
+
+Validate the key.
+
+```
+$ id=37A8E93F5D7E7B9A
+$ gpg --recv-key $id
+$ gpg --check-sig $id
+$ gpg --export $id | sudo apt-key add -
+```
+
+See the apt-key(8) manual page for more information about the APT key database, including how to remove keys you don't want anymore.
+
+Install the key.
+
+```
+$ sudo apt-key add apt-gpg-key.asc
+```
+
+3. Get the packages
+
+Configure apt to use the repository.
+
+```
+$ sudo wget -q -O /etc/apt/sources.list.d/novena.list http://apt.cryptech.is/novena/sources.list
+```
+
+Update the package index file.
+
+```
+$ sudo apt-get update
+```
+
+Get the cryptech meta-package.
+
+```
+$ sudo apt-get install cryptech-novena
+```
+
+This installs the ```cryptech-novena-rtl``` and ```cryptech-novena-sw``` packages.
+
+The ```cryptech-novena-rtl``` package includes an ```init.d``` script that configures the FPGA on system startup. This script should run automatically as part of the install process.
+
+### Updating the packages
+
+Once you've performed the steps above you should be able to upgrade to newer
+version of the code using the normal APT upgrade process, eg:
+
+```
+$ sudo apt-get update
+$ sudo apt-get upgrade
+```
+
+## Setting up PKCS!#11
+
+The PKCS11 token is in /usr/lib/libpkcs11.so. In order to start using it you need to set a pin and an SO pin. This you do with p11util thus:
+
+```
+(echo 12345678;echo 1234) | sudo p11util --set-so-pin --set-user-pin --pin-from-stdin
+```
+
+It is strongly suggested to change the so pin and pin (in that order above) to something sensible. Now your token is ready to use. Your favorite PKCS11-client may or may not work depending on the state of support for PKCS11 function calls - please open tickets for whatever is missing. If you want/need to talk PKCS11 from another host, you could install and configure [[PKCS11Proxy]] on both the novena and your host. Note that currently pkcs11-proxy doesn't handle differing word-lengths so your client-side will have to be 32bit (since the novena is).
+
+
+## Setting up the lab signer
+
+The lab DNSSEC signer MUST, at this point, be running on a 32-bit system in order to work with the 32-bit Novena.
+
+[[https://www.dropbox.com/s/f8b4s9vic7hsqyb/cryptech-proxy-lab-20150718r2.pdf]]([https://www.dropbox.com/s/f8b4s9vic7hsqyb/cryptech-proxy-lab-20150718r2.pdf])
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Faes.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Faes.md
new file mode 100644
index 0000000..907c90a
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Faes.md
@@ -0,0 +1,91 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>aes_speed</h1>
+
+<p>Speed optimized Verilog implementation of the symmetric block cipher AES
+(Advanced Encryption Standard) as specified in the NIST document <a href="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf">FIPS
+197</a>.</p>
+
+<p>This core is modified version of the Cryptech AES core. Note that the
+name of the core modules are identical to that core. The purpose of this
+is to allow a drop-in replacement in Cryptech designs.</p>
+
+<h2>Status</h2>
+
+<p>Second round of optimizations done. The core has been implemented in
+FPGA and tested in real HW.</p>
+
+<h2>Introduction</h2>
+
+<p>This implementation supports 128 and 256 bit keys. The
+implementation is iterative and process one 128 block at a time.</p>
+
+<p>The encipher and decipher block processing datapaths are separated and
+basically self contained given access to a set of round keys and a
+block. This makes it possible to hard wire either encipher or decipher
+and allow the build tools to optimize away the other functionality which
+will reduce the size to about 50%. For cipher modes such as CTR, GCM
+decryption in the AES core will never be used and thus the decipher
+block processing can be removed.</p>
+
+<p>The core has been equipped with 16 S-boxes for encipher and 16 Inverse
+S-boxes for decipher. This allows the core to perform the SubBytes and
+InverseSubBytes operations in the AES round functions in one cycle.</p>
+
+<p>The key expansion does not share S-boxes with the encipher datapath, so
+the total number of S-boxes is 40.</p>
+
+<h2>Performance comparison</h2>
+
+<p>Number of cycles for the old Cryptech AES core:</p>
+
+<ul>
+<li>AES-128 Encipher one block: 57</li>
+<li>AES-256 Decipher one block: 77</li>
+</ul>
+
+<p>Number of cycles for the Cryptech AES speed core:</p>
+
+<ul>
+<li>AES-128 Encipher one block: 16</li>
+<li>AES-255 Decipher one block: 20</li>
+</ul>
+
+<p>Note that these latency numbers are after key expansion. The given key
+must be expanded byt asserting the init control bit and wait for ready
+to be asserted. Key expansion takes about 10 to 14 cycles.</p>
+
+<h2>Implementation comparison</h2>
+
+<p>Implementation results for Xilinx Artix7-t200.</p>
+
+<p>Old Cryptech AES core:</p>
+
+<ul>
+<li>2094 slices</li>
+<li>2854 regs</li>
+<li>114 MHz (8.76ns)</li>
+</ul>
+
+<p>Cryptec AES speed core:</p>
+
+<ul>
+<li>2112 slices</li>
+<li>2984 regs</li>
+<li>116 MHz. (8.62ns)</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=core/cipher/aes)]]
+
+| Clone `https://git.cryptech.is/core/cipher/aes.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Faes_speed.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Faes_speed.md
new file mode 100644
index 0000000..445162e
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Faes_speed.md
@@ -0,0 +1,87 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>aes_speed</h1>
+
+<p>Speed optimized Verilog implementation of the symmetric block cipher AES
+(Advanced Encryption Standard) as specified in the NIST document <a href="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf">FIPS
+197</a>.</p>
+
+<p>This core is modified version of the Cryptech AES core. Note that the
+name of the core modules are identical to that core. The purpose of this
+is to allow a drop-in replacement in Cryptech designs.</p>
+
+<h2>Status</h2>
+
+<p>Second round of optimizations done. Core similates correctly. Core has
+been implemented in FPGA, but not functionally tested in real HW.</p>
+
+<h2>Introduction</h2>
+
+<p>This implementation supports 128 and 256 bit keys. The
+implementation is iterative and process one 128 block at a time.</p>
+
+<p>The encipher and decipher block processing datapaths are separated and
+basically self contained given access to a set of round keys and a
+block. This makes it possible to hard wire either encipher or decipher
+and allow the build tools to optimize away the other functionality which
+will reduce the size to about 50%. For cipher modes such as CTR, GCM
+decryption in the AES core will never be used and thus the decipher
+block processing can be removed.</p>
+
+<p>The core has been equipped with 16 S-boxes for encipher and 16 Inverse
+S-boxes for decipher. This allows the core to perform the SubBytes and
+InverseSubBytes operations in the AES round functions in one cycle.</p>
+
+<p>The key expansion does not share S-boxes with the encipher datapath, so
+the total number of S-boxes is 40.</p>
+
+<h2>Performance comparison</h2>
+
+<p>Number of cycles for the old Cryptech AES core:</p>
+
+<ul>
+<li>AES-128 Encipher one block with key expansion: 57</li>
+<li>AES-256 Decipher one block with key expansion: 77</li>
+</ul>
+
+<p>Number of cycles for the Cryptech AES speed core:</p>
+
+<ul>
+<li>AES-128 Encipher one block with key expansion: 16</li>
+<li>AES-255 Decipher one block with key expansion: 20</li>
+</ul>
+
+<h2>Implementation comparison</h2>
+
+<p>Implementation results for Xilinx Artix7-t200.</p>
+
+<p>Old Cryptech AES core:</p>
+
+<ul>
+<li>2094 slices</li>
+<li>2854 regs</li>
+<li>114 MHz (8.76ns)</li>
+</ul>
+
+<p>Cryptec AES speed core:</p>
+
+<ul>
+<li>2112 slices</li>
+<li>2984 regs</li>
+<li>116 MHz. (8.62ns)</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=core/cipher/aes_speed)]]
+
+| Clone `https://git.cryptech.is/core/cipher/aes_speed.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Fchacha.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Fchacha.md
new file mode 100644
index 0000000..08e5149
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher%2Fchacha.md
@@ -0,0 +1,71 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>chacha</h1>
+
+<p>Verilog 2001 implementation of the ChaCha stream cipher.</p>
+
+<h2>Functionality</h2>
+
+<p>This core implements ChaCha with support for 128 and 256 bit keys. The
+number of rounds can be set from two to 32 rounds in steps of two. The
+default number of rounds is eight.</p>
+
+<p>The core contains an internal 64-bit block counter that is automatically
+updated for each data block.</p>
+
+<h2>Performance</h2>
+
+<p>Each quarterround takes one cycle which means that the mininum latency
+will be 4*rounds. When the core is functionally correct we will add two
+more version with 2 and 4 parallel quarterrounds respectively. The four
+quarterounds version will achieve 1 cycle/round.</p>
+
+<h2>Implementation</h2>
+
+<p>Implementation results using the Altera Quartus 13 design tool.</p>
+
+<h3>Cyclone IV GX</h3>
+
+<ul>
+<li>6233 LEs</li>
+<li>3677 registers</li>
+<li>56.1 MHz</li>
+<li>11 cycles latency</li>
+<li>2.6 Gbps performance.</li>
+</ul>
+
+<h3>Cyclone V GX</h3>
+
+<ul>
+<li>2631 ALMs for logic</li>
+<li>3677 registers</li>
+<li>54.3 MHz</li>
+<li>11 cycles latency</li>
+<li>2.5 Gbps performance.</li>
+</ul>
+
+<h2>Status</h2>
+
+<p>(2014-09-03)
+- Added a new port in the core to allow setting of the initial value of
+the counter. The top level wrapper currently sets this value to a
+constant zero.</p>
+
+<ul>
+<li>Added the ChaCha core to Cryptech.</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=core/cipher/chacha)]]
+
+| Clone `https://git.cryptech.is/core/cipher/chacha.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher.md
new file mode 100644
index 0000000..a7dc5ad
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcipher.md
@@ -0,0 +1,19 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/cipher/aes_speed| core/cipher/aes_speed]] |`https://git.cryptech.is/core/cipher/aes_speed.git` | [[wiki:GitRepositories/core/cipher/aes_speed| README]] |
+|[[source:/core/cipher/aes| core/cipher/aes]] |`https://git.cryptech.is/core/cipher/aes.git` | [[wiki:GitRepositories/core/cipher/aes| README]] |
+|[[source:/core/cipher/chacha| core/cipher/chacha]] |`https://git.cryptech.is/core/cipher/chacha.git` | [[wiki:GitRepositories/core/cipher/chacha| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fcoretest.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fcoretest.md
new file mode 100644
index 0000000..f78d5f7
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fcoretest.md
@@ -0,0 +1,212 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>coretest</h1>
+
+<p>Test platform for the <a href="https://cryptech.is/">Cryptech Open HSM project</a>.</p>
+
+<p>(_Note:The Cryptech certificate is by choice not from a CA and therefore
+not in your brower trust store._)</p>
+
+<h2>Description</h2>
+
+<p>This platform and hardware design is used to functionally verfiy cores
+developed in the Cryptech Open HSM project. The test core itself
+contains just enough functionality to be able to verify that the SW in
+the host computer can talk to the core in the FPGA by reading and
+writing 32 bit data words to given addresses.</p>
+
+<p>This project includes cores in Verilog, a testbench as well as host SW
+to talk to the core.</p>
+
+<h2>Architecture</h2>
+
+<p>The coretest consists of three state machines:</p>
+
+<h3>rx_engine</h3>
+
+<p>Handles receiving command messages from the host. Awaits SYN signals from
+the host interface and reads bytes when SYN is asserted. For each byte
+the rx_engine assetts and ACK and waits for the SYN to be asserted. When
+a EOC byte has been detected the rx_engine signals the test_engine that
+there is a new command available in the rx_buffer.</p>
+
+<h3>tx_engine</h3>
+
+<p>Handles transmitting response messages to the host. When the test_engine
+signals that there is a new response in the tx_buffer the tx_engine will
+start transmitting all bytes up to and including the EOR byte it is
+expecting in the tx_buffer. The transmission is done by asserting SYN
+awaiting ACK, deasserting SYN and moving to the next byte before
+asserting SYN again. This process is repeated until all bytes has been
+transmitted.</p>
+
+<h3>test_engine</h3>
+
+<p>Performs the parsing of commands from the host. Known read or write
+commands are used to test the core to be tested. The response from the
+core is collected and the appropriate response is stored in the
+tx_buffer. The test_engine then signals the tx_engine that there is a
+new response message to be transmitted.</p>
+
+<h2>Interfaces</h2>
+
+<p>The host communication interface is a byte wide data interface with
+SYN-ACK handshake for each byte.</p>
+
+<p>The interface to the core to be tested is a memory like
+interface with chip select and write enable. The data width is 32-bits
+and the address is 16-bits.</p>
+
+<h2>Core under test</h2>
+
+<p>The core under test is expected to have a simple memory like interface
+with chip select (cs), write enable (we) signal ports, 16-bit address
+port and separate 32-bit data ports for read and write data. The core is
+also expected to have an error signal port that informs the master if
+any read or write commands given cannot be performed by the core.</p>
+
+<p><strong><em>Note:</em></strong>
+The core reset signal is expected to by active high. The
+core reset signal should be connected to the coretest core_reset
+port, not to system reset.</p>
+
+<h2>Protocol</h2>
+
+<p>Coretest uses a simple command-response protocol to allow a host to
+control the test functionality.</p>
+
+<p>The command messages are sent as a sequence of bytes with a command byte
+followed by zero or more arguments. The response consists of a response
+code byte followed by zero or more data fields.</p>
+
+<p>The start of a command is signalled by a Start of Command (SOC)
+byte. The end of a command is signalled by a End of Command (EOC)
+byte. These bytes are:</p>
+
+<ul>
+<li>SOC: 0x55</li>
+<li>EOC: 0xaa</li>
+</ul>
+
+<p>The start of a response is signalled by a Start of Response (SOR)
+byte. The end of a response is signalled by a End of Respons (EOC)
+byte. These bytes are:</p>
+
+<ul>
+<li>SOR: 0xaa</li>
+<li>EOR: 0x55</li>
+</ul>
+
+<p><strong><em>The commands accepted are:</em></strong>
+  - RESET_CMD. Reset the core being tested. Message length is 3 bytes
+    including SOC and EOC.
+    - SOC
+    - 0x01 opcode
+    - EOC</p>
+
+<ul>
+<li><p>READ_CMD. Read a 32-bit data word from a given address. Message
+length is 5 bytes including SOC and EOC.</p>
+
+<ul>
+<li>SOC</li>
+<li>0x10 opcode</li>
+<li>16-bit address in MSB format</li>
+<li>EOC</li>
+</ul></li>
+<li><p>WRITE_CMD. Write a given data word to a given address. Message
+length is 9 bytes including SOC and EOC.</p>
+
+<ul>
+<li>SOC</li>
+<li>0x11 opcode</li>
+<li>16-bit address in MSB format</li>
+<li>32-bit data in MSB format</li>
+<li>EOC</li>
+</ul></li>
+</ul>
+
+<p><strong><em>The possible responses are:</em></strong>
+  - UNKNOWN. Unknown command received. Message length is 4 bytes
+    including SOR and EOR.
+    - SOR
+    - 0xfe response code
+    - Received command
+    - EOR</p>
+
+<ul>
+<li><p>ERROR. Known but unsuccessful command as signalled by the
+core. Caused for example by a write command to read only
+register. Message length is 4 bytes including SOR and EOR.</p>
+
+<ul>
+<li>SOR</li>
+<li>0xfd response code</li>
+<li>command received</li>
+<li>EOR</li>
+</ul></li>
+<li><p>READ_OK. Sent after successful read operation. Message length is 9
+bytes including SOR and EOR .</p>
+
+<ul>
+<li>SOR</li>
+<li>0x7f response code</li>
+<li>16-bit address in MSB format</li>
+<li>32-bit data in MSB format</li>
+<li>EOR</li>
+</ul></li>
+<li><p>WRITE_OK. Sent after successful write operation. Message length is 5
+bytes including SOR and EOR </p>
+
+<ul>
+<li>SOR</li>
+<li>0x7e response code</li>
+<li>16-bit address in MSB format</li>
+<li>EOR</li>
+</ul></li>
+<li><p>RESET_OK. Sent after successful reset operation. Message length is 3
+bytes including SOR and EOR.</p>
+
+<ul>
+<li>SOR</li>
+<li>0x7d response code</li>
+<li>EOR</li>
+</ul></li>
+</ul>
+
+<h2>Status</h2>
+
+<p><strong><em>(2014-02-11):</em></strong></p>
+
+<p>Added information about the architecture and protocols. Updated the
+command and response with explicit read and write ok responses. Some
+cleanup of the description.</p>
+
+<p>Completed first draft of the RTL for coretest. The RTL is not debugged
+and has not been synthesized. We need to add a testbench and a simple
+test core.</p>
+
+<p>Added a simple test core.
+Adding initial version of UART core that will be used for the host
+interface.</p>
+
+<p><strong><em>(2014-02-10):</em></strong></p>
+
+<p>Initial version of the project. Based on previous cttest project but
+renamed and with new (ideas) about the test architecture. Specified
+command and response protocol.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/comm/coretest)]]
+
+| Clone `https://git.cryptech.is/core/comm/coretest.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Feim.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Feim.md
new file mode 100644
index 0000000..fb1551c
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Feim.md
@@ -0,0 +1,21 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>eim</h1>
+
+<p>Verilog implementation of the eim interface used to connect FPGA cores
+to the Freescale i.MX6 CPU.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/comm/eim)]]
+
+| Clone `https://git.cryptech.is/core/comm/eim.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Ffmc.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Ffmc.md
new file mode 100644
index 0000000..d44f72a
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Ffmc.md
@@ -0,0 +1,21 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>fmc</h1>
+
+<p>Verilog implementation of the Flexible Memory Controller interface used to
+connect FPGA cores to the STM32 MCU.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/comm/fmc)]]
+
+| Clone `https://git.cryptech.is/core/comm/fmc.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fi2c.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fi2c.md
new file mode 100644
index 0000000..dbd6443
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fi2c.md
@@ -0,0 +1,23 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>i2c</h1>
+
+<p>An I2C slave implemented in Verilog.</p>
+
+<p>The core i2c functionality is based on Bunnie Huang's i2c_slave.v from the
+novena-ws2312b-fpga project (https://github.com/xobs/novena-ws2812b-fpga).</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/comm/i2c)]]
+
+| Clone `https://git.cryptech.is/core/comm/i2c.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fuart.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fuart.md
new file mode 100644
index 0000000..7a2532d
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm%2Fuart.md
@@ -0,0 +1,27 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>uart</h1>
+
+<p>A Universal asynchronous receiver/transmitter (UART) implemented in Verilog.</p>
+
+<p>This UART used to be in coretest, but has been moved out as a separate
+project.</p>
+
+<p>The current implementation supports the ability to set the bit rate as
+well as number of data- and stop bits by writing to control addresses
+via the control interface.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/comm/uart)]]
+
+| Clone `https://git.cryptech.is/core/comm/uart.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm.md
new file mode 100644
index 0000000..6769db2
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fcomm.md
@@ -0,0 +1,21 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/comm/coretest| core/comm/coretest]] |`https://git.cryptech.is/core/comm/coretest.git` | [[wiki:GitRepositories/core/comm/coretest| README]] |
+|[[source:/core/comm/eim| core/comm/eim]] |`https://git.cryptech.is/core/comm/eim.git` | [[wiki:GitRepositories/core/comm/eim| README]] |
+|[[source:/core/comm/fmc| core/comm/fmc]] |`https://git.cryptech.is/core/comm/fmc.git` | [[wiki:GitRepositories/core/comm/fmc| README]] |
+|[[source:/core/comm/i2c| core/comm/i2c]] |`https://git.cryptech.is/core/comm/i2c.git` | [[wiki:GitRepositories/core/comm/i2c| README]] |
+|[[source:/core/comm/uart| core/comm/uart]] |`https://git.cryptech.is/core/comm/uart.git` | [[wiki:GitRepositories/core/comm/uart| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha1.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha1.md
new file mode 100644
index 0000000..f9992f3
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha1.md
@@ -0,0 +1,309 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>sha1</h1>
+
+<h2>Introduction</h2>
+
+<p>Verilog implementation of the SHA-1 cryptgraphic hash function. The
+functionality follows the specification in NIST FIPS 180-4.</p>
+
+<p>The sha1 design is divided into the following sections.</p>
+
+<ul>
+<li>src/rtl - RTL source files</li>
+<li>src/tb  - Testbenches for the RTL files</li>
+<li>src/model/python - Functional model written in python</li>
+<li>doc/ - documentation (currently not done.)</li>
+<li>toolruns/ - Where tools are supposed to be run. Includes a Makefile
+for building and simulating the design using <a href="http://iverilog.icarus.com/">Icarus
+Verilog</a>.</li>
+</ul>
+
+<p>The actual core consists of the following RTL files:</p>
+
+<ul>
+<li>sha1.v</li>
+<li>sha1_core.v</li>
+<li>sha1_w_mem.v</li>
+</ul>
+
+<p>The main core functionality is in the sha1_core file. The file
+sha1_w_mem contains the message block memory W (see FIPS 180-4).
+The top level entity is called sha1_core. The sha1_core module has wide
+interfaces (512 bit block input, 160 bit digest). In order to make it
+usable you probably want to wrap the core with a bus interface.</p>
+
+<p>The file sha1.v contains a top level wrapper that provides a simple
+interface with 32-bit data access . This interface contains mesage block
+and digest registers to allow a host to load the next block while the
+current block is being processed.</p>
+
+<h2>API</h2>
+
+<p>The following list contains the address map for all registers
+implemented by the sha1 top level wrapper:</p>
+
+<table>
+<thead>
+<tr>
+  <th>address</th>
+  <th>name</th>
+  <th>access</th>
+  <th>description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+  <td>0x00</td>
+  <td>name0</td>
+  <td>R</td>
+  <td>"SHA1"</td>
+</tr>
+<tr>
+  <td>0x01</td>
+  <td>name1</td>
+  <td>R</td>
+  <td>"    "</td>
+</tr>
+<tr>
+  <td>0x02</td>
+  <td>version</td>
+  <td>R</td>
+  <td>"0.50"</td>
+</tr>
+<tr>
+  <td></td>
+</tr>
+<tr>
+  <td>0x08</td>
+  <td>control</td>
+  <td>R/W</td>
+  <td>Control of core. Bit 0: init, Bit 1: next</td>
+</tr>
+<tr>
+  <td>0x09</td>
+  <td>status</td>
+  <td>R/W</td>
+  <td>Status of core. Bit 0: Ready, Bit 1: valid data</td>
+</tr>
+<tr>
+  <td></td>
+</tr>
+<tr>
+  <td>0x10</td>
+  <td>block0</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x11</td>
+  <td>block1</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x12</td>
+  <td>block2</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x13</td>
+  <td>block3</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x14</td>
+  <td>block4</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x15</td>
+  <td>block5</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x16</td>
+  <td>block6</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x17</td>
+  <td>block7</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x18</td>
+  <td>block8</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x19</td>
+  <td>block9</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x1a</td>
+  <td>block10</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x1b</td>
+  <td>block11</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x1c</td>
+  <td>block12</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x1d</td>
+  <td>block13</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x1e</td>
+  <td>block14</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td>0x1f</td>
+  <td>block15</td>
+  <td>R/W</td>
+  <td>data block register</td>
+</tr>
+<tr>
+  <td></td>
+</tr>
+<tr>
+  <td>0x20</td>
+  <td>digest0</td>
+  <td>R/W</td>
+  <td>digest register</td>
+</tr>
+<tr>
+  <td>0x21</td>
+  <td>digest1</td>
+  <td>R/W</td>
+  <td>digest register</td>
+</tr>
+<tr>
+  <td>0x22</td>
+  <td>digest2</td>
+  <td>R/W</td>
+  <td>digest register</td>
+</tr>
+<tr>
+  <td>0x23</td>
+  <td>digest3</td>
+  <td>R/W</td>
+  <td>digest register</td>
+</tr>
+<tr>
+  <td>0x24</td>
+  <td>digest4</td>
+  <td>R/W</td>
+  <td>digest register</td>
+</tr>
+</tbody>
+</table>
+
+<h2>Implementation details</h2>
+
+<p>The implementation is iterative with one cycle/round. The initialization
+takes one cycle. The W memory is based around a sliding window of 16
+32-bit registers that are updated in sync with the round processing. The
+total latency/message block is 82 cycles.</p>
+
+<p>All registers have asynchronous reset.</p>
+
+<p>The design has been implemented and tested on TerasIC DE0-Nano and C5G
+FPGA boards.</p>
+
+<h2>Status</h2>
+
+<p>The design has been implemented and extensively been tested on TerasIC
+DE0-Nano and C5G FPGA boards. The core has also been tested using SW
+running on The Novena CPU talking to the core in the Xilinx Spartan-6
+FPGA.</p>
+
+<h2>FPGA-results</h2>
+
+<h3>Altera Cyclone FPGAs</h3>
+
+<p>Implementation results using Altera Quartus-II 13.1.</p>
+
+<p><strong><em>Altera Cyclone IV E</em></strong></p>
+
+<ul>
+<li>EP4CE6F17C6</li>
+<li>2913 LEs</li>
+<li>1527 regs</li>
+<li>107 MHz</li>
+</ul>
+
+<p><strong><em>Altera Cyclone IV GX</em></strong></p>
+
+<ul>
+<li>EP4CGX22CF19C6</li>
+<li>2814 LEs</li>
+<li>1527 regs</li>
+<li>105 MHz</li>
+</ul>
+
+<p><strong><em>Altera Cyclone V</em></strong></p>
+
+<ul>
+<li>5CGXFC7C7F23C8</li>
+<li>1124 ALMs</li>
+<li>1527 regs</li>
+<li>104 MHz</li>
+</ul>
+
+<h3>Xilinx FPGAs</h3>
+
+<p>Implementation results using ISE 14.7.</p>
+
+<p><em>* Xilinx Spartan-6 *</em></p>
+
+<ul>
+<li>xc6slx45-3csg324</li>
+<li>1589 LUTs</li>
+<li>564 Slices</li>
+<li>1592 regs</li>
+<li>100 MHz</li>
+</ul>
+
+<h2>TODO</h2>
+
+<ul>
+<li>Documentation</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=core/hash/sha1)]]
+
+| Clone `https://git.cryptech.is/core/hash/sha1.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha256.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha256.md
new file mode 100644
index 0000000..a07b476
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha256.md
@@ -0,0 +1,183 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>sha256</h1>
+
+<p>Hardware implementation of the SHA-256 cryptographic hash function. The
+implementation is written in Verilog 2001 compliant code. The
+implementation includes a core and a wrapper that provides a 32-bit
+interface for simple integration. There is also an alternative wrapper
+that implements a Wishbone compliant interface.</p>
+
+<p>This is a low area implementation that iterates over the rounds but
+there is no sharing of operations such as adders.</p>
+
+<p>The hardware implementation is complemented by a functional model
+written in Python.</p>
+
+<h2>Implementation details</h2>
+
+<p>The sha256 is divided into the following sections.</p>
+
+<ul>
+<li>src/rtl - RTL source files</li>
+<li>src/tb  - Testbenches for the RTL files</li>
+<li>src/model/python - Functional model written in python</li>
+<li>doc - documentation (currently not done.)</li>
+<li>toolruns - Where tools are supposed to be run. Includes a Makefile for
+building and simulating the design using <a href="http://iverilog.icarus.com/">Icarus Verilog</a></li>
+</ul>
+
+<p>The actual core consists of the following files:</p>
+
+<ul>
+<li>sha256_core.v - The core itself with wide interfaces.</li>
+<li>sha256_w_mem.v - W message block memort and expansion logic.</li>
+<li>sha256_k_constants.v - K constants ROM memory.</li>
+</ul>
+
+<p>The top level entity is called sha256_core. This entity has wide
+interfaces (512 bit block input, 256 bit digest). In order to make it
+usable you probably want to wrap the core with a bus interface.</p>
+
+<p>Unless you want to provide your own interface you therefore also need to
+select one top level wrapper. There are two wrappers provided:</p>
+
+<ul>
+<li>sha256.v - A wrapper with a 32-bit memory like interface.</li>
+<li>wb_sha256.v - A wrapper that implements a <a href="http://opencores.org/opencores,wishbone">Wishbone</a> interface.</li>
+</ul>
+
+<p><strong><em>Do not include both wrappers in the same project.</em></strong></p>
+
+<p>The core (sha256_core) will sample all data inputs when given the init
+or next signal. the wrappers provided contains additional data
+registers. This allows you to load a new block while the core is
+processing the previous block.</p>
+
+<p>The W-memory scheduler is based on 16 32-bit registers. Thee registers
+are loaded with the current block. After 16 rounds the contents of the
+registers slide through the registers r5..r0 while the new W word is
+inserted at r15 as well as being returned to the core.</p>
+
+<h2>FPGA-results</h2>
+
+<h3>Altera Cyclone FPGAs</h3>
+
+<p>Implementation results using Altera Quartus-II 13.1.</p>
+
+<p><strong><em>Cyclone IV E</em></strong></p>
+
+<ul>
+<li>EP4CE6F17C6</li>
+<li>3882 LEs</li>
+<li>1813 registers</li>
+<li>74 MHz</li>
+<li>66 cycles latency</li>
+</ul>
+
+<p><strong><em>Cyclone IV GX</em></strong></p>
+
+<ul>
+<li>EP4CGX22CF19C6</li>
+<li>3773 LEs</li>
+<li>1813 registers</li>
+<li>76 MHz</li>
+<li>66 cycles latency</li>
+</ul>
+
+<p><strong><em>Cyclone V</em></strong></p>
+
+<ul>
+<li>5CGXFC7C7F23C8</li>
+<li>1469 ALMs</li>
+<li>1813 registers</li>
+<li>79 MHz</li>
+<li>66 cycles latency</li>
+</ul>
+
+<h3>Xilinx Artix-7 FPGAs</h3>
+
+<p>Implementation results using Xilinx ISE 14.7
+This implementation includes pipeline regsisters.</p>
+
+<ul>
+<li>xc7a200t-1fbg484</li>
+<li>2229 Slice LUTs</li>
+<li>775 Slices</li>
+<li>1935 registers</li>
+<li>101 MHz</li>
+<li>130 cycles latency</li>
+</ul>
+
+<h2>TODO</h2>
+
+<ul>
+<li>Extensive verification in physical device.</li>
+<li>Complete documentation.</li>
+</ul>
+
+<h2>Status</h2>
+
+<p><strong><em>(2016-05-31)</em></strong></p>
+
+<p>The core now supports both sha224 and sha256 modes. The default mode is
+sha256.</p>
+
+<p>NOTE: The mode bit is located in the ADDR_CTRL API register and this
+means that when writing to this register to start processing a block,
+care must be taken to set the mode bit to the intended mode. This means
+that old code that for example simply wrote 0x01 to initiate SHA256
+processing will now initiate SHA224 processing. Writing 0x05 will
+now initiate SHA256 processing.</p>
+
+<p>The API version has been bumped a major number to reflect this change.</p>
+
+<p>Regarding SHA224, it is up to the user to only read seven, not eight
+words from the digest registers. The core will update the LSW too.</p>
+
+<p><strong><em>(2013-02-23)</em></strong></p>
+
+<p>Cleanup, more results etc. Move all wmem update logic to a separate
+process for a cleaner code.</p>
+
+<p><strong>(2014-02-22)</strong></p>
+
+<p>Redesigned the W-memory into a sliding window solution. This not only
+removed 48 32-registers but also several muxes and address decoders.</p>
+
+<p>The old implementation resources and performance:</p>
+
+<ul>
+<li>9587 LEs</li>
+<li>3349 registers</li>
+<li>73 MHz</li>
+<li>66 cycles latency</li>
+</ul>
+
+<p>The new implementation resources and performance:</p>
+
+<ul>
+<li>3765 LEs</li>
+<li>1813 registers</li>
+<li>76 MHz</li>
+<li>66 cycles latency</li>
+</ul>
+
+<p><strong>(2014-02-19)</strong>
+- The core has been added to the Cryptech repo. The core comes from
+  https://github.com/secworks/sha256</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/hash/sha256)]]
+
+| Clone `https://git.cryptech.is/core/hash/sha256.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha3.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha3.md
new file mode 100644
index 0000000..7e6a74f
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha3.md
@@ -0,0 +1,105 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>SHA-3</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements the sponge construction defined in the SHA-3 hash standard.</p>
+
+<h2>API Specification</h2>
+
+<p>The interface of the core is similar to other CrypTech cores. FMC memory map is split into two parts, the first part contains registers and looks like the following:</p>
+
+<table>
+<thead>
+<tr>
+  <th>Offset</th>
+  <th>Register</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+  <td>0x0000</td>
+  <td>NAME0</td>
+</tr>
+<tr>
+  <td>0x0004</td>
+  <td>NAME1</td>
+</tr>
+<tr>
+  <td>0x0008</td>
+  <td>VERSION</td>
+</tr>
+<tr>
+  <td>0x0020</td>
+  <td>CONTROL</td>
+</tr>
+<tr>
+  <td>0x0024</td>
+  <td>STATUS</td>
+</tr>
+</tbody>
+</table>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong> <br />
+Read-only core name ("sha3", "    " [four whitespaces]).</p></li>
+<li><p><strong>VERSION</strong> <br />
+Read-only core version, currently "0.10".</p></li>
+<li><p><strong>CONTROL</strong> <br />
+Register bits: <br />
+[31:2] Don't care, always read as 0 <br />
+[1] "next" control bit <br />
+[0] "init" control bit <br />
+The "init" control bit replaces the core's state with the contents of the input block and starts hashing, it should be used to absorb the very first block of data into the sponge. The "next" control bit xor's the core's state with the contents of the input block and continues hashing, it should be used to absorb subsequent blocks into the sponge. The core starts operation when a control bit changes from 0 to 1. This way when a bit is set, the core will only perform one operation and then stop. To start another operation, the bit must be cleared at first and then set to 1 again. Note, that "init" has priority over "next", if both bits are set simultaneously, "init" takes precedence.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only register bits: <br />
+[31:2] Don't care, always read as 0 <br />
+[1] "valid" control bit <br />
+[0] "ready" control bit (always read as 1) <br />
+The "valid" status bit is cleared as soon as the core starts absorbing input data block, and gets set after the operation is complete. The "ready" status bit is hardwired to always read 1.</p></li>
+</ul>
+
+<p>The second part of the address space is split into two banks:</p>
+
+<table>
+<thead>
+<tr>
+  <th>Offset</th>
+  <th>Bank</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+  <td>0x200</td>
+  <td>BLOCK</td>
+</tr>
+<tr>
+  <td>0x300</td>
+  <td>STATE</td>
+</tr>
+</tbody>
+</table>
+
+<p>Length of each bank is 200 bytes, the first bank has read-write access and contains input data block, the second bank is read-only and contains the core's internal state.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>This core doesn't use vendor-specific primitives.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/hash/sha3)]]
+
+| Clone `https://git.cryptech.is/core/hash/sha3.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha512.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha512.md
new file mode 100644
index 0000000..bec9494
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash%2Fsha512.md
@@ -0,0 +1,58 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>sha512</h1>
+
+<p>Verilog implementation of the SHA-512 hash function. This implementation
+complies with the functionality in NIST FIPS 180-4. The supports the
+SHA-512 variants SHA-512/224, SHA-512/256, SHA-384 and SHA-512.</p>
+
+<h2>Implementation details</h2>
+
+<p>The core uses a sliding window with 16 64-bit registers for the W
+memory. The top level wrapper contains flag control registers for init
+and next that automatically resets. This means that the flags must be
+set for every block to be processed.</p>
+
+<h2>Status</h2>
+
+<p><strong><em>(2014-04-05)</em></strong></p>
+
+<p>RTL for the core and top is completed Testbenches for core and top
+completed. All single block and dual block test cases works. Results
+after building the complete design for Altera Cyclone V GX:</p>
+
+<ul>
+<li>2919 ALMs</li>
+<li>3609 Registers</li>
+<li>77 MHz max clock frequency</li>
+</ul>
+
+<p><strong><em>(2014-03-24)</em></strong></p>
+
+<p>Core works for the SHA-512 mode case. Added top level wrapper and built
+the design for Altera Cyclone V GX:</p>
+
+<ul>
+<li>2923 ALMs</li>
+<li>3609 Registers</li>
+<li>80 MHz max clock frequency</li>
+</ul>
+
+<p><strong><em>(2014-02-23)</em></strong></p>
+
+<p>Initial version. Based on the SHA-256 core. Nothing really to see yet.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/hash/sha512)]]
+
+| Clone `https://git.cryptech.is/core/hash/sha512.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fhash.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash.md
new file mode 100644
index 0000000..0d90078
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fhash.md
@@ -0,0 +1,20 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/hash/sha1| core/hash/sha1]] |`https://git.cryptech.is/core/hash/sha1.git` | [[wiki:GitRepositories/core/hash/sha1| README]] |
+|[[source:/core/hash/sha256| core/hash/sha256]] |`https://git.cryptech.is/core/hash/sha256.git` | [[wiki:GitRepositories/core/hash/sha256| README]] |
+|[[source:/core/hash/sha3| core/hash/sha3]] |`https://git.cryptech.is/core/hash/sha3.git` | [[wiki:GitRepositories/core/hash/sha3| README]] |
+|[[source:/core/hash/sha512| core/hash/sha512]] |`https://git.cryptech.is/core/hash/sha512.git` | [[wiki:GitRepositories/core/hash/sha512| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Flib.md b/raw-wiki-dump/GitRepositories%2Fcore%2Flib.md
new file mode 100644
index 0000000..4e54390
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Flib.md
@@ -0,0 +1,38 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>core/lib</h1>
+
+<p>This repository contains common modules instantiated by other cores:</p>
+
+<ul>
+<li><p><strong>lowlevel</strong> contains modules for math operations (addition, subtraction, etc). Two sets of modules are provided: <strong>generic</strong> ones can be used during simulation and when porting to a different architecture, modules from <strong>artix7</strong> should be used when building a bitstream for the Alpha board. To use the modules first <code>`include "cryptech_primitive_switch.vh"</code>, then instantiate them using <code>`CRYPTECH_PRIMITIVE_*</code> macro.</p></li>
+<li><p><strong>memory</strong> contains wrappers for block memories:</p>
+
+<ul>
+<li><code>bram_1rw_readfirst</code> is single read-write port</li>
+<li><code>bram_1rw_1ro_readfirst</code> is one read-write, one read-only port</li>
+<li><code>bram_1wo_1ro_readfirst</code> is one write-only, one read-only port (useful for storing private keys)</li>
+</ul></li>
+<li><p><strong>modular</strong> contains multiprecision modular adder and subtractor</p></li>
+<li><p><strong>multiword</strong> contains multiprecision integer comparator and mover/copier</p></li>
+<li><p><strong>util</strong> has the following:</p>
+
+<ul>
+<li><code>cryptech_clog2.vh</code> replacement for Xilinx' notorious clog2()</li>
+</ul></li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=core/lib)]]
+
+| Clone `https://git.cryptech.is/core/lib.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fecdsalib.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fecdsalib.md
new file mode 100644
index 0000000..2b08cde
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fecdsalib.md
@@ -0,0 +1,28 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdsalib</h1>
+
+<h2>Core Description</h2>
+
+<p>This is a library of code common to the ecdsa256 and ecdsa384 cores.  See documentation of those cores for details.</p>
+
+<p>This code was originally repelicated in both of the above cores, but the Xilinx synthesis tools got tetchy about that when trying to build a single image containing both cores.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>Cryptech Alpha platform is based on Xilinx Artix-7 200T FPGA, so this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/lowlevel/artix7, the core also offers generic replacements under /rtl/lowlevel/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. Selection of vendor/generic primitives is done in ecdsa_lowlevel_settings.v, when porting to other architectures, only those four low-level modules need to be ported.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/math/ecdsalib)]]
+
+| Clone `https://git.cryptech.is/core/math/ecdsalib.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexp.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexp.md
new file mode 100644
index 0000000..98d30a4
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexp.md
@@ -0,0 +1,109 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>modexp</h1>
+
+<p>Modular exponentiation core for implementing public key algorithms such
+as RSA, DH, ElGamal etc.</p>
+
+<p>The core calculates the following function:</p>
+
+<p>C = M ** e mod N</p>
+
+<p>M is a message with a length of n bits
+  e is the exponent with a length of m bits
+  N is the modulus  with a length of n bits</p>
+
+<p>The size n be one and up to and including 8192 bits in steps of 32
+bits.</p>
+
+<p>The size m be one and up to and including 8192 bits in steps of 32
+bits.</p>
+
+<p>The core has a 32-bit memory like interface, but provides status signals
+to inform the system that a given operation has is done. Additionally,
+any errors will also be asserted.</p>
+
+<p>The core is written in Verilog 2001 and suitable for implementation in
+FPGA and ASIC devices. No vendor specific macros are used in the code.</p>
+
+<h2>Implementation details</h2>
+
+<p>The core is iterative with 32-bit operands and not the fastest core on
+the planet.</p>
+
+<h2>Future developments</h2>
+
+<ul>
+<li><p>The core will perform blinding to protect against side channel
+attacks.</p></li>
+<li><p>Increased operands to 64-, 128-, or possibly even 256 bits for
+increased performance.</p></li>
+</ul>
+
+<h2>FPGA-results</h2>
+
+<h2>Altera Cyclone-V</h2>
+
+<ul>
+<li>203 registers</li>
+<li>387 ALMs</li>
+<li>106496 block memory bits</li>
+<li>107 MHz</li>
+</ul>
+
+<h3>Xilinx Artix-7 100T</h3>
+
+<ul>
+<li>160 registers</li>
+<li>565 LUTs</li>
+<li>13 RAMB18E1 block memories</li>
+<li>160 MHz</li>
+</ul>
+
+<h3>Xilinx Spartan-6 LX45</h3>
+
+<ul>
+<li>169 registers</li>
+<li>589 LUTs</li>
+<li>13 RAMB8BWER block memories</li>
+<li>136 MHz</li>
+</ul>
+
+<h2>Status</h2>
+
+<p><strong><em>(2015-04-27)</em></strong></p>
+
+<p>Modexp simulation with exponent and modolus with up to 1280 bits
+simulates. The auto test generation system works. Implementation in
+different FPGA types and vendors works.</p>
+
+<p><strong><em>(2015-04-23)</em></strong></p>
+
+<p>The Montgomery multiplication module works. The Residue calculation
+module works. Top level integration and debugging is onging. The core
+does not yet work and there are dragons to be found.</p>
+
+<p><strong><em>(2014-12-07)</em></strong></p>
+
+<p>Renamed the core tom modexp from rsa to make it more clear that it
+provides generic modular exponentiation, not RSA.</p>
+
+<p><strong><em>(2014-10-01)</em></strong></p>
+
+<p>Very early phase. Started to collect information and drawing some rough
+ideas on paper.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/math/modexp)]]
+
+| Clone `https://git.cryptech.is/core/math/modexp.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexpa7.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexpa7.md
new file mode 100644
index 0000000..0cbd63c
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexpa7.md
@@ -0,0 +1,252 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ModExpA7</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements modular exponentiation using the Artix-7 FPGA found on CrypTech Alpha board. It can be used during RSA operations such as encryption/decryption and signing.</p>
+
+<h2>Compile-Time Settings</h2>
+
+<p>The core has two synthesis-time parameters:</p>
+
+<ul>
+<li><p><strong>OPERAND_ADDR_WIDTH</strong> - Sets the _largest supported_ operand width. This affects the amount of block memory that is reserved for operand storage. Largest operand width in bits, that the core can handle is 32 * (2 ** OPERAND_ADDR_WIDTH). If the largest possible modulus is 1024 bits long, set OPERAND_ADDR_WIDTH = 5. For 2048-bit moduli support set OPERAND_ADDR_WIDTH = 6, for 4096-bit capable core set OPERAND_ADDR_WIDTH = 7 and so on.</p></li>
+<li><p><strong>SYSTOLIC_ARRAY_POWER</strong> - Determines the number of processing elements in the internal systolic array, total number of elements is 2 <em>* SYSTOLIC_ARRAY_POWER. This affects the number of DSP slices dedicated to parallelized multiplication. Allowed values are 1..OPERAND_ADDR_WIDTH-1, higher values produce higher performance core at the cost of higher device utilization. The number of used DSP slices is NUM_DSP = 10 + 2 * (2 + 7 * (2 *</em> SYSTOLIC_ARRAY_POWER)). Here's a quick reference table:</p></li>
+</ul>
+
+<table>
+<thead>
+<tr>
+  <th>SYSTOLIC_ARRAY_POWER</th>
+  <th>NUM_DSP</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+  <td>1</td>
+  <td>42</td>
+</tr>
+<tr>
+  <td>2</td>
+  <td>70</td>
+</tr>
+<tr>
+  <td>3</td>
+  <td>126</td>
+</tr>
+<tr>
+  <td>4</td>
+  <td>238</td>
+</tr>
+<tr>
+  <td>5</td>
+  <td>462</td>
+</tr>
+</tbody>
+</table>
+
+<p>Given that Alpha board FPGA has 740 DSP slices, SYSTOLIC_ARRAY_POWER=5 is the largest possible setting. Note that if two cores are needed (eg. to do the two easier CRT exponentiations simultaneously), this parameter should be reduced to 4 to fit two cores into the device.</p>
+
+<h2>API Specification</h2>
+
+<p>The interface of the core is similar to other CrypTech cores. FMC memory map is split into two parts, the first part contains registers and looks like the following:</p>
+
+<table>
+<thead>
+<tr>
+  <th>Offset</th>
+  <th>Register</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+  <td>0x0000</td>
+  <td>NAME0</td>
+</tr>
+<tr>
+  <td>0x0004</td>
+  <td>NAME1</td>
+</tr>
+<tr>
+  <td>0x0008</td>
+  <td>VERSION</td>
+</tr>
+<tr>
+  <td>0x0020</td>
+  <td>CONTROL</td>
+</tr>
+<tr>
+  <td>0x0024</td>
+  <td>STATUS</td>
+</tr>
+<tr>
+  <td>0x0040</td>
+  <td>MODE</td>
+</tr>
+<tr>
+  <td>0x0044</td>
+  <td>MODULUS_BITS</td>
+</tr>
+<tr>
+  <td>0x0048</td>
+  <td>EXPONENT_BITS</td>
+</tr>
+<tr>
+  <td>0x004C</td>
+  <td>BUFFER_BITS</td>
+</tr>
+<tr>
+  <td>0x0050</td>
+  <td>ARRAY_BITS</td>
+</tr>
+</tbody>
+</table>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong> <br />
+Read-only core name ("mode", "xp7a").</p></li>
+<li><p><strong>VERSION</strong> <br />
+Read-only core version, currently "0.20".</p></li>
+<li><p><strong>CONTROL</strong> <br />
+Register bits: <br />
+[31:2] Don't care, always read as 0 <br />
+[1] "next" control bit <br />
+[0] "init" control bit <br />
+The core uses Montgomery modular multiplier, that requires precomputation of modulus-dependent speed-up coefficient. Every time a new modulus is loaded into the core, this coefficient must be precalculated before exponentiation can be started. Changing the "init" bit from 0 to 1 starts precomputation. The core is edge-triggered, this way to start another precomputation the bit must be cleared first and then set to 1 again. The "next" control bit works the same way as the "init" bit, changing the bit from 0 to 1 triggers new exponentiation operation. The "init" bit has priority over the "next" bit, if both bits go high at the same time, precomputation will be started. When repeatedly encrypting/signing using the same modulus, precomputation needs to be done only once before the very first exponentiation.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only register bits: <br />
+[31:2] Don't care, always read as 0 <br />
+[1] "valid" control bit <br />
+[0] "ready" control bit <br />
+The "valid" status bit is cleared as soon as the core starts exponentiation, and gets set after the operation is complete. The "ready" status bit is cleared when the core starts precomputation and is set after the speed-up coefficient is precalculated.</p></li>
+<li><p><strong>MODE</strong> <br />
+Mode register bits: <br />
+[31:2] Don't care, always read as 0 <br />
+[1] "CRT enable" control bit <br />
+[0] Don't care, always read as 0 <br />
+The "CRT enable" control bit allows the core to take advantage of the Chinese remainder theorem to speed up RSA operations. When the CRT mode is disabled (MODE[1] = 0), the message (base) is assumed to be as large as the modulus. When the CRT mode is enabled (MODE[1] = 1), the message is assumed to be twice larger than the modulus and the core will reduce it before starting the exponentiation. Note that if the core was compiled for eg. 4096-bit operands (OPERAND_ADDR_WIDTH=7), it can only handle up to 2048-bit moduli in CRT mode. When singing using eg. 4096-bit public key without CRT, the modulus length must be set to 4096. When signing using the same 4096-bit public key with CRT, modulus length must be set to 2048.</p>
+
+<ul>
+<li><p><strong>MODULUS_BITS</strong> <br />
+Length of modulus in bits, must be a multiple of 32. Smallest allowed value is 64, largest allowed value is 32 * (2 ** OPERAND_ADDR_WIDTH). If the modulus is eg. 1000 bits wide, it must be prepended with 24 zeroes to make it contain an integer number of 32-bit words.</p></li>
+<li><p><strong>EXPONENT_BITS</strong> <br />
+Length of exponent in bits. Smallest allowed value is 2, largest allowed value is 32 * (2 ** OPERAND_ADDR_WIDTH).</p></li>
+<li><p><strong>BUFFER_BITS</strong> <br />
+Length of operand buffer in bits. This read-only parameter returns the length of internal operand buffer and allows the largest supported operand width to be determined at run-time.</p></li>
+<li><p><strong>ARRAY_BITS</strong> <br />
+Length of systolic array in bits. This read-only parameter returns the length of internal systolic multiplier array, it allows SYSTOLIC_ARRAY_POWER compile-time setting to be determined at run-time.</p></li>
+</ul></li>
+</ul>
+
+<p>The second part of the address space contains eight operand banks.</p>
+
+<p>Length of each bank (BANK_LENGTH) depends on the largest supported operand width: 0x80 bytes for 1024-bit core (OPERAND_ADDR_WIDTH = 5), 0x100 bytes for 2048-bit core (OPERAND_ADDR_WIDTH = 6), 0x200 bytes for 4096-bit core (OPERAND_ADDR_WIDTH = 7) and so on.</p>
+
+<p>The offset of the second part is 8 * BANK_LENGTH: 0x400 for 1024-bit core, 0x800 for 2048-bit core, 0x1000 for 4096-bit core and so on. The core has the following eight banks:</p>
+
+<table>
+<thead>
+<tr>
+  <th>Offset</th>
+  <th>Bank</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+  <td>8 * BANK_LENGTH</td>
+  <td>MODULUS</td>
+</tr>
+<tr>
+  <td>9 * BANK_LENGTH</td>
+  <td>MESSAGE (BASE)</td>
+</tr>
+<tr>
+  <td>10 * BANK_LENGTH</td>
+  <td>EXPONENT</td>
+</tr>
+<tr>
+  <td>11 * BANK_LENGTH</td>
+  <td>RESULT</td>
+</tr>
+<tr>
+  <td>12 * BANK_LENGTH</td>
+  <td>MODULUS_COEFF_OUT</td>
+</tr>
+<tr>
+  <td>13 * BANK_LENGTH</td>
+  <td>MODULUS_COEFF_IN</td>
+</tr>
+<tr>
+  <td>14 * BANK_LENGTH</td>
+  <td>MONTGOMERY_FACTOR_OUT</td>
+</tr>
+<tr>
+  <td>15 * BANK_LENGTH</td>
+  <td>MONTGOMERY_FACTOR_IN</td>
+</tr>
+</tbody>
+</table>
+
+<p>MODULUS, MESSAGE and EXPONENT banks are read-write, the RESULT bank stores the result of the exponentiation and is read-only.</p>
+
+<p>After precomputation the modulus-dependent speed-up coefficient and the Montgomery factor are placed in "output" MODULUS_COEFF_OUT and MONTGOMERY_FACTOR_OUT banks, the two banks are read-only. Before exponentiation corresponding modulus-dependent coefficient and Montgomery factor must be placed in "input" MODULUS_COEFF_IN and MONTGOMERY_FACTOR_IN banks, they are read-write. This split input/output banks design allows precomputed quantities to be retrieved from the core and stored along with the key for later reuse. Note that each key requires three pairs of precomputed numbers: one for the public key and two for each of the secret key components.</p>
+
+<h2>Implementation Details</h2>
+
+<p>The top-level core module contains:</p>
+
+<ul>
+<li>Block memory buffers for input and output operands</li>
+<li>Block memory buffers for internal quantities</li>
+<li>Precomputation module (Montgomery modulus-dependent speed-up coefficient)</li>
+<li>Precomputation module (Montgomery parasitic power compensation factor)</li>
+<li>Exponentiation module</li>
+</ul>
+
+<p>The exponentiation module contains:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Two modular multipliers that do right-to-left binary exponentiation (one multiplier does squaring, the other one does multiplication simultaneously)</li>
+</ul>
+
+<p>The modular multiplier module contains:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Wide operand loader</li>
+<li>Systolic array of processing elements</li>
+<li>Adder</li>
+<li>Subtractor</li>
+</ul>
+
+<p>The systolic array of processing elements contains:</p>
+
+<ul>
+<li>Array of processing elements</li>
+<li>Two FIFOs that accomodate carries and products</li>
+</ul>
+
+<p>Note, that the core is supplemented by a reference model written in C, that has extensive comments describing tricky corners of the underlying math.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>CrypTech Alpha platform is based on the Xilinx Artix-7 200T FPGA, this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/pe/artix7/. The core also offers generic replacements under /rtl/pe/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. When porting to other architectures, only those three low-level modules need to be ported. Selection of vendor/generic primitives is done in modexpa7_primitive_switch.v. Note that if you change the latency of the processing element, the SYSTOLIC_PE_LATENCY setting in modexpa7_settings.v must be changed accordingly.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/math/modexpa7)]]
+
+| Clone `https://git.cryptech.is/core/math/modexpa7.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexpng.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexpng.md
new file mode 100644
index 0000000..3a970ef
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath%2Fmodexpng.md
@@ -0,0 +1,214 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ModExpNG</h1>
+
+<h2>Core Description</h2>
+
+<p>This "next-generation" IP core implements the modular exponentiation math primitive using the specialized DSP slices present in the Artix-7 FPGA found on the CrypTech Alpha board. It can be used during RSA operations such as encryption/decryption and signing. Given a pair of blinding factors, the core internally blinds the message before signing and then unblinds it afterwards. The blinding factors are automatically mutated during each exponentiation for later reuse. Another prominent feature is the full support for Chinese Remainder Theorem. Given smaller moduli P and Q, the core can do the mixed-radix conversion variant of the algorithm ("Garner's formula") for faster computation. Due to limitations of the underlying hardware (primarily the capacity of the BlockRAM tile in the 7-Series Xilinx devices) the largest supported key length is 4096 bits.</p>
+
+<h2>Compile-Time Settings</h2>
+
+<p>The core has one synthesis-time parameter:</p>
+
+<ul>
+<li><strong>NUM_MULTS</strong> - Sets the number of DSP slices to use per modular multiplier, which must be a power of 2. Each multiplier consumes NUM_MULTS + 1 slices, since one additional multiplier is required to eliminate the final conditional subtraction step of the Montgomery modular multiplication routine. The core internally consists of a pair of <em>dual modular multipliers</em>, thus the total number of occupied DSP slices is 4 * (NUM_MULTS + 1). When in CRT mode, both <em>dual multipliers</em> operate simultaneously, each with its own modulus. The two multipliers inside of the <em>dual multiplier</em> simultaneously do the squaring and multiplication operations, which constitute one step of the Montgomery powering ladder.</li>
+</ul>
+
+<p>Combined DSP slice utilization is outlined in the following table:</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead>              <tr><th> NUM_MULTS </th><th> DSP Usage </th></tr></thead>
+<tbody align="right"><tr><td>         8 </td><td>        36 </td></tr></tbody>
+<tbody align="right"><tr><td>        16 </td><td>        68 </td></tr></tbody>
+<tbody align="right"><tr><td>        32 </td><td>       132 </td></tr></tbody>
+<tbody align="right"><tr><td>        64 </td><td>       260 </td></tr></tbody>
+</table>
+
+<p>Currently the core has been tested in hardware with a balanced setting of NUM_MULTS = 8. Larger values should decreate latency, but proportionally increase DSP slice usage. The core takes advantage of the dedicated high-speed cascade paths between DSP slices, thus all the NUM_MULTS slices must be placed in the same DSP column. Given that the column height for the Artix-7 FPGA is 100 DSP slices, the upper limit on NUM_MULTS is 64. This has not been yet tested in hardware and may require floorplanning or additional operand "broadcast" tree, which is a topic for future research.</p>
+
+<h2>API Specification</h2>
+
+<p>The interface of the core is similar to other CrypTech cores. FMC memory map is split into four regions (REGISTERS, INPUT_0, INPUT_1 and OUTPUT), each region is 32 kilobits (4 kilobytes). The first one (REGISTERS) contains core registers and looks like the following:</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup>
+<thead><tr><th colspan=2> REGISTERS Memory Map </th></tr></thead>
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead><tr><th> Offset </th><th> Register      </th></tr></thead>
+<tbody><tr><td> 0x0000 </td><td> NAME0         </td></tr></tbody>
+<tbody><tr><td> 0x0004 </td><td> NAME1         </td></tr></tbody>
+<tbody><tr><td> 0x0008 </td><td> VERSION       </td></tr></tbody>
+<tbody><tr><td> 0x0020 </td><td> CONTROL       </td></tr></tbody>
+<tbody><tr><td> 0x0024 </td><td> STATUS        </td></tr></tbody>
+<tbody><tr><td> 0x0040 </td><td> MODE          </td></tr></tbody>
+<tbody><tr><td> 0x0044 </td><td> MODULUS_BITS  </td></tr></tbody>
+<tbody><tr><td> 0x0048 </td><td> EXPONENT_BITS </td></tr></tbody>
+<tbody><tr><td> 0x004C </td><td> BANK_BITS     </td></tr></tbody>
+<tbody><tr><td> 0x0050 </td><td> NUM_MULTS     </td></tr></tbody>
+</table>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong></p>
+
+<p>Read-only core name ("<code>mode</code>", "<code>xpng</code>").</p></li>
+<li><p><strong>VERSION</strong></p>
+
+<p>Read-only core version, currently "<code>0.10</code>".</p></li>
+<li><p><strong>CONTROL</strong></p>
+
+<p>Register bits: <br />
+<code>[31:2]</code> Don't care, always read as 0 <br />
+<code>[1]</code> "<strong>next</strong>" control bit <br />
+<code>[0]</code> Don't care, always read as 0</p>
+
+<p>The "<strong>next</strong>" control bit is used to start an exponentiation. The core is edge-triggered, this way if the bit is currently set, it must be cleared first and then set to 1 again to start a new exponentiation.</p></li>
+<li><p><strong>STATUS</strong></p>
+
+<p>Read-only register bits: <br />
+<code>[31:2]</code> Don't care, always read as 0 <br />
+<code>[1]</code> "<strong>valid</strong>" status bit <br />
+<code>[0]</code> "<strong>ready</strong>" status bit, always read as 1  </p>
+
+<p>The "<strong>valid</strong>" status bit is cleared as soon as the core starts exponentiation, and gets set after the operation is finished.</p></li>
+<li><p><strong>MODE</strong></p>
+
+<p>Mode register bits: <br />
+<code>[31:2]</code> Don't care, always read as 0 <br />
+<code>[1]</code> "<strong>CRT enable</strong>" control bit <br />
+<code>[0]</code> Don't care, always read as 0  </p>
+
+<p>The "<strong>CRT enable</strong>" control bit allows the core to take advantage of the Chinese remainder theorem to speed up RSA operations.</p></li>
+<li><p><strong>MODULUS_BITS</strong></p>
+
+<p>Length of modulus in bits. Smallest allowed value is 64 * NUM_MULTS (currently 64 * 8 = 512), largest allowed value is 4096. The core rounds MODULUS_BITS down to the nearest multiple of 32 * NUM_MULTS (currently 32 * 8 = 256). Thus, allowed key lengths are 512, 768, 1024, 1280, ..., 4096. If the modulus is eg. 1000 bits wide, MODULUS_BITS must be set to 1024 and the modulus must be prepended with 24 zero bits to match the allowed length. Always set this to the length of the public key, do not use twice smaller value when CRT is enabled, the core automatically takes care of that.</p></li>
+<li><p><strong>EXPONENT_BITS</strong></p>
+
+<p>Length of exponent in bits. Smallest allowed value is 4, largest allowed value is 4096.</p></li>
+<li><p><strong>BANK_BITS</strong></p>
+
+<p>Length of operand bank in bits. This read-only parameter returns the length of internal operand bank and allows the largest supported operand width to be determined at run-time. Currently BANK_BITS is hardwired to always return 4096.</p></li>
+<li><p><strong>NUM_MULTS</strong></p>
+
+<p>This read-only parameter returns the width of the internal parallel multiplier, that was specified at compile-time. This parameter is currently 8.</p></li>
+</ul>
+
+<p>The two following memory regions (INPUT_0 and INPUT_1) contain input quantities, each region is split into eight banks, each bank is 4096 bits (512 bytes). The least significat byte of an input quantity should be written to offset 0 in a bank, i.e. one should start filling banks by writing the least significant word at the lowest offset.</p>
+
+<p>The second region (INPUT_0) contains the following banks:</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup>
+<thead><tr><th colspan=2> INPUT_0 Memory Map </th></tr></thead>
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead><tr><th> Offset </th><th> Bank     </th></tr></thead>
+<tbody><tr><td> 0x1000 </td><td> M        </td></tr></tbody>
+<tbody><tr><td> 0x1200 </td><td> N        </td></tr></tbody>
+<tbody><tr><td> 0x1400 </td><td> N_FACTOR </td></tr></tbody>
+<tbody><tr><td> 0x1600 </td><td> N_COEFF  </td></tr></tbody>
+<tbody><tr><td> 0x1A00 </td><td> X        </td></tr></tbody>
+<tbody><tr><td> 0x1C00 </td><td> Y        </td></tr></tbody>
+</table>
+
+<ul>
+<li><p><strong>M</strong> is the message to be signed (base).</p></li>
+<li><p><strong>N</strong> is the modulus (public key).</p></li>
+<li><p><strong>N_FACTOR</strong> is the <strong>N</strong> Montgomery factor and must be precomputed (described later).</p></li>
+<li><p><strong>N_COEFF</strong> is the <strong>N</strong> modulus-dependent speed-up coefficient and must be precomputed (described later). Note, that the bank for <strong>N_COEFF</strong> is twice larger than normal banks.</p></li>
+<li><p>(<strong>X</strong>, <strong>Y</strong>) are a pair of blinding factors. Blinding is always enabled, there's no way to disable it, thus a pair of blinding factors is required for exponentiation. Note, that a pair of (<strong>X</strong>, <strong>Y</strong>) = (1, 1) works just fine, but you effectively aren't doing any blinding this way. The message is blinded using <strong>Y</strong> and unblinded using <strong>X</strong>, thus the relationship between the two must be <strong>Y = (X ** -1) ** e</strong>. Note, that this scheme won't work for encryption, either a pair of (1, 1) must be used, or <strong>X</strong> and <strong>Y</strong> must be swapped. The overhead form blinding is four additional modular multiplications (two to blind-unblind the message and two to mutate the blinding factors) which is &lt;1% for 1024-bit keys and even lower for longer keys.</p></li>
+</ul>
+
+<p>The third region (INPUT_1) contains the following banks. Note, that since the third region contains secret components, it is "write-only", any reads from the region will return 0xDEADCODE.</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup>
+<thead><tr><th colspan=2> INPUT_1 Memory Map </th></tr></thead>
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead><tr><th> Offset </th><th> Bank     </th></tr></thead>
+<tbody><tr><td> 0x2000 </td><td> D        </td></tr></tbody>
+<tbody><tr><td> 0x2200 </td><td> P        </td></tr></tbody>
+<tbody><tr><td> 0x2300 </td><td> DP       </td></tr></tbody>
+<tbody><tr><td> 0x2400 </td><td> P_FACTOR </td></tr></tbody>
+<tbody><tr><td> 0x2600 </td><td> P_COEFF  </td></tr></tbody>
+<tbody><tr><td> 0x2800 </td><td> Q        </td></tr></tbody>
+<tbody><tr><td> 0x2900 </td><td> DQ       </td></tr></tbody>
+<tbody><tr><td> 0x2A00 </td><td> Q_FACTOR </td></tr></tbody>
+<tbody><tr><td> 0x2C00 </td><td> Q_COEFF  </td></tr></tbody>
+<tbody><tr><td> 0x2E00 </td><td> QINV     </td></tr></tbody>
+</table>
+
+<ul>
+<li><p><strong>D</strong> is the exponent (secret exponent for signing, F4 is commonly used for encryption).</p></li>
+<li><p><strong>P</strong>, <strong>Q</strong> are the smaller moduli, they must be supplied when CRT mode is enabled. Note, that their banks are twice smaller than normal banks.</p></li>
+<li><p><strong>DP</strong>, <strong>DQ</strong> are private key components, they must be supplied when CRT mode is enabled. Note, that their banks are twice smaller than normal banks.</p></li>
+<li><p><strong>P_FACTOR</strong>, <strong>Q_FACTOR</strong> are the <strong>P</strong> and <strong>Q</strong> Montgomery factors and must be precomputed (described later).</p></li>
+<li><p><strong>P_COEFF</strong>, <strong>Q_COEFF</strong> are the <strong>P</strong> and <strong>Q</strong> moduli-dependent speed-up coefficients and must be precomputed (described later).</p></li>
+<li><p><strong>QINV</strong> is the private key compoment, it must be supplided when CRT mode is enabled.</p></li>
+</ul>
+
+<p>The fourth region (OUTPUT) contains three banks where the core will store the output quantities:</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup>
+<thead><tr><th colspan=2> OUTPUT Memory Map </th></tr></thead>
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead><tr><th> Offset </th><th> Bank </th></tr></thead>
+<tbody><tr><td> 0x3000 </td><td> S    </td></tr></tbody>
+<tbody><tr><td> 0x3200 </td><td> XM   </td></tr></tbody>
+<tbody><tr><td> 0x3400 </td><td> YM   </td></tr></tbody>
+</table>
+
+<ul>
+<li><p><strong>S</strong> is the signature (or ciphertext after encryption).</p></li>
+<li><p>(<strong>XM</strong>, <strong>YM</strong>) are a pair of mutated blinding factors.</p></li>
+</ul>
+
+<h2>Montgomery Factors and Modulus-dependent Speed-up Coefficients</h2>
+
+<p>The core uses the Montgomery modular multiplier, which can only operate on numbers in the so called Montgomery domain. Bringing input numbers into Montgomery domain and converting output numbers out of Montgomery domain requires a special quantity called Montgomery factor: <strong>FACTOR</strong> = 2 ** (2 * (<strong>MODULUS_BITS</strong> + <strong>WORD_WIDTH</strong>)) mod <strong>N</strong>. This quantity has at most as many bits as the modulus and should be precomputed during key generation. The core's internal data buses are 16-bit wide, so for the formula above <strong>WORD_WIDTH</strong> = 16. The following pseudocode calculates the Montgomery factor given modulus <strong>N</strong>:</p>
+
+<pre><code>F = 1
+for i from 0 to 2 * (MODULUS_BITS + 16) - 1
+    F1 = F &lt;&lt; 1
+    F2 = F1 - N
+    F = (F2 &lt; 0) ? F1 : F2
+return F
+</code></pre>
+
+<p>The final step of Montgomery modular multiplication is Montgomery modular reduction. It is done by adding a multiple of the modulus to the intermediate product. The multiple is selected in such a way, that the lower half of the sum is all zero bits, so it can be safely reduced by just a trivial right shift. This speeds things up, since there's no more need to do computationally difficult division anymore. To determine the multiple of the modulus, another quantity is required, which is the so called modulus-dependent speed-up coefficient: <strong>COEFF</strong> = -<strong>N</strong> ** -1 mod 2 ** (<strong>MODULUS_BITS</strong> + <strong>WORD_WIDTH</strong>). The number of bits needed to store the coefficient exceeds the width of the modulus by one word. The core internally operates on 16-bit words, so the coefficient is wider than the modulus by two bytes. This non-obvious and somewhat inconvenient feature is required to skip the final conditional subtraction step of the "classic" Montgomery modular reduction. Since a selected multiple of the modulus is <em>added</em> to the intermediate product, the result after shifting it to the right can exceed the modulus, so the traditional solution is to do a conditional subtraction as the very last step. The more precise analysis indicates, that the conditional subtraction can be eliminated, if the main loop of the reduction is repeated for at least three additional times, i.e. <strong>MODULUS_BITS</strong> + 3 total iterations. The model operates on entire words internally, so it can only do <strong>MODULUS_BITS</strong> + <strong>WORD_WIDTH</strong> iterations and thus needs 16 extra bits of the speed-up factor. The following pseudocode calculates the modulus-dependent speed-up coefficient:</p>
+
+<pre><code>R = 1
+B = 1
+NN = ~N + 1
+for i from 1 to (MODULUS_BITS + 16 - 1)
+    B = B &lt;&lt; 1
+    T = R * NN mod 2 ** (MODULUS_BITS + 16)
+    if T[i] then
+        R = R + B
+return R
+</code></pre>
+
+<p>The <code>stm32/modexpng_util.c</code> file also has reference C code, that computes the Montgomery factor and the speed-up coeficient. Note that each keypair ideally requires three pairs of precomputed numbers: one for the public key <strong>N</strong> and one for each of the smaller secret moduli <strong>P</strong> and <strong>Q</strong>.</p>
+
+<h2>References</h2>
+
+<ol>
+<li><a href="https://eprint.iacr.org/2017/1115.pdf">Hardware Aspects of Montgomery Modular Multiplication</a></li>
+</ol>
+```
+
+[[RepositoryIndex(format=table,glob=core/math/modexpng)]]
+
+| Clone `https://git.cryptech.is/core/math/modexpng.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fmath.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath.md
new file mode 100644
index 0000000..01097b1
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fmath.md
@@ -0,0 +1,22 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/math/curve25519lib| core/math/curve25519lib]] |`https://git.cryptech.is/core/math/curve25519lib.git` | |
+|[[source:/core/math/ecdsalib| core/math/ecdsalib]] |`https://git.cryptech.is/core/math/ecdsalib.git` | [[wiki:GitRepositories/core/math/ecdsalib| README]] |
+|[[source:/core/math/modexpa7| core/math/modexpa7]] |`https://git.cryptech.is/core/math/modexpa7.git` | [[wiki:GitRepositories/core/math/modexpa7| README]] |
+|[[source:/core/math/modexpng| core/math/modexpng]] |`https://git.cryptech.is/core/math/modexpng.git` | [[wiki:GitRepositories/core/math/modexpng| README]] |
+|[[source:/core/math/modexps6| core/math/modexps6]] |`https://git.cryptech.is/core/math/modexps6.git` | |
+|[[source:/core/math/modexp| core/math/modexp]] |`https://git.cryptech.is/core/math/modexp.git` | [[wiki:GitRepositories/core/math/modexp| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdhp256.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdhp256.md
new file mode 100644
index 0000000..74ffc20
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdhp256.md
@@ -0,0 +1,117 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdhp256</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements the scalar point multiplier for ECDSA curve P-256. It can be used during generation of public keys, the core can also be used as part of the signing operation, it can also do ECDH key exchange.</p>
+
+<h2>API Specification</h2>
+
+<p>The core interface is similar to other Cryptech cores. FMC memory map looks like the following:</p>
+
+<p><code>0x0000 | NAME0</code> <br />
+<code>0x0004 | NAME1</code> <br />
+<code>0x0008 | VERSION</code>  </p>
+
+<p><code>0x0020 | CONTROL</code> <br />
+<code>0x0024 | STATUS</code>  </p>
+
+<p><code>0x0100 | K0</code> <br />
+<code>0x0104 | K1</code> <br />
+<code>...</code> <br />
+<code>0x011C | K7</code>  </p>
+
+<p><code>0x0120 | XIN0</code> <br />
+<code>0x0124 | XIN1</code> <br />
+<code>...</code> <br />
+<code>0x013C | XIN7</code></p>
+
+<p><code>0x0140 | YIN0</code> <br />
+<code>0x0144 | YIN1</code> <br />
+<code>...</code> <br />
+<code>0x015C | YIN7</code>  </p>
+
+<p><code>0x0160 | XOUT0</code> <br />
+<code>0x0164 | XOUT1</code> <br />
+<code>...</code> <br />
+<code>0x017C | XOUT7</code>  </p>
+
+<p><code>0x0180 | YOUT0</code> <br />
+<code>0x0184 | YOUT1</code> <br />
+<code>...</code> <br />
+<code>0x019C | YOUT7</code>  </p>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong>
+Read-only core name ("ecdhp256").</p></li>
+<li><p><strong>VERSION</strong>
+Read-only core version, currently "0.10".</p></li>
+<li><p><strong>CONTROL</strong>
+Control register bits:
+[31:2] Don't care, always read as 0
+[1] "next" control bit
+[0] Don't care, always read as 0
+The core starts multiplication when the "next" control bit changes from 0 to 1. This way when the bit is set, the core will only perform one multiplication and then stop. To start another operation, the bit must be cleared at first and then set to 1 again.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only status register bits:
+[31:2] Don't care, always read as 0
+[1] "valid" control bit
+[0] "ready" control bit (always read as 1)
+The "valid" control bit is cleared as soon as the core starts operation, and gets set after the multiplication operations is complete. Note, that unlike some other Cryptech cores, this core doesn't need any special initialization, so the "ready" control bit is simply hardwired to always read as 1. This is to keep general core interface consistency.</p></li>
+<li><p><strong>K0</strong>-<strong>K7</strong>
+Buffer for the 256-bit multiplication factor (multiplier) K. The core will compute R(XOUT, YOUT) = K * P(XIN, YIN). K0 is the least significant 32-bit word of K, i.e. bits [31:0], while K7 is the most significant 32-bit word of K, i.e. bits [255:224].</p></li>
+<li><p><strong>XIN0</strong>-<strong>XIN7</strong>, <strong>YIN0</strong>-<strong>YIN7</strong>
+Writeable buffers for the 256-bit coordinates X and Y of the input multiplicand P(XIN, YIN). Values should be in affine coordinates. XIN0 and YIN0 contain the least significant 32-bit words, i.e. bits [31:0], while XIN7 and YIN7 contain the most significant 32-bit words, i.e. bits [255:224]. Fill the buffers with coordinates of the base point during public key generation and during multiplication by the per-message (random) number. Fill the buffers with coordinates of Bob's public key to derive Alice's copy of the shared secret key.</p></li>
+<li><p><strong>XOUT0</strong>-<strong>XOUT7</strong>, <strong>YOUT0</strong>-<strong>YOUT7</strong>
+Read-only buffers for the 256-bit coordinates X and Y of the product R(XOUT, YOUT). Values are returned in affine coordinates. XOUT0 and YOUT0 contain the least significant 32-bit words, i.e. bits [31:0], while XOUT7 and YOUT7 contain the most significant 32-bit words, i.e. bits [255:224].</p></li>
+</ul>
+
+<h2>Implementation Details</h2>
+
+<p>The top-level core module contains block memory buffers for input and output operands and the base point multiplier, that reads from the input buffer and writes to the output buffers.</p>
+
+<p>The base point multiplier itself consists of the following:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Configurable "worker" unit</li>
+<li>Microprograms for the worker unit</li>
+<li>Multi-word mover unit</li>
+<li>Modular inversion unit</li>
+</ul>
+
+<p>The "worker" unit can execute five basic operations:</p>
+
+<ul>
+<li>comparison</li>
+<li>copying</li>
+<li>modular addition</li>
+<li>modular subtraction</li>
+<li>modular multiplications</li>
+</ul>
+
+<p>There are two primary microprograms, that the worker runs: curve point doubling and addition of curve point to the base point. Those microprograms use projective Jacobian coordinates, so one more microprogram is used to convert the product into affine coordinates with the help of modular inversion unit.</p>
+
+<p>Note, that the core is supplemented by a reference model written in C, that has extensive comments describing tricky corners of the underlying math.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>Cryptech Alpha platform is based on Xilinx Artix-7 200T FPGA, so this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/lowlevel/artix7, the core also offers generic replacements under /rtl/lowlevel/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. Selection of vendor/generic primitives is done in ecdsa_lowlevel_settings.v, when porting to other architectures, only those four low-level modules need to be ported.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/pkey/ecdhp256)]]
+
+| Clone `https://git.cryptech.is/core/pkey/ecdhp256.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdhp384.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdhp384.md
new file mode 100644
index 0000000..a651ff2
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdhp384.md
@@ -0,0 +1,117 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdhp256</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements the scalar point multiplier for ECDSA curve P-384. It can be used during generation of public keys, the core can also be used as part of the signing operation, it can also do ECDH key exchange.</p>
+
+<h2>API Specification</h2>
+
+<p>The core interface is similar to other Cryptech cores. FMC memory map looks like the following:</p>
+
+<p><code>0x0000 | NAME0</code> <br />
+<code>0x0004 | NAME1</code> <br />
+<code>0x0008 | VERSION</code>  </p>
+
+<p><code>0x0020 | CONTROL</code> <br />
+<code>0x0024 | STATUS</code>  </p>
+
+<p><code>0x0200 | K00</code> <br />
+<code>0x0204 | K01</code> <br />
+<code>...</code> <br />
+<code>0x022C | K11</code>  </p>
+
+<p><code>0x0240 | XIN00</code> <br />
+<code>0x0244 | XIN01</code> <br />
+<code>...</code> <br />
+<code>0x026C | XIN11</code></p>
+
+<p><code>0x0280 | YIN00</code> <br />
+<code>0x0284 | YIN01</code> <br />
+<code>...</code> <br />
+<code>0x02AC | YIN11</code>  </p>
+
+<p><code>0x02C0 | XOUT00</code> <br />
+<code>0x02C4 | XOUT01</code> <br />
+<code>...</code> <br />
+<code>0x02EC | XOUT11</code>  </p>
+
+<p><code>0x0300 | YOUT00</code> <br />
+<code>0x0304 | YOUT01</code> <br />
+<code>...</code> <br />
+<code>0x032C | YOUT11</code>  </p>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong>
+Read-only core name ("ecdhp384").</p></li>
+<li><p><strong>VERSION</strong>
+Read-only core version, currently "0.10".</p></li>
+<li><p><strong>CONTROL</strong>
+Control register bits:
+[31:2] Don't care, always read as 0
+[1] "next" control bit
+[0] Don't care, always read as 0
+The core starts multiplication when the "next" control bit changes from 0 to 1. This way when the bit is set, the core will only perform one multiplication and then stop. To start another operation, the bit must be cleared at first and then set to 1 again.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only status register bits:
+[31:2] Don't care, always read as 0
+[1] "valid" control bit
+[0] "ready" control bit (always read as 1)
+The "valid" control bit is cleared as soon as the core starts operation, and gets set after the multiplication operations is complete. Note, that unlike some other Cryptech cores, this core doesn't need any special initialization, so the "ready" control bit is simply hardwired to always read as 1. This is to keep general core interface consistency.</p></li>
+<li><p><strong>K00</strong>-<strong>K11</strong>
+Buffer for the 384-bit multiplication factor (multiplier) K. The core will compute R(XOUT, YOUT) = K * P(XIN, YIN). K0 is the least significant 32-bit word of K, i.e. bits [31:0], while K11 is the most significant 32-bit word of K, i.e. bits [383:352].</p></li>
+<li><p><strong>XIN00</strong>-<strong>XIN11</strong>, <strong>YIN00</strong>-<strong>YIN11</strong>
+Writeable buffers for the 384-bit coordinates X and Y of the input multiplicand P(XIN, YIN). Values should be in affine coordinates. XIN0 and YIN0 contain the least significant 32-bit words, i.e. bits [31:0], while XIN11 and YIN11 contain the most significant 32-bit words, i.e. bits [383:352]. Fill the buffers with coordinates of the base point during public key generation and during multiplication by the per-message (random) number. Fill the buffers with coordinates of Bob's public key to derive Alice's copy of the shared secret key.</p></li>
+<li><p><strong>XOUT00</strong>-<strong>XOUT11</strong>, <strong>YOUT00</strong>-<strong>YOUT11</strong>
+Read-only buffers for the 384-bit coordinates X and Y of the product R(XOUT, YOUT). Values are returned in affine coordinates. XOUT0 and YOUT0 contain the least significant 32-bit words, i.e. bits [31:0], while XOUT11 and YOUT11 contain the most significant 32-bit words, i.e. bits [383:352].</p></li>
+</ul>
+
+<h2>Implementation Details</h2>
+
+<p>The top-level core module contains block memory buffers for input and output operands and the base point multiplier, that reads from the input buffer and writes to the output buffers.</p>
+
+<p>The base point multiplier itself consists of the following:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Configurable "worker" unit</li>
+<li>Microprograms for the worker unit</li>
+<li>Multi-word mover unit</li>
+<li>Modular inversion unit</li>
+</ul>
+
+<p>The "worker" unit can execute five basic operations:</p>
+
+<ul>
+<li>comparison</li>
+<li>copying</li>
+<li>modular addition</li>
+<li>modular subtraction</li>
+<li>modular multiplications</li>
+</ul>
+
+<p>There are two primary microprograms, that the worker runs: curve point doubling and addition of curve point to the base point. Those microprograms use projective Jacobian coordinates, so one more microprogram is used to convert the product into affine coordinates with the help of modular inversion unit.</p>
+
+<p>Note, that the core is supplemented by a reference model written in C, that has extensive comments describing tricky corners of the underlying math.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>Cryptech Alpha platform is based on Xilinx Artix-7 200T FPGA, so this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/lowlevel/artix7, the core also offers generic replacements under /rtl/lowlevel/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. Selection of vendor/generic primitives is done in ecdsa_lowlevel_settings.v, when porting to other architectures, only those four low-level modules need to be ported.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/pkey/ecdhp384)]]
+
+| Clone `https://git.cryptech.is/core/pkey/ecdhp384.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdsa256.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdsa256.md
new file mode 100644
index 0000000..2aa7251
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdsa256.md
@@ -0,0 +1,103 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdsa256</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements the scalar base point multiplier for ECDSA curve P-256. It can be used during generation of public keys, the core can also be used as part of the signing operation.</p>
+
+<h2>API Specification</h2>
+
+<p>The core interface is similar to other Cryptech cores. FMC memory map looks like the following:</p>
+
+<p><code>0x0000 | NAME0</code>
+<code>0x0004 | NAME1</code>
+<code>0x0008 | VERSION</code></p>
+
+<p><code>0x0020 | CONTROL</code>
+<code>0x0024 | STATUS</code></p>
+
+<p><code>0x0080 | K0</code>
+<code>0x0084 | K1</code>
+<code>...</code>
+<code>0x009C | K7</code>
+<code>0x00A0 | X0</code>
+<code>0x00A4 | X1</code>
+<code>...</code>
+<code>0x00BC | X7</code>
+<code>0x00C0 | Y0</code>
+<code>0x00C4 | Y1</code>
+<code>...</code>
+<code>0x00DC | Y7</code></p>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong>
+Read-only core name ("ecdsa256").</p></li>
+<li><p><strong>VERSION</strong>
+Read-only core version, currently "0.11".</p></li>
+<li><p><strong>CONTROL</strong>
+Control register bits:
+[31:2] Don't care, always read as 0
+[1] "next" control bit
+[0] Don't care, always read as 0
+The core starts multiplication when the "next" control bit changes from 0 to 1. This way when the bit is set, the core will only perform one multiplication and then stop. To start another operation, the bit must be cleared at first and then set to 1 again.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only status register bits:
+[31:2] Don't care, always read as 0
+[1] "valid" control bit
+[0] "ready" control bit (always read as 1)
+The "valid" control bit is cleared as soon as the core starts operation, and gets set after the multiplication operations is complete. Note, that unlike some other Cryptech cores, this core doesn't need any special initialization, so the "ready" control bit is simply hardwired to always read as 1. This is to keep general core interface consistency.</p></li>
+<li><p><strong>K0</strong>-<strong>K7</strong>
+Buffer for the 256-bit multiplication factor (multiplier) K. The core will compute Q = K * G (the base point G is the multiplicand). K0 is the least significant 32-bit word of K, i.e. bits [31:0], while K7 is the most significant 32-bit word of K, i.e. bits [255:224].</p></li>
+<li><p><strong>X0</strong>-<strong>X7</strong>, <strong>Y0</strong>-<strong>Y7</strong>
+Buffers for the 256-bit coordinates X and Y of the product Q = K * G. Values are returned in affine coordinates. X0 and Y0 contain the least significant 32-bit words, i.e. bits [31:0], while X7 and Y7 contain the most significant 32-bit words, i.e. bits [255:224].</p></li>
+</ul>
+
+<h2>Implementation Details</h2>
+
+<p>The top-level core module contains block memory buffers for input and output operands and the base point multiplier, that reads from the input buffer and writes to the output buffers.</p>
+
+<p>The base point multiplier itself consists of the following:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Configurable "worker" unit</li>
+<li>Microprograms for the worker unit</li>
+<li>Multi-word mover unit</li>
+<li>Modular inversion unit</li>
+</ul>
+
+<p>The "worker" unit can execute five basic operations:</p>
+
+<ul>
+<li>comparison</li>
+<li>copying</li>
+<li>modular addition</li>
+<li>modular subtraction</li>
+<li>modular multiplications</li>
+</ul>
+
+<p>There are two primary microprograms, that the worker runs: curve point doubling and addition of curve point to the base point. Those microprograms use projective Jacobian coordinates, so one more microprogram is used to convert the product into affine coordinates with the help of modular inversion unit.</p>
+
+<p>Note, that the core is supplemented by a reference model written in C, that has extensive comments describing tricky corners of the underlying math.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>Cryptech Alpha platform is based on Xilinx Artix-7 200T FPGA, so this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/lowlevel/artix7, the core also offers generic replacements under /rtl/lowlevel/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. Selection of vendor/generic primitives is done in ecdsa_lowlevel_settings.v, when porting to other architectures, only those four low-level modules need to be ported.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/pkey/ecdsa256)]]
+
+| Clone `https://git.cryptech.is/core/pkey/ecdsa256.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdsa384.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdsa384.md
new file mode 100644
index 0000000..d4072a8
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey%2Fecdsa384.md
@@ -0,0 +1,105 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdsa384</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements the scalar base point multiplier for ECDSA curve P-384. It can be used during generation of public keys, the core can also be used as part of the signing operation.</p>
+
+<h2>API Specification</h2>
+
+<p>The core interface is similar to other Cryptech cores. FMC memory map looks like the following:</p>
+
+<p><code>0x0000 | NAME0</code>
+<code>0x0004 | NAME1</code>
+<code>0x0008 | VERSION</code></p>
+
+<p><code>0x0020 | CONTROL</code>
+<code>0x0024 | STATUS</code></p>
+
+<p><code>0x0100 | K0</code>
+<code>0x0104 | K1</code>
+<code>...</code>
+<code>0x012C | K11</code></p>
+
+<p><code>0x0140 | X0</code>
+<code>0x0144 | X1</code>
+<code>...</code>
+<code>0x017C | X11</code></p>
+
+<p><code>0x0180 | Y0</code>
+<code>0x0184 | Y1</code>
+<code>...</code>
+<code>0x01AC | Y11</code></p>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong>
+Read-only core name ("ecdsa384").</p></li>
+<li><p><strong>VERSION</strong>
+Read-only core version, currently "0.11".</p></li>
+<li><p><strong>CONTROL</strong>
+Control register bits:
+[31:2] Don't care, always read as 0
+[1] "next" control bit
+[0] Don't care, always read as 0
+The core starts multiplication when the "next" control bit changes from 0 to 1. This way when the bit is set, the core will only perform one multiplication and then stop. To start another operation, the bit must be cleared at first and then set to 1 again.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only status register bits:
+[31:2] Don't care, always read as 0
+[1] "valid" control bit
+[0] "ready" control bit (always read as 1)
+The "valid" control bit is cleared as soon as the core starts operation, and gets set after the multiplication operations is complete. Note, that unlike some other Cryptech cores, this core doesn't need any special initialization, so the "ready" control bit is simply hardwired to always read as 1. This is to keep general core interface consistency.</p></li>
+<li><p><strong>K0</strong>-<strong>K11</strong>
+Buffer for the 384-bit multiplication factor (multiplier) K. The core will compute Q = K * G (the base point G is the multiplicand). K0 is the least significant 32-bit word of K, i.e. bits [31:0], while K11 is the most significant 32-bit word of K, i.e. bits [383:352].</p></li>
+<li><p><strong>X0</strong>-<strong>X11</strong>, <strong>Y0</strong>-<strong>Y11</strong>
+Buffers for the 384-bit coordinates X and Y of the product Q = K * G. Values are returned in affine coordinates. X0 and Y0 contain the least significant 32-bit words, i.e. bits [31:0], while X11 and Y11 contain the most significant 32-bit words, i.e. bits [383:352].</p></li>
+</ul>
+
+<h2>Implementation Details</h2>
+
+<p>The top-level core module contains block memory buffers for input and output operands and the base point multiplier, that reads from the input buffer and writes to the output buffers.</p>
+
+<p>The base point multiplier itself consists of the following:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Configurable "worker" unit</li>
+<li>Microprograms for the worker unit</li>
+<li>Multi-word mover unit</li>
+<li>Modular inversion unit</li>
+</ul>
+
+<p>The "worker" unit can execute five basic operations:</p>
+
+<ul>
+<li>comparison</li>
+<li>copying</li>
+<li>modular addition</li>
+<li>modular subtraction</li>
+<li>modular multiplications</li>
+</ul>
+
+<p>There are two primary microprograms, that the worker runs: curve point doubling and addition of curve point to the base point. Those microprograms use projective Jacobian coordinates, so one more microprogram is used to convert the product into affine coordinates with the help of modular inversion unit.</p>
+
+<p>Note, that the core is supplemented by a reference model written in C, that has extensive comments describing tricky corners of the underlying math.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>Cryptech Alpha platform is based on Xilinx Artix-7 200T FPGA, so this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/lowlevel/artix7, the core also offers generic replacements under /rtl/lowlevel/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. Selection of vendor/generic primitives is done in ecdsa_lowlevel_settings.v, when porting to other architectures, only those four low-level modules need to be ported.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/pkey/ecdsa384)]]
+
+| Clone `https://git.cryptech.is/core/pkey/ecdsa384.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey.md
new file mode 100644
index 0000000..1b90db0
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fpkey.md
@@ -0,0 +1,21 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/pkey/ecdhp256| core/pkey/ecdhp256]] |`https://git.cryptech.is/core/pkey/ecdhp256.git` | [[wiki:GitRepositories/core/pkey/ecdhp256| README]] |
+|[[source:/core/pkey/ecdhp384| core/pkey/ecdhp384]] |`https://git.cryptech.is/core/pkey/ecdhp384.git` | [[wiki:GitRepositories/core/pkey/ecdhp384| README]] |
+|[[source:/core/pkey/ecdsa256| core/pkey/ecdsa256]] |`https://git.cryptech.is/core/pkey/ecdsa256.git` | [[wiki:GitRepositories/core/pkey/ecdsa256| README]] |
+|[[source:/core/pkey/ecdsa384| core/pkey/ecdsa384]] |`https://git.cryptech.is/core/pkey/ecdsa384.git` | [[wiki:GitRepositories/core/pkey/ecdsa384| README]] |
+|[[source:/core/pkey/ed25519| core/pkey/ed25519]] |`https://git.cryptech.is/core/pkey/ed25519.git` | |
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Falpha.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Falpha.md
new file mode 100644
index 0000000..528454a
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Falpha.md
@@ -0,0 +1,20 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>platform/alpha</h1>
+
+<p>Platform-specific files for the Cryptech Alpha board.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/platform/alpha)]]
+
+| Clone `https://git.cryptech.is/core/platform/alpha.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fcommon.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fcommon.md
new file mode 100644
index 0000000..3d484c4
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fcommon.md
@@ -0,0 +1,25 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>platform/common</h1>
+
+<p>Support code that is used to build projects, but not tied to a particular platform.</p>
+
+<h2>Introduction</h2>
+
+<p>At present, this contains core_selector, a set of muxes to select a core
+by the most significant address bits of a memory-like architecture.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/platform/common)]]
+
+| Clone `https://git.cryptech.is/core/platform/common.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fnovena.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fnovena.md
new file mode 100644
index 0000000..215714e
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fnovena.md
@@ -0,0 +1,33 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>platform/novena</h1>
+
+<p>Platform-specific files for the Novena PVT1.</p>
+
+<h2>Introduction</h2>
+
+<p>This includes the Verilog top-level files and build systems for Novena
+with either I2C or EIM interfaces.</p>
+
+<h2>Status</h2>
+
+<p><strong><em>(2015-03-16)</em></strong>
+Reorganized. Built using Xilinx ISE 14.7.</p>
+
+<p><strong><em>(2014-08-27)</em></strong>
+Initial version. Built using Xilinx ISE 14.3.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/platform/novena)]]
+
+| Clone `https://git.cryptech.is/core/platform/novena.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fterasic_c5g.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fterasic_c5g.md
new file mode 100644
index 0000000..f7b2a72
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform%2Fterasic_c5g.md
@@ -0,0 +1,40 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>platform/terasic_c5g</h1>
+
+<p>Platform-specific files for the TerasIC C5G development board.</p>
+
+<h2>Introduction</h2>
+
+<p>This includes the Verilog top-level files and build systems for Terasic
+with a UART interface.</p>
+
+<h2>Status</h2>
+
+<p><strong><em>(2015-03-16)</em></strong>
+Reorganized. Built using Altera Quarus 14.1.</p>
+
+<p><strong><em>(2014-03-07)</em></strong>
+Initial version. Build using Altera Quarus 13.1.</p>
+
+<ul>
+<li>Cyclone 5 GX device</li>
+<li>2847 ALMs and</li>
+<li>3665 registers</li>
+<li>86 MHz</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=core/platform/terasic_c5g)]]
+
+| Clone `https://git.cryptech.is/core/platform/terasic_c5g.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform.md b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform.md
new file mode 100644
index 0000000..b32e686
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Fplatform.md
@@ -0,0 +1,20 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/platform/alpha| core/platform/alpha]] |`https://git.cryptech.is/core/platform/alpha.git` | [[wiki:GitRepositories/core/platform/alpha| README]] |
+|[[source:/core/platform/common| core/platform/common]] |`https://git.cryptech.is/core/platform/common.git` | [[wiki:GitRepositories/core/platform/common| README]] |
+|[[source:/core/platform/novena| core/platform/novena]] |`https://git.cryptech.is/core/platform/novena.git` | [[wiki:GitRepositories/core/platform/novena| README]] |
+|[[source:/core/platform/terasic_c5g| core/platform/terasic_c5g]] |`https://git.cryptech.is/core/platform/terasic_c5g.git` | [[wiki:GitRepositories/core/platform/terasic_c5g| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Favalanche_entropy.md b/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Favalanche_entropy.md
new file mode 100644
index 0000000..96392df
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Favalanche_entropy.md
@@ -0,0 +1,55 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>avalanche_entropy</h1>
+
+<p>Entropy provider core for an external avalanche noise based entropy source.</p>
+
+<h2>Functional Description</h2>
+
+<p>This core samples noise provided on an input pin. The noise is expected
+to be 'digital' that is fairly rapidly move from voltage levels
+matching ones and zeros as handled by the digital process used to
+implement the core.</p>
+
+<p>The noise is sampled with double registers. Then phase detection is
+applied to find positive flanks. The core contains a free running clock
+(clocked at the provided core clock frequency). When a positive flank in
+the noise is detected, the LSB of the clock is sampled and added to a
+shift registers. When at least 32 bits has been collected, the result is
+presented as entropy available to any entropy consumer connected to the
+core.</p>
+
+<p>The core also includes a delta time counter. This counter is used for
+testing of the core and is available via the API.</p>
+
+<p>The fact that the core uses the flank of the to drive the entropy bit
+generation, but that the timing between the flanks means that if
+the noise source have a bias for zero or one state does not affect which
+entropy bits are generated.</p>
+
+<h2>Implementation Status</h2>
+
+<p>The core has been tested with several revisions of the Cryptech
+avalanche noise board. The core has been implemented in Altera
+Cyclone-IV and Cyclone-V devices as well as in Xilinx Spartan-6
+devices. The core clock frequency used has been 25 MHz, 33 MHz and 50
+MHz.</p>
+
+<p>The generated entropy has been extensively tested (using the ent tool as
+well as other custom tools) and found to be generating entropy with good
+quality.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/rng/avalanche_entropy)]]
+
+| Clone `https://git.cryptech.is/core/rng/avalanche_entropy.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Frosc_entropy.md b/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Frosc_entropy.md
new file mode 100644
index 0000000..9ed3a99
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Frosc_entropy.md
@@ -0,0 +1,52 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>rosc_entropy</h1>
+
+<p>Digital entropy source based on on jitter between multiple, digital ring
+oscillators. The entropy source is used in the TRNG as one of several
+entropy sources feeding the mixer.</p>
+
+<h2>Functionality</h2>
+
+<p>The digital oscillators are created using adders. The carry out from the
+adder are inverted and fed back into the adder as carry in. In
+combination with operand values we basically get an inverted signal (the
+carry out) that toggles reapeatedly. By having the operands externally
+defined, synthesis tools in general will not optimize them away.</p>
+
+<p>The carry out signal is sampled with a clock that toggles at a much
+slower rate than the intrinsic toggle rate of the carry out signal. In a
+modern FPGA, the toggle rate may be 400+ MHz while the sample rate might
+be 10 kHz. This sample time allows the differences in intrinsic toggle
+frequency between separate oscillators to drift apart after sampling.</p>
+
+<p>The entropy source contains 32 separate oscillators. The outputs from
+the oscillators are XOR-combined to create a single entropy bit. Entropy
+bits are collected into 32-bit words which are provided to entropy
+consumers.</p>
+
+<h2>Implementation Results</h2>
+
+<p>The entropy source has been implemented, tested and shown to produce
+good quality entropy (using the ent estimation tool etc) in Altera
+Cyclone-IV and Cyclone-V devices as well as in Xilinx Spartan-6.</p>
+
+<p>The Xilinx synthesis tool will try to optimize the combinational loop
+away. (More specifically, it claims that the oscillator sample registers
+will have a fixed value.). There is therefore an attribute in the source
+code to force the tool to preserve the register.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/rng/rosc_entropy)]]
+
+| Clone `https://git.cryptech.is/core/rng/rosc_entropy.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Ftrng.md b/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Ftrng.md
new file mode 100644
index 0000000..f0601c3
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Ftrng.md
@@ -0,0 +1,193 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>trng</h1>
+
+<p>True Random Number Generator core implemented in Verilog.</p>
+
+<h2>Introduction</h2>
+
+<p>This repo contains the design of a True Random Number Generator (TRNG)
+for the <a href="http://cryptech.is/">Cryptech OpenHSM</a> project.</p>
+
+<h2>Design inspiration, ideas and principles</h2>
+
+<p>The TRNG <strong>MUST</strong> be a really good one. Furthermore it must be trustable
+by its users. That means it should not do wild and crazy stuff. And
+users should be able to verify that the TRNG works as expected.</p>
+
+<ul>
+<li>Follow best practice</li>
+<li>Be conservative - No big untested ideas.</li>
+<li>Support transparency - The parts should be testable.</li>
+</ul>
+
+<p>Some of our inspiration comes from:
+* The Fortuna RNG by Ferguson and Schneier as described in Cryptography
+Engineering.</p>
+
+<ul>
+<li>/dev/random in OpenBSD</li>
+</ul>
+
+<h2>System description</h2>
+
+<p>The TRNG consists of a chain with three main subsystems</p>
+
+<ul>
+<li>Entropy generation</li>
+<li>Entropy mixing</li>
+<li>Random generation</li>
+</ul>
+
+<h3>Entropy generation</h3>
+
+<p>The entropy generation subsystems consists of at least two separate entropy
+generators. Each generator collects entropy from an independent physical
+process. The entropy sources MUST be of different types. For example
+avalance noise from a reversed bias P/N junction as one source and RSSI
+LSB from a receiver.</p>
+
+<p>The reason for having multiple entropy sources is both to provide
+redundancy as well as making it harder for an attacker to affect the
+entropy collection by forcing the attacker to try and affect different
+physical processes simultaneously.</p>
+
+<p>A given entropy generator is responsible for collecting the entropy
+(possibly including A/D conversion.). The entropy generator MUST
+implement some on-line testing of the physical entropy source based on
+the entropy collected. The tests shall be described in detail here but
+will at least include tests for:</p>
+
+<ul>
+<li>No long run lengths in generated values.</li>
+<li>Variance that exceeds a given threshhold.</li>
+<li>Mean value that don't deviate from expected mean.</li>
+<li>Frequency for all possible values are within expected variance.</li>
+</ul>
+
+<p>If the tests fails over a period of generated values the entropy source
+MUST raise an error flag. And MAY also block access to the entropy it
+otherwise provides.</p>
+
+<p>There shall also be possible to read out the raw entropy collected from
+a given entropy generator. This MUST ONLY be possible in a specific
+debug mode when no random generation is allowed. Also the entropy
+provided in debug mode MUST NOT be used for later random number
+generation. </p>
+
+<p>The entropy generator SHALL perform whitening on the collected entropy
+before providing it as 32-bit values to the entropy accumulator.</p>
+
+<h3>Entropy mixing</h3>
+
+<p>The entropy mixer subsystems reads 32-bit words from the entropy
+generators to build a block of bits to be mixed.</p>
+
+<p>When 1024 bits of mixed entropy has been collected the entropy is used
+as a message block which is fed into a hash function.</p>
+
+<p>The hash function used is SHA-512 (NIST FIPS 180-4).</p>
+
+<p>The digest is then extracted and provided to the random generation as as
+a seed.</p>
+
+<h3>Random generation</h3>
+
+<p>The random generation consists of a cryptographically secure pseudo random
+number generator (CSPRNG). The CSPRNG used in the trng is the stream
+cipher ChaCha.</p>
+
+<p>ChaCha is seeded with:</p>
+
+<ul>
+<li>512 bits block</li>
+<li>256 bits key</li>
+<li>64 bits IV</li>
+<li>64 bits counter</li>
+</ul>
+
+<p>In total the seed used is: 896 bits. This requires getting two seed
+blocks of 512 bits from the mixer.</p>
+
+<p>The number of rounds used in ChaCha is conservatively
+selected. We propose that the number of rounds shall be at least 24
+rounds. Possibly 32 rounds. Given the performance in HW for ChaCha and
+the size of the keystream block, the TRNG should be able to generate
+plentiful of random values even with 32 rounds.</p>
+
+<p>The random generator shall support the ability to test its functionality
+by seeding it with a user supplied value and then generate a number of
+values in a specific debug mode. The normal access to generated random
+values MUST NOT be allowed during the debug mode. The random generator
+MUST also set an error flag during debug mode. Finally, when exiting the
+debug mode, reseeding MUST be done.</p>
+
+<p>Finally the random generator provides random numbers as 32-bit
+values. the 512 bit keystream blocks from ChaCha are divided into 16
+32-bit words and provided in sequence.</p>
+
+<h2>Implementation details</h2>
+
+<p>The core supports multpiple entropy sources as well as a CSPRNG. For
+each entropy source there are some estimators that checks that the
+sources are not broken.</p>
+
+<p>There are also an ability to extract raw entropy as well as inject test
+data into the CSPRNG to verify the functionality.</p>
+
+<p>The core will include one FPGA based entropy source but expects the
+other entropy source(s) to be connected on external ports. It is up to
+the user/system implementer to provide physical entropy souces. We will
+suggest and provide info on how to design at least one such source.</p>
+
+<p>For simulation there are simplistic fake entropy sources that can be
+found in the tb/fake_modules directory. This modules SHOULD NOT be used
+as real sources.</p>
+
+<p>For synthesis there are wrappers for the real entropy source cores to
+adapt their interfaces to what we need in the trng. These wrappers
+should not be included during simulation.</p>
+
+<h2>API</h2>
+
+<p>Normal operation:
+* Extract 32-bit random words.</p>
+
+<p>Config parameters:</p>
+
+<ul>
+<li>Number of blocks in warm-up.</li>
+<li>Number of keystream blocks before reseeding.</li>
+</ul>
+
+<p>Debug access</p>
+
+<ul>
+<li>Enable/disable entropy generator X</li>
+<li>Check health of entropy generator X</li>
+<li>Read raw entropy from entropy generator X as 32-bit word.</li>
+<li>Write 256 bit seed value as 8 32-bit words</li>
+<li>Read out one or more 512 bit keystream blocks as 32-bit words.</li>
+</ul>
+
+<h2>Status</h2>
+
+<p><strong>* (2014-09-11) *</strong></p>
+
+<p>The first version of the CSPRNG is debugged and completed. This version
+supports automatic reseeding and an output fifo.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/rng/trng)]]
+
+| Clone `https://git.cryptech.is/core/rng/trng.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Fvndecorrelator.md b/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Fvndecorrelator.md
new file mode 100644
index 0000000..cf845ab
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Frng%2Fvndecorrelator.md
@@ -0,0 +1,35 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>vndecorrelator</h1>
+
+<p>A Verilog implementation of a von Neumann decorrelator.</p>
+
+<p>This tiny module consumes pairs of bits and generates decorrelated
+bits. Basically given a sequence of two bits, the decorrelator will:</p>
+
+<p>0, 1: Emit 1
+1, 0: Emit 0
+0, 0: Emit nothing
+1, 1: Emit nothing</p>
+
+<p>The rate of bits emitted is thus at most half of the bitrate on the
+input.</p>
+
+<p>The module is synchronous, but bits may arrive a number of cycles
+between eachother. The module will set the syn_out flag during one cycle
+to signal that the value in data_out is a valid bit.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/rng/vndecorrelator)]]
+
+| Clone `https://git.cryptech.is/core/rng/vndecorrelator.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Frng.md b/raw-wiki-dump/GitRepositories%2Fcore%2Frng.md
new file mode 100644
index 0000000..a76052c
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Frng.md
@@ -0,0 +1,20 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/rng/avalanche_entropy| core/rng/avalanche_entropy]] |`https://git.cryptech.is/core/rng/avalanche_entropy.git` | [[wiki:GitRepositories/core/rng/avalanche_entropy| README]] |
+|[[source:/core/rng/rosc_entropy| core/rng/rosc_entropy]] |`https://git.cryptech.is/core/rng/rosc_entropy.git` | [[wiki:GitRepositories/core/rng/rosc_entropy| README]] |
+|[[source:/core/rng/trng| core/rng/trng]] |`https://git.cryptech.is/core/rng/trng.git` | [[wiki:GitRepositories/core/rng/trng| README]] |
+|[[source:/core/rng/vndecorrelator| core/rng/vndecorrelator]] |`https://git.cryptech.is/core/rng/vndecorrelator.git` | [[wiki:GitRepositories/core/rng/vndecorrelator| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Futil%2Fkeywrap.md b/raw-wiki-dump/GitRepositories%2Fcore%2Futil%2Fkeywrap.md
new file mode 100644
index 0000000..30ae62e
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Futil%2Fkeywrap.md
@@ -0,0 +1,82 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>keywrap</h1>
+
+<h2>Introduction</h2>
+
+<p>This core implememts AES KEY WRAP as defined in <a href="https://tools.ietf.org/html/rfc3394">RFC
+3394</a> and the keywrap with padding
+according to <a href="https://tools.ietf.org/html/rfc5649">RFC 5694</a></p>
+
+<p>The core supports wrap/unwrap of objects up to 64 kByte in size.
+The core supports 128 and 256 bit wrapping keys.</p>
+
+<h2>Status</h2>
+
+<p>First complete version developed. The core does work.</p>
+
+<p>The core has been simulated with two different simulators and
+linted. The core has been used on the Cryptech Alpha and verified to
+work.</p>
+
+<h2>API</h2>
+
+<p>Objects to be processed are written in word order (MSB words). The
+caller writes the calculated magic value to the A regsisters in word
+order. The caller also needs to write the number of blocks (excluding
+magic block) into the RLEN register. Finally the caller needs to write
+the wrapping key.</p>
+
+<p>Due to address space limitations in the Cryptech cores (with 8-bit
+address space) the object storage is divided into banks [0 .. 127]. Each
+bank supports 128 32-bit words or 4096 bits. For objects lager than 4096
+bits, it is the callers responsibilty to switch banks when reading and
+writing to the storage.</p>
+
+<h2>Implementation details</h2>
+
+<h3>Key Wrap</h3>
+
+<p>The core implements the wrap block processing part of the AES Key Wrap
+as specified in chapter 2.1.1 of RFC 3394:</p>
+
+<p>For j = 0 to 5
+           For i=1 to n
+               B = AES(K, A | R[i])
+               A = MSB(64, B) ^ t where t = (n*j)+i
+               R[i] = LSB(64, B)</p>
+
+<p>The core does not perform the calculation of the magic value, which is
+the initial value of A. The core also does not perform padding om the
+message to an even 8 byte block.</p>
+
+<p>This means that SW needs to generate the 64-bit initial value of A and
+perform padding as meeded.</p>
+
+<p>(Similarly, the core implements the unwrap processng as specifie in
+chapter 2.2.2 of RFC 3394.)</p>
+
+<h2>Implementation results</h2>
+
+<p>The core has been implemented for Xilinx Artix7-t200 using ISE with the
+following results:</p>
+
+<p>Regs:    2906 (1%)
+Slices:  1991 (5%)
+RamB36E: 32 (8%)
+Clock:   100+ MH</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/util/keywrap)]]
+
+| Clone `https://git.cryptech.is/core/util/keywrap.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Futil%2Fmkmif.md b/raw-wiki-dump/GitRepositories%2Fcore%2Futil%2Fmkmif.md
new file mode 100644
index 0000000..f5b4e25
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Futil%2Fmkmif.md
@@ -0,0 +1,132 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Master Key Memory Interface</h1>
+
+<p>This core provides a 32-bit interface to a master key memory (MKM)
+implemented using an external volatile memory. The memory targeted is
+<a href="https://www.microchip.com/wwwproducts/en/23K640">Microchip 23K640</a>, a
+serial SRAM with a SPI interface.</p>
+
+<h2>Purpose and Functionality</h2>
+
+<p>The Master Key Memory is where a cryptographic master key is stored. The
+key is used (for example) to cryptographically wrap other keys and
+secrets. By wiping the MKM and thus the master key, the wrapped secrets
+are protected against leakage to a local attacker that physically breaks
+an active tamper detect shield.</p>
+
+<p>The core will in future versions provide functionality to autonomously
+protect against memory remanence effects by rotating bits in stored data,
+and moving data to different addresses in the external memory. The core
+will also be able to autonomously zeroise the memory when given an alarm
+signal.</p>
+
+<p>The current version however simply provides an interface to the slower,
+serial memory including initializing the memory in the correct mode. The
+core supports three commands: read word, write word, and initialize
+memory.</p>
+
+<h2>Limitations</h2>
+
+<p>The SPI clock is generated by the core clock (clk) divided by the
+SPI clock divisor * 2 (the divisor is the half period in cycles). The
+default divisor is set to generate an SPI clock of less than 1 MHz when
+the core clock is 50 MHz. For other speeds and other
+core frequencies, the divisor will have to be adjusted.</p>
+
+<p>The core will only read and write complete 32-bit words.</p>
+
+<p>Commands given while the core is performing a read, write or
+initialization operation will silently be ignored.</p>
+
+<h2>Implementation</h2>
+
+<p>The implementation is divided into three parts:</p>
+
+<ul>
+<li><p>A SPI interface able to transmit a given number of bits at a given SPI
+clock rate. Data received are simultaneously collected and provided as
+read data. The SPI interface also generates the SPI clock and chip
+enable.</p></li>
+<li><p>A Microchip-specific command handler that sends the read, write, and
+init commands to the memory using the SPI interface.</p></li>
+<li><p>An API interface that provides the ability to configure the SPI clock
+speed, set the address to read or write, and data access.</p></li>
+</ul>
+
+<p>The current implementation will initiate the Microchip memory directly
+after reset and set the memory in sequential mode. This means that it
+would actually be possible to write a stream of data to the memory, but
+since the API only handles a single 32-bit word, the mode is only used
+to remove the need to update the address between bytes.</p>
+
+<h3>Implementation Results</h3>
+
+<p><strong>Altera Cyclone IV E</strong></p>
+
+<ul>
+<li>Registers: 212</li>
+<li>Logic Elements: 289</li>
+<li>Fmax: 250 MHz</li>
+</ul>
+
+<p><strong>Altera Cyclone V</strong></p>
+
+<ul>
+<li>Registers: 221</li>
+<li>ALMs: 113</li>
+<li>Fmax: 194 MHz</li>
+</ul>
+
+<p><strong>Xilinx Spartan 6</strong></p>
+
+<ul>
+<li>Slice Registers: 206</li>
+<li>Slice LUTs: 185</li>
+<li>Fmax: 200 MHz</li>
+</ul>
+
+<p><strong>Xilinx Artix 7</strong></p>
+
+<ul>
+<li>Slice Registers: 205</li>
+<li>Slice LUTs: 176</li>
+<li>Fmax: 383 MHz</li>
+</ul>
+
+<h2>Status</h2>
+
+<p><strong>(2016-05-10)</strong></p>
+
+<p>The core has now been verified in a Xilinx Spartan-6 FPGA and the target
+Microchip memory connected to the FPGA memory. Read and write access has
+successfully been performed with SPI clock speeds from 300 Hz to 10 MHz.</p>
+
+<p><strong>(2016-05-02)</strong></p>
+
+<p>Functional development completed. Simulation based debugging
+completed. Built design for both Altera and Xilinx FPGAs.</p>
+
+<p><strong>(2016-04-25)</strong></p>
+
+<p>Refactored core into top_-, core- and spi-modules. Made the design much
+simpler. First implementation almost completed.</p>
+
+<p><strong>(2016-04-21)</strong></p>
+
+<p>Core implementation started.</p>
+```
+
+[[RepositoryIndex(format=table,glob=core/util/mkmif)]]
+
+| Clone `https://git.cryptech.is/core/util/mkmif.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fcore%2Futil.md b/raw-wiki-dump/GitRepositories%2Fcore%2Futil.md
new file mode 100644
index 0000000..20ba171
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore%2Futil.md
@@ -0,0 +1,18 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/util/keywrap| core/util/keywrap]] |`https://git.cryptech.is/core/util/keywrap.git` | [[wiki:GitRepositories/core/util/keywrap| README]] |
+|[[source:/core/util/mkmif| core/util/mkmif]] |`https://git.cryptech.is/core/util/mkmif.git` | [[wiki:GitRepositories/core/util/mkmif| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fcore.md b/raw-wiki-dump/GitRepositories%2Fcore.md
new file mode 100644
index 0000000..ea57077
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fcore.md
@@ -0,0 +1,50 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/cipher/aes_speed| core/cipher/aes_speed]] |`https://git.cryptech.is/core/cipher/aes_speed.git` | [[wiki:GitRepositories/core/cipher/aes_speed| README]] |
+|[[source:/core/cipher/aes| core/cipher/aes]] |`https://git.cryptech.is/core/cipher/aes.git` | [[wiki:GitRepositories/core/cipher/aes| README]] |
+|[[source:/core/cipher/chacha| core/cipher/chacha]] |`https://git.cryptech.is/core/cipher/chacha.git` | [[wiki:GitRepositories/core/cipher/chacha| README]] |
+|[[source:/core/comm/coretest| core/comm/coretest]] |`https://git.cryptech.is/core/comm/coretest.git` | [[wiki:GitRepositories/core/comm/coretest| README]] |
+|[[source:/core/comm/eim| core/comm/eim]] |`https://git.cryptech.is/core/comm/eim.git` | [[wiki:GitRepositories/core/comm/eim| README]] |
+|[[source:/core/comm/fmc| core/comm/fmc]] |`https://git.cryptech.is/core/comm/fmc.git` | [[wiki:GitRepositories/core/comm/fmc| README]] |
+|[[source:/core/comm/i2c| core/comm/i2c]] |`https://git.cryptech.is/core/comm/i2c.git` | [[wiki:GitRepositories/core/comm/i2c| README]] |
+|[[source:/core/comm/uart| core/comm/uart]] |`https://git.cryptech.is/core/comm/uart.git` | [[wiki:GitRepositories/core/comm/uart| README]] |
+|[[source:/core/hash/sha1| core/hash/sha1]] |`https://git.cryptech.is/core/hash/sha1.git` | [[wiki:GitRepositories/core/hash/sha1| README]] |
+|[[source:/core/hash/sha256| core/hash/sha256]] |`https://git.cryptech.is/core/hash/sha256.git` | [[wiki:GitRepositories/core/hash/sha256| README]] |
+|[[source:/core/hash/sha3| core/hash/sha3]] |`https://git.cryptech.is/core/hash/sha3.git` | [[wiki:GitRepositories/core/hash/sha3| README]] |
+|[[source:/core/hash/sha512| core/hash/sha512]] |`https://git.cryptech.is/core/hash/sha512.git` | [[wiki:GitRepositories/core/hash/sha512| README]] |
+|[[source:/core/lib| core/lib]] |`https://git.cryptech.is/core/lib.git` | [[wiki:GitRepositories/core/lib| README]] |
+|[[source:/core/math/curve25519lib| core/math/curve25519lib]] |`https://git.cryptech.is/core/math/curve25519lib.git` | |
+|[[source:/core/math/ecdsalib| core/math/ecdsalib]] |`https://git.cryptech.is/core/math/ecdsalib.git` | [[wiki:GitRepositories/core/math/ecdsalib| README]] |
+|[[source:/core/math/modexpa7| core/math/modexpa7]] |`https://git.cryptech.is/core/math/modexpa7.git` | [[wiki:GitRepositories/core/math/modexpa7| README]] |
+|[[source:/core/math/modexpng| core/math/modexpng]] |`https://git.cryptech.is/core/math/modexpng.git` | [[wiki:GitRepositories/core/math/modexpng| README]] |
+|[[source:/core/math/modexps6| core/math/modexps6]] |`https://git.cryptech.is/core/math/modexps6.git` | |
+|[[source:/core/math/modexp| core/math/modexp]] |`https://git.cryptech.is/core/math/modexp.git` | [[wiki:GitRepositories/core/math/modexp| README]] |
+|[[source:/core/pkey/ecdhp256| core/pkey/ecdhp256]] |`https://git.cryptech.is/core/pkey/ecdhp256.git` | [[wiki:GitRepositories/core/pkey/ecdhp256| README]] |
+|[[source:/core/pkey/ecdhp384| core/pkey/ecdhp384]] |`https://git.cryptech.is/core/pkey/ecdhp384.git` | [[wiki:GitRepositories/core/pkey/ecdhp384| README]] |
+|[[source:/core/pkey/ecdsa256| core/pkey/ecdsa256]] |`https://git.cryptech.is/core/pkey/ecdsa256.git` | [[wiki:GitRepositories/core/pkey/ecdsa256| README]] |
+|[[source:/core/pkey/ecdsa384| core/pkey/ecdsa384]] |`https://git.cryptech.is/core/pkey/ecdsa384.git` | [[wiki:GitRepositories/core/pkey/ecdsa384| README]] |
+|[[source:/core/pkey/ed25519| core/pkey/ed25519]] |`https://git.cryptech.is/core/pkey/ed25519.git` | |
+|[[source:/core/platform/alpha| core/platform/alpha]] |`https://git.cryptech.is/core/platform/alpha.git` | [[wiki:GitRepositories/core/platform/alpha| README]] |
+|[[source:/core/platform/common| core/platform/common]] |`https://git.cryptech.is/core/platform/common.git` | [[wiki:GitRepositories/core/platform/common| README]] |
+|[[source:/core/platform/novena| core/platform/novena]] |`https://git.cryptech.is/core/platform/novena.git` | [[wiki:GitRepositories/core/platform/novena| README]] |
+|[[source:/core/platform/terasic_c5g| core/platform/terasic_c5g]] |`https://git.cryptech.is/core/platform/terasic_c5g.git` | [[wiki:GitRepositories/core/platform/terasic_c5g| README]] |
+|[[source:/core/rng/avalanche_entropy| core/rng/avalanche_entropy]] |`https://git.cryptech.is/core/rng/avalanche_entropy.git` | [[wiki:GitRepositories/core/rng/avalanche_entropy| README]] |
+|[[source:/core/rng/rosc_entropy| core/rng/rosc_entropy]] |`https://git.cryptech.is/core/rng/rosc_entropy.git` | [[wiki:GitRepositories/core/rng/rosc_entropy| README]] |
+|[[source:/core/rng/trng| core/rng/trng]] |`https://git.cryptech.is/core/rng/trng.git` | [[wiki:GitRepositories/core/rng/trng| README]] |
+|[[source:/core/rng/vndecorrelator| core/rng/vndecorrelator]] |`https://git.cryptech.is/core/rng/vndecorrelator.git` | [[wiki:GitRepositories/core/rng/vndecorrelator| README]] |
+|[[source:/core/util/keywrap| core/util/keywrap]] |`https://git.cryptech.is/core/util/keywrap.git` | [[wiki:GitRepositories/core/util/keywrap| README]] |
+|[[source:/core/util/mkmif| core/util/mkmif]] |`https://git.cryptech.is/core/util/mkmif.git` | [[wiki:GitRepositories/core/util/mkmif| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fdoc%2Fdesign.md b/raw-wiki-dump/GitRepositories%2Fdoc%2Fdesign.md
new file mode 100644
index 0000000..e68da7f
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fdoc%2Fdesign.md
@@ -0,0 +1,62 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>design documentation</h1>
+
+<p>This repo contains a number of documents used during development of
+various parts the Cryptech design. Note that the directory contains
+source files (for example in OmniGraffle, Open Document file formats) as
+well as final documents (normally in PFF file format).</p>
+
+<ul>
+<li><p>Alpha_board_drawing
+A drawing/diagram that shows the functional components and their
+functional connectivities for the Cryptech Alpha board being
+developed. The drawing is not formal schematics for the Alpha board.</p></li>
+<li><p>Novena-entropy-board
+Sub directory with schematics as well as layout with silk screen for
+the Cryptech Noise board designed to be used as external entropy
+source on the Novena.</p></li>
+<li><p>alpha_board_config
+Configuration file for setting up the I/Os and functionality of the
+STM32 microcontroller on the Alpha board. The config file is used by
+the tool [STM32CubeMX][http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF259242?sc=microxplorer] from ST Microelectronics.</p></li>
+<li><p>application-aware-signing
+A drawing that shows a proposed mechanism with data and command flows
+for doing application based (application aware) signing.</p></li>
+<li><p>fpga_estimates
+A document that tracks the FPGA resources and performance of the
+different Cryptech cores in different FPGA technologies. The document
+also includes estimates for cores not yet designed or completed. The
+purpose of the document is to provide estimates of FPGA devices needed
+to implement different use cases.</p></li>
+<li><p>hsm-board
+A high level functional diagram of the Cryptech HSM board that shows
+the major functional blocks. Used during development of the Alpha
+board to see what components are needed to realise the functionality
+of the blocks. The Alpha_board_drawing is the concrete functional
+realisation of this diagram.</p></li>
+<li><p>hsm-keys
+A document that includes diagrams that shows proposed mechanisms for
+handling keys including managament, protection and migration of
+wrapped keys.</p></li>
+<li><p>novena-memory-map
+This document contains information about the memory map of the
+Cryptech FPGA design with the specific memory maps of each core as
+well as how the cores are addressed and accessed from SW via different
+interfaces.</p></li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=doc/design)]]
+
+| Clone `https://git.cryptech.is/doc/design.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fdoc%2Fpresentations.md b/raw-wiki-dump/GitRepositories%2Fdoc%2Fpresentations.md
new file mode 100644
index 0000000..7886ffd
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fdoc%2Fpresentations.md
@@ -0,0 +1,29 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Presentations</h1>
+
+<p>This repo contains presentations about the Cryptech project and the
+Cryptech HSM design.</p>
+
+<ul>
+<li><p>Cryptech_HW_status_2014-03-10.pdf
+A short presentation about the status of the Cryptech HW as of March 2014.</p></li>
+<li><p>Cryptech_TRNG_Ideas_2014-03-17
+A presentation that shows goals and design ideas for the True Random
+Number Generator (TRNG) to be implemented for Cryptech.</p></li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=doc/presentations)]]
+
+| Clone `https://git.cryptech.is/doc/presentations.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fdoc.md b/raw-wiki-dump/GitRepositories%2Fdoc.md
new file mode 100644
index 0000000..2261469
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fdoc.md
@@ -0,0 +1,18 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/doc/design| doc/design]] |`https://git.cryptech.is/doc/design.git` | [[wiki:GitRepositories/doc/design| README]] |
+|[[source:/doc/presentations| doc/presentations]] |`https://git.cryptech.is/doc/presentations.git` | [[wiki:GitRepositories/doc/presentations| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fhardware.md b/raw-wiki-dump/GitRepositories%2Fhardware.md
new file mode 100644
index 0000000..4fcafa8
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fhardware.md
@@ -0,0 +1,51 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>STM32 firmware for Cryptech Alpha board</h1>
+
+<p>The Alpha board is our first full prototype for an open-source hardware
+security module (HSM). It is a custom board with an STM32 Cortex-M4
+microcontroller and an Artix-7 FPGA, flash-based keystore, separate memory
+for the Key Encryption Key, etc. See the wiki for design documents.</p>
+
+<h1>Copyrights</h1>
+
+<p>The license for all work done on this in the CrypTech project is a
+3-clause BSD license.</p>
+
+<p>The "Noise generator" and "Amplifier" parts of the circuit diagram are
+copied from Benedikt Stockebrand's ARRGH project. </p>
+
+<p>Both copyright statements are included in LICENSE.txt.</p>
+
+<h1>Board Revisions</h1>
+
+<ol>
+<li><p><code>rev01</code> was the "dev-bridge" board, a daughterboard for the Novena,
+which talked to the Novena's FPGA through the high-speed expansion
+connector.</p></li>
+<li><p><code>rev02</code> is the Alpha board, our first full prototype for an open-source
+hardware security module (HSM). It is a custom board with an STM32
+Cortex-M4 microcontroller and an Artix-7 FPGA, flash-based keystore,
+separate memory for the Key Encryption Key, etc.</p>
+
+<p>The board's form factor (4 x 4 in, 101.6 x 101.6 mm) was based on the
+Intel NUC mini-PC, but there were some issues sourcing enough cases, so
+only a few of these boards were made.</p></li>
+<li><p><code>rev03</code> is functionally the same as <code>rev02</code>, but in a Eurocard form
+factor (100 x 120 mm, aka "3Ux120").</p></li>
+</ol>
+```
+
+[[RepositoryIndex(format=table,glob=hardware)]]
+
+| Clone `https://git.cryptech.is/hardware.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Freleng%2Falpha.md b/raw-wiki-dump/GitRepositories%2Freleng%2Falpha.md
new file mode 100644
index 0000000..39c72df
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Freleng%2Falpha.md
@@ -0,0 +1,140 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>releng/alpha</h1>
+
+<p>Release engineering stuff for Cryptech Alpha board and support software.</p>
+
+<h2>Overview</h2>
+
+<p>The Makefiles and scripts in this repository attempt to automate the
+process of building packaged versions of the firmware and software for
+the Cryptech Alpha board.  At a high level, this consists of two main
+phases:</p>
+
+<ol>
+<li><p>Building a firmware package (Verilog and C code which runs on the
+Alpha board itself, regardless the host system to which the Alpha
+is connected); and</p></li>
+<li><p>Building software packages (code which runs on the host to which
+the Alpha is connected).</p></li>
+</ol>
+
+<p>Since the firmware is the same for any given version of the Cryptech
+source code, and since the process of building the firmware binaries
+is both time-consuming and involves tools like the XiLinx Verilog
+synthesis toolkit and cross-compilers for multiple CPUs (the Alpha's
+Cortex M4 ARM CPU and the Atmel AVR ATtiny828 MCU used to implement
+the anti-tampering logic for the master key memory), we include a
+signed tarball containing pre-built binaries for all the firmware as
+part of the source tarball for the software packages.</p>
+
+<p>You are of course free to build all of this for yourself, with or
+without modification, the pre-built versions are just a convenience.</p>
+
+<h2>Source Tree</h2>
+
+<p>The source code itself, for both the firmware and the software, is in
+the source/ directory, with names corresponding to the canonical names
+of the relevant git repositories.  At the time this document was
+written, a few of the repositories in question had not yet been
+promoted to their expected permanent homes in the core/ or sw/ trees,
+but we expect this to be temporary.  Regardless, directory names
+within the source/ directory tree are intended to track the canonical
+names of the git repositories, whatever they may be at any given time.</p>
+
+<h2>Firmware Build Process</h2>
+
+<p>The firmware build process consists of five main phases:</p>
+
+<ol>
+<li><p>Building a "shadow" directory tree populated with symlinks back to
+the source tree.  This allows us to preserve binaries between
+compilation runs where appropriate, without cluttering up the
+source tree with various intermediate files which don't belong
+there.  In particular, this allows to skip the Verilog synthesis
+stage when nothing there has changed, which makes the overall
+build process run significantly faster.</p></li>
+<li><p>Synthesizing the Verilog source code into a bitstream.  This phase
+generates a single bitstream file, suitable for loading into the
+Alpha's FPGA chip.</p></li>
+<li><p>Cross-compiling C code for the Alpha's ARM processor.  This
+produces two images: the bootloader, and the HSM firmware itself.</p></li>
+<li><p>Cross compiling C code for the Alpha's AVR MCU.  This produces a
+single image, which runs the tamper-response controller.</p></li>
+<li><p>Packaging all of the firmware created in the above steps into a
+tarball, with some meta-data describing the package, including
+SHA-2 digests of all of the firmware image files and a signature
+over the entire meta-data block.</p></li>
+</ol>
+
+<p>The precise formats which show up in the firmware tarball are subject
+to change.  At the moment, they consist of:</p>
+
+<ul>
+<li><p>A raw bitstream (".bit" file) for the Xilinx Artix-7 FPGA.</p></li>
+<li><p>ELF and raw binary image files for the Cortex M4 ARM CPU; we supply
+both .elf and .bin files because some tools want one format, some
+want the other.</p></li>
+<li><p>A ".hex" image for the AVR MCU.</p></li>
+</ul>
+
+<p>The overall packaging for the firmware tarball is intentionally pretty
+boring: tar, gzip, gpg, and JSON.  The intent is that users be able to
+use our firmware tarball even if the scripts we provide are unsuitable
+for some reason.</p>
+
+<p>The final result of the firmware build process is the firmware
+tarball, which is written into the source/ tree for inclusion by the
+software packaging phase.</p>
+
+<h2>Software Build Process</h2>
+
+<p>The software build process also consists of several phases, but is a
+bit more open-ended than the firmware build process.  Phases in the
+current build process:</p>
+
+<ol>
+<li><p>Building a source tarball and Debian source package (".dsc").
+The Debian and Ubuntu Linux distributions are our primary
+development platforms, so we need to produce packages for them in
+any case, and the process of producing a Debian-family source
+package produces a source tarball as one of its outputs, so we get
+that for free by doing this step first.</p></li>
+<li><p>Running <a href="https://pbuilder.alioth.debian.org/">pbuilder</a> to generate clean binary packages for the
+"i386" and "amd64" architectures for Debian Jessie and Ubuntu
+Xenial.</p></li>
+<li><p>Loading all of the Debian and Ubuntu packages produced above into
+the staging instances of a set of APT repositories.</p></li>
+<li><p>Generation of a <a href="http://brew.sh/">Homebrew</a> formula and committing that formula to
+the staging instance of a Homebrew "tap" (git repository), using the
+tarball created during the Debian source package stage as the
+source package.  The Homebrew formula is source-only (no "bottled"
+binary packages): creating binary packages would not be
+particularly difficult (one <a href="https://github.com/tpoechtrager/osxcross">osxcross</a> instance per version of
+OSX we want to support would do it), but Apple's Xcode SDK license
+doesn't permit this unless we run our build farm on Apple
+hardware.</p></li>
+<li><p>Uploading changes from the staging repositories to our public
+repositories.</p></li>
+</ol>
+
+<p>In theory, it would also be possible to produce Windows binaries using
+the <a href="http://www.mingw.org/">MinGW</a> cross-compilation environment, but Windows is sufficiently
+different from all other platforms that even minimal Windows support
+would almost certainly require extensive source code changes, so we
+have not put any serious thought into build issues for Windows.</p>
+```
+
+[[RepositoryIndex(format=table,glob=releng/alpha)]]
+
+| Clone `https://git.cryptech.is/releng/alpha.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Freleng%2Fnovena.md b/raw-wiki-dump/GitRepositories%2Freleng%2Fnovena.md
new file mode 100644
index 0000000..4c0da8b
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Freleng%2Fnovena.md
@@ -0,0 +1,56 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>relenv/novena</h1>
+
+<p><strong>WARNING:</strong> Code for the Novena is no longer our primary development
+focus, so while there's no particular reason why recent versions of
+the base code should not work on the Novena, this has not been tested.
+Don't expect frequent updates to this repository.</p>
+
+<p>Release engineering tree for the Cryptech code for the Novena PVT-1,
+initially targetted at what we need to package for IETF 93 in Praha.</p>
+
+<p>General idea is to build two binary packages, one with the bitstream
+for the FPGA, one for software cross-compiled for the Novena.  As a
+convenience, there's also a meta-package which just pulls in the first
+two as dependencies.</p>
+
+<p>The current build setup is somewhat specific to the Novena (in
+particular, the use of the Debian package system), but the general
+outline will likely be reusable for other platforms in the future.</p>
+
+<p>Overall structure of the current setup:</p>
+
+<ul>
+<li><p>The top-level Makefile controls the overall build process.  It does
+_not_ run make directly on any of its subdirectories, instead it
+invokes the Debian package building tools with the right settings.</p></li>
+<li><p>Each of the three packages generated has its own Makefile and
+debian/ directory.  These Makefiles are intended to work with the
+Debian package building tools, and do not necessarily do anything
+useful if used in any other context.</p></li>
+<li><p>Building the software package requires a cross-compiler, see
+<a href="https://wiki.debian.org/CrossToolchains">the Debian cross compilation tools page</a>.</p></li>
+<li><p>Building the firmware package requires
+<a href="http://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html">the XiLinx tools</a>.</p></li>
+<li><p>You'll also need the usual Debian package building tools, as well as
+Python and the python-yaml library.</p></li>
+<li><p>The software and Verilog repositories are spliced into this one
+using git's submodule mechanism.  The top-level Makefile attempts to
+automate all of the submodule voodoo needed for normal builds.</p></li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=releng/novena)]]
+
+| Clone `https://git.cryptech.is/releng/novena.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Freleng.md b/raw-wiki-dump/GitRepositories%2Freleng.md
new file mode 100644
index 0000000..cf79f02
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Freleng.md
@@ -0,0 +1,18 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/releng/alpha| releng/alpha]] |`https://git.cryptech.is/releng/alpha.git` | [[wiki:GitRepositories/releng/alpha| README]] |
+|[[source:/releng/novena| releng/novena]] |`https://git.cryptech.is/releng/novena.git` | [[wiki:GitRepositories/releng/novena| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Fcryptlib.md b/raw-wiki-dump/GitRepositories%2Fsw%2Fcryptlib.md
new file mode 100644
index 0000000..398a53e
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw%2Fcryptlib.md
@@ -0,0 +1,97 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>cryptlib</h1>
+
+<h2>Introduction</h2>
+
+<p>This is a port of Peter Gutmann's
+<a href="https://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib package</a>
+to the Cryptech project's environment.  This is a work in progress,
+and still at a very early stage as of this writing.</p>
+
+<p>The main addition to the stock cryptlib environment is a set of
+Hardware Adaption Layer (HAL) implementations that use the Cryptech
+FPGA cores.</p>
+
+<p>While we expect to be making more significant use of cryptlib in the
+future, the main purposes of this code at the moment are
+proof-of-concept and connecting the Cryptech cores to a more complete
+cryptographic programming environment for testing and development
+purposes.</p>
+
+<h2>Current status</h2>
+
+<p>At present, the Cryptech HAL code runs only on the Novena PVT1.  There
+are three variants of the HAL, all using the I2C bus, but speaking
+different protocols:</p>
+
+<ul>
+<li><p>An implementation using the <code>coretest</code> byte-stream protocol
+implemented by the <code>core/novena</code> FPGA build.</p></li>
+<li><p>An implementation using the simpler interface implemented by the
+<code>core/novena_i2c_simple</code> environment.</p></li>
+<li><p>An implementation using the <code>coretest</code> byt-stream protocol as
+implemented by the <code>test/novena_trng</code> FPGA build.  This differs from
+the others in that it supports the Cryptech TRNG.  Note that neither
+this HAL nor this FPGA build supports any cryptographic algorithms.</p></li>
+</ul>
+
+<p>All of these HAL implementations are in the <code>src/</code> directory.  See the
+<code>GNUmakefile</code> for details on how to select the variant you want.</p>
+
+<p>At present, the only relevant Cryptech cores are the TRNG and several
+digest algorithms.   The current HAL uses the SHA-1, SHA-256, and
+SHA-512 cores to implement the SHA-1, SHA-256, SHA-384, and SHA-512
+digests.  SHA-512/224 and SHA-512/256 are not supported.</p>
+
+<p>In principal there is no reason why one could not write a HAL which
+spoke to a Terasic board, perhaps via the <code>coretest</code> protocol over a
+UART, but to date this has not been done.</p>
+
+<h2>Code import status</h2>
+
+<p>Cryptlib itself is present in the repository in the form of a verbatim
+copy of the Cryptlib 3.4.2 distribution zipfile, which the top-level
+makefile unpacks while building.  This has proven simpler to work with
+than importing the entire Cryptlib distribution into a vendor branch.</p>
+
+<p>Packaging Cryptlib this way has two implications:</p>
+
+<ul>
+<li><p>You may need to <code>apt-get install unzip</code> on your Novena.</p></li>
+<li><p>Any changes you might make to Cryptlib itself will be lost when you
+run <code>make clean</code>.</p></li>
+</ul>
+
+<h2>Test code</h2>
+
+<p>The <code>tests/</code> directory contains a few test scripts, written in Python,
+using the standard Cryptlib Python bindings.  The Cryptlib Python
+environment is a fairly literaly translation of the Cryptlib C
+environment, so portions of it will be a bit, um, surprising to Python
+programmers, but the basic functionality works.  Note that it's normal
+for test scripts to fail when the functionality they're testing isn't
+loaded on the FPGA.</p>
+
+<h2>Copyright status</h2>
+
+<p>Cryptlib itself is copyright by Peter Gutmann.  See the Cryptlib web
+site for licensing details.</p>
+
+<p>Code written for the Cryptech project is under the usual Cryptech
+BSD-style license.</p>
+```
+
+[[RepositoryIndex(format=table,glob=sw/cryptlib)]]
+
+| Clone `https://git.cryptech.is/sw/cryptlib.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Flibhal.md b/raw-wiki-dump/GitRepositories%2Fsw%2Flibhal.md
new file mode 100644
index 0000000..920b2c7
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw%2Flibhal.md
@@ -0,0 +1,299 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>libhal</h1>
+
+<h2>Overview</h2>
+
+<p>This library combines a set of low-level API functions which talk to
+the Cryptech FPGA cores with a set of higher-level functions providing
+various cryptographic services.</p>
+
+<p>There's some overlap between the low-level code here and the low-level
+code in core/platform/novena, which will need sorting out some day,
+but at the time this library forked that code, the
+core/platform/novena code was all written to support a test harness
+rather than a higher-level API.</p>
+
+<p>Current contents of the library:</p>
+
+<ul>
+<li><p>Low-level I/O code (FMC, EIM, and I2C).</p></li>
+<li><p>An implementation of AES Key Wrap using the Cryptech AES core.</p></li>
+<li><p>An interface to the Cryptech CSPRNG.</p></li>
+<li><p>An interface to the Cryptech hash cores, including HMAC.</p></li>
+<li><p>An implementation of PBKDF2.</p></li>
+<li><p>An implementation of RSA, optionally using the Cryptech ModExp core.</p></li>
+<li><p>An implementation of ECDSA, optionally using the Cryptech ECDSA base
+point multiplier cores.</p></li>
+<li><p>An implementation of HSS/LMS hash-based signatures.</p></li>
+<li><p>An interface to the Master Key Memory interface core on the Cryptech
+Alpha platform.</p></li>
+<li><p>A simple keystore implementation with drivers for RAM and flash
+storage on the Cryptech Alpha platform.</p></li>
+<li><p>A remote procedure call (RPC) interface.</p></li>
+<li><p>(Just enough) ASN.1 code to support a uniform interface to public
+(SubjectPublicKeyInformation (SPKI)) and private (PKCS #8) keys.</p></li>
+<li><p>A simple key backup mechanism, including a Python script to drive it
+from the client side.</p></li>
+<li><p>An RPC multiplexer to allow multiple clients (indepedent processes)
+to talk to the Cryptech Alpha at once.</p></li>
+<li><p>Client implenetations of the RPC mechanism in both C and Python.</p></li>
+<li><p>Test code for all of the above.</p></li>
+</ul>
+
+<p>Most of these are fairly well self-contained, although the PBKDF2
+implementation uses the hash-core-based HMAC implementation with
+fallback to a software implementation if the cores aren't available.</p>
+
+<p>The major exceptions are the RSA and ECDSA implementations, which uses
+an external bignum implementation (libtfm) to handle a lot of the
+arithmetic.  In the long run, much or all of this may end up being
+implemented in Verilog, but for the moment all of the RSA math except
+for modular exponentiation is happening in software, as is all of the
+math for ECDSA verification; ECDSA math for key generation and signing
+on the P-256 and P-384 curves is done in the ECDSA base point
+multiplier cores when those are available.</p>
+
+<h2>RSA</h2>
+
+<p>The RSA implementation includes a compile-time option to bypass the
+ModExp core and do everything in software, because the ModExp core is
+a tad slow at the moment (others are hard at work fixing this).</p>
+
+<p>The RSA implementation includes optional blinding (enabled by default).</p>
+
+<h2>ECDSA</h2>
+
+<p>The ECDSA implementation is specific to the NIST prime curves P-256,
+P-384, and P-521.</p>
+
+<p>The ECDSA implementation includes a compile-time option to allow test
+code to bypass the CSPRNG in order to test against known test vectors.
+Do <strong>NOT</strong> enable this in production builds, as ECDSA depends on good
+random numbers not just for private keys but for individual
+signatures, and an attacker who knows the random number used for a
+particular signature can use this to recover the private key.
+Arguably, this option should be removed from the code entirely.</p>
+
+<p>The ECDSA software implementation attempts to be constant-time, to
+reduce the risk of timing channel attacks.  The algorithms chosen for
+the point arithmetic are a tradeoff between speed and code complexity,
+and can probably be improved upon even in software; reimplementing at
+least the field arithmetic in hardware would probably also help.
+Signing and key generation performance is significantly better when
+the ECDSA base point multiplier cores are available.</p>
+
+<p>The point addition and point doubling algorithms in the current ECDSA
+software implementation come from the <a href="http://www.hyperelliptic.org/EFD/g1p/auto-shortw-jacobian-3.html">EFD</a>.  At least at the
+moment, we're only interested in ECDSA with the NIST prime curves, so
+we use algorithms optimized for a=-3.</p>
+
+<p>The point multiplication algorithm is a straightforward double-and-add
+loop, which is not the fastest possible algorithm, but is relatively
+easy to confirm by inspection as being constant-time within the limits
+imposed by the NIST curves.  Point multiplication could probably be
+made faster by using a non-adjacent form (NAF) representation for the
+scalar, but the author doesn't understand that well enough to
+implement it as a constant-time algorithm.  In theory, changing to a
+NAF representation could be done without any change to the public API.</p>
+
+<p>Points stored in keys and curve parameters are in affine format, but
+point arithmetic is performed in Jacobian projective coordinates, with
+the coordinates themselves in Montgomery form; final mapping back to
+affine coordinates also handles the final Montgomery reduction.</p>
+
+<h2>Hash-Based Signatures</h2>
+
+<p>A hashsig private key is a Merkle tree of one-time signing keys, which can
+be used to sign a finite number of messages. Since they don't rely on
+"hard math" for security, hashsig schemes are quantum-resistant.</p>
+
+<p>This hashsig code is a clean-room implementation of draft-mcgrew-hash-sigs.
+It has been shown to interoperate with the Cisco reference code (each can
+verify the other's signatures).</p>
+
+<p>Following the recommendations of the draft, we only store the topmost hash
+tree (the "root tree") in the token keystore; lower-level trees are stored
+in the volatile keystore, and are regenerated upon a system restart.</p>
+
+<p>This implementation has limitations on the number of keys, size of OTS
+keys, and size of signatures, because of the design of the keystore and of
+the RPC mechanism:</p>
+
+<ol>
+<li>The token keystore is a fairly small flash, partitioned into 2048
+8096-byte blocks. Therefore, we can't support LMS algorithm types &gt;
+lms_sha256_n32_h10 (a.k.a. h=10, or 1024 keys per tree). In this case,
+keygen will return HAL_ERROR_NO_KEY_INDEX_SLOTS.</li>
+</ol>
+
+<p>Additionally, the 8KB key storage size means that we can't support LM-OTS
+algorithm type lmots_sha256_n32_w1, which has an OTS key size of 8504
+bytes. In this case, keygen will return HAL_ERROR_UNSUPPORTED_KEY.</p>
+
+<ol>
+<li><p>The volatile keystore is currently limited to 1280 keys, so only 2
+levels at h=10, but more levels at h=5. One could easily increase the size
+of the volatile keystore, but L=2/h=10 gives us a key that can sign 1M
+messages, which is sufficient for development and testing purposes.</p></li>
+<li><p>The RPC mechanism currently limits request and response messages to
+16KB, so we can't generate or verify signatures greater than that size.
+In this case, keygen will return HAL_ERROR_UNSUPPORTED_KEY.</p></li>
+</ol>
+
+<p>Because the hashsig private key consists of a large number of one-time
+signing keys, and because only the root tree is stored in flash, it can
+take several minutes to reconstruct the full tree on system restart.
+During this time, attempts to generate a hashsig key, delete a hashsig
+key, or sign with a hashsig key will return HAL_ERROR_NOT_READY.</p>
+
+<p>A hashsig private key can sign at most 2^(L*h) messages. (System restarts
+will cause the lower-level trees to be regenerated, which will need to be
+signed with by the root tree, so frequent restarts will rapidly exhaust
+the root tree.) When a hashsig key is exhausted, any attempt to use it for
+signing will return HAL_ERROR_HASHSIG_KEY_EXHAUSTED.</p>
+
+<h2>Keystore</h2>
+
+<p>The keystore is basically a light-weight database intended to be run
+directly over some kind of block-access device, with an internal
+low-level driver interface so that we can use the same API for
+multiple keystore devices (eg, flash for "token objects" and RAM for
+"session objects", in the PKCS #11 senses of those terms).</p>
+
+<p>The available storage is divided up into "blocks" of a fixed size; for
+simplicity, the block size is a multiple of the subsector size of the
+flash chip on the Alpha platform, since that's the minimum erasable
+unit.  All state stored in the keystore itself follows the conventions
+needed for flash devices, whether the device in question is flash or
+not.  The basic rule here is that one can only clear bits, never set
+them: the only way to set a bit is to erase the whole block and start
+over.  So blocks progress from an initial state ("erased") where all
+bits are set to one, through several states where the block contains
+useful data, and ending in a state where all bits are set to zero
+("zeroed"), because that's the way that flash hardware works.</p>
+
+<p>The keystore implementation also applies a light-weight form of wear
+leveling to all keystore devices, whether they're flash devices or
+not.  The wear-leveling mechanism is not particularly sophisticated,
+but should suffice.  The wear-leveling code treats the entirety of a
+particular keystore device as a ring buffer of blocks, and keeps track
+of which blocks have been used recently by zeroing blocks upon freeing
+them rather than erasing them immediately, while also always keeping
+the block at the current head of the free list in the erased state.
+Taken together, this is enough to recover location of the block at the
+head of the free list after a reboot, which is sufficient for a
+round-robin wear leveling strategy.</p>
+
+<p>The block format includes a field for a CRC-32 checksum, which covers
+the entire block except for a few specific fields which need to be
+left out.  On reboot, blocks with bad CRC-32 values are considered
+candidates for reuse, but are placed at the end of the free list,
+preserve their contents for as long as possible in case the real
+problem is a buggy firmware update.</p>
+
+<p>At the moment, the decision about whether to use the CRC-32 mechanism
+is up to the individual driver: the flash driver uses it, the RAM
+driver (which never stores anything across reboots anyway) does not.</p>
+
+<p>Since the flash-like semantics do not allow setting bits, updates to a
+block always consist of allocating a new block and copying the
+modified data.  The keystore code uses a trivial lock-step protocol
+for this: first:</p>
+
+<ol>
+<li>The old block is marked as a "tombstone";</li>
+<li>The new block (with modified data) is written;</li>
+<li>The old block is erased.</li>
+</ol>
+
+<p>This protocol is deliberately as simple as possible, so that there is
+always a simple recovery path on reboot.</p>
+
+<p>Active blocks within a keystore are named by UUIDs.  With one
+exception, these are always type-4 (random) UUIDs, generated directly
+from output of the TRNG.  The one exception is the current PIN block,
+which always uses the reserved all-zeros UUID, which cannot possibly
+conflict with a type-4 UUID (by definition).</p>
+
+<p>The core of the keystore mechanism is the <code>ks-&gt;index[]</code> array, which
+contains nothing but a list of block numbers.  This array is divided
+into two parts: the first part is the index of active blocks, which is
+kept sorted (by UUID); the second part is the round-robin free list.
+Everything else in the keystore is indexed by these block numbers,
+which means that the index array is the only data structure which the
+keystore code needs to sort or rotate when adding, removing, or
+updating a block.  Because the block numbers themselves are small
+integers, the index array itself is small enough that shuffling data
+within it using <code>memmove()</code> is a relatively cheap operation, which in
+turn avoids a lot of complexity that would be involved in managing
+more sophisticated data structures.</p>
+
+<p>The keystore code includes both caching of recently used keystore
+blocks (to avoid unnecessary flash reads) and caching of the location
+of the block corresponding to a particular UUID (to avoid unnecessary
+index searches).  Aside from whatever direct performance benefits this
+might bring, this also frees the pkey layer that sits directly on top
+of the keystore code from needing to keep a lot of active state on
+particular keystore objects, which is important given that this whole
+thing sits under an RPC protocol driven by a client program which can
+impose arbitrary delays between any two operations at the pkey layer.</p>
+
+<h2>Key backup</h2>
+
+<p>The key backup mechanism is a straightforward three-step process,
+mediated by a Python script which uses the Python client
+implementation of the RPC mechanism.  Steps:</p>
+
+<ol>
+<li><p>Destination HSM (target of key transfer) generates an RSA keypair,
+exports the public key (the "key encryption key encryption key" or
+"KEKEK").</p></li>
+<li><p>Source HSM (origin of the key transfer) wraps keys to be backed up
+using AES keywrap with key encryption keys (KEKs) generated by the
+TRNG; these key encryption keys are in turn encrypted with RSA
+public key (KEKEK) generated by the receipient HSM.</p></li>
+<li><p>Destination HSM receives wrapped keys, unwraps the KEKs using the
+KEKEK then unwraps the wrapped private keys.</p></li>
+</ol>
+
+<p>Transfer of the wrapped keys between the two HSMs can be by any
+convenient mechanism; for simplicity, <code>cryptech_backup</code> script bundles
+everything up in a text file using JSON and Base64 encoding.</p>
+
+<h2>Multiplexer daemon</h2>
+
+<p>While the C client library can be built to talk directly to the
+Cryptech Alpha board, in most cases it is more convenient to use the
+<code>cryptech_muxd</code> multiplexer daemon, which is now the default.  Client
+code talks to <code>cryptech_muxd</code> via a <code>PF_UNIX</code> socket; <code>cryptech_muxd</code>
+handles interleaving of messages between multiple clients, and also
+manages access to the Alpha's console port.</p>
+
+<p>The multiplexer requires two external Python libraries, Tornado
+(version 4.0 or later) and PySerial (version 3.0 or later).</p>
+
+<p>In the long run, the RPC mechanism will need to be wrapped in some
+kind of secure channel protocol, but we're not there yet.</p>
+
+<h2>API</h2>
+
+<p>Yeah, we ought to document the API, Real Soon Now, perhaps using
+<a href="http://www.doxygen.org/">Doxygen</a>.  For the moment, see the function prototypes in hal.h,
+the Python definitions in cryptech.libhal, and and comments in the
+code.</p>
+```
+
+[[RepositoryIndex(format=table,glob=sw/libhal)]]
+
+| Clone `https://git.cryptech.is/sw/libhal.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Fpkcs11.md b/raw-wiki-dump/GitRepositories%2Fsw%2Fpkcs11.md
new file mode 100644
index 0000000..a821db0
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw%2Fpkcs11.md
@@ -0,0 +1,78 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>PKCS #11</h1>
+
+<h2>Introduction</h2>
+
+<p>This is an implementation of the <a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a> API for the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a>
+project.  Like most PKCS #11 implementations, this one is incomplete
+and probably always will be: PKCS #11 is very open-ended, and the
+specification includes enough rope for an unwary developer to hang not
+only himself, but all of his friends, relations, and casual
+acquaintances.</p>
+
+<p>Along with the PKCS #11 library itself, the package includes a
+companion Python interface ("cryptech.py11"), which uses the ctypes
+module from the Python standard library to talk to the PKCS #11
+implementation.  The Python implementation is intended primarily to
+simplify testing the C code, but can be used for other purposes; while
+it seems unlikely that anything could ever make PKCS #11 "fun", the
+<code>cryptech.py11</code> library attempts to make it a bit less awful by
+providing both direct acess to the raw PKCS #11 API and a somewhat
+more "pythonic" API layered on top of the raw API.</p>
+
+<h2>Novel design features</h2>
+
+<p><a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a>'s data model involves an n-level-deep hierarchy of object
+classes, which is somewhat tedious to implement correctly in C,
+particularly if one wants the correspondence between specification and
+code to be at all obvious.  In order to automate much of the drudge
+work involved, this implementation uses an external representation of
+the object class hierarchy, which is processed at compile time by a
+Python script to generate tables which drive the C code which performs
+the necessary type checking.</p>
+
+<h2>Current status</h2>
+
+<p>As of this writing, the implementation supports only the RSA, ECDSA,
+SHA-1, and SHA-2 algorithms, but the design is intended to be
+extensible.</p>
+
+<p>The underlying cryptographic support comes from the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a>
+<code>libhal</code> package.</p>
+
+<p>Testing to date has been done using the <code>bin/pkcs11/</code> tools from the
+BIND9 distribution, the <code>hsmcheck</code> and <code>ods-hsmutil</code> tools from the
+OpenDNSSEC distribution, the <code>hsmbully</code> diagnostic tool, the Google
+<code>pkcs11test</code> test suite, and a somewhat ad hoc set of unit tests using
+Python's unittest library along with our own <code>cryptech.py11</code> library.</p>
+
+<p>The library is also known to work as an <code>OpenSSL</code> engine when used
+with the <code>engine-pkcs11</code> package spun out of the OpenSC project.  This
+has not been tested extensively, but key generation, signature, and
+verification all work (with RSA keys -- the engine appears not to
+understand ECDSA keys, we have not investigated into details here).</p>
+
+<h2>Copyright status</h2>
+
+<p>The <a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a> header files are "derived from the RSA Security Inc.
+PKCS #11 Cryptographic Token Interface (Cryptoki)".  See the
+<code>pkcs11*.h</code> header files for details.</p>
+
+<p>Code written for the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a> project is under the usual Cryptech
+BSD-style license.</p>
+```
+
+[[RepositoryIndex(format=table,glob=sw/pkcs11)]]
+
+| Clone `https://git.cryptech.is/sw/pkcs11.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Fstm32.md b/raw-wiki-dump/GitRepositories%2Fsw%2Fstm32.md
new file mode 100644
index 0000000..b4a4cc7
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw%2Fstm32.md
@@ -0,0 +1,180 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>STM32 firmware for Cryptech Alpha board</h1>
+
+<p>The Alpha board is our first full prototype for an open-source hardware
+security module (HSM). It is a custom board with an STM32 Cortex-M4
+microcontroller and an Artix-7 FPGA, flash-based keystore, separate memory
+for the Key Encryption Key, etc. See the <code>hardware</code> repository for
+schematics and production files. See the wiki for design documents.</p>
+
+<p>The code in this repository builds the firmware that provides the HSM
+functionality on the Alpha board.</p>
+
+<p>There is some residual code here to support the "dev-bridge" board, a
+daughterboard for the Novena, which talks to the Novena's FPGA through the
+high-speed expansion connector. Only a few of these boards were ever made,
+and all development/testing ceased as soon as the Alpha became available,
+so the dev-bridge should be considered deprecated, and support may be
+removed in the future.</p>
+
+<h1>Copyrights</h1>
+
+<p>The license for all work done on this in the CrypTech project is a
+3-clause BSD license.</p>
+
+<p>Third-party components, as well as code generated using the
+STMicroelectronics initialization code generator STM32CubeMX, or adapted
+from STM example/support code, may have different licensing, detailed
+below.</p>
+
+<h1>Components</h1>
+
+<h2>Libraries</h2>
+
+<ul>
+<li><p><code>mbed</code> - A stripped down copy of the ARM CMSIS library, copied from the
+mbed github (see <code>libraries/mbed/README.txt</code> for details). The bulk of
+this library is covered under 3-clause BSD licenses from either ARM or
+STMicroelectronics, but one file is covered under an Apache license from
+ARM.</p></li>
+<li><p><code>libhal</code> - Build directory for our own Hardware Adaption Library
+(hardware-independent Cryptech components). Source is expected to be in
+<code>sw/libhal</code>.</p></li>
+<li><p><code>libtfm</code> - Build directory for "Tom's Fast Math", which is used heavily
+for bignum math in the RSA and ECDSA code. This code is covered under an
+unrestricted public domain license, and source is expected to be in
+<code>sw/thirdparty/libtfm</code>.</p></li>
+<li><p><code>libcli</code> - Build directory for a third-party Command Line Interface
+library. The source is not currently under <code>sw/thirdparty</code> because the
+license is LGPLv2.1; we are negotiating to see if we can get a
+BSD-compatible license for it.</p></li>
+<li><p><code>libprof</code> - A port of the <code>gmon</code> profiling package, to be used in
+development only, not in production code (obviously). The licensing is a
+mix of BSD and "Cygwin license", which now seems to be LGPLv3.</p></li>
+</ul>
+
+<h2>Projects</h2>
+
+<p>These directories build different firmware images for the Alpha board.</p>
+
+<ul>
+<li><p><code>hsm</code> - Firmware providing HSM functionality. Clients communicate via
+RPC requests on the USER USB port, or interactively on the MGMT USB
+port.</p></li>
+<li><p><code>bootloader</code> - The first thing that runs on the device. It either starts
+the primary firmware, or installs new firmware.</p></li>
+<li><p><code>board-test</code> - Tests of hardware components.</p></li>
+<li><p><code>cli-test</code> - Test of the CLI itself, plus some interactive tests of
+hardware components. Duplicates way too much of the HSM CLI.</p></li>
+<li><p><code>libhal-test</code> - A framework for running the libhal component
+tests. Hasn't been run in a while, probably still works.</p></li>
+</ul>
+
+<h1>Building</h1>
+
+<p>Our primary build environments are Debian and Ubuntu, but this should work
+on any system with Gnu tools installed.</p>
+
+<p>The following packages need to be installed:</p>
+
+<pre><code>$ apt-get install gcc-arm-none-eabi gdb-arm-none-eabi openocd
+</code></pre>
+
+<p>The Makefile assumes that all Cryptech repositories have been fetched into
+a canonical directory structure, e.g. <code>libhal</code> and <code>thirdparty</code> are
+siblings to this directory, under <code>sw</code>.</p>
+
+<p>To build the source code, issue <code>make</code> from the top level directory
+(where this file is). The first time, this will build the complete STM
+CMSIS library. A subsequent <code>make clean</code> will <em>not</em> clean away the CMSIS
+library, but a <code>make distclean</code> will.</p>
+
+<h1>Installing</h1>
+
+<p>Do <code>bin/flash-target</code> from the top level directory (where this file is)
+to flash a built image into the microcontroller. See the section ST-LINK
+below for information about the actual hardware programming device needed.</p>
+
+<p>Example loading the HSM firmware:</p>
+
+<pre><code>$ make hsm
+$ ./bin/flash-target projects/hsm/hsm
+</code></pre>
+
+<p>At this point, the STM32 will reset into the bootloader which flashes the
+blue LED five times in one second, and then jumps to the primary firmware.</p>
+
+<p>Once the bootloader is installed, regular firmware can be loaded without
+an ST-LINK cable like this:</p>
+
+<pre><code>$ cryptech_upload --firmware -i projects/hsm/hsm.bin
+</code></pre>
+
+<p>Then reboot the Alpha board.</p>
+
+<h2>ST-LINK</h2>
+
+<p>To program the MCU, an ST-LINK adapter is used. The cheapest way to get
+one is to buy an evaluation board with an ST-LINK integrated, and pinouts
+to program external chips. This should work with any evaluation board from
+STM; we have tested with STM32F4DISCOVERY (with ST-LINK v2.0) and
+NUCLEO-F411RE (with ST-LINK v2.1).</p>
+
+<p>The ST-LINK programming pins is called J1 and is near the CrypTech logo
+printed on the circuit board. The pin-outs is shown on the circuit board
+(follow the thin white line from J1 to the white box with STM32_SWD
+written in it). From left to right, the pins are</p>
+
+<pre><code>3V3, CLK, GND, I/O, NRST and N/C
+</code></pre>
+
+<p>This matches the pin-out on the DISCO and NUCLEO boards we have tried.</p>
+
+<p>First remove the pair of ST-LINK jumpers (CN4 on the DISCO, CN2 on the
+NUCLEO). Then find the 6-pin SWD header on the left of the STM board (CN2
+on the DISCO, CN4 on the NUCLEO), and connect them to the Alpha board:</p>
+
+<pre><code>NUCLEO / DISCO           CRYPTECH ALPHA
+--------------           --------------
+* 1 VDD_TARGET      &lt;-&gt;  3V3
+* 2 SWCLK / T_JTCK  &lt;-&gt;  CLK
+* 3 GND             &lt;-&gt;  GND
+* 4 SWDIO / T_JTMS  &lt;-&gt;  IO
+* 5 NRST / T_NRST   &lt;-&gt;  NRST
+* 6 N/C
+</code></pre>
+
+<p>The Alpha board should be powered on before attempting to flash it.</p>
+
+<h2>Debugging the firmware</h2>
+
+<p><a href="http://fun-tech.se/stm32/OpenOCD/gdb.php">This site</a> shows several ways
+to use various debuggers to debug the firmware in an STM32.</p>
+
+<p>There is a shell script called 'bin/debug' that starts an OpenOCD server
+and GDB. Example:</p>
+
+<pre><code>$ ./bin/debug projects/hsm/hsm
+</code></pre>
+
+<p>Once in GDB, issue <code>monitor reset halt</code> to reset the STM32 before debugging.</p>
+
+<p>Remember that the first code to run will be the bootloader, but if you do
+e.g. <code>break main</code> and <code>continue</code> you will end up in main() after the
+bootloader has jumped there.</p>
+```
+
+[[RepositoryIndex(format=table,glob=sw/stm32)]]
+
+| Clone `https://git.cryptech.is/sw/stm32.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Ftamper.md b/raw-wiki-dump/GitRepositories%2Fsw%2Ftamper.md
new file mode 100644
index 0000000..cec2785
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw%2Ftamper.md
@@ -0,0 +1,128 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Cryptech tamper detection</h1>
+
+<p>This is software for the Atmel AVR ATtiny828 MCU on the Cryptech alpha
+board, rev02, implementing tamper detection and master key erasure.</p>
+
+<h2>Overview</h2>
+
+<pre><code>   *************
+   * P A N I C *
+   *   button  *
+   *************
+    /
+   /
+  /
+AVR ---- SPI mux ---- FPGA
+            |          |
+            |         ARM
+           MKM
+
+AVR -- Atmel MCU
+FPGA -- FPGA
+MKM -- Master Key Memory, 23K640 SRAM
+SPI mux -- 2 x MC74AC244DW
+ARM -- ARM CPU
+</code></pre>
+
+<p>The MKM holds the master key for the device.</p>
+
+<p>The AVR, MKM and the mux are all battery powered.</p>
+
+<p>The AVR and the FPGA are both sharing access to the MKM through the
+mux, with the AVR connected to the pins used for deciding who's in
+control of the memory. If the AVR doesn't actively grab control of the
+MKM, the FPGA is in control.</p>
+
+<p>When the panic button is pressed, the AVR takes control over the MKM
+and writes zeros to it as quickly as possible. In idle mode, i.e. when
+the panic button is not pressed, the AVR tries to consume as little
+power as possible.</p>
+
+<h2>Building the software</h2>
+
+<p>To build a .hex file suitible for uploading to a board with a
+ATTiny828, a C compiler for AVR is needed, as wells a objcopy. On a
+Debian system, the following command can be used for installing both:</p>
+
+<pre><code>apt-get install gcc-avr binutils-avr avr-libc
+</code></pre>
+
+<p>To build tamper.hex, type 'make' in this directory.</p>
+
+<p>To upload a .hex file to a board, the program avrdude can be used. On
+a Debian system, the following command can be used for installing
+avrdude:</p>
+
+<pre><code>apt-get install avrdude
+</code></pre>
+
+<p>If configuration for ATtiny828 is missing, the file attiny828.conf in
+this directory could be appended to avrdude.conf:</p>
+
+<pre><code>cat attiny828.conf &gt;&gt; /etc/avrdude.conf
+</code></pre>
+
+<p>Often, a piece of hardware called "SPI programmer" is needed in order
+to upload the .hex file to the target system. The one I've been using
+has "sparkfun.com" printed on it. This small board has a mini-USB port
+to connect to a host system and a header with SPI pins to connect to a
+board with an AVR on it.</p>
+
+<p>To upload a .hex file to a board, use the upload.sh shell script in
+this directory with the name of the file as the only argument:</p>
+
+<pre><code>./upload.sh tamper.hex
+</code></pre>
+
+<p>Depending on permissions on your host system you might want to run the
+upload script as root.</p>
+
+<h2>GPIO on Cryptech HSM rev.03</h2>
+
+<p>The GPIO ports are located on JP5 (AVR_GPIO). From left to right, as seen when the marking is above the connector, the ports are:</p>
+
+<ol>
+<li>3V3</li>
+<li>PORTC0</li>
+<li>PORTC1</li>
+<li>PORTC2</li>
+<li>PORTC3</li>
+<li>PORTC4</li>
+<li>PORTC5</li>
+<li>PORTC6</li>
+<li>PORTC7
+<ol>
+<li>GND</li>
+</ol></li>
+</ol>
+
+<h2>Dependencies</h2>
+
+<h3>Debian</h3>
+
+<ul>
+<li>apt-get install gcc-avr binutils-avr avr-libc avrdude</li>
+</ul>
+
+<h3>Fedora</h3>
+
+<ul>
+<li>dnf install avrdude avr-gcc avr-libc</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=sw/tamper)]]
+
+| Clone `https://git.cryptech.is/sw/tamper.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty%2Flibtfm.md b/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty%2Flibtfm.md
new file mode 100644
index 0000000..03eaeb8
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty%2Flibtfm.md
@@ -0,0 +1,31 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>libtfm</h1>
+
+<p>This is a trivial port of the Tom's Fast Math (TFM) bignum library to
+the Cryptech environment.  We use a git submodule to pull the package
+from GitHub, we verify that the SHA-256 digest of what we got from
+GitHub matches the version we tested, then we build the library with
+the options we want.</p>
+
+<p>See tomsfastmath/doc/tfm.pdf for API details.</p>
+
+<p>In theory, the need for most (perhaps all) of this will go away when
+more of the bignum math is implemented in Verilog.  Part of the reason
+for using the TFM library is that its extremely modular structure make
+it easy for us to link in only the functions we need.</p>
+```
+
+[[RepositoryIndex(format=table,glob=sw/thirdparty/libtfm)]]
+
+| Clone `https://git.cryptech.is/sw/thirdparty/libtfm.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty%2Fsqlite3.md b/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty%2Fsqlite3.md
new file mode 100644
index 0000000..5d9c0d3
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty%2Fsqlite3.md
@@ -0,0 +1,25 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>SQLite3</h1>
+
+<p>This is a trivial port of the SQLite3 database package to the Cryptech
+environment.</p>
+
+<p>If we end up making heavier use of SQLite3 as the project progresses,
+we may need something more elaborate (eg, to enable SQLite3's "bare
+flash" driver), but this should suffice for the moment.</p>
+```
+
+[[RepositoryIndex(format=table,glob=sw/thirdparty/sqlite3)]]
+
+| Clone `https://git.cryptech.is/sw/thirdparty/sqlite3.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty.md b/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty.md
new file mode 100644
index 0000000..b6977ef
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw%2Fthirdparty.md
@@ -0,0 +1,19 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/sw/thirdparty/ekermit| sw/thirdparty/ekermit]] |`https://git.cryptech.is/sw/thirdparty/ekermit.git` | |
+|[[source:/sw/thirdparty/libtfm| sw/thirdparty/libtfm]] |`https://git.cryptech.is/sw/thirdparty/libtfm.git` | [[wiki:GitRepositories/sw/thirdparty/libtfm| README]] |
+|[[source:/sw/thirdparty/sqlite3| sw/thirdparty/sqlite3]] |`https://git.cryptech.is/sw/thirdparty/sqlite3.git` | [[wiki:GitRepositories/sw/thirdparty/sqlite3| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fsw.md b/raw-wiki-dump/GitRepositories%2Fsw.md
new file mode 100644
index 0000000..8c2d23c
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fsw.md
@@ -0,0 +1,24 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/sw/cryptlib| sw/cryptlib]] |`https://git.cryptech.is/sw/cryptlib.git` | [[wiki:GitRepositories/sw/cryptlib| README]] |
+|[[source:/sw/libhal| sw/libhal]] |`https://git.cryptech.is/sw/libhal.git` | [[wiki:GitRepositories/sw/libhal| README]] |
+|[[source:/sw/pkcs11| sw/pkcs11]] |`https://git.cryptech.is/sw/pkcs11.git` | [[wiki:GitRepositories/sw/pkcs11| README]] |
+|[[source:/sw/stm32| sw/stm32]] |`https://git.cryptech.is/sw/stm32.git` | [[wiki:GitRepositories/sw/stm32| README]] |
+|[[source:/sw/tamper| sw/tamper]] |`https://git.cryptech.is/sw/tamper.git` | [[wiki:GitRepositories/sw/tamper| README]] |
+|[[source:/sw/thirdparty/ekermit| sw/thirdparty/ekermit]] |`https://git.cryptech.is/sw/thirdparty/ekermit.git` | |
+|[[source:/sw/thirdparty/libtfm| sw/thirdparty/libtfm]] |`https://git.cryptech.is/sw/thirdparty/libtfm.git` | [[wiki:GitRepositories/sw/thirdparty/libtfm| README]] |
+|[[source:/sw/thirdparty/sqlite3| sw/thirdparty/sqlite3]] |`https://git.cryptech.is/sw/thirdparty/sqlite3.git` | [[wiki:GitRepositories/sw/thirdparty/sqlite3| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_bp_entropy.md b/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_bp_entropy.md
new file mode 100644
index 0000000..71d0d0a
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_bp_entropy.md
@@ -0,0 +1,38 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>coretest_bpaysan_entropy</h1>
+
+<p>Coretest system for testing the FPGA based entropy source developed by Bernd Paysan.</p>
+
+<h2>Introduction</h2>
+
+<p>This project is a coretest system dedicated to test entropy sources
+within a FPGA device. The specific entropy source has ben designed by
+Bernd Paysan.</p>
+
+<p>The entropy source used two sets of 16 free running digital oscillators
+that are interconnected.</p>
+
+<p>The system uses the coretest module to read and write 32-bit data to
+core, In this case it allows a caller to read generated random 16-bit
+values from the entropy source. The 16 bit data is in the LSB of the
+word.</p>
+
+<p>The completc system contains a UART core for external access. The
+project contains pin assignments etc to implement the system on a
+TerasIC C5G board.</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/coretest_bp_entropy)]]
+
+| Clone `https://git.cryptech.is/test/coretest_bp_entropy.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_fpga_entropy.md b/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_fpga_entropy.md
new file mode 100644
index 0000000..02b3a16
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_fpga_entropy.md
@@ -0,0 +1,50 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>coretest_fpga_entropy</h1>
+
+<p>Coretest system for testing FPGA based entropy source.</p>
+
+<h2>Introduction</h2>
+
+<p>This project is a coretest system dedicated to test entropy sources
+within a FPGA device. The specific entropy source is based on a digital
+oscillator design by Bernd Paysan. In this entropy source, we use six
+instances with different frequencies. The oscillator outputs are
+combined to generate a bit value. 32 bit values are combined to create a
+random word.</p>
+
+<p>The system uses the coretest module to read and write 32-bit data to
+core, In this case it allows a caller to read generated random 16-bit
+values from the entropy source. The 16 bit data is in the LSB of the
+word.</p>
+
+<p>The completc system contains a UART core for external access. The
+project contains pin assignments etc to implement the system on a
+TerasIC C5G board.</p>
+
+<h2>Implementation details.</h2>
+
+<p>This FPGA system consists of the following components:</p>
+
+<ul>
+<li>The FPGA entropy source core</li>
+<li>The UART core</li>
+<li>The coretest core</li>
+</ul>
+
+<p>There are pin assignments and clock defines for the TerasIC C5G board.</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/coretest_fpga_entropy)]]
+
+| Clone `https://git.cryptech.is/test/coretest_fpga_entropy.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_test_core.md b/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_test_core.md
new file mode 100644
index 0000000..d578c25
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Fcoretest_test_core.md
@@ -0,0 +1,24 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>coretest_test_core</h1>
+
+<p>The coretest module combined with the test_core as a test module. The
+uart core is used as external interface.</p>
+
+<p>This repo basically contains the top level wrapper that builds a
+coretest system ready to be integrated into a real FPGA.</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/coretest_test_core)]]
+
+| Clone `https://git.cryptech.is/test/coretest_test_core.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Fexternal_avalanche_entropy.md b/raw-wiki-dump/GitRepositories%2Ftest%2Fexternal_avalanche_entropy.md
new file mode 100644
index 0000000..05cb516
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Fexternal_avalanche_entropy.md
@@ -0,0 +1,36 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h2>External Avalanche Entropy</h2>
+
+<p>This is a test project of an entropy provider that collects entropy from
+an avalanche noise based source.</p>
+
+<p>The design expects a one bit digital input noise signal. The collector
+observes positive flank events in the input noise signal and measures the
+time between these events using a counter. The counter is free running
+and increases once for each clock cycle (currently running av 50 MHz).</p>
+
+<p>The LSB of the counter is added to a 32-bit entropy register at each
+event.</p>
+
+<p>As debug output the entropy register is sampled at a given rate
+(currently a few times per second). The debug output is connected to LED
+on the FPGA development board.</p>
+
+<p>The project also contains project files, pin assignments and clock
+definition neded to implement the design on a TerasIC DE0-Nano board.</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/external_avalanche_entropy)]]
+
+| Clone `https://git.cryptech.is/test/external_avalanche_entropy.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Ffpga_entropy.md b/raw-wiki-dump/GitRepositories%2Ftest%2Ffpga_entropy.md
new file mode 100644
index 0000000..6af5b66
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Ffpga_entropy.md
@@ -0,0 +1,31 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>fpga_entropy</h1>
+
+<p>Test implementation of FPGA-internal entropy source.</p>
+
+<h2>Introduction</h2>
+
+<p>This is an attempt at building an entropy source within a FPGA
+device. the entropy source consists of multiple delay loops that are
+XORed together. The bits sampled are used to generate 32 bit words which
+can be extracted to a host machine for analysis.</p>
+
+<p>The main problem is probably being able to control the FPGA tool not to
+kill the delay loops. We try to do this by building hierarchies. It
+might work.</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/fpga_entropy)]]
+
+| Clone `https://git.cryptech.is/test/fpga_entropy.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_base.md b/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_base.md
new file mode 100644
index 0000000..c91873a
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_base.md
@@ -0,0 +1,48 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Cryptech Novena FPGA baseline</h1>
+
+<h2>Introduction</h2>
+
+<p>This repo contains the Novena FPGA baseline developed as part of the
+Cryptech project. The design contains a new FPGA top level, now clock
+implementation and reworked EIM interface.</p>
+
+<p>The main purpose of the baseline is to allow us to run the Cryptech
+cores and FPGA system with the general system clock and then interface
+to the EIM with the EIM burst clock.</p>
+
+<h2>Technical details</h2>
+
+<p>The design tries to be a clean top that is easy for others to work on
+and adapt to their needs. The top is stripped from ports not needed for
+the baseline. All clock and reset implementation is placed in a separate
+module. The EIM interface is in a separate module and then the rest of
+the system is in a third module.</p>
+
+<p>Internally the baseline contains an arbiter to connect cores with a
+32-bit memory like interface to the EIM. Finally there is SW to
+configure the EIM interface as well as talking to a test core in the
+FPGA.</p>
+
+<p>For information about the EIM clocking and the baseline HW and SW
+design, see the documentation.</p>
+
+<h2>Author</h2>
+
+<p>The baseline has been written by Pavel Shatov.</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/novena_base)]]
+
+| Clone `https://git.cryptech.is/test/novena_base.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_entropy.md b/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_entropy.md
new file mode 100644
index 0000000..9f6730e
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_entropy.md
@@ -0,0 +1,39 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>novena_entropy</h1>
+
+<p>This is an experimental HW system for the Novena platform.</p>
+
+<p>The purpose of the system is to debug, evaluate and qualify the
+avalanche Cryptech entropy providers for the Novena platform with the
+Xilinx Spartan-6 FPGA. The entropy providers being tested are the noise
+based entropy provider and the ring oscillator based entropy provider.</p>
+
+<p>The following cores are used in the system:
+  - core/coretest, the test command parser</p>
+
+<ul>
+<li><p>core/i2c, the serial interface that connects the system to the
+Novena CPU.</p></li>
+<li><p>core/avalanche_entropy, the entropy provider that is driven by an
+external noise source.</p></li>
+<li><p>core/rosc_entropy, the entropy provider driven by jitter between 32
+independently running ring oscillators in the FPGA.</p></li>
+</ul>
+
+<p>Test SW is available in src/sw</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/novena_entropy)]]
+
+| Clone `https://git.cryptech.is/test/novena_entropy.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_i2c_simple.md b/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_i2c_simple.md
new file mode 100644
index 0000000..eab8f08
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_i2c_simple.md
@@ -0,0 +1,46 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>novena_i2c_simple</h1>
+
+<p>The coretest system for the Novena PVT1, over I2C, with simplified
+user interface.</p>
+
+<h2>Introduction</h2>
+
+<p>This variant of novena_i2c provides a more intuitive, more compact,
+and more efficient user interface - just write() the block data, and
+read() the digest. All signalling to/from the hash cores is implicit
+and handled by the SHA wrapper cores.</p>
+
+<p>Repeated writes to the same SHA core will be added to the same digest;
+the act of reading the digest resets the internal state, so that the
+next write will start a new digest.</p>
+
+<p>Each hash algorithm is a separate virtual I2C device on bus 2, with
+the following device addresses:
+  SHA-1         0x1e
+  SHA-256       0x1f
+  SHA-512/224   0x20
+  SHA-512/256   0x21
+  SHA-384       0x22
+  SHA-512       0x23</p>
+
+<h2>Status</h2>
+
+<p><strong><em>(2014-09-18)</em></strong>
+Initial version. Built using Xilinx ISE 14.3.</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/novena_i2c_simple)]]
+
+| Clone `https://git.cryptech.is/test/novena_i2c_simple.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_trng.md b/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_trng.md
new file mode 100644
index 0000000..4815ec2
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Fnovena_trng.md
@@ -0,0 +1,42 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>novena_trng</h1>
+
+<p>This is an experimental HW system for the Novena platform.</p>
+
+<p>The purpose of the system is to debug, evaluate and qualify the
+Cryptech True Random Number Generator (TRNG) on the Novena platform with
+the Xilinx Spartan-6 FPGA. The entropy providers being tested are the noise
+based entropy provider and the ring oscillator based entropy provider.</p>
+
+<p>The following cores are used in the system:
+  - core/coretest, the test command parser</p>
+
+<ul>
+<li><p>core/i2c, the serial interface that connects the system to the
+Novena CPU.</p></li>
+<li><p>core/avalanche_entropy, the entropy provider that is driven by an
+external noise source.</p></li>
+<li><p>core/rosc_entropy, the entropy provider driven by jitter between 32
+independently running ring oscillators in the FPGA.</p></li>
+<li><p>core/trng, the cryptech random number generator. This core uses the
+ChaCha stream cipher core in core/chacha, the SHA-512 hash function
+core in core/sha512</p></li>
+</ul>
+
+<p>Test SW is available in src/sw</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/novena_trng)]]
+
+| Clone `https://git.cryptech.is/test/novena_trng.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest%2Ftest_core.md b/raw-wiki-dump/GitRepositories%2Ftest%2Ftest_core.md
new file mode 100644
index 0000000..46f09d3
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest%2Ftest_core.md
@@ -0,0 +1,23 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>test_core</h1>
+
+<p>A very simple test core with a simple 32-bit memory lilke interface and
+debug port that can be connected to external LEDs etc. Used to drive the
+verification of the coretest framework where it is used as a test
+target.</p>
+```
+
+[[RepositoryIndex(format=table,glob=test/test_core)]]
+
+| Clone `https://git.cryptech.is/test/test_core.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Ftest.md b/raw-wiki-dump/GitRepositories%2Ftest.md
new file mode 100644
index 0000000..cbef0ed
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Ftest.md
@@ -0,0 +1,26 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/test/coretest_bp_entropy| test/coretest_bp_entropy]] |`https://git.cryptech.is/test/coretest_bp_entropy.git` | [[wiki:GitRepositories/test/coretest_bp_entropy| README]] |
+|[[source:/test/coretest_fpga_entropy| test/coretest_fpga_entropy]] |`https://git.cryptech.is/test/coretest_fpga_entropy.git` | [[wiki:GitRepositories/test/coretest_fpga_entropy| README]] |
+|[[source:/test/coretest_test_core| test/coretest_test_core]] |`https://git.cryptech.is/test/coretest_test_core.git` | [[wiki:GitRepositories/test/coretest_test_core| README]] |
+|[[source:/test/external_avalanche_entropy| test/external_avalanche_entropy]] |`https://git.cryptech.is/test/external_avalanche_entropy.git` | [[wiki:GitRepositories/test/external_avalanche_entropy| README]] |
+|[[source:/test/fpga_entropy| test/fpga_entropy]] |`https://git.cryptech.is/test/fpga_entropy.git` | [[wiki:GitRepositories/test/fpga_entropy| README]] |
+|[[source:/test/novena_base| test/novena_base]] |`https://git.cryptech.is/test/novena_base.git` | [[wiki:GitRepositories/test/novena_base| README]] |
+|[[source:/test/novena_entropy| test/novena_entropy]] |`https://git.cryptech.is/test/novena_entropy.git` | [[wiki:GitRepositories/test/novena_entropy| README]] |
+|[[source:/test/novena_i2c_simple| test/novena_i2c_simple]] |`https://git.cryptech.is/test/novena_i2c_simple.git` | [[wiki:GitRepositories/test/novena_i2c_simple| README]] |
+|[[source:/test/novena_trng| test/novena_trng]] |`https://git.cryptech.is/test/novena_trng.git` | [[wiki:GitRepositories/test/novena_trng| README]] |
+|[[source:/test/test_core| test/test_core]] |`https://git.cryptech.is/test/test_core.git` | [[wiki:GitRepositories/test/test_core| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Falpha_to_kicad.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Falpha_to_kicad.md
new file mode 100644
index 0000000..df254d5
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Falpha_to_kicad.md
@@ -0,0 +1,72 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<p>Work-in-progress repository with output of altium2kicad conversion
+of the Cryptech Alpha rev03 board.</p>
+
+<p>The conversion was done using 'convert.sh', with the Altium Designer
+project files from</p>
+
+<p>https://wiki.cryptech.is/browser/hardware/cad/rev03</p>
+
+<p>and the altium2kicad project from</p>
+
+<p>https://github.com/thesourcerer8/altium2kicad</p>
+
+<h2>Current status</h2>
+
+<p>NOTE: The latest stable KiCAD version as of this writing is 4.0.7 - it does
+NOT include necessary support for stitching vias. Install KiCAD nightly build
+to work with the Cryptech Alpha PCB.</p>
+
+<p>The schematics are mostly converted. A few components do not connect with their
+nets (e.g. C9 and C10 on sheet rev02_01), but maybe a manual overhaul will be
+needed anyways at the end of conversion. A bigger issue is that no components
+get footprints associated with them in the schema, so generating a new netlist
+won't work at all. The footprints exists in some form in the PCB, so we only
+need to figure out how to reference them properly in the schema.</p>
+
+<p>All the copper layers convert reasonably well. The challenges are mostly
+around filled polygons on the various layers. A python script (fix-pcb.py)
+modifies parameters to get a fairly close result.</p>
+
+<p>I'm currently looking into ensuring the drill hole sizes are right, and the
+non-copper layers have been largely ignored this far.</p>
+
+<h2>Issues</h2>
+
+<p>Two layers (Altium Gerber files CrypTech.G1 and CrypTech.G2) have fills
+that I have not been able to reproduce. I targeted not missing any copper,
+accepting that the KiCAD gerber fills reach more places, so add some copper
+on those layers.</p>
+
+<p>Drill hole sizes have not been checked. KiCAD seems to add ~0.85 mil more
+clearance around vias. This needs to be double checked but I'm hoping that
+we can just tolerate that.</p>
+
+<p>Importing WRL files (3D models) required some hacking of the altium2kicad
+tool that I haven't been able to work on upstreaming yet. Something is still
+not right here, but the board does have a fair amount of component (including
+the more special ones) in KiCAD 3D view.</p>
+
+<p>Another hack that has not been upstreamed is loading more of the source
+files, IIRC to get all component footprints properly converted.</p>
+
+<p>The KiCAD board does not pass DRC checks yet. I believe part of this is
+because design rule settings aren't (fully?) imported from Altium. Need
+to figure out the settings used for this project, and fix all drill sizes
+I think.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/ft/alpha_to_kicad)]]
+
+| Clone `https://git.cryptech.is/user/ft/alpha_to_kicad.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Fbootstrap.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Fbootstrap.md
new file mode 100644
index 0000000..2032e56
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Fbootstrap.md
@@ -0,0 +1,23 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Bootstrap scripts used with the Alpha board</h1>
+
+<p>Some scripts and (slightly modified) tools used to to bootstrap Alpha boards.</p>
+
+<p>TODO: Implement reproducible builds of the firmware, and have these scripts
+check for 'blessed' binaries before flashing.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/ft/bootstrap)]]
+
+| Clone `https://git.cryptech.is/user/ft/bootstrap.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Fstm32-avalanche-noise.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Fstm32-avalanche-noise.md
new file mode 100644
index 0000000..b7b5f84
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Fstm32-avalanche-noise.md
@@ -0,0 +1,177 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>STM32 avalanche noise entropy source</h1>
+
+<p>This is an open source and open hardware entropy source, using an
+STM32 microcontroller to gather entropy from a common avalanche
+noise circuit.</p>
+
+<p>A special thanks goes to Benedikt Stockebrand who designed the circuit
+and the currently used core extraction algorithm in his ARRGH project.</p>
+
+<p>http://www.stepladder-it.com/Downloads/arrgh-0.2.1alpha.txz</p>
+
+<h1>Copyrights</h1>
+
+<p>The license for all work done on this in the CrypTech project is a
+3-clause BSD license (see LICENSE.txt for details). Some files have
+been generated using the STMicroelectronics initialization code
+generator STM32CubeMX and thus have additional copyright header(s).</p>
+
+<p>The "Noise generator" and "Amplifier" parts of the circuit diagram are
+copied from the ARRGH project. ARRGH copyright statement is included
+in LICENSE.txt.</p>
+
+<p>A stripped down copy of the ARM CMSIS library version 3.20 is included
+in the Drivers/CMSIS/ directory. Unused parts (and documentation etc.)
+have been removed, but every attempt have been made to keep any
+licensing information intact. See in particular the file
+Drivers/CMSIS/CMSIS END USER LICENCE AGREEMENT.pdf.</p>
+
+<p>A full copy of the STM32F4xx HAL Drivers is included in the
+Drivers/STM32F4xx_HAL_Driver/ directory.</p>
+
+<h1>Building</h1>
+
+<p>The following packages need to be installed (on Ubuntu 14.04):</p>
+
+<p>apt-get install gcc-arm-none-eabi gdb-arm-none-eabi openocd</p>
+
+<p>XXX not sure this is the complete set, if you find that you need
+additional packages please let me know. See e-mail address at the bottom.</p>
+
+<p>To build the source code, issue "make" from the top level directory
+(where this file is). The first time, this will build the complete STM
+CMSIS library. A subsequent "make clean" will <em>not</em> clean away the CMSIS
+library, but a "make really-clean" will.</p>
+
+<h1>Installing</h1>
+
+<p>Do "make flash-target" from the top level directory (where this file is)
+to build the firmware for the application selected in the top level
+Makefile and flash it into the microcontroller. See the section STLINK
+below for information about the actual hardware programming device needed.</p>
+
+<h1>Using</h1>
+
+<p>The microcontroller code can currently run in one of two modes, set
+statically at the beginning of main(): MODE_DELTAS and MODE_ENTROPY.</p>
+
+<p>MODE_ENTROPY is the default, and means the microcontroller will send
+entropy as binary data as fast as it can get it, which is about 24 kB/s
+in the current version of hardware and software. To get some entropy
+and perform rudimentary analysis of it, and assuming USB is used and
+the device was enumerated as ttyUSB0, do</p>
+
+<p>ldattach -8 -n -1 -s 460800 tty /dev/ttyUSB0
+  echo &gt; /dev/ttyUSB0
+  cat /dev/ttyUSB0 | rngtest -c 10
+  cat /dev/ttyUSB0 | head -c 100000 | ent</p>
+
+<p>For Raspberry-Pi, follow any of the guides on the internet for how to
+enable the serial port on the GPIO pin header and then try</p>
+
+<p>ldattach -s 115200 -8 -n -1 tty /dev/ttyAMA0
+  echo &gt; /dev/ttyAMA0
+  cat /dev/ttyAMA0 | rngtest -c 10
+  cat /dev/ttyAMA0 | head -c 100000 | ent</p>
+
+<p>(the baud rate used with the R-Pi could probably be increased with a
+little hardware debugging effort).</p>
+
+<p>Which UART on the board that will receive the entropy is controlled
+by the sending of a newline to the UART ('echo &gt; /dev/ttyUSB0' and
+'echo &gt; /dev/ttyAMA0' in the examples above). The power on default is
+the USB UART.</p>
+
+<p>MODE_DELTAS is a quality assurance mode, and outputs the raw Timer IC
+values captured for analysis. The stand alone program in src/delta16/
+parses the data format used by MODE_DELTAS and can convert it to
+something you can analyse. More about how to do that later.</p>
+
+<h1>Contents</h1>
+
+<p>This documentation needs to be improved, but here are some quick notes:</p>
+
+<p>Hardware design (Eagle and PDF files) are in hardware/rev09/</p>
+
+<p>The firmware to extract entropy from this hardware is in src/entropy/</p>
+
+<p>There are additional firmwares to aid in debugging any hardware issues
+in src/led-test/ and src/uart-test/</p>
+
+<h1>Hardware</h1>
+
+<p>The avalanche noise circuit was first implemented using a NUCLEO-F401RE
+evaluation board that has an STM32F401RET6 MCU. Because of human error,
+the STM32F401RBT6 was used when assembling rev08 and rev09 boards. This
+chip has less flash and RAM, so some region mappings had to change.</p>
+
+<p>MCU dependant parameters are found in the top level common.mk near the
+top, read the comments regarding STDPERIPH_SETTINGS, MCU_LINKSCRIPT and
+SRCS.</p>
+
+<h1>STLINK</h1>
+
+<p>To program the MCU, an STLINK adapter is used. The cheapest way to get
+one is to buy an evaluation board with an STLINK integrated, and pinouts
+to program external chips. All the evaluation boards I've encountered
+from STM has this ability. I'm using an STLINK from an STM32F4DISCOVERY
+board, but the even cheaper NUCLEO-F401RE should work too. The NUCLEO
+one has a STLINK v2.1 which is probably, but not necessarily, supported
+by the OpenOCD version in your Linux distribution (as of end of 2014).</p>
+
+<p>The STLINK programming pins are the 1+4 throughole pads above the ARM
+on the circuit board. See the schematics for details, but the pinout
+from left to right (1, space, 4) of rev09 is</p>
+
+<p>NRST, space, CLK, IO, GND, VCC</p>
+
+<h1>Debugging the firmware</h1>
+
+<p>This site shows several ways to use various debuggers to debug the
+firmware in an STM32:</p>
+
+<p>http://fun-tech.se/stm32/OpenOCD/gdb.php</p>
+
+<p>I've only managed to get the most basic text line gdb to work,
+something along these lines:</p>
+
+<p>1) Start OpenOCD server (with a configuration file for your type of STLINK
+   adapter)</p>
+
+<p>$ openocd -f /usr/share/openocd/scripts/board/stm32f4discovery.cfg</p>
+
+<p>2) Connect to the OpenOCD server and re-flash already compiled firmware:</p>
+
+<p>$ telnet localhost 4444
+   reset halt
+   flash probe 0
+   stm32f2x mass_erase 0
+   flash write_bank 0 /path/to/main.bin 0
+   reset halt</p>
+
+<p>3) Start GDB and have it connect to the OpenOCD server:</p>
+
+<p>$ arm-none-eabi-gdb --eval-command="target remote localhost:3333" main.elf</p>
+
+<hr />
+
+<p>Fredrik Thulin <a href="mailto:fredrik@thulin.net">fredrik@thulin.net</a>, for the
+CrypTech project <a href="https://cryptech.is/">https://cryptech.is/</a>
+2015-01-14</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/ft/stm32-avalanche-noise)]]
+
+| Clone `https://git.cryptech.is/user/ft/stm32-avalanche-noise.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Ftamper.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Ftamper.md
new file mode 100644
index 0000000..aab1a62
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fft%2Ftamper.md
@@ -0,0 +1,95 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Cryptech tamper detection</h1>
+
+<p>This is software for the Atmel AVR ATtiny828 MCU on the Cryptech alpha
+board, rev02, implementing tamper detection and master key erasure.</p>
+
+<h2>Overview</h2>
+
+<pre><code>   *************
+   * P A N I C *
+   *   button  *
+   *************
+    /
+   /
+  /
+AVR ---- SPI mux ---- FPGA
+            |          |
+            |         ARM
+           MKM
+
+AVR -- Atmel MCU
+FPGA -- FPGA
+MKM -- Master Key Memory, 23K640 SRAM
+SPI mux -- 2 x MC74AC244DW
+ARM -- ARM CPU
+</code></pre>
+
+<p>The MKM holds the master key for the device.</p>
+
+<p>The AVR, MKM and the mux are all battery powered.</p>
+
+<p>The AVR and the FPGA are both sharing access to the MKM through the
+mux, with the AVR connected to the pins used for deciding who's in
+control of the memory. If the AVR doesn't actively grab control of the
+MKM, the FPGA is in control.</p>
+
+<p>When the panic button is pressed, the AVR takes control over the MKM
+and writes zeros to it as quickly as possible. In idle mode, i.e. when
+the panic button is not pressed, the AVR tries to consume as little
+power as possible.</p>
+
+<h2>Building the software</h2>
+
+<p>To build a .hex file suitible for uploading to a board with a
+ATTiny828, a C compiler for AVR is needed, as wells a objcopy. On a
+Debian system, the following command can be used for installing both:</p>
+
+<pre><code>apt-get install gcc-avr binutils-avr avr-libc
+</code></pre>
+
+<p>To build tamper.hex, type 'make' in this directory.</p>
+
+<p>To upload a .hex file to a board, the program avrdude can be used. On
+a Debian system, the following command can be used for installing
+avrdude:</p>
+
+<pre><code>apt-get install avrdude
+</code></pre>
+
+<p>If configuration for ATtiny828 is missing, the file attiny828.conf in
+this directory could be appended to avrdude.conf:</p>
+
+<pre><code>cat attiny828.conf &gt;&gt; /etc/avrdude.conf
+</code></pre>
+
+<p>Often, a piece of hardware called "SPI programmer" is needed in order
+to upload the .hex file to the target system. The one I've been using
+has "sparkfun.com" printed on it. This small board has a mini-USB port
+to connect to a host system and a header with SPI pins to connect to a
+board with an AVR on it.</p>
+
+<p>To upload a .hex file to a board, use the upload.sh shell script in
+this directory with the name of the file as the only argument:</p>
+
+<pre><code>./upload.sh tamper.hex
+</code></pre>
+
+<p>Depending on permissions on your host system you might want to run the
+upload script as root.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/ft/tamper)]]
+
+| Clone `https://git.cryptech.is/user/ft/tamper.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fft.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fft.md
new file mode 100644
index 0000000..75a3177
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fft.md
@@ -0,0 +1,22 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/ft/alpha_to_kicad| user/ft/alpha_to_kicad]] |`https://git.cryptech.is/user/ft/alpha_to_kicad.git` | [[wiki:GitRepositories/user/ft/alpha_to_kicad| README]] |
+|[[source:/user/ft/bootstrap| user/ft/bootstrap]] |`https://git.cryptech.is/user/ft/bootstrap.git` | [[wiki:GitRepositories/user/ft/bootstrap| README]] |
+|[[source:/user/ft/libcli| user/ft/libcli]] |`https://git.cryptech.is/user/ft/libcli.git` | |
+|[[source:/user/ft/stm32-avalanche-noise| user/ft/stm32-avalanche-noise]] |`https://git.cryptech.is/user/ft/stm32-avalanche-noise.git` | [[wiki:GitRepositories/user/ft/stm32-avalanche-noise| README]] |
+|[[source:/user/ft/stm32-dev-bridge| user/ft/stm32-dev-bridge]] |`https://git.cryptech.is/user/ft/stm32-dev-bridge.git` | |
+|[[source:/user/ft/tamper| user/ft/tamper]] |`https://git.cryptech.is/user/ft/tamper.git` | [[wiki:GitRepositories/user/ft/tamper| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob%2Fbenchmark.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob%2Fbenchmark.md
new file mode 100644
index 0000000..eb83772
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob%2Fbenchmark.md
@@ -0,0 +1,26 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Cryptech Benchmark</h1>
+
+<p>This repository contains benchmark code for Cryptech HSM.</p>
+
+<h2>Dependencies</h2>
+
+<ul>
+<li>https://github.com/jschlyter/p11speed/tree/cka_token_true</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=user/jakob/benchmark)]]
+
+| Clone `https://git.cryptech.is/user/jakob/benchmark.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob%2Ftamper.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob%2Ftamper.md
new file mode 100644
index 0000000..b0531ad
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob%2Ftamper.md
@@ -0,0 +1,128 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Cryptech tamper detection</h1>
+
+<p>This is software for the Atmel AVR ATtiny828 MCU on the Cryptech alpha
+board, rev02, implementing tamper detection and master key erasure.</p>
+
+<h2>Overview</h2>
+
+<pre><code>   *************
+   * P A N I C *
+   *   button  *
+   *************
+    /
+   /
+  /
+AVR ---- SPI mux ---- FPGA
+            |          |
+            |         ARM
+           MKM
+
+AVR -- Atmel MCU
+FPGA -- FPGA
+MKM -- Master Key Memory, 23K640 SRAM
+SPI mux -- 2 x MC74AC244DW
+ARM -- ARM CPU
+</code></pre>
+
+<p>The MKM holds the master key for the device.</p>
+
+<p>The AVR, MKM and the mux are all battery powered.</p>
+
+<p>The AVR and the FPGA are both sharing access to the MKM through the
+mux, with the AVR connected to the pins used for deciding who's in
+control of the memory. If the AVR doesn't actively grab control of the
+MKM, the FPGA is in control.</p>
+
+<p>When the panic button is pressed, the AVR takes control over the MKM
+and writes zeros to it as quickly as possible. In idle mode, i.e. when
+the panic button is not pressed, the AVR tries to consume as little
+power as possible.</p>
+
+<h2>Building the software</h2>
+
+<p>To build a .hex file suitible for uploading to a board with a
+ATTiny828, a C compiler for AVR is needed, as wells a objcopy. On a
+Debian system, the following command can be used for installing both:</p>
+
+<pre><code>apt-get install gcc-avr binutils-avr avr-libc
+</code></pre>
+
+<p>To build tamper.hex, type 'make' in this directory.</p>
+
+<p>To upload a .hex file to a board, the program avrdude can be used. On
+a Debian system, the following command can be used for installing
+avrdude:</p>
+
+<pre><code>apt-get install avrdude
+</code></pre>
+
+<p>If configuration for ATtiny828 is missing, the file attiny828.conf in
+this directory could be appended to avrdude.conf:</p>
+
+<pre><code>cat attiny828.conf &gt;&gt; /etc/avrdude.conf
+</code></pre>
+
+<p>Often, a piece of hardware called "SPI programmer" is needed in order
+to upload the .hex file to the target system. The one I've been using
+has "sparkfun.com" printed on it. This small board has a mini-USB port
+to connect to a host system and a header with SPI pins to connect to a
+board with an AVR on it.</p>
+
+<p>To upload a .hex file to a board, use the upload.sh shell script in
+this directory with the name of the file as the only argument:</p>
+
+<pre><code>./upload.sh tamper.hex
+</code></pre>
+
+<p>Depending on permissions on your host system you might want to run the
+upload script as root.</p>
+
+<h2>GPIO on Cryptech HSM rev.03</h2>
+
+<p>The GPIO ports are located on JP5 (AVR_GPIO). From left to right, as seen when the marking is above the connector, the ports are:</p>
+
+<ol>
+<li>3V3</li>
+<li>PORTC0</li>
+<li>PORTC1</li>
+<li>PORTC2</li>
+<li>PORTC3</li>
+<li>PORTC4</li>
+<li>PORTC5</li>
+<li>PORTC6</li>
+<li>PORTC7
+<ol>
+<li>GND</li>
+</ol></li>
+</ol>
+
+<h2>Dependencies</h2>
+
+<h3>Debian</h3>
+
+<ul>
+<li>apt-get install gcc-avr binutils-avr avr-libc avrdude</li>
+</ul>
+
+<h3>Fedora</h3>
+
+<ul>
+<li>dnf install avrdude avr-gcc avr-libc</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=user/jakob/tamper)]]
+
+| Clone `https://git.cryptech.is/user/jakob/tamper.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob.md
new file mode 100644
index 0000000..f231a1a
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjakob.md
@@ -0,0 +1,18 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/jakob/benchmark| user/jakob/benchmark]] |`https://git.cryptech.is/user/jakob/benchmark.git` | [[wiki:GitRepositories/user/jakob/benchmark| README]] |
+|[[source:/user/jakob/tamper| user/jakob/tamper]] |`https://git.cryptech.is/user/jakob/tamper.git` | [[wiki:GitRepositories/user/jakob/tamper| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Ffpga_mkm.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Ffpga_mkm.md
new file mode 100644
index 0000000..3ea9c92
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Ffpga_mkm.md
@@ -0,0 +1,51 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>fpga-mkm</h1>
+
+<h2>Introduction</h2>
+
+<p>This core implements a FPGA based, active Master Key Memory (MKM).</p>
+
+<p>The memory provides access control, anti-remanence functionality and
+tamper detection protection with ns zeriosation latency.</p>
+
+<p>The target FPGA family is the Lattice iCE40 that can be kept in stand-by
+with a small battery. The target design flow is the
+[http://www.clifford.at/icestorm/ "Project IceStorm"] fully open source
+Verilog-to-Bitstream flow for iCE40 FPGAs.</p>
+
+<p>The core provides a SPI slave interface for connectivity and one or more
+tamper event inputs. Finally there might be a LED that provides
+status. At least during debugging.</p>
+
+<h2>Status</h2>
+
+<p>SPI slave interface to send and receive bytes has been implemented and
+somewhat verified. Command parser and response handler that talks to the
+SPI slave has been started, but not been completed.</p>
+
+<p>The memory with the tamper respons has been implemented, but not yet
+been verified.</p>
+
+<p>Toolchain etc has been setup for the ICEstick.</p>
+
+<h2>Implementation details</h2>
+
+<h2>Implementation results</h2>
+
+<p>TBW.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/js/fpga_mkm)]]
+
+| Clone `https://git.cryptech.is/user/js/fpga_mkm.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap.md
new file mode 100644
index 0000000..9cccd22
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fkeywrap.md
@@ -0,0 +1,97 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>keywrap</h1>
+
+<h2>Introduction</h2>
+
+<p>This core implememts AES KEY WRAP as defined in <a href="https://tools.ietf.org/html/rfc3394">RFC
+3394</a> and the keywrap with padding
+according to <a href="https://tools.ietf.org/html/rfc5649">RFC 5694</a></p>
+
+<p>The core supports wrap/unwrap of objects up to 64 kByte in size.
+The core supports 128 and 256 bit wrapping keys.</p>
+
+<h2>Status</h2>
+
+<p>First complete version developed. The core does work.</p>
+
+<p>The core has been simulated with two different simulators and
+linted. The core has been used on the Cryptech Alpha and verified to
+work.</p>
+
+<h2>API</h2>
+
+<p>Objects to be processed are written in word order (MSB words). The
+caller writes the calculated magic value to the A regsisters in word
+order. The caller also needs to write the number of blocks (excluding
+magic block) into the RLEN register. Finally the caller needs to write
+the wrapping key.</p>
+
+<p>Due to address space limitations in the Cryptech cores (with 8-bit
+address space) the object storage is divided into banks [0 .. 127]. Each
+bank supports 128 32-bit words or 4096 bits. For objects lager than 4096
+bits, it is the callers responsibilty to switch banks when reading and
+writing to the storage.</p>
+
+<h2>Implementation details</h2>
+
+<h3>Key Wrap</h3>
+
+<p>The core implements the wrap block processing part of the AES Key Wrap
+as specified in chapter 2.1.1 of RFC 3394:</p>
+
+<p>For j = 0 to 5
+           For i=1 to n
+               B = AES(K, A | R[i])
+               A = MSB(64, B) ^ t where t = (n*j)+i
+               R[i] = LSB(64, B)</p>
+
+<p>The core does not perform the calculation of the magic value, which is
+the initial value of A. The core also does not perform padding om the
+message to an even 8 byte block.</p>
+
+<p>This means that SW needs to generate the 64-bit initial value of A and
+perform padding as meeded.</p>
+
+<p>(Similarly, the core implements the unwrap processng as specifie in
+chapter 2.2.2 of RFC 3394.)</p>
+
+<h3>Auto Zeroise</h3>
+
+<p>The core implements an auto zeroise functionality for secret key. This
+means that any loaded wrapping key will automatically be wiped from all
+registers storing key information after a specified timeout. Timeout
+countdown is halted when the core is performing any wrap/unwrap operation,
+and the timeout is reset to its defined start value after an operation
+has been completed.</p>
+
+<p>SW can set the timout value (in cycles), SW can also inspect the key
+status and timeout status. Reading status also triggers a reset of the
+timeout counter. This allows SW to keep a loaded key alive by simply
+checking status. Finally SW can actively trigger a key zeroisation
+operation.</p>
+
+<h2>Implementation results</h2>
+
+<p>The core has been implemented for Xilinx Artix7-t200 using ISE with the
+following results:</p>
+
+<p>Regs:    2906 (1%)
+Slices:  1991 (5%)
+RamB36E: 32 (8%)
+Clock:   100+ MH</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/js/keywrap)]]
+
+| Clone `https://git.cryptech.is/user/js/keywrap.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fmkmif.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fmkmif.md
new file mode 100644
index 0000000..1924f07
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fmkmif.md
@@ -0,0 +1,132 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Master Key Memory Interface</h1>
+
+<p>This core provides a 32-bit interface to a master key memory (MKM)
+implemented using an external volatile memory. The memory targeted is
+<a href="https://www.microchip.com/wwwproducts/en/23K640">Microchip 23K640</a>, a
+serial SRAM with a SPI interface.</p>
+
+<h2>Purpose and Functionality</h2>
+
+<p>The Master Key Memory is where a cryptographic master key is stored. the
+key is used (for example) to cryptographically wrap other keys and
+secrets. By wiping the MKM and thus the master key, the wrapped secrets
+are protected against leakage to a local attacker that physically breaks
+an active tamper detect shield.</p>
+
+<p>The core will in future versions provide functionality to autonomously
+protect against memory remanence effects by rotating bits in stored data
+and moving data to different addresses in the external memory. The core
+will also be able to autonomously zeroise the memory when given an alarm
+signal.</p>
+
+<p>The current version however simply provides an interface to the slower,
+serial memory including initializing the memory in the correct mode. The
+core supports three commands: read word, write word and initialize
+memory.</p>
+
+<h2>Limitations</h2>
+
+<p>The SPI clock is generated by the core clock (clk) divided by the
+SPI clock divisor * 2 (the divisor is the half period in cycles). The
+default divisor is set to generate an SPI clock of less than 1 MHz when
+the core clock is 50 MHz. For other speeds and other
+core frequencies the divisor will have to be adjusted.</p>
+
+<p>The core will only read and write complete 32-bit words.</p>
+
+<p>Commands given while the core is performing a read, write or
+initialization operation will silently be ignored.</p>
+
+<h2>Implementation</h2>
+
+<p>The implementation is divided into three parts:</p>
+
+<ul>
+<li><p>A SPI interface able to transmit a given number of bits at a given SPI
+clock rate. Data received are simultaneously collected and provided as
+read data. The SPI interface also generates the SPI clock and chip
+enable.</p></li>
+<li><p>A command handler core that read and write words as well as send
+init commands to the memory using the SPI interface.</p></li>
+<li><p>An API interface that provides the ability to configure the SPI clock
+speed, setting the address to be read or written and data access.</p></li>
+</ul>
+
+<p>The current implementation will initiate the Microchip memory directly
+after reset and set the memory in sequential mode. This means that it
+would actually be possible to write a stream of data to the memory, but
+since the API only handles a single 32-bit word, the mode is only used
+to remove the need to update the address between bytes.</p>
+
+<h3>Implementation Results</h3>
+
+<p><strong>Altera Cyclone IV E</strong></p>
+
+<ul>
+<li>Registers: 212</li>
+<li>Logic Elements: 289</li>
+<li>Fmax: 250 MHz</li>
+</ul>
+
+<p><strong>Altera Cyclone V</strong></p>
+
+<ul>
+<li>Registers: 221</li>
+<li>ALMs: 113</li>
+<li>Fmax: 194 MHz</li>
+</ul>
+
+<p><strong>Xilinx Spartan 6</strong></p>
+
+<ul>
+<li>Slice Registers: 206</li>
+<li>Slice LUTs: 185</li>
+<li>Fmax: 200 MHz</li>
+</ul>
+
+<p><strong>Xilinx Artix 7</strong></p>
+
+<ul>
+<li>Slice Registers: 205</li>
+<li>Slice LUTs: 176</li>
+<li>Fmax: 383 MHz</li>
+</ul>
+
+<h2>Status</h2>
+
+<p><strong>(2016-05-10)</strong></p>
+
+<p>The core has now been verified in a Xilinx Spartan-6 FPGA and the target
+Microchip memory connected to the FPGA.memory. Read and write access has
+successfully been performed with SPI clock speeds from 300 Hz to 10 MHz.</p>
+
+<p><strong>(2016-05-02)</strong></p>
+
+<p>Functional development completed. Simulation based debugging
+completed. Built design for both Altera and Xilinx FPGAs.</p>
+
+<p><strong>(2016-04-25)</strong></p>
+
+<p>Refactored core into top_-, core- and spi-modules. Made the design much
+simpler. First implementation almost completed.</p>
+
+<p><strong>(2016-04-21)</strong></p>
+
+<p>Core implementation started.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/js/mkmif)]]
+
+| Clone `https://git.cryptech.is/user/js/mkmif.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Ftoggle.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Ftoggle.md
new file mode 100644
index 0000000..e512c7d
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Ftoggle.md
@@ -0,0 +1,31 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>toggle</h1>
+
+<h2>Introduction</h2>
+
+<p>This repo contains a simple deign that toggles an ouput pin. The toggle
+is in sync with the given sys_clk, but the toggle circuit divides down
+the clock. The divisor is build time defined.</p>
+
+<p>The design is used in the Cryptech FPGA design to observe internal
+clock frequencies.</p>
+
+<h2>Status</h2>
+
+<p>Has been simulated with Icarus Verilog.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/js/toggle)]]
+
+| Clone `https://git.cryptech.is/user/js/toggle.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fvndecorrelator.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fvndecorrelator.md
new file mode 100644
index 0000000..344b2c2
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs%2Fvndecorrelator.md
@@ -0,0 +1,44 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>vndecorrelator</h1>
+
+<h1>Introduction</h1>
+
+<p>A Verilog implementation of a von Neumann decorrelator, generally called
+a conditioner or whitening function. This tiny module consumes entropy
+bits and outputs decorrelated bits.</p>
+
+<p>The <a href="http://www1.spms.ntu.edu.sg/~kkhoongm/Entropy.pdf">Von Neumann decorrelator</a>
+consumes pairs of bits and outputs bits based on the pattern in th bit pairs:</p>
+
+<ul>
+<li>00 and 11: No output of a bit.</li>
+<li>10 and 01: Output the first bit in the pair</li>
+</ul>
+
+<p>In the best case with random bits, the output bitrate will be 1/4. For
+heavily biased input bits, the rate will be much slower. When used with
+a broken entropy source that is stuck at zero or one, no bits will be
+emitted.</p>
+
+<p>This implementation operates on streams of single bits and creates pairs
+internally.</p>
+
+<h1>Status</h1>
+
+<p>Implementation done. Tested in FPGA designs and works.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/js/vndecorrelator)]]
+
+| Clone `https://git.cryptech.is/user/js/vndecorrelator.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fjs.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs.md
new file mode 100644
index 0000000..999beae
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fjs.md
@@ -0,0 +1,21 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/js/fpga_mkm| user/js/fpga_mkm]] |`https://git.cryptech.is/user/js/fpga_mkm.git` | [[wiki:GitRepositories/user/js/fpga_mkm| README]] |
+|[[source:/user/js/keywrap| user/js/keywrap]] |`https://git.cryptech.is/user/js/keywrap.git` | [[wiki:GitRepositories/user/js/keywrap| README]] |
+|[[source:/user/js/mkmif| user/js/mkmif]] |`https://git.cryptech.is/user/js/mkmif.git` | [[wiki:GitRepositories/user/js/mkmif| README]] |
+|[[source:/user/js/toggle| user/js/toggle]] |`https://git.cryptech.is/user/js/toggle.git` | [[wiki:GitRepositories/user/js/toggle| README]] |
+|[[source:/user/js/vndecorrelator| user/js/vndecorrelator]] |`https://git.cryptech.is/user/js/vndecorrelator.git` | [[wiki:GitRepositories/user/js/vndecorrelator| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fln5%2Fstm32-avalanche-noise.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fln5%2Fstm32-avalanche-noise.md
new file mode 100644
index 0000000..64995ef
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fln5%2Fstm32-avalanche-noise.md
@@ -0,0 +1,177 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>STM32 avalanche noise entropy source</h1>
+
+<p>This is an open source and open hardware entropy source, using an
+STM32 microcontroller to gather entropy from a common avalanche
+noise circuit.</p>
+
+<p>A special thanks goes to Benedikt Stockebrand who designed the circuit
+and the currently used core extraction algorithm in his ARRGH project.</p>
+
+<p>http://www.stepladder-it.com/Downloads/arrgh-0.2.1alpha.txz</p>
+
+<h1>Copyrights</h1>
+
+<p>The license for all work done on this in the CrypTech project is a
+3-clause BSD license (see LICENSE.txt for details). Some files have
+been generated using the STMicroelectronics initialization code
+generator STM32CubeMX and thus have additional copyright header(s).</p>
+
+<p>The "Noise generator" and "Amplifier" parts of the circuit diagram are
+copied from the ARRGH project. ARRGH copyright statement is included
+in LICENSE.txt.</p>
+
+<p>A stripped down copy of the ARM CMSIS library version 3.20 is included
+in the Drivers/CMSIS/ directory. Unused parts (and documentation etc.)
+have been removed, but every attempt have been made to keep any
+licensing information intact. See in particular the file
+Drivers/CMSIS/CMSIS END USER LICENCE AGREEMENT.pdf.</p>
+
+<p>A full copy of the STM32F4xx HAL Drivers is included in the
+Drivers/STM32F4xx_HAL_Driver/ directory.</p>
+
+<h1>Building</h1>
+
+<p>The following packages need to be installed (on Ubuntu 14.04):</p>
+
+<p>apt-get install gcc-arm-none-eabi gdb-arm-none-eabi openocd</p>
+
+<p>XXX not sure this is the complete set, if you find that you need
+additional packages please let me know. See e-mail address at the bottom.</p>
+
+<p>To build the source code, issue "make" from the top level directory
+(where this file is). The first time, this will build the complete STM
+CMSIS library. A subsequent "make clean" will <em>not</em> clean away the CMSIS
+library, but a "make really-clean" will.</p>
+
+<h1>Installing</h1>
+
+<p>Do "make flash-target" from the top level directory (where this file is)
+to build the firmware for the application selected in the top level
+Makefile and flash it into the microcontroller. See the section STLINK
+below for information about the actual hardware programming device needed.</p>
+
+<h1>Using</h1>
+
+<p>The microcontroller code can currently run in one of two modes, set
+statically at the beginning of main(): MODE_DELTAS and MODE_ENTROPY.</p>
+
+<p>MODE_ENTROPY is the default, and means the microcontroller will send
+entropy as binary data as fast as it can get it, which is about 24 kB/s
+in the current version of hardware and software. To get some entropy
+and perform rudimentary analysis of it, and assuming USB is used and
+the device was enumerated as ttyUSB0, do</p>
+
+<p>ldattach -8 -n -1 -s 460800 tty /dev/ttyUSB0
+  echo &gt; /dev/ttyUSB0
+  cat /dev/ttyUSB0 | rngtest -c 10
+  cat /dev/ttyUSB0 | head -c 100000 | ent</p>
+
+<p>For Raspberry-Pi, follow any of the guides on the internet for how to
+enable the serial port on the GPIO pin header and then try</p>
+
+<p>ldattach -s 115200 -8 -n -1 tty /dev/ttyAMA0
+  echo &gt; /dev/ttyAMA0
+  cat /dev/ttyAMA0 | rngtest -c 10
+  cat /dev/ttyAMA0 | head -c 100000 | ent</p>
+
+<p>(the baud rate used with the R-Pi could probably be increased with a
+little hardware debugging effort).</p>
+
+<p>Which UART on the board that will receive the entropy is controlled
+by the sending of a newline to the UART ('echo &gt; /dev/ttyUSB0' and
+'echo &gt; /dev/ttyAMA0' in the examples above). The power on default is
+the USB UART.</p>
+
+<p>MODE_DELTAS is a quality assurance mode, and outputs the raw Timer IC
+values captured for analysis. The stand alone program in src/delta16/
+parses the data format used by MODE_DELTAS and can convert it to
+something you can analyse. More about how to do that later.</p>
+
+<h1>Contents</h1>
+
+<p>This documentation needs to be improved, but here are some quick notes:</p>
+
+<p>Hardware design (Eagle and PDF files) are in hardware/rev09/</p>
+
+<p>The firmware to extract entropy from this hardware is in src/entropy/</p>
+
+<p>There are additional firmwares to aid in debugging any hardware issues
+in src/led-test/ and src/uart-test/</p>
+
+<h1>Hardware</h1>
+
+<p>The avalanche noise circuit was first implemented using a NUCLEO-F401RE
+evaluation board that has an STM32F401RET6 MCU. Because of human error,
+the STM32F401RBT6 was used when assembling rev08 and rev09 boards. This
+chip has less flash and RAM, so some region mappings had to change.</p>
+
+<p>MCU dependant parameters are found in the top level common.mk near the
+top, read the comments regarding STDPERIPH_SETTINGS, MCU_LINKSCRIPT and
+SRCS.</p>
+
+<h1>STLINK</h1>
+
+<p>To program the MCU, an STLINK adapter is used. The cheapest way to get
+one is to buy an evaluation board with an STLINK integrated, and pinouts
+to program external chips. All the evaluation boards I've encountered
+from STM has this ability. I'm using an STLINK from an STM32F4DISCOVERY
+board, but the even cheaper NUCLEO-F401RE should work too. The NUCLEO
+one has a STLINK v2.1 which is probably, but not necessarily, supported
+by the OpenOCD version in your Linux distribution (as of end of 2014).</p>
+
+<p>The STLINK programming pins are the 1+4 throughole pads above the ARM
+on the circuit board. See the schematics for details, but the pinout
+from left to right (1, space, 4) of rev09 is</p>
+
+<p>NRST, space, CLK, IO, GND, VCC</p>
+
+<h1>Debugging the firmware</h1>
+
+<p>This site shows several ways to use various debuggers to debug the
+firmware in an STM32:</p>
+
+<p>http://fun-tech.se/stm32/OpenOCD/gdb.php</p>
+
+<p>I've only managed to get the most basic text line gdb to work,
+something along these lines:</p>
+
+<p>1) Start OpenOCD server (with a configuration file for your type of STLINK
+   adapter)</p>
+
+<p>$ openocd -f /usr/share/openocd/scripts/board/stm32f4discovery.cfg</p>
+
+<p>2) Connect to the OpenOCD server and re-flash already compiled firmware:</p>
+
+<p>$ telnet localhost 4444
+   reset halt
+   flash probe 0
+   stm32f2x mass_erase 0
+   flash write_bank 0 /path/to/main.bin 0
+   reset halt</p>
+
+<p>3) Start GDB and have it connect to the OpenOCD server:</p>
+
+<p>$ arm-none-eabi-gdb --eval-command="target remote localhost:3333" main.elf</p>
+
+<hr />
+
+<p>Fredrik Thulin <a href="mailto:fredrik@thulin.net">fredrik@thulin.net</a>, for the
+CrypTech project <a href="https://cryptech.is/">https://cryptech.is/</a>
+2015-01-14</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/ln5/stm32-avalanche-noise)]]
+
+| Clone `https://git.cryptech.is/user/ln5/stm32-avalanche-noise.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fln5%2Ftamper.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fln5%2Ftamper.md
new file mode 100644
index 0000000..7a3682c
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fln5%2Ftamper.md
@@ -0,0 +1,95 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Cryptech tamper detection</h1>
+
+<p>This is software for the Atmel AVR ATtiny828 MCU on the Cryptech alpha
+board, rev02, implementing tamper detection and master key erasure.</p>
+
+<h2>Overview</h2>
+
+<pre><code>   *************
+   * P A N I C *
+   *   button  *
+   *************
+    /
+   /
+  /
+AVR ---- SPI mux ---- FPGA
+            |          |
+            |         ARM
+           MKM
+
+AVR -- Atmel MCU
+FPGA -- FPGA
+MKM -- Master Key Memory, 23K640 SRAM
+SPI mux -- 2 x MC74AC244DW
+ARM -- ARM CPU
+</code></pre>
+
+<p>The MKM holds the master key for the device.</p>
+
+<p>The AVR, MKM and the mux are all battery powered.</p>
+
+<p>The AVR and the FPGA are both sharing access to the MKM through the
+mux, with the AVR connected to the pins used for deciding who's in
+control of the memory. If the AVR doesn't actively grab control of the
+MKM, the FPGA is in control.</p>
+
+<p>When the panic button is pressed, the AVR takes control over the MKM
+and writes zeros to it as quickly as possible. In idle mode, i.e. when
+the panic button is not pressed, the AVR tries to consume as little
+power as possible.</p>
+
+<h2>Building the software</h2>
+
+<p>To build a .hex file suitible for uploading to a board with a
+ATTiny828, a C compiler for AVR is needed, as wells a objcopy. On a
+Debian system, the following command can be used for installing both:</p>
+
+<pre><code>apt-get install gcc-avr binutils-avr avr-libc
+</code></pre>
+
+<p>To build tamper.hex, type 'make' in this directory.</p>
+
+<p>To upload a .hex file to a board, the program avrdude can be used. On
+a Debian system, the following command can be used for installing
+avrdude:</p>
+
+<pre><code>apt-get install avrdude
+</code></pre>
+
+<p>If configuration for ATtiny828 is missing, the file attiny828.conf in
+this directory could be appended to avrdude.conf:</p>
+
+<pre><code>cat attiny828.conf &gt;&gt; /etc/avrdude.conf
+</code></pre>
+
+<p>Often, a piece of hardware called "SPI programmer" is needed in order
+to upload the .hex file to the target system. The one I've been using
+has "sparkfun.com" printed on it. This small board has a mini-USB port
+to connect to a host system and a header with SPI pins to connect to a
+board with an AVR on it.</p>
+
+<p>To upload a .hex file to a board, use the upload.sh shell script in
+this directory with the name of the file as the only argument:</p>
+
+<pre><code>./upload.sh tamper.hex
+</code></pre>
+
+<p>Depending on permissions on your host system you might want to run the
+upload script as root.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/ln5/tamper)]]
+
+| Clone `https://git.cryptech.is/user/ln5/tamper.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fln5.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fln5.md
new file mode 100644
index 0000000..5583669
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fln5.md
@@ -0,0 +1,18 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/ln5/stm32-avalanche-noise| user/ln5/stm32-avalanche-noise]] |`https://git.cryptech.is/user/ln5/stm32-avalanche-noise.git` | [[wiki:GitRepositories/user/ln5/stm32-avalanche-noise| README]] |
+|[[source:/user/ln5/tamper| user/ln5/tamper]] |`https://git.cryptech.is/user/ln5/tamper.git` | [[wiki:GitRepositories/user/ln5/tamper| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fpaul%2Fhashsig-naive.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fpaul%2Fhashsig-naive.md
new file mode 100644
index 0000000..11a6bcc
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fpaul%2Fhashsig-naive.md
@@ -0,0 +1,31 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>hashsig-naive</h1>
+
+<p>Reference implementation of of the LMS Hash Based Signature Scheme from
+<code>draft-mcgrew-hash-sigs-10</code>.</p>
+
+<p>This is a naive implementation, which hews as closely as possible to the
+text of the draft, without any regard for performance (or security - keys
+are stored unencrypted in the local file system). It is intended to show
+that the draft can be implemented as written (except I found a few
+omissions in the text), and can interoperate with the official reference
+implementation at http://github.com/cisco/hash-sigs.</p>
+
+<p>The user interface is modeled on <code>demo.c</code> from the Cisco implementation,
+although all code was written independently.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/paul/hashsig-naive)]]
+
+| Clone `https://git.cryptech.is/user/paul/hashsig-naive.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fpaul.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fpaul.md
new file mode 100644
index 0000000..c57b15b
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fpaul.md
@@ -0,0 +1,18 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/paul/hashsig-naive| user/paul/hashsig-naive]] |`https://git.cryptech.is/user/paul/hashsig-naive.git` | [[wiki:GitRepositories/user/paul/hashsig-naive| README]] |
+|[[source:/user/paul/libcli| user/paul/libcli]] |`https://git.cryptech.is/user/paul/libcli.git` | |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fcurve25519_fpga_model.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fcurve25519_fpga_model.md
new file mode 100644
index 0000000..6b6a549
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fcurve25519_fpga_model.md
@@ -0,0 +1,63 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>curve25519_fpga_model</h1>
+
+<p>This reference model was written to help debug Verilog code. It comprises two parts: <strong>x25519_fpga_model</strong> and <strong>ed25519_fpga_model</strong>. See [1] for more information about the difference. The model mimics how an FPGA would do elliptic curve point scalar multiplication. Note, that the model may do weird (from CPU point of view, of course) things at times. Another important thing is that while FPGA modules are actually written to operate in constant-time manner, this model itself doesn't take any active measures to keep run-time constant. Do <strong>NOT</strong> use it in production as-is!</p>
+
+<p>Elliptic curve arithmetic can be split into several "layers":</p>
+
+<ol>
+<li>Low-level arithmetic</li>
+<li>Multi-precision arithmetic</li>
+<li>Modular arithmetic</li>
+<li>Curve arithmetic</li>
+</ol>
+
+<p><strong>Low-level arithmetic</strong> comprises elementary operations that the underlying hardware can do. These are typically 16-/32-/64-bit addition/subtraction and multiplication for conventional processors. Xilinx FPGA devices have specialized DSP slices that can do up to 48-bit addition/subtraction and up to 25x18-bit multiplication (latest 7 Series family at least).</p>
+
+<p><strong>Multi-precision arithmetic</strong> comprises operations on large (256-bit for this model) numbers using the elementary operations from layer 1.</p>
+
+<p><strong>Modular arithmetic</strong> comprises operations modulo certain prime based on layer 2. For this particualar model the prime is p = 2^255 - 19.</p>
+
+<p><strong>Curve arithmetic</strong> comprises addition and doubling of curve points and scalar multiplication based on the double-and-add algorithm.</p>
+
+<p>Levels 1-3 are the same for both X25519 and Ed25519. The trick used in layer 3 is that the model internally works modulo 2p (2^256-38), because it's computationally more efficient to not fully reduce the result until the very end of calculation. See "Special Reduction" in [2] for more information. Final reduction is done by simply adding zero modulo p.</p>
+
+<p>Conversion from the coordinate system used in layer 4 to affine coordinates involves modular inversion. Layer 3 offers modular inversion based on Fermat's little theorem. The addition chain used is from [3]. Thanks for reverse engineering Bernstein's "straightforward sequence of 254 squarings and 11 multiplications" :-P</p>
+
+<p>Modular inversion is offered in two variants: "abstract" (easy to debug user-friendly C code) and microcoded. The latter variant mimics how an FPGA does inversion.</p>
+
+<p>Layer 4 is different for X25519 and Ed25519.</p>
+
+<p>Curve arithmetic for Ed25519 uses Algorithm 4 ("Joye double-and-add") from [4] to do point multiplication. Point doubling is done according to "dbl-2008-hwcd" formulae from [5]. The only difference is that E, F, G &amp; H have opposite sign, this is equivalent to the original algorithm, because the final result depends on E * F and G * H. Point addition is done according to "add-2008-hwcd-4" from [5]. The coordinate system is (X, Y, Z, T), where T = X * Y. Conversion to affine coordinates is: x = X * Z^-1, y = Y * Z^-1. Note that the encoding of the result is somewhat tricky, see [6]. The short story is that we don't need to store entire X coordinate, just its sign is enough to recover X from Y.</p>
+
+<p>_TODO: Describe layer 4 for X25519._</p>
+
+<p>_TODO: Describe how microcode works._</p>
+
+<p>References:</p>
+
+<ol>
+<li><a href="https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures">StackExchange answer explaining the practical difference between Curve25519 and Ed25519</a></li>
+<li><a href="http://joppebos.com/files/waifi09.pdf">"High-Performance Modular Multiplication on the Cell Processor"</a></li>
+<li><a href="https://briansmith.org/ecc-inversion-addition-chains-01">"The Most Efficient Known Addition Chains for Field Element &amp; Scalar Inversion for the Most Popular &amp; Most Unpopular Elliptic Curves"</a></li>
+<li><a href="https://eprint.iacr.org/2011/338.pdf">"Fast and Regular Algorithms for Scalar Multiplication
+over Elliptic Curves"</a></li>
+<li><a href="https://hyperelliptic.org/EFD/g1p/auto-twisted-extended-1.html">"Extended coordinates with a=-1 for twisted Edwards curves"</a></li>
+<li><a href="https://crypto.stackexchange.com/questions/58921/decoding-a-ed25519-key-per-rfc8032">"decoding a Ed25519 key per RFC8032"</a></li>
+</ol>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/curve25519_fpga_model)]]
+
+| Clone `https://git.cryptech.is/user/shatov/curve25519_fpga_model.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdh_fpga_model.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdh_fpga_model.md
new file mode 100644
index 0000000..f6e771e
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdh_fpga_model.md
@@ -0,0 +1,40 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdh_model_fpga</h1>
+
+<p>This reference model was written to help debug Verilog code, it mimics how an FPGA would do elliptic curve point scalar multiplication for ECDH using curves P-256 and P-384. Note, that the model may do weird (from CPU point of view, of course) things at times. Another important thing is that while FPGA modules are actually written to operate in constant-time manner, this model itself doesn't take any active measures to keep run-time constant. Do <strong>NOT</strong> use it in production as-is!</p>
+
+<p>The model is split into 4 layers:</p>
+
+<ul>
+<li>Low-level primitives (32- and 48-bit adders, 32-bit subtractor, 16x16-bit multiplier, 48-bit accumulator)</li>
+<li>Utility routines (copier, comparator)</li>
+<li>Modular arithmetic (adder, subtractor, multiplier, invertor)</li>
+<li>EC arithmetic (adder, doubler, multiplier)</li>
+</ul>
+
+<p>Modular multiplier and invertor use complex algorithms and are thus further split into "helper" sub-routines.</p>
+
+<p>This model uses tips and tricks from the following sources:</p>
+
+<ol>
+<li><a href="http://diamond.boisestate.edu/~liljanab/MATH308/GuideToECC.pdf">Guide to Elliptic Curve Cryptography</a></li>
+<li><a href="https://www.iacr.org/archive/ches2008/51540064/51540064.pdf">Ultra High Performance ECC over NIST Primes
+on Commercial FPGAs</a></li>
+<li><a href="http://joppebos.com/files/CTInversion.pdf">Constant Time Modular Inversion</a></li>
+</ol>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/ecdh_fpga_model)]]
+
+| Clone `https://git.cryptech.is/user/shatov/ecdh_fpga_model.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa256.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa256.md
new file mode 100644
index 0000000..7d5003f
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa256.md
@@ -0,0 +1,103 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdsa256</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements the scalar base point multiplier for ECDSA curve P-256. It can be used during generation of public keys, the core can also be used as part of the signing operation. </p>
+
+<h2>API Specification</h2>
+
+<p>The core interface is similar to other Cryptech cores. FMC memory map looks like the following:</p>
+
+<p><code>0x0000 | NAME0</code>
+<code>0x0004 | NAME1</code>
+<code>0x0008 | VERSION</code></p>
+
+<p><code>0x0020 | CONTROL</code>
+<code>0x0024 | STATUS</code></p>
+
+<p><code>0x0080 | K0</code>
+<code>0x0084 | K1</code>
+<code>...</code>
+<code>0x009C | K7</code>
+<code>0x00A0 | X0</code>
+<code>0x00A4 | X1</code>
+<code>...</code>
+<code>0x00BC | X7</code>
+<code>0x00C0 | Y0</code>
+<code>0x00C4 | Y1</code>
+<code>...</code>
+<code>0x00DC | Y7</code></p>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong>
+Read-only core name ("ecdsa256").</p></li>
+<li><p><strong>VERSION</strong>
+Read-only core version, currently "0.11".</p></li>
+<li><p><strong>CONTROL</strong>
+Control register bits:
+[31:2] Don't care, always read as 0
+[1] "next" control bit
+[0] Don't care, always read as 0
+The core starts multiplication when the "next" control bit changes from 0 to 1. This way when the bit is set, the core will only perform one multiplication and then stop. To start another operation, the bit must be cleared at first and then set to 1 again.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only status register bits:
+[31:2] Don't care, always read as 0
+[1] "valid" control bit
+[0] "ready" control bit (always read as 1)
+The "valid" control bit is cleared as soon as the core starts operation, and gets set after the multiplication operations is complete. Note, that unlike some other Cryptech cores, this core doesn't need any special initialization, so the "ready" control bit is simply hardwired to always read as 1. This is to keep general core interface consistency.</p></li>
+<li><p><strong>K0</strong>-<strong>K7</strong>
+Buffer for the 256-bit multiplication factor (multiplier) K. The core will compute Q = K * G (the base point G is the multiplicand). K0 is the least significant 32-bit word of K, i.e. bits [31:0], while K7 is the most significant 32-bit word of K, i.e. bits [255:224].</p></li>
+<li><p><strong>X0</strong>-<strong>X7</strong>, <strong>Y0</strong>-<strong>Y7</strong>
+Buffers for the 256-bit coordinates X and Y of the product Q = K * G. Values are returned in affine coordinates. X0 and Y0 contain the least significant 32-bit words, i.e. bits [31:0], while X7 and Y7 contain the most significant 32-bit words, i.e. bits [255:224].</p></li>
+</ul>
+
+<h2>Implementation Details</h2>
+
+<p>The top-level core module contains block memory buffers for input and output operands and the base point multiplier, that reads from the input buffer and writes to the output buffers.</p>
+
+<p>The base point multiplier itself consists of the following:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Configurable "worker" unit</li>
+<li>Microprograms for the worker unit</li>
+<li>Multi-word mover unit</li>
+<li>Modular inversion unit</li>
+</ul>
+
+<p>The "worker" unit can execute five basic operations:</p>
+
+<ul>
+<li>comparison</li>
+<li>copying</li>
+<li>modular addition</li>
+<li>modular subtraction</li>
+<li>modular multiplications</li>
+</ul>
+
+<p>There are two primary microprograms, that the worker runs: curve point doubling and addition of curve point to the base point. Those microprograms use projective Jacobian coordinates, so one more microprogram is used to convert the product into affine coordinates with the help of modular inversion unit.</p>
+
+<p>Note, that the core is supplemented by a reference model written in C, that has extensive comments describing tricky corners of the underlying math.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>Cryptech Alpha platform is based on Xilinx Artix-7 200T FPGA, so this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/lowlevel/artix7, the core also offers generic replacements under /rtl/lowlevel/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. Selection of vendor/generic primitives is done in ecdsa_lowlevel_settings.v, when porting to other architectures, only those four low-level modules need to be ported.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/ecdsa256)]]
+
+| Clone `https://git.cryptech.is/user/shatov/ecdsa256.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa384.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa384.md
new file mode 100644
index 0000000..f684cec
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa384.md
@@ -0,0 +1,105 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdsa384</h1>
+
+<h2>Core Description</h2>
+
+<p>This core implements the scalar base point multiplier for ECDSA curve P-384. It can be used during generation of public keys, the core can also be used as part of the signing operation. </p>
+
+<h2>API Specification</h2>
+
+<p>The core interface is similar to other Cryptech cores. FMC memory map looks like the following:</p>
+
+<p><code>0x0000 | NAME0</code>
+<code>0x0004 | NAME1</code>
+<code>0x0008 | VERSION</code></p>
+
+<p><code>0x0020 | CONTROL</code>
+<code>0x0024 | STATUS</code></p>
+
+<p><code>0x0100 | K0</code>
+<code>0x0104 | K1</code>
+<code>...</code>
+<code>0x012C | K11</code></p>
+
+<p><code>0x0140 | X0</code>
+<code>0x0144 | X1</code>
+<code>...</code>
+<code>0x017C | X11</code></p>
+
+<p><code>0x0180 | Y0</code>
+<code>0x0184 | Y1</code>
+<code>...</code>
+<code>0x01AC | Y11</code></p>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong>
+Read-only core name ("ecdsa384").</p></li>
+<li><p><strong>VERSION</strong>
+Read-only core version, currently "0.11".</p></li>
+<li><p><strong>CONTROL</strong>
+Control register bits:
+[31:2] Don't care, always read as 0
+[1] "next" control bit
+[0] Don't care, always read as 0
+The core starts multiplication when the "next" control bit changes from 0 to 1. This way when the bit is set, the core will only perform one multiplication and then stop. To start another operation, the bit must be cleared at first and then set to 1 again.</p></li>
+<li><p><strong>STATUS</strong>
+Read-only status register bits:
+[31:2] Don't care, always read as 0
+[1] "valid" control bit
+[0] "ready" control bit (always read as 1)
+The "valid" control bit is cleared as soon as the core starts operation, and gets set after the multiplication operations is complete. Note, that unlike some other Cryptech cores, this core doesn't need any special initialization, so the "ready" control bit is simply hardwired to always read as 1. This is to keep general core interface consistency.</p></li>
+<li><p><strong>K0</strong>-<strong>K11</strong>
+Buffer for the 384-bit multiplication factor (multiplier) K. The core will compute Q = K * G (the base point G is the multiplicand). K0 is the least significant 32-bit word of K, i.e. bits [31:0], while K11 is the most significant 32-bit word of K, i.e. bits [383:352].</p></li>
+<li><p><strong>X0</strong>-<strong>X11</strong>, <strong>Y0</strong>-<strong>Y11</strong>
+Buffers for the 384-bit coordinates X and Y of the product Q = K * G. Values are returned in affine coordinates. X0 and Y0 contain the least significant 32-bit words, i.e. bits [31:0], while X11 and Y11 contain the most significant 32-bit words, i.e. bits [383:352].</p></li>
+</ul>
+
+<h2>Implementation Details</h2>
+
+<p>The top-level core module contains block memory buffers for input and output operands and the base point multiplier, that reads from the input buffer and writes to the output buffers.</p>
+
+<p>The base point multiplier itself consists of the following:</p>
+
+<ul>
+<li>Buffers for storage of temporary values</li>
+<li>Configurable "worker" unit</li>
+<li>Microprograms for the worker unit</li>
+<li>Multi-word mover unit</li>
+<li>Modular inversion unit</li>
+</ul>
+
+<p>The "worker" unit can execute five basic operations:</p>
+
+<ul>
+<li>comparison</li>
+<li>copying</li>
+<li>modular addition</li>
+<li>modular subtraction</li>
+<li>modular multiplications</li>
+</ul>
+
+<p>There are two primary microprograms, that the worker runs: curve point doubling and addition of curve point to the base point. Those microprograms use projective Jacobian coordinates, so one more microprogram is used to convert the product into affine coordinates with the help of modular inversion unit.</p>
+
+<p>Note, that the core is supplemented by a reference model written in C, that has extensive comments describing tricky corners of the underlying math.</p>
+
+<h2>Vendor-specific Primitives</h2>
+
+<p>Cryptech Alpha platform is based on Xilinx Artix-7 200T FPGA, so this core takes advantage of Xilinx-specific DSP slices to carry out math-intensive operations. All vendor-specific math primitives are placed under /rtl/lowlevel/artix7, the core also offers generic replacements under /rtl/lowlevel/generic, they can be used for simulation with 3rd party tools, that are not aware of Xilinx-specific stuff. Selection of vendor/generic primitives is done in ecdsa_lowlevel_settings.v, when porting to other architectures, only those four low-level modules need to be ported.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/ecdsa384)]]
+
+| Clone `https://git.cryptech.is/user/shatov/ecdsa384.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa_fpga_model.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa_fpga_model.md
new file mode 100644
index 0000000..4df7c6a
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fecdsa_fpga_model.md
@@ -0,0 +1,40 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ecdsa_model_fpga</h1>
+
+<p>This reference model was written to help debug Verilog code, it mimics how an FPGA would do elliptic curve base point scalar multiplication for ECDSA curves P-256 and P-384. Note, that the model may do weird (from CPU point of view, of course) things at times. Another important thing is that while FPGA modules are actually written to operate in constant-time manner, this model itself doesn't take any active measures to keep run-time constant. Do <strong>NOT</strong> use it in production as-is!</p>
+
+<p>The model is split into 4 layers:</p>
+
+<ul>
+<li>Low-level primitives (32- and 48-bit adders, 32-bit subtractor, 16x16-bit multiplier, 48-bit accumulator)</li>
+<li>Utility routines (copier, comparator)</li>
+<li>Modular arithmetic (adder, subtractor, multiplier, invertor)</li>
+<li>EC arithmetic (adder, doubler, multiplier)</li>
+</ul>
+
+<p>Modular multiplier and invertor use complex algorithms and are thus further split into "helper" sub-routines.</p>
+
+<p>This model uses tips and tricks from the following sources:</p>
+
+<ol>
+<li><a href="http://diamond.boisestate.edu/~liljanab/MATH308/GuideToECC.pdf">Guide to Elliptic Curve Cryptography</a></li>
+<li><a href="https://www.iacr.org/archive/ches2008/51540064/51540064.pdf">Ultra High Performance ECC over NIST Primes
+on Commercial FPGAs</a></li>
+<li><a href="http://joppebos.com/files/CTInversion.pdf">Constant Time Modular Inversion</a></li>
+</ol>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/ecdsa_fpga_model)]]
+
+| Clone `https://git.cryptech.is/user/shatov/ecdsa_fpga_model.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Ffmc-test.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Ffmc-test.md
new file mode 100644
index 0000000..8778f6f
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Ffmc-test.md
@@ -0,0 +1,25 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>fmc-test</h1>
+
+<p>Demo program for stm32-dev-bridge board to test FMC arbiter in Novena's
+on-board FPGA.</p>
+
+<p>Current issues:
+ * SystemClock_Config() currently uses 16 MHz HSI oscillator as PLL input,
+this should be changed to 25 MHz crystal later.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/fmc-test)]]
+
+| Clone `https://git.cryptech.is/user/shatov/fmc-test.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fgost.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fgost.md
new file mode 100644
index 0000000..9f9a35b
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fgost.md
@@ -0,0 +1,18 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/shatov/gost/streebog_tester| user/shatov/gost/streebog_tester]] |`https://git.cryptech.is/user/shatov/gost/streebog_tester.git` | |
+|[[source:/user/shatov/gost/streebog| user/shatov/gost/streebog]] |`https://git.cryptech.is/user/shatov/gost/streebog.git` | |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexp_fpga_model.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexp_fpga_model.md
new file mode 100644
index 0000000..0030940
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexp_fpga_model.md
@@ -0,0 +1,30 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>modexp_fpga_model</h1>
+
+<p>This reference model was written to help debug Verilog code, it mimics how an FPGA would do modular exponentiation using systolic Montgomery multiplier. Note, that the model may do weird (from CPU point of view, of course) things at times. Another important thing is that while FPGA modules are written to operate in true constant-time manner, this model itself doesn't take any active measures to keep run-time constant. Do <strong>NOT</strong> use it in production as-is!</p>
+
+<p>The model is split into low-level primitives (32-bit adder, 32-bit subtractor, 32x32-bit multiplier with pre-adder) and higher-level arithmetic routines (multiplier and exponentiator).</p>
+
+<p>This model uses tips and tricks from the following sources:</p>
+
+<ol>
+<li><a href="ftp://ftp.rsasecurity.com/pub/pdfs/tr201.pdf">High-Speed RSA Implementation</a></li>
+<li><a href="http://cacr.uwaterloo.ca/hac/">Handbook of Applied Cryptography</a></li>
+<li><a href="https://www.hindawi.com/journals/ijrc/2011/127147/">Montgomery Modular Multiplication on Reconfigurable Hardware: Systolic versus Multiplexed Implementation</a></li>
+</ol>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/modexp_fpga_model)]]
+
+| Clone `https://git.cryptech.is/user/shatov/modexp_fpga_model.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexpng.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexpng.md
new file mode 100644
index 0000000..2476644
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexpng.md
@@ -0,0 +1,214 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>ModExpNG</h1>
+
+<h2>Core Description</h2>
+
+<p>This "next-generation" IP core implements the modular exponentiation math primitive using the specialized DSP slices present in the Artix-7 FPGA found on the CrypTech Alpha board. It can be used during RSA operations such as encryption/decryption and signing. Given a pair of blinding factors, the core internally blinds the message before signing and then unblinds it afterwards. The blinding factors are automatically mutated during each exponentiation for later reuse. Another prominent feature is the full support for Chinese Remainder Theorem. Given smaller moduli P and Q, the core can do the mixed-radix conversion variant of the algorithm ("Garner's formula") for faster computation. Due to limitations of the underlying hardware (primarily the capacity of the BlockRAM tile in the 7-Series Xilinx devices) the largest supported key length is 4096 bits.</p>
+
+<h2>Compile-Time Settings</h2>
+
+<p>The core has one synthesis-time parameter:</p>
+
+<ul>
+<li><strong>NUM_MULTS</strong> - Sets the number of DSP slices to use per modular multiplier, which must be a power of 2. Each multiplier consumes NUM_MULTS + 1 slices, since one additional multiplier is required to eliminate the final conditional subtraction step of the Montgomery modular multiplication routine. The core internally consists of a pair of <em>dual modular multipliers</em>, thus the total number of occupied DSP slices is 4 * (NUM_MULTS + 1). When in CRT mode, both <em>dual multipliers</em> operate simultaneously, each with its own modulus. The two multipliers inside of the <em>dual multiplier</em> simultaneously do the squaring and multiplication operations, which constitute one step of the Montgomery powering ladder.</li>
+</ul>
+
+<p>Combined DSP slice utilization is outlined in the following table:</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead>              <tr><th> NUM_MULTS </th><th> DSP Usage </th></tr></thead>
+<tbody align="right"><tr><td>         8 </td><td>        36 </td></tr></tbody>
+<tbody align="right"><tr><td>        16 </td><td>        68 </td></tr></tbody>
+<tbody align="right"><tr><td>        32 </td><td>       132 </td></tr></tbody>
+<tbody align="right"><tr><td>        64 </td><td>       260 </td></tr></tbody>
+</table>
+
+<p>Currently the core has been tested in hardware with a balanced setting of NUM_MULTS = 8. Larger values should decreate latency, but proportionally increase DSP slice usage. The core takes advantage of the dedicated high-speed cascade paths between DSP slices, thus all the NUM_MULTS slices must be placed in the same DSP column. Given that the column height for the Artix-7 FPGA is 100 DSP slices, the upper limit on NUM_MULTS is 64. This has not been yet tested in hardware and may require floorplanning or additional operand "broadcast" tree, which is a topic for future research.</p>
+
+<h2>API Specification</h2>
+
+<p>The interface of the core is similar to other CrypTech cores. FMC memory map is split into four regions (REGISTERS, INPUT_0, INPUT_1 and OUTPUT), each region is 32 kilobits (4 kilobytes). The first one (REGISTERS) contains core registers and looks like the following:</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup>
+<thead><tr><th colspan=2> REGISTERS Memory Map </th></tr></thead>
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead><tr><th> Offset </th><th> Register      </th></tr></thead>
+<tbody><tr><td> 0x0000 </td><td> NAME0         </td></tr></tbody>
+<tbody><tr><td> 0x0004 </td><td> NAME1         </td></tr></tbody>
+<tbody><tr><td> 0x0008 </td><td> VERSION       </td></tr></tbody>
+<tbody><tr><td> 0x0020 </td><td> CONTROL       </td></tr></tbody>
+<tbody><tr><td> 0x0024 </td><td> STATUS        </td></tr></tbody>
+<tbody><tr><td> 0x0040 </td><td> MODE          </td></tr></tbody>
+<tbody><tr><td> 0x0044 </td><td> MODULUS_BITS  </td></tr></tbody>
+<tbody><tr><td> 0x0048 </td><td> EXPONENT_BITS </td></tr></tbody>
+<tbody><tr><td> 0x004C </td><td> BANK_BITS     </td></tr></tbody>
+<tbody><tr><td> 0x0050 </td><td> NUM_MULTS     </td></tr></tbody>
+</table>
+
+<p>The core has the following registers:</p>
+
+<ul>
+<li><p><strong>NAME0</strong>, <strong>NAME1</strong></p>
+
+<p>Read-only core name ("<code>mode</code>", "<code>xpng</code>").</p></li>
+<li><p><strong>VERSION</strong></p>
+
+<p>Read-only core version, currently "<code>0.10</code>".</p></li>
+<li><p><strong>CONTROL</strong></p>
+
+<p>Register bits: <br />
+<code>[31:2]</code> Don't care, always read as 0 <br />
+<code>[1]</code> "<strong>next</strong>" control bit <br />
+<code>[0]</code> Don't care, always read as 0</p>
+
+<p>The "<strong>next</strong>" control bit is used to start an exponentiation. The core is edge-triggered, this way if the bit is currently set, it must be cleared first and then set to 1 again to start a new exponentiation.</p></li>
+<li><p><strong>STATUS</strong></p>
+
+<p>Read-only register bits: <br />
+<code>[31:2]</code> Don't care, always read as 0 <br />
+<code>[1]</code> "<strong>valid</strong>" status bit <br />
+<code>[0]</code> "<strong>ready</strong>" status bit, always read as 1  </p>
+
+<p>The "<strong>valid</strong>" status bit is cleared as soon as the core starts exponentiation, and gets set after the operation is finished.</p></li>
+<li><p><strong>MODE</strong></p>
+
+<p>Mode register bits: <br />
+<code>[31:2]</code> Don't care, always read as 0 <br />
+<code>[1]</code> "<strong>CRT enable</strong>" control bit <br />
+<code>[0]</code> Don't care, always read as 0  </p>
+
+<p>The "<strong>CRT enable</strong>" control bit allows the core to take advantage of the Chinese remainder theorem to speed up RSA operations.</p></li>
+<li><p><strong>MODULUS_BITS</strong></p>
+
+<p>Length of modulus in bits. Smallest allowed value is 64 * NUM_MULTS (currently 64 * 8 = 512), largest allowed value is 4096. The core rounds MODULUS_BITS down to the nearest multiple of 32 * NUM_MULTS (currently 32 * 8 = 256). Thus, allowed key lengths are 512, 768, 1024, 1280, ..., 4096. If the modulus is eg. 1000 bits wide, MODULUS_BITS must be set to 1024 and the modulus must be prepended with 24 zero bits to match the allowed length. Always set this to the length of the public key, do not use twice smaller value when CRT is enabled, the core automatically takes care of that.</p></li>
+<li><p><strong>EXPONENT_BITS</strong></p>
+
+<p>Length of exponent in bits. Smallest allowed value is 4, largest allowed value is 4096.</p></li>
+<li><p><strong>BANK_BITS</strong></p>
+
+<p>Length of operand bank in bits. This read-only parameter returns the length of internal operand bank and allows the largest supported operand width to be determined at run-time. Currently BANK_BITS is hardwired to always return 4096.</p></li>
+<li><p><strong>NUM_MULTS</strong></p>
+
+<p>This read-only parameter returns the width of the internal parallel multiplier, that was specified at compile-time. This parameter is currently 8.</p></li>
+</ul>
+
+<p>The two following memory regions (INPUT_0 and INPUT_1) contain input quantities, each region is split into eight banks, each bank is 4096 bits (512 bytes). The least significat byte of an input quantity should be written to offset 0 in a bank, i.e. one should start filling banks by writing the least significant word at the lowest offset.</p>
+
+<p>The second region (INPUT_0) contains the following banks:</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup>
+<thead><tr><th colspan=2> INPUT_0 Memory Map </th></tr></thead>
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead><tr><th> Offset </th><th> Bank     </th></tr></thead>
+<tbody><tr><td> 0x1000 </td><td> M        </td></tr></tbody>
+<tbody><tr><td> 0x1200 </td><td> N        </td></tr></tbody>
+<tbody><tr><td> 0x1400 </td><td> N_FACTOR </td></tr></tbody>
+<tbody><tr><td> 0x1600 </td><td> N_COEFF  </td></tr></tbody>
+<tbody><tr><td> 0x1A00 </td><td> X        </td></tr></tbody>
+<tbody><tr><td> 0x1C00 </td><td> Y        </td></tr></tbody>
+</table>
+
+<ul>
+<li><p><strong>M</strong> is the message to be signed (base).</p></li>
+<li><p><strong>N</strong> is the modulus (public key).</p></li>
+<li><p><strong>N_FACTOR</strong> is the <strong>N</strong> Montgomery factor and must be precomputed (described later).</p></li>
+<li><p><strong>N_COEFF</strong> is the <strong>N</strong> modulus-dependent speed-up coefficient and must be precomputed (described later). Note, that the bank for <strong>N_COEFF</strong> is twice larger than normal banks.</p></li>
+<li><p>(<strong>X</strong>, <strong>Y</strong>) are a pair of blinding factors. Blinding is always enabled, there's no way to disable it, thus a pair of blinding factors is required for exponentiation. Note, that a pair of (<strong>X</strong>, <strong>Y</strong>) = (1, 1) works just fine, but you effectively aren't doing any blinding this way. The message is blinded using <strong>Y</strong> and unblinded using <strong>X</strong>, thus the relationship between the two must be <strong>Y = (X ** -1) ** e</strong>. Note, that this scheme won't work for encryption, either a pair of (1, 1) must be used, or <strong>X</strong> and <strong>Y</strong> must be swapped. The overhead form blinding is four additional modular multiplications (two to blind-unblind the message and two to mutate the blinding factors) which is &lt;1% for 1024-bit keys and even lower for longer keys.</p></li>
+</ul>
+
+<p>The third region (INPUT_1) contains the following banks. Note, that since the third region contains secret components, it is "write-only", any reads from the region will return 0xDEADCODE.</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup>
+<thead><tr><th colspan=2> INPUT_1 Memory Map </th></tr></thead>
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead><tr><th> Offset </th><th> Bank     </th></tr></thead>
+<tbody><tr><td> 0x2000 </td><td> D        </td></tr></tbody>
+<tbody><tr><td> 0x2200 </td><td> P        </td></tr></tbody>
+<tbody><tr><td> 0x2300 </td><td> DP       </td></tr></tbody>
+<tbody><tr><td> 0x2400 </td><td> P_FACTOR </td></tr></tbody>
+<tbody><tr><td> 0x2600 </td><td> P_COEFF  </td></tr></tbody>
+<tbody><tr><td> 0x2800 </td><td> Q        </td></tr></tbody>
+<tbody><tr><td> 0x2900 </td><td> DQ       </td></tr></tbody>
+<tbody><tr><td> 0x2A00 </td><td> Q_FACTOR </td></tr></tbody>
+<tbody><tr><td> 0x2C00 </td><td> Q_COEFF  </td></tr></tbody>
+<tbody><tr><td> 0x2E00 </td><td> QINV     </td></tr></tbody>
+</table>
+
+<ul>
+<li><p><strong>D</strong> is the exponent (secret exponent for signing, F4 is commonly used for encryption).</p></li>
+<li><p><strong>P</strong>, <strong>Q</strong> are the smaller moduli, they must be supplied when CRT mode is enabled. Note, that their banks are twice smaller than normal banks.</p></li>
+<li><p><strong>DP</strong>, <strong>DQ</strong> are private key components, they must be supplied when CRT mode is enabled. Note, that their banks are twice smaller than normal banks.</p></li>
+<li><p><strong>P_FACTOR</strong>, <strong>Q_FACTOR</strong> are the <strong>P</strong> and <strong>Q</strong> Montgomery factors and must be precomputed (described later).</p></li>
+<li><p><strong>P_COEFF</strong>, <strong>Q_COEFF</strong> are the <strong>P</strong> and <strong>Q</strong> moduli-dependent speed-up coefficients and must be precomputed (described later).</p></li>
+<li><p><strong>QINV</strong> is the private key compoment, it must be supplided when CRT mode is enabled.</p></li>
+</ul>
+
+<p>The fourth region (OUTPUT) contains three banks where the core will store the output quantities:</p>
+
+<table border rules="groups" cellpadding="5">
+<colgroup><col></colgroup>
+<thead><tr><th colspan=2> OUTPUT Memory Map </th></tr></thead>
+<colgroup><col></colgroup><colgroup><col></colgroup>
+<thead><tr><th> Offset </th><th> Bank </th></tr></thead>
+<tbody><tr><td> 0x3000 </td><td> S    </td></tr></tbody>
+<tbody><tr><td> 0x3200 </td><td> XM   </td></tr></tbody>
+<tbody><tr><td> 0x3400 </td><td> YM   </td></tr></tbody>
+</table>
+
+<ul>
+<li><p><strong>S</strong> is the signature (or ciphertext after encryption).</p></li>
+<li><p>(<strong>XM</strong>, <strong>YM</strong>) are a pair of mutated blinding factors.</p></li>
+</ul>
+
+<h2>Montgomery Factors and Modulus-dependent Speed-up Coefficients</h2>
+
+<p>The core uses the Montgomery modular multiplier, which can only operate on numbers in the so called Montgomery domain. Bringing input numbers into Montgomery domain and converting output numbers out of Montgomery domain requires a special quantity called Montgomery factor: <strong>FACTOR</strong> = 2 ** (2 * (<strong>MODULUS_BITS</strong> + <strong>WORD_WIDTH</strong>)) mod <strong>N</strong>. This quantity has at most as many bits as the modulus and should be precomputed during key generation. The core's internal data buses are 16-bit wide, so for the formula above <strong>WORD_WIDTH</strong> = 16. The following pseudocode calculates the Montgomery factor given modulus <strong>N</strong>:</p>
+
+<pre><code>F = 1
+for i from 0 to 2 * (MODULUS_BITS + 16) - 1
+    F1 = F &lt;&lt; 1
+    F2 = F1 - N
+    F = (F2 &lt; 0) ? F1 : F2
+return F
+</code></pre>
+
+<p>The final step of Montgomery modular multiplication is Montgomery modular reduction. It is done by adding a multiple of the modulus to the intermediate product. The multiple is selected in such a way, that the lower half of the sum is all zero bits, so it can be safely reduced by just a trivial right shift. This speeds things up, since there's no more need to do computationally difficult division anymore. To determine the multiple of the modulus, another quantity is required, which is the so called modulus-dependent speed-up coefficient: <strong>COEFF</strong> = -<strong>N</strong> ** -1 mod 2 ** (<strong>MODULUS_BITS</strong> + <strong>WORD_WIDTH</strong>). The number of bits needed to store the coefficient exceeds the width of the modulus by one word. The core internally operates on 16-bit words, so the coefficient is wider than the modulus by two bytes. This non-obvious and somewhat inconvenient feature is required to skip the final conditional subtraction step of the "classic" Montgomery modular reduction. Since a selected multiple of the modulus is <em>added</em> to the intermediate product, the result after shifting it to the right can exceed the modulus, so the traditional solution is to do a conditional subtraction as the very last step. The more precise analysis indicates, that the conditional subtraction can be eliminated, if the main loop of the reduction is repeated for at least three additional times, i.e. <strong>MODULUS_BITS</strong> + 3 total iterations. The model operates on entire words internally, so it can only do <strong>MODULUS_BITS</strong> + <strong>WORD_WIDTH</strong> iterations and thus needs 16 extra bits of the speed-up factor. The following pseudocode calculates the modulus-dependent speed-up coefficient:</p>
+
+<pre><code>R = 1
+B = 1
+NN = ~N + 1
+for i from 1 to (MODULUS_BITS + 16 - 1)
+    B = B &lt;&lt; 1
+    T = R * NN mod 2 ** (MODULUS_BITS + 16)
+    if T[i] then
+        R = R + B
+return R
+</code></pre>
+
+<p>The <code>stm32/modexpng_util.c</code> file also has reference C code, that computes the Montgomery factor and the speed-up coeficient. Note that each keypair ideally requires three pairs of precomputed numbers: one for the public key <strong>N</strong> and one for each of the smaller secret moduli <strong>P</strong> and <strong>Q</strong>.</p>
+
+<h2>References</h2>
+
+<ol>
+<li><a href="https://eprint.iacr.org/2017/1115.pdf">Hardware Aspects of Montgomery Modular Multiplication</a></li>
+</ol>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/modexpng)]]
+
+| Clone `https://git.cryptech.is/user/shatov/modexpng.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexpng_fpga_model.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexpng_fpga_model.md
new file mode 100644
index 0000000..8b011c1
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fmodexpng_fpga_model.md
@@ -0,0 +1,22 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>modexpng_fpga_model</h1>
+
+<p>Math model of ModExpNG IP core. The model mimics how an FPGA does modular exponentiation.</p>
+
+<p>First use the scripts from the <code>vector/</code> folder to generate and format a keypair vector, then edit the <i>DUMP_*</i> switches in <code>modexpng_fpga_model.py</code> to dump the desired internal values. The <i>FORCE_OVERFLOW</i> setting artificially forces the virtually neven seen internal interim overflow situation and allows its handler to be tested. You can also un-comment the _#c.dump_banks()_ line and move it anywhere within _sign_using_crt()_ and/or _sign_without_crt()_ to dump the contents of entire core's memory.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/modexpng_fpga_model)]]
+
+| Clone `https://git.cryptech.is/user/shatov/modexpng_fpga_model.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fnovena-fmc-arbiter.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fnovena-fmc-arbiter.md
new file mode 100644
index 0000000..d402fb8
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov%2Fnovena-fmc-arbiter.md
@@ -0,0 +1,33 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>novena-fmc</h1>
+
+<p>FMC interface arbiter for Novena's on-board Spartan-6 FPGA.</p>
+
+<p>This demo project has one 32-bit test register instead of core selection logic.</p>
+
+<p>Important things to note:</p>
+
+<ul>
+<li><p>Width of address bus is now parametrized (bridge board has 22 address lines),
+this way it will be easy to change it in the future (when time comes to
+configure Alpha for the first time).</p></li>
+<li><p>Clock manager no longer uses an IP core, instead of this clkmgr_dcm_new.v
+now directly instantiates DCM_SP primitive. Clock frequency can be changed by
+tweaking CLK_OUT_MUL and CLK_OUT_DIV parameters.</p></li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=user/shatov/novena-fmc-arbiter)]]
+
+| Clone `https://git.cryptech.is/user/shatov/novena-fmc-arbiter.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov.md
new file mode 100644
index 0000000..d7ae757
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fshatov.md
@@ -0,0 +1,32 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/shatov/ModExpA7| user/shatov/ModExpA7]] |`https://git.cryptech.is/user/shatov/ModExpA7.git` | |
+|[[source:/user/shatov/alpha_rev04| user/shatov/alpha_rev04]] |`https://git.cryptech.is/user/shatov/alpha_rev04.git` | |
+|[[source:/user/shatov/curve25519_fpga_model| user/shatov/curve25519_fpga_model]] |`https://git.cryptech.is/user/shatov/curve25519_fpga_model.git` | [[wiki:GitRepositories/user/shatov/curve25519_fpga_model| README]] |
+|[[source:/user/shatov/ecdh_fpga_model| user/shatov/ecdh_fpga_model]] |`https://git.cryptech.is/user/shatov/ecdh_fpga_model.git` | [[wiki:GitRepositories/user/shatov/ecdh_fpga_model| README]] |
+|[[source:/user/shatov/ecdsa256| user/shatov/ecdsa256]] |`https://git.cryptech.is/user/shatov/ecdsa256.git` | [[wiki:GitRepositories/user/shatov/ecdsa256| README]] |
+|[[source:/user/shatov/ecdsa384| user/shatov/ecdsa384]] |`https://git.cryptech.is/user/shatov/ecdsa384.git` | [[wiki:GitRepositories/user/shatov/ecdsa384| README]] |
+|[[source:/user/shatov/ecdsa_fpga_model| user/shatov/ecdsa_fpga_model]] |`https://git.cryptech.is/user/shatov/ecdsa_fpga_model.git` | [[wiki:GitRepositories/user/shatov/ecdsa_fpga_model| README]] |
+|[[source:/user/shatov/fmc-test| user/shatov/fmc-test]] |`https://git.cryptech.is/user/shatov/fmc-test.git` | [[wiki:GitRepositories/user/shatov/fmc-test| README]] |
+|[[source:/user/shatov/gost/streebog_tester| user/shatov/gost/streebog_tester]] |`https://git.cryptech.is/user/shatov/gost/streebog_tester.git` | |
+|[[source:/user/shatov/gost/streebog| user/shatov/gost/streebog]] |`https://git.cryptech.is/user/shatov/gost/streebog.git` | |
+|[[source:/user/shatov/modexp_fpga_model| user/shatov/modexp_fpga_model]] |`https://git.cryptech.is/user/shatov/modexp_fpga_model.git` | [[wiki:GitRepositories/user/shatov/modexp_fpga_model| README]] |
+|[[source:/user/shatov/modexpng_fpga_model| user/shatov/modexpng_fpga_model]] |`https://git.cryptech.is/user/shatov/modexpng_fpga_model.git` | [[wiki:GitRepositories/user/shatov/modexpng_fpga_model| README]] |
+|[[source:/user/shatov/modexpng| user/shatov/modexpng]] |`https://git.cryptech.is/user/shatov/modexpng.git` | [[wiki:GitRepositories/user/shatov/modexpng| README]] |
+|[[source:/user/shatov/novena-fmc-arbiter| user/shatov/novena-fmc-arbiter]] |`https://git.cryptech.is/user/shatov/novena-fmc-arbiter.git` | [[wiki:GitRepositories/user/shatov/novena-fmc-arbiter| README]] |
+|[[source:/user/shatov/stm32_n25q128| user/shatov/stm32_n25q128]] |`https://git.cryptech.is/user/shatov/stm32_n25q128.git` | |
+|[[source:/user/shatov/stm32_sdram| user/shatov/stm32_sdram]] |`https://git.cryptech.is/user/shatov/stm32_sdram.git` | |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Faes-keywrap.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Faes-keywrap.md
new file mode 100644
index 0000000..32485ba
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Faes-keywrap.md
@@ -0,0 +1,44 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>AES key wrap</h1>
+
+<p>A preliminary implementation of AES Key Wrap, RFC 5649 flavor, using
+Cryptlib to supply the AES ECB transformations.</p>
+
+<p>aes_keywrap.py contains two different Python implementations:</p>
+
+<ol>
+<li><p>An implementation using Python longs as 64-bit integers; and</p></li>
+<li><p>An implementation using Python arrays.</p></li>
+</ol>
+
+<p>The first of these is the easiest to understand, as it can just do
+(long) integer arithmetic and follow the specification very closely.
+The second is closer to what one would do to implement this in an
+assembly language like C.</p>
+
+<p>aes_keywrap.[ch] is a C implementation.  The API for this is not yet
+set in stone.</p>
+
+<p>All three implementations include test vectors.</p>
+
+<p>The two implementations based on byte arrays use shift and mask
+operations to handle the two numerical values ("m" and "t") which
+require byte swapping on little endian hardware; this is not the most
+efficient implementation possible, but it's portable, and will almost
+certainly be lost in the noise under the AES operations.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/sra/aes-keywrap)]]
+
+| Clone `https://git.cryptech.is/user/sra/aes-keywrap.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Faes_merged.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Faes_merged.md
new file mode 100644
index 0000000..2a48725
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Faes_merged.md
@@ -0,0 +1,87 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>aes_speed</h1>
+
+<p>Speed optimized Verilog implementation of the symmetric block cipher AES
+(Advanced Encryption Standard) as specified in the NIST document <a href="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf">FIPS
+197</a>.</p>
+
+<p>This core is modified version of the Cryptech AES core. Note that the
+name of the core modules are identical to that core. The purpose of this
+is to allow a drop-in replacement in Cryptech designs.</p>
+
+<h2>Status</h2>
+
+<p>Second round of optimizations done. Core similates correctly. Core has
+been implemented in FPGA, but not functionally tested in real HW.</p>
+
+<h2>Introduction</h2>
+
+<p>This implementation supports 128 and 256 bit keys. The
+implementation is iterative and process one 128 block at a time.</p>
+
+<p>The encipher and decipher block processing datapaths are separated and
+basically self contained given access to a set of round keys and a
+block. This makes it possible to hard wire either encipher or decipher
+and allow the build tools to optimize away the other functionality which
+will reduce the size to about 50%. For cipher modes such as CTR, GCM
+decryption in the AES core will never be used and thus the decipher
+block processing can be removed.</p>
+
+<p>The core has been equipped with 16 S-boxes for encipher and 16 Inverse
+S-boxes for decipher. This allows the core to perform the SubBytes and
+InverseSubBytes operations in the AES round functions in one cycle.</p>
+
+<p>The key expansion does not share S-boxes with the encipher datapath, so
+the total number of S-boxes is 40.</p>
+
+<h2>Performance comparison</h2>
+
+<p>Number of cycles for the old Cryptech AES core:</p>
+
+<ul>
+<li>AES-128 Encipher one block with key expansion: 57</li>
+<li>AES-256 Decipher one block with key expansion: 77</li>
+</ul>
+
+<p>Number of cycles for the Cryptech AES speed core:</p>
+
+<ul>
+<li>AES-128 Encipher one block with key expansion: 16</li>
+<li>AES-255 Decipher one block with key expansion: 20</li>
+</ul>
+
+<h2>Implementation comparison</h2>
+
+<p>Implementation results for Xilinx Artix7-t200.</p>
+
+<p>Old Cryptech AES core:</p>
+
+<ul>
+<li>2094 slices</li>
+<li>2854 regs</li>
+<li>114 MHz (8.76ns)</li>
+</ul>
+
+<p>Cryptec AES speed core:</p>
+
+<ul>
+<li>2112 slices</li>
+<li>2984 regs</li>
+<li>116 MHz. (8.62ns)</li>
+</ul>
+```
+
+[[RepositoryIndex(format=table,glob=user/sra/aes_merged)]]
+
+| Clone `https://git.cryptech.is/user/sra/aes_merged.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Fbuild-tools.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Fbuild-tools.md
new file mode 100644
index 0000000..9057d5f
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Fbuild-tools.md
@@ -0,0 +1,22 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Build tools</h1>
+
+<p>A collection of scripts I find useful when working with the Cryptech
+git repositories.  YMMV.  No warantee expressed or implied.  If one of
+these scripts breaks, you get to keep both pieces.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/sra/build-tools)]]
+
+| Clone `https://git.cryptech.is/user/sra/build-tools.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Fopenssl-engine.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Fopenssl-engine.md
new file mode 100644
index 0000000..5cfe3bb
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra%2Fopenssl-engine.md
@@ -0,0 +1,85 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+```
+#!html
+<h1>Toys to test Cryptech Alpha HSM with OpenSSL engine API</h1>
+
+<p>Packages you need (on Debian Jessie, anyway):</p>
+
+<pre><code>sudo apt-get install opensc cryptech-alpha stunnel micro-httpd w3m
+sudo apt-get install -t jessie-backports libengine-pkcs11-openssl
+</code></pre>
+
+<p>We're using the backported version of libengine-pkcs11-openssl because
+we want ECDSA support -- the ancient version that originally shipped
+with Jessie only supported RSA.</p>
+
+<p>General plan here is to use pkcs11-tool to create keys, then use the
+pkcs11 OpenSSL engine and OpenSSL command line tool to do vaguely
+useful things with those keys.</p>
+
+<h2>Configuration</h2>
+
+<ul>
+<li><p><code>openssl.conf</code> contains two different kinds of OpenSSL voodoo: the
+bits needed to configure the engine, and the bits needed to
+construct X.509 certificates.  The engine configuration uses
+environment variables to minimize the number of places where the
+same information needs to be configured.</p></li>
+<li><p><code>environment.sh</code> is where environment variables are configured,
+including the PKCS #11 PIN: you would not want to handle the PIN
+this way in production!  But it's convenient for a test script.</p></li>
+</ul>
+
+<h2>Scripts</h2>
+
+<ul>
+<li><p><code>create-keys.sh</code> uses <code>pkcs11-tool</code> to create several test keys.</p></li>
+<li><p><code>list-keys.sh</code> uses <code>pkcs11-tool</code> to list keys known to the HSM.</p></li>
+<li><p><code>delete-keys.sh</code> uses <code>pkcs11-tool</code> to delete the keys which
+<code>create-keys.sh</code> created.</p></li>
+<li><p><code>issue-certificates.sh</code> generates a small X.509v3 certificate tree.
+As a sanity check, it also verifies the issued certificates.
+This depends on the keys created by <code>create-keys.sh</code>.</p></li>
+<li><p><code>basic-signature.sh</code> performs a basic hash-and-sign of a data file
+using the <code>openssl dgst</code> command, writing a detached signature out
+as a binary file.  As a sanity check, it also verifies the resulting
+signature using the public key extracted from the corresponding
+certificate (so this depends on <code>issue-certificates.sh</code>).</p></li>
+<li><p><code>smime-signature.sh</code> generates and verifies a signed S/MIME message;
+this also depends on <code>issue-certificates.sh</code>.</p></li>
+<li><p><code>https-server.sh</code> runs a toy https server, using keys and certificates
+generated by <code>create-keys.sh</code> and <code>issue-certificates.sh</code>.</p></li>
+<li><p><code>https-client.sh</code> uses w3m as a client to talk to the toy server
+run by <code>https-server.sh</code> (and therefore has the same dependencies).</p></li>
+</ul>
+
+<h2>References and notes</h2>
+
+<ul>
+<li><a href="https://www.nlnetlabs.nl/downloads/publications/hsm/">https://www.nlnetlabs.nl/downloads/publications/hsm/</a></li>
+<li><a href="https://github.com/OpenSC/OpenSC/wiki">https://github.com/OpenSC/OpenSC/wiki</a></li>
+<li><a href="https://wiki.openssl.org/index.php/Command_Line_Utilities">https://wiki.openssl.org/index.php/Command_Line_Utilities</a></li>
+<li><a href="https://www.openssl.org/docs/man1.0.2/apps/">https://www.openssl.org/docs/man1.0.2/apps/</a></li>
+</ul>
+
+<p>Given the overall state of OpenSSL's documentation, it also helps to
+be able to read the OpenSSL source code: in this particular case, the
+<code>apps/</code> directory is most likely to be useful.  It turns out that many
+(not all) places where one of the OpenSSL command line functions allow
+one to specify a key format other than <code>PEM</code>, one of the supported
+formats is <code>ENGINE</code>, in which case the "filename" is interpreted as a
+key selector.</p>
+```
+
+[[RepositoryIndex(format=table,glob=user/sra/openssl-engine)]]
+
+| Clone `https://git.cryptech.is/user/sra/openssl-engine.git` |
+|---|
diff --git a/raw-wiki-dump/GitRepositories%2Fuser%2Fsra.md b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra.md
new file mode 100644
index 0000000..d75dcfa
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser%2Fsra.md
@@ -0,0 +1,19 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/sra/aes-keywrap| user/sra/aes-keywrap]] |`https://git.cryptech.is/user/sra/aes-keywrap.git` | [[wiki:GitRepositories/user/sra/aes-keywrap| README]] |
+|[[source:/user/sra/build-tools| user/sra/build-tools]] |`https://git.cryptech.is/user/sra/build-tools.git` | [[wiki:GitRepositories/user/sra/build-tools| README]] |
+|[[source:/user/sra/openssl-engine| user/sra/openssl-engine]] |`https://git.cryptech.is/user/sra/openssl-engine.git` | [[wiki:GitRepositories/user/sra/openssl-engine| README]] |
diff --git a/raw-wiki-dump/GitRepositories%2Fuser.md b/raw-wiki-dump/GitRepositories%2Fuser.md
new file mode 100644
index 0000000..08d7d8e
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories%2Fuser.md
@@ -0,0 +1,52 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/user/ft/alpha_to_kicad| user/ft/alpha_to_kicad]] |`https://git.cryptech.is/user/ft/alpha_to_kicad.git` | [[wiki:GitRepositories/user/ft/alpha_to_kicad| README]] |
+|[[source:/user/ft/bootstrap| user/ft/bootstrap]] |`https://git.cryptech.is/user/ft/bootstrap.git` | [[wiki:GitRepositories/user/ft/bootstrap| README]] |
+|[[source:/user/ft/libcli| user/ft/libcli]] |`https://git.cryptech.is/user/ft/libcli.git` | |
+|[[source:/user/ft/stm32-avalanche-noise| user/ft/stm32-avalanche-noise]] |`https://git.cryptech.is/user/ft/stm32-avalanche-noise.git` | [[wiki:GitRepositories/user/ft/stm32-avalanche-noise| README]] |
+|[[source:/user/ft/stm32-dev-bridge| user/ft/stm32-dev-bridge]] |`https://git.cryptech.is/user/ft/stm32-dev-bridge.git` | |
+|[[source:/user/ft/tamper| user/ft/tamper]] |`https://git.cryptech.is/user/ft/tamper.git` | [[wiki:GitRepositories/user/ft/tamper| README]] |
+|[[source:/user/jakob/benchmark| user/jakob/benchmark]] |`https://git.cryptech.is/user/jakob/benchmark.git` | [[wiki:GitRepositories/user/jakob/benchmark| README]] |
+|[[source:/user/jakob/tamper| user/jakob/tamper]] |`https://git.cryptech.is/user/jakob/tamper.git` | [[wiki:GitRepositories/user/jakob/tamper| README]] |
+|[[source:/user/js/fpga_mkm| user/js/fpga_mkm]] |`https://git.cryptech.is/user/js/fpga_mkm.git` | [[wiki:GitRepositories/user/js/fpga_mkm| README]] |
+|[[source:/user/js/keywrap| user/js/keywrap]] |`https://git.cryptech.is/user/js/keywrap.git` | [[wiki:GitRepositories/user/js/keywrap| README]] |
+|[[source:/user/js/mkmif| user/js/mkmif]] |`https://git.cryptech.is/user/js/mkmif.git` | [[wiki:GitRepositories/user/js/mkmif| README]] |
+|[[source:/user/js/toggle| user/js/toggle]] |`https://git.cryptech.is/user/js/toggle.git` | [[wiki:GitRepositories/user/js/toggle| README]] |
+|[[source:/user/js/vndecorrelator| user/js/vndecorrelator]] |`https://git.cryptech.is/user/js/vndecorrelator.git` | [[wiki:GitRepositories/user/js/vndecorrelator| README]] |
+|[[source:/user/ln5/stm32-avalanche-noise| user/ln5/stm32-avalanche-noise]] |`https://git.cryptech.is/user/ln5/stm32-avalanche-noise.git` | [[wiki:GitRepositories/user/ln5/stm32-avalanche-noise| README]] |
+|[[source:/user/ln5/tamper| user/ln5/tamper]] |`https://git.cryptech.is/user/ln5/tamper.git` | [[wiki:GitRepositories/user/ln5/tamper| README]] |
+|[[source:/user/paul/hashsig-naive| user/paul/hashsig-naive]] |`https://git.cryptech.is/user/paul/hashsig-naive.git` | [[wiki:GitRepositories/user/paul/hashsig-naive| README]] |
+|[[source:/user/paul/libcli| user/paul/libcli]] |`https://git.cryptech.is/user/paul/libcli.git` | |
+|[[source:/user/shatov/ModExpA7| user/shatov/ModExpA7]] |`https://git.cryptech.is/user/shatov/ModExpA7.git` | |
+|[[source:/user/shatov/alpha_rev04| user/shatov/alpha_rev04]] |`https://git.cryptech.is/user/shatov/alpha_rev04.git` | |
+|[[source:/user/shatov/curve25519_fpga_model| user/shatov/curve25519_fpga_model]] |`https://git.cryptech.is/user/shatov/curve25519_fpga_model.git` | [[wiki:GitRepositories/user/shatov/curve25519_fpga_model| README]] |
+|[[source:/user/shatov/ecdh_fpga_model| user/shatov/ecdh_fpga_model]] |`https://git.cryptech.is/user/shatov/ecdh_fpga_model.git` | [[wiki:GitRepositories/user/shatov/ecdh_fpga_model| README]] |
+|[[source:/user/shatov/ecdsa256| user/shatov/ecdsa256]] |`https://git.cryptech.is/user/shatov/ecdsa256.git` | [[wiki:GitRepositories/user/shatov/ecdsa256| README]] |
+|[[source:/user/shatov/ecdsa384| user/shatov/ecdsa384]] |`https://git.cryptech.is/user/shatov/ecdsa384.git` | [[wiki:GitRepositories/user/shatov/ecdsa384| README]] |
+|[[source:/user/shatov/ecdsa_fpga_model| user/shatov/ecdsa_fpga_model]] |`https://git.cryptech.is/user/shatov/ecdsa_fpga_model.git` | [[wiki:GitRepositories/user/shatov/ecdsa_fpga_model| README]] |
+|[[source:/user/shatov/fmc-test| user/shatov/fmc-test]] |`https://git.cryptech.is/user/shatov/fmc-test.git` | [[wiki:GitRepositories/user/shatov/fmc-test| README]] |
+|[[source:/user/shatov/gost/streebog_tester| user/shatov/gost/streebog_tester]] |`https://git.cryptech.is/user/shatov/gost/streebog_tester.git` | |
+|[[source:/user/shatov/gost/streebog| user/shatov/gost/streebog]] |`https://git.cryptech.is/user/shatov/gost/streebog.git` | |
+|[[source:/user/shatov/modexp_fpga_model| user/shatov/modexp_fpga_model]] |`https://git.cryptech.is/user/shatov/modexp_fpga_model.git` | [[wiki:GitRepositories/user/shatov/modexp_fpga_model| README]] |
+|[[source:/user/shatov/modexpng_fpga_model| user/shatov/modexpng_fpga_model]] |`https://git.cryptech.is/user/shatov/modexpng_fpga_model.git` | [[wiki:GitRepositories/user/shatov/modexpng_fpga_model| README]] |
+|[[source:/user/shatov/modexpng| user/shatov/modexpng]] |`https://git.cryptech.is/user/shatov/modexpng.git` | [[wiki:GitRepositories/user/shatov/modexpng| README]] |
+|[[source:/user/shatov/novena-fmc-arbiter| user/shatov/novena-fmc-arbiter]] |`https://git.cryptech.is/user/shatov/novena-fmc-arbiter.git` | [[wiki:GitRepositories/user/shatov/novena-fmc-arbiter| README]] |
+|[[source:/user/shatov/stm32_n25q128| user/shatov/stm32_n25q128]] |`https://git.cryptech.is/user/shatov/stm32_n25q128.git` | |
+|[[source:/user/shatov/stm32_sdram| user/shatov/stm32_sdram]] |`https://git.cryptech.is/user/shatov/stm32_sdram.git` | |
+|[[source:/user/sra/aes-keywrap| user/sra/aes-keywrap]] |`https://git.cryptech.is/user/sra/aes-keywrap.git` | [[wiki:GitRepositories/user/sra/aes-keywrap| README]] |
+|[[source:/user/sra/build-tools| user/sra/build-tools]] |`https://git.cryptech.is/user/sra/build-tools.git` | [[wiki:GitRepositories/user/sra/build-tools| README]] |
+|[[source:/user/sra/openssl-engine| user/sra/openssl-engine]] |`https://git.cryptech.is/user/sra/openssl-engine.git` | [[wiki:GitRepositories/user/sra/openssl-engine| README]] |
diff --git a/raw-wiki-dump/GitRepositories.md b/raw-wiki-dump/GitRepositories.md
new file mode 100644
index 0000000..4927b29
--- /dev/null
+++ b/raw-wiki-dump/GitRepositories.md
@@ -0,0 +1,109 @@
+```
+#!htmlcomment
+
+This page is maintained automatically by a script.  Don't modify this page by hand,
+your changes will just be overwritten the next time the script runs.  Talk to your
+Friendly Neighborhood Repository Maintainer if you need to change something here.
+
+```
+
+# Git Repositories
+
+This page lists links to the currently available git repositories.
+Clone these with git to pull your own copies of the sources.
+
+| Repository | URL for git cloning | |
+|---|---|---|
+|[[source:/core/cipher/aes_speed| core/cipher/aes_speed]] |`https://git.cryptech.is/core/cipher/aes_speed.git` | [[wiki:GitRepositories/core/cipher/aes_speed| README]] |
+|[[source:/core/cipher/aes| core/cipher/aes]] |`https://git.cryptech.is/core/cipher/aes.git` | [[wiki:GitRepositories/core/cipher/aes| README]] |
+|[[source:/core/cipher/chacha| core/cipher/chacha]] |`https://git.cryptech.is/core/cipher/chacha.git` | [[wiki:GitRepositories/core/cipher/chacha| README]] |
+|[[source:/core/comm/coretest| core/comm/coretest]] |`https://git.cryptech.is/core/comm/coretest.git` | [[wiki:GitRepositories/core/comm/coretest| README]] |
+|[[source:/core/comm/eim| core/comm/eim]] |`https://git.cryptech.is/core/comm/eim.git` | [[wiki:GitRepositories/core/comm/eim| README]] |
+|[[source:/core/comm/fmc| core/comm/fmc]] |`https://git.cryptech.is/core/comm/fmc.git` | [[wiki:GitRepositories/core/comm/fmc| README]] |
+|[[source:/core/comm/i2c| core/comm/i2c]] |`https://git.cryptech.is/core/comm/i2c.git` | [[wiki:GitRepositories/core/comm/i2c| README]] |
+|[[source:/core/comm/uart| core/comm/uart]] |`https://git.cryptech.is/core/comm/uart.git` | [[wiki:GitRepositories/core/comm/uart| README]] |
+|[[source:/core/hash/sha1| core/hash/sha1]] |`https://git.cryptech.is/core/hash/sha1.git` | [[wiki:GitRepositories/core/hash/sha1| README]] |
+|[[source:/core/hash/sha256| core/hash/sha256]] |`https://git.cryptech.is/core/hash/sha256.git` | [[wiki:GitRepositories/core/hash/sha256| README]] |
+|[[source:/core/hash/sha3| core/hash/sha3]] |`https://git.cryptech.is/core/hash/sha3.git` | [[wiki:GitRepositories/core/hash/sha3| README]] |
+|[[source:/core/hash/sha512| core/hash/sha512]] |`https://git.cryptech.is/core/hash/sha512.git` | [[wiki:GitRepositories/core/hash/sha512| README]] |
+|[[source:/core/lib| core/lib]] |`https://git.cryptech.is/core/lib.git` | [[wiki:GitRepositories/core/lib| README]] |
+|[[source:/core/math/curve25519lib| core/math/curve25519lib]] |`https://git.cryptech.is/core/math/curve25519lib.git` | |
+|[[source:/core/math/ecdsalib| core/math/ecdsalib]] |`https://git.cryptech.is/core/math/ecdsalib.git` | [[wiki:GitRepositories/core/math/ecdsalib| README]] |
+|[[source:/core/math/modexpa7| core/math/modexpa7]] |`https://git.cryptech.is/core/math/modexpa7.git` | [[wiki:GitRepositories/core/math/modexpa7| README]] |
+|[[source:/core/math/modexpng| core/math/modexpng]] |`https://git.cryptech.is/core/math/modexpng.git` | [[wiki:GitRepositories/core/math/modexpng| README]] |
+|[[source:/core/math/modexps6| core/math/modexps6]] |`https://git.cryptech.is/core/math/modexps6.git` | |
+|[[source:/core/math/modexp| core/math/modexp]] |`https://git.cryptech.is/core/math/modexp.git` | [[wiki:GitRepositories/core/math/modexp| README]] |
+|[[source:/core/pkey/ecdhp256| core/pkey/ecdhp256]] |`https://git.cryptech.is/core/pkey/ecdhp256.git` | [[wiki:GitRepositories/core/pkey/ecdhp256| README]] |
+|[[source:/core/pkey/ecdhp384| core/pkey/ecdhp384]] |`https://git.cryptech.is/core/pkey/ecdhp384.git` | [[wiki:GitRepositories/core/pkey/ecdhp384| README]] |
+|[[source:/core/pkey/ecdsa256| core/pkey/ecdsa256]] |`https://git.cryptech.is/core/pkey/ecdsa256.git` | [[wiki:GitRepositories/core/pkey/ecdsa256| README]] |
+|[[source:/core/pkey/ecdsa384| core/pkey/ecdsa384]] |`https://git.cryptech.is/core/pkey/ecdsa384.git` | [[wiki:GitRepositories/core/pkey/ecdsa384| README]] |
+|[[source:/core/pkey/ed25519| core/pkey/ed25519]] |`https://git.cryptech.is/core/pkey/ed25519.git` | |
+|[[source:/core/platform/alpha| core/platform/alpha]] |`https://git.cryptech.is/core/platform/alpha.git` | [[wiki:GitRepositories/core/platform/alpha| README]] |
+|[[source:/core/platform/common| core/platform/common]] |`https://git.cryptech.is/core/platform/common.git` | [[wiki:GitRepositories/core/platform/common| README]] |
+|[[source:/core/platform/novena| core/platform/novena]] |`https://git.cryptech.is/core/platform/novena.git` | [[wiki:GitRepositories/core/platform/novena| README]] |
+|[[source:/core/platform/terasic_c5g| core/platform/terasic_c5g]] |`https://git.cryptech.is/core/platform/terasic_c5g.git` | [[wiki:GitRepositories/core/platform/terasic_c5g| README]] |
+|[[source:/core/rng/avalanche_entropy| core/rng/avalanche_entropy]] |`https://git.cryptech.is/core/rng/avalanche_entropy.git` | [[wiki:GitRepositories/core/rng/avalanche_entropy| README]] |
+|[[source:/core/rng/rosc_entropy| core/rng/rosc_entropy]] |`https://git.cryptech.is/core/rng/rosc_entropy.git` | [[wiki:GitRepositories/core/rng/rosc_entropy| README]] |
+|[[source:/core/rng/trng| core/rng/trng]] |`https://git.cryptech.is/core/rng/trng.git` | [[wiki:GitRepositories/core/rng/trng| README]] |
+|[[source:/core/rng/vndecorrelator| core/rng/vndecorrelator]] |`https://git.cryptech.is/core/rng/vndecorrelator.git` | [[wiki:GitRepositories/core/rng/vndecorrelator| README]] |
+|[[source:/core/util/keywrap| core/util/keywrap]] |`https://git.cryptech.is/core/util/keywrap.git` | [[wiki:GitRepositories/core/util/keywrap| README]] |
+|[[source:/core/util/mkmif| core/util/mkmif]] |`https://git.cryptech.is/core/util/mkmif.git` | [[wiki:GitRepositories/core/util/mkmif| README]] |
+|[[source:/doc/design| doc/design]] |`https://git.cryptech.is/doc/design.git` | [[wiki:GitRepositories/doc/design| README]] |
+|[[source:/doc/presentations| doc/presentations]] |`https://git.cryptech.is/doc/presentations.git` | [[wiki:GitRepositories/doc/presentations| README]] |
+|[[source:/hardware| hardware]] |`https://git.cryptech.is/hardware.git` | [[wiki:GitRepositories/hardware| README]] |
+|[[source:/releng/alpha| releng/alpha]] |`https://git.cryptech.is/releng/alpha.git` | [[wiki:GitRepositories/releng/alpha| README]] |
+|[[source:/releng/novena| releng/novena]] |`https://git.cryptech.is/releng/novena.git` | [[wiki:GitRepositories/releng/novena| README]] |
+|[[source:/sw/cryptlib| sw/cryptlib]] |`https://git.cryptech.is/sw/cryptlib.git` | [[wiki:GitRepositories/sw/cryptlib| README]] |
+|[[source:/sw/libhal| sw/libhal]] |`https://git.cryptech.is/sw/libhal.git` | [[wiki:GitRepositories/sw/libhal| README]] |
+|[[source:/sw/pkcs11| sw/pkcs11]] |`https://git.cryptech.is/sw/pkcs11.git` | [[wiki:GitRepositories/sw/pkcs11| README]] |
+|[[source:/sw/stm32| sw/stm32]] |`https://git.cryptech.is/sw/stm32.git` | [[wiki:GitRepositories/sw/stm32| README]] |
+|[[source:/sw/tamper| sw/tamper]] |`https://git.cryptech.is/sw/tamper.git` | [[wiki:GitRepositories/sw/tamper| README]] |
+|[[source:/sw/thirdparty/ekermit| sw/thirdparty/ekermit]] |`https://git.cryptech.is/sw/thirdparty/ekermit.git` | |
+|[[source:/sw/thirdparty/libtfm| sw/thirdparty/libtfm]] |`https://git.cryptech.is/sw/thirdparty/libtfm.git` | [[wiki:GitRepositories/sw/thirdparty/libtfm| README]] |
+|[[source:/sw/thirdparty/sqlite3| sw/thirdparty/sqlite3]] |`https://git.cryptech.is/sw/thirdparty/sqlite3.git` | [[wiki:GitRepositories/sw/thirdparty/sqlite3| README]] |
+|[[source:/test/coretest_bp_entropy| test/coretest_bp_entropy]] |`https://git.cryptech.is/test/coretest_bp_entropy.git` | [[wiki:GitRepositories/test/coretest_bp_entropy| README]] |
+|[[source:/test/coretest_fpga_entropy| test/coretest_fpga_entropy]] |`https://git.cryptech.is/test/coretest_fpga_entropy.git` | [[wiki:GitRepositories/test/coretest_fpga_entropy| README]] |
+|[[source:/test/coretest_test_core| test/coretest_test_core]] |`https://git.cryptech.is/test/coretest_test_core.git` | [[wiki:GitRepositories/test/coretest_test_core| README]] |
+|[[source:/test/external_avalanche_entropy| test/external_avalanche_entropy]] |`https://git.cryptech.is/test/external_avalanche_entropy.git` | [[wiki:GitRepositories/test/external_avalanche_entropy| README]] |
+|[[source:/test/fpga_entropy| test/fpga_entropy]] |`https://git.cryptech.is/test/fpga_entropy.git` | [[wiki:GitRepositories/test/fpga_entropy| README]] |
+|[[source:/test/novena_base| test/novena_base]] |`https://git.cryptech.is/test/novena_base.git` | [[wiki:GitRepositories/test/novena_base| README]] |
+|[[source:/test/novena_entropy| test/novena_entropy]] |`https://git.cryptech.is/test/novena_entropy.git` | [[wiki:GitRepositories/test/novena_entropy| README]] |
+|[[source:/test/novena_i2c_simple| test/novena_i2c_simple]] |`https://git.cryptech.is/test/novena_i2c_simple.git` | [[wiki:GitRepositories/test/novena_i2c_simple| README]] |
+|[[source:/test/novena_trng| test/novena_trng]] |`https://git.cryptech.is/test/novena_trng.git` | [[wiki:GitRepositories/test/novena_trng| README]] |
+|[[source:/test/test_core| test/test_core]] |`https://git.cryptech.is/test/test_core.git` | [[wiki:GitRepositories/test/test_core| README]] |
+|[[source:/user/ft/alpha_to_kicad| user/ft/alpha_to_kicad]] |`https://git.cryptech.is/user/ft/alpha_to_kicad.git` | [[wiki:GitRepositories/user/ft/alpha_to_kicad| README]] |
+|[[source:/user/ft/bootstrap| user/ft/bootstrap]] |`https://git.cryptech.is/user/ft/bootstrap.git` | [[wiki:GitRepositories/user/ft/bootstrap| README]] |
+|[[source:/user/ft/libcli| user/ft/libcli]] |`https://git.cryptech.is/user/ft/libcli.git` | |
+|[[source:/user/ft/stm32-avalanche-noise| user/ft/stm32-avalanche-noise]] |`https://git.cryptech.is/user/ft/stm32-avalanche-noise.git` | [[wiki:GitRepositories/user/ft/stm32-avalanche-noise| README]] |
+|[[source:/user/ft/stm32-dev-bridge| user/ft/stm32-dev-bridge]] |`https://git.cryptech.is/user/ft/stm32-dev-bridge.git` | |
+|[[source:/user/ft/tamper| user/ft/tamper]] |`https://git.cryptech.is/user/ft/tamper.git` | [[wiki:GitRepositories/user/ft/tamper| README]] |
+|[[source:/user/jakob/benchmark| user/jakob/benchmark]] |`https://git.cryptech.is/user/jakob/benchmark.git` | [[wiki:GitRepositories/user/jakob/benchmark| README]] |
+|[[source:/user/jakob/tamper| user/jakob/tamper]] |`https://git.cryptech.is/user/jakob/tamper.git` | [[wiki:GitRepositories/user/jakob/tamper| README]] |
+|[[source:/user/js/fpga_mkm| user/js/fpga_mkm]] |`https://git.cryptech.is/user/js/fpga_mkm.git` | [[wiki:GitRepositories/user/js/fpga_mkm| README]] |
+|[[source:/user/js/keywrap| user/js/keywrap]] |`https://git.cryptech.is/user/js/keywrap.git` | [[wiki:GitRepositories/user/js/keywrap| README]] |
+|[[source:/user/js/mkmif| user/js/mkmif]] |`https://git.cryptech.is/user/js/mkmif.git` | [[wiki:GitRepositories/user/js/mkmif| README]] |
+|[[source:/user/js/toggle| user/js/toggle]] |`https://git.cryptech.is/user/js/toggle.git` | [[wiki:GitRepositories/user/js/toggle| README]] |
+|[[source:/user/js/vndecorrelator| user/js/vndecorrelator]] |`https://git.cryptech.is/user/js/vndecorrelator.git` | [[wiki:GitRepositories/user/js/vndecorrelator| README]] |
+|[[source:/user/ln5/stm32-avalanche-noise| user/ln5/stm32-avalanche-noise]] |`https://git.cryptech.is/user/ln5/stm32-avalanche-noise.git` | [[wiki:GitRepositories/user/ln5/stm32-avalanche-noise| README]] |
+|[[source:/user/ln5/tamper| user/ln5/tamper]] |`https://git.cryptech.is/user/ln5/tamper.git` | [[wiki:GitRepositories/user/ln5/tamper| README]] |
+|[[source:/user/paul/hashsig-naive| user/paul/hashsig-naive]] |`https://git.cryptech.is/user/paul/hashsig-naive.git` | [[wiki:GitRepositories/user/paul/hashsig-naive| README]] |
+|[[source:/user/paul/libcli| user/paul/libcli]] |`https://git.cryptech.is/user/paul/libcli.git` | |
+|[[source:/user/shatov/ModExpA7| user/shatov/ModExpA7]] |`https://git.cryptech.is/user/shatov/ModExpA7.git` | |
+|[[source:/user/shatov/alpha_rev04| user/shatov/alpha_rev04]] |`https://git.cryptech.is/user/shatov/alpha_rev04.git` | |
+|[[source:/user/shatov/curve25519_fpga_model| user/shatov/curve25519_fpga_model]] |`https://git.cryptech.is/user/shatov/curve25519_fpga_model.git` | [[wiki:GitRepositories/user/shatov/curve25519_fpga_model| README]] |
+|[[source:/user/shatov/ecdh_fpga_model| user/shatov/ecdh_fpga_model]] |`https://git.cryptech.is/user/shatov/ecdh_fpga_model.git` | [[wiki:GitRepositories/user/shatov/ecdh_fpga_model| README]] |
+|[[source:/user/shatov/ecdsa256| user/shatov/ecdsa256]] |`https://git.cryptech.is/user/shatov/ecdsa256.git` | [[wiki:GitRepositories/user/shatov/ecdsa256| README]] |
+|[[source:/user/shatov/ecdsa384| user/shatov/ecdsa384]] |`https://git.cryptech.is/user/shatov/ecdsa384.git` | [[wiki:GitRepositories/user/shatov/ecdsa384| README]] |
+|[[source:/user/shatov/ecdsa_fpga_model| user/shatov/ecdsa_fpga_model]] |`https://git.cryptech.is/user/shatov/ecdsa_fpga_model.git` | [[wiki:GitRepositories/user/shatov/ecdsa_fpga_model| README]] |
+|[[source:/user/shatov/fmc-test| user/shatov/fmc-test]] |`https://git.cryptech.is/user/shatov/fmc-test.git` | [[wiki:GitRepositories/user/shatov/fmc-test| README]] |
+|[[source:/user/shatov/gost/streebog_tester| user/shatov/gost/streebog_tester]] |`https://git.cryptech.is/user/shatov/gost/streebog_tester.git` | |
+|[[source:/user/shatov/gost/streebog| user/shatov/gost/streebog]] |`https://git.cryptech.is/user/shatov/gost/streebog.git` | |
+|[[source:/user/shatov/modexp_fpga_model| user/shatov/modexp_fpga_model]] |`https://git.cryptech.is/user/shatov/modexp_fpga_model.git` | [[wiki:GitRepositories/user/shatov/modexp_fpga_model| README]] |
+|[[source:/user/shatov/modexpng_fpga_model| user/shatov/modexpng_fpga_model]] |`https://git.cryptech.is/user/shatov/modexpng_fpga_model.git` | [[wiki:GitRepositories/user/shatov/modexpng_fpga_model| README]] |
+|[[source:/user/shatov/modexpng| user/shatov/modexpng]] |`https://git.cryptech.is/user/shatov/modexpng.git` | [[wiki:GitRepositories/user/shatov/modexpng| README]] |
+|[[source:/user/shatov/novena-fmc-arbiter| user/shatov/novena-fmc-arbiter]] |`https://git.cryptech.is/user/shatov/novena-fmc-arbiter.git` | [[wiki:GitRepositories/user/shatov/novena-fmc-arbiter| README]] |
+|[[source:/user/shatov/stm32_n25q128| user/shatov/stm32_n25q128]] |`https://git.cryptech.is/user/shatov/stm32_n25q128.git` | |
+|[[source:/user/shatov/stm32_sdram| user/shatov/stm32_sdram]] |`https://git.cryptech.is/user/shatov/stm32_sdram.git` | |
+|[[source:/user/sra/aes-keywrap| user/sra/aes-keywrap]] |`https://git.cryptech.is/user/sra/aes-keywrap.git` | [[wiki:GitRepositories/user/sra/aes-keywrap| README]] |
+|[[source:/user/sra/build-tools| user/sra/build-tools]] |`https://git.cryptech.is/user/sra/build-tools.git` | [[wiki:GitRepositories/user/sra/build-tools| README]] |
+|[[source:/user/sra/openssl-engine| user/sra/openssl-engine]] |`https://git.cryptech.is/user/sra/openssl-engine.git` | [[wiki:GitRepositories/user/sra/openssl-engine| README]] |
diff --git a/raw-wiki-dump/Hardware.md b/raw-wiki-dump/Hardware.md
new file mode 100644
index 0000000..e271794
--- /dev/null
+++ b/raw-wiki-dump/Hardware.md
@@ -0,0 +1,28 @@
+# Cryptech Hardware
+
+## Generation 1
+
+Various generic FPGA development boards.
+
+## Generation 2
+
+//[wiki:CoretestHashesNovena Novena]//
+
+## Generation 3
+
+An Alpha version of a CrypTech HSM, currently in early design
+
+[[Image(cryptech-g3.png)]]
+
+There is no real tamper wrapping and no tamper sensors.  The tamper switch is used to simulate tamper detection to test the system's tamper reaction(s).
+
+For the ARM, we think we want
+
+    * No or minimal magic blobs because it's inside the security boundary
+    * Support for booting, flash file system, and USB
+    * Do not need memory protection or allocation, threads, video or sound or ...
+    * Some speed, but the crypto is done in the FPGA
+    * All components must be free of any GPL-like virus or restrictions
+
+
+[wiki:AlphaBoardComponents The BOM and board requirements for the alpha board].
diff --git a/raw-wiki-dump/InterMapTxt.md b/raw-wiki-dump/InterMapTxt.md
new file mode 100644
index 0000000..c4cc275
--- /dev/null
+++ b/raw-wiki-dump/InterMapTxt.md
@@ -0,0 +1,135 @@
+# InterMapTxt
+
+## This is the place for defining InterWiki prefixes
+
+This page was modelled after the MeatBall:InterMapTxt page.
+In addition, an optional comment is allowed after the mapping.
+
+
+This page is interpreted in a special way by Trac, in order to support
+InterWiki links in a flexible and dynamic way.
+
+The code block after the first line separator in this page
+will be interpreted as a list of InterWiki specifications:
+```
+prefix <space> URL [<space> # comment]
+```
+
+By using `$1`, `$2`, etc. within the URL, it is possible to create
+InterWiki links which support multiple arguments, e.g. Trac:ticket:40.
+The URL itself can be optionally followed by a comment,
+which will subsequently be used for decorating the links
+using that prefix.
+
+New InterWiki links can be created by adding to that list, in real time.
+Note however that *deletions* are also taken into account immediately,
+so it may be better to use comments for disabling prefixes.
+
+Also note that InterWiki prefixes are case insensitive.
+
+
+## List of Active Prefixes
+
+[[InterWiki]]
+
+
+----
+
+## Prefix Definitions
+
+```
+PEP     http://www.python.org/dev/peps/pep-$1/    # Python Enhancement Proposal
+PythonBug    http://bugs.python.org/issue$1       # Python Issue #$1
+Python-issue http://bugs.python.org/issue$1       # Python Issue #$1
+PythonWiki    https://wiki.python.org/moin/       # Python Wiki
+
+
+Trac-ML  http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/ # Message $1 in Trac Mailing List
+trac-dev http://thread.gmane.org/gmane.comp.version-control.subversion.trac.devel/   # Message $1 in Trac Development Mailing List
+
+apidoc http://www.edgewall.org/docs/trac-trunk/html/$1.html # $1 in the API documentation for Trac
+apiref http://www.edgewall.org/docs/trac-trunk/epydoc/$1.html # $1 in the Epydoc API reference for Trac
+
+bitten   http://bitten.edgewall.org/intertrac/    # Bitten's Trac
+
+Mercurial http://www.selenic.com/mercurial/wiki/index.cgi/ # the wiki for the Mercurial distributed SCM
+hg        http://www.selenic.com/hg/rev/$1?rev=$2          # Changeset $1 $2 in Mercurial repository
+hg-issue  http://mercurial.selenic.com/bts/issue           # Issue $1 in Mercurial BTS
+
+RFC       http://tools.ietf.org/html/rfc$1          # IETF's RFC $1
+ISO       http://en.wikipedia.org/wiki/ISO_         # ISO Standard $1 in Wikipedia
+kb        http://support.microsoft.com/kb/$1/en-us/ # Article $1 in Microsoft's Knowledge Base
+
+pypi        http://pypi.python.org/pypi/   # $1 package in the Python Package Index
+CheeseShop  http://pypi.python.org/pypi/           # $1 package in the Python Package Index
+peak        http://peak.telecommunity.com/DevCenter/     # $1 in Python Enterprise Application Kit's Wiki
+setuptools-issue http://bugs.python.org/setuptools/issue # issue$1 in legacy Setuptools tracker
+pypa-setuptools-issue https://bitbucket.org/pypa/setuptools/issue/ # issue #$1 in BitBucket Setuptools tracker
+
+SQLite      http://www.sqlite.org/cvstrac/wiki?p=$1     # $1 page in the CvsTrac for SQLite
+SQLiteTkt   http://www.sqlite.org/cvstrac/tktview?tn=$1 # Ticket $1 in the CvsTrac for SQLite
+
+mysql-bugs  http://bugs.mysql.com/bug.php?id=  # Bug #$1 in MySQL's bug database
+mysql-issue http://bugs.mysql.com/bug.php?id=  # Bug #$1 in MySQL's bug database
+
+MODPYTHON          http://issues.apache.org/jira/browse/MODPYTHON- # Issue $1 in mod_python's JIRA instance
+mod-python-issue   http://issues.apache.org/jira/browse/MODPYTHON- # Issue $1 in mod_python's JIRA instance
+
+SvnWiki     http://www.orcaware.com/svn/wiki/                        # Subversion Wiki
+svnissue    http://subversion.tigris.org/issues/show_bug.cgi?id=     # Subversion issue #$1
+svn-issue   http://subversion.tigris.org/issues/show_bug.cgi?id=     # Subversion issue #$1
+svncset     http://svn.collab.net/viewvc/svn?view=revision&revision= # Subversion [$1]
+
+mod-wsgi    http://code.google.com/p/modwsgi/wiki/                 # mod_wsgi Wiki on Google Code
+mod-wsgi-issue  http://code.google.com/p/modwsgi/issues/detail?id= # mod_wsgi Issue Tracker on Google Code
+
+chromium-issue  http://code.google.com/p/chromium/issues/detail?id=
+
+Django      http://code.djangoproject.com/intertrac/ # Django's Trac
+AgileTrac   http://www.agile-trac.org/intertrac/     # Plugin adding Iterations to Trac
+
+CreoleWiki   http://wikicreole.org/wiki/
+Creole1Wiki  http://wikicreole.org/wiki/
+Creole2Wiki  http://wiki.wikicreole.org/
+
+MediaWiki    http://www.mediawiki.org/wiki/
+
+SO  http://stackoverflow.com/questions/ # Question $1 in StackOverflow
+
+Transifex https://www.transifex.com/projects/p/trac/
+
+kwquery      /query?group=status&keywords=~  # Custom query for tickets matching keyword $1
+
+#
+# A arbitrary pick of InterWiki prefixes...
+#
+Acronym          http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=
+C2find           http://c2.com/cgi/wiki?FindPage&value=
+Cache            http://www.google.com/search?q=cache:
+CPAN             http://search.cpan.org/perldoc?
+DebianBug        http://bugs.debian.org/
+DebianPackage    http://packages.debian.org/
+DebianPTS        http://packages.qa.debian.org/
+Dictionary       http://www.dict.org/bin/Dict?Database=*&Form=Dict1&Strategy=*&Query=
+Google           http://www.google.com/search?q=
+lmgtfy           http://lmgtfy.com/?q= # Well, just search for "$1", follow the link to see how to do it...
+GoogleGroups     http://groups.google.com/group/$1/msg/$2        # Message $2 in $1 Google Group
+gdiscussion      https://groups.google.com/d/topic/$1/$2/discussion # Discussion $2 in $1 Google
+gmessage         https://groups.google.com/d/msg/$1/$2 # Message $2 in $1 Google Group
+gforum           https://groups.google.com/forum/#!forum/$1 # Forum $1 in Google Groups
+JargonFile       http://downlode.org/perl/jargon-redirect.cgi?term=
+MeatBall         http://www.usemod.com/cgi-bin/mb.pl?
+MetaWiki         http://sunir.org/apps/meta.pl?
+MetaWikiPedia    http://meta.wikipedia.org/wiki/
+MoinMoin         http://moinmo.in/
+TracHacks        http://trac-hacks.org/wiki/
+OSM              http://www.openstreetmap.org/wiki/
+WhoIs            http://www.whois.sc/
+Why              http://clublet.com/c/c/why?
+c2Wiki           http://c2.com/cgi/wiki?
+WikiPedia        http://en.wikipedia.org/wiki/
+```
+
+
+----
+See also: InterWiki, InterTrac
diff --git a/raw-wiki-dump/InterTrac.md b/raw-wiki-dump/InterTrac.md
new file mode 100644
index 0000000..bf81a0e
--- /dev/null
+++ b/raw-wiki-dump/InterTrac.md
@@ -0,0 +1,69 @@
+# InterTrac Links
+
+Trac supports a convenient way to refer to resources of other Trac servers, from within the Wiki markup. An InterTrac link can be seen as a scoped TracLinks. It is used for referring to a Trac resource located in another Trac environment. A resource can be a wiki page, changeset, ticket or milestone.
+
+## List of Active InterTrac Prefixes
+
+[[InterTrac]]
+
+## Link Syntax
+
+Simply use the name of the other Trac environment as a prefix, followed by a colon, ending with the resource located in the other environment:
+
+```
+<target_environment>:<TracLinks>
+```
+
+The other resource is specified using a regular TracLinks, of any flavor.
+
+That target environment name is either the real name of the environment or an alias for it.
+The aliases are defined in the `trac.ini` file, see below.
+The prefix is case insensitive.
+
+If the InterTrac link is enclosed in square brackets, like `[th:WikiExtrasPlugin]`, the InterTrac prefix is removed in the displayed link like a normal link resolver would be, ie the above would be displayed as `WikiExtrasPlugin`.
+
+For convenience, there is also an alternative short-hand form, where an alias can be used as an immediate prefix for the identifier of a ticket, changeset or report, eg `#T234`, `[T1508]`, `[trac 1508]`.
+
+## Examples
+
+It is necessary to set up a configuration for the InterTrac facility.
+This configuration has to be done in the TracIni file, `[intertrac]` section, for example:
+
+```#!ini
+[intertrac]
+# -- Example of setting up an alias:
+t = trac
+
+# -- Link to an external Trac:
+trac.title = Edgewall's Trac for Trac
+trac.url = http://trac.edgewall.org
+```
+
+The `.url` is mandatory and is used for locating the other Trac.
+This can be a relative URL in case that Trac environment is located on the same server.
+
+The `.title` information is used in a tooltip, ie when hovering the cursor over an InterTrac link.
+
+Now, given the above configuration, one could create the following links:
+
+    * to this InterTrac page:
+        * `trac:wiki:InterTrac` trac:wiki:InterTrac
+        * `t:wiki:InterTrac` t:wiki:InterTrac
+        * Keys are case insensitive: `T:wiki:InterTrac` T:wiki:InterTrac
+    * to the ticket #234:
+        * `trac:ticket:234` trac:ticket:234
+        * `trac:#234` trac:#234
+        * `#T234` #T234
+    * to the changeset [1912]:
+        * `trac:changeset:1912` trac:changeset:1912
+        * `[T1912]` [T1912]
+    * to the log range [3300:3330]:
+        * `trac:log:@3300:3330` trac:log:@3300:3330
+        * `[trac 3300:3330]` [trac 3300:3330]
+        * finally, to link to the start page of a remote trac, simply use its prefix followed by ':', inside an explicit link. Example: `[th: Trac Hacks]` (note that the *remote* Trac has to run Trac >= 0.11 for this to work*)
+
+
+The generic form `intertrac_prefix:module:id` is translated to the corresponding URL `<remote>/module/id`, shorthand links are specific to some modules (e.g. !#T234 is processed by the ticket module) and for the rest (`intertrac_prefix:something`), we rely on the TracSearch#quickjump facility of the remote Trac.
+
+----
+See also: TracLinks, InterWiki
diff --git a/raw-wiki-dump/InterWiki.md b/raw-wiki-dump/InterWiki.md
new file mode 100644
index 0000000..ef86371
--- /dev/null
+++ b/raw-wiki-dump/InterWiki.md
@@ -0,0 +1,70 @@
+# Support for InterWiki links
+
+## Definition
+
+An InterWiki link can be used for referring to a Wiki page located in another Wiki system, and by extension, to any object located in any other Web application, provided a simple URL mapping can be done.
+
+InterWiki prefixes can even be used to simply introduce links to new protocols, such as `tsvn:` used by [trac:TortoiseSvn TortoiseSvn].
+
+## Link Syntax
+
+```
+<target_wiki>(:<identifier>)+
+```
+
+The link is composed by the targeted Wiki (or system) name, followed by a colon, eg `MeatBall:`, followed by a page specification in the target.
+Note that, as for InterTrac prefixes, **InterWiki prefixes are case insensitive**.
+
+The target Wiki URL is looked up in the `[interwiki]` section of TracIni or in the InterMapTxt wiki page, modeled after MeatBall:InterMapTxt. If a prefix is defined in both the `[interwiki]` section and InterMapTxt, the `[interwiki]` section takes precedence.
+
+In addition to traditional InterWiki links, where the target is simply *appended* to the URL, Trac supports parametric InterWiki URLs:
+identifiers `$1`, `$2`, ... in the URL will be replaced by corresponding arguments.
+The argument list is formed by splitting the page identifier using the ":" separator.
+
+### [interwiki]
+
+Every option in the `[interwiki]` section in TracIni defines one InterWiki prefix. The option name defines the prefix. The option value defines the URL, optionally followed by a description separated from the URL by whitespace. Parametric URLs are supported as well.
+
+**Example:**
+```#!ini
+[interwiki]
+MeatBall = http://www.usemod.com/cgi-bin/mb.pl?
+PEP = http://www.python.org/peps/pep-$1.html Python Enhancement Proposal $1
+tsvn = tsvn: Interact with TortoiseSvn
+```
+
+## Examples
+
+If the following is an excerpt of the InterMapTxt page:
+
+```
+= InterMapTxt =
+== This is the place for defining InterWiki prefixes ==
+
+Currently active prefixes: [[InterWiki]]
+
+This page is modelled after the MeatBall:InterMapTxt page.
+In addition, an optional comment is allowed after the mapping.
+----
+```
+PEP      http://www.python.org/peps/pep-$1.html           # Python Enhancement Proposal $1
+Trac-ML  http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/$1  # Message $1 in Trac Mailing List
+
+tsvn     tsvn:                                            # Interact with TortoiseSvn
+...
+MeatBall http://www.usemod.com/cgi-bin/mb.pl?
+MetaWiki http://sunir.org/apps/meta.pl?
+MetaWikiPedia http://meta.wikipedia.org/wiki/
+MoinMoin http://moinmoin.wikiwikiweb.de/
+...
+```
+```
+
+Then,
+
+    * `MoinMoin:InterWikiMap` should be rendered as MoinMoin:InterWikiMap and the *title* for that link would be "InterWikiMap in MoinMoin".
+    * `Trac-ML:4346` should be rendered as Trac-ML:4346 and the *title* for that link would be "Message 4346 in Trac Mailing List".
+
+
+----
+See also: InterTrac, InterMapTxt
diff --git a/raw-wiki-dump/InterconnectStandards.md b/raw-wiki-dump/InterconnectStandards.md
new file mode 100644
index 0000000..819b497
--- /dev/null
+++ b/raw-wiki-dump/InterconnectStandards.md
@@ -0,0 +1,319 @@
+# Comparison of On-Chip Bus Standards
+
+## Introduction
+This document contains a brief summary of different on-chip bus
+standards. The standards are described and compared based on license and
+availability, technical specifications and general usage.
+
+The purpose of the document is to provide a basis for selecting the
+primary bus standard for the Cryptech Open HSM project.
+
+
+## Overview
+System on Chip (SoC) designs require some sort of connectivity between
+the different components (called cores or IP-cores, as in Intellectual
+Property) that are placed onto the same die.
+
+There are several standards for on-chip interconnect, standards that
+provide technical diversity that might be required by the
+system. Typical differences are:
+
+
+    - Performance. The capacity as well as latency.
+
+
+
+    - Intelligence. Simple master-slave read/write access or DMA-transfers,
+
+   coherence support etc.
+
+
+    - point to point or point to multipoint. Basically bus based or switch
+
+   fabric.
+
+
+There are also non-technical differences:
+
+
+    - Licensing and pricing. Does using a standard add monetary cost and
+
+   does using the standard infer restrictions in sharing, disclosure of
+   source code?
+
+
+    - Market share. The market share is primarily interesting as basis for
+
+   the availability of other cores that could be integrated.
+
+
+## Description of Standards
+
+### AMBA
+AMBA (Advanced Microcontroller Bus Architecture) [#fn1 (1)], [#fn2 (2)] is a family of
+interconnect standards from ARM Ltd. AMBA is widely used in systems
+implemented in ASICs (for example mobile phone platforms), but are also
+used in FPGAs. AMBA is for example used by the LEON [#fn3 (3)] processor
+cores and subsystem GRLIB.
+
+AMBA currently contains four main interconnect types:
+
+
+    - APB. A simple register read/write bus used to connect simpler
+
+    devices such as timers, IRQ handlers, slow serial I/O such as UARTS
+    and GPIO interfaces. The peripherals are connected to a common bus
+    with a single master.
+
+
+    - AHB. A more advanced bus based interconnect. Supports more complex
+
+    data transfers of up to 1 kByte data. Supports multiple masters.
+
+
+    - AXI. A switch fabric based interconnect that supports multiple
+
+    parallel transfers, multiple masters etc.
+
+
+    - ACE. A low latency interconnect that supports cache coherency to
+
+    allow the design of multicore, multiprocessor systems on-chip.
+
+(There are also additional protocols in the AMBA specification for
+things like tracing etc.)
+
+The license model for AMBA is _Open_ according to ARM. This seems to
+mean that one can use AMBA to build a system. But at the same time, ARM
+has intellectual properties to parts of the technology as well as
+trademarks. For more information on ARM licensing, see [#fn4 (4)].
+
+The OpenCores project [#fn7 (7)] lists several cores as well as tools for
+different AMBA interconnect types.
+
+Pros:
+
+    - Technically advanced and covers a wide range of system
+
+    requirements.
+
+
+    - A huge user base.
+
+
+
+    - A huge selection of third party support in terms of tools as well as
+
+    cores. Most of these cores and tools are commercial and proprietary,
+    closed source.
+
+Cons:
+
+    - Licensing. Would Cryptech need to get a license?
+
+
+
+    - Availability of open cores
+
+
+
+
+### Avalon
+Avalon [#fn5 (5)] is a proprietary switch fabric interconnect from Altera
+corporation. It is used in systems developed using the Altera Nios-II
+[#fn6 (6)] family of soft processor cores and related peripherals.
+
+According to Altera, the license for Avalon is open: "Avalon interfaces
+are an open standard. No license or royalty is required to develop and
+sell products that use, or are based on Avalon interfaces."
+
+As far as we can discern, Avalon is not generally used outside of Altera
+based designs and not supported by a large group of third party
+vendors. The OpenCores project lists only a few cores that uses Avalon
+as interface standard.
+
+=
+Pros:
+
+    - Good technical features.
+
+
+
+    - Easy integration in Nios-II based systems.
+
+
+Cons:
+
+    - Limited to Altera based FPGA designs.
+
+
+
+    - Low support from open and proprietary third party suppliers of tools
+
+    and cores.
+
+
+
+### CoreConnect
+CoreConnect [#fn8 (8)] is an interconnect standard initially developed by
+IBM. The standard is now used by several vendors, for example the
+FPGA-vendor Xilinx[#fn9 (9)].
+
+Similarly to AMBA, CoreConnect contains several types of buses providing
+simple peripheral access (DCR), high speed access for processor based
+systems (OPB), as well as multicore solutions (PLB).
+
+The license for CoreConnect is granted by IBM [#fn10 (10)]. The license seems to be
+an AS IS-license, but contains a lot of other regulations. IBM holds a
+number of patents related to CoreConnect (see the license agreement).
+
+Pros:
+
+    - Good support on for systems implemented on Xilinx FPGAs.
+
+
+Cons:
+
+    - Low support by open cores and tools.
+    - License agreement.
+
+
+
+### OCP
+The Open Core Protocol [#fn11 (11)] is a vendor neutral open interconnect standard
+being developed by the EDA standards organisation Accellera [#fn12 (12)]. The
+standards was previously developed by the vendor organisation OCP-IP [#fn13 (13)],
+but were transferred to Accellera in October 2013.
+
+Like AMBA, OCP contains a wide range of interconnect types from simple
+register read/write access over a common bus to point to
+point-interconnect and coherency support.
+
+There are quite a few commercial cores using OCP, but there seem to be
+very few open cores using OCP. OpenCores only lists a few cores and
+they are all bridges used to connect OCP to AMBA or Wishbone.
+
+The license for accessing the specification itself is an amended AS
+IS-type license[#fn14 (14)]. The license for the interconnect seems to be rather
+open.
+
+Pros:
+
+    - Good technical features.
+
+
+Cons:
+
+    - Not very common in use by open cores.
+
+
+
+### Wishbone
+Wishbone [#fn15 (15)][#fn16 (16)] (often written WISHBONE) is an open interconnect
+standard developed by members of the OpenCore project as an alternative
+to commercial solutions - primarily AMBA.
+
+Wishbone supports bus based as well as switch fabric interconnect
+solutions of Wishbone cores. There are cores and tools to create CPU
+based systems with buses and fabrics. Technically Wishbone is simpler
+that AMBA and CoreConnect, but provides multimasters, point to point
+switch fabrics, etc.
+
+There are tools available to generate Wishbone interfaces for a core as
+well as creating a Wishbone connected system with different types of
+interconnect solutions.
+
+The main use is related to the OpenRISC CPU core platform
+[#fn17 (17)][#fn18 (18)]. OpenCores lists a huge selection of cores with Wishbone
+support. The majority of these cores have LGPL and GPL licenses. There
+are also third party commercial vendors that support Wishbone cores and
+systems.
+
+The license for the Wishbone standard is public domain and dos not
+impose any restrictions on usage in cores and systems. The
+specification document itself is close to Creative Commons CC-BY.
+
+Pros:
+
+    - Fairly good technical support.
+    - Good support from open tools and cores.
+    - Public domain license.
+
+
+Cons:
+
+    - Not as advanced. No good coherency support for example.
+
+
+
+## Conclusions
+OF the different standards, only two standards are really interesting
+for Cryptech - AMBA and Wishbone.
+
+From a technical point of view, selecting AMBA would be the proper
+choice. AMBA provides all types of interconnect that a Cryptech
+implementation might need. Also, building a Cryptech implementation
+using third party cores (CPU cores for example) would be easier with
+AMBA than the other standards. Wher AMBA falls short is the questions
+related to licensing as well as the a bit less common support from open
+cores and tools.
+
+Based on ease of licensing, openness and availability of open cores,
+Wishbone is an easy choice. Wishbone would quite probably meet all
+performance and functionality requirements a Cryptech implementation
+might have. Integration with and support from commercial cores, tools
+and vendors will however not be as good. Choosing Wishbone will quite
+probably mean more work for the Cryptech project to deliver cores and
+tools. And for the users of Cryptech Wishbone may also require more work
+and thus reduce the interest Cryptech as a HSM solution.
+
+
+
+## References
+[=#fn1 (1)] https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture
+
+[=#fn2 (2)] http://www.arm.com/products/system-ip/amba/amba-open-specifications.php
+
+[=#fn3 (3)] https://en.wikipedia.org/wiki/LEON
+
+[=#fn4 (4)] http://www.arm.com/products/system-ip/amba/index.php?tab=AMBA+Trademark+Guidelines
+
+[=#fn5 (5)] http://www.altera.com/literature/manual/mnl_avalon_spec.pdf
+
+[=#fn6 (6)] http://www.altera.com/devices/processor/nios2/ni2-index.html
+
+[=#fn7 (7)] http://opencores.org/
+
+[=#fn8 (8)] https://en.wikipedia.org/wiki/CoreConnect
+
+[=#fn9 (9)] http://www.xilinx.com/products/intellectual-property/dr_pcentral_coreconnect.htm
+
+[=#fn10 (10)] http://www.xilinx.com/ipcenter/doc/ibm_click_core_connect_license.pdf
+
+[=#fn11 (11)] https://en.wikipedia.org/wiki/Open_Core_Protocol
+
+[=#fn12 (12)] https://en.wikipedia.org/wiki/Accellera
+
+[=#fn13 (13)] http://www.ocpip.org/
+
+[=#fn14 (14)] http://www.ocpip.org/license_signup.php
+
+[=#fn15 (15)] http://opencores.org/opencores,wishbone
+
+[=#fn16 (16)] https://en.wikipedia.org/wiki/Wishbone_(computer_bus)
+
+[=#fn17 (17)] http://openrisc.net/
+
+[=#fn18 (18)] http://opencores.org/or1k/Main_Page
+
+
+## Copyright and License
+
+This document has been written by Joachim Strömbergson.
+
+(c) 2014 SUNET - The Swedish University Network
+
+This document is licensed under a Creative Commons license (CC BY 3.0).
+For more information, see:
+
+https://creativecommons.org/licenses/by/3.0/
diff --git a/raw-wiki-dump/Joachim%20Str%C3%B6mbergson.md b/raw-wiki-dump/Joachim%20Str%C3%B6mbergson.md
new file mode 100644
index 0000000..dcf0a94
--- /dev/null
+++ b/raw-wiki-dump/Joachim%20Str%C3%B6mbergson.md
@@ -0,0 +1,336 @@
+# Joachim Strömbergson
+## Bio
+
+
+## Current activities
+
+* Developing coretest - a core testing framework for FPGAs.
+* Implementation of UART
+* Verification of SHA-256
+* Verification of SHA-1
+* Implementation of AES-128
+* Design proposal for TRNG
+* Design proposal for Curve25519 accelerator
+
+
+
+## Work Notes
+### Presentations from meeting 2014-03-10 (updated and extended):
+
+* [browser:/doc/presentations/Cryptech_HW_status_2014-03-10.pdf "Cryptech HW status 2014-03-10"]
+* [browser:/doc/presentations/Cryptech_TRNG_Ideas_2014-03-17.pdf "Cryptech TRNG Ideas 2014-03-17"]
+
+
+### Open EDA Tools
+
+* http://torc-isi.sourceforge.net/index.php - Torc is an open-source C++ infrastructure and tool set for reconfigurable computing
+
+
+
+### Curve25519
+We need to create an accelerator or possibly a complete implementation of the Curve25519 EC based DH-excgange.  We should be able to look at some previous work:
+
+
+* http://eprint.iacr.org/2013/375 - NaCl on 8-Bit AVR Microcontrollers. Includes an iterative implementation of Curve25519
+* http://cryptojedi.org/crypto/index.shtml - The code to the implementation
+* http://nacl.cr.yp.to/ - The main NaCl library by DJB.
+* http://cr.yp.to/ecdh/curve25519-20060209.pdf - The Curve25519 paper by DJB.
+
+
+
+## Pre meeting notes
+
+### Stockholm 2013-12-05 - 2012-12-06
+Preparation notes for the OpenHSM meeting 2013-12-05 --
+2013-12-06. The notes contains topics, questions and ideas
+I want to bring up, check and discuss on the meeting.
+
+Philosophy
+----------
+
+- How to build trust in the project?
+    - Total openess and transparency
+    - Traceability of decisions
+    - Focus on simple third party validation
+    - Partitioning of security functions
+
+
+
+Project goal
+------------
+
+- Low cost vs high performance
+
+
+
+- Scalability
+    - Functionality
+    - Performance
+    - Security
+
+
+
+- Target system
+    - Performance
+
+
+
+    - Self contained, external
+        - USB,
+        - Ethernet
+
+
+
+    - Integrated
+        - PCIe
+        - Mem module
+        - SD card
+
+
+
+- Target users
+    - Single user
+    - Enterprise
+
+
+
+- Roadmap and development plan
+    - Prototyp - första målplattform
+    - Establish first Use cases
+
+
+
+- Deliveries
+    - Proof of concept, prototype
+    - Self assembly and/or finished product
+    - Source code for SW, HW
+    - PCB
+    - Enclosures
+    - Development environment
+    - Test, validation environment
+    - Tool development
+
+
+
+    - Time plan
+        - Start when
+        - Proto when
+        - v 1.0 when
+
+
+
+
+Project management
+------------------
+
+- Status financing
+
+
+
+- Ownership
+
+
+
+- Oveerseeing board
+    - IETF, ISOC,... ?
+
+
+
+- Advisory board
+    - Reviewers, external experts
+        - FPGA key extract dude
+        - DJB
+
+
+
+- Team
+    - Addtiona competency needed?
+
+
+
+- Project security
+    - Communication
+    - ...
+
+
+
+Development general
+-------------------
+
+- License(s)
+    - GPLv2, v3
+    - BSD
+
+
+
+- Methodology
+    - Agile
+    - Minimal functionality in PoC
+    - Clear increments
+
+
+
+- Repository
+    - Github
+
+
+
+Technology
+----------
+
+- Target technologies
+    - FPGA (+ internal, external CPUs)
+    - ASIC
+    - Pure CPU based
+
+
+
+- Target PoC board
+    - Select one early
+
+
+
+- Toolchains and languages
+    - SW
+    - HW
+        - Verilog 2001, 2005, SystemVerilog
+        - Icarus, gplcver
+        - Vendor specific
+        - Validation of bitstream
+            - Edge of trust, dowm the Rabbit hole
+
+
+
+- Security support in design
+    - JTAG
+    - BIST for functionality
+    - BIST for security
+        - KATS
+
+
+
+    - On-line self check
+        - RNG
+            - Pathological problems
+                - Stuck at fixed values
+                - variance
+                - bias
+
+
+
+- Reuse of existing design, code?
+    - Cores - OpenCores
+        - OpenRISC
+        - AES, SHA, RSA
+    - SoftHSM - DNSSEC PKCS#11
+    - Nettle
+    - ...
+
+
+
+- On chip 32-bit or 64 bit CPU core
+    - OpenRISC
+        - LGPL
+        - http://openrisc.net/
+        - http://opencores.org/or1k/Main_Page
+        - https://en.wikipedia.org/wiki/OpenRISC
+
+
+
+- RNG
+    - More than one entropy source
+        - Just external sources
+            - User/vendor/implemented supplied
+        - One external, one internal
+            - YubiHSM entropy source: https://www.yubico.com/products/yubihsm/
+            - Haveged: http://www.issihosts.com/haveged/
+            - DakaRand: http://dankaminsky.com/2012/08/15/dakarand/
+            - Jytter a userspace RNG: http://www.chronox.de/
+            - CPU Jitter RNG: http://www.chronox.de/
+        - CSPRNG based on Linux, OpenBSD, Fortuna, NIST etc.
+            - NIST SP 800-90. CTR_DRBG
+            - Fortuna https://en.wikipedia.org/wiki/Fortuna_PRNG
+                - Schneier, Ferguson. No estimator needed.
+            - OpenBSD arc4random: http://www.openbsd.org/cgi-bin/man.cgi?query=arc4random&sektion=3
+        - Raw read access in test mode to collected entropy pre whitening
+        - Write access in test mode to CSPRNG
+        - No key generation etc allowed during test mode.
+
+
+
+Technical requirements
+----------------------
+
+- Functional requirements
+    - TLS 1.x
+    - Need roadmap for functions
+        - AES, SHA-256, DH, RSA first iteration
+    - Why GOST?
+    - Why MD5?
+    - Curves supported?
+        - Curve25519
+        - NIST, IEEE, RFC 4xxx
+
+
+
+- HW/SW partitioning
+    - Modularity
+
+
+
+- API
+    - DMA, buffering, formats
+    - PKCS#11
+    - Observability and control
+
+
+
+- Security requirements
+    - Common Criteria - EAL
+    - FIPS 140-2 level 3-4
+
+
+
+- Performance
+    - Operations/s
+    - Packets per second
+    - Latency
+
+
+
+Validaiton
+----------
+
+- Methodology
+    - Unit tests, KATs
+
+
+
+- Documentation
+    - What to document
+    - How
+
+
+
+- Reviews
+    - Plan for them
+    - Who to ask
+
+
+
+- Tools
+    - Valgrind, Purify, linters
+
+
+
+Documentation
+-------------
+
+- Meetings
+    - Discussions, MoMs
+    - Decisiona - motivation
+
+
+
+    - Design
+    - Test and validation
diff --git a/raw-wiki-dump/MailingLists.md b/raw-wiki-dump/MailingLists.md
new file mode 100644
index 0000000..95cb5cf
--- /dev/null
+++ b/raw-wiki-dump/MailingLists.md
@@ -0,0 +1,37 @@
+# Communications
+
+## Mailing Lists
+
+The following lists are open to all:
+
+* Cryptech Project Announcements\\
+
+  announce@cryptech.is\\
+  [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/announce)\\
+  [Announce List Archive](https://lists.cryptech.is/archives/announce/)
+
+* General technology and engineering list\\
+
+  tech@cryptech.is\\
+  [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/tech)\\
+  [Tech List Archive](https://lists.cryptech.is/archives/tech/)
+
+* Repository commit watch list (posting restricted)\\
+
+  commit@cryptech.is\\
+  [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/commits)\\
+  [Commit List Archive](https://lists.cryptech.is/archives/commits)
+
+The following lists require approval for subscription:
+
+* Cryptech Project Core Team\\
+
+  core@cryptech.is\\
+  [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/core)\\
+  [Core List Archive](https://lists.cryptech.is/archives/core/)
+
+* Finance, funding, administration\\
+
+  org@cryptec.is\\
+  [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/org)\\
+  [Org List Archive](https://lists.cryptech.is/archives/org/)
diff --git a/raw-wiki-dump/MiscStuff.md b/raw-wiki-dump/MiscStuff.md
new file mode 100644
index 0000000..8742c7b
--- /dev/null
+++ b/raw-wiki-dump/MiscStuff.md
@@ -0,0 +1,36 @@
+# References & Miscellaneous
+
+## Interesting research and people
+Advisory board, reviewers etc.
+
+### Elliptic Curves
+
+* [http://safecurves.cr.yp.to/](http://safecurves.cr.yp.to/). Including Curve3617.
+* [http://www.nsa.gov/ia/_files/nist-routines.pdf](http://www.nsa.gov/ia/_files/nist-routines.pdf). Details for implementing NIST curves.
+* [http://blog.cr.yp.to/20140323-ecdsa.html](http://blog.cr.yp.to/20140323-ecdsa.html) djb on How to design an elliptic-curve signature system
+
+
+
+### Side channel attacks
+
+* [http://www.cl.cam.ac.uk/~sps32/](http://www.cl.cam.ac.uk/~sps32/), Dr Sergei Skorobogatov
+* [BSI - Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_46_ECCGuide_e_pdf.pdf)
+
+
+## Useful References
+
+
+* [Remote timing attacks are practical](https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-timing.html), D. Boneh and D. Brumley.
+* [Common Critiera Security Target for the AEP Keyper](http://www.cybersecurity.my/mycc/document/mycpr/C037/AEP_Keyper_EAL4_ASE_1.3.pdf)
+* [Cryptographic hardware: how to make it cool, fast and unbreakable](https://www.cosic.esat.kuleuven.be/ches2012/tutorials.shtml),
+
+  Junfeng Fan, KU Leuven
+
+* [REC FPGA Seminar IAP 1998](http://web.mit.edu/bunnie/www/xi/rec.html), Bunnie Huang
+* [the formal verification of realistic compilers usable for critical embedded software](http://compcert.inria.fr/)
+
+
+## Somewhat Related Web Sites
+
+
+* [List of Open SW Alternatives](https://prism-break.org/)
diff --git a/raw-wiki-dump/NoisyDiode.md b/raw-wiki-dump/NoisyDiode.md
new file mode 100644
index 0000000..6a9caee
--- /dev/null
+++ b/raw-wiki-dump/NoisyDiode.md
@@ -0,0 +1,28 @@
+
+## Noisy Diode entropy source
+
+The Cryptech project is using Avalanche Noise as a physical entropy source connected to the FPGA.
+
+Avalanche breakdown is a physical process that occurs when current is forced backwards through a diode until it cannot hold back anymore. The diode will then begin conducting for a brief time until the voltage drops to a point where the diode recovers. The breakdown and recovery points are not deterministic, and can thus be used as a source of real physical entropy.
+
+The unamplified noise looks like this:
+
+[[Image(noise1.jpg)]]
+
+After amplification, details are lost but the signal is now 3.3V (blue is noise before amplification, yellow is amplified)
+
+[[Image(noise2.jpg)]]
+
+Many implementations on the Internet feed a similar signal into an ADC (Analog Digital converter) and use the resulting data value at the time of the sampling as entropy. The Cryptech project believes a more robust way of extracting entropy is to instead feed the noise to a Schmitt trigger and then measure the time between rising edges. This would be more robust since any analog reading of the noise (such as with an ADC) will be sensitive to changes in temperature, supplied voltage and component aging.
+
+After beeing fed through a Schmitt trigger, the noise looks like this (yellow signal, blue is just a 4 MHz clock):
+
+[[Image(noise-schmitt.jpg)]]
+
+The Cryptech project has to date made a couple of different hardware entropy source boards, but they all share the same design for the avalanche noise source. The core parts of the circuit are shown below. Git repository with full schematics and source code is linked at the bottom of this page.
+
+[[Image(noise-schematics.png)]]
+
+Links:
+
+[[GitRepositories/user/ft/stm32-avalanche-noise| Raspberry-Pi / USB entropy source]]
diff --git a/raw-wiki-dump/OpenCryptoChip.md b/raw-wiki-dump/OpenCryptoChip.md
new file mode 100644
index 0000000..521d19c
--- /dev/null
+++ b/raw-wiki-dump/OpenCryptoChip.md
@@ -0,0 +1,183 @@
+[[PageOutline]]
+
+# An Open Crypto Chip
+
+## The Layer Cake Architecture Picture
+\\
+[[Image(layer-cake.jpg)]]
+
+\\
+\\
+## Use Cases
+
+* RPKI/DNSSEC Signing
+* Transport VPNs
+* Routers and TCP/AO
+* Email
+* Federations, Identity Systems, SSO etc
+* Password Stretching & HMAC:ing
+* PGP and SSH Keys on a Stick
+* High Quality Entropy Randomness
+* A Communications Terminal Doing One Thing Well, Like Jabber w/o X11
+* HSM for Pond, OTR identity keys, ssh private keys, etc. (i.e. key gen, store, import/export non X.509 packages)
+* Password management
+
+
+[[Image(cryptech venn.png)]]
+
+## Basic Functions of Crypto Chip
+
+* Key Generation
+* Key Storage
+* Key Wrap
+* Key Unwrap
+* Hash
+* Sign
+* M of N Sign
+* Verify Signature
+* Encrypt
+* Decrypt
+* KDFs, e.g. Password Stretching (a la PBKDF2)
+* Random (RO + noisy diode?)
+
+
+## Key wrapping
+We need to support key wrapping. Some pointers:
+
+
+- https://en.wikipedia.org/wiki/Key_Wrap
+- http://tools.ietf.org/html/rfc5297
+- http://csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf
+- https://tools.ietf.org/html/rfc3394
+- https://tools.ietf.org/html/rfc5649
+
+
+
+## Things we Should Try To Do, Even if we Can't Do Them Perfectly
+
+* Tamper Protection (wipe on signal, suggest detectors, suggest potting features)
+* Side Channel Attack Reduction
+
+
+
+
+# Rough Cut at v0.01 Proof of Concept Feature Set
+As a proof of concept, to validate as much as possible the assurance of the tools and methods, and as a demonstration of the project tools, team, and architecture, we have a [wiki:RoughV1 proposed version 0.01 product] as a proof of concept and a demonstration of the project tools, team, and architecture
+\\
+\\
+# Ongoing Decisions and Research
+
+* Security Target Description
+* Performance Target(s)
+* Tool-Chain Investigation
+* Prototype Design
+* Testing / Assurance Methods for all Components
+* Verilog/RTL assurance, with open source and with proprietary
+* Prototyping Platform(s)
+* Documentation, Decision History, & Transparency
+
+\\
+\\
+
+# Ongoing Development
+
+* [wiki:SunetInitialDevelopment "SUNET is sponsoring the first two development steps"] currently being done.
+* [wiki:TRNGDevelopment " Investigation and planning of a TRNG with entropy sources"]
+* [wiki:EDAToolchainSurvey" Investigation of possible EDA tools and ways to do open and assured HW development"]
+* [wiki:SideChannel" Collection about side-channel attacks and detection, mitigation methods"]
+
+
+# v0.1 Major Sub-Projects
+
+## Security Goals and Documentation
+
+* Agreement
+* Specification
+
+
+## Development Platform
+
+* The Bunnie laptop Novena. Includes a Xilinx Spartan 6 LX45 FPGHA. The specs, drivers, source for Novena can be found here: http://www.kosagi.com/w/index.php?title=Novena_Main_Page
+
+
+
+* TerasIC C5G Cyclone 5 GX Starter Kit. Includes an Altera C5GX FPGA. This board is used for core, subsystem development and verification. Info, documentation and ordering of the TerasIC board can be found here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
+
+
+Here is a writeup on how to [wiki:CoretestHashesC5G "setup and run coretest_hashes on the C5G board"].
+
+
+* TerasIC DE0-Nano board. This tiny, USB powered board is used for core development and verification. Info, documentation, resources, ordering of the TerasIC board can be found here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=593
+
+
+
+## Hardware Development Tools
+
+
+## Component Libraries
+
+* Research
+* Select
+* [wiki:InterconnectStandards "On-chip Interconnect Standards"] to use.
+
+
+## Methods and Validation
+
+* Overall Strategy
+* Following the Tool-Chain
+
+
+## Detailed Specification
+
+* Feature Set
+
+
+## QA & Documentation
+
+## Green/Yellow Software Support
+
+* Spec / ABI
+* Development
+* Documentationa and Testing
+
+
+## Assured Linux Platform
+
+* DDC Compiler
+* System Build
+* Minimal Component Set
+
+
+# v0.1 Project Timeline
+
+## February 2014
+
+* Specification of v0.1 Goals and Feature Set
+* Security Goals & Documentation Outline
+
+
+## July 2014
+
+* SHA & AES
+
+
+## September 2014
+
+* TRNG
+* Assured Linux Platform - Initial Report
+
+
+## November 2014
+
+* Security Goals & Documentation Overall and v0.1
+* RSA Signing on Bunnie Board
+* Assured Linux Platform - Compiler
+
+
+## March 2015
+
+* v0.1 Protoype
+
+
+# Future Development
+The v0.1 version of CrypTech is not the last version nor the only possible version. The project for example consider possible [wiki:ASICImplementations "ASIC Implementations"].
diff --git a/raw-wiki-dump/OpenDNSSEC.md b/raw-wiki-dump/OpenDNSSEC.md
new file mode 100644
index 0000000..49e2868
--- /dev/null
+++ b/raw-wiki-dump/OpenDNSSEC.md
@@ -0,0 +1,138 @@
+# DNSSEC signing using OpenDNSSEC and a Cryptech alpha board rev03
+
+## Before you start, you'll need
+
+
+- A Cryptech Alpha board, preferrably revision "rev03"
+- APT on the host system configured to find packages in the Cryptech
+
+  repository, see BinaryPackages for instructions
+
+```
+apt-get install cryptech-alpha opendnssec opensc
+```
+
+Once you have the software package installed, you may need to [wiki:Upgrading upgrade your HSM's firmware].
+
+## Configure the HSM
+
+For now, connect USB cables to both the DATA and MGMT ports of your HSM and plug them into the host where you will be running OpenDNSSEC.
+In production use it should not be necessary to leave the MGMT port connected, but it's easier to set up this way, and, as this is still a development platform, this is the configuration that's gotten the most testing.
+
+```
+# eval $(cryptech_probe)
+# cryptech_muxd &
+# cryptech_console
+
+Username: wheel
+Password: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+
+cryptech> keystore set pin wheel supersikritnewpw
+cryptech> keystore set pin so 123456
+cryptech> keystore set pin user 1234
+
+cryptech> masterkey set EFBEADDE
+^C
+```
+
+Leave `cryptech_muxd` running, so that the PKCS !#11 library can use it to talk to the HSM.
+
+
+## Configure OpenDNSSEC
+
+```
+mkdir /var/lib/opendnssec/cryptech
+
+cat > /var/lib/opendnssec/unsigned/example.com << EOF
+\$TTL 600
+example.com.  IN SOA  hidden-master.example.com. hostmaster.example.com. (
+                                2016041401 ; serial
+                                720        ; 28800      ; refresh (8 hours)
+                                720        ; 7200       ; retry (2 hours)
+                                300        ; 604800     ; expire (1 week)
+                                120        ; 3600       ; minimum (1 hour)
+                                )
+
+               NS      lab.cryptech.is.
+test           A       127.0.0.1
+EOF
+
+chown -R opendnssec: /var/lib/opendnssec/*
+```
+
+
+## OpenDNSSEC configuration changes
+
+/etc/opendnssec/conf.xml:
+
+```
+<Repository name="Cryptech">
+        <Module>/usr/lib/libcryptech-pkcs11.so</Module>
+        <TokenLabel>Cryptech Token</TokenLabel>
+        <PIN>1234</PIN>
+        <SkipPublicKey/>
+</Repository>
+```
+
+The PIN is whatever was chosen as PIN for 'user' above.
+The TokenLabel has to be "Cryptech Token", not something you choose.
+
+
+/etc/opendnssec/kasp.xml:
+
+    s/SoftHSM/Cryptech/
+
+/etc/opendnssec/zonelist.xml:
+
+```
+<Zone name="example.com">
+        <Policy>lab</Policy>
+        <SignerConfiguration>/var/lib/opendnssec/signconf/example.com.xml</SignerConfiguration>
+        <Adapters>
+                <Input>
+                        <Adapter type="File">/var/lib/opendnssec/unsigned/example.com</Adapter>
+                </Input>
+                <Output>
+                        <Adapter type="File">/var/lib/opendnssec/signed/example.com</Adapter>
+                </Output>
+        </Adapters>
+</Zone>
+```
+
+
+## Initialization and signing
+
+Make the deamons reload their configuration:
+
+```
+    service opendnssec-enforcer restart
+    service opendnssec-signer restart
+```
+
+Initialize opendnssec:
+
+```
+    ods-ksmutil setup
+```
+
+That should be it!
+
+See /var/log/syslog for output from ods-kaspcheck, ods-enforcerd and ods-signerd.
+See /var/lib/opendnssec/signed/ for a signed example.com zone.
+
+To list keys using ods-ksmutil, accessing the HSM using pkcs11
+directly (rather than going through any of the opendnssec daemons),
+export the environment variables from /etc/default/opendnssec and run
+"ods-ksmutil keys list --verbose":
+
+```
+# ods-ksmutil keys list --verbose
+SQLite database set to: /var/lib/opendnssec/kasp.db
+Keys:
+Zone:                           Keytype:      State:    Date of next transition (to):  Size:   Algorithm:  CKA_ID:                           Repository:                       Keytag:
+example.com                     KSK           ready     waiting for ds-seen (active)   2048    8           7f9b9329480ebe5dc81054ccb293e261  Cryptech                          62642
+example.com                     ZSK           active    2016-07-13 19:04:30 (retire)   1024    8           97e972633613bd605944a0531ff5399b  Cryptech                          56620
+```
+
+If the output for repository is "Cryptech NOT IN repository",
+ods-ksmutil has not been able to actually list the keys in the HSM.
diff --git a/raw-wiki-dump/PKCS11Proxy.md b/raw-wiki-dump/PKCS11Proxy.md
new file mode 100644
index 0000000..e0776a3
--- /dev/null
+++ b/raw-wiki-dump/PKCS11Proxy.md
@@ -0,0 +1,50 @@
+The pkcs11-proxy is a way to tunnel PKCS11 over TCP (TLS). This page explains how to build and install PKCS11 proxy on the novena. There are various forks of this on github. We're going to use the SUNET fork since it support TLS-PSK for authentication out of the box. The proxy does not currently support different word length on each side of the tunnel so to use it with the novena platform your PKCS11 client must be 32 bit.
+
+## Why would you want this?
+
+Not all applications will run on the arm-based novena. For instance not all parts of opendnssec is not fully ported to arm (and probably never will be).
+
+## Building PKCS11 proxy
+
+```
+# apt-get -y install git cmake libssl-dev
+# git clone https://github.com/SUNET/pkcs11-proxy
+# cd pkcs11-proxy
+# mkdir build
+# cd build
+# cmake ..
+# make
+# make install
+```
+
+## Setting up pkcs11 proxy on the novena
+
+Next create a pre-shared secret for TLS authentication...
+
+```
+# (echo -n "psk:"`xxd -l 16 -p /dev/random`; echo) > psk.txt
+```
+
+The resulting file (psk.txt) needs to be present both on the server and client side of the PKCS11 tunnel so copy it (or its one-line content) to the client side of your proxy.
+
+Now start a pkcs11 proxy daemon:
+
+```
+# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11_DAEMON_SOCKET="tls://<your ip>:4444" pkcs11-daemon /usr/lib/libpkcs11.so
+```
+
+Now on another machine (where pkcs11-proxy has been installed) access the remote token via
+
+```
+# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11_PROXY_SOCKET="tls://<your ip>:4444" pkcs11-tool --module /usr/local/lib/libpkcs11-proxy.so -I
+```
+
+## Tracing PKCS11 calls
+
+If you want to trace the PKCS11 calls you can use pkcs11spy from the opensc package. If you install opensc look for an SO called pkcs11-spy.so. On the novena it is in /usr/lib/arm-linux-gnueabihf/pkcs11-spy.so. To use it set your environment variable PKCS11SPY to your real PKCS11 library and use pkcs11-spy.so instead. For instance to use PCKCS11 spy on the server side of the PKCS11 proxy start the pkcs11-daemon thus:
+
+```
+# env PKCS11_PROXY_TLS_PSK_FILE="psk.txt" PKCS11SPY="/usr/lib/libpkcs11.so" PKCS11_DAEMON_SOCKET="tls://<your ip>:4444" pkcs11-daemon /usr/lib/arm-linux-gnueabihf/pkcs11-spy.so
+```
+
+This should now generate lots of output when you run PKCS11 calls over the tunnel.
diff --git a/raw-wiki-dump/PageTemplates.md b/raw-wiki-dump/PageTemplates.md
new file mode 100644
index 0000000..00e3ca8
--- /dev/null
+++ b/raw-wiki-dump/PageTemplates.md
@@ -0,0 +1,18 @@
+# Wiki Page Templates
+
+The default content for a new wiki page can be chosen from a list of page templates.
+
+That list is generated from all the wiki pages having a name starting with *PageTemplates/*.
+The initial content of a new page will simply be the content of the chosen template page, or a blank page if the special *(blank page)* entry is selected. When there are no wiki pages with the *PageTemplates/* prefix, the initial content will always be the blank page and the list selector will not be shown, ie this matches the behavior we had up to now.
+
+To create a new template, simply create a new page having a name starting with *PageTemplates/*.
+
+Hint: one could even create a *PageTemplates/Template* for facilitating the creation of new templates!
+
+After the first template has been created, a drop-down selection box will automatically appear on any new wiki pages that are created. By default it is located on the right side of the 'Create this page' button. The default selection will be *blank page*, or *DefaultPage* if *PageTemplates/DefaultPage* exists.
+
+Available templates:
+[[TitleIndex(PageTemplates/)]]
+
+----
+See also: TracWiki
diff --git a/raw-wiki-dump/PhotoFolder.md b/raw-wiki-dump/PhotoFolder.md
new file mode 100644
index 0000000..e60ef0c
--- /dev/null
+++ b/raw-wiki-dump/PhotoFolder.md
@@ -0,0 +1,10 @@
+
+## Note: Copyright
+
+Rules for use:
+non-commercial, must include photo credit of (c) Stonehouse Photographic
+
+## Note: Banner / Carousel Photos
+
+These work best when the focal point lies to the right. Title and caption from posts will overlay the left-hand side of the carousel. To crop these images, you will generally want to cut off extra pixels from the left of the image (though there is room on some to cut from the right as well). Crop the carousel images to 1920 x 600 pixels.
+
diff --git a/raw-wiki-dump/PostAlphaPlan.md b/raw-wiki-dump/PostAlphaPlan.md
new file mode 100644
index 0000000..aadc44a
--- /dev/null
+++ b/raw-wiki-dump/PostAlphaPlan.md
@@ -0,0 +1,71 @@
+
+The core dev team had a design meeting in Berlin after the alpha workshop. We came up with a plan for the hardware and the software work for the next few months:
+
+## Hardware
+
+### Revision 04
+
+This is targeted for the mid-flight revision in the 50 board order from propoint. For practical reasons, we should limit ourselves to bugfixes and other "low risk" changes for this release.
+
+
+* On-board battery (super-cap, long battery life etc, battery outside the tamper boundary etc)
+* Next generation USB based on Stuges daughter board work
+* Support higher clock speeds
+* Proposed: pull out 2 more UARTS from the STM32 to support memory-card readers and pin-entry devices
+
+
+### Revision 05
+
+
+* Power instrumentation
+* EMC
+* Tamper revisions??
+
+
+## Software
+
+The software plan is divided into 3 parts: "now", "next week" and "next month". These are labels, not a time frame. The "now" list represents stuff that is currently seeing active work. We move stuff from "next week" to "now" and from "next month" to "next week" as part of our planning process (at the engineering calls).
+
+### Now
+
+
+* CLI updates [Done, but waiting on a BSD-friendly license]
+* rewrite keystore code to support larger keysizes and more slots [Done]
+* multi-core resource management [Done]
+* finish verilog EC point multiplier [Done]
+* increase clock speed
+* openssl engine [Done]
+* debug log [Mechanism done, nothing using it yet]
+* usb driver matching rev04 usb updates
+
+
+### Next Week
+
+
+* GOST drivers
+* key backup [Done]
+* SHA3
+* ECDSA verilog [Done]
+* build system configuration management
+* real documentation: user, admin and dev manuals
+* Python RPC client [Done]
+* set time and date from CLI
+
+
+### Next Month
+
+
+* 25519 verilog
+* design papers
+* doxygen
+* m of n
+* notify ARM and FPGA of tamper events
+* secure channel
+* ECDH
+* AES drivers
+* audit logging
+
+
+### Eventually
+
+* Profiling [Mechanism done]
diff --git a/raw-wiki-dump/PrahaWorkshop.md b/raw-wiki-dump/PrahaWorkshop.md
new file mode 100644
index 0000000..6638dce
--- /dev/null
+++ b/raw-wiki-dump/PrahaWorkshop.md
@@ -0,0 +1,86 @@
+[[PageOutline]]
+
+# CrypTech Workshop - 2015.07.18 Praha
+
+## Logistics
+
+* Hilton Hotel, the IETF venue
+* Amsterdam Room (this is a change)
+* 09:00 - 17:00
+
+
+## Introductions
+
+* The CrypTech Team
+* Others Who Have Contributed
+* Other Folk at the Meeting
+
+
+## Workshop Goals
+
+* Get an understanding of the project status and roadmap
+* Discus your requirements and expectations with the team
+* Get hands-on experience with the cryptech code on the novena dev board
+* Procrastinate finding a new name for the project
+* NON-GOAL: you don't get to go home with hardware
+
+
+## Overview of Project
+
+* Overall Goals
+    * A Set of Designs, not a product
+    * Save the World, Securely :)
+* Short Term Goals
+    * Sign a DNSSEC Zone
+    * Sign RPKI Data
+* Roadmap
+    * Novena Dev Platform
+    * Noise Board
+    * Bridge Board
+    * Alpha Board
+    * Better/Beta Board :)
+
+
+## Status
+
+* Novena, Bridge, and Alpha Hardware
+* Verilog Cores
+* Software
+* APIs
+* Current Build and Work Packaging
+
+
+## User Feedback So Far
+
+## Workshop 0
+
+* Unpack Novenas
+* Install Noise Board
+* Build Bitstream and Download
+* Build Software and Install
+* Install DNSSEC Signware on Your Laptop
+* Sign a Zone
+
+
+## User Feedback So Far
+
+## Workshop 1
+
+* Unpack and Install Bridge Boards
+* Build Software and Install
+* Install DNSSEC Signware on Your Laptop
+* Sign a Zone
+
+
+## User Feedback
+
+## Morning coffee break :)
+
+## You Should Bring
+
+* Laptop
+* MacOSX, Linux, or ?  (if you want to build FPGAware, debian 64-bit, and it needs a desktop, VM OK)
+* Micro-SD card if you want to take images and/or data home
+* Logic Analyzer (optional, for hardware geeks)
+* JTAG Interface (optional, for hardware geeks)
+* Cookies or Equivalent to Share
diff --git a/raw-wiki-dump/PrahaWorkshopSSH.md b/raw-wiki-dump/PrahaWorkshopSSH.md
new file mode 100644
index 0000000..a48c5b6
--- /dev/null
+++ b/raw-wiki-dump/PrahaWorkshopSSH.md
@@ -0,0 +1,16 @@
+## The list of all known SSH keys
+
+```
+
+
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZJUtfVH0KQfdGhVetTQRpg9Ki8xGKNnO07r6df9DrrmDrsHVSsDOv8zxMoNh4XHbaLtmSCT8IkB8xLU6dXVCH4vWZZwfzaKKRNgMOSfOSc6blKKBV6xEw9qXeMe4dWcfknl3yAr6EqYsg5Lrmqgalr8Vyd6FGAoGbLR4Qh7vrahMqXp3+20kn1xfDm5reSJDbNPmU4eNhJykTNtr6l6CbK/OFzhqcMI/AW5AO0wL8f5wIoHQzescZWQMDMW+1gVyDiS8lGS6nhsSZwZZeAJrXHK/LF3ldz1To5HBxzpU5Sziav8C5bgTeYo5YfqDuBq8m9mgZTzqocXFcXUCr0I6x dol@dolmacbook
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnskRpNxWJE/YgDR3o6sMWwwmbUJ8f2SJa0gHfHM+fcxxC2zQN9/9mqJSxS1E9QdeuRbbHpYxEUtHoX0vSrmia/VALDiQAMps51RBqq6YlrYqvP/Rb0hZ0Z4/YgjTosLdu1PeTzih6mwbyNNF0+gY987Ig31qXQytNF+9G1oSY9dgBAq52lu170QXTRwum4B6Gh4/pCnM6xx+7nY2oqlgvl2wYHVAOJ39W9r4y9kBhcVs51XvJqYehjaoyKYf1+PzA0FsvhJkZuG6ws5eEGSB90lAzKGyFZXedvOLmnFmqAraoLeuKajHIFJDfKNfHHbYpn8ERIfVW66nbqlXFO2g3 fredrik@thulin.net
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCo3wT4gGyEmGGw5ePMO+jscvq7lo4hIPQHVZNgrChVWphvD1MkkH6PfoUYNfKwagFjUPQcDotQxGaVfvxL6Y4WzOfwiONHTj/4b2skxdRw5B/K2ZnGw2pbfXP4Nhjb1gry2K+BSVWqP3pVZk5tQ+P0YqbwKNfBFlaqS1dR8uIwo6E/8wGIjcMcDMAioMyRlU2R/u1aXQliol75GWu0jP9xrDyE3mRxoptn7kiUi9JAs/iZtlsiJh51IOADhhNMLWcmQEzKrcR2zytWZqEPzCx9C72/nPl3WacNXqdrMMT5tjt18TOFCf1jhBCHzXMu+biaoHB5sSBtue0zLFyO1A1XxLYxCp+jqlwJm2xAkS1rpFhdW3qlJZe0dV3a3TwepMGi/ObhggEk8ygwDNpYPEbgKqBcKb5RMpPJS2aEKbKd1+UStCagwPNwgRLrBME9YIAI9zyN8sFgHyy70q2XzhUJ5zz+X8JMVaKEKMTVh31u01jQchdvHkkGD7/xbp3hluFOCI1ChYKSlRdakoS6XnPopZ/0tHrkpk+k5lScu9lPHvBTMa3gq+b++TDbkW8dtYq3c78xHcAmOEjXvezbTnKpe/dRfWEUbmrGOch3mzDPoYAtjj7fdEWUGELhCSJB813B7HcGS6oXmW0PYEtOEIgeo83JX6i2qYiTQmjY1kOgBw== jakob@kirei.se
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDEK7I/KcbkhIevS+N88wBEA7OP+HtsULSxB0zl9xZO34mjCHfN6jQDYulwDbsk7IikRO4kn4cqPiaLkSX+8gXv/NsNqLXttK0x5Yt95Q25rXUMKYw/wkDxArD8k+wI71c41iTHyId1ZkHnUNmS9qxS2ajEhOCTYhB5xYYgeUscGwn6iiz5Ksjru28UnL/JZUZ3BHxm62XEHL6Yr9Bz/yzCKatm7+55eH0BMtiWFADtKEKz1nUGR8EUEIuchfQRZzXhmJmk+LNh+ft/BKcAjWKjz7LxncDH0fPqtRBYdB9dxziGozviYi20kVLzDdsOsnVL5lF9km1JtpyMyAHb7fbNA5xsCSge0rRL6+K5g4iX9QcCiTf12HjurHpFOktopItGtF60yyfbK2itBDlYiQxBSU75mvvllBxQ3gk47WCNrhuut/Uyyc8tjLmPdTIfc0+Mjz4owh3hfgNpJTO22jwo7CDtn/2bPe24aRpcrzldlMMi4jLLP58znCxabJFwAe9YrxavqGr9qcS1lBaGCrLc98vTix4eJFQQOazwJIFrDUDeeyuTo/ebAZ3nVQyRBTBDCfr1w06/OVAF9QLuxp2wFtuiVdw/DHZ93OwyCN/wDIC8yH/zJuLPKRD5PyBrQ14KLY/iLHw8scWcebvRvTrCc3SZkdXqhIySArXb+17Qzw== js@snabbis.local
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVvB4gdJ6EWRmx8xUSxrhoUNnWxEf8ZwAqhzC1+7XBY/hSd/cbEotLB9gxgqt0CLW56VU4FPLTw8snD8tgsyZN6KH1Da7UXno8oMk8tJdwLQM0Ggx3aWuztItkDfBc3Lfvq5T07YfphqJO7rcSGbS4QQdflXuOM9JLi6NStVao0ia4aE6Tj68pVVb3++XYvqvbU6NtEICvkTxEY93YpnRSfeAi64hsbaqSTN4kpeltzoSD1Rikz2aQFtFXE03ZC48HtGGhdMFA/Ade6KWBDaXxHGARVQ9/UccfhaR2XSjVxSZ8FBNOzNsH4k9cQIb2ndkEOXZXnjF5ZjdI4ZU0F+t7 leifj+00060AD478D6@sunet.se
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQVmVIptFt7ghSm5PpKw6uRQSEozHGKRN6AUyevyarfMuRONWvnFawTL/bqc6atX23dV6q0mIRzfUu+43ABjv5suwXaXoDw6rc6b8jElX/aJTDjea7n3i2hkhmGQwe8ibvjz2ZgNEkzz8NJSJI9nEzgPoHHM9/enpMb/saPWU/JFfPLAQ9XsQV+u1fhuTyrTlVynKN1iQxxCRjySD9boWo7XGQ8/0VBy28xS/eGDGs4Wty+SKT9QEabipyq7gqqsgoo87B1UUP98kawZF/wPMk5D+bWUej6dHaJEZECdAcalHlj7TCfJJM+ELHcQ8BD+4YzbkjTWPFG6ihI29bnV3z linus@nordberg.se
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfi07vngzbVdipBCSC+pDoauAck0nN45sV+u9A5vRLM9qwYIZm8XFlqJmKhmZMJWaY+rR4VCZKD8F8/Tmw26Q2kOG4tAajA2kZV+2Us0nXHE8YktKoLqojjSxMi73LT/CtAjbxNZNs6hAVKgIDqFyY7pJhrpNkVxQGMHB/MboVTqS1X3Jglm8J9T5/kNNU6brjErFCxQIOnLFJHczdcLMio31wK37jXZUWvbp8dXJrjNINU1r953hBibkZ178LODsitojXWsBckJZPxc43of7caGROesbIZQeGi/BKnxOgKWXresgeZngw8+hb5bQemI+ktbCQg3Exna7EHi6TGCLV paul@Darkstar-VirtualBox
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9+qRUZdFK9Fcweb3Zemice+QFDmqn0uXfjnB9xjIGXlzV7mi7mcDIMwRdL8es4CbNzx7gk8qbxl+bzSWlGrW8mE2smXicvb5aXAl1Gq7A1tmwb9j7Pb3/AUA0fonh086AjH/olVDHEXfE6fA+auMeW7NcYEAY4YBn9yrQSmvS4i3RcZtAETe+aCO/Cjl147DIeqH9hcSbBdEWdcH5Q0DIPYY1QnOlZAdphXDm3Kvr9poSX+2W6Zm8tRYJAATXh+gCFYWF2xig40k/5C0/jX48muuJ+gemav07PiOs6gwrvc2hJvhdHm5+3FoE2MaqPm7xZvEg0maLEvGSvydw0MQ9 paul@psgd.org
+ssh-dss AAAAB3NzaC1kc3MAAACBAMcyFrmcI06jwD2IEA5lvqNM84mr05eMIARy+JQ9f++tix9eMk5Y7b9Dmau3iYNG7WAEUtzEhj+ZO1QSMNqDX+TARAkesWHhRtNp5aTSpTrnyb7W74x7Wdjd0Zw6iQyYjzv8qYdcg3siN/POE6traHqzratuSrN9euEjXSq6lmutAAAAFQCo1RS1pRSCgmkTogCNHEqCnHDOOwAAAIEAg0XcJyRT3Er5oanfdQQT69mXfrGkcqGaahJchbIkVX9MDlFLmrAw8Av/77Plesq6uOgQuP1/tgJKN3gjW+n25S4Ly5L6P+vo8JH22+gSDWKdfjbf44xDRdorG19vbOrjynrZ/qZIS9UAdjT0aWiCkyRjhcqFpv3EvqXaqP/wpewAAACBAIu6JsMU53WWWDDVGtFVTKPkx1S0MF69xIOrVVbka88DzHsRg9qLqHlH/7TjVYv8Dzp4SBp1sf70JQhFgA0cPbQB7VcGX9rlJdvSqE2d695iSkJY8X08UrcSasjHbThtbjy1dsVXxiUV0Vt7rFYKaxlk4GJz83p8e7KorTiJMTu/ randy@psg.com
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCkrrpUCqIibbYB7v4Kr/B07yTGXJgMjAsFf+YHIC9WpcLvpe5v4+O8t4Q/WSMVETlkUZHIKVntHeLYLHIQVyL2njuM+MYShslz8lpc0Z/cIInpHSAM/rm9p/6MaKzAz8RODYe9Oxah34bNI7lXLUkNOBsUTRaKUA6jav/kfbPA/Y3ADIo8Hj1HcNfTxw6E+lmFAf3BkdzyvAmTGLIuv9BbD737B25BIERs5U0EltsdDvNPa3gMLyDt/slslu16WzBRE4tijf0Kbl7DyTeBKSi1EAaQe75N8cHgRSJe96ikkNqTy65vcKw41HTCoLzgJA/EuzwWgSvo96pK0uCM27R0+zlg1zp3Z6UQXDhKukmVYP72AF6Csk9BSkb3vURgMAwYDZQUKmzdd+YzE9sdmFa4fwYZmdHs+cC1XcU6uNbo3202yP/E5NiZ9wN8+fKqNpXVePUYPc8ACOYLBO3hjfvtwmXRM1rIcBgm5NbWotlCTmf6c2mfh+4tDtStSNGSf7a3bq9rHIS1GLDH0FNaWkjB+CKY5KnXF4vvMDqauDORt0pTH5OHsVsCgJjemwR0qHK6O7LxcSg8gzNvA5y4N/Pf6tcvoSNLbJoIF+XQ7oRhOYNPiR2gBziQ3paEMLsl57ewGOAvwT+O26wys1tmwcPr0FQHUnIzv+ecDY3oCw9fRw== sra@hactrn.net
+```
diff --git a/raw-wiki-dump/ProjectArchive.md b/raw-wiki-dump/ProjectArchive.md
new file mode 100644
index 0000000..0407c13
--- /dev/null
+++ b/raw-wiki-dump/ProjectArchive.md
@@ -0,0 +1,4 @@
+*Page Under Construction*
+
+# Project Archive and Far Future Planning
+## [wiki:AssuredTooChain Assured Tool Chain]
diff --git a/raw-wiki-dump/ProjectManagement.md b/raw-wiki-dump/ProjectManagement.md
new file mode 100644
index 0000000..aad8443
--- /dev/null
+++ b/raw-wiki-dump/ProjectManagement.md
@@ -0,0 +1,26 @@
+[[PageOutline]]
+
+# v0.1 Resources
+
+## Human - 4-5 FTE
+
+* 0.5 Specifications
+* 1.0 FPGA Tools and Core
+* 1.0 Core Libraries and Interfaces
+* 0.5 QA & Docs
+* 0.5 Assured Linux Platform
+* 1.0 Coordination
+
+
+## Hardware
+
+* 4 Bunnie Boards
+* 2 Altera Eval Systems
+* Linux Platform
+
+
+## Travel & Overhead
+
+* Travel $5k/mo
+* Communications $1k/mo
+* Administrative $1k/mo
diff --git a/raw-wiki-dump/ProjectMetadata.md b/raw-wiki-dump/ProjectMetadata.md
new file mode 100644
index 0000000..e9b9c70
--- /dev/null
+++ b/raw-wiki-dump/ProjectMetadata.md
@@ -0,0 +1,27 @@
+
+# Project Metadata
+
+## Project Logo Files
+
+* See "Attachments" at the bottom of this page
+* PhotoFolder
+
+
+== Meeting Presentations and Notes ==
+
+* DocMeet
+* PrahaWorkshop
+* BerlinWorkshop
+
+
+== Technical References	==
+
+* MiscStuff
+* InterconnectStandards
+* RandomnessTesting
+
+
+== Related Work ==
+
+* RelatedWork
+* SideChannel
diff --git a/raw-wiki-dump/ProjectStatus.md b/raw-wiki-dump/ProjectStatus.md
new file mode 100644
index 0000000..c42d475
--- /dev/null
+++ b/raw-wiki-dump/ProjectStatus.md
@@ -0,0 +1,19 @@
+*Page Under Development*
+
+# Project Status
+
+## [wiki:Dashboard Project Dashboard]
+
+## Crypto Chip Design and Prototype
+
+* PostAlphaPlan
+* AlphaBoardStrategy
+* AlphaBoardComponents
+* [Core Git Repository](http://trac.cryptech.is/wiki/GitRepositories/core)
+* [wiki:Hardware]
+* [wiki:DevBridgeBoard]
+
+
+## Pilot Project
+
+* [wiki:DNSSEC Requirements]
diff --git a/raw-wiki-dump/QuickStart.md b/raw-wiki-dump/QuickStart.md
new file mode 100644
index 0000000..75d5a3f
--- /dev/null
+++ b/raw-wiki-dump/QuickStart.md
@@ -0,0 +1,26 @@
+[[PageOutline]]
+*Page Under Development*
+
+# Git Repositories
+The team uses Git to store and track project development. All submissions are [signed](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work).
+
+The active repositories are automatically posted to GitRepositories.
+
+
+# The Alpha Board
+
+The current hardware is the AlphaBoard.  More information (to be organized at some point -- yes, this wiki is a mess, again):
+
+* AlphaBoardComponents
+* AlphaBoardPictures
+* AlphaBoardReview
+* AlphaBoardStrategy
+* AlphaReviewLog
+* AlphaSchematics
+
+
+The Alpha board currently ships with very old firmware, but you can [wiki:Upgrading upgrade it yourself].
+
+# DNSSEC signing using OpenDNSSEC
+
+* [[OpenDNSSEC]]
diff --git a/raw-wiki-dump/RandomnessTesting.md b/raw-wiki-dump/RandomnessTesting.md
new file mode 100644
index 0000000..0b14c59
--- /dev/null
+++ b/raw-wiki-dump/RandomnessTesting.md
@@ -0,0 +1,80 @@
+# Randomness Testing Tools
+
+This page explains some basics on testing for randomness, and the background necessary to understand their outputs.
+
+## Basic Considerations
+When testing the randomness of an alleged/assumed random bit/byte stream, there are two fundamentally different categories of tests: There are *blackbox* tests which are independent of the particular source, and *whitebox* tests tailored to the particular properties of the given source.
+
+For reasons rather unsurprising, the *blackbox* and *whitebox* categories largely correlate with the categories *publicly available tests from others* and *tests developed by the designers of the particular stream source*; this obviously leads to other issues concerning the trustworthiness and reliability of the tests---testing your own stuff is always a somewhat risky approach.
+
+All tests basically work by taking a certain part of the data space, declaring them as "not random" or possibly "suspect", and then comparing some test input against this partitioning.  Mathematically speaking, all the possible partitionings are equally relevant and as such any stream is equally "random" or "non-random", so choosing any partitioning definition is somewhat arbitrary.
+
+The usual *blackbox* tests are effectively based on tests used for non-crypto pseudo random number generators; as such, they are generally useful for quick, preliminary testing and for establishing confidence in the source by outsiders.  But to test the health of a source, eventually whitebox tests tailored to the failure modes of the given source are needed.
+
+
+## The `dieharder` Test Suite
+Dieharder is by far the most extensive blackbox test suite.  However, it is originally aimed at testing the output of non-crypto pseudo random number generators; aside from the limitations of using it for an entirely different purpose, it is rather notorious with regard to its need for extensive amounts of input.  Additionally, it runs all tests sequentially, rather than making use of today's multi-core multi-threaded CPU architectures; this leads to unnecessary I/O while reading an input file that doesn't fit the disk cache, and runtimes of about an hour or so depending on the sort of computer used.
+
+### Usage
+Generally the best approach to use `dieharder` is to first generate an output file, e.g. `random.out` to run the tests on, so `dieharder` can apply all its individual tests to the same data.  For a standard test, at least about 14 GB worth of data are needed; more if one of the tests needing large amounts of data returns a suspect result and `dieharder` re-tries the same test with more data.
+
+The command line options I (bs) personally use are `dieharder -g 201 -f random.out -s 1 -Y 1 -k 2 -a`:
+ -g 201 -f random.out:: Don't use a compiled-in pseudo RNG but the file `random.out` as input.
+ -s 1:: Rewind the input after every test.  Without this, successive tests use successive parts of the input file.
+ -Y 1:: Keep testing until a definite (in probabilistic terms:-) test result is obtained.
+ -k 2:: Use some high precision numerics for the KS test; recommended by the man page.
+ -a::   Run all tests.
+
+Additionally, these may be useful for more targeted testing:
+ -m <n>:: Multiply the `psamples` value by `n`; good for getting even more reliable results, at the expense of the additional data needed.
+ -d <test name/number>:: Perform a specific test.
+ -l:: List all available tests by name and number.
+ -p <n>:: Set the `psamples` value.  See below why you may need this.
+
+### Interpretation of Results
+The way `dieharder` works, it simply returns a clear assessment of the test results; interpretation should be immediately obvious.
+
+### Caveats
+There are a number of things to keep in mind when using `dieharder`, especially so when running it on a reduced amount of test data.
+
+    * If `dieharder` reaches the end of the input file, it rewinds and uses the same test data again.  This has rather drastic effects on several tests which assume that some sort of repetition in the input is a sign for a seriously flawed generator.
+    * The `-Y 1` option works by adding 100 to the value of `psamples` until a conclusive result is found.  This works reasonably well with tests that start with a value of 100 to `psamples`, but there are tests starting with 1000, and others starting with 1.
+    * The `-m <n>` option also just affects the initial value of `psamples`.
+    * Some of the tests themselves are marked as "suspect" or "do not use" if you run `dieharder -l`.  Still, `-a` runs them, for whatever reason.
+    * Expect about one test in a `-a` run to return a "weak" result that needs to be resolved.  According to the man page, about 1 in 1000 tests (not `-a` runs!) may fail despite the fact that the input is good.  In that case I suggest doubling the input size, either by using `-m <n>` (which only works in conjunction with `-a`) or by adjusting `psamples` and/or `tsamples` manually.
+
+
+### Installation
+The ["Dieharder home page"](http://www.phy.duke.edu/~rgb/General/dieharder.php) provides the source code as well as documentation. Dieharder is also available via package systems in Linux (apt-get install dieharder) and by brew for OSX.
+
+
+## The FIPS140-2 Test Suite `rngtest` from `rng-tools`
+While somewhat questionable in the way it has been defined in the FIPS140-2 document (and silently been removed in the -3 draft...), these tests are generally considered useful for a quick preliminary test on small amounts of test data.
+They generally work on blocks of 20000 bits.
+
+### Usage
+The `rngtest` program reads data from its standard input and by default returns a statistics overview when it reaches EOF.  This can be changed with these two options (among others):
+ -c <n>:: Stop running after `n` blocks.
+ -b <n>:: Give intermediate results every `n` blocks.
+Use at least one of these when running on a pipe or device...
+
+### Interpretation of Results
+Since `rngtest` works on rather small sample sizes it causes a significant number of false alarms:
+| Test         | Expected failure rate |
+|---|---|
+| Total          |  800ppm                 |
+| Monobit        |  100ppm                 |
+| Poker          |  100ppm                 |
+| Runs           |  300ppm                 |
+| Long run       |  300ppm                 |
+| Continuous run | Extremely rare          |
+
+These failure rates were however measured experimentally rather than derived from the algorithms themselves, so caveat utilitor.
+
+Seriously flawed inputs often show excessive failures from very small input; it is generally a good idea to keep testing until at least about 100 failures in total have occurred before seriously comparing the measured results to the expected failure rates from the table.
+
+
+
+
+
+
diff --git a/raw-wiki-dump/RecentChanges.md b/raw-wiki-dump/RecentChanges.md
new file mode 100644
index 0000000..0fed14f
--- /dev/null
+++ b/raw-wiki-dump/RecentChanges.md
@@ -0,0 +1,3 @@
+** [TitleIndex Index by Title] ** | ** Index by Date **
+
+[[RecentChanges]]
diff --git a/raw-wiki-dump/RelatedWork.md b/raw-wiki-dump/RelatedWork.md
new file mode 100644
index 0000000..8b48baf
--- /dev/null
+++ b/raw-wiki-dump/RelatedWork.md
@@ -0,0 +1,22 @@
+# Related Work
+
+## Richard Lamb / ICANN
+[Presentation at ICANN](http://ccnso.icann.org/file/32383/download/37379)\\
+[Presentation at ICANN](http://ccnso.icann.org/file/40211/download/52359)\\
+"I wrote pkcs11 libraries and also have modified BIND that offloads full
+RRSIG calculation (including time) to board.  Clearly can use anything
+other than TPM to do RSA calculations."
+
+## SoftHSM
+
+- ["SoftHSM"](https://www.opendnssec.org/softhsm/) - part of OpenDNSSEC
+- ["Possum"](http://wiki.cacert.org/Possum) - an earlier attempt att an Open Source HSM.
+
+
+
+## Project Turris - CZNIC
+[Project Thuris Web Pages](http://www.turris.cz/en/)\\
+Project Turris is a service helping to protect its user's home network
+with the help of a special router. It is a not-for-profit research
+project of CZ.NIC, z. s. p. o., the registry of the Czech national top
+level domain .CZ.
diff --git a/raw-wiki-dump/ReleaseNotes.md b/raw-wiki-dump/ReleaseNotes.md
new file mode 100644
index 0000000..43a7f5b
--- /dev/null
+++ b/raw-wiki-dump/ReleaseNotes.md
@@ -0,0 +1,32 @@
+[[PageOutline]]
+
+# Release Notes
+
+## 3.0, May 2017
+
+
+* New keystore implementation.  Basically a very small flash filesystem, including basic wear leveling.  Maximum number of keys varies depending on key size and how many options are attached, but for any reasonable use it should hold on the order of 2,000 keys at least.
+* In-memory keystore moved to HSM (previously was in memory of the client library), uses same API as flash keystore.
+* RPC mechanism extended to support the new keystores (`hal_rpc_pkey_match()`, `hal_rpc_pkey_set_attributes()`, etc).
+* PKCS !#11 code rewritten to use libhal attribute mechanism, sqlite3 database gone.
+* Verilog implementations of ECDSA base point multipliers for P-256 and P-384 curves, key generation and signing significantly faster than with software ECDSA implementation.
+* Key backup mechanism: two more RPC functions, and a Python script `cryptech_backup` to drive the process.
+* Private key representation changed to PKCS !#8 format (a self-identifying uniform format with optional encryption, supported by many other tools).  Key backup uses encrypted form of PKCS !#8.
+* Default build of client software now uses a multiplexer daemon `cryptech_muxd` which allows multiple clients to talk to the HSM at once (packages such as OpenDNSSEC which uses multiple daemons talking to the same HSM need this).  Software can still be built for direct connection to HSM but it is no longer the default.
+* New trivial script `cryptech_console` to talk to the HSM's management port via the multiplexer daemon; `cryptech_upload` now supports both direct connection and connection via the multiplexer daemon.
+* Python client implementations of libhal RPC mechanism and PKCS !#11 now installed as `cryptech.libhal` and `cryptech.py11`, respectively.
+* Python PKCS !#11 client hacked to play nicely with `pkcs11-spy` debugging tool.
+* RTOS replaced by simple non-preemptive (voluntary yield) tasking system, eliminating a huge morass of potential race conditions, debugging nightmares, priority inversions, and similar horrors.  Lack of preemption means that console acess may have to wait for something else to yield the ARM CPU, but it's more than worth it to get rid of all the stability problems the RTOS was causing.
+* [source:/user/sra/openssl-engine Sample code for using the HSM as an OpenSSL engine] is available.  This only works with RSA for the moment, due to apparent limitations of the engine implementation.
+
+
+Getting started with 3.0:
+
+
+* [wiki:BinaryPackages Install the software].
+* [wiki:Upgrading Upgrade the firmware].  **Please note the warnings about bricking your HSM**, how to avoid that, and what to do if you failed to avoid it.
+* Set the usual environment variables, perhaps using `cryptech_probe`.
+* Start the multiplexer daemon `cryptech_muxd`.
+
+
+At this point, you should be able to use the PKCS !#11 library, the `cryptech_backup` script, and so forth.
diff --git a/raw-wiki-dump/Requirements.md b/raw-wiki-dump/Requirements.md
new file mode 100644
index 0000000..434e4db
--- /dev/null
+++ b/raw-wiki-dump/Requirements.md
@@ -0,0 +1,172 @@
+# HSM Requirements
+
+Requirements for the Cryptech Alpha System. Derived from Use Cases (see below). There are also utility, internal requirements (again, see below).
+
+## Capacity
+### Per key storage requirements
+In addition to the actual key data, each key requires
+
+- Key type – 4 bytes
+- Key identifier – 4 bytes
+- Key flags, e.g. exportable – 8 bytes
+
+This results a total 16 bytes overhead for each key.
+
+### Examples per algorithm
+(For RSA, we  might also want to include the primes p and q might also be included which requires additional storage.)
+
+
+- RSA-8192 requires 1024 bytes secret key, 1024 bytes public key + 4 bytes exponent + 16 bytes overhead = 2068 bytes
+- RSA-4096 requires 512 bytes secret key,   512 bytes public key + 4 bytes exponent + 16 bytes overhead = 1044 bytes
+- RSA-2048 requires 256 bytes secret key,   256 bytes public key + 4 bytes exponent + 16 bytes overhead = 532 bytes
+- EC P-256 requires 32 bytes secret key, 64 bytes public key + 16 bytes overhead = 112 bytes
+- EC P-384 requires 48 bytes secret key, 96 bytes public key + 16 bytes overhead = 160 bytes
+- Curve 25519 requires 32 bytes secret key, 32 bytes public key + 16 bytes overhead = 80 bytes
+
+
+
+## Use Cases
+### DNSSEC
+#### Number of keys
+
+- TLD (or provider using key sharing) requires ~ 100 key pairs
+- 3 KSK per zone (previous, current, new)
+- 3 ZSK per zone (previous, current, new)
+
+#### Possibly dual algorithms
+
+- A typical TLD operator usually has less than 10 TLDs
+- Other DNS providers may use key sharing to limit number of keys required
+
+#### Algorithms
+
+- RSA-1024/SHA-256
+- RSA-2048/SHA-256
+- EC-P256/SHA-256
+
+#### Performance
+Each update to a zone requires 3-4 signatures (per algorithm)
+
+- Resign SOA (signed by ZSK)
+- Resign updated RR (signed by ZSK)
+- Resign NSEC/NSEC3 (signed by ZSK), may require multiple signatures
+
+Non-interactive latency (batch), dynamic updates may require faster signing
+
+### SAML
+#### Number of keys
+SAML federation operator requires max 10 key pairs (including space for roll)
+#### Algorithms
+
+- RSA-2048/SHA-256
+
+#### Performance
+
+- Non-interactive latency (batch)
+    - non-MDX: …
+- Interactive latency
+    - MDX: …
+
+
+### PKIX (including RPKI)
+#### Number of keys
+
+- Typical Certification Authority ~ 10 key pairs
+    - CA key, OCSP, CRL per level in the CA
+    - Root CA is one level
+    - For subordinate CAs, perhaps 2-5 CAs in a HSM is reasonable?
+
+#### Algorithms
+
+- RSA-2048/SHA-256
+- RSA-4096/SHA-256
+- RSA-4096/SHA-512 ?
+- EC-P256/SHA-256
+
+#### Performance
+
+- Non-interactive latency
+    - Root CA: Less than 1 signature per day
+    - Issuing CA: One signature per issued certificate
+    - CRL: Less than 1 signature per hour
+- Interactive latency
+    - OCSP: Multiple signatures per second
+
+
+### Tor
+Requirements according to (section 1): https://gitweb.torproject.org/torspec.git/plain/dir-spec.txt
+#### Number of keys
+
+- 1 private key
+- 10 public keys
+
+#### Algorithms
+
+- RSA-2048/SHA-1 ?
+- RSA-2048/SHA-256
+- RSA-4096/SHA-256 ?
+- RSA-4096/SHA-512 ?
+
+#### Performance
+
+- 2 signatures per hour
+- 20 verification operations per hour
+- 1 second max latency for RSA-2048 based verification
+
+
+### Certificate Transparency (CT)
+#### Number of keys
+CT requires 1 key (ECDSA or RSA) per log
+#### Algorithms
+
+- RSA-2048/SHA-256
+- RSA-4096/SHA-256 ?
+- RSA-4096/SHA-512 ?
+- EC-P256/SHA-256
+
+#### Performance
+
+- A Certificate Transparency log uses one ECDSA or one RSA key to sign two separate documents:
+- STH's might need to be signed once per hour
+- SCT's might need to be signed once per second (*)
+
+
+See RFC 6962, section 2.1.4 – https://tools.ietf.org/html/rfc6962
+
+
+## Internal Functional Requirements
+
+### Algorithms and functions
+
+- Key wrapping using AES-256 with SIV, http://tools.ietf.org/html/rfc5297
+- Internal Storage Master Key (ISMK) in battery backed RAM connected to FPGA
+    - Battery connection controlled by tamper mechanism
+    - Active erasure controlled by tamper mechanism
+- 32-bit high quality random number generation
+
+
+### PKCS11
+
+The following PKCS11 mechanisms are required to fulfill the aforementioned use cases:
+
+
+- RSA
+    - CKM_RSA_PKCS_KEY_PAIR_GEN
+    - CKM_RSA_PKCS
+    - CKM_RSA_X_509 ?
+    - CKM_SHA256_RSA_PKCS
+    - CKM_SHA512_RSA_PKCS ?
+- ECDSA
+    - CKM_EC_KEY_PAIR_GEN
+    - CKM_ECDSA
+- AES
+    - … TBD …
+- Random
+    - … TBD …
+- Key Wrapping
+    - … TBD …
+- Hash
+    - CKM_SHA256
+    - CKM_SHA512 (?)
+
+
diff --git a/raw-wiki-dump/RoughV1.md b/raw-wiki-dump/RoughV1.md
new file mode 100644
index 0000000..1891975
--- /dev/null
+++ b/raw-wiki-dump/RoughV1.md
@@ -0,0 +1,125 @@
+# Rough Cut at v0.01 Proof of Concept Feature Set
+
+[[PageOutline]]
+
+This is a proposed version 0.01 product as a proof of concept.  The
+intent is not to have a very useful product, but rather to gain
+confidence in our architecture, tools, and team.  The result is intended
+to be the basis for further development into a more useful second stage,
+in the sense of
+[agile development](https://en.wikipedia.org/wiki/Agile_software_development).
+It very intentionally is not a
+[waterfall design](https://en.wikipedia.org/wiki/Waterfall_model),
+
+The interface between the Green and Yellow layers is seen as an important design
+inflection.
+
+Some code will be in C in the Green (auxiliary core) because we can get it open
+source out of the can.  for v.2 (or whatever) we would move it down to the FPGA in
+Verilog.
+
+## FPGA Overview
+[[Image(HW_sketch_v0001.png)]]
+\\
+\\
+## Sketch of TRNG Chain
+[[Image(HW_RNG.png​)]]
+\\
+\\
+
+## Off-FPGA
+
+* Persistent Storage
+    * For Keys and Time
+    * Or the battery for tamper wipe is big enough to hold the FPGA up
+    * Or the Green processor has enough non-volatile store
+* Entropy Source
+* Realtime Clock
+* Tamper Mechanism
+
+
+## Layers
+
+```
+#!html
+<h1 style="text-align: left; color: blue">
+  Blue / FPGA
+</h1>
+```
+
+
+* TRNG
+* BigNumber, Modular, & Exponentiation (expose to green for RSA)
+* SHA-256
+* AES-128
+* EC for ECDH. Curve3617 would be nice, but whatever we can get open source to start
+* OpenRISC Core or ARM to support Green (maybe FreeScale from Bunnie)
+
+
+```
+#!html
+<h1 style="text-align: left; color: green">
+  Green / On-Chip Core
+</h1>
+```
+
+
+* RSA 2048 & 4096 (move to blue later) [ 1024 for Tor? ]
+* MACs: HMAC, 1305, uMAC
+* DH (move to blue later)
+* Device Activation, Move Authorization, Wiping
+
+
+```
+#!html
+<h1 style="text-align: left; color: yellow">
+  Yellow / Off-Chip Support
+</h1>
+```
+
+
+* Interface to Red
+    * PKCS!#8
+    * PKCS!#11
+    * PGP Support
+* X.509 and PGP
+* PKCS!#11 for POLA resistance
+* No PKCS!#10 because it will take a year
+* Backup may be just dump/restore of the whole FPGA/CoreState
+
+
+```
+#!html
+<h1 style="text-align: left; color: red">
+  Red / Applications
+</h1>
+```
+
+
+* X.509 CA
+* DNSSEC
+* PGP (asymmetric key sign/verify + symmetric message encryption/decryption)
+* Tor consensus(?)
+
+
+## Issues in v0.01
+
+
+* License of tool chain to build
+* License for borrowed components (open cores, open fpga)
+* License for result
+    * What we build ourselves - BSD
+    * What components we ship - life is compromise
+* Toolchains, Verilog, C, ...
+* FPGAs and ASICs use a Verilog-based toolchain.  There are no mature open
+
+  Verilog compilers so the [DDC approach](http://www.dwheeler.com/trusting-trust/)
+  will not work.  Net-list optimization is also an issue.  We're looking into this,
+  but it's going to be really hard.  Research for v2.
+
+* Protoyping platform
+    * [Bunnie's Novena laptop](http://www.bunniestudios.com/blog/?p=3265)
+    * Altera Evaluation Board
+* RTC, external connectivity to et some sort of assured time
+* Repository - too many git junkies.  Keep main repo on our server for the security boundary.  Can mirror on GitHub to be socially cool.
+* Emacs or vi (no Rob, not TECO) :)
diff --git a/raw-wiki-dump/SandBox.md b/raw-wiki-dump/SandBox.md
new file mode 100644
index 0000000..226b3e3
--- /dev/null
+++ b/raw-wiki-dump/SandBox.md
@@ -0,0 +1,5 @@
+# The Sandbox
+
+This is just a page to practice and learn WikiFormatting.
+
+Go ahead, edit it freely.
diff --git a/raw-wiki-dump/ScratchPage.md b/raw-wiki-dump/ScratchPage.md
new file mode 100644
index 0000000..0cba8a7
--- /dev/null
+++ b/raw-wiki-dump/ScratchPage.md
@@ -0,0 +1,3 @@
+# Scratch Page
+
+OK, so here's this perfectly good scratch page.  Can I edit it with Emacs today?
diff --git a/raw-wiki-dump/SecureChannel.md b/raw-wiki-dump/SecureChannel.md
new file mode 100644
index 0000000..1d943d5
--- /dev/null
+++ b/raw-wiki-dump/SecureChannel.md
@@ -0,0 +1,179 @@
+# Secure Channel
+
+This is a sketch of a design for the secure channel that we want to
+have between the Cryptech HSM and the client libraries which talk to
+it.  Work in progress, and not implemented yet because a few of the
+pieces are still missing.
+
+## Design goals and constraints
+
+Basic design goals:
+
+
+* End-to-end between client library and HSM.
+
+
+
+* Not require yet another presentation layer if we can avoid it (so,
+
+  reuse XDR if possible, unless we have some strong desire to switch
+  to something else).
+
+
+* Provide end-to-end message integrity between client library and HSM.
+
+
+
+* Provide end-to-end message confidentiality between client library
+
+  and HSM.  We only need this for a few operations, but between PINs
+  and private keys it would be simpler just to provide it all the time
+  than to be selective.
+
+
+* Provide some form of mutual authentication between client library
+
+  and HSM.  This is tricky, since it requires either configuration (of
+  the other party's authenticator) or leap-of-faith.  Leap-of-faith is
+  probably good enough for most of what we really care about (insuring
+  that we're talking to the same dog now as we were earlier).
+
+  Not 100% certain we need this at all, but if we're going to leave
+  ourselves wide open to monkey-in-the-middle attacks, there's not
+  much point in having a secure channel at all.
+
+
+* Use boring simple crypto that we already have (or almost have) and
+
+  which runs fast.
+
+
+* Continue to support multiplexer.  Taken together with end-to-end
+
+  message confidentiality, this may mean two layers of headers: an
+  outer set which the multiplexer is allowed to mutate, then an inner
+  set which is protected.  Better, though, would be if the multiplexer
+  can work just by reading the outer headers without modifying
+  anything.
+
+
+* Simple enough that we can implement it easily in HSM, PKCS #11
+
+  library, and Python library.
+
+## Why not TLS?
+
+We could, of course, Just Use TLS.  Might end up doing that, if it
+turns out to be easier, but TLS is a complicated beast, with far more
+options than we need, and doesn't provide all of what we want, so a
+fair amount of the effort would be, not wasted exactly, but a giant
+step sideways.  Absent sane alternatives, I'd just suck it up and do
+this, with a greatly restricted ciphersuite, but I think we have a
+better option.
+
+## Design
+
+Basic design lifted from "Cryptography Engineering: Design Principles
+and Practical Applications" (ISBN 978-0-470-47424-2,
+http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470474246.html),
+tweaked in places to fit tools we have readily available.
+
+Toolkit:
+
+
+* AES
+* SHA-2
+* ECDH
+* ECDSA
+* XDR
+
+
+As in the book, there are two layers here: the basic secure channel,
+moving encrypted-and-authenticated frames back and forth, and a higher
+level which handles setup, key agreement, and endpoint authentication.
+
+Chapter 7 outlines a simple lower layer using AES-CTR and
+HMAC-SHA-256.  I don't see any particular reason to change any of
+this, AES-CTR is easy enough.  I suppose it might be worth looking
+into AES-CCM and AES-GCM, but they're somewhat more complicated;
+section 7.5 ("Alternatives") discusses these briefly, we also know
+some of the authors.
+
+For key agreement we probably want to use ECDH.  We don't quite have
+that yet, but in theory it's relatively minor work to generalize our
+existing ECDSA code to cover that too, and, again in theory, it should
+be possible to generalize our existing ECDSA fast base point multiplier
+Verilog cores into fast point multiplier cores (sic: limitation of the
+current cores is that they only compute scalar times the base point,
+not scalar times an arbitrary point, which is fine for ECDSA but
+doesn't work for ECDH).
+
+For signature (mutual authentication) we probably want to use ECDSA,
+again because we have it and it's fast.  The more interesting question
+is the configuration vs leap-of-faith discussion, figuring out under
+which circumstances we really care about the peer's identity, and
+figuring out how to store state.
+
+Chapter 14 (key negotiation) of the same book covers the rest of the
+protocol, substituting ECDH and ECDSA for DH and RSA, respectively.
+As noted in the text, we could use a shared secret key and a MAC
+function instead of public key based authentication.
+
+Alternatively, the Station-to-Station protocol described in 4.6.1 of
+"Guide to Elliptic Curve Cryptography" (ISBN 978-0-387-95273-4,
+https://link.springer.com/book/10.1007/b97644) appears to do what
+we want, straight out of the box.
+
+Interaction with multiplexer is slightly interesting.  The multiplexer
+really only cares about one thing: being able to match responses from
+the HSM to queries sent into the HSM, so that the multiplexer can send
+the responses back to the right client.  At the moment, it does this
+by seizing control of the client_handle field in the RPC frame, which
+it can get away with doing because there's no end-to-end integrity
+check at all (yuck).  We could add an outer layer of headers for the
+multiplexer, but would rather not.
+
+The obvious "real" identity for clients to use would be the public
+keys (ECDSA in the above discussion) they use to authenticate to the
+HSM, or a hash (perhaps truncated) thereof.  That's good as far as it
+goes, and may suffice if we can assume that clients always have unique
+keys, but if client keys are something over which the client has any
+control (which includes selecting where they're stored, which we may
+not be able to avoid), we have to consider the possibility of multiple
+clients using the same key (yuck).  So a candidate replacement for the
+client_handle for multiplexer purposes would be some combination of a
+public key hash and a process ID, both things the client could provide
+without the multiplexer needing to do anything.
+
+The one argument in favor of leaving control of this to the
+multiplexer (rather than the endpoints) is that it would (sort of)
+protect against one client trying to masquerade as another -- but
+that's really just another reason why clients should have their own
+keys to the extent possible.
+
+As a precaution, perhaps the multiplexer should check for duplicate
+identifiers, then do, um, something? if it finds duplicates.  This
+kind of violates Steinbach's Guideline for Systems Programming ("Never
+test for an error condition you don't know how to handle").  Obvious
+answer is to break all connections old and new using the duplicate
+identity, minor questions about how to reset from that, whether worth
+doing at all, etc.  Maybe clients just shouldn't do that.
+
+## Open issues
+
+
+* Does the resulting design pass examination by clueful people?
+
+
+
+* Does this end up still being significantly simpler than TLS?
+
+
+
+* The Cryptography Engineering protocols include a hack to work around
+
+  a length extension weakness in SHA-2 (see section 5.4.2).  Do we
+  need this?  Would we be better off using SHA-3 instead?  The book
+  claims that SHA-3 was expected to fix this, but that was before NIST
+  pissed away their reputation by getting too cosy with the NSA again.
+  Over my head, ask somebody with more clue.
diff --git a/raw-wiki-dump/SideChannel.md b/raw-wiki-dump/SideChannel.md
new file mode 100644
index 0000000..83d031a
--- /dev/null
+++ b/raw-wiki-dump/SideChannel.md
@@ -0,0 +1,8 @@
+
+# Side Channel Attacks
+
+Side Channel attacks on hardware are hard to avoid, detect and mitigate. But this should not stop us from trying. The CrypTech platform should be developed with side channel issues in mind. This page tries to collect information about relevant side channel attacks, mitigation strategies, side channel resistant design methods (blinding for example) and detection.
+
+
+* http://eprint.iacr.org/2013/579 "On Measurable Side-Channel Leaks inside ASIC Design Primitives"
+* http://people.umass.edu/gbecker/BeckerChes13.pdf "Stealthy Dopant-Level Hardware Trojans"
diff --git a/raw-wiki-dump/StateOfPlay.md b/raw-wiki-dump/StateOfPlay.md
new file mode 100644
index 0000000..b9b448b
--- /dev/null
+++ b/raw-wiki-dump/StateOfPlay.md
@@ -0,0 +1,160 @@
+[[PageOutline]]
+
+# A Completely Informal Snapshot Of The Current State Of The Cryptech Project As Of 2014-11-06
+
+This page contains a snapshot of the status in the project and will almost certainly be obsolete by the time you read it.  If you find something that's wrong, please fix it!
+
+
+## Cores
+We have a bunch of cores, primarily for FPGA implementation.  Some of them implement cryptographic
+algorithms or critical functionality like the TRNG. Other cores are support cores for implementation of the Cryptech HSM. Other cores are for developing the cores and the HW. Finally some are just test
+code.
+
+Cores that have been promoted to official cryptech HW cores:
+
+
+* `core/chacha` - The ChaCha stream cipher
+* `core/sha1` - FIPS 180-2 SHA-1 hash
+* `core/sha256` - FIPS 180-4 SHA-256 hash
+* `core/sha512` - FIPS 180-4 SHA-512/x hash
+* `core/trng` - The Cryptech TRNG sub system. Uses ChaCha, SHA-512 and entropy cores.
+* `core/avalanche_entropy` - Avalanche entropy provider core. Requires external avalanche noise source.
+* `core/rosc_entropy` - Digital ring oscillator based entropy provider core.
+
+
+Utility, test, board support:
+
+
+* `core/coretest` - Core for performing command/response operations to drive testing of a core.
+* `core/coretest_hashes` - Subsysem with coretest and the hash function cores as test objects.
+* `core/coretest_test_core` - Coretest with a simple test core
+* `core/i2c` - I2C interface core.
+* `core/novena`
+* `core/novena_eim`
+* `core/novena_i2c_simple`
+* `core/test_core`
+* `core/uart`- UART interface core to allow serial communication with FPGA functionality.
+* `core/vndecorrelator` - von Neumann decorrelation core.
+
+
+Documentation is very haphazard: some of the repositories have
+detailed README.md files, but in many cases the documentation, what
+there is of it, is probably meaningful only to the person who wrote
+it, not because of any lack of good intent, just because what's
+written assumes that the reader knows everything that the author does
+about the other cores, the rest of the environment, and how everything
+fits together.
+
+## Builds
+
+At this point I have figured out how to build two different FPGA
+images for the Novena PVT1.  In both cases, I'm using the Makefile
+rather than attempting to use the XiLinx GUI environment.
+
+
+* `core/novena` builds the current set of digest cores into a
+
+  framework that uses the "coretest" byte stream protocol over an I2C
+  bus.
+
+
+* `core/novena_i2c_simple` builds the current set of digest cores into
+
+  a framework that uses a simplfied write()/read() API over an I2C bus.
+
+There's a third build, `core/novena_eim`, which was only just updated
+today, and which is reported as not quite stable yet.  Will try
+building it soon and report here.
+
+Both working builds (and, almost certainly, any useful build) involve
+more than just the named repository.  `verilator`, when asked nicely,
+will draw a graph of Verilog module relationships.  Take this with
+salt, as I am a long way from getting `verilator` to run cleanly on
+any of this, but the current graphs may still be useful in visualizing
+what's happening here.
+
+At least some of the modules that `verilator` complains about not
+being able to find appear to come from XiLinx libraries that
+`verilator` doesn't know about.
+See [Libraries Guide for HDL Designs]]([http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_1/spartan6_hdl.pdf|Spartan-6) for details.
+
+### Module relationships in core/novena build
+
+[[Image(novena__linkcells.svg)]]
+
+### Module relationships in core/novena_i2c_simple build
+
+[[Image(novena_i2c_simple__linkcells.svg)]]
+
+### Module relationships in core/novena_eim build
+
+[[Image(novena_eim__linkcells.svg)]]
+
+### Module relationships in cores/trng build
+
+By special request, here's a graph for the TRNG too, even though we
+don't yet have a way to speak to it from the Novena:
+
+[[Image(trng__linkcells.svg)]]
+
+## C Code
+
+Most of the cores have at least minimal test frameworks, written in a
+combination of Verilog, C, and Python, but there's also a preliminary
+port of Cryptlib to the Cryptech environment, in `sw/cryptlib`.  As of
+this writing, the only Cryptech-specific features of this port, other
+than a few makefile tricks, are:
+
+
+* A set of HALs that make use of the `core/novena` and
+
+  `core/novena_i2c_simple` FPGA builds, using the Linux /dev/i2c
+  device interface; and
+
+
+* Another Python script to test the resulting Cryptlib build, using
+
+  the stock Cryptlib Python bindings.
+
+No HAL for `core/novena_eim` yet.
+
+The Cryptlib Python bindings build kind of slowly on the Novena, sorry
+about that.
+
+## Hardware
+
+The hardware guys have done cool stuff with hardware entropy sources.
+I even have one of the noise boards, but until I have some way to
+connect C code to the TRNG, I don't have much use for it other than to
+admire the craftsmanship.  Soon, I hope.
+
+## Tools
+
+Already mentioned `verilator`.  In addition to generating GraphViz
+input, `verilator` has a `--lint` mode which looks interesting.
+
+(JS) Verilator is fairly usable, at least as a linter. Adding `-Wall` provides more warnings.
+Since we at least uses Icarus Verilog (iverilog), Altera Quartus and Xilinx ISE one would assume that they would provide all possible warnings. That is not the case. They all seem to fins different things to warn about. And Verilator provides even more. The more parsers and checkers the better. But we will not be able to, or want to fix all warnings. Some things are by design. We should probably document what we ignore.
+
+I haven't yet figured out whether we have any real use for
+`verilator`'s core function of synthesizing Verilog into C++.  I've
+been toying with the idea of a software-only development environment,
+where one simulates an embedded machine using two Unix processes: one
+would be a virtual FPGA generated by `verilator`, the other would be a
+classical deeply embedded system running as a single process.  The two
+processes would communicate via a `PF_UNIX` socket or something on
+that order.  It might be possible to jam everything into a single
+process, but I suspect it wouldn't be worth the trouble.
+
+Joachim has Makefiles which use `iverilog` to generate simulation
+images.  Installing `iverilog` is easy enough (`apt-get install`, etc)
+but I haven't yet figured out how to do anything interesting with the
+simulation images.  Joachim replies:
+
+    There is help in the Makefile.  You run the targets, either as
+    make sim-foo or just ./foo.sim.  Most if not all tests are self
+    testing with test cases and should report number of test cases and
+    how many passed.  Which should be all.
+
+As far as I know we've done nothing yet to deal with threats to the
+tool chain (Thompson attack, etc).
diff --git a/raw-wiki-dump/SunetInitialDevelopment.md b/raw-wiki-dump/SunetInitialDevelopment.md
new file mode 100644
index 0000000..974bd5e
--- /dev/null
+++ b/raw-wiki-dump/SunetInitialDevelopment.md
@@ -0,0 +1,137 @@
+# Planning for SUNET funded Cryptech Work
+The following documents the first two development steps in Cryptech
+funded by SUNET. The development is being done by Joachim Strömbergson
+from Secworks AB.
+
+## Step one (Deadline 2014-02-28)
+
+    - Acquire a FPGA development platform.
+
+DONE. We have a Terasic DE0 board and a Terasic Cyclone V GX starter kit board.
+
+
+
+    - Create a working development and verification flow from RTL design
+
+   downto FPGA.
+
+
+    - Verify the functionality of the SHA-256 core in a physical FPGA.
+
+
+
+### Actions for step one
+
+    - Select FPGA development board to acquire
+        - Large enough to test sub systems and possibly a complete HSM.
+        - Good external interfaces for communication with host systems.
+        - Good external interfaces to entropy sources, memories,
+
+     GPIO. Arduino Shields would be good.
+
+
+    - Create a survey on interconnect standards usable for Cryptech
+        - Availability and market share/usage in third party cores.
+        - License
+        - Technical details - Bus, fabric, performance etc.
+
+
+
+
+    - Create base coretest functionality to allow testing of cores in the
+
+     FPGA on the development board. Read and write access to registers
+     over a known communication channel.
+
+
+    - Verify the development flow from Verilog RTL downto FPGA.
+
+
+
+    - Verifiera SHA-256 core using coretest.
+
+
+
+    - Start FPGA tool survey
+        - What is available as open tools and what is the status.
+        - What is available as open tools from the vendors.
+        - Talk to people in the industry to get their views on an open toolchain.
+
+
+
+## Step two (Deadline 2014-03-31)
+
+    - Produce first draft of design proposal to the Cryptech True Random Number Generator (TRNG)
+        - Security target, security model and assumptions
+        - Structure, architecture
+        - API
+        - Functionality
+        - Online test system
+        - Verification model
+        - First two entropy sources
+
+
+
+    - Complete SHA-1 core. Including functional verification in FPGA.
+
+
+
+    - First draft of SHA-256 and SHA-1 core documentation.
+
+
+
+### Actions for step two
+
+    - Create template for documentation
+
+
+
+    - Collect info on known TRNGs and TRNG strategies
+
+
+
+    - Collect info on online tests being used.
+
+
+
+    - Create proposal for architecture.
+
+
+
+    - Write implementation proposal.
+
+
+
+    - Specify API.
+
+
+
+    - Write security target and security model.
+
+
+
+    - Write assumptions and limitations.
+
+
+
+    - Write verification model.
+
+
+
+    - Finalize SHA-1 core RTl.
+
+
+
+    - Build SHA-1 core in FPGA.
+
+
+
+    - Verify SHA-1 functionality in FPGA using coretest.
+
+
+
+    - Write documentation for SHA-256 core.
+
+
+
+    - Write documentation for SHA-1 core.
diff --git a/raw-wiki-dump/TRNGDevelopment.md b/raw-wiki-dump/TRNGDevelopment.md
new file mode 100644
index 0000000..9204952
--- /dev/null
+++ b/raw-wiki-dump/TRNGDevelopment.md
@@ -0,0 +1,9 @@
+# TRNG Development
+One, if not THE key functionality in the Cryptech system is the True Random Number Generator (TRNG). We therefore need to discuss, investigate and test to find a TRNG that we and the users of Cryptech can trust and can verify to be trusted.
+
+
+## Information collected
+
+* [http://digirep.rhul.ac.uk/file/315c7a7e-4963-4a62-189f-4ad198a79f30/5/Paper.pdf](http://digirep.rhul.ac.uk/file/315c7a7e-4963-4a62-189f-4ad198a79f30/5/Paper.pdf) (pdf) Pseudorandom Number Generation in Smart Cards:
+
+An Implementation, Performance and Randomness Analysis. A paper that uses Javacard to implement different TRNGs and evluates them.
diff --git a/raw-wiki-dump/TicketQuery.md b/raw-wiki-dump/TicketQuery.md
new file mode 100644
index 0000000..15bd507
--- /dev/null
+++ b/raw-wiki-dump/TicketQuery.md
@@ -0,0 +1,153 @@
+# TicketQuery Wiki Macro
+
+The TicketQuery macro lets you display information on tickets within wiki pages.
+The query language used by the `[[TicketQuery]]` macro is described in [TracQuery#UsingtheTicketQueryMacro TracQuery] page.
+
+## Usage
+
+[[MacroList(TicketQuery)]]
+
+## Example
+
+| **Example** | **Result** | **Macro** |
+|---|---|---|
+
+|-----------------------------------------------------------
+|Number of [query:status=new&milestone= Triage tickets]: |\
+|---|
+| **[[TicketQuery(status=new&milestone=,count)]]**|\
+| `[[TicketQuery(status=new&milestone=,count)]]` |
+
+|-----------------------------------------------------------
+|Number of new tickets: |\
+|---|
+| **[[TicketQuery(status=new,count)]]**|\
+| `[[TicketQuery(status=new,count)]]` |
+
+|-----------------------------------------------------------
+|Number of reopened tickets: |\
+|---|
+| **[[TicketQuery(status=reopened,count)]]**|\
+| `[[TicketQuery(status=reopened,count)]]` |
+
+|-----------------------------------------------------------
+|Number of assigned tickets: |\
+|---|
+| **[[TicketQuery(status=assigned,count)]]**|\
+| `[[TicketQuery(status=assigned,count)]]` |
+
+|-----------------------------------------------------------
+|Number of invalid tickets: |\
+|---|
+| **[[TicketQuery(status=closed,resolution=invalid,count)]]**|\
+| `[[TicketQuery(status=closed,resolution=invalid,count)]]` |
+
+|-----------------------------------------------------------
+|Number of worksforme tickets: |\
+|---|
+| **[[TicketQuery(status=closed,resolution=worksforme,count)]]**|\
+| `[[TicketQuery(status=closed,resolution=worksforme,count)]]` |
+
+|-----------------------------------------------------------
+|Number of duplicate tickets: |\
+|---|
+| **[[TicketQuery(status=closed,resolution=duplicate,count)]]**|\
+| `[[TicketQuery(status=closed,resolution=duplicate,count)]]` |
+
+|-----------------------------------------------------------
+|Number of wontfix tickets: |\
+|---|
+| **[[TicketQuery(status=closed,resolution=wontfix,count)]]**|\
+| `[[TicketQuery(status=closed,resolution=wontfix,count)]]` |
+
+|-----------------------------------------------------------
+|Number of fixed tickets: |\
+|---|
+| **[[TicketQuery(status=closed,resolution=fixed,count)]]**|\
+| `[[TicketQuery(status=closed,resolution=fixed,count)]]` |
+
+|-----------------------------------------------------------
+|Total number of tickets: |\
+|---|
+| **[[TicketQuery(count)]]**|\
+| `[[TicketQuery(count)]]` |
+
+|-----------------------------------------------------------
+|Number of tickets reported **or** owned by current user: |\
+|---|
+| **[[TicketQuery(reporter=$USER,or,owner=$USER,count)]]**|\
+| `[[TicketQuery(reporter=$USER,or,owner=$USER,count)]]` |
+
+|-----------------------------------------------------------
+|Number of tickets created this month: |\
+|---|
+| **[[TicketQuery(created=thismonth..,count)]]**|\
+| `[[TicketQuery(created=thismonth..,count)]]` |
+
+|-----------------------------------------------------------
+|Last 3 modified tickets: |\
+|---|
+|**[[TicketQuery(max=3,order=modified,desc=1,compact)]]**|\
+| `[[TicketQuery(max=3,order=modified,desc=1,compact)]]` |
+
+|-----------------------------------------------------------
+```#!th rowspan=2, style="text-align: left;"
+Details of ticket #1:
+```
+```#!td style="border-bottom: 0;"
+```
+```#!td
+`[[TicketQuery(id=1,col=id|owner|reporter,rows=summary,table)]]`
+```
+|-
+```#!td colspan=2, style="border-top: 0;"
+[[TicketQuery(id=1,col=id|owner|reporter,rows=summary,table)]]
+```
+|-----------------------------------------------------------
+
+## Using the `[[TicketQuery]]` Macro
+
+The [trac:TicketQuery TicketQuery] macro lets you display lists of tickets matching certain criteria anywhere you can use WikiFormatting.
+
+Example:
+```
+[[TicketQuery(version=0.6|0.7&resolution=duplicate)]]
+```
+
+This is displayed as:
+  [[TicketQuery(version=0.6|0.7&resolution=duplicate)]]
+
+Just like the [wiki:TracQuery#UsingTracLinks query: wiki links], the parameter of this macro expects a query string formatted according to the rules of the simple [wiki:TracQuery#QueryLanguage ticket query language]. This also displays the link and description of a single ticket:
+```
+[[TicketQuery(id=123)]]
+```
+
+This is displayed as:
+  [[TicketQuery(id=123)]]
+
+A more compact representation without the ticket summaries is:
+```
+[[TicketQuery(version=0.6|0.7&resolution=duplicate, compact)]]
+```
+
+This is displayed as:
+  [[TicketQuery(version=0.6|0.7&resolution=duplicate, compact)]]
+
+If you wish to receive only the number of defects that match the query, use the `count` parameter:
+```
+[[TicketQuery(version=0.6|0.7&resolution=duplicate, count)]]
+```
+
+This is displayed as:
+  [[TicketQuery(version=0.6|0.7&resolution=duplicate, count)]]
+
+A graphical use of the macro is with the `format=progress` attribute:
+```
+[[TicketQuery(milestone=0.12.8&group=type,format=progress)]]
+```
+
+For example for one of the upcoming milestones, bars are shown by ticket type:
+[[TicketQuery(milestone=0.12.8&group=type,format=progress)]]
+
+----
+See also: TracQuery, TracTickets, TracReports, TracGuide
diff --git a/raw-wiki-dump/TitleIndex.md b/raw-wiki-dump/TitleIndex.md
new file mode 100644
index 0000000..2a98938
--- /dev/null
+++ b/raw-wiki-dump/TitleIndex.md
@@ -0,0 +1,3 @@
+** Index by Title ** | ** [RecentChanges Index by Date] **
+
+[[TitleIndex(format=group,min=4)]]
diff --git a/raw-wiki-dump/TracAccessibility.md b/raw-wiki-dump/TracAccessibility.md
new file mode 100644
index 0000000..cb45caf
--- /dev/null
+++ b/raw-wiki-dump/TracAccessibility.md
@@ -0,0 +1,39 @@
+# Accessibility Support in Trac
+
+Not every user has a graphic environment with a mouse or other pointing device. Some users rely on keyboard, alternative keyboard or voice input to navigate links and activate form controls. In a Trac session, users can use devices other than a pointing device by enabling keyboard shortcuts through the [/prefs/keybindings Keyboard Shortcuts] preferences panel.
+
+Trac supports accessibility keys for the most common operations. The access keys differ by browser and the following work for several browsers:
+
+    - on Linux platforms, press any of the keys listed below in combination with the `<Alt>` key
+    - on a Mac, use the `<Ctrl>` + `<Opt>` key instead
+    - on Windows, you need to hit `<Shift> + <Alt> + <Key>`. This works for the most common browsers, such as Firefox, Chrome, Safari and Internet Explorer
+
+
+Also see [wikipedia:Access_key#Access_in_different_browsers access in different browsers] for more details.
+
+## Global Access Keys
+
+
+    * `1` - WikiStart
+    * `2` - [TracTimeline Timeline]
+    * `3` - [TracRoadmap Roadmap]
+    * `4` - [TracSearch Search]
+    * `6` - [TracGuide Trac Guide / Documentation]
+    * `7` - [TracTickets New Ticket]
+    * `9` - [/about About Trac]
+    * `e` - Edit (wiki or report)
+    * `r` - Preview (wiki or ticket)
+    * `f` - Search
+
+
+## TracBrowser Access Keys
+
+
+* `j` - Select next entry
+* `k` - Select previous entry
+* `o` - Expand folder/view file
+* `<Enter>` - Expand folder/view file
+
+
+----
+See also: TracGuide
diff --git a/raw-wiki-dump/TracAdmin.md b/raw-wiki-dump/TracAdmin.md
new file mode 100644
index 0000000..8274773
--- /dev/null
+++ b/raw-wiki-dump/TracAdmin.md
@@ -0,0 +1,66 @@
+# TracAdmin
+
+[[PageOutline(2-5, Contents, floated)]]
+[[TracGuideToc]]
+
+Trac is distributed with a powerful command-line configuration tool. This tool can be used to configure and customize your Trac-installation to better fit your needs.
+
+Some of those configurations can also be performed via the web administration module.
+
+## Usage
+
+For nearly every `trac-admin` command, you will need to specify the path to the TracEnvironment that you want to administer as the first argument:
+```
+trac-admin /path/to/projenv wiki list
+```
+
+The only exception is for the `help` command, but even in this case if you omit the environment, you will only get a very succinct list of commands (`help` and `initenv`), the same list you would get when invoking `trac-admin` alone.
+Also, `trac-admin --version` will tell you about the Trac version (e.g. 0.12) corresponding to the program.
+
+To get a comprehensive list of the available commands and sub-commands, specify an existing environment:
+```
+trac-admin /path/to/projenv help
+```
+
+Some commands have a more detailed help, which you can access by specifying the command's name as a subcommand for `help`:
+```
+trac-admin /path/to/projenv help <command>
+```
+
+### `trac-admin <targetdir> initenv` === #initenv
+
+This subcommand is very important as is the one used to create a TracEnvironment in the specified `<targetdir>`. That directory must not exist prior to the call.
+
+[[TracAdminHelp(initenv)]]
+
+It supports an extra `--inherit` option, which can be used to specify a global configuration file which can be used to share settings between several environments. You can also inherit from a shared configuration afterwards, by setting the `[inherit] file` option in the `conf/trac.ini` file in your newly created environment, but the advantage of specifying the inherited configuration file at environment creation time is that only the options *not* already specified in the global configuration file will be written in the created environment's `conf/trac.ini` file.
+See TracIni#GlobalConfiguration.
+
+Note that in version 0.11 of Trac, `initenv` lost an extra last argument `<templatepath>`, which was used in previous versions to point to the `templates` folder. If you are using the one-liner `trac-admin /path/to/trac/ initenv <projectname> <db> <repostype> <repospath>` in the above and get an error that reads `Wrong number of arguments to initenv: 4`, then this is because you are using a `trac-admin` script from an **older** version of Trac.
+
+## Interactive Mode
+
+When passing the environment path as the only argument, `trac-admin` starts in interactive mode.
+Commands can then be executed on the selected environment using the prompt, which offers tab-completion
+(on non-Windows environments, and when the Python `readline` module is available) and automatic repetition of the last command issued.
+
+Once you are in interactive mode, you can also get help on specific commands or subsets of commands:
+
+For example, to get an explanation of the `resync` command, run:
+```
+$ help resync
+```
+
+To get help on all the Wiki-related commands, run:
+```
+$ help wiki
+```
+
+## Full Command Reference
+
+You will find below the detailed help for all the commands available by default in `trac-admin`. Note that this may not match the list given by `trac-admin <yourenv> help`, as the commands pertaining to components disabled in that environment won't be available and conversely some plugins activated in the environment can add their own commands.
+
+[[TracAdminHelp()]]
+
+----
+See also: TracGuide, TracBackup, TracPermissions, TracEnvironment, TracIni, [trac:TracMigrate TracMigrate]
diff --git a/raw-wiki-dump/TracBackup.md b/raw-wiki-dump/TracBackup.md
new file mode 100644
index 0000000..8759c67
--- /dev/null
+++ b/raw-wiki-dump/TracBackup.md
@@ -0,0 +1,34 @@
+# Trac Backup
+
+[[TracGuideToc]]
+
+Trac backups are simply a copied snapshot of the entire [wiki:TracEnvironment project environment] directory, including the database. Backups can be created using the `hotcopy` command in [wiki:TracAdmin trac-admin].
+
+**Note**: Trac uses the `hotcopy` nomenclature to match that of [Subversion](http://subversion.tigris.org/), to make it easier to remember when managing both Trac and Subversion servers.
+
+## Creating a Backup
+
+To create a backup of a live TracEnvironment simply run:
+```#!sh
+$ trac-admin /path/to/projenv hotcopy /path/to/backupdir
+```
+
+[wiki:TracAdmin trac-admin] will lock the database while copying.
+
+The resulting backup directory is safe to handle using standard file-based backup tools like `tar` or `dump`/`restore`.
+
+Please note, the `hotcopy` command will not overwrite a target directory and when such exists, the operation ends with an error: `Command failed: [Errno 17] File exists:` This is discussed in [trac:ticket:3198 #3198].
+
+## Restoring a Backup
+
+To restore an environment from a backup, stop the process running Trac, ie the Web server or [wiki:TracStandalone tracd], restore the contents of your backup (path/to/backupdir) to your [wiki:TracEnvironment project environment] directory and restart the service.
+
+To restore a PostgreSQL database backup, use the command:
+```#!sh
+psql -U <user> -d <database> -f postgresql.dump
+```
+
+The `<database>` option is the same as the [TracEnvironment#DatabaseConnectionStrings database connection string] in the `[trac]` `database` option of //trac.ini//.
+
+----
+See also: TracAdmin, TracEnvironment, TracGuide, [trac:TracMigrate TracMigrate]
diff --git a/raw-wiki-dump/TracBatchModify.md b/raw-wiki-dump/TracBatchModify.md
new file mode 100644
index 0000000..6c921e8
--- /dev/null
+++ b/raw-wiki-dump/TracBatchModify.md
@@ -0,0 +1,14 @@
+# Trac Ticket Batch Modification
+[[TracGuideToc]]
+
+Trac supports modifying a batch of tickets in one request from [TracQuery custom query] results.
+
+To perform a batch modification, select the tickets you wish to modify and set the new field values using the section underneath the query results.
+
+## List fields
+
+The `Keywords` and `Cc` fields are treated as lists, where list items can be added and/or removed in addition of replacing the entire list value. All list field controls accept multiple items, such as multiple keywords or cc addresses.
+
+## Excluded fields
+
+Multi-line text fields are not supported, because no valid use-case has been presented for syncing them across several tickets. That restriction applies to the `Description` field as well as to any [custom field] of type 'textarea'. However, future versions of Trac could support in conjunction with more suitable actions like 'prepend', 'append' or 'search & replace' ([http://trac-hacks.org/ticket/2415 th:#2415](TracTicketsCustomFields#AvailableFieldTypesandOptions)).
diff --git a/raw-wiki-dump/TracBrowser.md b/raw-wiki-dump/TracBrowser.md
new file mode 100644
index 0000000..627e071
--- /dev/null
+++ b/raw-wiki-dump/TracBrowser.md
@@ -0,0 +1,57 @@
+# The Trac Repository Browser
+
+[[TracGuideToc]]
+
+The Trac repository browser can be used to browse specific revisions of directories and files stored in the repositories associated with the Trac environment.
+
+At the top-level of the repository browser is the **Repository Index**, listing all the configured repositories.
+Each repository has a name which is used as a path prefix in a "virtual" file hierarchy encompassing all the available repositories.
+One of the repositories can be configured with an empty name; this is the default repository. When such a default repository is present, its top-level files and directories are also listed, in a **Default Repository** section placed before the repository index. If the default repository is the only repository associated with the Trac environment, then the **Repository Index** will be omitted. This means that after upgrading a single-repository Trac of version 0.11 (or earlier) to a multi-repository Trac (0.12), the repository browser will look and feel the same, that single repository becoming automatically the "default" repository.
+
+Directory entries are displayed in a list with sortable columns. The list entries can be sorted by *Name*, *Size*, *Age* or *Author* by clicking on the column headers. The sort order can be reversed by clicking on a given column header again.
+
+The browser can be used to navigate through the directory structure by clicking on the directory names.
+Clicking on a file name will show the contents of the file.
+Clicking on the revision number of a file or directory will take you to the TracRevisionLog for that file.
+Note that there's also a *Revision Log* navigation link that will do the same for the path currently being examined.
+Clicking on the *diff* icon after revision number will display the changes made to the files modified in that revision.
+Clicking on the *Age* of the file - will take you to that changeset in the timeline.
+
+It's also possible to browse directories or files as they were in history, at any given repository revision. The default behavior is to display the latest revision but another revision number can easily be selected using the *View revision* input field at the top of the page.
+
+The color bar next to the *Age* column gives a visual indication of the age of the last change to a file or directory, following the convention that **[[span(style=color:#88f,blue)]]** is oldest and **[[span(style=color:#f88,red)]]** is newest, but this can be [TracIni#browser-section configured].
+
+At the top of the browser page, there's a *Visit* drop-down menu which you can use to select some interesting places in the repository, for example branches or tags.
+This is sometimes referred to as the *browser quickjump* facility.
+The precise meaning and content of this menu depends on your repository backend.
+For Subversion, this list contains by default the top-level trunk directory and sub-directories of the top-level branches and tags directories (`/trunk`, `/branches/*`, and `/tags/*`). This can be [TracIni#svn-section configured] for more advanced cases.
+
+If you're using a Javascript enabled browser, you'll be able to expand and collapse directories in-place by clicking on the arrow head at the right side of a directory. Alternatively, the [trac:TracAccessibility keyboard] can also be used for this:
+
+    - use `j` and `k` to select the next or previous entry, starting with the first
+    - `o` (**o**pen) to toggle between expanded and collapsed state of the selected
+
+   directory or for visiting the selected file
+
+    - `v` (**v**iew, **v**isit) and `<Enter>`, same as above
+    - `r` can be used to force the **r**eload of an already expanded directory
+    - `a` can be used to directly visit a file in **a**nnotate (blame) mode
+    - `l` to view the **l**og for the selected entry
+
+If no row has been selected using `j` or `k` these keys will operate on the entry under the mouse.
+
+For the Subversion backend, some advanced additional features are available:
+
+    - The `svn:needs-lock` property will be displayed.
+    - Support for the `svn:mergeinfo` property showing the merged and eligible information.
+    - Support for browsing the `svn:externals` property, which can be [TracIni#svn:externals-section configured].
+    - The `svn:mime-type` property is used to select the syntax highlighter for rendering the file. For example, setting `svn:mime-type` to `text/html` will ensure the file is highlighted as HTML, regardless of the file extension. It also allows selecting the character encoding used in the file content. For example, if the file content is encoded in UTF-8, set `svn:mime-type` to `text/html;charset=utf-8`. The `charset=` specification overrides the default encoding defined in the `default_charset` option of the `[trac]` section of [TracIni#trac-section trac.ini].
+```#!comment
+MMM: I found this section a bit hard to understand. I changed the first item as I understood that well.
+but I think the other items could be changed also
+ cboos: in the meantime, I've added the ''advanced'' word as a hint this can be a bit complex...
+
+```
+
+----
+See also: TracGuide, TracChangeset, TracFineGrainedPermissions
diff --git a/raw-wiki-dump/TracCgi.md b/raw-wiki-dump/TracCgi.md
new file mode 100644
index 0000000..0684bd9
--- /dev/null
+++ b/raw-wiki-dump/TracCgi.md
@@ -0,0 +1,70 @@
+# Installing Trac as CGI
+[[TracGuideToc]]
+[[PageOutline]]
+
+```#!div class=important
+ ''Please note that using Trac via CGI is the slowest deployment method available. It is slower than [TracModPython mod_python], [TracFastCgi FastCGI] and even [trac:TracOnWindowsIisAjp IIS/AJP] on Windows.''
+```
+
+CGI script is the entrypoint that web-server calls when a web-request to an application is made. The `trac.cgi` script can be created using the `trac-admin <env> deploy <dir>` command which automatically substitutes the required paths, see TracInstall#cgi-bin. Make sure the script is executable by your web server.
+
+## Apache web-server configuration
+
+In [Apache](http://httpd.apache.org/) there are two ways to run Trac as CGI:
+
+ 1. Use a `ScriptAlias` directive that maps an URL to the `trac.cgi` script (recommended)
+ 1. Copy the `trac.cgi` file into the directory for CGI executables used by your web server (commonly named `cgi-bin`). You can also create a symbolic link, but in that case make sure that the `FollowSymLinks` option is enabled for the `cgi-bin` directory.
+
+To make Trac available at `http://yourhost.example.org/trac` add `ScriptAlias` directive to Apache configuration file, changing `trac.cgi` path to match your installation:
+```#!apache
+ScriptAlias /trac /path/to/www/trac/cgi-bin/trac.cgi
+```
+
+ *Note that this directive requires enabled `mod_alias` module.*
+
+If you're using Trac with a single project you need to set its location using the `TRAC_ENV` environment variable:
+```#!apache
+<Location "/trac">
+  SetEnv TRAC_ENV "/path/to/projectenv"
+</Location>
+```
+
+Or to use multiple projects you can specify their common parent directory using the `TRAC_ENV_PARENT_DIR` variable:
+```#!apache
+<Location "/trac">
+  SetEnv TRAC_ENV_PARENT_DIR "/path/to/project/parent/dir"
+</Location>
+```
+
+ *Note that the `SetEnv` directive requires enabled `mod_env` module. It is also possible to set TRAC_ENV in trac.cgi. Just add the following code between "try:" and "from trac.web ...":*
+
+```#!python
+    import os
+    os.environ['TRAC_ENV'] = "/path/to/projectenv"
+```
+
+ * Or for TRAC_ENV_PARENT_DIR: *
+
+```#!python
+    import os
+    os.environ['TRAC_ENV_PARENT_DIR'] = "/path/to/project/parent/dir"
+```
+
+If you are using the [Apache suEXEC] feature please see [trac:ApacheSuexec](http://httpd.apache.org/docs/suexec.html).
+
+On some systems, you *may* need to edit the shebang line in the `trac.cgi` file to point to your real Python installation path. On a Windows system you may need to configure Windows to know how to execute a .cgi file (Explorer -> Tools -> Folder Options -> File Types -> CGI).
+
+### Using WSGI
+
+You can run a [WSGI handler] [http://pythonweb.org/projects/webmodules/doc/0.5.3/html_multipage/lib/example-webserver-web-wsgi-simple-cgi.html under CGI].  You can [wiki:TracModWSGI#Thetrac.wsgiscript write your own application function](http://henry.precheur.org/python/how_to_serve_cgi), or use the deployed trac.wsgi's application.
+
+## Mapping Static Resources
+
+See TracInstall#MappingStaticResources.
+
+## Adding Authentication
+
+See TracInstall#ConfiguringAuthentication.
+
+----
+See also:  TracGuide, TracInstall, [wiki:TracModWSGI], TracFastCgi, TracModPython
diff --git a/raw-wiki-dump/TracChangeLog.md b/raw-wiki-dump/TracChangeLog.md
new file mode 100644
index 0000000..e396e2c
--- /dev/null
+++ b/raw-wiki-dump/TracChangeLog.md
@@ -0,0 +1,663 @@
+[[PageOutline(2-3)]]
+# Change Log
+This is a rough list of changes between released versions.
+
+To see where Trac is going in future releases, see the [trac:roadmap Roadmap].
+
+
+## 1.2.x Releases
+
+### 1.2 'Hermes'
+
+//(November 5, 2016)//
+
+Trac 1.2 is the first major release of Trac in more than 4 years.
+
+The following are some highlights from the release:
+
+
+* Extensible notification system ([trac:#3517])
+* Notification preference panel ([trac:#4056])
+* Usernames replaced with full names ([trac:#7339])
+* Restyled ticket changelog ([trac:#11835])
+* Workflow controls on the //New Ticket// page ([trac:#2045])
+* Editable wiki page version comments ([trac:#6573])
+* Datetime custom fields ([trac:#1942])
+
+
+For more information see the [trac:wiki:TracDev/ApiChanges/1.2 API changes] and the detailed
+release notes for [[trac:wiki:TracDev/ReleaseNotes/1.2#DevelopmentReleases | 1.2]] and [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.8 through 1.0.13]]
+(as 1.2 contains all the fixes done for 1.0.8 through 1.0.13).
+
+[trac:source:/tags/trac-1.2 View Tag] | [trac:milestone:1.2 View Milestone]
+
+## 1.1.x Releases
+// 1.1.x releases are development releases leading eventually to Trac 1.2. See them as kind of snapshots of [trac:source:trunk].
+
+** No guarantees of feature and API compatibility is made from one 1.1.x release to the next. //
+
+### 1.2rc1
+
+//(September 14, 2016)//
+
+The first Trac 1.2 release candidate is the culmination of nearly 4 years of development.
+
+Highlights of the changes since 1.1.6:
+
+
+    - Pygments lexer options can be specified as [WikiProcessors WikiProcessor] arguments and defaults can be set in the environment configuration ([trac:#5654]).
+    - Usernames are replaced with full names when `[trac]` `show_full_names` is true ([trac:#7339]).
+    - Enum tables on the Ticket Admin pages can be reordered by drag and drop. ([trac:#11682]).
+    - Ticket changelog is restyled and has a new //Show comments// preference ([trac:#11835]).
+    - Authentication cookies can be shared across subdomains when `[trac]` `auth_cookie_domain` is configured ([trac:#12251]).
+
+
+For more information see the [trac:wiki:TracDev/ApiChanges/1.1 API changes] and the detailed
+release notes for [[trac:wiki:TracDev/ReleaseNotes/1.1#DevelopmentReleases | 1.2rc1]] and [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.8 through 1.0.13]]
+(as 1.2rc1 contains all the fixes done for 1.0.8 through 1.0.13).
+
+[trac:source:/tags/trac-1.2rc1 View Tag] | [trac:milestone:1.2 View Milestone]
+
+### 1.1.6
+
+//(July 17, 2015)//
+
+Trac 1.1.6 contains more than a half dozen minor fixes and enhancements.
+
+For more information see the [trac:wiki:TracDev/ApiChanges/1.1 API changes] and the detailed
+release notes for [[trac:wiki:TracDev/ReleaseNotes/1.1#DevelopmentReleases | 1.1.6]] and [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.7]]
+(as 1.1.6 contains all the fixes done for 1.0.7).
+
+[trac:source:/tags/trac-1.1.6 View Tag] | [trac:milestone:1.1.6 View Milestone]
+
+
+### 1.1.5
+
+//(May 18, 2015)//
+
+Highlights of the changes:
+
+
+    - Corrected highlighting of unmodified values in //Config// section of the //About Trac// page ([trac:#6551]).
+    - New helper methods on `DatabaseManager` class for plugins to upgrade the database ([trac:#8172]).
+    - New `[notification-subscriber]` config section for general configuration of notification subscription defaults and `SubscriberList` macro ([trac:#11875]).
+    - Removed dependency on `ConfigObj` for TracFineGrainedPermissions ([trac:#11982]).
+    - `Image` macro supports InterWiki prefixes ([trac:#12025]).
+
+
+See also the [trac:wiki:TracDev/ApiChanges/1.1 API changes] and the detailed
+release notes for [[trac:wiki:TracDev/ReleaseNotes/1.1#DevelopmentReleases | 1.1.5]], [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.6]] and [[trac:wiki:TracDev/ReleaseNotes/0.12#MaintenanceReleases | 0.12.7]]
+(as 1.1.5 contains all the fixes done for 1.0.6 and 0.12.7).
+
+[trac:source:/tags/trac-1.1.5 View Tag] | [trac:milestone:1.1.5 View Milestone]
+
+### 1.1.4
+
+//(March 24, 2015)//
+
+Highlights of the changes:
+
+
+    - Performance improvements with MySQL/MariaDB ([trac:#3676]).
+    - Click on //Permissions// Admin page table row toggles all
+
+   checkboxes in the row ([trac:#11417]).
+
+    - Configuration sections are written to trac.ini when enabling a
+
+   component through TracAdmin or the web administration module
+   ([trac:#11437]).
+
+    - Subscription rules can be reordered by drag and drop ([trac:#11941]).
+
+
+See also the [trac:wiki:TracDev/ApiChanges/1.1 API changes] and the detailed
+release notes for [[trac:wiki:TracDev/ReleaseNotes/1.1#DevelopmentReleases | 1.1.4]]
+and [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.4/1.0.5]]
+(as 1.1.4 contains all the fixes done for 1.0.4 and 1.0.5).
+
+[trac:source:/tags/trac-1.1.4 View Tag] | [trac:milestone:1.1.4 View Milestone]
+
+### 1.1.3
+
+//(January 13, 2015)//
+
+The following list contains highlights of the changes:
+
+
+    - The ticket creation step can be configured in the TracWorkflow and the
+
+   workflow controls are present on the NewTicket page ([trac:#2045]).
+
+    - New notification system that can be extended by plugins ([trac:#3517]).
+    - New preferences panel for notification subscriptions ([trac:#4056]).
+    - Wiki page version comments can be edited by users with `WIKI_ADMIN` ([trac:#6573]).
+    - Improved positioning of //Add Comment// section and //author// field
+
+   on the ticket form ([trac:#10207]).
+
+    - The delete confirmation pages warn if attachments will also be deleted
+
+   ([trac:#11542]).
+
+    - Removed support for [trac:SilverCity], Enscript and PhpRenderer syntax
+
+   highlighters ([trac:#11795]).
+
+    - Combined //Date & Time// and //Language// preference panels as
+
+   //Localization// ([trac:#11813]).
+
+    - Groups and permissions can be used in the workflow `set_owner` attribute
+
+   ([trac:#11839]).
+
+See also the [trac:wiki:TracDev/ApiChanges/1.1 API changes] and the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.1#DevelopmentReleases | 1.1.3]] and [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.3]] (as 1.1.3 contains all the fixes done
+for 1.0.3).
+
+[trac:source:/tags/trac-1.1.3 View Tag] | [trac:milestone:1.1.3 View Milestone]
+
+### 1.1.2
+
+//(October 23, 2014)//
+
+The following list contains highlights of the changes:
+
+
+    - Dropped support for Python 2.5. Trac can no longer be run on Python 2.5 as incompatible changes have been made in the source code ([trac:#11600]).
+    - The new ticket workflow action `may_set_owner` is similar to `set_owner` but the owner defaults to the existing ticket owner rather than the current user ([trac:#10018]).
+    - The new option `[ticket]` `optional_fields` specifies ticket select fields that are treated as optional (i.e. an empty value is allowed) ([trac:#10772]).
+    - Line number and row highlighting annotations can be specified for WikiProcessor code blocks ([trac:#10834]).
+    - The //default handler// can be set as a session preference ([trac:#11597]), and the default value for all users can be set from the //Basic Settings// admin page ([trac:#11519]).
+    - Attachments can't be added to read-only wiki pages ([trac:#11244]).
+    - Tables on the admin pages have a //Select all// checkbox in the header ([trac:#10994]).
+    - Submit buttons are disabled if the required items are not selected ([trac:#11056]).
+    - The Admin //Permissions// page has a //Copy Permissions// form for copying permissions between users and groups ([trac:#11099]).
+    - The new option `[milestone]` `default_retarget_to` determines the default milestone for retargeting tickets when a milestone is deleted or closed, and can be specified from the //Milestone// admin page ([trac:#10010]).
+    - The //retarget// select is not shown when closing or deleting a milestone which has no tickets associated with it ([trac:#11366]).
+    - //Clear default// buttons allow the ticket system default values (e.g. `default_milestone`, `default_version`) to be cleared through the corresponding admin pages ([trac:#10772], [trac:#11300]).
+    - The `TitleIndex` macro supports relative path prefixes when used on wiki pages ([trac:#11455]).
+    - [trac:CommitTicketUpdater] will recognize a ticket reference that includes a trailing `#comment:N` or `#comment:description` ([trac:#11622]).
+    - The //Tickets// column of the milestone table on the //Milestone// admin page contains links to the query page showing all tickets associated with the milestone, grouped by status ([trac:#11661]).
+    - Authz policy can be used to restrict access to the //Report List// page using the resource id `-1` ([trac:#11697]).
+
+
+See also the [trac:wiki:TracDev/ApiChanges/1.1 API changes] and the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.1#DevelopmentReleases | 1.1.2]], [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.2]] and [[trac:wiki:TracDev/ReleaseNotes/0.12#MaintenanceReleases | 0.12.6]] (as 1.1.2 contains all the fixes done for 1.0.2 and 0.12.6).
+
+[trac:source:/tags/trac-1.1.2 View Tag] | [trac:milestone:1.1.2 View Milestone]
+
+### 1.1.1
+
+//(February 3, 2013)//
+
+Trac 1.1.1 starts the 1.1.x development line leading to 1.2 with some new features and a few not-so-disruptive changes.
+
+The following list contains only a few highlights:
+
+
+    - Added support for custom ticket fields of type time ([trac:#1942])
+    - In new tickets, custom time ticket fields may default to an absolute or relative date / time ([trac:#10853])
+    - In TracBatchModify, custom time ticket fields can be changed with a date(time)picker popup control ([trac:#10854])
+    - Optionally display the component of tickets in their timeline entries (`[timeline]` `ticket_show_component` setting) ([trac:#10885])
+    - Fixed batch modification when no fields are changed ([trac:#10924])
+    - Dynamic variables can be used in the report title and description ([trac:#10979])
+    - jQuery upgraded to 1.8.3, jQuery UI upgraded to 1.9.2 and jQuery UI Timepicker upgraded to 1.1.1 ([trac:#10976])
+    - Dropped support for Python 2.5, either Python 2.6 or Python 2.7 is required //(well, as it happens, 2.5 //still// works, that's a bug ;-) )//
+
+
+See also the [trac:wiki:TracDev/ApiChanges/1.1 API changes] and the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.1#DevelopmentReleases | 1.1.1]], [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.1]] and [[trac:wiki:TracDev/ReleaseNotes/0.12#MaintenanceReleases | 0.12.5]] (as 1.1.1 contains all the fixes done for 1.0.1 and 0.12.5).
+
+[trac:source:/tags/trac-1.1.1 View Tag] | [trac:milestone:1.1.1 View Milestone]
+
+## 1.0.x Releases
+
+### 1.0.13
+
+//(September 11, 2016)//
+
+Trac 1.0.13 provides around a dozen bug fixes and minor
+enhancements. The following are some highlights:
+
+
+    - Use locale environment variables to negotiate locale
+
+   on console ([trac:#12418]).
+
+    - Fixed using incorrect revisions when downloading a zip
+
+   file via browser page from Git repository ([trac:#12557]).
+
+[trac:source:/tags/trac-1.0.13 View Tag] | [trac:milestone:1.0.13 View Milestone]
+
+### 1.0.12
+
+//(July 4, 2016)//
+
+Trac 1.0.12 provides around 20 bug fixes and minor enhancements. The following are some highlights:
+
+
+    - Reconnect to PostgreSQL server after restarting it
+
+   ([trac:#4984]).
+
+    - Workflow actions on the batch modify form are sorted
+
+   by the default attribute ([trac:#12447]).
+
+    - Fixed Pygments stylesheet not found when style name
+
+   contained a dash ([trac:#12505]).
+
+    - Fixed incorrect parsing of projects list file by
+
+   `GitwebProjectsRepositoryProvider` ([trac:#12518]).
+
+    - `TracIni` macro displays option documentation as
+
+   multi-line rather than one-liner ([trac:#12522]).
+
+    - Fixed regression with `GitConnector` leading to
+
+   `IOError: Too many open files` ([trac:#12524]).
+
+[trac:source:/tags/trac-1.0.12 View Tag] | [trac:milestone:1.0.12 View Milestone]
+
+### 1.0.11
+
+//(May 7, 2016)//
+
+Trac 1.0.11 provides more than 30 bug fixes and minor
+enhancements. As in 1.0.10, an area of focus has been to
+eliminate tracebacks in the logs due to invalid requests.
+The following are some additional highlights:
+
+
+    - Fixed resetting //Oldest first// after auto-preview of
+
+   ticket change log ([trac:#12381]).
+
+    - Trac is now distributed as wheel package ([trac:#12391]).
+    - Fixed database exceptions in query system when
+
+   *milestones/versions/enums* are not defined and a custom
+   field of the same name is added ([trac:#12399]).
+
+    - Custom field //milestone// was not shown when
+
+   standard //milestone// field was hidden ([trac:#12400]).
+
+    - Query system now sorts by `enum.value` rather than
+
+   `ticket.type` for `order=type` ([trac:#12402]).
+
+    - Added support for Babel 2.3.2 (2.3.0 and 2.3.1 should
+
+   not be used)  ([trac:#12445]).
+
+[trac:source:/tags/trac-1.0.11 View Tag] | [trac:milestone:1.0.11 View Milestone]
+
+### 1.0.10
+
+//(February 20, 2016)//
+
+Trac 1.0.10 provides more than 30 bug fixes and minor enhancements. Two areas of focus
+have been fixing test failures on Windows and eliminating tracebacks in the logs due to
+invalid requests.
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.10]].
+
+[trac:source:/tags/trac-1.0.10 View Tag] | [trac:milestone:1.0.10 View Milestone]
+
+### 1.0.9
+
+//(September 10, 2015)//
+
+Trac 1.0.9 provides more than a dozen minor fixes and enhancements, including significantly reduced memory usage by the Git repository connector.
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.9]].
+
+[trac:source:/tags/trac-1.0.9 View Tag] | [trac:milestone:1.0.9 View Milestone]
+
+### 1.0.8
+
+//(July 24, 2015)//
+
+Trac 1.0.8 fixes a regression introduced in Trac 1.0.7: the session
+for an authenticated username containing non-alphanumeric characters
+could not be retrieved, resulting in the user being denied access to
+every realm and resource ([trac:#12129]).
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.8]].
+
+[trac:source:/tags/trac-1.0.8 View Tag] | [trac:milestone:1.0.8 View Milestone]
+
+### 1.0.7
+
+//(July 17, 2015)//
+
+Trac 1.0.7 contains more than a dozen minor fixes and enhancements, including the following highlights:
+
+    - Custom `svn:keywords` definitions are expanded in Subversion 1.8 and later ([trac:#11364]).
+    - Fixed MySQL performance regression in query with custom fields ([trac:#12113]).
+
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.7]].
+
+[trac:source:/tags/trac-1.0.7 View Tag] | [trac:milestone:1.0.7 View Milestone]
+
+### 1.0.6
+
+//(May 20, 2015)//
+
+Trac 1.0.6 provides more than 20 fixes and enhancements. The following are some highlights:
+
+    - Hash changeset ids and branch names can be used in revision ranges ([trac:#11050])
+    - Improved rendering performance using chunked response when `[trac]` `use_chunked_encoding` is `True` ([trac:#11802])
+    - Improved performance of Git repositories ([trac:#11971]).
+    - Header to send when `[trac]` `use_xsendfile` is `True` can be specified through the option `[trac]` `xsendfile_header`. X-Sendfile is supported in Nginx by specifying `X-Accel-Redirect` for the header ([trac:#11981]).
+    - Symbolic link can be used for `conf/trac.ini` in environment directory ([trac:#12000]).
+    - Hyphen character can be used in WikiProcessor parameter name ([trac:#12023]).
+
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.6]] and [[trac:wiki:TracDev/ReleaseNotes/0.12#MaintenanceReleases | 0.12.7]] (as 1.0.6 also contains the changes in 0.12.7).
+
+[trac:source:/tags/trac-1.0.6 View Tag] | [trac:milestone:1.0.6 View Milestone]
+
+### 1.0.5
+
+//(March 24, 2015)//
+
+Trac 1.0.5 provides several fixes. The following are some highlights:
+
+
+    - Images are not rendered in the timeline ([trac:#10751]).
+    - Git tags are shown in the browser view ([trac:#11964]).
+    - Added support for `journal_mode` and `synchronous` pragmas
+
+   in `sqlite:` database connection string ([trac:#11967]).
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.5]].
+
+[trac:source:/tags/trac-1.0.5 View Tag] | [trac:milestone:1.0.5 View Milestone]
+
+### 1.0.4
+
+//(February 8, 2015)//
+
+Trac 1.0.4 contains a few fixes, including a fix for a regression in 1.0.3.
+
+
+    - Workflow action labels were not displayed unless name attribute
+
+   was explicitly defined ([trac:#11930]).
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.4]].
+
+[trac:source:/tags/trac-1.0.4 View Tag] | [trac:milestone:1.0.4 View Milestone]
+
+### 1.0.3
+
+//(January 13, 2015)//
+
+Trac 1.0.3 is a maintenance release containing numerous fixes and minor
+enhancements. The following are a few of the highlights:
+
+The following list contains only a few highlights:
+
+
+    - Notification is sent when adding an attachment to a ticket ([trac:#2259]).
+    - Stylesheets and scripts are loaded during autopreview, resulting in proper
+
+   syntax highlighting when code WikiProcessors are added ([trac:#10470]) and display
+   of Workflow graphs without explicit autopreview ([trac:#10674]).
+
+    - Merge changesets are shown as differences against first parent, resulting
+
+   in less noisy changesets ([trac:#10740]).
+
+    - Pygments 2.0 is supported ([trac:#11796]).
+    - Fixed error when completing the `initenv` TracAdmin command ([trac:#11797]).
+    - Performance improvement on systems with many thousands of authenticated
+
+   users due to caching of Environment.get_known_users ([trac:#11868]).
+
+    - Distribution metadata of wheel package is supported and displayed on the
+
+   About page ([trac:#11877]).
+
+    - … and more than 3 dozen total fixes!
+
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.3]].
+
+[trac:source:/tags/trac-1.0.3 View Tag] | [trac:milestone:1.0.3 View Milestone]
+
+
+### 1.0.2
+
+//(October 23, 2014)//
+
+Trac 1.0.2 contains a number of bug fixes and minor enhancements, as well as a major update for many translations.
+
+The following list contains only a few highlights:
+
+
+    - Subversion keywords are expanded and EOL substitutions made when viewing a file in the repository browser and when downloading a file ([trac:#717]).
+    - Notification email is sent to the old owner when a ticket is reassigned ([trac:#2311]).
+    - Ticket change history is updated when renaming and deleting a milestone, and when retargeting tickets to another milestone ([trac:#4582], [trac:#5658]).
+    - Numerous fixes for the Authz permissions policy in the browser/repository ([trac:#10961], [trac:#11646]), wiki ([trac:#8976], [trac:#11067]), admin ([trac:#11069]) and report ([trac:#11176]) realms.
+    - Multiple forms submits are disallowed ([trac:#10138]).
+    - `ConfigurationError` is raised if any of the `permission_policies` can't be loaded, preventing possible information leakage due to internal and installation errors ([trac:#10285]).
+    - Wiki toolbars can be disabled through a configuration setting ([trac:#10837])
+    - The number of entries in a table is shown next to heading on applicable admin pages ([trac:#11027]).
+    - //Cancel// buttons are consistently located on all pages ([trac:#11076]).
+    - Focus is placed on a text element when an edit page is loaded ([trac:#11084]).
+    - The //Edit conflict// and //Merge// warning messages are always visible in side-by-side edit mode ([trac:#11102]).
+    - Improvements to the layout of the Report ([trac:#11106], [trac:#11664]) and Ticket pages ([trac:#11471]).
+    - Genshi 0.7 compatibility ([trac:#11218]).
+    - Numerous minor fixes for Git repository support.
+    - … and more than a hundred more fixes!
+
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.2]] and [[trac:wiki:TracDev/ReleaseNotes/0.12#MaintenanceReleases | 0.12.6]] (as 1.0.2 contains all the fixes done for 0.12.6).
+
+[trac:source:/tags/trac-1.0.2 View Tag] | [trac:milestone:1.0.2 View Milestone]
+
+
+### 1.0.1
+
+//(February 1, 2013)//
+
+Trac 1.0.1 contains a number of bug fixes and minor enhancements, as well as a major update for many translations.
+
+The following list contains only a few highlights:
+
+
+    - Fix zip source download for large directories in Subversion repositories ([trac:#10840])
+    - Performance improvement for the Roadmap, by caching milestone properties ([trac:#10879])
+    - Added a *select all* checkbox to table of components for each plugin on the Plugins admin panel ([trac:#9609])
+    - Restore the *Modify* link at the top of the ticket page, as it was in Trac 0.12 ([trac:#10856])
+    - `ListOption` keeps values other than empty string and None in raw list as default ([trac:#10541])
+    - Prevent possibility of multiple identical info or warning messages being presented to the user ([trac:#10987])
+    - The BatchModify select-all checkboxes are toggled with tri-state behavior when the ticket checkboxes are toggled ([trac:#10992])
+    - Update the ticket changetime to the current time when deleting a ticket comment ([trac:#10486])
+
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/1.0#MaintenanceReleases | 1.0.1]] and [[trac:wiki:TracDev/ReleaseNotes/0.12#MaintenanceReleases | 0.12.5]] (as 1.0.1 contains all the fixes done for 0.12.5).
+
+[trac:source:/tags/trac-1.0.1 View Tag] | [trac:milestone:1.0.1 View Milestone]
+
+
+### **1.0 'Cell' **
+
+//(September 7, 2012)//
+
+Trac 1.0 is a major release adding refreshed user interface and improved DVCS repository support as the most visible changes.
+
+The following list contains only a few highlights:
+
+    - The default theme looks more modern, especially on recent browsers (no effort has been made to make it look better on older browsers like IE6 or 7)
+    - The [TH:GitPlugin] has been donated by Herbert Valerio Riedel to the Trac project (many thanks!) and is now maintained here as an optional component
+    - As a consequence, the Subversion support has been moved below `tracopt.versioncontrol` as well
+    - The Git and Mercurial log view feature a visualization of the branching structure
+    - Usability improvements for the tickets, with a better support for conflict detection and resolution
+    - Integration of the [TH:BatchModifyPlugin], contributed by Brian Meeker (many thanks!) and is now maintained there as a default component
+    - jQuery/UI integration, featuring a date picker for date fields
+    - Improved integration with Pygments syntax highlighting
+    - ... and numerous smaller features added and bugs fixed since 0.12!
+
+
+See the full list in [trac:wiki:TracDev/ReleaseNotes/1.0 1.0].
+
+[[trac:source:/tags/trac-1.0 View Tag]] | [[trac:milestone:1.0 View Milestone]]
+
+## 0.12.x Releases
+
+### 0.12.7
+
+//(July 12, 2015)//
+
+Trac 0.12.7 fixes a minor security issue, as well as a half dozen other minor issues:
+
+    - InterWiki filters links through `[wiki] safe_schemes` option if `[wiki] render_unsafe_content` is disabled ([trac:#12053]).
+
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/0.12#MaintenanceReleases | 0.12.7]].
+
+[trac:source:/tags/trac-0.12.7 View Tag] | [trac:milestone:0.12.7 View Milestone]
+
+### 0.12.6
+
+//(October 23, 2014)//
+
+Trac 0.12.6 contains fixes for a few issues:
+
+    - Subversion blame would fail for a path with URL-encoded characters ([trac:#10386]), a lower-case drive letter on Windows ([trac:#10514]), or a non-ascii filename with Subversion 1.7 ([trac:#11167]).
+    - Improved performance rendering `svn:mergeinfo` properties in browser view ([trac:#8459]) and changeset view ([trac:#11219]).
+    - Query with many custom fields would fail ([trac:#11140]).
+    - Zip archive had a timestamp with no timezone information ([trac:#11162]).
+    - Failure or incorrect ranges rendering log TracLinks ([trac:#11308], [trac:#11346]).
+    - Textareas in ticket view did not wrap correctly in IE 11 ([trac:#11376]).
+    - Emails were not being obfuscated in owner field on CSV export from ticket and query pages ([trac:#11594]).
+    - Locale data was not being included in egg in Distribute 0.6.29 and later ([trac:#11640]).
+    - Deleting a milestone would not delete its attachments ([trac:#11672]).
+    - Added support for Babel 1.0 and later ([trac:#11258], [trac:#11345]).
+    - Added support for `ConfigObj` 5.0 and later ([trac:#11498]).
+    - … and dozens more fixes!
+
+
+See the detailed release notes for [[trac:wiki:TracDev/ReleaseNotes/0.12#MaintenanceReleases | 0.12.6]].
+
+[trac:source:/tags/trac-0.12.6 View Tag] | [trac:milestone:0.12.6 View Milestone]
+
+### 0.12.5
+
+//(January 15, 2013)//
+
+Trac 0.12.5 contains fixes for a few issues:
+
+    - upload of .mht files ([Wikipedia:MHTML] web page archive files) now works ([trac:#9880])
+    - more robust parsing of attachment URLs ([trac:#10280]) and uploaded file names ([trac:#10850])
+    - lots of improvement to the date formatting code, which is now much more robust when timezone and daylight saving time computations are involved ([trac:#10768], [trac:#10863], [trac:#10864], [trac:#10912], [trac:#10920])
+    - no longer generate invalid JSON encoded data with Python 2.4 and 2.5 ([trac:#10877])
+    - ... and fix a couple more minor defects ([trac:#10967], [trac:#10892], [trac:#10923], [trac:#10858], [trac:#10835])
+
+
+[trac:source:/tags/trac-0.12.5 View Tag] | [trac:milestone:0.12.5 View Milestone]
+
+### 0.12.4
+
+//(September 7, 2012)//
+
+Trac 0.12.4 contains only a handful of minor fixes.
+
+[trac:source:/tags/trac-0.12.4 View Tag] | [trac:milestone:0.12.4 View Milestone]
+
+### 0.12.3
+
+//(February 6, 2012)//
+
+Trac 0.12.3 contains a few minor fixes and a few minor features.
+
+    - compatibility with Subversion 1.7 ([trac:#10414])
+    - easier troubleshooting of common startup errors ([trac:#10024])
+    - jQuery upgraded to 1.4.4 ([trac:#10001])
+    - improve fine-grained permission handling in the source browser ([trac:#9976], [trac:#10208], [trac:#10110])
+    - added compatibility with MySQL 5.5.3 utf8mb4 databases ([trac:#9766])
+    - ... and dozens more fixes!
+
+
+[trac:source:/tags/trac-0.12.3 View Tag] | [trac:milestone:0.12.3 View Milestone]
+
+### 0.12.2
+
+//(January 31, 2011)//
+
+Trac 0.12.2 contains a few minor fixes and a few minor features.
+
+This list contains only a few highlights:
+
+    - install: improved robustness of Trac installation if Babel is
+
+   installed after the fact ([trac:#9439], [trac:#9595], [trac:#9961])
+
+    - notifications: support for Asian character width ([trac:#4717])
+    - roadmap: fix display of progress bar in some corner cases ([trac:#9718])
+
+   and respect the overall_completion milestone group setting ([trac:#9721])
+
+    - reports: reports and queries look much better, as the columns now
+
+   keep the same width across groups; the absence of word wrapping in
+   reports has been fixed ([trac:#9825])
+
+    - web admin: improved layout ([trac:#8866], [trac:#9963])
+    - web: it's now possible to log in different Trac instances sharing
+
+   the same URL prefix (e.g. /project and /project-test) ([trac:#9951])
+
+[trac:source:/tags/trac-0.12.2 View Tag] | [trac:milestone:0.12.2 View Milestone]
+
+### 0.12.1
+
+//(October 9, 2010)//
+
+Trac 0.12.1 contains a few important performance improvements, some minor fixes and a few minor features.
+
+This list contains only a few highlights:
+
+    - db: improve concurrency behavior ([trac:#9111])
+    - fcgi: add an environment variable `TRAC_USE_FLUP` to control the usage of flup vs. bundled _fcgi.py (defaults to 0, i.e. use bundled as before)
+    - svn authz: improve compatibility with svn 1.5 format ([trac:#8289])
+    - milestone: allow to set the time for the due date ([trac:#6369], [trac:#9582])
+    - ticket: fixes for the CC: property ([trac:#8597], [trac:#9522])
+    - notification: improved the formatting of ticket fields in notification e-mails ([trac:#9484], [trac:#9494])
+    - i18n: added a configuration option to set the default language ([trac:#8117])
+    - several fixes for upgrade ([trac:#9400], [trac:#9416], [trac:#9483], [trac:#9556])
+
+
+[trac:source:/tags/trac-0.12.1 View Tag] | [trac:milestone:0.12.1 View Milestone]
+
+### ** 0.12 'Babel' **
+
+//(June 13, 2010)//
+
+Trac 0.12 is a major release introducing i18n and multiple repository support as the most visible changes.
+
+The following list contains only a few highlights:
+
+    - The user interface is translated in a dozen of languages, provided the [Babel:] package is installed
+    - Multiple repositories can be associated to a single Trac environment; the repositories can be of heterogeneous types (svn, hg, git, darcs...)
+    - Usability improvements for the Wiki, with a nice side-by-side edit mode with automatic preview
+    - Richer Wiki syntax, with much improved support for tables, partial [trac:WikiCreole] compatibility and numerous smaller improvements
+    - Usability improvements for the Ticket module, with automatic preview of comments while you type and possibility to edit or remove them later
+    - Improved Custom Queries (time fields, multiple disjoint conditions, a.k.a. OR queries)
+    - Timeline filtering by user
+    - ... and numerous smaller features added and bugs fixed since 0.11!
+
+
+[trac:source:/tags/trac-0.12 View Tag] | [trac:milestone:0.12 View Milestone]
+
+## Older Releases
+
+For releases prior to 0.12, see [trac:TracChangeLog@95].
diff --git a/raw-wiki-dump/TracChangeset.md b/raw-wiki-dump/TracChangeset.md
new file mode 100644
index 0000000..3d32446
--- /dev/null
+++ b/raw-wiki-dump/TracChangeset.md
@@ -0,0 +1,78 @@
+# Trac Changeset Module
+
+[[TracGuideToc]]
+[[PageOutline(2-5,Contents,pullout)]]
+
+Trac has a built-in functionality for visualizing "diffs", or changes to files.
+
+There are different kinds of *change sets*.  Some correspond to revisions made in the repositories, others aggregate changes made in several revisions. Ultimately, any kind of difference can be shown.
+
+The changeset view consists of two parts, the *header* and the *diff views*.
+
+## Changeset Header
+
+The header shows an overview of the whole changeset.
+Here you will find information such as:
+
+
+    * Timestamp — When the changeset was commited
+    * Author — Who commited the changeset
+    * Message — A brief description from the author (the commit log message)
+    * Location — Parent directory of all files affected by this changeset
+    * Files — A list of files affected by this changeset
+
+
+If more than one revision is involved in the set of changes being displayed, the *Timestamp*, *Author* and *Message* fields will not be shown.
+
+A colored rectangle indicates how the file is affected by the changeset:
+
+ [[span(style=background:#bfb;border:1px solid #999;font-size:80%;margin-right:.5em,*  *)]] Green: Added \\
+ [[span(style=background:#f88;border:1px solid #999;font-size:80%;margin-right:.5em,*  *)]] Red: Removed \\
+ [[span(style=background:#fd8;border:1px solid #999;font-size:80%;margin-right:.5em,*  *)]] Yellow: Modified \\
+ [[span(style=background:#88f;border:1px solid #999;font-size:80%;margin-right:.5em,*  *)]] Blue: Copied \\
+ [[span(style=background:#ccc;border:1px solid #999;font-size:80%;margin-right:.5em,*  *)]] Gray: Moved \\
+The color legend is located below the header as a reminder.
+
+## Diff Views
+
+Below the header is the main part of the changeset, the diff view. Each file is shown in a separate section, each of which contains only the regions of the file that are affected by the changeset. There are two different styles to display the diffs: *inline* or *side-by-side*. You can switch between the styles using the preferences form:
+
+
+    * The *inline* style shows the changed regions of a file underneath each other. A region removed from the file will be colored red, an added region will be colored green. If a region was modified, the old version is displayed above the new version. Line numbers indicate the exact position of the change in both the old and the new version of the file.
+    * The *side-by-side* style shows the old version on the left and the new version on the right and this will typically require more screen width than the inline style. Added and removed regions will be colored in the same way as with the inline style (green and red), and modified regions will have a yellow background.
+
+
+In addition, various advanced options are available in the preferences form for adjusting the display of the diffs:
+
+    * You can set how many lines are displayed before and after every change; if the value *all* is used, then the full file will be shown.
+    * You can toggle whether blank lines, case changes and white space changes are ignored, thereby letting you find the functional changes more quickly.
+
+
+## The Different Ways to Get a Diff
+
+### Examining a Changeset
+
+When viewing a repository check-in, such as when following a changeset [wiki:TracLinks link] or a changeset event in the [wiki:TracTimeline timeline], Trac will display the exact changes made by the check-in.
+
+There will be also navigation links to the *Previous Changeset* to and *Next Changeset*.
+
+### Examining Differences Between Revisions
+
+Often you want to look at changes made on a file or on a directory spanning multiple revisions. The easiest way to get there is from the TracRevisionLog, where you can select the *old* and the *new* revisions of the file or directory, and then click the *View changes* button.
+
+### Examining Differences Between Branches
+
+One of the core features of version control systems is the possibility to work simultaneously on different *Lines of Developments*, commonly called "branches". Trac enables you to examine the exact differences between such branches.
+
+Using the **View changes ...** button in the TracBrowser allows you to enter *From:* and *To:* path/revision pairs. The resulting set of differences consist of the changes that should be applied to the *From:* content to get to the *To:* content.
+
+For convenience, it is possible to invert the roles of the *old* and the *new* path/revision pairs by clicking the *Reverse Diff* link on the changeset page.
+
+### Checking the Last Change
+
+Another way to examine changes is to use the *Last Change* link provided by the TracBrowser.
+
+This link will take you to the last change that was made on that path. From there, you can use the *Previous Change* and *Next Change* links to traverse the change history of the file or directory.
+
+----
+See also: TracGuide, TracBrowser
diff --git a/raw-wiki-dump/TracEnvironment.md b/raw-wiki-dump/TracEnvironment.md
new file mode 100644
index 0000000..bc57a33
--- /dev/null
+++ b/raw-wiki-dump/TracEnvironment.md
@@ -0,0 +1,139 @@
+# The Trac Environment
+
+[[TracGuideToc]]
+[[PageOutline(2-5,Contents,pullout)]]
+
+Trac uses a directory structure and a database for storing project data. The directory is referred to as the environment.
+Trac uses a directory structure and a database for storing project data. The directory is referred to as the **environment**.
+
+Trac supports [SQLite], [http://www.postgresql.org/ PostgreSQL] and [http://mysql.com/ MySQL](http://sqlite.org/) databases. With PostgreSQL and MySQL you have to create the database before running `trac-admin initenv`.
+
+## Creating an Environment
+
+A new Trac environment is created using the [TracAdmin#initenv initenv] command:
+```#!sh
+$ trac-admin /path/to/myproject initenv
+```
+
+`trac-admin` will ask you for the name of the project and the [#DatabaseConnectionStrings database connection string].
+
+### Useful Tips
+
+
+    - Place your environment's directory on a filesystem which supports sub-second timestamps, as Trac monitors the timestamp of its configuration files and changes happening on a filesystem with too coarse-grained timestamp resolution may go undetected in Trac < 1.0.2. This is also true for the location of authentication files when using TracStandalone.
+
+
+
+    - The user under which the web server runs will require file system write permission to the environment directory and all the files inside. Please remember to set the appropriate permissions. The same applies to the source code repository, although the user under which Trac runs will only require write access to a Subversion repository created with the BDB file system; for other repository types, check the corresponding plugin's documentation.
+
+
+
+    - `initenv` does not create a version control repository for the specified path. If you wish to specify a default repository using optional the arguments to `initenv` you must create the repository first, otherwise you will see a message when initializing the environment: //Warning: couldn't index the default repository//.
+
+
+
+    - Non-ascii environment paths are not supported.
+
+
+
+    - TracPlugins located in a [TracIni#inherit-section shared plugins folder] that is defined in an [TracIni#GlobalConfiguration inherited configuration] are not loaded during creation, and hence, if they need to create extra tables for example, you'll need to [TracUpgrade#UpgradetheTracEnvironment upgrade the environment]. Alternatively you can avoid the need to upgrade the environment by specifying a configuration file at the time the environment is created, using the `--config` option. See TracAdmin#FullCommandReference for more information.
+
+
+```#!div style="border: 1pt dotted; margin: 1em"
+**Caveat:** don't confuse the //Trac environment directory// with the //source code repository directory//.
+
+This is a common beginners' mistake.
+It happens that the structure for a Trac environment is loosely modeled after the Subversion repository directory structure, but those are two disjoint entities and they are not and //must not// be located at the same place.
+```
+
+## Database Connection Strings
+
+You will need to specify a database connection string at the time the environment is created. The default is SQLite, which is probably sufficient for most projects. The SQLite database file is stored in the environment directory, and can easily be [wiki:TracBackup backed up] together with the rest of the environment.
+
+Note that if the username or password of the connection string (if applicable) contains the `:`, `/` or `@` characters, they need to be URL encoded.
+
+### SQLite Connection String
+
+The connection string for an SQLite database is:
+```
+sqlite:db/trac.db
+```
+where `db/trac.db` is the path to the database file within the Trac environment.
+
+### PostgreSQL Connection String
+
+The connection string for PostgreSQL is a bit more complex. For example, to connect to a PostgreSQL database named `trac` on `localhost` for user `johndoe` and password `letmein`, use:
+```
+postgres://johndoe:letmein@localhost/trac
+```
+
+If PostgreSQL is running on a non-standard port, for example 9342, use:
+```
+postgres://johndoe:letmein@localhost:9342/trac
+```
+
+On UNIX, you might want to select a UNIX socket for the transport, either the default socket as defined by the PGHOST environment variable:
+```
+postgres://user:password@/database
+```
+
+or a specific one:
+```
+postgres://user:password@/database?host=/path/to/socket/dir
+```
+
+See the [PostgreSQL documentation] for detailed instructions on how to administer [http://postgresql.org PostgreSQL](http://www.postgresql.org/docs/).
+Generally, the following is sufficient to create a database user named `tracuser` and a database named `trac`:
+```#!sh
+$ createuser -U postgres -E -P tracuser
+$ createdb -U postgres -O tracuser -E UTF8 trac
+```
+
+When running `createuser` you will be prompted for the password for the user 'tracuser'. This new user will not be a superuser, will not be allowed to create other databases and will not be allowed to create other roles. These privileges are not needed to run a Trac instance. If no password is desired for the user, simply remove the `-P` and `-E` options from the `createuser` command. Also note that the database should be created as UTF8. LATIN1 encoding causes errors, because of Trac's use of unicode. SQL_ASCII also seems to work.
+
+Under some default configurations (Debian), run the `createuser` and `createdb` scripts as the `postgres` user:
+```#!sh
+$ sudo su - postgres -c 'createuser -U postgres -S -D -R -E -P tracuser'
+$ sudo su - postgres -c 'createdb -U postgres -O tracuser -E UTF8 trac'
+```
+
+Trac uses the `public` schema by default, but you can specify a different schema in the connection string:
+```
+postgres://user:pass@server/database?schema=yourschemaname
+```
+
+### MySQL Connection String
+
+The format of the MySQL connection string is similar to those for PostgreSQL, with the `postgres` scheme being replaced by `mysql`. For example, to connect to a MySQL database on `localhost` named `trac` for user `johndoe` with password `letmein`:
+```
+mysql://johndoe:letmein@localhost:3306/trac
+```
+
+## Source Code Repository
+
+A single environment can be connected to more than one repository. However, by default Trac is not connected to any source code repository, and the *Browse Source* navigation item will not be displayed.
+
+There are many different ways to connect repositories to an environment, see TracRepositoryAdmin. A single repository can be specified when the environment is created by passing the optional arguments `repository_type` and `repository_dir` to the `initenv` command.
+
+## Directory Structure
+
+An environment consists of the following files and directories:
+
+
+    * `README` - Brief description of the environment.
+    * `VERSION` - Environment version identifier.
+    * `files`
+        * `attachments` - Attachments to wiki pages and tickets.
+    * `conf`
+        * `trac.ini` - Main configuration file. See TracIni.
+    * `db`
+        * `trac.db` - The SQLite database, if you are using SQLite.
+    * `htdocs` - Directory containing web resources, which can be referenced in Genshi templates using `/chrome/site/...` URLs.
+    * `log` - Default directory for log files, if `file` logging is enabled and a relative path is given.
+    * `plugins` - Environment-specific [wiki:TracPlugins plugins].
+    * `templates` - Custom Genshi environment-specific templates.
+        * `site.html` - Method to customize header, footer, and style, described in TracInterfaceCustomization#SiteAppearance.
+
+
+----
+See also: TracAdmin, TracBackup, TracIni, TracGuide
diff --git a/raw-wiki-dump/TracFastCgi.md b/raw-wiki-dump/TracFastCgi.md
new file mode 100644
index 0000000..2a499bf
--- /dev/null
+++ b/raw-wiki-dump/TracFastCgi.md
@@ -0,0 +1,457 @@
+# Trac with FastCGI
+
+[[TracGuideToc]]
+[[PageOutline(2-5, Contents, floated)]]
+
+[FastCGI] interface allows Trac to remain resident much like with [wiki:TracModPython mod_python] or [wiki:TracModWSGI mod_wsgi](http://www.fastcgi.com/). It is faster than external CGI interfaces which must start a new process for each request. Additionally, it is supported by a much wider variety of web servers.
+
+Note that unlike mod_python, FastCGI supports [Apache SuEXEC](http://httpd.apache.org/docs/suexec.html), ie run with different permissions than the web server runs with. `mod_wsgi` supports the `WSGIDaemonProcess` with user / group parameters to achieve the same effect.
+
+**Note for Windows:** Trac's FastCGI does not run under Windows, as Windows does not implement `Socket.fromfd`, which is used by `_fcgi.py`. If you want to connect to IIS, you may want to try [trac:TracOnWindowsIisAjp AJP]/[trac:TracOnWindowsIisAjp ISAPI].
+
+## Apache configuration
+
+There are two FastCGI modules commonly available for Apache: `mod_fastcgi` and `mod_fcgid` (preferred). The latter is more up-to-date.
+
+The following sections focus on the FCGI specific setup, see also [wiki:TracModWSGI#ConfiguringAuthentication] for configuring the authentication in Apache.
+
+Regardless of which cgi module is used, be sure the web server has executable permissions on the cgi-bin folder. While FastCGI will throw specific permissions errors, mod_fcgid will throw an ambiguous error if this has not been done: `Connection reset by peer: mod_fcgid: error reading data from FastCGI server`.
+
+### Set up with `mod_fastcgi`
+
+`mod_fastcgi` uses `FastCgiIpcDir` and `FastCgiConfig` directives that should be added to an appropriate Apache configuration file:
+```#!apache
+# Enable fastcgi for .fcgi files
+# (If you're using a distro package for mod_fcgi, something like
+# this is probably already present)
+<IfModule mod_fastcgi.c>
+   AddHandler fastcgi-script .fcgi
+   FastCgiIpcDir /var/lib/apache2/fastcgi
+</IfModule>
+LoadModule fastcgi_module /usr/lib/apache2/modules/mod_fastcgi.so
+```
+
+Setting `FastCgiIpcDir` is optional if the default is suitable. Note that the `LoadModule` line must be after the `IfModule` group.
+
+Configure `ScriptAlias` or similar options as described in TracCgi, but calling `trac.fcgi` instead of `trac.cgi`.
+
+Add the following to the Apache configuration file (below the `FastCgiIpcDir` line) if you intend to set up the `TRAC_ENV` as an overall default:
+```#!apache
+FastCgiConfig -initial-env TRAC_ENV=/path/to/env/trac
+```
+
+Alternatively, you can serve multiple Trac projects in a directory by adding this:
+```#!apache
+FastCgiConfig -initial-env TRAC_ENV_PARENT_DIR=/parent/dir/of/projects
+```
+
+### Set up with `mod_fcgid`
+
+Configure `ScriptAlias` (see TracCgi for details), but call `trac.fcgi` instead of `trac.cgi`:
+```#!apache
+ScriptAlias /trac /path/to/www/trac/cgi-bin/trac.fcgi/
+```
+
+Note the slash at the end.
+
+To set up Trac environment for `mod_fcgid` it is necessary to use `DefaultInitEnv` directive. It cannot be used in `Directory` or `Location` context, so if you need to support multiple projects, try the alternative environment setup below:
+```#!apache
+DefaultInitEnv TRAC_ENV /path/to/env/trac/
+```
+
+### Alternative environment setup
+
+A better method to specify the path to the Trac environment is to embed the path into `trac.fcgi` script itself. That doesn't require configuration of the server environment variables, works for both [modules as well as for [http://www.lighttpd.net/ lighttpd](trac:FastCgi]) and CGI:
+```#!python
+import os
+os.environ['TRAC_ENV'] = "/path/to/projectenv"
+```
+
+or:
+```#!python
+import os
+os.environ['TRAC_ENV_PARENT_DIR'] = "/path/to/project/parent/dir"
+```
+
+With this method different projects can be supported by using different `.fcgi` scripts with different `ScriptAliases`.
+
+See [this fcgid example config](https://coderanger.net/~coderanger/httpd/fcgi_example.conf) which uses a ScriptAlias directive with trac.fcgi with a trailing / like this:
+```#!apache
+ScriptAlias / /srv/tracsite/cgi-bin/trac.fcgi/
+```
+
+## Cherokee Configuration
+
+Configuring [Cherokee](http://cherokee-project.com/) with Trac is straightforward, if you spawn Trac as an SCGI process. You can either start it manually, or better yet, automatically by letting Cherokee spawn the server whenever it is down.
+
+First set up an information source in cherokee-admin with a local interpreter:
+
+```
+Host:
+localhost:4433
+
+Interpreter:
+/usr/bin/tracd —single-env —daemonize —protocol=scgi —hostname=localhost —port=4433 /path/to/project/
+```
+
+If the port was not reachable, the interpreter command would be launched. Note that, in the definition of the information source, you will have to manually launch the spawner if you use a *Remote host* as *Information source* instead of a *Local interpreter*.
+
+After doing this, we will just have to create a new rule managed by the SCGI handler to access Trac. It can be created in a new virtual server, trac.example.net for instance, and will only need two rules. The **default** one will use the SCGI handler associated to the previously created information source.
+The second rule will be there to serve the few static files needed to correctly display the Trac interface. Create it as *Directory rule* for */common* and just set it to the *Static files* handler and with a *Document root* that points to the appropriate files: *$TRAC_LOCAL/htdocs/* (where $TRAC_LOCAL is a directory defined by the user or the system administrator to place local Trac resources).
+
+**Note:** If the tracd process fails to start up, and Cherokee displays a 503 error page, you might be missing the [python-flup] package ([trac:#9903](http://trac.saddi.com/flup)). Python-flup is a dependency which provides Trac with SCGI capability. You can install it on Debian based systems with:
+```#!sh
+sudo apt-get install python-flup
+```
+
+## Lighttpd Configuration
+
+The FastCGI front-end was developed primarily for use with alternative webservers, such as [Lighttpd](http://www.lighttpd.net/).
+
+Lighttpd is a secure, fast, compliant and very flexible web-server that has been optimized for high-performance environments. It has a very low memory footprint compared to other web servers and takes care of CPU load.
+
+For using `trac.fcgi`(prior to 0.11) / fcgi_frontend.py (0.11) with Lighttpd add the following to your lighttpd.conf:
+```
+#var.fcgi_binary="/usr/bin/python /path/to/fcgi_frontend.py" # 0.11 if installed with easy_setup, it is inside the egg directory
+var.fcgi_binary="/path/to/cgi-bin/trac.fcgi" # 0.10 name of prior fcgi executable
+fastcgi.server = ("/trac" =>
+
+                   ("trac" =>
+                     ("socket" => "/tmp/trac-fastcgi.sock",
+                      "bin-path" => fcgi_binary,
+                      "check-local" => "disable",
+                      "bin-environment" =>
+                        ("TRAC_ENV" => "/path/to/projenv")
+                     )
+                   )
+                 )
+```
+
+Note that you will need to add a new entry to `fastcgi.server` for each separate Trac instance that you wish to run. Alternatively, you may use the `TRAC_ENV_PARENT_DIR` variable instead of `TRAC_ENV` as described above, and you may set one of the two in `trac.fcgi` instead of in `lighttpd.conf` using `bin-environment`, as in the section above on Apache configuration.
+
+Note that Lighttpd has a bug related to 'SCRIPT_NAME' and 'PATH_INFO' when the uri of fastcgi.server is '/' instead of '/trac' in this example (see [trac:#2418]). This is fixed in Lighttpd 1.5, and under Lighttpd 1.4.23 or later the workaround is to add `"fix-root-scriptname" => "enable"` as a parameter of fastcgi.server.
+
+For using two projects with lighttpd add the following to your `lighttpd.conf`:
+```
+fastcgi.server = ("/first" =>
+                   ("first" =>
+                    ("socket" => "/tmp/trac-fastcgi-first.sock",
+                     "bin-path" => fcgi_binary,
+                     "check-local" => "disable",
+                     "bin-environment" =>
+                       ("TRAC_ENV" => "/path/to/projenv-first")
+                    )
+                  ),
+                  "/second" =>
+                    ("second" =>
+                    ("socket" => "/tmp/trac-fastcgi-second.sock",
+                     "bin-path" => fcgi_binary,
+                     "check-local" => "disable",
+                     "bin-environment" =>
+                       ("TRAC_ENV" => "/path/to/projenv-second")
+                    )
+                  )
+                )
+```
+
+Note that the field values are different. If you prefer setting the environment variables in the `.fcgi` scripts, then copy/rename `trac.fcgi`, eg to `first.fcgi` and `second.fcgi`, and reference them in the above settings.
+Note that the above will result in different processes in any event, even if both are running from the same `trac.fcgi` script.
+
+```#!div class=important
+'''Note:''' The order in which the server.modules are loaded is very important: if mod_auth is not loaded '''before''' mod_fastcgi, then the server will fail to authenticate the user.
+```
+
+For authentication you should enable mod_auth in lighttpd.conf 'server.modules', select auth.backend and auth rules:
+```
+server.modules              = (
+...
+  "mod_auth",
+...
+)
+
+auth.backend               = "htpasswd"
+
+# Separated password files for each project
+# See "Conditional Configuration" in
+# http://trac.lighttpd.net/trac/file/branches/lighttpd-merge-1.4.x/doc/configuration.txt
+
+$HTTP["url"] =~ "^/first/" {
+  auth.backend.htpasswd.userfile = "/path/to/projenv-first/htpasswd.htaccess"
+}
+$HTTP["url"] =~ "^/second/" {
+  auth.backend.htpasswd.userfile = "/path/to/projenv-second/htpasswd.htaccess"
+}
+
+# Enable auth on trac URLs, see
+# http://trac.lighttpd.net/trac/file/branches/lighttpd-merge-1.4.x/doc/authentication.txt
+
+auth.require = ("/first/login" =>
+                ("method"  => "basic",
+                 "realm"   => "First project",
+                 "require" => "valid-user"
+                ),
+                "/second/login" =>
+                ("method"  => "basic",
+                 "realm"   => "Second project",
+                 "require" => "valid-user"
+                )
+               )
+
+```
+
+Note that Lighttpd (v1.4.3) stops if the password file doesn't exist.
+
+Note that Lighttpd doesn't support 'valid-user' in versions prior to 1.3.16.
+
+Conditional configuration is also useful for mapping static resources, ie serving out images and CSS directly instead of through FastCGI:
+```
+# Aliasing functionality is needed
+server.modules += ("mod_alias")
+
+# Set up an alias for the static resources
+alias.url = ("/trac/chrome/common" => "/usr/share/trac/htdocs")
+
+# Use negative lookahead, matching all requests that ask for any resource under /trac, EXCEPT in
+# /trac/chrome/common, and use FastCGI for those
+$HTTP["url"] =~ "^/trac(?!/chrome/common)" {
+# Even if you have other fastcgi.server declarations for applications other than Trac, do NOT use += here
+fastcgi.server = ("/trac" =>
+                   ("trac" =>
+                     ("socket" => "/tmp/trac-fastcgi.sock",
+                      "bin-path" => fcgi_binary,
+                      "check-local" => "disable",
+                      "bin-environment" =>
+                        ("TRAC_ENV" => "/path/to/projenv")
+                     )
+                   )
+                 )
+}
+```
+
+The technique can be easily adapted for use with multiple projects by creating aliases for each of them, and wrapping the fastcgi.server declarations inside conditional configuration blocks.
+
+Also there is another way to handle multiple projects and it uses `TRAC_ENV_PARENT_DIR` instead of `TRAC_ENV` as well as global authentication:
+```
+#  This is for handling multiple projects
+  alias.url       = ( "/trac/" => "/path/to/trac/htdocs/" )
+
+  fastcgi.server += ("/projects"  =>
+                      ("trac" =>
+                        (
+                          "socket" => "/tmp/trac.sock",
+                          "bin-path" => fcgi_binary,
+                          "check-local" => "disable",
+                          "bin-environment" =>
+                            ("TRAC_ENV_PARENT_DIR" => "/path/to/parent/dir/of/projects/" )
+                        )
+                      )
+                    )
+#And here starts the global auth configuration
+  auth.backend = "htpasswd"
+  auth.backend.htpasswd.userfile = "/path/to/unique/htpassword/file/trac.htpasswd"
+  $HTTP["url"] =~ "^/projects/.*/login$" {
+    auth.require = ("/" =>
+                     (
+                       "method"  => "basic",
+                       "realm"   => "trac",
+                       "require" => "valid-user"
+                     )
+                   )
+  }
+```
+
+Changing date/time format also supported by lighttpd over environment variable LC_TIME:
+```
+fastcgi.server = ("/trac" =>
+                   ("trac" =>
+                     ("socket" => "/tmp/trac-fastcgi.sock",
+                      "bin-path" => fcgi_binary,
+                      "check-local" => "disable",
+                      "bin-environment" =>
+                        ("TRAC_ENV" => "/path/to/projenv",
+                        "LC_TIME" => "ru_RU")
+                     )
+                   )
+                 )
+```
+
+For details about languages specification see [trac:TracFaq TracFaq] question 2.13.
+
+Other important information like the [wiki:TracInstall#MappingStaticResources mapping static resources advices] are useful for non-fastcgi specific installation aspects.
+
+Relaunch Lighttpd and browse to `http://yourhost.example.org/trac` to access Trac.
+
+Note about running Lighttpd with reduced permissions: If nothing else helps and trac.fcgi doesn't start with Lighttpd settings `server.username = "www-data"`, `server.groupname = "www-data"`, then in the `bin-environment` section set `PYTHON_EGG_CACHE` to the home directory of `www-data` or some other directory accessible to this account for writing.
+
+## LiteSpeed Configuration
+
+The FastCGI front-end was developed primarily for use with alternative webservers, such as [LiteSpeed](http://www.litespeedtech.com/).
+
+LiteSpeed web server is an event-driven asynchronous Apache replacement designed from the ground-up to be secure, scalable, and operate with minimal resources. LiteSpeed can operate directly from an Apache config file and is targeted for business-critical environments.
+
+ 1. Please make sure you have a working install of a Trac project. Test install with "tracd" first.
+ 1. Create a Virtual Host for this setup. From now on we will refer to this vhost as TracVhost. For this tutorial we will be assuming that your Trac project will be accessible via:
+```
+http://yourdomain.com/trac/
+```
+ 1. Go "TracVhost → External Apps" tab and create a new "External Application":
+```
+Name: MyTracFCGI
+Address: uds://tmp/lshttpd/mytracfcgi.sock
+Max Connections: 10
+Environment: TRAC_ENV=/fullpathto/mytracproject/ <--- path to root folder of trac project
+Initial Request Timeout (secs): 30
+Retry Timeout (secs): 0
+Persistent Connection	Yes
+Connection Keepalive Timeout: 30
+Response Bufferring: No
+Auto Start: Yes
+Command: /usr/share/trac/cgi-bin/trac.fcgi  <--- path to trac.fcgi
+Back Log: 50
+Instances: 10
+```
+ 1. Optional: If you need to use htpasswd based authentication. Go to "TracVhost → Security" tab and create a new security Realm:
+ ```
+DB Type: Password File
+Realm Name: MyTracUserDB               <--- any name you wish and referenced later
+User DB Location: /fullpathto/htpasswd <--- path to your htpasswd file
+```
+ If you don’t have a htpasswd file or don’t know how to create the entries within one, go to http://sherylcanter.com/encrypt.php, to generate the user:password combos.
+ 1. Go to "PythonVhost → Contexts" and create a new FCGI Context:
+ ```
+URI: /trac/                              <--- URI path to bind to python fcgi app we created
+Fast CGI App: [VHost Level] MyTractFCGI  <--- select the Trac fcgi extapp we just created
+Realm: TracUserDB                        <--- only if (4) is set. select realm created in (4)
+```
+ 1. Modify `/fullpathto/mytracproject/conf/trac.ini`:
+ ```
+#find/set base_rul, url, and link variables
+base_url = http://yourdomain.com/trac/ <--- base url to generate correct links to
+url = http://yourdomain.com/trac/      <--- link of project
+link = http://yourdomain.com/trac/     <--- link of graphic logo
+```
+ 1. Restart LiteSpeed: `lswsctrl restart`, and access your new Trac project at ```http://yourdomain.com/trac/```.
+
+## Nginx Configuration
+
+[Nginx](http://nginx.org/en/) is able to communicate with FastCGI processes, but can not spawn them. So you need to start FastCGI server for Trac separately.
+
+ 1. Nginx configuration with basic authentication handled by Nginx - confirmed to work on 0.6.32
+ ```#!nginx
+    server {
+        listen       10.9.8.7:443;
+        server_name  trac.example;
+
+        ssl                  on;
+        ssl_certificate      /etc/ssl/trac.example.crt;
+        ssl_certificate_key  /etc/ssl/trac.example.key;
+
+        ssl_session_timeout  5m;
+
+        ssl_protocols  SSLv2 SSLv3 TLSv1;
+        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
+        ssl_prefer_server_ciphers   on;
+
+        # it makes sense to serve static resources through Nginx (or ``~ [/some/prefix]/chrome/(.*)``)
+        location ~ /chrome/(.*) {
+             alias /home/trac/instance/static/htdocs/$1;
+        }
+
+        # You can copy this whole location to ``location [/some/prefix](/login)``
+        # and remove the auth entries below if you want Trac to enforce
+        # authorization where appropriate instead of needing to authenticate
+        # for accessing the whole site.
+        # (Or ``~ location /some/prefix(/.*)``.)
+        location ~ (/.*) {
+            auth_basic            "trac realm";
+            auth_basic_user_file /home/trac/htpasswd;
+
+            # socket address
+            fastcgi_pass   unix:/home/trac/run/instance.sock;
+
+            # python - wsgi specific
+            fastcgi_param HTTPS on;
+
+            ## WSGI REQUIRED VARIABLES
+            # WSGI application name - trac instance prefix.
+	    # (Or ``fastcgi_param  SCRIPT_NAME  /some/prefix``.)
+            fastcgi_param  SCRIPT_NAME        "";
+            fastcgi_param  PATH_INFO          $1;
+
+            ## WSGI NEEDED VARIABLES - trac warns about them
+            fastcgi_param  REQUEST_METHOD     $request_method;
+            fastcgi_param  SERVER_NAME        $server_name;
+            fastcgi_param  SERVER_PORT        $server_port;
+            fastcgi_param  SERVER_PROTOCOL    $server_protocol;
+            fastcgi_param  QUERY_STRING       $query_string;
+
+            # For Nginx authentication to work - do not forget to comment these
+            # lines if not using Nginx for authentication
+            fastcgi_param  AUTH_USER          $remote_user;
+            fastcgi_param  REMOTE_USER        $remote_user;
+
+            # for ip to work
+            fastcgi_param REMOTE_ADDR         $remote_addr;
+
+            # For attchments to work
+            fastcgi_param    CONTENT_TYPE     $content_type;
+            fastcgi_param    CONTENT_LENGTH   $content_length;
+        }
+    }
+```
+ 1. Modified trac.fcgi:
+ ```#!python
+#!/usr/bin/env python
+import os
+sockaddr = '/home/trac/run/instance.sock'
+os.environ['TRAC_ENV'] = '/home/trac/instance'
+
+try:
+     from trac.web.main import dispatch_request
+     import trac.web._fcgi
+
+     fcgiserv = trac.web._fcgi.WSGIServer(dispatch_request,
+          bindAddress = sockaddr, umask = 7)
+     fcgiserv.run()
+
+except SystemExit:
+    raise
+except Exception, e:
+    print 'Content-Type: text/plain\r\n\r\n',
+    print 'Oops...'
+    print
+    print 'Trac detected an internal error:'
+    print
+    print e
+    print
+    import traceback
+    import StringIO
+    tb = StringIO.StringIO()
+    traceback.print_exc(file=tb)
+    print tb.getvalue()
+
+```
+ 1. Reload nginx and launch trac.fcgi:
+ ```#!sh
+trac@trac.example ~ $ ./trac-standalone-fcgi.py
+```
+
+The above assumes that:
+
+    * There is a user named 'trac' for running Trac instances and keeping Trac environments in its home directory
+    * `/home/trac/instance` contains a Trac environment
+    * `/home/trac/htpasswd` contains authentication information
+    * `/home/trac/run` is owned by the same group the Nginx runs under
+        * and if your system is Linux the `/home/trac/run` has setgid bit set (`chmod g+s run`)
+        * and patch from [trac:#7239] is applied, or you'll have to fix the socket file permissions every time
+
+
+Unfortunately Nginx does not support variable expansion in fastcgi_pass directive.
+Thus it is not possible to serve multiple Trac instances from one server block.
+
+If you worry enough about security, run Trac instances under separate users.
+
+Another way to run Trac as a FCGI external application is offered in [trac:#6224].
+
+----
+See also: TracGuide, TracInstall, [wiki:TracModWSGI ModWSGI], [wiki:TracCgi CGI], [wiki:TracModPython ModPython], [trac:TracNginxRecipe TracNginxRecipe]
diff --git a/raw-wiki-dump/TracFineGrainedPermissions.md b/raw-wiki-dump/TracFineGrainedPermissions.md
new file mode 100644
index 0000000..78fa9be
--- /dev/null
+++ b/raw-wiki-dump/TracFineGrainedPermissions.md
@@ -0,0 +1,335 @@
+# Fine grained permissions
+[[PageOutline(2-5, Contents, floated)]]
+[[TracGuideToc]]
+
+There is a general mechanism in place that allows custom **permission policy plugins** to grant or deny any action on any kind of Trac resource, even at the level of specific versions of such resources.
+
+That mechanism is `authz_policy`, which is an optional module in `tracopt.perm.authz_policy.*`, so it is installed by default. It can be activated via the //Plugins// panel in the Trac administration module.
+
+## Permission Policies
+
+A great diversity of permission policies can be implemented and Trac comes with a few examples.
+
+Which policies are currently active is determined by a configuration setting in TracIni:
+
+```#!ini
+[trac]
+permission_policies = ReadonlyWikiPolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy
+```
+This lists the [#ReadonlyWikiPolicy] which controls readonly access to wiki pages, followed by the DefaultPermissionPolicy which checks for the traditional coarse grained style permissions described in TracPermissions, and the LegacyAttachmentPolicy which knows how to use the coarse grained permissions for checking the permissions available on attachments.
+
+Among the optional choices, there is [#AuthzPolicy], a very generic permission policy, based on an Authz-style system. See
+[trac:source:branches/1.0-stable/tracopt/perm/authz_policy.py authz_policy.py] for details.
+
+Another popular permission policy [#AuthzSourcePolicy], re-implements the pre-0.12 support for checking fine-grained permissions limited to Subversion repositories in terms of the new system.
+
+See also [trac:source:branches/1.0-stable/sample-plugins/permissions sample-plugins/permissions] for more examples.
+
+### AuthzPolicy
+#### Configuration
+
+* Put a [authzpolicy.conf](http://swapoff.org/files/authzpolicy.conf) file somewhere, preferably on a secured location on the server, not readable for others than the webuser. If the  file contains non-ASCII characters, the UTF-8 encoding should be used.
+* Update your `trac.ini`:
+
+  1. modify the [TracIni#trac-section permission_policies] entry in the `[trac]` section:
+```#!ini
+[trac]
+...
+permission_policies = AuthzPolicy, ReadonlyWikiPolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy
+```
+  1. add a new `[authz_policy]` section:
+```#!ini
+[authz_policy]
+authz_file = /some/trac/env/conf/authzpolicy.conf
+```
+  1. enable the plugin through [/admin/general/plugin WebAdmin] or by editing the `[components]` section:
+```#!ini
+[components]
+tracopt.perm.authz_policy.* = enabled
+```
+
+#### Usage Notes
+
+Note the order in which permission policies are specified: policies are implemented in the sequence provided and therefore may override earlier policy specifications.
+
+A policy will return either `True`, `False` or `None` for a given permission check. `True` is returned if the policy explicitly grants the permission. `False` is returned if the policy explicitly denies the permission. `None` is returned if the policy is unable to either grant or deny the permission.
+
+NOTE: Only if the return value is `None` will the *next* permission policy be consulted. If none of the policies explicitly grants the permission, the final result will be `False`, i.e. permission denied.
+
+The `authzpolicy.conf` file is a `.ini` style configuration file:
+```#!ini
+[wiki:PrivatePage@*]
+john = WIKI_VIEW, !WIKI_MODIFY
+jack = WIKI_VIEW
+* =
+```
+
+* Each section of the config is a glob pattern used to match against a Trac resource descriptor. These descriptors are in the form:
+```
+<realm>:<id>@<version>[/<realm>:<id>@<version> ...]
+
+```
+
+Resources are ordered left to right, from parent to child. If any component is inapplicable, `*` is substituted. If the version pattern is not specified explicitly, all versions (`@*`) is added implicitly. Example: Match the WikiStart page:
+```#!ini
+[wiki:*]
+[wiki:WikiStart*]
+[wiki:WikiStart@*]
+[wiki:WikiStart]
+```
+
+Example: Match the attachment `wiki:WikiStart@117/attachment:FOO.JPG@*` on WikiStart:
+```#!ini
+[wiki:*]
+[wiki:WikiStart*]
+[wiki:WikiStart@*]
+[wiki:WikiStart@*/attachment:*]
+[wiki:WikiStart@117/attachment:FOO.JPG]
+```
+
+
+* Sections are checked against the current Trac resource descriptor **IN ORDER** of appearance in the configuration file. **ORDER IS CRITICAL**.
+
+
+
+* Once a section matches, the current username is matched against the keys (usernames) of the section, **IN ORDER**.
+    * If a key (username) is prefixed with a `@`, it is treated as a group.
+    * If a value (permission) is prefixed with a `!`, the permission is denied rather than granted.
+
+
+The username will match any of 'anonymous', 'authenticated', <username> or '*', using normal Trac permission rules. || **Note:** Other groups which are created by user (e.g. by 'adding subjects to groups' on web interface page //Admin / Permissions//) cannot be used. See [trac:ticket:5648 #5648] for details about this missing feature. ||
+
+For example, if the `authz_file` contains:
+```#!ini
+[wiki:WikiStart@*]
+* = WIKI_VIEW
+
+[wiki:PrivatePage@*]
+john = WIKI_VIEW
+* = !WIKI_VIEW
+```
+and the default permissions are set like this:
+```
+john           WIKI_VIEW
+jack           WIKI_VIEW
+# anonymous has no WIKI_VIEW
+```
+
+Then:
+
+    * All versions of WikiStart will be viewable by everybody, including anonymous
+    * PrivatePage will be viewable only by john
+    * other pages will be viewable only by john and jack
+
+
+Groups:
+```#!ini
+[groups]
+admins = john, jack
+devs = alice, bob
+
+[wiki:Dev@*]
+@admins = TRAC_ADMIN
+@devs = WIKI_VIEW
+* =
+
+[*]
+@admins = TRAC_ADMIN
+* =
+```
+
+Then:
+
+- everything is blocked (whitelist approach), but
+- admins get all TRAC_ADMIN everywhere and
+- devs can view wiki pages.
+
+
+Some repository examples (Browse Source specific):
+```#!ini
+# A single repository:
+[repository:test_repo@*]
+john = BROWSER_VIEW, FILE_VIEW
+# John has BROWSER_VIEW and FILE_VIEW for the entire test_repo
+
+# The default repository (requires Trac 1.0.2 or later):
+[repository:@*]
+john = BROWSER_VIEW, FILE_VIEW
+# John has BROWSER_VIEW and FILE_VIEW for the entire default repository
+
+# All repositories:
+[repository:*@*]
+jack = BROWSER_VIEW, FILE_VIEW
+# Jack has BROWSER_VIEW and FILE_VIEW for all repositories
+```
+
+Very granular repository access:
+```#!ini
+# John has BROWSER_VIEW and FILE_VIEW access to trunk/src/some/location/ only
+[repository:test_repo@*/source:trunk/src/some/location/*@*]
+john = BROWSER_VIEW, FILE_VIEW
+
+# John has BROWSER_VIEW and FILE_VIEW access to only revision 1 of all files at trunk/src/some/location only
+[repository:test_repo@*/source:trunk/src/some/location/*@1]
+john = BROWSER_VIEW, FILE_VIEW
+
+# John has BROWSER_VIEW and FILE_VIEW access to all revisions of 'somefile' at trunk/src/some/location only
+[repository:test_repo@*/source:trunk/src/some/location/somefile@*]
+john = BROWSER_VIEW, FILE_VIEW
+
+# John has BROWSER_VIEW and FILE_VIEW access to only revision 1 of 'somefile' at trunk/src/some/location only
+[repository:test_repo@*/source:trunk/src/some/location/somefile@1]
+john = BROWSER_VIEW, FILE_VIEW
+```
+
+Note: In order for Timeline to work/visible for John, we must add CHANGESET_VIEW to the above permission list.
+
+#### Missing Features
+Although possible with the DefaultPermissionPolicy handling (see Admin panel), fine-grained permissions still miss those grouping features (see [trac:ticket:9573 #9573], [trac:ticket:5648 #5648]). Patches are partially available, see authz_policy.2.patch, part of [trac:ticket:6680 #6680].
+
+You cannot do the following:
+```#!ini
+[groups]
+team1 = a, b, c
+team2 = d, e, f
+team3 = g, h, i
+departmentA = team1, team2
+```
+
+Permission groups are not supported either, so you cannot do the following:
+```#!ini
+[groups]
+permission_level_1 = WIKI_VIEW, TICKET_VIEW
+permission_level_2  = permission_level_1, WIKI_MODIFY, TICKET_MODIFY
+[*]
+@team1 = permission_level_1
+@team2 = permission_level_2
+@team3 = permission_level_2, TICKET_CREATE
+```
+
+### AuthzSourcePolicy  (mod_authz_svn-like permission policy) === #AuthzSourcePolicy
+
+At the time of this writing, the old granular permissions system from Trac 0.11 and before used for restricting access to the repository has been converted to a permission policy component. But from the user's point of view, this makes little if any difference.
+
+That kind of granular permission control needs a definition file, which is the one used by Subversion's mod_authz_svn.
+More information about this file format and about its usage in Subversion is available in the [Path-Based Authorization](http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html) section in the Server Configuration chapter of the svn book.
+
+Example:
+```#!ini
+[/]
+* = r
+
+[/branches/calc/bug-142]
+harry = rw
+sally = r
+
+[/branches/calc/bug-142/secret]
+harry =
+```
+
+
+    * **/** = *Everyone has read access by default*
+    * **/branches/calc/bug-142** = *harry has read/write access, sally read only*
+    * **/branches/calc/bug-142/secret** = *harry has no access, sally has read access (inherited as a sub folder permission)*
+
+
+#### Trac Configuration
+
+To activate granular permissions you __must__ specify the ```authz_file``` option in the `[svn]` section of trac.ini. If this option is set to null or not specified, the permissions will not be used.
+
+```#!ini
+[svn]
+authz_file = /path/to/svnaccessfile
+```
+
+If you want to support the use of the `[`*modulename*`:/`*some*`/`*path*`]` syntax within the `authz_file`, add:
+
+```#!ini
+authz_module_name = modulename
+```
+
+where *modulename* refers to the same repository indicated by the `<name>.dir` entry in the `[repositories]` section. As an example, if the `somemodule.dir` entry in the `[repositories]` section is `/srv/active/svn/somemodule`, that would yield the following:
+
+``` #!ini
+[svn]
+authz_file = /path/to/svnaccessfile
+authz_module_name = somemodule
+...
+[repositories]
+somemodule.dir = /srv/active/svn/somemodule
+```
+
+where the svn access file, ```/path/to/svnaccessfile```, contains entries such as ```[somemodule:/some/path]```.
+
+**Note:** Usernames inside the Authz file __must__ be the same as those used inside trac.
+
+As of version 0.12, make sure you have *AuthzSourcePolicy* included in the permission_policies list in trac.ini, otherwise the authz permissions file will be ignored.
+
+```#!ini
+[trac]
+permission_policies = AuthzSourcePolicy, ReadonlyWikiPolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy
+```
+
+#### Subversion Configuration
+
+The same access file is typically applied to the corresponding Subversion repository using an Apache directive like this:
+```#!apache
+<Location /repos>
+  DAV svn
+  SVNParentPath /usr/local/svn
+
+  # our access control policy
+  AuthzSVNAccessFile /path/to/svnaccessfile
+</Location>
+```
+
+For information about how to restrict access to entire projects in a multiple project environment see [trac:wiki:TracMultipleProjectsSVNAccess].
+
+### ReadonlyWikiPolicy
+
+Since 1.1.2, the read-only attribute of wiki pages is enabled and enforced when `ReadonlyWikiPolicy` is in the list of active permission policies. The default for new Trac installations in 1.1.2 and later is:
+```
+[trac]
+permission_policies = ReadonlyWikiPolicy,
+ DefaultPermissionPolicy,
+ LegacyAttachmentPolicy
+```
+
+When upgrading from earlier versions of Trac, `ReadonlyWikiPolicy` will be appended to the list of `permission_policies` when upgrading the environment, provided that `permission_policies` has the default value. If any non-default `permission_polices` are active, `ReadonlyWikiPolicy` **will need to be manually added** to the list. A message will be echoed to the console when upgrading the environment, indicating if any action needs to be taken.
+
+**ReadonlyWikiPolicy must be listed //before// DefaultPermissionPolicy**. The latter returns `True` to allow modify, delete or rename actions when the user has the respective `WIKI_*` permission, without consideration for the read-only attribute.
+
+The `ReadonlyWikiPolicy` returns `False` to deny modify, delete and rename actions on wiki pages when the page has the read-only attribute set and the user does not have `WIKI_ADMIN`, regardless of `WIKI_MODIFY`, `WIKI_DELETE` and `WIKI_RENAME` permissions. It returns `None` for all other cases.
+
+When active, the [#AuthzPolicy] should therefore come before `ReadonlyWikiPolicy`, allowing it to grant or deny the actions on individual resources, which is the usual ordering for `AuthzPolicy` in the `permission_policies` list.
+```
+[trac]
+permission_policies = AuthzPolicy,
+ ReadonlyWikiPolicy,
+ DefaultPermissionPolicy,
+ LegacyAttachmentPolicy
+```
+
+The placement of [#AuthzSourcePolicy] relative to `ReadonlyWikiPolicy` does not matter since they don't perform checks on the same realms.
+
+For all other permission policies, the user will need to decide the proper ordering. Generally, if the permission policy should be capable of overriding the check performed by `ReadonlyWikiPolicy`, it should come before `ReadonlyWikiPolicy` in the list. If the `ReadonlyWikiPolicy` should override the check performed by another permission policy, as is the case for `DefaultPermissionPolicy`, then `ReadonlyWikiPolicy` should come first.
+
+## Debugging permissions
+In trac.ini set:
+```#!ini
+[logging]
+log_file = trac.log
+log_level = DEBUG
+log_type = file
+```
+
+Display the trac.log to understand what checks are being performed:
+```#!sh
+tail -n 0 -f log/trac.log | egrep '\[perm\]|\[authz_policy\]'
+```
+
+See the sourced documentation of the plugin for more info.
+
+----
+See also: TracPermissions,
+[TracHacks:FineGrainedPageAuthzEditorPlugin](http://trac-hacks.org/wiki/FineGrainedPageAuthzEditorPlugin) for a simple editor plugin.
diff --git a/raw-wiki-dump/TracGuide.md b/raw-wiki-dump/TracGuide.md
new file mode 100644
index 0000000..3b708c1
--- /dev/null
+++ b/raw-wiki-dump/TracGuide.md
@@ -0,0 +1,72 @@
+# The Trac User and Administration Guide
+
+[[TracGuideToc]]
+```#!span style="font-size:90%"
+//The TracGuide is meant to serve as a starting point for all documentation regarding Trac usage and development. The guide is a free document, a collaborative effort, and a part of the [http://trac.edgewall.org Trac Project] itself.//
+```
+
+## Introduction
+
+Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. It helps developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies.
+
+It provides an interface to Subversion as well as other version control systems, an integrated Wiki and convenient reporting facilities.
+
+Trac allows wiki markup in issue descriptions and commit messages, creating links and seamless references between bugs, tasks, changesets, files and wiki pages. A timeline shows all current and past project events in order, making the acquisition of an overview of the project and tracking progress very easy. The roadmap shows the road ahead, listing the upcoming milestones.
+
+## User Guide
+
+
+    * Using the Wiki subsystem:
+        * TracWiki — How to use the built-in Wiki.
+        * WikiFormatting — Reference to the wiki syntax used throughout.
+    * Using the Version Control subsystem:
+        * TracBrowser — Browsing source code with Trac.
+        * TracChangeset — Viewing changes to source code.
+        * TracRevisionLog — Viewing change history.
+    * Using the Ticket subsystem:
+        * TracTickets — Using the issue tracker.
+        * TracRoadmap — The roadmap helps tracking project progress.
+        * TracReports — Writing and using reports.
+        * TracQuery — Executing custom ticket queries.
+        * TracBatchModify - Modifying a batch of tickets in one request.
+    * Other modules and general topics:
+        * TracSearch — Full text search in all content.
+        * TracTimeline — The timeline provides a historic perspective on a project.
+        * TracRss — RSS content syndication in Trac.
+        * TracAccessibility — Accessibility keys support.
+
+
+## Administrator Guide
+
+
+    * Installation and upgrade:
+        * TracInstall — How to install and run Trac.
+        * TracUpgrade — How to upgrade existing installations.
+        * TracImport — Importing tickets from other bug databases.
+        * TracPlugins — Installing and managing Trac extensions.
+    * Configuration and customization:
+        * TracIni — Trac configuration file reference.
+        * TracPermissions — Access control and permissions.
+        * TracNavigation — Customize main navigation menus.
+        * TracInterfaceCustomization — Customizing the Trac interface.
+        * TracLogging — The Trac logging facility.
+    * Administering the Version Control subsystem:
+        * TracRepositoryAdmin — Management of Source Code Repositories.
+    * Administering the Ticket subsystem:
+        * TracTicketsCustomFields — Expanding tickets with customized fields.
+        * TracNotification — Email notification.
+        * TracWorkflow — Configurable Ticket Workflow.
+    * Reference:
+        * TracEnvironment — All you need to know about Trac environments.
+        * TracAdmin — Administering a Trac project via the command-line.
+
+
+## Support and Other Sources of Information
+
+
+    * [trac:TracFaq Trac FAQ] — A collection of Frequently Asked Questions on the project website.
+    * [trac:TracDev] and [trac:TracDev/ApiDocs API docs] — Trac Developer documentation.
+    * TracSupport — How to get more information.
+
+
+If you are looking for a good place to ask a question about Trac, see the [trac:MailingList MailingList]. It provides a friendly environment to discuss openly among Trac users and developers.
diff --git a/raw-wiki-dump/TracImport.md b/raw-wiki-dump/TracImport.md
new file mode 100644
index 0000000..c70e8a0
--- /dev/null
+++ b/raw-wiki-dump/TracImport.md
@@ -0,0 +1,108 @@
+# Importing ticket data
+
+[[PageOutline(2-5,Contents,pullout)]]
+
+To migrate issue tickets from other issue-tracking systems into Trac or perform housekeeping actions on tickets or simply synchronize different databases, there are some tools, plugins and scripts available.
+
+## TicketImportPlugin
+
+[TicketImportPlugin]: a plugin that lets you import or update into Trac a series of tickets from a **CSV file** or (if the [https://pypi.python.org/pypi/xlrd xlrd library](https://trac-hacks.org/wiki/TicketImportPlugin) is installed) from an **Excel spreadsheet**.
+
+## ExportImportXlsPlugin
+
+[ExportImportXlsPlugin](https://trac-hacks.org/wiki/ExportImportXlsPlugin): a plugin that adds an admin panel for exporting and importing tickets via **XLS file**. Requires the python packages xlwt/rxld.
+
+## Bugzilla
+
+[BugzillaIssueTrackingPlugin]: a plugin that integrates Bugzilla issue data into Trac keeping TracLinks. Ticket data can be imported from Bugzilla using the [trac:browser:trunk/contrib/bugzilla2trac.py bugzilla2trac.py](https://trac-hacks.org/wiki/BugzillaIssueTrackingPlugin) script, available in the contrib/ directory of the Trac distribution.
+
+```
+$ bugzilla2trac.py
+bugzilla2trac - Imports a bug database from Bugzilla into Trac.
+
+Usage: bugzilla2trac.py [options]
+
+Available Options:
+  --db <MySQL dbname>              - Bugzilla's database
+  --tracenv /path/to/trac/env      - full path to Trac db environment
+  -h | --host <MySQL hostname>     - Bugzilla's DNS host name
+  -u | --user <MySQL username>     - effective Bugzilla's database user
+  -p | --passwd <MySQL password>   - Bugzilla's user password
+  -c | --clean                     - remove current Trac tickets before importing
+  --help | help                    - this help info
+
+Additional configuration options can be defined directly in the script.
+```
+
+Currently, the following data is imported from Bugzilla:
+
+    * bugs
+    * bug activity (field changes)
+    * bug attachments
+    * user names and passwords (put into a htpasswd file)
+
+
+The script provides a number of features to ease the conversion, such as:
+
+    * PRODUCT_KEYWORDS: Trac has no concept of products, so the script provides the ability to attach a ticket keyword instead.
+    * IGNORE_COMMENTS: Don't import Bugzilla comments that match a certain regexp.
+    * STATUS_KEYWORDS: Attach ticket keywords for the Bugzilla statuses not available in Trac. By default, the `VERIFIED` and `RELEASED` Bugzilla statuses are translated into Trac keywords.
+
+
+For more details on the available options, see the configuration section at the top of the script.
+
+### Known Issues
+```#!comment
+Don't merge this section in the default page
+```
+[[TicketQuery(keywords=~bugzilla,status=closed)]]
+
+The adequate milestone for valid bugzilla2trac issue is usually *Not applicable*, which means that fixes to the contributed script are not planned for a particular Trac release, but can happen anytime.
+
+## Jira
+
+[JiraToTracIntegration](https://trac-hacks.org/wiki/JiraToTracIntegration): a plugin that provides tools to import Atlassian Jira backup files into Trac. The plugin consists of a Python 3.1 commandline tool that:
+
+    - Parses the Jira backup XML file.
+    - Sends the imported Jira data and attachments to Trac using the [th:XmlRpcPlugin].
+    - Generates a htpasswd file containing the imported Jira users and their SHA-512 base64 encoded passwords.
+
+
+## Mantis
+
+[MantisImportScript](https://trac-hacks.org/wiki/MantisImportScript): a script to import the following type of data from Mantis into Trac:
+
+    * bugs
+    * bug comments
+    * bug activity (field changes)
+    * attachments (as long as the files live in the mantis database, not on the filesystem).
+
+
+## PlanetForge
+
+[PlanetForgeImportExportPlugin]: this plugin exports Trac data (wiki, tickets, compoments, permissions, repositories, etc.) using the open format designed by the [https://gforge.inria.fr/projects/coclico/ COCLICO](https://trac-hacks.org/wiki/PlanetForgeImportExportPlugin) project. It extends the webadmin panel and the 'trac admin ...' command. Has no 'import' feature.
+
+## Scarab
+
+[ScarabToTracScript]: a script that migrates Scarab issues to Trac tickets. Requires [th:XmlRpcPlugin](https://trac-hacks.org/wiki/ScarabToTracScript).
+
+## Sourceforge
+
+[SfnToTracScript](https://trac-hacks.org/wiki/SfnToTracScript): importer of SourceForge's new backup file (originated from #Trac3521).
+Also, ticket data can be imported from Sourceforge using the [trac:browser:trunk/contrib/sourceforge2trac.py sourceforge2trac.py] script, available in the contrib/ directory of the Trac distribution.
+
+## Other
+
+Since Trac uses a SQL database to store the data, you can also custom-import from other systems by examining the database tables. Just go into [sqlite](http://www.sqlite.org/sqlite.html) command line to look at the tables and import them from your application.
+
+### Comma delimited file - CSV
+
+See [trac:attachment:csv2trac.2.py:wiki:TracSynchronize csv2trac.2.py] for details. This approach is particularly useful if you need to enter a large number of tickets by hand. Note that the ticket type type field, (task etc.) is also needed for this script to work with more recent Trac releases.
+
+Comments on script: The script has an error on line 168: 'Ticket' needs to be 'ticket'. Also, the listed values for severity and priority are swapped.
+
+----
+See also:
+
+    * to import/export wiki pages: TracAdmin,
+    * to export tickets: TracTickets, TracQuery
diff --git a/raw-wiki-dump/TracIni.md b/raw-wiki-dump/TracIni.md
new file mode 100644
index 0000000..3e9f628
--- /dev/null
+++ b/raw-wiki-dump/TracIni.md
@@ -0,0 +1,36 @@
+# The Trac Configuration File
+
+[[TracGuideToc]]
+[[PageOutline(2-5,Contents,pullout)]]
+
+Trac is configured through the **`trac.ini`** file, located in the `<projectenv>/conf` directory. The `trac.ini` configuration file and its parent directory should be writable by the web server.
+
+Trac monitors the timestamp of the file to trigger a complete environment reload and flush its caches when the timestamp changes. Most changes to the configuration will be reflected immediately, though changes to the `[components]` or `[logging]` sections will require restarting the web server. You may also need to restart the web server after creating a [#GlobalConfiguration global configuration] file when none was previously present.
+
+## Global Configuration
+
+Configuration can be shared among environments using one or more global configuration files. Options in the global configuration will be merged with the environment-specific options, with local options overriding global options. The global configuration file is specified as follows:
+```#!ini
+[inherit]
+file = /path/to/global/trac.ini
+```
+Multiple files can be specified using a comma-separated list.
+
+Note that you can also specify a global option file when creating a new project, by adding the option `--inherit=/path/to/global/trac.ini` to [TracAdmin#initenv trac-admin]'s `initenv` command. If you do not do this but nevertheless intend to use a global option file with your new environment, you will have to go through the newly generated `conf/trac.ini` file and delete the entries that will otherwise override those set in the global file.
+
+There are two more entries in the [[#inherit-section| [inherit] ]] section, `templates_dir` for sharing global templates and `plugins_dir`, for sharing plugins. Those entries can themselves be specified in the shared configuration file, and in fact, configuration files can even be chained if you specify another `[inherit] file` there.
+
+Note that the templates found in the `templates/` directory of the TracEnvironment have precedence over those found in `[inherit] templates_dir`. In turn, the latter have precedence over the installed templates, so be careful about what you put there. Notably, if you override a default template, refresh your modifications when you upgrade to a new version of Trac. The preferred way to perform TracInterfaceCustomization is still to write a custom plugin doing an appropriate `ITemplateStreamFilter` transformation.
+
+## Reference for settings
+
+This is a brief reference of available configuration options, and their default settings.
+
+Documentation improvements should be discussed on the [trac:MailingList#Trac-dev trac-dev mailing list] or described in a [trac:NewTicket ticket]. Even better, [trac:TracDev/SubmittingPatches submit a patch] against the docstrings in the code.
+``` #!comment
+Please don't waste your time by editing the HTML code below, changes won't be picked up. Instead, follow the above guidance for suggesting documentation improvements.
+```
+[[TracIni]]
+
+----
+See also: TracGuide, TracAdmin, TracEnvironment
diff --git a/raw-wiki-dump/TracInstall.md b/raw-wiki-dump/TracInstall.md
new file mode 100644
index 0000000..aeccadb
--- /dev/null
+++ b/raw-wiki-dump/TracInstall.md
@@ -0,0 +1,453 @@
+# Trac Installation Guide for 1.1
+[[TracGuideToc]]
+
+Trac is written in the Python programming language and needs a database, [SQLite], [http://www.postgresql.org/ PostgreSQL], or [http://mysql.com/ MySQL]. For HTML rendering, Trac uses the [http://genshi.edgewall.org Genshi](http://sqlite.org/) templating system.
+
+Trac can also be localized, and there is probably a translation available in your language. If you want to use the Trac interface in other languages, then make sure you have installed the optional package [#OtherPythonPackages Babel]. Pay attention to the extra steps for localization support in the [#InstallingTrac Installing Trac] section below. Lacking Babel, you will only get the default English version.
+
+If you're interested in contributing new translations for other languages or enhancing the existing translations, then please have a look at [trac:wiki:TracL10N TracL10N].
+
+What follows are generic instructions for installing and setting up Trac. While you may find instructions for installing Trac on specific systems at [trac:TracInstallPlatforms TracInstallPlatforms], please **first read through these general instructions** to get a good understanding of the tasks involved.
+
+[[PageOutline(2-3,Installation Steps,inline)]]
+
+## Dependencies
+### Mandatory Dependencies
+To install Trac, the following software packages must be installed:
+
+
+    * [Python](http://www.python.org/), version >= 2.6 and < 3.0
+
+   (note that we dropped the support for Python 2.5 in this release)
+
+    * [setuptools](http://pypi.python.org/pypi/setuptools), version >= 0.6
+    * [Genshi](http://genshi.edgewall.org/wiki/Download), version >= 0.6
+
+
+You also need a database system and the corresponding python bindings. The database can be either SQLite, PostgreSQL or MySQL.
+
+#### For the SQLite database #ForSQLite
+
+As you must be using Python 2.6 or 2.7, you already have the SQLite database bindings bundled with the standard distribution of Python (the `sqlite3` module).
+
+Optionally, you may install a newer version of [pysqlite] than the one provided by the Python distribution. See [trac:PySqlite#ThePysqlite2bindings PySqlite](http://pypi.python.org/pypi/pysqlite) for details.
+
+#### For the PostgreSQL database #ForPostgreSQL
+
+You need to install the database and its Python bindings:
+
+    * [PostgreSQL](http://www.postgresql.org/), version 8.0 or later
+    * [psycopg2](http://pypi.python.org/pypi/psycopg2), version 2.0 or later
+
+
+See [trac:DatabaseBackend#Postgresql DatabaseBackend] for details.
+
+#### For the MySQL database #ForMySQL
+
+Trac works well with MySQL, provided you follow the guidelines:
+
+
+    * [MySQL](http://mysql.com/), version 5.0 or later
+    * [MySQLdb](http://sf.net/projects/mysql-python), version 1.2.2 or later
+
+
+Given the caveats and known issues surrounding MySQL, read carefully the [trac:MySqlDb] page before creating the database.
+
+### Optional Dependencies
+
+#### Subversion
+
+[Subversion](http://subversion.apache.org/), 1.6.x or later and the ***corresponding*** Python bindings.
+
+There are [pre-compiled SWIG bindings] available for various platforms. (Good luck finding precompiled SWIG bindings for any Windows package at that listing. [trac:TracSubversion] points you to [http://alagazam.net Alagazam](http://subversion.apache.org/packages.html), which works for me under Python 2.6.)
+
+For troubleshooting information, see the [trac:TracSubversion#Troubleshooting TracSubversion] page.
+
+```#!div style="border: 1pt dotted; margin: 1em"
+**Note:**
+* Trac '''doesn't''' use [http://pysvn.tigris.org/ PySVN], nor does it work yet with the newer `ctype`-style bindings.
+* If using Subversion, Trac must be installed on the '''same machine'''. Remote repositories are currently [trac:ticket:493 not supported].
+```
+
+#### Git
+
+[Git] 1.5.6 or later is supported. More information is available on the [trac:TracGit](http://git-scm.com/) page.
+
+#### Other Version Control Systems
+
+Support for other version control systems is provided via third-party plugins. See [trac:PluginList#VersionControlSystems] and [trac:VersionControlSystem].
+
+#### Web Server
+A web server is optional because Trac is shipped with a server included, see the [#RunningtheStandaloneServer Running the Standalone Server] section below.
+
+Alternatively you can configure Trac to run in any of the following environments:
+
+    * [Apache](http://httpd.apache.org/) with
+        - [mod_wsgi], see [wiki:TracModWSGI](https://github.com/GrahamDumpleton/mod_wsgi) and
+
+     [ModWSGI IntegrationWithTrac](http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac).
+
+    - [mod_python 3.5.0](http://modpython.org/), see TracModPython
+* a [FastCGI](http://www.fastcgi.com/)-capable web server (see TracFastCgi)
+* an [AJP](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html)-capable web
+
+   server (see [trac:TracOnWindowsIisAjp TracOnWindowsIisAjp])
+
+    * Microsoft IIS with FastCGI and a FastCGI-to-WSGI gateway (see [trac:CookBook/Installation/TracOnWindowsIisWfastcgi IIS with FastCGI])
+    * a CGI-capable web server (see TracCgi), **but usage of Trac as a cgi script
+
+   is highly discouraged**, better use one of the previous options.
+
+
+#### Other Python Packages
+
+
+    * [Babel](http://babel.edgewall.org), version 0.9.6 or >= 1.3,
+
+   needed for localization support
+
+    * [docutils](http://docutils.sourceforge.net/), version >= 0.3.9
+
+   for WikiRestructuredText.
+
+    * [Pygments](http://pygments.org) for
+
+   [TracSyntaxColoring syntax highlighting].
+
+    * [pytz](http://pytz.sf.net) to get a complete list of time zones,
+
+   otherwise Trac will fall back on a shorter list from
+   an internal time zone implementation.
+
+```#!div style="border: 1pt dotted; margin: 1em"
+**Attention**: The available versions of these dependencies are not necessarily interchangeable, so please pay attention to the version numbers. If you are having trouble getting Trac to work, please double-check all the dependencies before asking for help on the [trac:MailingList] or [trac:IrcChannel].
+```
+
+Please refer to the documentation of these packages to find out how they are best installed. In addition, most of the [trac:TracInstallPlatforms platform-specific instructions] also describe the installation of the dependencies. Keep in mind however that the information there *probably concern older versions of Trac than the one you're installing*.
+
+## Installing Trac
+
+The [TracAdmin trac-admin] command-line tool, used to create and maintain [TracEnvironment project environments], as well as the [TracStandalone tracd] standalone server are installed along with Trac. There are several methods for installing Trac.
+
+It is assumed throughout this guide that you have elevated permissions as the `root` user or by prefixing commands with `sudo`. The umask `0002` should be used for a typical installation on a Unix-based platform.
+
+### Using `easy_install`
+Trac can be installed from PyPI or the Subversion repository using [setuptools](http://pypi.python.org/pypi/setuptools).
+
+A few examples:
+
+
+    - Install the latest stable version of Trac:
+ ```#!sh
+$ easy_install Trac
+
+```
+
+    - Install latest development version:
+ ```#!sh
+$ easy_install http://download.edgewall.org/trac/Trac-latest-dev.tar.gz
+
+```
+   Note that in this case you won't have the possibility to run a localized version of Trac;
+   either use a released version or install from source
+
+More information can be found on the [trac:wiki:setuptools setuptools] page.
+
+```#!div style="border: 1pt dotted; margin: 1em"
+**Setuptools Warning:** If the version of your setuptools is in the range 5.4 through 5.6, the environment variable `PKG_RESOURCES_CACHE_ZIP_MANIFESTS` must be set in order to avoid significant performance degradation. More information may be found in [#DeployingTrac Deploying Trac].
+```
+
+### Using `pip`
+'pip' is an easy_install replacement that is very useful to quickly install python packages.
+To get a Trac installation up and running in less than 5 minutes:
+
+Assuming you want to have your entire pip installation in `/opt/user/trac`
+
+ -
+ ```#!sh
+pip install trac psycopg2
+```
+or
+ -
+ ```#!sh
+pip install trac mysql-python
+```
+
+Make sure your OS specific headers are available for pip to automatically build PostgreSQL (`libpq-dev`) or MySQL (`libmysqlclient-dev`) bindings.
+
+pip will automatically resolve all dependencies (like Genshi, pygments, etc.), download the latest packages from pypi.python.org and create a self contained installation in `/opt/user/trac`.
+
+All commands (`tracd`, `trac-admin`) are available in `/opt/user/trac/bin`. This can also be leveraged for `mod_python` (using `PythonHandler` directive) and `mod_wsgi` (using `WSGIDaemonProcess` directive)
+
+Additionally, you can install several Trac plugins (listed [here](https://pypi.python.org/pypi?:action=browse&show=all&c=516)) through pip.
+
+### From source
+Using the python-typical setup at the top of the source directory also works. You can obtain the source for a .tar.gz or .zip file corresponding to a release (e.g. `Trac-1.0.tar.gz`) from the [trac:TracDownload] page, or you can get the source directly from the repository. See [trac:TracRepositories#OfficialSubversionrepository TracRepositories] for details.
+
+```#!sh
+$ python ./setup.py install
+```
+
+*You will need root permissions or equivalent for this step.*
+
+This will byte-compile the Python source code and install it as an .egg file or folder in the `site-packages` directory
+of your Python installation. The .egg will also contain all other resources needed by standard Trac, such as `htdocs` and `templates`.
+
+If you install from source and want to make Trac available in other languages, make sure Babel is installed. Only then, perform the `install` (or simply redo the `install` once again afterwards if you realize Babel was not yet installed):
+```#!sh
+$ python ./setup.py install
+```
+Alternatively, you can run `bdist_egg` and copy the .egg from `dist/` to the place of your choice, or you can create a Windows installer (`bdist_wininst`).
+
+### Using installer
+
+On Windows, Trac can be installed using the exe installers available on the [trac:TracDownload] page. Installers are available for the 32-bit and 64-bit versions of Python. Make sure to use the installer that matches the architecture of your Python installation.
+
+### Using package manager
+
+Trac may be available in your platform's package repository. Note however, that the version provided by your package manager may not be the latest release.
+
+### Advanced `easy_install` Options
+
+To install Trac to a custom location, or find out about other advanced installation options, run:
+```#!sh
+easy_install --help
+```
+
+Also see [Installing Python Modules](http://docs.python.org/2/install/index.html) for detailed information.
+
+Specifically, you might be interested in:
+```#!sh
+easy_install --prefix=/path/to/installdir
+```
+or, if installing Trac on a Mac OS X system:
+```#!sh
+easy_install --prefix=/usr/local --install-dir=/Library/Python/2.6/site-packages
+```
+
+```#!div style="border: 1pt dotted; margin: 1em"
+**Mac OS X Note:** On Mac OS X 10.6,  running `easy_install trac` will install into `/usr/local` and `/Library/Python/2.6/site-packages` by default.
+
+The `tracd` and `trac-admin` commands will be placed in `/usr/local/bin` and will install the Trac libraries and dependencies into `/Library/Python/2.6/site-packages`, which is Apple's preferred location for third-party Python application installations.
+```
+
+## Creating a Project Environment
+
+A [TracEnvironment Trac environment] is the backend where Trac stores information like wiki pages, tickets, reports, settings, etc. An environment is a directory that contains a human-readable [TracIni configuration file], and other files and directories.
+
+A new environment is created using [TracAdmin trac-admin]:
+```#!sh
+$ trac-admin /path/to/myproject initenv
+```
+
+[TracAdmin trac-admin] will prompt you for the information it needs to create the environment: the name of the project and the [TracEnvironment#DatabaseConnectionStrings database connection string]. If you're not sure what to specify for any of these options, just press `<Enter>` to use the default value.
+
+Using the default database connection string will always work as long as you have SQLite installed. For the other [trac:DatabaseBackend database backends] you should plan ahead and already have a database ready to use at this point.
+
+Also note that the values you specify here can be changed later using TracAdmin or directly editing the [TracIni conf/trac.ini] configuration file.
+
+```#!div style="border: 1pt dotted; margin: 1em"
+**Filesystem Warning:** When selecting the location of your environment, make sure that the filesystem on which the environment directory resides supports sub-second timestamps (i.e. **not** `ext2` or `ext3` on Linux, or HFS+ on OSX), as the modification time of the `conf/trac.ini` file will be monitored to decide whether an environment restart is needed or not. A too coarse-grained timestamp resolution may result in inconsistencies in Trac < 1.0.2. The best advice is to opt for a platform with sub-second timestamp resolution, regardless of the Trac version.
+```
+
+Finally, make sure the user account under which the web front-end runs will have **write permissions** to the environment directory and all the files inside. This will be the case if you run `trac-admin ... initenv` as this user. If not, you should set the correct user afterwards. For example on Linux, with the web server running as user `apache` and group `apache`, enter:
+```#!sh
+$ chown -R apache:apache /path/to/myproject
+```
+
+The actual username and groupname of the apache server may not be exactly `apache`, and are specified in the Apache configuration file by the directives `User` and `Group` (if Apache `httpd` is what you use).
+
+```#!div class=important
+'''Warning:''' Please only use ASCII-characters for account name and project path, unicode characters are not supported there.
+```
+
+## Deploying Trac
+
+```#!div style="border: 1pt dotted; margin: 1em"
+**Setuptools Warning:** If the version of your setuptools is in the range 5.4 through 5.6, the environment variable `PKG_RESOURCES_CACHE_ZIP_MANIFESTS` must be set in order to avoid significant performance degradation.
+
+If running `tracd`, the environment variable can be set system-wide or for just the user that runs the `tracd` process. There are several ways to accomplish this in addition to what is discussed here, and depending on the distribution of your OS.
+
+To be effective system-wide a shell script with the `export` statement may be added to `/etc/profile.d`. To be effective for a user session the `export` statement may be added to `~/.profile`.
+```#!sh
+export PKG_RESOURCES_CACHE_ZIP_MANIFESTS=1
+```
+
+Alternatively, the variable can be set in the shell before executing `tracd`:
+```#!sh
+$ PKG_RESOURCES_CACHE_ZIP_MANIFESTS=1 tracd --port 8000 /path/to/myproject
+```
+
+If running the Apache web server, Ubuntu/Debian users should add the `export` statement to `/etc/apache2/envvars`. RedHat/CentOS/Fedora should can add the `export` statement to `/etc/sysconfig/httpd`.
+```
+
+### Running the Standalone Server
+
+After having created a Trac environment, you can easily try the web interface by running the standalone server [TracStandalone tracd]:
+```#!sh
+$ tracd --port 8000 /path/to/myproject
+```
+
+Then, fire up a browser and visit `http://localhost:8000/`. You should get a simple listing of all environments that `tracd` knows about. Follow the link to the environment you just created, and you should see Trac in action. If you only plan on managing a single project with Trac you can have the standalone server skip the environment list by starting it like this:
+```#!sh
+$ tracd -s --port 8000 /path/to/myproject
+```
+
+### Running Trac on a Web Server
+
+Trac provides various options for connecting to a "real" web server:
+
+    - [TracFastCgi FastCGI]
+    - [wiki:TracModWSGI Apache with mod_wsgi]
+    - [TracModPython Apache with mod_python]
+    - //[TracCgi CGI] (should not be used, as the performance is far from optimal)//
+
+
+Trac also supports [AJP] which may be your choice if you want to connect to IIS. Other deployment scenarios are possible: [trac:TracNginxRecipe nginx], [http://projects.unbit.it/uwsgi/wiki/Example#Traconapacheinasub-uri uwsgi], [trac:TracOnWindowsIisIsapi Isapi-wsgi](trac:TracOnWindowsIisAjp) etc.
+
+#### Generating the Trac cgi-bin directory #cgi-bin
+
+In order for Trac to function properly with FastCGI you need to have a `trac.fcgi` file and for mod_wsgi a `trac.wsgi` file. These are Python scripts which load the appropriate Python code. They can be generated using the `deploy` option of [TracAdmin trac-admin].
+
+There is, however, a bit of a chicken-and-egg problem. The [TracAdmin trac-admin] command requires an existing environment to function, but complains if the deploy directory already exists. This is a problem, because environments are often stored in a subdirectory of the deploy. The solution is to do something like this:
+```#!sh
+mkdir -p /usr/share/trac/projects/my-project
+trac-admin /usr/share/trac/projects/my-project initenv
+trac-admin /usr/share/trac/projects/my-project deploy /tmp/deploy
+mv /tmp/deploy/* /usr/share/trac
+```
+Don't forget to check that the web server has the execution right on scripts in the `/usr/share/trac/cgi-bin` directory.
+
+#### Mapping Static Resources
+
+Without additional configuration, Trac will handle requests for static resources such as stylesheets and images. For anything other than a TracStandalone deployment, this is not optimal as the web server can be set up to directly serve the static resources. For CGI setup, this is **highly undesirable** as it causes abysmal performance.
+
+Web servers such as [Apache](http://httpd.apache.org/) allow you to create //Aliases// to resources, giving them a virtual URL that doesn't necessarily reflect their location on the file system. We can map requests for static resources directly to directories on the file system, to avoid Trac processing the requests.
+
+There are two primary URL paths for static resources: `/chrome/common` and `/chrome/site`. Plugins can add their own resources, usually accessible at the `/chrome/<plugin>` path.
+
+A single `/chrome` alias can used if the static resources are extracted for all plugins. This means that the `deploy` command must be executed after installing or updating a plugin that provides static resources, or after modifying resources in the `$env/htdocs` directory. This is probably appropriate for most installations but may not be what you want if, for example, you wish to upload plugins through the //Plugins// administration page.
+
+The resources are extracted using the [TracAdmin trac-admin]` <environment> deploy` command:
+[[TracAdminHelp(deploy)]]
+
+The target `<directory>` will contain an `htdocs` directory with:
+
+    - `common/` - the static resources of Trac
+    - `site/` - a copy of the environment's `htdocs/` directory
+    - `shared` - the static resources shared by multiple Trac environments, with a location defined by the `[inherit]` `htdocs_dir` option
+    - `<plugin>/` - one directory for each resource directory provided by the plugins enabled for this environment
+
+
+The example that follows will create a single `/chrome` alias. If that isn't the correct approach for your installation you simply need to create more specific aliases:
+```#!apache
+Alias /trac/chrome/common /path/to/trac/htdocs/common
+Alias /trac/chrome/site /path/to/trac/htdocs/site
+Alias /trac/chrome/shared /path/to/trac/htdocs/shared
+Alias /trac/chrome/<plugin> /path/to/trac/htdocs/<plugin>
+```
+
+##### Example: Apache and `ScriptAlias` #ScriptAlias-example
+
+Assuming the deployment has been done this way:
+```#!sh
+$ trac-admin /var/trac/env deploy /path/to/shared/trac
+```
+
+Add the following snippet to Apache configuration, changing paths to match your deployment. The snippet must be placed *before* the `ScriptAlias` or `WSGIScriptAlias` directive, because those directives map all requests to the Trac application:
+```#!apache
+Alias /trac/chrome /path/to/trac/htdocs
+
+<Directory "/path/to/www/trac/htdocs">
+  # For Apache 2.2
+  <IfModule !mod_authz_core.c>
+    Order allow,deny
+    Allow from all
+  </IfModule>
+  # For Apache 2.4
+  <IfModule mod_authz_core.c>
+    Require all granted
+  </IfModule>
+</Directory>
+```
+
+If using mod_python, add this too, otherwise the alias will be ignored:
+```#!apache
+<Location "/trac/chrome/common">
+  SetHandler None
+</Location>
+```
+
+Alternatively, if you wish to serve static resources directly from your project's `htdocs` directory rather than the location to which the files are extracted with the `deploy` command, you can configure Apache to serve those resources. Again, put this *before* the `ScriptAlias` or `WSGIScriptAlias` for the .*cgi scripts, and adjust names and locations to match your installation:
+```#!apache
+Alias /trac/chrome/site /path/to/projectenv/htdocs
+
+<Directory "/path/to/projectenv/htdocs">
+  # For Apache 2.2
+  <IfModule !mod_authz_core.c>
+    Order allow,deny
+    Allow from all
+  </IfModule>
+  # For Apache 2.4
+  <IfModule mod_authz_core.c>
+    Require all granted
+  </IfModule>
+</Directory>
+```
+
+Another alternative to aliasing `/trac/chrome/common` is having Trac generate direct links for those static resources (and only those), using the [[TracIni#trac-section| [trac] htdocs_location]] configuration setting:
+```#!ini
+[trac]
+htdocs_location = http://static.example.org/trac-common/
+```
+
+Note that this makes it easy to have a dedicated domain serve those static resources, preferentially cookie-less.
+
+Of course, you still need to make the Trac `htdocs/common` directory available through the web server at the specified URL, for example by copying (or linking) the directory into the document root of the web server:
+```#!sh
+$ ln -s /path/to/trac/htdocs/common /var/www/static.example.org/trac-common
+```
+
+#### Setting up the Plugin Cache
+
+Some Python plugins need to be extracted to a cache directory. By default the cache resides in the home directory of the current user. When running Trac on a Web Server as a dedicated user (which is highly recommended) who has no home directory, this might prevent the plugins from starting. To override the cache location you can set the `PYTHON_EGG_CACHE` environment variable. Refer to your server documentation for detailed instructions on how to set environment variables.
+
+## Configuring Authentication
+
+Trac uses HTTP authentication. You'll need to configure your webserver to request authentication when the `.../login` URL is hit (the virtual path of the "login" button). Trac will automatically pick the `REMOTE_USER` variable up after you provide your credentials. Therefore, all user management goes through your web server configuration. Please consult the documentation of your web server for more info.
+
+The process of adding, removing, and configuring user accounts for authentication depends on the specific way you run Trac.
+
+Please refer to one of the following sections:
+
+    * TracStandalone#UsingAuthentication if you use the standalone server, `tracd`.
+    * [wiki:TracModWSGI#ConfiguringAuthentication TracModWSGI#ConfiguringAuthentication] if you use the Apache web server, with any of its front end: `mod_wsgi`, `mod_python`, `mod_fcgi` or `mod_fastcgi`.
+    * TracFastCgi if you're using another web server with FCGI support (Cherokee, Lighttpd, LiteSpeed, nginx)
+
+
+[trac:TracAuthenticationIntroduction] also contains some useful information for beginners.
+
+## Granting admin rights to the admin user
+Grant admin rights to user admin:
+```#!sh
+$ trac-admin /path/to/myproject permission add admin TRAC_ADMIN
+```
+
+This user will have an //Admin// navigation item that directs to pages for administering your Trac project.
+
+## Configuring Trac
+
+TracRepositoryAdmin provides information on configuring version control repositories for your project.
+
+## Using Trac
+
+Once you have your Trac site up and running, you should be able to create tickets, view the timeline, browse your version control repository if configured, etc.
+
+Keep in mind that //anonymous// (not logged in) users can by default access only a few of the features, in particular they will have a read-only access to the resources. You will need to configure authentication and grant additional [TracPermissions permissions] to authenticated users to see the full set of features.
+
+* Enjoy! *
+
+[trac:TracTeam The Trac Team]
+
+----
+See also: [trac:TracInstallPlatforms TracInstallPlatforms], TracGuide, TracUpgrade, TracPermissions
diff --git a/raw-wiki-dump/TracInterfaceCustomization.md b/raw-wiki-dump/TracInterfaceCustomization.md
new file mode 100644
index 0000000..695ff58
--- /dev/null
+++ b/raw-wiki-dump/TracInterfaceCustomization.md
@@ -0,0 +1,192 @@
+# Customizing the Trac Interface
+[[TracGuideToc]]
+[[PageOutline(2-5,Contents,pullout)]]
+
+This page gives suggestions on how to customize the look of Trac. Topics include editing the HTML templates and CSS files, but not the program code itself. The topics show users how they can modify the look of Trac to meet their specific needs. Suggestions for changes to Trac's interface applicable to all users should be filed as tickets, not listed on this page.
+
+## Project Logo and Icon
+The easiest parts of the Trac interface to customize are the logo and the site icon. Both of these can be configured with settings in [wiki:TracIni trac.ini].
+
+The logo or icon image should be put in a folder named "htdocs" in your project's environment folder. *Note: in projects created with a Trac version prior to 0.9 you will need to create this folder*.
+
+**Note**: you can actually put the logo and icon anywhere on your server (as long as it's accessible through the web server), and use their absolute or server-relative URLs in the configuration.
+
+Now configure the appropriate section of your [wiki:TracIni trac.ini]:
+
+### Logo
+Change the `src` setting to `site/` followed by the name of your image file. The `width` and `height` settings should be modified to match your image's dimensions. The Trac chrome handler uses `site/` for files within the project directory `htdocs`, and `common/` for the common `htdocs` directory belonging to a Trac installation. Note that 'site/' is not a placeholder for your project name, it is the literal prefix that should be used. For example, if your project is named 'sandbox', and the image file is 'red_logo.gif' then the 'src' setting would be 'site/red_logo.gif', not 'sandbox/red_logo.gif'.
+
+```#!ini
+[header_logo]
+src = site/my_logo.gif
+alt = My Project
+width = 300
+height = 100
+```
+
+### Icon
+Icons are small images displayed by your web browser next to the site's URL and in the `Bookmarks` menu. Icons should be a 32x32 image in `.gif` or `.ico` format. Change the `icon` setting to `site/` followed by the name of your icon file:
+
+```#!ini
+[project]
+icon = site/my_icon.ico
+```
+
+## Custom Navigation Entries
+The new [mainnav] and [metanav] can now be used to customize the text and link used for the navigation items, or even to disable them, but not for adding new ones.
+
+In the following example, we rename the link to the Wiki start "Home", and hide the "Help/Guide". We also make the "View Tickets" entry link to a specific report:
+```#!ini
+[mainnav]
+wiki.label = Home
+tickets.href = /report/24
+
+[metanav]
+help = disabled
+```
+
+See also TracNavigation for a more detailed explanation of the mainnav and metanav terms.
+
+## Site Appearance #SiteAppearance
+
+Trac is using [Genshi](http://genshi.edgewall.org) as the templating engine. Say you want to add a link to a custom stylesheet, and then your own header and footer. Save the following content as `site.html` inside your projects `templates/` directory (each Trac project can have their own `site.html`), eg `/path/to/env/templates/site.html`:
+
+```#!xml
+<html xmlns="http://www.w3.org/1999/xhtml"
+      xmlns:py="http://genshi.edgewall.org/"
+      py:strip="">
+
+  <!--! Add site-specific style sheet -->
+  <head py:match="head" py:attrs="select('@*')">
+    ${select('*|comment()|text()')}
+    <link rel="stylesheet" href="${href.chrome('site/style.css')}" />
+  </head>
+
+  <body py:match="body" py:attrs="select('@*')">
+    <!--! Add site-specific header -->
+    <div id="siteheader">
+      <!--! Place your header content here... -->
+    </div>
+
+    ${select('*|text()')}
+
+    <!--! Add site-specific footer -->
+    <div id="sitefooter">
+      <!--! Place your footer content here... -->
+    </div>
+  </body>
+</html>
+```
+
+Notice that XSLT bears some similarities with Genshi templates. However, there are some Trac specific features, for example the `${href.chrome('site/style.css')}` attribute references `style.css` in the environment's `htdocs/` directory. In a similar fashion `${chrome.htdocs_location}` is used to specify the common `htdocs/` directory belonging to a Trac installation. That latter location can however be overriden using the [[TracIni#trac-section|[trac] htdocs_location]] configuration setting.
+
+`site.html` is one file to contain all your modifications. It usually works using the `py:match` directive (element or attribute), and it allows you to modify the page as it renders. The matches hook onto specific sections depending on what it tries to find and modify them.
+See [this thread](http://groups.google.com/group/trac-users/browse_thread/thread/70487fb2c406c937/) for a detailed explanation of the above example `site.html`.
+A `site.html` can contain any number of such `py:match` sections for whatever you need to modify. This is all Genshi, so the [docs on the exact syntax](http://genshi.edgewall.org/wiki/Documentation/xml-templates.html) can be found there.
+
+Example snippet of adding introduction text to the new ticket form (but not shown during preview):
+
+```#!xml
+<form py:match="div[@id='content' and @class='ticket']/form" py:attrs="select('@*')">
+  <py:if test="req.path_info == '/newticket' and (not 'preview' in req.args)">
+    <p>Please make sure to search for existing tickets before reporting a new one!</p>
+  </py:if>
+  ${select('*')}
+</form>
+```
+
+This example illustrates a technique of using `req.path_info` to limit scope of changes to one view only. For instance, to make changes in `site.html` only for timeline and avoid modifying other sections - use `req.path_info == '/timeline'` condition in `<py:if>` test.
+
+More examples snippets for `site.html` can be found at [trac:wiki:CookBook/SiteHtml CookBook/SiteHtml].
+
+Example snippets for `style.css` can be found at [trac:wiki:CookBook/SiteStyleCss CookBook/SiteStyleCss].
+
+Note that the `site.html`, despite its name, can be put in a shared templates directory, see the [[TracIni#inherit-section|[inherit] templates_dir]] option. This could provide easier maintainence as one new global `site.html` file can be made to include any existing header, footer and newticket snippets.
+
+## Project List #ProjectList
+
+You can use a custom Genshi template to display the list of projects if you are using Trac with multiple projects.
+
+The following is the basic template used by Trac to display a list of links to the projects. For projects that could not be loaded, it displays an error message. You can use this as a starting point for your own index template:
+
+```#!text/html
+<!DOCTYPE html
+    PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"
+      xmlns:py="http://genshi.edgewall.org/"
+      xmlns:xi="http://www.w3.org/2001/XInclude">
+  <head>
+    <title>Available Projects</title>
+  </head>
+  <body>
+    <h1>Available Projects</h1>
+    <ul>
+      <li py:for="project in projects" py:choose="">
+        <a py:when="project.href" href="$project.href"
+           title="$project.description">$project.name</a>
+        <py:otherwise>
+          <small>$project.name: <em>Error</em> <br /> ($project.description)</small>
+        </py:otherwise>
+      </li>
+    </ul>
+  </body>
+</html>
+```
+
+Once you've created your custom template you will need to configure the webserver to tell Trac where the template is located:
+
+For [wiki:TracModWSGI mod_wsgi]:
+```#!python
+os.environ['TRAC_ENV_INDEX_TEMPLATE'] = '/path/to/template.html'
+```
+
+For [wiki:TracFastCgi FastCGI]:
+```#!apache
+FastCgiConfig -initial-env TRAC_ENV_PARENT_DIR=/parent/dir/of/projects \
+              -initial-env TRAC_ENV_INDEX_TEMPLATE=/path/to/template
+```
+
+For [wiki:TracModPython mod_python]:
+```#!apache
+PythonOption TracEnvParentDir /parent/dir/of/projects
+PythonOption TracEnvIndexTemplate /path/to/template
+```
+
+For [wiki:TracCgi CGI]:
+```#!apache
+SetEnv TRAC_ENV_INDEX_TEMPLATE /path/to/template
+```
+
+For [wiki:TracStandalone], you'll need to set up the `TRAC_ENV_INDEX_TEMPLATE` environment variable in the shell used to launch tracd:
+
+    - Unix:
+   ```#!sh
+$ export TRAC_ENV_INDEX_TEMPLATE=/path/to/template
+
+   ```
+
+    - Windows:
+   ```#!sh
+$ set TRAC_ENV_INDEX_TEMPLATE=/path/to/template
+
+   ```
+
+## Project Templates
+
+The appearance of each individual Trac environment, ie instance of a project, can be customized independently of other projects, even those hosted on the same server. The recommended way is to use a `site.html` template whenever possible, see [#SiteAppearance]. Using `site.html` means changes are made to the original templates as they are rendered, and you should not normally need to redo modifications whenever Trac is upgraded. If you do make a copy of `theme.html` or any other Trac template, you need to migrate your modifiations to the newer version. If not, new Trac features or bug fixes may not work as expected.
+
+With that word of caution, any Trac template may be copied and customized. The default Trac templates are located inside the installed Trac egg, such as `/usr/lib/pythonVERSION/site-packages/Trac-VERSION.egg/trac/templates, ../trac/ticket/templates, ../trac/wiki/templates`. The [#ProjectList] template file is called `index.html`, while the template responsible for main layout is called `theme.html`. Page assets such as images and CSS style sheets are located in the egg's `trac/htdocs` directory.
+
+However, do not edit templates or site resources inside the Trac egg. Reinstalling Trac overwrites your modifications. Instead use one of these alternatives:
+
+    * For a modification to one project only, copy the template to project `templates` directory.
+    * For a modification shared by several projects, copy the template to a shared location and have each project point to this location using the `[inherit] templates_dir` trac.ini option.
+
+
+Trac resolves requests for a template by first looking inside the project, then in any inherited templates location, and finally inside the Trac egg.
+
+Trac caches templates in memory by default to improve performance. To apply a template you need to restart the web server.
+
+----
+See also TracGuide, TracIni
diff --git a/raw-wiki-dump/TracLinks.md b/raw-wiki-dump/TracLinks.md
new file mode 100644
index 0000000..8871d43
--- /dev/null
+++ b/raw-wiki-dump/TracLinks.md
@@ -0,0 +1,412 @@
+# Trac Links
+
+[[TracGuideToc]]
+[[PageOutline(2-5,Contents,pullout)]]
+
+TracLinks are a fundamental feature of Trac, because they allow easy hyperlinking between the various entities in the system — such as tickets, reports, changesets, Wiki pages, milestones, and source files — from anywhere where WikiFormatting is used.
+
+TracLinks are generally of the form **type:id** (where *id* represents the number, name or path of the item) though some frequently used kinds of items also have short-hand notations.
+
+## Where to use TracLinks
+
+You can use TracLinks in:
+
+
+    * Source code (Subversion) commit messages
+    * Wiki pages
+    * Full descriptions for tickets, reports and milestones
+
+
+and any other text fields explicitly marked as supporting WikiFormatting.
+
+## Overview
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+ Wiki pages :: `CamelCase` or `wiki:CamelCase`
+ Parent page :: `[..]`
+ Tickets :: `#1` or `ticket:1`
+ Ticket comments :: `comment:1:ticket:2`
+ Reports :: `{1}` or `report:1`
+ Milestones :: `milestone:1.0`
+ Attachment :: `attachment:example.tgz` (for current page attachment), `attachment:attachment.1073.diff:ticket:944` (absolute path)
+ Changesets :: `r1`, `[1]`, `changeset:1` or (restricted) `[1/trunk]`, `changeset:1/trunk`, `[1/repository]`
+ Revision log :: `r1:3`, `[1:3]` or `log:@1:3`, `log:trunk@1:3`, `[2:5/trunk]`
+ Diffs :: `diff:@1:3`, `diff:plugins/0.12/mercurial-plugin@9128:9953`,
+          `diff:tags/trac-0.9.2/wiki-default//tags/trac-0.9.3/wiki-default`
+          or `diff:trunk/trac@3538//sandbox/vc-refactoring@3539`
+ Files :: `source:trunk/COPYING`, `source:/trunk/COPYING@200` (at version 200), `source:/trunk/COPYING@200#L25` (at version 200, line 25)
+
+```
+```#!td
+ Wiki pages :: CamelCase or wiki:CamelCase
+ Parent page :: [..]
+ Tickets :: #1 or ticket:1
+ Ticket comments :: comment:1:ticket:2
+ Reports :: {1} or report:1
+ Milestones :: milestone:1.0
+ Attachment :: attachment:example.tgz (for current page attachment), attachment:attachment.1073.diff:ticket:944 (absolute path)
+ Changesets :: r1, [1], changeset:1 or (restricted) [1/trunk], changeset:1/trunk, [1/repository]
+ Revision log :: r1:3, [1:3] or log:@1:3, log:trunk@1:3, [2:5/trunk]
+ Diffs :: diff:@1:3, diff:plugins/0.12/mercurial-plugin@9128:9953,
+          diff:tags/trac-0.9.2/wiki-default//tags/trac-0.9.3/wiki-default
+          or diff:trunk/trac@3538//sandbox/vc-refactoring@3539
+ Files :: source:trunk/COPYING, source:/trunk/COPYING@200 (at version 200), source:/trunk/COPYING@200#L25 (at version 200, line 25)
+```
+
+**Note:** The wiki:CamelCase form is rarely used, but it can be convenient to refer to pages whose names do not follow WikiPageNames rules, ie single words, non-alphabetic characters, etc. See WikiPageNames for more about features specific to links to Wiki page names.
+
+
+```#!table class=""
+|||| Trac links using the full (non-shorthand) notation can also be given a custom link title like this: ||
+```#!td
+```
+[ticket:1 This is a link to ticket number one] or
+[[ticket:1|This is another link to ticket number one]].
+```
+```
+```#!td
+[ticket:1 This is a link to ticket number one] or
+[[ticket:1|This is another link to ticket number one]].
+```
+|--------------------------------------------------------------------------------------
+|| If the title is omitted, only the id (the part after the colon) is displayed:  |
+|---|---|
+```#!td
+```
+[ticket:1] or [[ticket:2]]
+
+```
+```
+```#!td
+[ticket:1] or [[ticket:2]]
+```
+|--------------------------------------------------------------------------------------
+|| `wiki` is the default if the namespace part of a full link is omitted:  |
+|---|---|
+```#!td
+```
+[SandBox the sandbox] or
+[[SandBox|the sandbox]]
+
+```
+```
+```#!td
+[SandBox the sandbox] or
+[[SandBox|the sandbox]]
+```
+|--------------------------------------------------------------------------------------
+|| The short form *realm:target* can also be wrapped within a <...> pair, [[br]] which allow for arbitrary characters (i.e. anything but >)  |
+|---|---|
+```#!td
+```
+<wiki:Strange(page@!)>
+
+```
+```
+```#!td
+<wiki:Strange(page@!)>
+```
+```
+
+TracLinks are a very simple idea, but actually allow quite a complex network of information. In practice, it's very intuitive and simple to use, and we've found the "link trail" extremely helpful to better understand what's happening in a project or why a particular change was made.
+
+## Advanced use of TracLinks
+
+### Relative links
+
+To create a link to a [trac:SubWiki SubWiki]-page just use a '/':
+```
+ WikiPage/SubWikiPage or ./SubWikiPage
+```
+
+To link from a [trac:SubWiki SubWiki] page to a parent, simply use a '..':
+```
+  [..] or [[..]]
+```
+  [..] or [[..]]
+
+To link from a [trac:SubWiki SubWiki] page to a [=#sibling sibling] page, use a '../':
+```
+  [../Sibling see next sibling] or [[../Sibling|see next sibling]]
+```
+  [../Sibling see next sibling] or [[../Sibling|see next sibling]]
+
+But in practice you often won't need to add the `../` prefix to link to a sibling page.
+For resolving the location of a wiki link, it's the target page closest in the hierarchy to the page where the link is written which will be selected. So for example, within a sub-hierarchy, a sibling page will be targeted in preference to a toplevel page.
+This makes it easy to copy or move pages to a sub-hierarchy by [[WikiNewPage#renaming|renaming]] without having to adapt the links.
+
+To link explicitly to a [=#toplevel toplevel] Wiki page, use the `wiki:/` prefix. Be careful **not** to use the `/` prefix alone, as this corresponds to the [#Server-relativelinks] syntax and with such a link you will lack the `/wiki/` part in the resulting URL. A link such as `[../newticket]` will stay in the wiki namespace and therefore link to a sibling page.
+
+### Link anchors
+
+To create a link to a specific anchor in a page, use '#':
+```
+ [#Linkanchors Link anchors] or [[#Linkanchors|Link anchors]]
+```
+  [#Linkanchors Link anchors] or [[#Linkanchors|Link anchors]]
+
+Hint: when you move your mouse over the title of a section, a '¶' character will be displayed. This is a link to that specific section and you can use this to copy the `#...` part inside a relative link to an anchor.
+
+To create a link to the first or last occurrence of a term on a page, use a *pseudo anchor* starting with '#/' or '#?':
+```
+ [#/Milestone first occurrence of Milestone] or
+ [#?Milestone last occurrence of Milestone]
+```
+ [#/Milestone first occurrence of Milestone] or
+ [#?Milestone last occurrence of Milestone]
+This will also highlight all other matches on the linked page. By default only case sensitive matches are considered. To include case insensitive matches append '/i':
+```
+ [#/Milestone/i first occurrence of Milestone or milestone] or
+ [#?Milestone/i last occurrence of Milestone or milestone]
+```
+ [#/Milestone/i first occurrence of Milestone or milestone] or
+ [#?Milestone/i last occurrence of Milestone or milestone]
+
+*(since Trac 1.0)*
+
+Such anchors can be very useful for linking to specific lines in a file in the source browser:
+```
+ [trac:source:tags/trac-0.12/trac/wiki/api.py#L127 Line 127] or
+ [trac:source:tags/trac-0.12/trac/ticket/roadmap.py#L47 Line 47]
+```
+ [trac:source:tags/trac-0.12/trac/wiki/api.py#L127 Line 127] or
+ [trac:source:tags/trac-0.12/trac/ticket/roadmap.py#L47 Line 47]
+(Hint: The line numbers displayed in the source browser are links to anchors on the respective lines.)
+
+Since such links become outdated when the file changes, it can be useful to link using a '#/' pseudo anchor instead:
+```
+ [trac:source:trunk/trac/wiki/api.py#/IWikiSyntaxProvider IWikiSyntaxProvider] or
+ [trac:source:trunk/trac/env.py#/ISystemInfoProvider ISystemInfoProvider]
+```
+ [trac:source:trunk/trac/wiki/api.py#/IWikiSyntaxProvider IWikiSyntaxProvider] or
+ [trac:source:trunk/trac/env.py#/ISystemInfoProvider ISystemInfoProvider]
+
+### InterWiki links
+
+Other prefixes can be defined freely and made to point to resources in other Web applications. The definition of those prefixes as well as the URLs of the corresponding Web applications is defined in a special Wiki page, the InterMapTxt page. Note that while this could be used to create links to other Trac environments, there is a more specialized way to register other Trac environments which offers greater flexibility.
+
+### InterTrac links
+
+This can be seen as a kind of InterWiki link specialized for targeting other Trac projects.
+
+Any type of Trac link can be written in one Trac environment and actually refer to resources in another Trac environment. All that is required is to prefix the Trac link with the name of the other Trac environment followed by a colon. The other Trac environment must be registered on the InterTrac page.
+
+A distinctive advantage of InterTrac links over InterWiki links is that the shorthand form of Trac links (e.g. `{}`, `r`, `#`) can also be used. For example if T was set as an alias for Trac, links to Trac tickets can be written #T234, links to Trac changesets can be written [trac 1508].
+See InterTrac for the complete details.
+
+### Server-relative links
+
+It is often useful to be able to link to objects in your project that have no built-in Trac linking mechanism, such as static resources, `newticket`, a shared `/register` page on the server, etc.
+
+To link to resources inside the project, use either an absolute path from the project root, or a relative link from the URL of the current page (*Changed in 0.11*):
+
+```
+[/newticket Create a new ticket] or [[//newticket|Create a new ticket]]
+[/ home] or [[/|home]]
+```
+
+Display: [/newticket Create a new ticket] or [[//newticket|Create a new ticket]]
+[/ home] or [[/|home]]
+
+To link to another location on the server (possibly outside the project but on the same host), use the `//` prefix (*Changed in 0.11*):
+
+```
+[//register Register Here] or [[//register|Register Here]]
+```
+
+Display: [//register Register Here] or [[//register|Register Here]]
+
+### Quoting space in TracLinks
+
+Immediately after a TracLinks prefix, targets containing space characters should be enclosed in a pair of quotes or double quotes.
+Examples:
+
+    * wiki:"The whitespace convention"
+    * attachment:'the file.txt' or
+    * attachment:"the file.txt"
+    * attachment:"the file.txt:ticket:123"
+
+
+Note that by using [trac:WikiCreole] style links, it's quite natural to write links containing spaces:
+
+    * ![[The whitespace convention]]
+    * ![[attachment:the file.txt]]
+
+
+### Escaping Links
+
+To prevent parsing of a TracLink, you can escape it by preceding it with a '!' (exclamation mark).
+```
+ !NoLinkHere.
+ ![42] is not a link either.
+```
+
+Display:
+ NoLinkHere.
+ ![42] is not a link either.
+
+### Parameterized Trac links
+
+Many Trac resources have more than one way to be rendered, depending on some extra parameters. For example, a Wiki page can accept a `version` or a `format` parameter, a report can make use of dynamic variables, etc.
+
+Trac links can support an arbitrary set of parameters, written in the same way as they would be for the corresponding URL. Some examples:
+
+    - `wiki:WikiStart?format=txt`
+    - `ticket:1?version=1`
+    - `[/newticket?component=module1 create a ticket for module1]`
+    - `[/newticket?summary=Add+short+description+here create a ticket with URL with spaces]`
+
+
+## TracLinks Reference
+
+The following sections describe the individual link types in detail, as well as notes on advanced usage of links.
+
+### attachment: links
+
+The link syntax for attachments is as follows:
+
+    * attachment:the_file.txt creates a link to the attachment the_file.txt of the current object
+    * attachment:the_file.txt:wiki:MyPage creates a link to the attachment the_file.txt of the MyPage wiki page
+    * attachment:the_file.txt:ticket:753 creates a link to the attachment the_file.txt of the ticket 753
+
+
+Note that the older way, putting the filename at the end, is still supported: attachment:ticket:753:the_file.txt.
+
+If you'd like to create a direct link to the content of the attached file instead of a link to the attachment page, simply use `raw-attachment:` instead of `attachment:`.
+
+This can be useful for pointing directly to an HTML document, for example. Note that for this use case, you'd have to allow the web browser to render the content by setting `[attachment] render_unsafe_content = yes` (see TracIni#attachment-section). Caveat: only do that in environments for which you're 100% confident you can trust the people who are able to attach files, as otherwise this would open up your site to [wikipedia:Cross-site_scripting cross-site scripting] attacks.
+
+See also [#export:links].
+
+### comment: links
+
+When you're inside a given ticket, you can simply write e.g. comment:3 to link to the third change comment.
+It is possible to link to a comment of a specific ticket from anywhere using one of the following syntax:
+
+    - `comment:3:ticket:123`
+    - `ticket:123#comment:3` (note that you can't write `#123#comment:3`!)
+
+It is also possible to link to the ticket's description using one of the following syntax:
+
+    - `comment:description` (within the ticket)
+    - `comment:description:ticket:123`
+    - `ticket:123#comment:description`
+
+
+### htdocs: links
+
+Use `htdocs:path/to/file` to reference files in the `htdocs` directory of the Trac environment, the [TracEnvironment#DirectoryStructure web resource directory].
+
+### query: links
+
+See TracQuery#UsingTracLinks and [#ticket:links].
+
+### search: links
+
+See TracSearch#SearchLinks
+
+### ticket: links
+
+ *aliases:* `bug:`, `issue:`
+
+Besides the obvious `ticket:id` form, it is also possible to specify a list of tickets or even a range of tickets instead of the `id`. This generates a link to a custom query view containing this fixed set of tickets.
+
+Example:
+
+    - `ticket:5000-6000`
+    - `ticket:1,150`
+
+
+### timeline: links
+
+Links to the timeline can be created by specifying a date in the ISO:8601 format. The date can be optionally followed by a time specification. The time is interpreted as being UTC time, but if you don't want to compute the UTC time, you can specify a local time followed by your timezone offset relative to UTC.
+
+Examples:
+
+    - `timeline:2008-01-29`
+    - `timeline:2008-01-29T15:48`
+    - `timeline:2008-01-29T15:48Z`
+    - `timeline:2008-01-29T16:48+01`
+    - `timeline:2008-01-29T16:48+0100`
+    - `timeline:2008-01-29T16:48+01:00`
+
+
+### wiki: links
+
+See WikiPageNames and [#QuotingspaceinTracLinks quoting space in TracLinks] above. It is possible to create a link to a specific page revision using the syntax WikiStart@1.
+
+### Version Control related links
+
+It should be noted that multiple repository support works by creating a kind of virtual namespace for versioned files in which the toplevel folders correspond to the repository names. Therefore, in presence of multiple repositories, a */path* specification in the syntax of links detailed below should start with the name of the repository. If omitted, the default repository is used. In case a toplevel folder of the default repository has the same name as a repository, the latter "wins". One can always access such folder by fully qualifying it. The default repository can be an alias of a named repository, or conversely, it is always possible to create an alias for the default repository, ask your Trac administrator.
+
+For example, `source:/trunk/COPYING` targets the path `/trunk/COPYING` in the default repository, whereas `source:/projectA/trunk/COPYING` targets the path `/trunk/COPYING` in the repository named `projectA`. This can be the same file if `'projectA'` is an alias to the default repository or if `*` (the default repository) is an alias to `'projectA'`.
+
+#### source: links
+
+ *aliases:* `browser:`, `repos:`
+
+The default behavior for a `source:/some/path link` is to open the browser in that directory directory if the path points to a directory or to show the latest content of the file.
+
+It's also possible to link directly to a specific revision of a file like this:
+
+    - `source:/some/file@123` - link to the file's revision 123
+    - `source:/some/file@head` - link explicitly to the latest revision of the file
+    - `source:/some/file@named-branch` - link to latest revision of the specified file in `named-branch` (DVCS such as Git or Mercurial)
+
+
+If the revision is specified, one can even link to a specific line number:
+
+    - `source:/some/file@123#L10`
+    - `source:/tag/0.10@head#L10`
+    - `source:/some/file@named-branch#L10`
+
+
+Finally, one can also highlight an arbitrary set of lines:
+
+    - `source:/some/file@123:10-20,100,103#L99` - highlight lines 10 to 20, and lines 100 and 103, and target line 99
+    - or without version number (the `@` is still needed): `source:/some/file@:10-20,100,103#L99`. Version can be omitted when the path is pointing to a source file that will no longer change (like `source:/tags/...`), otherwise it's better to specify which lines of //which version// of the file you're talking about.
+
+
+Note that in presence of multiple repositories, the name of the repository is simply integrated in the path you specify for `source:` (e.g. `source:reponame/trunk/README`). *(since 0.12)*
+
+#### export: links
+
+To force the download of a file in the repository, as opposed to displaying it in the browser, use the `export` link.  Several forms are available:
+
+    * `export:/some/file` - get the HEAD revision of the specified file
+    * `export:123:/some/file` - get revision 123 of the specified file
+    * `export:/some/file@123` - get revision 123 of the specified file
+    * `export:/some/file@named-branch` - get latest revision of the specified file in `named-branch` (DVCS such as Git or Mercurial).
+
+
+This can be very useful for displaying XML or HTML documentation with correct stylesheets and images, in case that has been checked in into the repository. Note that for this use case, you'd have to allow the web browser to render the content by setting `[browser] render_unsafe_content = yes` (see TracIni#browser-section), otherwise Trac will force the files to be downloaded as attachments for security concerns.
+
+If the path is to a directory in the repository instead of a specific file, the source browser will be used to display the directory (identical to the result of `source:/some/dir`).
+
+#### log: links
+
+The `log:` links are used to display revision ranges. In its simplest form, it can link to the latest revisions of the specified path, but it can also support displaying an arbitrary set of revisions.
+
+    - `log:/` - the latest revisions starting at the root of the repository
+    - `log:/trunk/tools` - the latest revisions in `trunk/tools`
+    - `log:/trunk/tools@10000` - the revisions in `trunk/tools` starting from  revision 10000
+    - `log:@20788,20791:20795` - list revision 20788 and the revisions from 20791 to 20795
+    - `log:/trunk/tools@20788,20791:20795` - list revision 20788 and the revisions from 20791 to 20795 which affect the given path
+    - `log:/tools@named-branch` - the revisions in `tools` starting from the latest revision in `named-branch` (DVCS such as Git or Mercurial)
+
+
+There are short forms for revision ranges as well:
+
+    - `[20788,20791:20795]`
+    - `[20788,20791:20795/trunk/tools]`
+    - `r20791:20795` (but not `r20788,20791:20795` nor `r20791:20795/trunk`)
+
+
+Finally, note that in all of the above, a revision range can be written either as `x:y` or `x-y`.
+
+In the presence of multiple repositories, the name of the repository should be specified as the first part of the path, e.g. `log:repos/branches` or `[20-40/repos]`.
+
+----
+See also: WikiFormatting, TracWiki, WikiPageNames, InterTrac, InterWiki
diff --git a/raw-wiki-dump/TracLogging.md b/raw-wiki-dump/TracLogging.md
new file mode 100644
index 0000000..9eb5f7f
--- /dev/null
+++ b/raw-wiki-dump/TracLogging.md
@@ -0,0 +1,50 @@
+# Trac Logging
+[[TracGuideToc]]
+
+Trac supports logging of system messages using the standard [logging module](http://docs.python.org/library/logging.html) that comes with Python.
+
+Logging is configured in the `[logging]` section in [wiki:TracIni#logging-section trac.ini].
+
+## Supported Logging Methods
+
+The log method is set using the `log_type` option in [wiki:TracIni#logging-section trac.ini], which takes any of the following values:
+
+ **none*:: Suppress all log messages.
+ **file**:: Log messages to a file, specified with the `log_file` option in [wiki:TracIni#logging-section trac.ini]. Relative paths in `log_file` are resolved relative to the `log` directory of the environment.
+ **stderr**:: Output all log entries to console ([wiki:TracStandalone tracd] only).
+ **syslog**:: (UNIX) Send all log messages to the local syslogd via named pipe `/dev/log`. By default, syslog will write them to the file /var/log/messages.
+ **eventlog**:: (Windows) Use the system's NT Event Log for Trac logging.
+
+## Log Levels
+
+The verbosity level of logged messages can be set using the `log_level` option in [wiki:TracIni#logging-section trac.ini]. The log level defines the minimum level of urgency required for a message to be logged, and those levels are:
+
+ **CRITICAL**:: Log only the most critical (typically fatal) errors.
+ **ERROR**:: Log failures, bugs and errors.
+ **WARN**:: Log warnings, non-interrupting events.
+ **INFO**:: Diagnostic information, log information about all processing.
+ **DEBUG**:: Trace messages, profiling, etc.
+
+Additionally, you can  enable logging of SQL statements at debug level. This is turned off by default, as it's very verbose. Set `[trac] debug_sql = yes` in TracIni to activate.
+
+## Log Format
+
+The output format for log entries can be specified through the `log_format` option in [trac.ini]. The format is a string which can contain any of the [http://docs.python.org/library/logging.html#logrecord-attributes Python logging Formatter variables](wiki:TracIni#logging-section). Additonally, the following Trac-specific variables can be used:
+ **$(basename)s**:: The last path component of the current environment.
+ **$(path)s**:: The absolute path for the current environment.
+ **$(project)s**:: The originating project's name.
+
+Note that variables are identified using a dollar sign (`$(...)s`) instead of percent sign (`%(...)s`).
+
+The default format is:
+```#!ini
+log_format = Trac[$(module)s] $(levelname)s: $(message)s
+```
+
+In a multi-project environment where all logs are sent to the same place (e.g. `syslog`), it makes sense to add the project name. In this example we use `basename` since that can generally be used to identify a project:
+```#!ini
+log_format = Trac[$(basename)s:$(module)s] $(levelname)s: $(message)s
+```
+
+----
+See also: TracIni, TracGuide, TracEnvironment
diff --git a/raw-wiki-dump/TracModPython.md b/raw-wiki-dump/TracModPython.md
new file mode 100644
index 0000000..b772521
--- /dev/null
+++ b/raw-wiki-dump/TracModPython.md
@@ -0,0 +1,387 @@
+[[TracGuideToc]]
+
+# Trac and mod_python
+
+Mod_python is an [Apache](https://httpd.apache.org/) module that embeds the Python interpreter within the server, so that web-based applications in Python will run many times faster than traditional CGI and will have the ability to retain database connections.
+Trac supports [mod_python], which speeds up Trac's response times considerably, especially compared to [TracCgi CGI], and permits use of many Apache features not possible with [wiki:TracStandalone tracd](http://www.modpython.org/)/mod_proxy.
+
+[[PageOutline(2-3,Overview,inline)]]
+
+## Simple configuration: single project #Simpleconfiguration
+
+If you just installed mod_python, you may have to add a line to load the module in the Apache configuration:
+```#!apache
+LoadModule python_module modules/mod_python.so
+```
+
+**Note**: The exact path to the module depends on how the HTTPD installation is laid out.
+
+On Debian using apt-get:
+```#!sh
+apt-get install libapache2-mod-python libapache2-mod-python-doc
+```
+
+Still on Debian, after you have installed mod_python, you must enable the modules in apache2, equivalent to the above Load Module directive:
+```#!sh
+a2enmod python
+```
+
+On Fedora use, using yum:
+```#!sh
+yum install mod_python
+```
+
+You can test your mod_python installation by adding the following to your httpd.conf. You should remove this when you are done testing for security reasons. Note: mod_python.testhandler is only available in mod_python 3.2+.
+```#!apache
+<Location /mpinfo>
+  SetHandler mod_python
+  PythonInterpreter main_interpreter
+  PythonHandler mod_python.testhandler
+  # For Apache 2.2
+  <IfModule !mod_authz_core.c>
+    Order allow,deny
+    Allow from all
+  </IfModule>
+  # For Apache 2.4
+  <IfModule mod_authz_core.c>
+    Require all granted
+  </IfModule>
+</Location>
+```
+
+A simple setup of Trac on mod_python looks like this:
+```#!apache
+<Location /projects/myproject>
+  SetHandler mod_python
+  PythonInterpreter main_interpreter
+  PythonHandler trac.web.modpython_frontend
+  PythonOption TracEnv /var/trac/myproject
+  PythonOption TracUriRoot /projects/myproject
+  # For Apache 2.2
+  <IfModule !mod_authz_core.c>
+    Order allow,deny
+    Allow from all
+  </IfModule>
+  # For Apache 2.4
+  <IfModule mod_authz_core.c>
+    Require all granted
+  </IfModule>
+</Location>
+```
+
+The option **`TracUriRoot`** may or may not be necessary in your setup. Try your configuration without it; if the URLs produced by Trac look wrong, if Trac does not seem to recognize URLs correctly, or you get an odd "No handler matched request to..." error, add the **`TracUriRoot`** option. You will notice that the `Location` and **`TracUriRoot`** have the same path.
+
+The options available are:
+```#!apache
+# For a single project
+PythonOption TracEnv /var/trac/myproject
+
+# For multiple projects
+PythonOption TracEnvParentDir /var/trac/myprojects
+
+# For the index of multiple projects
+PythonOption TracEnvIndexTemplate /srv/www/htdocs/trac/project_list_template.html
+
+# A space delimitted list, with a "," between key and value pairs.
+PythonOption TracTemplateVars key1,val1 key2,val2
+
+# Useful to get the date in the wanted order
+PythonOption TracLocale en_GB.UTF8
+
+# See description above
+PythonOption TracUriRoot /projects/myproject
+```
+
+### Python Egg Cache
+
+Compressed Python eggs like Genshi are normally extracted into a directory named `.python-eggs` in the users home directory. Since Apache's home usually is not writeable, an alternate egg cache directory can be specified like this:
+```#!apache
+PythonOption PYTHON_EGG_CACHE /var/trac/myprojects/egg-cache
+```
+
+Or you can uncompress the Genshi egg to resolve problems extracting from it.
+
+### Configuring Authentication
+
+See corresponding section in the [wiki:TracModWSGI#ConfiguringAuthentication] page.
+
+## Advanced Configuration
+
+### Setting the Python Egg Cache
+
+If the Egg Cache isn't writeable by your Web server, you'll either have to change the permissions, or point Python to a location where Apache can write. This can manifest itself as a `500 internal server error` and/or a complaint in the syslog.
+
+```#!apache
+<Location /projects/myproject>
+  ...
+  PythonOption PYTHON_EGG_CACHE /tmp
+  ...
+</Location>
+```
+
+### Setting the PythonPath
+
+If the Trac installation isn't installed in your Python path, you will have to tell Apache where to find the Trac mod_python handler  using the `PythonPath` directive:
+```#!apache
+<Location /projects/myproject>
+  ...
+  PythonPath "sys.path + ['/path/to/trac']"
+  ...
+</Location>
+```
+
+Be careful about using the PythonPath directive, and *not* `SetEnv PYTHONPATH`, as the latter won't work.
+
+### Setting up multiple projects
+
+The Trac mod_python handler supports a configuration option similar to Subversion's `SvnParentPath`, called `TracEnvParentDir`:
+```#!apache
+<Location /projects>
+  SetHandler mod_python
+  PythonInterpreter main_interpreter
+  PythonHandler trac.web.modpython_frontend
+  PythonOption TracEnvParentDir /var/trac
+  PythonOption TracUriRoot /projects
+</Location>
+```
+
+When you request the `/projects` URL, you will get a listing of all subdirectories of the directory you set as `TracEnvParentDir` that look like Trac environment directories. Selecting any project in the list will bring you to the corresponding Trac environment.
+
+If you don't want to have the subdirectory listing as your projects home page you can use a
+```#!apache
+<LocationMatch "/.+/">
+```
+
+This will instruct Apache to use mod_python for all locations different from root while having the possibility of placing a custom home page for root in your DocumentRoot folder.
+
+You can also use the same authentication realm for all of the projects using a `<LocationMatch>` directive:
+```#!apache
+<LocationMatch "/projects/[^/]+/login">
+  AuthType Basic
+  AuthName "Trac"
+  AuthUserFile /var/trac/.htpasswd
+  Require valid-user
+</LocationMatch>
+```
+
+### Virtual Host Configuration
+
+Below is the sample configuration required to set up your Trac as a virtual server, ie when you access it at the URLs like
+`http://trac.mycompany.com`:
+
+```#!apache
+<VirtualHost *>
+    DocumentRoot /var/www/myproject
+    ServerName trac.mycompany.com
+    <Location />
+        SetHandler mod_python
+        PythonInterpreter main_interpreter
+        PythonHandler trac.web.modpython_frontend
+        PythonOption TracEnv /var/trac/myproject
+        PythonOption TracUriRoot /
+    </Location>
+    <Location /login>
+        AuthType Basic
+        AuthName "MyCompany Trac Server"
+        AuthUserFile /var/trac/myproject/.htpasswd
+        Require valid-user
+    </Location>
+</VirtualHost>
+```
+
+This does not seem to work in all cases. What you can do if it does not:
+
+    * Try using `<LocationMatch>` instead of `<Location>`.
+    * `<Location />` may, in your server setup, refer to the complete host instead of simple the root of the server. This means that everything (including the login directory referenced below) will be sent to Python and authentication does not work, ie you get the infamous Authentication information missing error. If this is the case, try using a sub-directory for Trac instead of the root, ie /web/ and /web/login instead of / and /login.
+    * Depending on apache's `NameVirtualHost` configuration, you may need to use `<VirtualHost *:80>` instead of `<VirtualHost *>`.
+
+
+For a virtual host that supports multiple projects replace `TracEnv /var/trac/myproject` with `TracEnvParentDir /var/trac`.
+
+**Note**: DocumentRoot should not point to your Trac project env. As Asmodai wrote on #trac: "suppose there's a webserver bug that allows disclosure of DocumentRoot they could then leech the entire Trac environment".
+
+## Troubleshooting
+
+If you get server error pages, you can either check the Apache error log, or enable the `PythonDebug` option:
+```#!apache
+<Location /projects/myproject>
+  ...
+  PythonDebug on
+</Location>
+```
+
+For multiple projects, try restarting the server as well.
+
+### Login Not Working
+
+If you've used `<Location />` directive, it will override any other directives, as well as `<Location /login>`.
+The workaround is to use negation expression as follows (for multi project setups):
+```#!apache
+#this one for other pages
+<Location ~ "/*(?!login)">
+   SetHandler mod_python
+   PythonHandler trac.web.modpython_frontend
+   PythonOption TracEnvParentDir /projects
+   PythonOption TracUriRoot /
+</Location>
+
+#this one for login page
+<Location ~ "/[^/]+/login">
+   SetHandler mod_python
+   PythonHandler trac.web.modpython_frontend
+   PythonOption TracEnvParentDir /projects
+   PythonOption TracUriRoot /
+
+   #remove these if you don't want to force SSL
+   RewriteEngine On
+   RewriteCond %{HTTPS} off
+   RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
+
+   AuthType Basic
+   AuthName "Trac"
+   AuthUserFile /projects/.htpasswd
+   Require valid-user
+</Location>
+```
+
+### Expat-related segmentation faults === #expat
+
+This problem will most certainly hit you on Unix when using Python 2.4.
+In Python 2.4, some version of [Expat](http://expat.sourceforge.net/) (an XML parser library written in C) is used and if Apache is using another version, this results in segmentation faults.
+As Trac 0.11 is using Genshi, which will indirectly use Expat, that problem can now hit you even if everything was working fine before with Trac 0.10. This problem has not been reported for Python 2.5+, so best to upgrade.
+
+### Form submission problems
+
+If you're experiencing problems submitting some of the forms in Trac (a common problem is that you get redirected to the start page after submission), check whether your ```DocumentRoot``` contains a folder or file with the same path that you mapped the mod_python handler to. For some reason, mod_python gets confused when it is mapped to a location that also matches a static resource.
+
+### Problem with virtual host configuration
+
+If the <Location /> directive is used, setting the `DocumentRoot` may result in a *403 (Forbidden)* error. Either remove the `DocumentRoot` directive, or make sure that accessing the directory it points is allowed, in a corresponding `<Directory>` block.
+
+Using <Location /> together with `SetHandler` resulted in having everything handled by mod_python, which leads to not being able to download any CSS or images/icons. Use <Location /trac> `SetHandler None` </Location> to circumvent the problem, though this may not be the most elegant solution.
+
+### Problem with zipped egg
+
+It's possible that your version of mod_python will not import modules from zipped eggs. If you encounter an `ImportError: No module named trac` in your Apache logs but you think everything is where it should be, this might be your problem. Look in your site-packages directory; if the Trac module appears as a *file* rather than a *directory*, then this might be your problem. To rectify this, try installing Trac using the `--always-unzip` option:
+
+```#!sh
+easy_install --always-unzip Trac-0.12b1.zip
+```
+
+### Using .htaccess
+
+Although it may seem trivial to rewrite the above configuration as a directory in your document root with a `.htaccess` file, this does not work. Apache will append a "/" to any Trac URLs, which interferes with its correct operation.
+
+It may be possible to work around this with mod_rewrite, but I failed to get this working. In all, it is more hassle than it is worth.
+
+This also works out-of-box, with following trivial config:
+```#!apache
+SetHandler mod_python
+PythonInterpreter main_interpreter
+PythonHandler trac.web.modpython_frontend
+PythonOption TracEnv /system/path/to/this/directory
+PythonOption TracUriRoot /path/on/apache
+
+AuthType Basic
+AuthName "ProjectName"
+AuthUserFile /path/to/.htpasswd
+Require valid-user
+```
+
+The `TracUriRoot` is obviously the path you need to enter to the browser to get to Trac, eg `domain.tld/projects/trac`.
+
+### Additional .htaccess help
+
+If you are using the .htaccess method you may have additional problems if your Trac directory is inheriting .htaccess directives from another. This may also help to add to your .htaccess file:
+
+```#!apache
+<IfModule mod_rewrite.c>
+  RewriteEngine Off
+</IfModule>
+```
+
+### Platform specific issues
+#### Win32 Issues
+
+If you run Trac with mod_python < 3.2 on Windows, uploading attachments will **not** work. This problem is resolved in mod_python 3.1.4 or later, so please upgrade mod_python to fix this.
+
+#### OS X issues
+
+When using mod_python on OS X you will not be able to restart Apache using `apachectl restart`. This is apparently fixed in mod_python 3.2, so please upgrade mod_python to fix this.
+
+#### SELinux issues
+
+If Trac reports something like: `Cannot get shared lock on db.lock`, then the security context on the repository may need to be set:
+
+```#!sh
+chcon -R -h -t httpd_sys_content_t PATH_TO_REPOSITORY
+```
+
+See also [How do I set repository permissions correctly?](http://subversion.apache.org/faq.html#reposperms)
+
+#### FreeBSD issues
+
+The FreeBSD ports have both the new and old versions of mod_python and SQLite, but earlier versions of pysqlite and mod_python won't integrate:
+
+    * pysqlite requires threaded support in Python
+    * mod_python requires a threadless install.
+
+
+Apache2 does not automatically support threads on FreeBSD. You could force thread support when running `./configure` for Apache, using `--enable-threads`, but this isn´t recommended.
+The best option [seems to be](http://modpython.org/pipermail/mod_python/2006-September/021983.html) adding to /usr/local/apache2/bin/ennvars the line:
+
+```#!sh
+export LD_PRELOAD=/usr/lib/libc_r.so
+```
+
+#### Fedora 7 Issues
+
+Make sure you install the 'python-sqlite2' package as it seems to be required for TracModPython, but not for tracd.
+
+### Subversion issues
+
+If you get the following Trac error `Unsupported version control system "svn"` only under mod_python, though it works well on the command-line and even with TracStandalone, chances are that you forgot to add the path to the Python bindings with the [TracModPython#ConfiguringPythonPath PythonPath] directive. A better way is to add a link to the bindings in the Python `site-packages` directory, or create a `.pth` file in that directory.
+
+If this is not the case, it's possible that you are using Subversion libraries that are binary incompatible with the Apache ones and an incompatibility of the `apr` libraries is usually the cause. In that case, you also won't be able to use the svn modules for Apache (`mod_dav_svn`).
+
+You also need a recent version of `mod_python` in order to avoid a runtime error (```argument number 2: a 'apr_pool_t *' is expected```) due to the default usage of multiple sub-interpreters. Version 3.2.8 *should* work, though it's probably better to use the workaround described in [trac:#3371 #3371], in order to force the use of the main interpreter:
+```#!apache
+PythonInterpreter main_interpreter
+```
+
+This is also the recommended workaround for other issues seen when using the Python bindings for Subversion within mod_python ([trac:#2611 #2611], [trac:#3455 #3455]). See in particular Graham Dumpleton's comment in [trac:comment:9:ticket:3455 #3455] explaining the issue.
+
+### Page layout issues
+
+If the formatting of the Trac pages look weird, chances are that the style sheets governing the page layout are not handled properly by the web server. Try adding the following lines to your Apache configuration:
+```#!apache
+Alias /myproject/css "/usr/share/trac/htdocs/css"
+<Location /myproject/css>
+    SetHandler None
+</Location>
+```
+
+**Note**: For the above configuration to have any effect it must be put after the configuration of your project root location, ie ```<Location /myproject />```.
+
+**Note:** Do not enable python optimizations using the directive `PythonOptimize On`. When optimizations are enabled the page header/footer and documentation for macros and plugins will be hidden. An error will be raised in Trac 1.0.11 and later when optimizations are enabled.
+
+### HTTPS issues
+
+If you want to run Trac fully under https you might find that it tries to redirect to plain http. In this case just add the following line to your Apache configuration:
+```#!apache
+<VirtualHost *>
+    DocumentRoot /var/www/myproject
+    ServerName trac.mycompany.com
+    SetEnv HTTPS 1
+    ....
+</VirtualHost>
+```
+
+### Segmentation fault with php5-mhash or other php5 modules
+
+You may encounter segfaults (reported on Debian etch) if php5-mhash module is installed. Try to remove it to see if this solves the problem. See [Debian bug report](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411487).
+
+Some people also have troubles when using PHP5 compiled with its own third party libraries instead of system libraries. Check [Django segmentation fault](http://www.djangoproject.com/documentation/modpython/#if-you-get-a-segmentation-fault).
+
+----
+See also: TracGuide, TracInstall, [wiki:TracModWSGI ModWSGI], [wiki:TracFastCgi FastCGI], [trac:TracNginxRecipe]
diff --git a/raw-wiki-dump/TracModWSGI.md b/raw-wiki-dump/TracModWSGI.md
new file mode 100644
index 0000000..4167349
--- /dev/null
+++ b/raw-wiki-dump/TracModWSGI.md
@@ -0,0 +1,442 @@
+# Trac and mod_wsgi
+
+[mod_wsgi](https://github.com/GrahamDumpleton/mod_wsgi) is an Apache module for running WSGI-compatible Python applications directly on top of the Apache webserver. The mod_wsgi adapter is written completely in C and provides very good performance.
+
+[[PageOutline(2-3,Overview,inline)]]
+
+## The `trac.wsgi` script
+
+Trac can be run on top of mod_wsgi with the help of an application script, which is a Python file saved with a `.wsgi` extension.
+
+A robust and generic version of this file can be created using the `trac-admin <env> deploy <dir>` command which automatically substitutes the required paths, see TracInstall#cgi-bin. The script should be sufficient for most installations and users not wanting more information can proceed to [#Mappingrequeststothescript configuring Apache].
+
+If you are using Trac with multiple projects, you can specify their common parent directory using the `TRAC_ENV_PARENT_DIR` in trac.wsgi:
+```#!python
+def application(environ, start_request):
+    # Add this to config when you have multiple projects
+    environ.setdefault('trac.env_parent_dir', '/usr/share/trac/projects')
+    ..
+```
+
+### A very basic script
+
+In its simplest form, the script could be:
+
+```#!python
+import os
+
+os.environ['TRAC_ENV'] = '/usr/local/trac/mysite'
+os.environ['PYTHON_EGG_CACHE'] = '/usr/local/trac/mysite/eggs'
+
+import trac.web.main
+application = trac.web.main.dispatch_request
+```
+
+The `TRAC_ENV` variable should naturally be the directory for your Trac environment, and the `PYTHON_EGG_CACHE` should be a directory where Python can temporarily extract Python eggs. If you have several Trac environments in a directory, you can also use `TRAC_ENV_PARENT_DIR` instead of `TRAC_ENV`.
+
+On Windows:
+
+    - If run under the user's session, the Python Egg cache can be found in `%AppData%\Roaming`, for example:
+```#!python
+os.environ['PYTHON_EGG_CACHE'] = r'C:\Users\Administrator\AppData\Roaming\Python-Eggs'
+
+```
+
+    - If run under a Window service, you should create a directory for Python Egg cache:
+```#!python
+os.environ['PYTHON_EGG_CACHE'] = r'C:\Trac-Python-Eggs'
+
+```
+
+### A more elaborate script
+
+If you are using multiple `.wsgi` files (for example one per Trac environment) you must *not* use `os.environ['TRAC_ENV']` to set the path to the Trac environment. Using this method may lead to Trac delivering the content of another Trac environment, as the variable may be filled with the path of a previously viewed Trac environment.
+
+To solve this problem, use the following `.wsgi` file instead:
+```#!python
+import os
+
+os.environ['PYTHON_EGG_CACHE'] = '/usr/local/trac/mysite/eggs'
+
+import trac.web.main
+def application(environ, start_response):
+  environ['trac.env_path'] = '/usr/local/trac/mysite'
+  return trac.web.main.dispatch_request(environ, start_response)
+```
+
+For clarity, you should give this file a `.wsgi` extension. You should probably put the file in its own directory, since you will expose it to Apache.
+
+If you have installed Trac and Python eggs in a path different from the standard one, you should add that path by adding the following code at the top of the wsgi script:
+
+```#!python
+import site
+site.addsitedir('/usr/local/trac/lib/python2.4/site-packages')
+```
+
+Change it according to the path you installed the Trac libs at.
+
+## Mapping requests to the script
+
+After preparing your .wsgi script, add the following to your Apache configuration file, typically `httpd.conf`:
+
+```#!apache
+WSGIScriptAlias /trac /usr/local/trac/mysite/apache/mysite.wsgi
+
+<Directory /usr/local/trac/mysite/apache>
+    WSGIApplicationGroup %{GLOBAL}
+    # For Apache 2.2
+    <IfModule !mod_authz_core.c>
+        Order deny,allow
+        Allow from all
+    </IfModule>
+    # For Apache 2.4
+    <IfModule mod_authz_core.c>
+        Require all granted
+    </IfModule>
+</Directory>
+```
+
+Here, the script is in a subdirectory of the Trac environment.
+
+If you followed the directions [TracInstall#cgi-bin Generating the Trac cgi-bin directory], your Apache configuration file should look like following:
+
+```#!apache
+WSGIScriptAlias /trac /usr/share/trac/cgi-bin/trac.wsgi
+
+<Directory /usr/share/trac/cgi-bin>
+    WSGIApplicationGroup %{GLOBAL}
+    # For Apache 2.2
+    <IfModule !mod_authz_core.c>
+        Order deny,allow
+        Allow from all
+    </IfModule>
+    # For Apache 2.4
+    <IfModule mod_authz_core.c>
+        Require all granted
+    </IfModule>
+</Directory>
+```
+
+In order to let Apache run the script, access to the directory in which the script resides is opened up to all of Apache. Additionally, the `WSGIApplicationGroup` directive ensures that Trac is always run in the first Python interpreter created by mod_wsgi. This is necessary because the Subversion Python bindings, which are used by Trac, don't always work in other sub-interpreters and may cause requests to hang or cause Apache to crash. After adding this configuration, restart Apache, and then it should work.
+
+To test the setup of Apache, mod_wsgi and Python itself (ie without involving Trac and dependencies), this simple wsgi application can be used to make sure that requests gets served (use as only content in your `.wsgi` script):
+
+```#!python
+def application(environ, start_response):
+        start_response('200 OK',[('Content-type','text/html')])
+        return ['<html><body>Hello World!</body></html>']
+```
+
+For more information about using the mod_wsgi specific directives, see the [mod_wsgi's wiki] and more specifically the [https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithTrac.wiki IntegrationWithTrac](https://code.google.com/archive/p/modwsgi/wikis) page.
+
+## Configuring Authentication
+
+The following sections describe different methods for setting up authentication. See also [Authentication, Authorization and Access Control](http://httpd.apache.org/docs/2.4/howto/auth.html) in the Apache guide.
+
+### Using Basic Authentication
+
+The simplest way to enable authentication with Apache is to create a password file. Use the `htpasswd` program as follows:
+```#!sh
+$ htpasswd -c /somewhere/trac.htpasswd admin
+New password: <type password>
+Re-type new password: <type password again>
+Adding password for user admin
+```
+
+After the first user, you don't need the "-c" option anymore:
+```#!sh
+$ htpasswd /somewhere/trac.htpasswd john
+New password: <type password>
+Re-type new password: <type password again>
+Adding password for user john
+```
+
+See the man page for `htpasswd` for full documentation.
+
+After you've created the users, you can set their permissions using TracPermissions.
+
+Now, you need to enable authentication against the password file in the Apache configuration:
+```#!apache
+<Location "/trac/login">
+  AuthType Basic
+  AuthName "Trac"
+  AuthUserFile /somewhere/trac.htpasswd
+  Require valid-user
+</Location>
+```
+
+If you are hosting multiple projects, you can use the same password file for all of them:
+```#!apache
+<LocationMatch "/trac/[^/]+/login">
+  AuthType Basic
+  AuthName "Trac"
+  AuthUserFile /somewhere/trac.htpasswd
+  Require valid-user
+</LocationMatch>
+```
+
+Note that neither a file nor a directory named 'login' needs to exist. See also the [mod_auth_basic](https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html) documentation.
+
+### Using Digest Authentication
+
+For better security, it is recommended that you either enable SSL or at least use the "digest" authentication scheme instead of "Basic".
+
+You have to create your `.htpasswd` file with the `htdigest` command instead of `htpasswd`, as follows:
+```#!sh
+$ htdigest -c /somewhere/trac.htpasswd trac admin
+```
+
+The "trac" parameter above is the "realm", and will have to be reused in the Apache configuration in the AuthName directive:
+
+```#!apache
+<Location "/trac/login">
+  AuthType Digest
+  AuthName "trac"
+  AuthDigestDomain /trac
+  AuthUserFile /somewhere/trac.htpasswd
+  Require valid-user
+</Location>
+```
+
+For multiple environments, you can use the same `LocationMatch` as described with the previous method.
+
+**Note**: `Location` cannot be used inside .htaccess files, but must instead live within the main httpd.conf file. If you are on a shared server, you therefore will not be able to provide this level of granularity.
+
+Don't forget to activate the mod_auth_digest. For example, on a Debian 4.0r1 (etch) system:
+```#!apache
+  LoadModule auth_digest_module /usr/lib/apache2/modules/mod_auth_digest.so
+```
+
+See also the [mod_auth_digest](https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html) documentation.
+
+### Using LDAP Authentication
+
+Configuration for [mod_ldap](https://httpd.apache.org/docs/2.4/mod/mod_ldap.html) authentication in Apache is more involved (httpd 2.2+ and OpenLDAP: slapd 2.3.19).
+
+1. You need to load the following modules in Apache httpd.conf:
+```#!apache
+  LoadModule ldap_module modules/mod_ldap.so
+  LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
+```
+1. Your httpd.conf also needs to look something like:
+```#!apache
+<Location /trac/>
+  # (if you're using it, mod_python specific settings go here)
+  Order deny,allow
+  Deny from all
+  Allow from 192.168.11.0/24
+  AuthType Basic
+  AuthName "Trac"
+  AuthBasicProvider "ldap"
+  AuthLDAPURL "ldap://127.0.0.1/dc=example,dc=co,dc=ke?uid?sub?(objectClass=inetOrgPerson)"
+  authzldapauthoritative Off
+  Require valid-user
+</Location>
+```
+1. You can use the LDAP interface as a way to authenticate to a Microsoft Active Directory. Use the following as your LDAP URL:
+```#!apache
+  AuthLDAPURL "ldap://directory.example.com:3268/DC=example,DC=com?sAMAccountName?sub?(objectClass=user)"
+```
+ You will also need to provide an account for Apache to use when checking credentials. As this password will be listed in plain text in the configuration, you need to use an account specifically for this task:
+```#!apache
+  AuthLDAPBindDN ldap-auth-user@example.com
+  AuthLDAPBindPassword "password"
+```
+ The whole section looks like:
+```#!apache
+<Location /trac/>
+  # (if you're using it, mod_python specific settings go here)
+  Order deny,allow
+  Deny from all
+  Allow from 192.168.11.0/24
+  AuthType Basic
+  AuthName "Trac"
+  AuthBasicProvider "ldap"
+  AuthLDAPURL "ldap://adserver.company.com:3268/DC=company,DC=com?sAMAccountName?sub?(objectClass=user)"
+  AuthLDAPBindDN       ldap-auth-user@company.com
+  AuthLDAPBindPassword "the_password"
+  authzldapauthoritative Off
+  # require valid-user
+  Require ldap-group CN=Trac Users,CN=Users,DC=company,DC=com
+</Location>
+```
+
+Note 1: This is the case where the LDAP search will get around the multiple OUs, conecting to the Global Catalog Server portion of AD. Note the port is 3268, not the normal LDAP 389. The GCS is basically a "flattened" tree which allows searching for a user without knowing to which OU they belong.
+
+Note 2: You can also require the user be a member of a certain LDAP group, instead of just having a valid login:
+```#!apache
+  Require ldap-group CN=Trac Users,CN=Users,DC=example,DC=com
+```
+
+See also:
+
+    - [mod_authnz_ldap](https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html), documentation for mod_authnz_ldap.
+    - [mod_ldap](https://httpd.apache.org/docs/2.4/mod/mod_ldap.html), documentation for mod_ldap, which provides connection pooling and a shared cache.
+    - [TracHacks:LdapPlugin](https://trac-hacks.org/wiki/LdapPlugin) for storing TracPermissions in LDAP.
+
+
+### Using SSPI Authentication
+
+If you are using Apache on Windows, you can use mod_auth_sspi to provide single-sign-on. Download the module from the SourceForge [mod-auth-sspi project](http://sourceforge.net/projects/mod-auth-sspi/) and then add the following to your VirtualHost:
+```#!apache
+<Location /trac/login>
+  AuthType SSPI
+  AuthName "Trac Login"
+  SSPIAuth On
+  SSPIAuthoritative On
+  SSPIDomain MyLocalDomain
+  SSPIOfferBasic On
+  SSPIOmitDomain Off
+  SSPIBasicPreferred On
+  Require valid-user
+</Location>
+```
+
+Using the above, usernames in Trac will be of the form `DOMAIN\username`, so you may have to re-add permissions and such. If you do not want the domain to be part of the username, set `SSPIOmitDomain On` instead.
+
+Some common problems with SSPI authentication: [trac:#1055], [trac:#1168] and [trac:#3338].
+
+See also [trac:TracOnWindows/Advanced].
+
+### Using CA SiteMinder Authentication
+
+Setup CA SiteMinder to protect your Trac login URL, for example `/trac/login`. Also, make sure the policy is set to include the HTTP_REMOTE_USER variable. If your site allows it, you can set this in `LocalConfig.conf`:
+```#!apache
+RemoteUserVar="WHATEVER_IT_SHOULD_BE"
+SetRemoteUser="YES"
+```
+
+The specific variable is site-dependent. Ask your site administrator. If your site does not allow the use of `LocalConfig.conf` for security reasons, have your site administrator set the policy on the server to set REMOTE_USER.
+
+Also add a LogOffUri parameter to the agent configuration, for example `/trac/logout`.
+
+Then modify the trac.wsgi script generated using `trac-admin <env> deploy <dir>` to add the following lines, which extract the `HTTP_REMOTE_USER` variable and set it to `REMOTE_USER`:
+
+```#!python
+def application(environ, start_request):
+    # Set authenticated username on CA SiteMinder to REMOTE_USER variable
+    # strip() is used to remove any spaces on the end of the string
+    if 'HTTP_SM_USER' in environ:
+        environ['REMOTE_USER'] = environ['HTTP_REMOTE_USER'].strip()
+    ...
+```
+
+You do not need any Apache "Location" directives.
+
+### Example: Apache/mod_wsgi with Basic Authentication, Trac being at the root of a virtual host
+
+Per the mod_wsgi documentation linked to above, here is an example Apache configuration that:
+
+    - serves the Trac instance from a virtualhost subdomain
+    - uses Apache basic authentication for Trac authentication.
+
+
+If you want your Trac to be served from eg http://trac.my-proj.my-site.org, then from the folder eg `/home/trac-for-my-proj`, if you used the command `trac-admin the-env initenv` to create a folder `the-env`, and you used `trac-admin the-env deploy the-deploy` to create a folder `the-deploy`, then first:
+
+Create the htpasswd file:
+```#!sh
+cd /home/trac-for-my-proj/the-env
+htpasswd -c htpasswd firstuser
+### and add more users to it as needed:
+htpasswd htpasswd seconduser
+```
+
+Keep the file above your document root for security reasons.
+
+Create this file for example `/etc/apache2/sites-enabled/trac.my-proj.my-site.org.conf` on Ubuntu with the following content:
+
+```#!apache
+<Directory /home/trac-for-my-proj/the-deploy/cgi-bin/trac.wsgi>
+  WSGIApplicationGroup %{GLOBAL}
+  Order deny,allow
+  Allow from all
+</Directory>
+
+<VirtualHost *:80>
+  ServerName trac.my-proj.my-site.org
+  DocumentRoot /home/trac-for-my-proj/the-env/htdocs/
+  WSGIScriptAlias / /home/trac-for-my-proj/the-deploy/cgi-bin/trac.wsgi
+  <Location '/'>
+    AuthType Basic
+    AuthName "Trac"
+    AuthUserFile /home/trac-for-my-proj/the-env/htpasswd
+    Require valid-user
+  </Location>
+</VirtualHost>
+
+```
+
+For subdomains to work you would probably also need to alter `/etc/hosts` and add A-Records to your host's DNS.
+
+## Troubleshooting
+
+### Use a recent version
+
+Please use either version 1.6, 2.4 or later of `mod_wsgi`. Versions prior to 2.4 in the 2.X branch have problems with some Apache configurations that use WSGI file wrapper extension. This extension is used in Trac to serve up attachments and static media files such as style sheets. If you are affected by this problem, attachments will appear to be empty and formatting of HTML pages will appear not to work due to style sheet files not loading properly. Another frequent symptom is that binary attachment downloads are truncated. See mod_wsgi tickets [#100] and [https://code.google.com/archive/p/modwsgi/issues/132 #132](https://code.google.com/archive/p/modwsgi/issues/100).
+
+**Note**: using mod_wsgi 2.5 and Python 2.6.1 gave an Internal Server Error on my system (Apache 2.2.11 and Trac 0.11.2.1). Upgrading to Python 2.6.2 (as suggested [here]) solved this for me[[BR]](http://www.mail-archive.com/modwsgi@googlegroups.com/msg01917.html)-- Graham Shanks
+
+If you plan to use `mod_wsgi` in embedded mode on Windows or with the MPM worker on Linux, then you will need version 3.4 or greater. See [trac:#10675] for details.
+
+### Getting Trac to work nicely with SSPI and 'Require Group'
+
+If you have set Trac up on Apache, Win32 and configured SSPI, but added a 'Require group' option to your Apache configuration, then the SSPIOmitDomain option is probably not working. If it is not working, your usernames in Trac probably look like 'DOMAIN\user' rather than 'user'.
+
+This WSGI script fixes that:
+```#!python
+import os
+import trac.web.main
+
+os.environ['TRAC_ENV'] = '/usr/local/trac/mysite'
+os.environ['PYTHON_EGG_CACHE'] = '/usr/local/trac/mysite/eggs'
+
+def application(environ, start_response):
+    if "\\" in environ['REMOTE_USER']:
+        environ['REMOTE_USER'] = environ['REMOTE_USER'].split("\\", 1)[1]
+    return trac.web.main.dispatch_request(environ, start_response)
+```
+
+### Trac with PostgreSQL
+
+When using the mod_wsgi adapter with multiple Trac instances and PostgreSQL (or MySQL?) as the database, the server *may* create a lot of open database connections and thus PostgreSQL processes.
+
+A somewhat brutal workaround is to disable connection pooling in Trac. This is done by setting `poolable = False` in `trac.db.postgres_backend` on the `PostgreSQLConnection` class.
+
+But it is not necessary to edit the source of Trac. The following lines in `trac.wsgi` will also work:
+
+```#!python
+import trac.db.postgres_backend
+trac.db.postgres_backend.PostgreSQLConnection.poolable = False
+```
+
+or
+
+```#!python
+import trac.db.mysql_backend
+trac.db.mysql_backend.MySQLConnection.poolable = False
+```
+
+Now Trac drops the connection after serving a page and the connection count on the database will be kept low.
+
+//This is not a recommended approach though. See also the notes at the bottom of the [mod_wsgi's IntegrationWithTrac](https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithTrac.wiki) wiki page.//
+
+### Missing Headers and Footers
+
+If python optimizations are enabled, then headers and footers will not be rendered. An error will be raised in Trac 1.0.11 and later when optimizations are enabled.
+
+In your WSGI configuration file, the `WSGIPythonOptimize` setting must be set to `0` (`1` or `2` will not work):
+
+```#!apache
+    WSGIPythonOptimize 0
+```
+
+On Ubuntu, the WSGI mod configuration is at `/etc/apache2/mods-enabled/wsgi.conf`.
+
+The same issue is seen with `PythonOptimize On` in [TracModPython#Pagelayoutissues ModPython].
+
+### Other resources
+
+For more troubleshooting tips, see also the [mod_python troubleshooting] section, as most Apache-related issues are quite similar, plus discussion of potential [https://code.google.com/archive/p/modwsgi/wikis/ApplicationIssues.wiki application issues] when using mod_wsgi. The wsgi page also has a [https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithTrac.wiki Integration With Trac](TracModPython#Troubleshooting) document.
+
+----
+See also: TracGuide, TracInstall, [wiki:TracFastCgi FastCGI], [wiki:TracModPython ModPython], [trac:TracNginxRecipe TracNginxRecipe]
diff --git a/raw-wiki-dump/TracNavigation.md b/raw-wiki-dump/TracNavigation.md
new file mode 100644
index 0000000..5c0a595
--- /dev/null
+++ b/raw-wiki-dump/TracNavigation.md
@@ -0,0 +1,72 @@
+# Trac Navigation
+
+The main and meta navigation entries can be customized in some basic ways. The `[mainnav]` and `[metanav]` configuration sections can be used to customize the navigation item text and link, change the ordering of the navigation items, or even disable them.
+
+### `[mainnav]` #mainnav-bar
+`[mainnav]` corresponds to the **main navigation bar**, the one containing entries such as *Wiki*, *Timeline*, *Roadmap*, *Browse Source* and so on. This navigation bar is meant to access the default page of the main modules enabled in Trac that are accessible for the current user.
+
+
+** [=#Example Example] **
+
+In the following example we rename the link to WikiStart //Home//, and make the //View Tickets// entry link to a specific report.
+```#!ini
+[mainnav]
+wiki.label = Home
+tickets.href = /report/24
+```
+
+### `[metanav]` #metanav-bar
+`[metanav]` corresponds to the **meta navigation bar**, by default positioned above the main navigation bar and below the *Search* box. It contains the *Login*, *Logout*, *Help/Guide* etc. entries. This navigation bar is meant to access some global information about the Trac project and the current user.
+
+There is one special entry in the  `[metanav]` section: `logout.redirect` is the page the user sees after hitting the logout button.  The *Help/Guide* link is also hidden in the following example.
+[[comment(see also #Trac3808)]]
+
+** Example **
+
+```#!ini
+[metanav]
+help = disabled
+logout.redirect = wiki/Logout
+```
+
+
+### URL Formats
+Possible URL formats for `.href` or `.redirect`:
+| **config** | **redirect to** |
+|---|---|
+| `wiki/Logout` | `/projects/env/wiki/Logout` |
+| `http://hostname/` | `http://hostname/` |
+| `/projects` | `/projects` |
+
+
+
+### Ordering #nav-order
+The `order` attribute specifies the order in which the navigation items are displayed. This can be particularly useful for plugins that add navigation items.
+
+Non-negative floating point values may be used for the `order` attribute. The navigation items will be arranged from left to right in increasing order. Navigation items without an `order` attribute are sorted alphabetically by name.
+
+The default values are:
+```#!ini
+[mainnav]
+browser.order = 4
+newticket.order = 6
+roadmap.order = 3
+search.order = 7
+tickets.order = 5
+timeline.order = 2
+wiki.order = 1
+
+[metanav]
+about.order = 5
+help.order = 4
+login.order = 1
+logout.order = 2
+prefs.order = 3
+```
+
+### Context Navigation #ctxtnav-bar
+
+Note that it is still not possible to customize the **contextual navigation bar**, ie the one usually placed below the main navigation bar.
+
+----
+See also: TracInterfaceCustomization, and the [TracHacks:NavAddPlugin] or [http://trac-hacks.org/wiki/MenusPlugin TracHacks:MenusPlugin](http://trac-hacks.org/wiki/NavAddPlugin) (still needed for adding entries)
diff --git a/raw-wiki-dump/TracNotification.md b/raw-wiki-dump/TracNotification.md
new file mode 100644
index 0000000..4c3a091
--- /dev/null
+++ b/raw-wiki-dump/TracNotification.md
@@ -0,0 +1,280 @@
+# Email Notification of Ticket Changes
+[[TracGuideToc]]
+
+Trac supports notification of ticket changes via email.
+
+Email notification is useful to keep users up-to-date on tickets/issues of interest, and also provides a convenient way to post all ticket changes to a dedicated mailing list. For example, this is how the [Trac-tickets](http://lists.edgewall.com/archive/trac-tickets/) mailing list is set up.
+
+Disabled by default, notification can be activated and configured in [wiki:TracIni trac.ini].
+
+## Receiving Notification Mails
+When reporting a new ticket or adding a comment, enter a valid email address or your Trac username in the *reporter*, *assigned to/owner* or *cc* field. Trac will automatically send you an email when changes are made to the ticket, depending on how notification is configured.
+
+### How to use your username to receive notification mails
+
+To receive notification mails, you can either enter a full email address or your Trac username. To get notified with a simple username or login, you need to specify a valid email address in the *Preferences* page.
+
+Alternatively, a default domain name (**`smtp_default_domain`**) can be set in the TracIni file, see [#ConfigurationOptions Configuration Options] below. In this case, the default domain will be appended to the username, which can be useful for an "Intranet" kind of installation.
+
+When using apache and mod_kerb for authentication against Kerberos / Active Directory, usernames take the form (**`username@EXAMPLE.LOCAL`**). To avoid this being interpreted as an email address, add the Kerberos domain to  (**`ignore_domains`**).
+
+### Ticket attachment notifications
+
+Since 1.0.3 Trac will send notifications when a ticket attachment is added or deleted. Usually attachment notifications will be enabled in an environment by default. To disable the attachment notifications for an environment the `TicketAttachmentNotifier` component must be disabled:
+```#!ini
+[components]
+trac.ticket.notification.TicketAttachmentNotifier = disabled
+```
+
+## Configuring SMTP Notification
+
+**Important:** For TracNotification to work correctly, the `[trac] base_url` option must be set in [wiki:TracIni trac.ini].
+
+### Configuration Options
+These are the available options for the `[notification]` section in trac.ini:
+
+[[TracIni(notification)]]
+
+### Example Configuration (SMTP)
+```#!ini
+[notification]
+smtp_enabled = true
+smtp_server = mail.example.com
+smtp_from = notifier@example.com
+smtp_replyto = myproj@projects.example.com
+smtp_always_cc = ticketmaster@example.com, theboss+myproj@example.com
+```
+
+### Example Configuration (`sendmail`)
+```#!ini
+[notification]
+smtp_enabled = true
+email_sender = SendmailEmailSender
+sendmail_path = /usr/sbin/sendmail
+smtp_from = notifier@example.com
+smtp_replyto = myproj@projects.example.com
+smtp_always_cc = ticketmaster@example.com, theboss+myproj@example.com
+```
+
+### Subscriber Configuration
+The default subscriptions are configured in the `[notification-subscriber]` section in trac.ini:
+
+[[TracIni(notification-subscriber)]]
+
+Each user can override these defaults in his *Notifications* preferences.
+
+For example to unsubscribe from notifications for one's own changes and comments, the rule "Never notify: I update a ticket" should be added above other subscription rules.
+
+### Customizing the e-mail subject
+The e-mail subject can be customized with the `ticket_subject_template` option, which contains a [Genshi text template](http://genshi.edgewall.org/wiki/Documentation/text-templates.html) snippet. The default value is:
+```#!genshi
+$prefix #$ticket.id: $summary
+```
+The following variables are available in the template:
+
+
+    * `env`: The project environment (see [trac:source:/trunk/trac/env.py env.py]).
+    * `prefix`: The prefix defined in `smtp_subject_prefix`.
+    * `summary`: The ticket summary, with the old value if the summary was edited.
+    * `ticket`: The ticket model object (see [trac:source:/trunk/trac/ticket/model.py model.py]). Individual ticket fields can be addressed by appending the field name separated by a dot, eg `$ticket.milestone`.
+
+
+### Customizing the e-mail content
+
+The notification e-mail content is generated based on `ticket_notify_email.txt` in `trac/ticket/templates`. You can add your own version of this template by adding a `ticket_notify_email.txt` to the templates directory of your environment. The default looks like this:
+
+```#!genshi
+$ticket_body_hdr
+$ticket_props
+{% choose ticket.new %}\
+{%   when True %}\
+$ticket.description
+{%   end %}\
+{%   otherwise %}\
+{%     if changes_body %}\
+${_('Changes (by %(author)s):', author=change.author)}
+
+$changes_body
+{%     end %}\
+{%     if changes_descr %}\
+{%       if not changes_body and not change.comment and change.author %}\
+${_('Description changed by %(author)s:', author=change.author)}
+{%       end %}\
+$changes_descr
+--
+{%     end %}\
+{%     if change.comment %}\
+
+${changes_body and _('Comment:') or _('Comment (by %(author)s):', author=change.author)}
+
+$change.comment
+{%     end %}\
+{%   end %}\
+{% end %}\
+
+--
+${_('Ticket URL: <%(link)s>', link=ticket.link)}
+$project.name <${project.url or abs_href()}>
+$project.descr
+```
+
+## Sample Email
+```
+#42: testing
+---------------------------+------------------------------------------------
+       Id:  42             |      Status:  assigned
+Component:  report system  |    Modified:  Fri Apr  9 00:04:31 2004
+ Severity:  major          |   Milestone:  0.9
+ Priority:  lowest         |     Version:  0.6
+    Owner:  anonymous      |    Reporter:  jonas@example.com
+---------------------------+------------------------------------------------
+Changes:
+  * component:  changeset view => search system
+  * priority:  low => highest
+  * owner:  jonas => anonymous
+  * cc:  daniel@example.com =>
+         daniel@example.com, jonas@example.com
+  * status:  new => assigned
+
+Comment:
+I'm interested too!
+
+--
+Ticket URL: <http://example.com/trac/ticket/42>
+My Project <http://myproj.example.com/>
+```
+
+## Customizing e-mail content for MS Outlook
+
+MS Outlook normally presents plain text e-mails with a variable-width font, and as a result the ticket properties table will most certainly look like a mess in MS Outlook. This can be fixed with some customization of the [#Customizingthee-mailcontent e-mail template].
+
+Replace the following second row in the template:
+```
+$ticket_props
+```
+
+with this (requires Python 2.6 or later):
+```
+--------------------------------------------------------------------------
+{% with
+   pv = [(a[0].strip(), a[1].strip()) for a in [b.split(':') for b in
+         [c.strip() for c in
+          ticket_props.replace('|', '\n').splitlines()[1:-1]] if ':' in b]];
+   sel = ['Reporter', 'Owner', 'Type', 'Status', 'Priority', 'Milestone',
+          'Component', 'Severity', 'Resolution', 'Keywords'] %}\
+${'\n'.join('%s\t%s' % (format(p[0]+':', ' <12'), p[1]) for p in pv if p[0] in sel)}
+{% end %}\
+--------------------------------------------------------------------------
+```
+
+The table of ticket properties is replaced with a list of a selection of the properties. A tab character separates the name and value in such a way that most people should find this more pleasing than the default table when using MS Outlook.
+```#!div style="margin: 1em 1.75em; border:1px dotted"
+```#!html
+#42: testing<br />
+--------------------------------------------------------------------------<br />
+<table cellpadding=0>
+<tr><td>Reporter:</td><td>jonas@example.com</td></tr>
+<tr><td>Owner:</td><td>anonymous</td></tr>
+<tr><td>Type:</td><td>defect</td></tr>
+<tr><td>Status:</td><td>assigned</td></tr>
+<tr><td>Priority:</td><td>lowest</td></tr>
+<tr><td>Milestone:</td><td>0.9</td></tr>
+<tr><td>Component:</td><td>report system</td></tr>
+<tr><td>Severity:</td><td>major</td></tr>
+<tr><td>Resolution:</td><td> </td></tr>
+<tr><td>Keywords:</td><td> </td></tr>
+</table>
+--------------------------------------------------------------------------<br />
+Changes:<br />
+<br />
+&nbsp;&nbsp;* component: &nbsp;changeset view =&gt; search system<br />
+&nbsp;&nbsp;* priority: &nbsp;low =&gt; highest<br />
+&nbsp;&nbsp;* owner: &nbsp;jonas =&gt; anonymous<br />
+&nbsp;&nbsp;* cc: &nbsp;daniel@example.com =&gt;<br />
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;daniel@example.com, jonas@example.com<br />
+&nbsp;&nbsp;* status: &nbsp;new =&gt; assigned<br />
+<br />
+Comment:<br />
+I'm interested too!<br />
+<br />
+--<br />
+Ticket URL: &lt;http://example.com/trac/ticket/42&gt;<br />
+My Project &lt;http://myproj.example.com/&gt;<br />
+```
+```
+
+**Important**: Only those ticket fields that are listed in `sel` are part of the HTML mail. If you have defined custom ticket fields which are to be part of the mail, then they have to be added to `sel`. Example:
+```
+   sel = ['Reporter', ..., 'Keywords', 'Custom1', 'Custom2']
+```
+
+However, the solution is still a workaround to an automatically HTML-formatted e-mail.
+
+## Using GMail as the SMTP relay host
+
+Use the following configuration snippet:
+```#!ini
+[notification]
+smtp_enabled = true
+use_tls = true
+mime_encoding = base64
+smtp_server = smtp.gmail.com
+smtp_port = 587
+smtp_user = user
+smtp_password = password
+```
+
+where *user* and *password* match an existing GMail account, ie the ones you use to log in on [http://gmail.com](http://gmail.com).
+
+Alternatively, you can use `smtp_port = 25`.[[br]]
+You should not use `smtp_port = 465`. Doing so may deadlock your ticket submission. Port 465 is reserved for the SMTPS protocol, which is not supported by Trac. See [trac:comment:2:ticket:7107 #7107] for details.
+
+## Troubleshooting
+
+If you cannot get the notification working, first make sure the log is activated and have a look at the log to find if an error message has been logged. See TracLogging for help about the log feature.
+
+Notification errors are not reported through the web interface, so the user who submits a change or a new ticket never gets notified about a notification failure. The Trac administrator needs to look at the log to find the error trace.
+
+### *Permission denied* error
+
+Typical error message:
+```#!sh
+  ...
+  File ".../smtplib.py", line 303, in connect
+    raise socket.error, msg
+  error: (13, 'Permission denied')
+```
+
+This error usually comes from a security settings on the server: many Linux distributions do not allow the web server (Apache, ...) to post email messages to the local SMTP server.
+
+Many users get confused when their manual attempts to contact the SMTP server succeed:
+```#!sh
+telnet localhost 25
+```
+This is because a regular user may connect to the SMTP server, but the web server cannot:
+```#!sh
+sudo -u www-data telnet localhost 25
+```
+
+In such a case, you need to configure your server so that the web server is authorized to post to the SMTP server. The actual settings depend on your Linux distribution and current security policy. You may find help in the Trac [trac:MailingList MailingList] archive.
+
+Relevant ML threads:
+
+    * SELinux: http://article.gmane.org/gmane.comp.version-control.subversion.trac.general/7518
+
+
+For SELinux in Fedora 10:
+```#!sh
+$ setsebool -P httpd_can_sendmail 1
+```
+
+### *Suspected spam* error
+
+Some SMTP servers may reject the notification email sent by Trac.
+
+The default Trac configuration uses Base64 encoding to send emails to the recipients. The whole body of the email is encoded, which sometimes trigger *false positive* spam detection on sensitive email servers. In such an event, change the default encoding to "quoted-printable" using the `mime_encoding` option.
+
+Quoted printable encoding works better with languages that use one of the Latin charsets. For Asian charsets, stick with the Base64 encoding.
+
+----
+See also: TracTickets, TracIni, TracGuide, [trac:TracDev/NotificationApi]
diff --git a/raw-wiki-dump/TracPermissions.md b/raw-wiki-dump/TracPermissions.md
new file mode 100644
index 0000000..bff3ae0
--- /dev/null
+++ b/raw-wiki-dump/TracPermissions.md
@@ -0,0 +1,221 @@
+# Trac Permissions
+[[TracGuideToc]]
+
+Trac uses a simple, case sensitive, permission system to control what users can and can't access.
+
+Permission privileges are managed using the [TracAdmin trac-admin] tool or the *General / Permissions* panel in the *Admin* tab of the web interface.
+
+In addition to the default permission policy described in this page, it is possible to activate additional permission policies by enabling plugins and listing them in the `[trac] permission_policies` configuration entry in the TracIni. See TracFineGrainedPermissions for more details.
+
+Non-authenticated users accessing the system are assigned the name "anonymous". Assign permissions to the "anonymous" user to set privileges for anonymous/guest users. The parts of Trac that a user does not have the privileges for will not be displayed in the navigation.
+In addition to these privileges, users can be granted additional individual rights in effect when authenticated and logged into the system. All logged in users belong to the virtual group "authenticated", which inherits permissions from "anonymous".
+
+## Graphical Admin Tab
+
+To access this tab, a user must have one of the following permissions: `TRAC_ADMIN`, `PERMISSION_ADMIN`, `PERMISSION_GRANT`, `PERMISSION_REVOKE`. The permissions can be granted using the `trac-admin` command (more on `trac-admin` below):
+```
+  $ trac-admin /path/to/projenv permission add bob TRAC_ADMIN
+```
+
+Then, the user `bob` will be able to see the Admin tab, and can then access the permissions menu. This menu will allow you to perform all the following actions, but from the browser without requiring root access to the server (just the correct permissions for your user account). **Use at least one lowercase character in user names, as all-uppercase names are reserved for permissions.**
+
+ 1. [[Image(htdocs:../common/guide/admin.png)]]
+ 1. [[Image(htdocs:../common/guide/admin-permissions.png)]]
+ 1. [[Image(htdocs:../common/guide/admin-permissions-TICKET_ADMIN.png)]]
+
+An easy way to quickly secure a new Trac install is to run the above command on the anonymous user, install the [AccountManagerPlugin](http://trac-hacks.org/wiki/AccountManagerPlugin), create a new admin account graphically and then remove the TRAC_ADMIN permission from the anonymous user.
+
+From the graphical admin tab, users with `PERMISSION_GRANT` will only be allowed to grant permissions that they possess, and users with `PERMISSION_REVOKE` will only be allowed to revoke permissions that they possess. For example, a user cannot grant `MILESTONE_ADMIN` unless they have `PERMISSION_GRANT` and `MILESTONE_ADMIN`, and they cannot revoke `MILESTONE_ADMIN` unless they have `PERMISSION_REVOKE` and `MILESTONE_ADMIN`. `PERMISSION_ADMIN` just grants the user both `PERMISSION_GRANT` and `PERMISSION_REVOKE`, and users with `TRAC_ADMIN` can grant or revoke any permission.
+
+## Available Privileges
+
+To enable all privileges for a user, use the `TRAC_ADMIN` permission. Having `TRAC_ADMIN` is like being `root` on a *NIX system: it will allow you to perform any operation.
+
+Otherwise, individual privileges can be assigned to users for the various different functional areas of Trac (**note that the privilege names are case-sensitive**):
+
+### Repository Browser
+
+| `BROWSER_VIEW` | View directory listings in the [wiki:TracBrowser repository browser] |
+|---|---|
+| `LOG_VIEW` | View revision logs of files and directories in the [wiki:TracBrowser repository browser] |
+| `FILE_VIEW` | View files in the [wiki:TracBrowser repository browser] |
+| `CHANGESET_VIEW` | View [wiki:TracChangeset repository check-ins] |
+
+
+### Ticket System
+
+| `TICKET_VIEW` | View existing [wiki:TracTickets tickets] and perform [wiki:TracQuery ticket queries] |
+|---|---|
+| `TICKET_CREATE` | Create new [wiki:TracTickets tickets] |
+| `TICKET_APPEND` | Add comments or attachments to [wiki:TracTickets tickets] |
+| `TICKET_CHGPROP` | Modify [wiki:TracTickets ticket] properties (priority, assignment, keywords, etc.) with the following exceptions: edit description field, add/remove other users from cc field when logged in, and set email to pref |
+| `TICKET_MODIFY` | Includes both `TICKET_APPEND` and `TICKET_CHGPROP`, and in addition allows resolving [wiki:TracTickets tickets]. Tickets can be assigned to users through a [TracTickets#Assign-toasDrop-DownList drop-down list] when the list of possible owners has been restricted. |
+| `TICKET_EDIT_CC` | Full modify cc field |
+| `TICKET_EDIT_DESCRIPTION` | Modify description field |
+| `TICKET_EDIT_COMMENT` | Modify another user's comments. Any user can modify their own comments by default. |
+| `TICKET_BATCH_MODIFY` | [wiki:TracBatchModify Batch modify] tickets |
+| `TICKET_ADMIN` | All `TICKET_*` permissions, deletion of ticket attachments and modification of the reporter field, which grants ability to create a ticket on behalf of another user (it will appear that another user created the ticket). It also allows managing ticket properties through the web administration module. |
+
+
+Attention: the "view tickets" button appears with the `REPORT_VIEW` permission.
+
+### Roadmap
+
+| `MILESTONE_VIEW` | View milestones and assign tickets to milestones. |
+|---|---|
+| `MILESTONE_CREATE` | Create a new milestone |
+| `MILESTONE_MODIFY` | Modify existing milestones |
+| `MILESTONE_DELETE` | Delete milestones |
+| `MILESTONE_ADMIN` | All `MILESTONE_*` permissions |
+| `ROADMAP_VIEW` | View the [wiki:TracRoadmap roadmap] page, is not (yet) the same as MILESTONE_VIEW, see [trac:#4292 #4292] |
+| `ROADMAP_ADMIN` | to be removed with [trac:#3022 #3022], replaced by MILESTONE_ADMIN |
+
+
+### Reports
+
+| `REPORT_VIEW` | View [wiki:TracReports reports], i.e. the "view tickets" link. |
+|---|---|
+| `REPORT_SQL_VIEW` | View the underlying SQL query of a [wiki:TracReports report] |
+| `REPORT_CREATE` | Create new [wiki:TracReports reports] |
+| `REPORT_MODIFY` | Modify existing [wiki:TracReports reports] |
+| `REPORT_DELETE` | Delete [wiki:TracReports reports] |
+| `REPORT_ADMIN` | All `REPORT_*` permissions |
+
+
+### Wiki System
+
+| `WIKI_VIEW` | View existing [wiki:TracWiki wiki] pages |
+|---|---|
+| `WIKI_CREATE` | Create new [wiki:TracWiki wiki] pages |
+| `WIKI_MODIFY` | Change [wiki:TracWiki wiki] pages |
+| `WIKI_RENAME` | Rename [wiki:TracWiki wiki] pages |
+| `WIKI_DELETE` | Delete [wiki:TracWiki wiki] pages and attachments |
+| `WIKI_ADMIN` | All `WIKI_*` permissions, plus the management of *readonly* pages. |
+
+
+### Permissions
+
+| `PERMISSION_GRANT` | add/grant a permission |
+|---|---|
+| `PERMISSION_REVOKE` | remove/revoke a permission |
+| `PERMISSION_ADMIN` | All `PERMISSION_*` permissions |
+
+
+### Others
+
+| `TIMELINE_VIEW` | View the [wiki:TracTimeline timeline] page |
+|---|---|
+| `SEARCH_VIEW` | View and execute [wiki:TracSearch search] queries |
+| `CONFIG_VIEW` | Enables additional pages on *About Trac* that show the current configuration or the list of installed plugins |
+| `EMAIL_VIEW` | Shows email addresses even if [wiki:TracIni#trac-section trac show_email_addresses] configuration option is false |
+
+
+## Creating New Privileges
+
+To create custom permissions, for example to be used in a custom workflow, enable the optional [trac:ExtraPermissionsProvider tracopt.perm.config_perm_provider.ExtraPermissionsProvider] component in the "Plugins" admin panel, and add the desired permissions to the `[extra-permissions]` section in your [wiki:TracIni#extra-permissions-section trac.ini]. For more information, please refer to the documentation  on the [wiki:TracIni#extra-permissions-section TracIni] page after enabling the component.
+
+## Granting Privileges
+
+You grant privileges to users using [wiki:TracAdmin trac-admin]. The current set of privileges can be listed with the following command:
+```
+  $ trac-admin /path/to/projenv permission list
+```
+
+This command will allow the user *bob* to delete reports:
+```
+  $ trac-admin /path/to/projenv permission add bob REPORT_DELETE
+```
+
+The `permission add` command also accepts multiple privilege names:
+```
+  $ trac-admin /path/to/projenv permission add bob REPORT_DELETE WIKI_CREATE
+```
+
+Or add all privileges:
+```
+  $ trac-admin /path/to/projenv permission add bob TRAC_ADMIN
+```
+
+## Permission Groups
+
+There are two built-in groups, "authenticated" and "anonymous".
+Any user who has not logged in is automatically in the "anonymous" group.
+Any user who has logged in is also in the "authenticated" group.
+The "authenticated" group inherits permissions from the "anonymous" group.
+For example, if the "anonymous" group has permission WIKI_MODIFY,
+it is not necessary to add the WIKI_MODIFY permission to the "authenticated" group as well.
+
+Custom groups may be defined that inherit permissions from the two built-in groups.
+
+Permissions can be grouped together to form roles such as *developer*, *admin*, etc.
+```
+  $ trac-admin /path/to/projenv permission add developer WIKI_ADMIN
+  $ trac-admin /path/to/projenv permission add developer REPORT_ADMIN
+  $ trac-admin /path/to/projenv permission add developer TICKET_MODIFY
+  $ trac-admin /path/to/projenv permission add bob developer
+  $ trac-admin /path/to/projenv permission add john developer
+```
+
+Group membership can be checked by doing a ```permission list``` with no further arguments; the resulting output will include group memberships. **Use at least one lowercase character in group names, as all-uppercase names are reserved for permissions**.
+
+## Adding a New Group and Permissions
+Permission groups can be created by assigning a user to a group you wish to create, then assign permissions to that group.
+
+The following will add *bob* to the new group called *beta_testers* and then will assign WIKI_ADMIN permissions to that group. (Thus, *bob* will inherit the WIKI_ADMIN permission)
+```
+   $ trac-admin /path/to/projenv permission add bob beta_testers
+   $ trac-admin /path/to/projenv permission add beta_testers WIKI_ADMIN
+
+```
+
+## Removing Permissions
+
+Permissions can be removed using the 'remove' command. For example:
+
+This command will prevent the user *bob* from deleting reports:
+```
+  $ trac-admin /path/to/projenv permission remove bob REPORT_DELETE
+```
+
+Just like `permission add`, this command accepts multiple privilege names.
+
+You can also remove all privileges for a specific user:
+```
+  $ trac-admin /path/to/projenv permission remove bob '*'
+```
+
+Or one privilege for all users:
+```
+  $ trac-admin /path/to/projenv permission remove '*' REPORT_ADMIN
+```
+
+## Default Permissions
+
+By default on a new Trac installation, the `anonymous` user will have *view* access to everything in Trac, but will not be able to create or modify anything.
+On the other hand, the `authenticated` users will have the permissions to *create and modify tickets and wiki pages*.
+
+**anonymous**
+```
+ BROWSER_VIEW
+ CHANGESET_VIEW
+ FILE_VIEW
+ LOG_VIEW
+ MILESTONE_VIEW
+ REPORT_SQL_VIEW
+ REPORT_VIEW
+ ROADMAP_VIEW
+ SEARCH_VIEW
+ TICKET_VIEW
+ TIMELINE_VIEW
+ WIKI_VIEW
+```
+
+**authenticated**
+```
+ TICKET_CREATE
+ TICKET_MODIFY
+ WIKI_CREATE
+ WIKI_MODIFY
+```
+----
+See also: TracAdmin, TracGuide and TracFineGrainedPermissions
diff --git a/raw-wiki-dump/TracPlugins.md b/raw-wiki-dump/TracPlugins.md
new file mode 100644
index 0000000..cc1d9bb
--- /dev/null
+++ b/raw-wiki-dump/TracPlugins.md
@@ -0,0 +1,234 @@
+[[PageOutline(2-5,Contents,pullout)]]
+
+# Trac plugins
+
+Trac is extensible with [trac:PluginList plugins]. Plugin functionality is based on the [trac:TracDev/ComponentArchitecture component architecture], with special cases described in the [trac:TracDev/PluginDevelopment plugin development] page.
+
+## Plugin discovery
+
+From the user's point of view, a plugin is either a standalone .py file or an .egg package. Trac looks for plugins in Python's `site-packages` directory, the [TracIni#GlobalConfiguration global shared] `plugins` directory and the [TracEnvironment project environment] `plugins` directory. Components defined in globally-installed plugins must be explicitly enabled in the [[TracIni#components-section| [components] ]] section of the `trac.ini` file. Components defined in the `plugins` directory of the project environment are enabled, unless explicitly disabled in the `[components]` section of the `trac.ini` file.
+
+## Requirements for Trac eggs #Requirements
+
+To use egg-based plugins in Trac, you need to have [setuptools](http://peak.telecommunity.com/DevCenter/setuptools) (version >= 0.6) installed.
+
+To install `setuptools`, download the bootstrap module [ez_setup.py](http://peak.telecommunity.com/dist/ez_setup.py) and execute it as follows:
+
+```#!sh
+$ python ez_setup.py
+```
+
+If the `ez_setup.py` script fails to install the setuptools release, you can download it from [pypi:setuptools PyPI] and install it manually.
+
+Plugins can also consist of a single `.py` file dropped directly into either the project's or the shared `plugins` directory.
+
+## Installing a Trac plugin
+
+The instructions below are applicable to a plugin packaged as an egg. Plugins implemented as a single `py` file should be downloaded and copied to the [TracEnvironment project environment] `plugins` directory or the [TracIni#GlobalConfiguration global shared] plugins directory.
+
+### For a single project
+
+If you have downloaded a source distribution of a plugin, and want to build the `.egg` file:
+
+
+    * Unpack the source. It should provide `setup.py`.
+    * Run:
+ ```#!sh
+$ python setup.py bdist_egg
+
+```
+
+You should now have an *.egg file. Examine the output of running Python to find where this was created.
+
+Once you have the plugin archive, copy it into the `plugins` directory of the [wiki:TracEnvironment project environment]. Also, make sure that the web server has sufficient permissions to read the plugin egg. Then restart the web server. If you are running as a [wiki:TracStandalone "tracd" standalone server], restart tracd, ie kill the process and run again.
+
+To uninstall a plugin installed this way, remove the egg from the `plugins` directory and restart the web server.
+
+**Note**: the Python version that the egg is built with *must* match the Python version with which Trac is run. For example, if you are running Trac under Python 2.6, but have upgraded your standalone Python to 2.7, the eggs won't be recognized.
+
+**Note**: in a multi-project setup, a pool of Python interpreter instances will be dynamically allocated to projects based on need; since plugins occupy a place in Python's module system, the first version of any given plugin to be loaded will be used for all projects. In other words, you cannot use different versions of a single plugin in two projects of a multi-project setup. It may be safer to install plugins for all projects (see below), and then enable them selectively on a project-by-project basis.
+
+### For all projects
+
+#### With an .egg file
+
+Some plugins, such as [TracTags](https://trac-hacks.org/wiki/TagsPlugin), are downloadable as an `.egg` file that can be installed with `easy_install` or `pip`:
+```#!sh
+$ easy_install TracTags
+$ pip install TracTags
+```
+
+If `easy_install` is not on your system, see the Requirements section above to install it. Windows users will need to add the `Scripts` directory of their Python installation (for example, `C:\Python27\Scripts`) to their `PATH` environment variable, or use the full path to `easy_install` (for example, `C:\Python27\Scripts\easy_install.py`). See [easy_install Windows notes](http://peak.telecommunity.com/DevCenter/EasyInstall#windows-notes) for more information.
+
+`pip` is included in Python 2.7.9. In earlier versions of Python it can be installed through the package manager of your OS (e.g. `apt-get install python-pip`) or using the [get_pip.py](https://pip.pypa.io/en/latest/installing.html#install-pip).
+
+If Trac reports permission errors after installing a zipped egg, and you would rather not bother providing an egg cache directory writable by the web server, you can get around it by simply unzipping the egg. Just pass `--always-unzip` to `easy_install`:
+```#!sh
+$ easy_install --always-unzip TracTags
+```
+You should end up with a directory having the same name as the zipped egg, complete with `.egg` extension, and containing its uncompressed contents.
+
+Trac also searches for plugins installed in the shared plugins directory, see TracIni#GlobalConfiguration. This is a convenient way to share the installation of plugins across several, but not all, environments.
+
+#### From source
+
+`easy_install` makes installing from source a snap. Just give it the URL to either a Subversion repository or a tarball/zip of the source:
+```#!sh
+$ easy_install https://trac-hacks.org/svn/tagsplugin/trunk
+```
+
+#### Enabling the plugin
+
+Unlike plugins installed per environment, you'll have to explicitly enable globally installed plugins via [wiki:TracIni trac.ini]. This also applies to plugins installed in the shared plugins directory, ie the path specified in the `[inherit] plugins_dir` configuration option.
+
+This is done in the `[components]` section of the configuration file `trac.ini`. For example:
+```#!ini
+[components]
+tractags.* = enabled
+```
+
+The name of the option is the Python package of the plugin. This should be specified in the documentation of the plugin, but can also be easily discovered by looking at the source: look for a top-level directory that contains a file named `__init__.py`.
+
+After installing the plugin, you must restart your web server.
+
+#### Upgrading the environment
+
+Some plugins may require an environment upgrade. This will typically be necessary for plugins that implement `IEnvironmentSetupParticipant`. Common reasons for requiring an environment upgrade are to add tables to the database or add configuration parameters to trac.ini. A notification will be displayed when accessing Trac for the first time after installing a plugin and restarting the web server. To upgrade the environment, run the command:
+
+```#!sh
+$ trac-admin /path/to/env upgrade
+```
+
+A database backup will be made before upgrading the environment, unless the `--no-backup` option is specified. For more information, refer to the documentation output by `trac-admin /path/to/env help upgrade`.
+
+#### Uninstalling
+
+Neither `easy_install` nor `python setup.py` have an uninstall feature. However, it is usually trivial to remove a globally installed egg and reference:
+
+ 1. Do `easy_install -m [plugin name]` to remove references from `$PYTHONLIB/site-packages/easy-install.pth` when the plugin installed by setuptools.
+ 1. Delete executables from `/usr/bin`, `/usr/local/bin`, or `C:\\Python*\Scripts`. To find what executables are involved, refer to the `[console-script]` section of `setup.py`.
+ 1. Delete the .egg file or folder from where it's installed, usually inside `$PYTHONLIB/site-packages/`.
+ 1. Restart the web server.
+
+If you are uncertain about the location of the egg file, you can try to locate it by replacing `myplugin` with whatever namespace the plugin uses (as used when enabling the plugin):
+```#!pycon
+>>> import myplugin
+>>> print myplugin.__file__
+/opt/local/python24/lib/site-packages/myplugin-0.4.2-py2.4.egg/myplugin/__init__.pyc
+```
+
+## Setting up the plugin cache
+
+Some plugins will need to be extracted by the Python egg's runtime (`pkg_resources`), so that their contents are actual files on the file system. The directory in which they are extracted defaults to `.python-eggs` in the home directory of the current user, which may or may not be a problem. You can, however, override the default location using the `PYTHON_EGG_CACHE` environment variable.
+
+To do this from the Apache configuration, use the `SetEnv` directive:
+```#!apache
+SetEnv PYTHON_EGG_CACHE /path/to/dir
+```
+
+This works whether you're using the [wiki:TracCgi CGI] or the [wiki:TracModPython mod_python] front-end. Put this directive next to where you set the path to the [wiki:TracEnvironment Trac environment], ie in the same `<Location>` block.
+
+For example for CGI:
+```#!apache
+ <Location /trac>
+   SetEnv TRAC_ENV /path/to/projenv
+   SetEnv PYTHON_EGG_CACHE /path/to/dir
+ </Location>
+```
+
+Or for mod_python:
+```#!apache
+ <Location /trac>
+   SetHandler mod_python
+   ...
+   SetEnv PYTHON_EGG_CACHE /path/to/dir
+ </Location>
+```
+
+**Note**: SetEnv requires the `mod_env` module, which needs to be activated for Apache. In this case the SetEnv directive can also be used in the `mod_python` Location block.
+
+For [wiki:TracFastCgi FastCGI], you'll need to `-initial-env` option, or whatever is provided by your web server for setting environment variables.
+
+**Note**: if you already use -initial-env to set the project directory for either a single project or parent, you will need to add an additional -initial-env directive to the FastCgiConfig directive:
+
+```#!apache
+FastCgiConfig -initial-env TRAC_ENV=/var/lib/trac -initial-env PYTHON_EGG_CACHE=/var/lib/trac/plugin-cache
+```
+
+### About hook scripts
+
+If you have set up some Subversion hook scripts that call the Trac engine, such as the post-commit hook script provided in the `/contrib` directory, make sure you define the `PYTHON_EGG_CACHE` environment variable within these scripts as well.
+
+## Web-based plugin administration
+
+The [trac:WebAdmin] interface offers limited support for plugin configuration through the web to users with `TRAC_ADMIN` permission:
+
+
+* en/disabling installed plugins
+* installing plugins by uploading them as eggs
+
+
+If you wish to disable the second function for security reasons, add the following to your `trac.ini` file:
+```#!ini
+[components]
+trac.admin.web_ui.PluginAdminPanel = disabled
+```
+This disables the whole panel, so the first function will no longer be available either.
+
+## Troubleshooting
+
+### Is setuptools properly installed?
+
+Try this from the command line:
+```#!sh
+$ python -c "import pkg_resources"
+```
+
+If you get **no output**, setuptools **is** installed. Otherwise, you'll need to install it before plugins will work in Trac.
+
+### Did you get the correct version of the Python egg?
+
+Python eggs have the Python version encoded in their filename. For example, `MyPlugin-1.0-py2.5.egg` is an egg for Python 2.5, and will **not** be loaded if you're running a different Python version (such as 2.4 or 2.6).
+
+Also, verify that the egg file you downloaded is indeed a .zip archive. If you downloaded it from a Trac site, chances are you downloaded the HTML preview page instead.
+
+### Is the plugin enabled?
+
+If you install a plugin globally, ie *not* inside the `plugins` directory of the Trac project environment, you must explicitly enable it in [TracIni trac.ini]. Make sure that:
+
+
+    * you actually added the necessary line(s) to the `[components]` section.
+    * the package/module names are correct and do not contain typos.
+    * the value is "enabled", not "enable" or "Enable".
+    * the section name is "components", not "component".
+
+
+### Check the permissions on the .egg file
+
+Trac must be able to read the .egg file.
+
+### Check the log files
+
+Enable [wiki:TracLogging logging] and set the log level to `DEBUG`, then watch the log file for messages about loading plugins.
+
+### Verify you have the proper permissions
+
+Some plugins require you have special permissions in order to use them. [trac:WebAdmin WebAdmin], for example, requires the user to have `TRAC_ADMIN` permissions for it to show up on the navigation bar.
+
+### Is the wrong version of the plugin loading?
+
+If you put your plugins inside plugins directories, and certainly if you have more than one project, you need to make sure that the correct version of the plugin is loading. Here are some basic rules:
+
+
+    * Only one version of the plugin can be loaded for each running Trac server, ie each Python process. The Python namespaces and module list will be shared, and it cannot handle duplicates. Whether a plugin is `enabled` or `disabled` makes no difference.
+    * A globally installed plugin (typically `setup.py install`) will override any version in the global or project plugins directories. A plugin from the global plugins directory will be located *before* any project plugins directory.
+    * If your Trac server hosts more than one project (as with `TRAC_ENV_PARENT_DIR` setups), having two versions of a plugin in two different projects will give unpredicatable results. Only one of them will load, and the one loaded will be shared by both projects. Trac will load the first plugin found, usually from the project that receives the first request.
+    * Having more than one version listed inside Python site-packages is fine, ie installed with `setup.py install`, because setuptools will make sure you get the version installed most recently. However, don't store more than one version inside a global or project plugins directory: neither the version number nor the installed date will matter at all. There is no way to determine which one will be located first when Trac searches the directory for plugins.
+
+
+### If all of the above failed
+
+Okay, so the logs don't mention plugins, the egg is readable, the Python version is correct, *and* the egg has been installed globally (and is enabled in trac.ini)... and it *still* doesn't work or give any error messages or any other indication as to why. Hop on the [trac:IrcChannel IrcChannel] and ask away!
+
+----
+See also TracGuide, [trac:PluginList plugin list], [trac:TracDev/ComponentArchitecture component architecture].
diff --git a/raw-wiki-dump/TracQuery.md b/raw-wiki-dump/TracQuery.md
new file mode 100644
index 0000000..5c64a7e
--- /dev/null
+++ b/raw-wiki-dump/TracQuery.md
@@ -0,0 +1,118 @@
+# Trac Ticket Queries
+[[TracGuideToc]]
+
+In addition to [wiki:TracReports reports], Trac provides support for *custom ticket queries*, which can be used to display tickets that meet specified criteria.
+
+To configure and execute a custom query, switch to the *View Tickets* module from the navigation bar, and select the *Custom Query* link.
+
+## Filters
+
+When you first go to the query page, the default filter will display tickets relevant to you:
+
+    * If logged in then all open tickets, it will display open tickets assigned to you.
+    * If not logged in but you have specified a name or email address in the preferences, then it will display all open tickets where your email (or name if email not defined) is in the CC list.
+    * If not logged in and no name/email is defined in the preferences, then all open issues are displayed.
+
+
+Current filters can be removed by clicking the button to the left with the minus sign on the label. New filters are added from the pulldown lists at the bottom corners of the filters box; 'And' conditions on the left, 'Or' conditions on the right.  Filters with either a text box or a pulldown menu of options can be added multiple times to perform an *Or* on the criteria.
+
+You can use the fields just below the filters box to group the results based on a field, or display the full description for each ticket.
+
+After you have edited your filters, click the *Update* button to refresh your results.
+
+Some shortcuts can be used to manipulate //checkbox// filters.
+
+* Clicking on a filter row label toggles all checkboxes.
+* Pressing the modifier key while clicking on a filter row label inverts the state of all checkboxes.
+* Pressing the modifier key while clicking on a checkbox selects the checkbox and deselects all other checkboxes in the filter.
+
+
+The modifier key is platform and browser dependent. On Mac the modified key is Option/Alt or Command. On Linux the modifier key is Ctrl + Alt. Opera on Windows seems to use Ctrl + Alt, while Alt is effective for other Windows browsers.
+
+## Navigating Tickets
+
+Clicking on one of the query results will take you to that ticket. You can navigate through the results by clicking the *Next Ticket* or *Previous Ticket* links just below the main menu bar, or click the *Back to Query* link to return to the query page.
+
+You can safely edit any of the tickets and continue to navigate through the results using the *Next/Previous/Back to Query* links after saving your results. When you return to the query *any tickets which were edited* will be displayed with italicized text. If one of the tickets was edited such that [[html(<span style="color: grey">it no longer matches the query criteria </span>)]], the text will also be greyed. Lastly, if **a new ticket matching the query criteria has been created**, it will be shown in bold.
+
+The query results can be refreshed and cleared of these status indicators by clicking the *Update* button again.
+
+## Saving Queries
+
+Trac allows you to save the query as a named query accessible from the reports module. To save a query ensure that you have *Updated* the view and then click the *Save query* button displayed beneath the results.
+You can also save references to queries in Wiki content, as described below.
+
+**Note:** one way to easily build queries like the ones below, you can build and test the queries in the Custom report module and when ready - click *Save query*. This will build the query string for you. All you need to do is remove the extra line breaks.
+
+**Note:** you must have the **REPORT_CREATE** permission in order to save queries to the list of default reports. The *Save query* button will only appear if you are logged in as a user that has been granted this permission. If your account does not have permission to create reports, you can still use the methods below to save a query.
+
+### Using TracLinks
+
+You may want to save some queries so that you can come back to them later. You can do this by making a link to the query from any Wiki page.
+```
+[query:status=new|assigned|reopened&version=1.0 Active tickets against 1.0]
+```
+
+Which is displayed as:
+  [query:status=new|assigned|reopened&version=1.0 Active tickets against 1.0]
+
+This uses a very simple query language to specify the criteria, see [wiki:TracQuery#QueryLanguage Query Language].
+
+Alternatively, you can copy the query string of a query and paste that into the Wiki link, including the leading `?` character:
+```
+[query:?status=new&status=assigned&status=reopened&group=owner Assigned tickets by owner]
+```
+
+Which is displayed as:
+  [query:?status=new&status=assigned&status=reopened&group=owner Assigned tickets by owner]
+
+### Customizing the *table* format
+
+You can also customize the columns displayed in the table format (*format=table*) by using *col=<field>*. You can specify multiple fields and what order they are displayed in by placing pipes (`|`) between the columns:
+```
+[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter)]]
+```
+
+This is displayed as:
+[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter)]]
+
+#### Full rows
+
+In *table* format you can also have full rows by using *rows=<field>*:
+```
+[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]]
+```
+
+This is displayed as:
+[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]]
+
+## Query Language
+
+`query:` TracLinks and the `[[TicketQuery]]` macro both use a mini “query language” for specifying query filters. Filters are separated by ampersands (`&`). Each filter consists of the ticket field name, an operator and one or more values. More than one value are separated by a pipe (`|`), meaning that the filter matches any of the values. To include a literal `&` or `|` in a value, escape the character with a backslash (`\`).
+
+The available operators are:
+| **`=`** | the field content exactly matches one of the values |
+|---|---|
+| **`~=`** | the field content contains one or more of the values |
+| **`^=`** | the field content starts with one of the values |
+| **`$=`** | the field content ends with one of the values |
+
+
+All of these operators can also be negated:
+| **`!=`** | the field content matches none of the values |
+|---|---|
+| **`!~=`** | the field content does not contain any of the values |
+| **`!^=`** | the field content does not start with any of the values |
+| **`!$=`** | the field content does not end with any of the values |
+
+
+The date fields `created` and `modified` can be constrained by using the `=` operator and specifying a value containing two dates separated by two dots (`..`). Either end of the date range can be left empty, meaning that the corresponding end of the range is open. The date parser understands a few natural date specifications like "3 weeks ago", "last month" and "now", as well as Bugzilla-style date specifications like "1d", "2w", "3m" or "4y" for 1 day, 2 weeks, 3 months and 4 years, respectively. Spaces in date specifications can be omitted to avoid having to quote the query string.
+| **`created=2007-01-01..2008-01-01`** | query tickets created in 2007 |
+|---|---|
+| **`created=lastmonth..thismonth`** | query tickets created during the previous month |
+| **`modified=1weekago..`** | query tickets that have been modified in the last week |
+| **`modified=..30daysago`** | query tickets that have been inactive for the last 30 days |
+
+
+----
+See also: TracTickets, TracReports, TracGuide, TicketQuery
diff --git a/raw-wiki-dump/TracReports.md b/raw-wiki-dump/TracReports.md
new file mode 100644
index 0000000..0e9467b
--- /dev/null
+++ b/raw-wiki-dump/TracReports.md
@@ -0,0 +1,338 @@
+# Trac Reports
+[[TracGuideToc]]
+
+The Trac reports module provides a simple, yet powerful reporting facility
+to present information about tickets in the Trac database.
+
+Rather than have its own report definition format, TracReports relies on standard SQL
+`SELECT` statements for custom report definition.
+
+  **Note:** *The report module is being phased out in its current form because it seriously limits the ability of the Trac team to make adjustments to the underlying database schema. We believe that the [wiki:TracQuery query module] is a good replacement that provides more flexibility and better usability. While there are certain reports that cannot yet be handled by the query module, we intend to further enhance it so that at some point the reports module can be completely removed. This also means that there will be no major enhancements to the report module anymore.*
+
+  *You can already completely replace the reports module by the query module simply by disabling the former in [wiki:TracIni trac.ini]:*
+  ```
+  [components]
+  trac.ticket.report.* = disabled
+  ```
+  *This will make the query module the default handler for the “View Tickets” navigation item. We encourage you to try this configuration and report back what kind of features of reports you are missing, if any.*
+
+A report consists of these basic parts:
+
+    * **ID** — Unique (sequential) identifier
+    * **Title** — Descriptive title
+    * **Description** — A brief description of the report, in WikiFormatting text.
+    * **Report Body** — List of results from report query, formatted according to the methods described below.
+    * **Footer** — Links to alternative download formats for this report.
+
+
+## Changing Sort Order
+Simple reports - ungrouped reports to be specific - can be changed to be sorted by any column simply by clicking the column header.
+
+If a column header is a hyperlink (red), click the column you would like to sort by. Clicking the same header again reverses the order.
+
+## Changing Report Numbering
+There may be instances where you need to change the ID of the report, perhaps to organize the reports better. At present this requires changes to the trac database. The *report* table has the following schema:
+
+    * id integer PRIMARY KEY
+    * author text
+    * title text
+    * query text
+    * description text
+
+Changing the ID changes the shown order and number in the *Available Reports* list and the report's perma-link. This is done by running something like:
+```
+update report set id=5 where id=3;
+```
+Keep in mind that the integrity has to be maintained (i.e., ID has to be unique, and you don't want to exceed the max, since that's managed by SQLite someplace).
+
+You may also need to update or remove the report number stored in the report or query.
+
+## Navigating Tickets
+Clicking on one of the report results will take you to that ticket. You can navigate through the results by clicking the *Next Ticket* or *Previous Ticket* links just below the main menu bar, or click the *Back to Report* link to return to the report page.
+
+You can safely edit any of the tickets and continue to navigate through the results using the *Next/Previous/Back to Report* links after saving your results, but when you return to the report, there will be no hint about what has changed, as would happen if you were navigating a list of tickets obtained from a query (see TracQuery#NavigatingTickets).
+
+## Alternative Download Formats
+Aside from the default HTML view, reports can also be exported in a number of alternative formats.
+At the bottom of the report page, you will find a list of available data formats. Click the desired link to
+download the alternative report format.
+
+### Comma-delimited - CSV (Comma Separated Values)
+Export the report as plain text, each row on its own line, columns separated by a single comma (',').
+**Note:** The output is fully escaped so carriage returns, line feeds, and commas will be preserved in the output.
+
+### Tab-delimited
+Like above, but uses tabs (\t) instead of comma.
+
+### RSS - XML Content Syndication
+All reports support syndication using XML/RSS 2.0. To subscribe to an RSS feed, click the orange 'XML' icon at the bottom of the page. See TracRss for general information on RSS support in Trac.
+
+----
+
+## Creating Custom Reports
+
+*Creating a custom report requires a comfortable knowledge of SQL.*
+
+**Note that you need to set up [TracPermissions#Reports permissions] in order to see the buttons for adding or editing reports.**
+
+A report is basically a single named SQL query, executed and presented by
+Trac.  Reports can be viewed and created from a custom SQL expression directly
+in the web interface.
+
+Typically, a report consists of a SELECT-expression from the 'ticket' table,
+using the available columns and sorting the way you want it.
+
+## Ticket columns
+The *ticket* table has the following columns:
+
+    * id
+    * type
+    * time
+    * changetime
+    * component
+    * severity
+    * priority
+    * owner
+    * reporter
+    * cc
+    * version
+    * milestone
+    * status
+    * resolution
+    * summary
+    * description
+    * keywords
+
+
+See TracTickets for a detailed description of the column fields.
+
+Example: **All active tickets, sorted by priority and time**
+```
+SELECT id AS ticket, status, severity, priority, owner,
+       time AS created, summary FROM ticket
+  WHERE status IN ('new', 'assigned', 'reopened')
+  ORDER BY priority, time
+```
+
+Dynamic variables can also be used in the report title and description (since 1.1.1).
+
+## Advanced Reports: Dynamic Variables
+For more flexible reports, Trac supports the use of *dynamic variables* in report SQL statements.
+In short, dynamic variables are *special* strings that are replaced by custom data before query execution.
+
+### Using Variables in a Query
+The syntax for dynamic variables is simple, any upper case word beginning with '$' is considered a variable.
+
+Example:
+```
+SELECT id AS ticket,summary FROM ticket WHERE priority=$PRIORITY
+```
+
+To assign a value to $PRIORITY when viewing the report, you must define it as an argument in the report URL, leaving out the leading '$'.
+
+Example:
+```
+ http://trac.edgewall.org/reports/14?PRIORITY=high
+```
+
+To use multiple variables, separate them with an '&'.
+
+Example:
+```
+ http://trac.edgewall.org/reports/14?PRIORITY=high&SEVERITY=critical
+```
+
+
+### Special/Constant Variables
+There is one dynamic variable whose value is set automatically (the URL does not have to be changed) to allow practical reports.
+
+
+    * $USER — Username of logged in user.
+
+
+Example (*List all tickets assigned to me*):
+```
+SELECT id AS ticket,summary FROM ticket WHERE owner=$USER
+```
+
+
+
+## Advanced Reports: Custom Formatting
+Trac is also capable of more advanced reports, including custom layouts,
+result grouping and user-defined CSS styles. To create such reports, we'll use
+specialized SQL statements to control the output of the Trac report engine.
+
+### Special Columns
+To format reports, TracReports looks for 'magic' column names in the query
+result. These 'magic' names are processed and affect the layout and style of the
+final report.
+
+### Automatically formatted columns
+
+    * **ticket** — Ticket ID number. Becomes a hyperlink to that ticket.
+    * **id** — same as **ticket** above when **realm** is not set
+    * **realm** — together with **id**, can be used to create links to other resources than tickets (e.g. a realm of *wiki* and an *id* to a page name will create a link to that wiki page)
+        - for some kind of resources, it may be necessary to specify their *parent* resources (e.g. for *changeset*, which *repos*) and this can be achieved using the **parent_realm** and **parent_id** columns
+    * **created, modified, date, time** — Format cell as a date and/or time.
+    * **description** — Ticket description field, parsed through the wiki engine.
+
+
+**Example:**
+```
+SELECT id AS ticket, created, status, summary FROM ticket
+```
+
+Those columns can also be defined but marked as hidden, see [#column-syntax below].
+
+See trac:wiki/CookBook/Configuration/Reports for some example of creating reports for realms other than *ticket*.
+
+### Custom formatting columns
+Columns whose names begin and end with 2 underscores (Example: **`__color__`**) are
+assumed to be *formatting hints*, affecting the appearance of the row.
+
+
+    * **`__group__`** — Group results based on values in this column. Each group will have its own header and table.
+    * **`__grouplink__`** — Make the header of each group a link to the specified URL. The URL is taken from the first row of each group.
+    * **`__color__`** — Should be a numeric value ranging from 1 to 5 to select a pre-defined row color. Typically used to color rows by issue priority.
+```
+#!html
+<div style="margin-left:7.5em">Defaults:
+<span style="border: none; color: #333; background: transparent;  font-size: 85%; background: #fdc; border-color: #e88; color: #a22">Color 1</span>
+<span style="border: none; color: #333; background: transparent;  font-size: 85%; background: #ffb; border-color: #eea; color: #880">Color 2</span>
+<span style="border: none; color: #333; background: transparent;  font-size: 85%; background: #fbfbfb; border-color: #ddd; color: #444">Color 3</span>
+<span style="border: none; color: #333; background: transparent; font-size: 85%; background: #e7ffff; border-color: #cee; color: #099">Color 4</span>
+<span style="border: none; color: #333; background: transparent;  font-size: 85%; background: #e7eeff; border-color: #cde; color: #469">Color 5</span>
+</div>
+
+```
+
+    * **`__style__`** — A custom CSS style expression to use on the `<tr>` element of the current row.
+    * **`__class__`** — Zero or more space-separated CSS class names to be set on the `<tr>` element of the current row. These classes are added to the class name derived from `__color__` and the odd / even indicator.
+
+
+**Example:** *List active tickets, grouped by milestone, group header linked to milestone page, colored by priority*
+```
+SELECT p.value AS __color__,
+     t.milestone AS __group__,
+     '../milestone/' || t.milestone AS __grouplink__,
+     (CASE owner WHEN 'daniel' THEN 'font-weight: bold; background: red;' ELSE '' END) AS __style__,
+       t.id AS ticket, summary
+  FROM ticket t,enum p
+  WHERE t.status IN ('new', 'assigned', 'reopened')
+    AND p.name=t.priority AND p.type='priority'
+  ORDER BY t.milestone, p.value, t.severity, t.time
+```
+
+**Note:** A table join is used to match *ticket* priorities with their
+numeric representation from the *enum* table.
+
+### Changing layout of report rows === #column-syntax
+By default, all columns on each row are display on a single row in the HTML
+report, possibly formatted according to the descriptions above. However, it's
+also possible to create multi-line report entries.
+
+
+    * **`column_`** — *Break row after this*. By appending an underscore ('_') to the column name, the remaining columns will be continued on a second line.
+
+
+
+    * **`_column_`** — *Full row*. By adding an underscore ('_') both at the beginning and the end of a column name, the data will be shown on a separate row.
+
+
+
+    * **`_column`** — *Hide data*. Prepending an underscore ('_') to a column name instructs Trac to hide the contents from the HTML output. This is useful for information to be visible only if downloaded in other formats (like CSV or RSS/XML).
+
+   This can be used to hide any kind of column, even important ones required for identifying the resource, e.g. `id as _id` will hide the **Id** column but the link to the ticket will be present.
+
+**Example:** *List active tickets, grouped by milestone, colored by priority, with  description and multi-line layout*
+
+```
+SELECT p.value AS __color__,
+       t.milestone AS __group__,
+       (CASE owner
+          WHEN 'daniel' THEN 'font-weight: bold; background: red;'
+          ELSE '' END) AS __style__,
+       t.id AS ticket, summary AS summary_,             -- ## Break line here
+       component,version, severity, milestone, status, owner,
+       time AS created, changetime AS modified,         -- ## Dates are formatted
+       description AS _description_,                    -- ## Uses a full row
+       changetime AS _changetime, reporter AS _reporter -- ## Hidden from HTML output
+  FROM ticket t,enum p
+  WHERE t.status IN ('new', 'assigned', 'reopened')
+    AND p.name=t.priority AND p.type='priority'
+  ORDER BY t.milestone, p.value, t.severity, t.time
+```
+
+### Reporting on custom fields
+
+If you have added custom fields to your tickets (see TracTicketsCustomFields), you can write a SQL query to cover them. You'll need to make a join on the ticket_custom table, but this isn't especially easy.
+
+If you have tickets in the database *before* you declare the extra fields in trac.ini, there will be no associated data in the ticket_custom table. To get around this, use SQL's "LEFT OUTER JOIN" clauses. See [trac:TracIniReportCustomFieldSample TracIniReportCustomFieldSample] for some examples.
+
+### A note about SQL rewriting #rewriting
+
+Beyond the relatively trivial replacement of dynamic variables, the SQL query is also altered in order to support two features of the reports:
+ 1. [#sort-order changing the sort order]
+ 2. pagination support (limitation of the number of result rows displayed on each page)
+In order to support the first feature, the sort column is inserted in the `ORDER BY` clause in the first position or in the second position if a `__group__` column is specified (an `ORDER BY` clause is created if needed). In order to support pagination, a `LIMIT ... OFFSET ...` clause is appended.
+The query might be too complex for the automatic rewrite to work correctly, resulting in an erroneous query. In this case you still have the possibility to control exactly how the rewrite is done by manually inserting the following tokens:
+
+    - `@SORT_COLUMN@`, the place where the name of the selected sort column will be inserted,
+    - `@LIMIT_OFFSET@`, the place where the pagination support clause will be added
+
+Note that if you write them after an SQL comment, `--`, you'll effectively disable rewriting if this is what you want!
+
+Let's take an example, consider the following SQL query:
+```
+-- ## 4: Assigned, Active Tickets by Owner ## --
+
+--
+-- List assigned tickets, group by ticket owner, sorted by priority.
+--
+
+SELECT p.value AS __color__,
+   owner AS __group__,
+   id AS ticket, summary, component, milestone, t.type AS type, severity, time AS created,
+   changetime AS _changetime, description AS _description,
+   reporter AS _reporter
+  FROM ticket t,enum p
+  WHERE status = 'assigned'
+AND p.name=t.priority AND p.type='priority'
+  ORDER BY __group__, p.value, severity, time
+```
+
+The automatic rewrite will be the following (4 rows per page, page 2, sorted by `component`):
+```
+SELECT p.value AS __color__,
+   owner AS __group__,
+   id AS ticket, summary, component, milestone, t.type AS type, severity, time AS created,
+   changetime AS _changetime, description AS _description,
+   reporter AS _reporter
+  FROM ticket t,enum p
+  WHERE status = 'assigned'
+AND p.name=t.priority AND p.type='priority'
+  ORDER BY __group__ ASC, `component` ASC,  __group__, p.value, severity, time
+ LIMIT 4 OFFSET 4
+```
+
+The equivalent SQL query with the rewrite tokens would have been:
+```
+SELECT p.value AS __color__,
+   owner AS __group__,
+   id AS ticket, summary, component, milestone, t.type AS type, severity, time AS created,
+   changetime AS _changetime, description AS _description,
+   reporter AS _reporter
+  FROM ticket t,enum p
+  WHERE status = 'assigned'
+AND p.name=t.priority AND p.type='priority'
+  ORDER BY __group__, @SORT_COLUMN@, p.value, severity, time
+@LIMIT_OFFSET@
+```
+
+If you want to always sort first by priority and only then by the user selected sort column, simply use the following `ORDER BY` clause:
+```
+  ORDER BY __group__, p.value, @SORT_COLUMN@, severity, time
+```
+
+----
+See also: TracTickets, TracQuery, TracGuide, [Query Language Understood by SQLite](http://www.sqlite.org/lang_expr.html)
diff --git a/raw-wiki-dump/TracRepositoryAdmin.md b/raw-wiki-dump/TracRepositoryAdmin.md
new file mode 100644
index 0000000..ba3a1f6
--- /dev/null
+++ b/raw-wiki-dump/TracRepositoryAdmin.md
@@ -0,0 +1,226 @@
+# Repository Administration
+[[PageOutline(2-3)]]
+
+## Quick start #QuickStart
+
+
+    * Enable the repository connector(s) for the version control system(s) that you will use.
+    * Add repositories through the //Repositories// admin panel, with `trac-admin` or in the `[repositories]` section of [wiki:TracIni#repositories-section trac.ini].
+    * Set up a call to `trac-admin $ENV changeset added $REPO $REV` in the post-commit hook of each repository. Additionally, add a call to `trac-admin $ENV changeset modified $REPO $REV` in the post-revprop-change hook of repositories allowing revision property changes.
+    * Make sure the user under which your hooks are run has write access to the Trac environment, or use a tool like `sudo` to temporarily elevate privileges.
+
+
+## Enabling the components
+
+Support for version control systems is provided by optional components distributed with Trac, which are disabled by default //(since 1.0)//. Subversion and Git must be explicitly enabled if you wish to use them.
+
+The version control systems can be enabled by adding the following to the `[components]` section of your [TracIni#components-section trac.ini], or enabling the components in the //Plugins// admin panel.
+
+```#!ini
+tracopt.versioncontrol.svn.* = enabled
+```
+
+```#!ini
+tracopt.versioncontrol.git.* = enabled
+```
+
+## Specifying repositories #Repositories
+Trac supports multiple repositories per environment, and the repositories may be for different version control system types. Each repository must be defined in a repository configuration provider, the two supported by default are the [#ReposDatabase database store] and the [#ReposTracIni trac.ini configuration file]. A repository should not be defined in multiple configuration providers.
+
+It is possible to define aliases of repositories, that act as "pointers" to real repositories. This can be useful when renaming a repository, to avoid breaking links to the old name.
+
+A number of attributes can be associated with each repository. The attributes define the repository's location, type, name and how it is displayed in the source browser. The following attributes are supported:
+
+|**Attribute** |**Description** |
+|---|---|
+|`alias` |\
+|A repository having an `alias` attribute is an alias to a real repository. All TracLinks referencing the alias resolve to the aliased repository. Note that multiple indirection is not supported, so an alias must always point to a real repository. The `alias` and `dir` attributes are mutually exclusive. |
+|`description` |\
+|The text specified in the `description` attribute is displayed below the top-level entry for the repository in the source browser. It supports WikiFormatting. |
+|`dir` |\
+|The `dir` attribute specifies the location of the repository in the filesystem. It corresponds to the value previously specified in the option `[trac] repository_dir`. The `alias` and `dir` attributes are mutually exclusive. |
+|`hidden` |When set to `true`, the repository is hidden from the repository index page in the source browser. Browsing the repository is still possible, and links referencing the repository remain valid. |
+|`sync_per_request`|When set to `true` the repository will be synced on every request. This is not recommended, instead a post-commit hook should be configured to provide [#ExplicitSync explicit synchronization] and `sync_per_request` should be set to `false`.|
+|`type` |The `type` attribute sets the type of version control system used by the repository. Trac supports Subversion and Git out-of-the-box, and plugins add support for many other systems. If `type` is not specified, it defaults to the value of the `[trac] repository_type` option. |
+|`url` |The `url` attribute specifies the root URL to be used for checking out from the repository. When specified, a "Repository URL" link is added to the context navigation links in the source browser, that can be copied into the tool used for creating the working copy. |
+
+
+A repository `name` and one of `alias` or `dir` attributes are mandatory. All others are optional.
+
+For some version control systems, it is possible to specify not only the path to the repository in the `dir` attribute, but also a *scope* within the repository. Trac will then only show information related to the files and changesets below that scope. The Subversion backend for Trac supports this. For other types, check the corresponding plugin's documentation.
+
+After adding a repository, the cache for that repository must be re-synchronized once with the `trac-admin $ENV repository resync` command.
+
+ `repository resync <repos>`::
+   Re-synchronize Trac with a repository.
+
+
+### In `trac.ini` #ReposTracIni
+Repositories and repository attributes can be specified in the `[repositories]` section of [wiki:TracIni#repositories-section trac.ini]. Every attribute consists of a key structured as `{name}.{attribute}` and the corresponding value separated with an equal sign (`=`). The name of the default repository is empty.
+
+The main advantage of specifying repositories in `trac.ini` is that they can be inherited from a global configuration (see the [wiki:TracIni#GlobalConfiguration global configuration] section of TracIni). One drawback is that, due to limitations in the `ConfigParser` class used to parse `trac.ini`, the repository name is always all-lowercase.
+
+The following example defines two Subversion repositories named `project` and `lib`, and an alias to `project` as the default repository. This is a typical use case where a Trac environment previously had a single repository (the `project` repository), and was converted to multiple repositories. The alias ensures that links predating the change continue to resolve to the `project` repository.
+```#!ini
+[repositories]
+project.dir = /var/repos/project
+project.description = This is the ''main'' project repository.
+project.type = svn
+project.url = http://example.com/svn/project
+project.hidden = true
+
+lib.dir = /var/repos/lib
+lib.description = This is the secondary library code.
+lib.type = svn
+lib.url = http://example.com/svn/lib
+
+.alias = project
+```
+Note that `name.alias = target` makes `name` an alias for the `target` repo, not the other way around.
+
+### In the database #ReposDatabase
+Repositories can also be specified in the database, using either the "Repositories" admin panel under "Version Control", or the `trac-admin $ENV repository` commands.
+
+The admin panel shows the list of all repositories defined in the Trac environment. It allows adding repositories and aliases, editing repository attributes and removing repositories. Note that repositories defined in `trac.ini` are displayed but cannot be edited.
+
+The following [wiki:TracAdmin trac-admin] commands can be used to perform repository operations from the command line.
+
+ `repository add <repos> <dir> [type]`::
+   Add a repository `<repos>` located at `<dir>`, and optionally specify its type.
+
+ `repository alias <name> <target>`::
+   Create an alias `<name>` for the repository `<target>`.
+
+ `repository remove <repos>`::
+   Remove the repository `<repos>`.
+
+ `repository set <repos> <key> <value>`::
+   Set the attribute `<key>` to `<value>` for the repository `<repos>`.
+
+Note that the default repository has an empty name, so it will likely need to be quoted when running `trac-admin` from a shell. Alternatively, the name "`(default)`" can be used instead, for example when running `trac-admin` in interactive mode.
+
+## Repository caching
+
+The Subversion and Git repository connectors support caching, which improves the performance browsing the repository, viewing logs and viewing changesets. Cached repositories must be [#Synchronization synchronized]; either explicit or implicit synchronization can be used. When searching changesets, only cached repositories are searched.
+
+Subversion repositories are cached unless the type is `direct-svnfs`. Git repositories are cached when `[git]` [wiki:TracIni#git-section cached_repository] is `true`.
+
+## Repository synchronization #Synchronization
+Prior to 0.12, Trac synchronized its cache with the repository on every HTTP request. This approach is not very efficient and not practical anymore with multiple repositories. For this reason, explicit synchronization through post-commit hooks was added.
+
+There is also new functionality in the form of a repository listener extension point *(IRepositoryChangeListener)* that is triggered by the post-commit hook when a changeset is added or modified, and can be used by plugins to perform actions on commit.
+
+### Mercurial Repositories
+Please note that at the time of writing, no initial resynchronization or any hooks are necessary for Mercurial repositories - see [trac:#9485] for more information.
+
+### Explicit synchronization #ExplicitSync
+This is the preferred method of repository synchronization. It requires setting the `sync_per_request` attribute to `false`, and adding a call to `trac-admin` in the `post-commit` hook of each repository. Additionally, if a repository allows changing revision metadata, a call to `trac-admin` must be added to the `post-revprop-change` hook as well.
+
+ `changeset added <repos> <rev> [...]`::
+   Notify Trac that one or more changesets have been added to a repository.
+
+ `changeset modified <repos> <rev> [...]`::
+   Notify Trac that metadata on one or more changesets in a repository has been modified.
+
+The `<repos>` argument can be either a repository name (use "`(default)`" for the default repository) or the path to the repository.
+
+Note that you may have to set the environment variable `PYTHON_EGG_CACHE` to the same value as was used for the web server configuration before calling `trac-admin`, if you changed it from its default location. See [wiki:TracPlugins Trac Plugins] for more information.
+
+#### Subversion
+
+The following examples are complete post-commit and post-revprop-change scripts for Subversion. They should be edited for the specific environment, marked executable (where applicable) and placed in the `hooks` directory of each repository. On Unix (`post-commit`):
+```#!sh
+#!/bin/sh
+export PYTHON_EGG_CACHE="/path/to/dir"
+/usr/bin/trac-admin /path/to/env changeset added "$1" "$2"
+```
+Note: Check with `whereis trac-admin`, whether `trac-admin` is really installed under `/usr/bin/` or maybe under `/usr/local/bin/` and adapt the path.
+On Windows (`post-commit.cmd`):
+```#!bat
+@C:\Python26\Scripts\trac-admin.exe C:\path\to\env changeset added "%1" "%2"
+```
+
+The post-revprop-change hook for Subversion is very similar. On Unix (`post-revprop-change`):
+```#!sh
+#!/bin/sh
+export PYTHON_EGG_CACHE="/path/to/dir"
+/usr/bin/trac-admin /path/to/env changeset modified "$1" "$2"
+```
+On Windows (`post-revprop-change.cmd`):
+```#!bat
+@C:\Python26\Scripts\trac-admin.exe C:\path\to\env changeset modified "%1" "%2"
+```
+
+The Unix variants above assume that the user running the Subversion commit has write access to the Trac environment, which is the case in the standard configuration where both the repository and Trac are served by the web server. If you access the repository through another means, for example `svn+ssh://`, you may have to run `trac-admin` with different privileges, for example by using `sudo`.
+
+Note that calling `trac-admin` in your Subversion hooks can slow down the commit and log editing operations on the client side. You might want to use the [trac:source:trunk/contrib/trac-svn-hook contrib/trac-svn-hook] script which starts `trac-admin` in an asynchronous way. The script also comes with a number of safety checks and usage advices which should make it easier to set up and test your hooks. There's no equivalent `trac-svn-hook.bat` for Windows yet, but the script can be run by Cygwin's bash.
+
+See the [section about hooks](http://svnbook.red-bean.com/en/1.5/svn.reposadmin.create.html#svn.reposadmin.create.hooks) in the Subversion book for more information. Other repository types will require different hook setups.
+
+#### Git
+
+Git hooks can be used in the same way for explicit syncing of Git repositories.  If your git repository is one that gets committed to directly on the machine that hosts trac, add the following to the `hooks/post-commit` file in your git repo (note: this will do nothing if you only update the repo by pushing to it):
+```#!sh
+#!/bin/sh
+REV=$(git rev-parse HEAD)
+trac-admin /path/to/env changeset added <repos> $REV
+```
+
+Alternately, if your repository is one that only gets pushed to, add the following to the `hooks/post-receive` file in the repo:
+```#!sh
+#!/bin/sh
+tracenv=/path/to/env     # change with your Trac environment's path
+repos=                   # change with your repository's name
+while read oldrev newrev refname; do
+    if [ "$oldrev" = 0000000000000000000000000000000000000000 ]; then
+        git rev-list --reverse "$newrev" --
+    else
+        git rev-list --reverse "$newrev" "^$oldrev" --
+    fi | xargs trac-admin "$tracenv" changeset added "$repos"
+done
+```
+
+The `<repos>` argument can be either a repository name (use "`(default)`" for the default repository) or the path to the repository.
+
+#### Mercurial
+
+For Mercurial, add the following entries to the `.hgrc` file of each repository accessed by Trac (if [trac:TracMercurial] is installed in a Trac `plugins` directory, download [trac:source:mercurial-plugin/tracext/hg/hooks.py hooks.py] and place it somewhere accessible):
+```#!ini
+[hooks]
+; If mercurial-plugin is installed globally
+commit = python:tracext.hg.hooks.add_changesets
+changegroup = python:tracext.hg.hooks.add_changesets
+
+; If mercurial-plugin is installed in a Trac plugins directory
+commit = python:/path/to/hooks.py:add_changesets
+changegroup = python:/path/to/hooks.py:add_changesets
+
+[trac]
+env = /path/to/env
+trac-admin = /path/to/trac-admin
+```
+
+### Per-request synchronization #PerRequestSync
+If the post-commit hooks are not available, the environment can be set up for per-request synchronization. In that case, the `sync_per_request` attribute for each repository in the database and in [wiki:TracIni#trac-section trac.ini] must be set to `false`.
+
+Note that in this case, the changeset listener extension point is not called, and therefore plugins using it will not work correctly.
+
+## Automatic changeset references in tickets
+
+You can automatically add a reference to the changeset as a ticket comment whenever changes are committed to the repository. The description of the commit needs to contain one of the following formulas:
+
+    * **`Refs #123`** - to reference this changeset in `#123` ticket
+    * **`Fixes #123`** - to reference this changeset and close `#123` ticket with the default status *fixed*
+
+
+This functionality requires installing a post-commit hook as described in [#ExplicitSync], and enabling the optional commit updater components by adding the following line to the `[components]` section of your [wiki:TracIni#components-section trac.ini], or enabling the components in the //Plugins// admin panel.
+```#!ini
+tracopt.ticket.commit_updater.* = enabled
+```
+For more information, see the documentation of the `CommitTicketUpdater` component in the //Plugins// admin panel and the [trac:CommitTicketUpdater] page.
+
+## Troubleshooting
+
+### My trac-post-commit-hook doesn't work anymore #trac-post-commit-hook
+
+You must now use the optional components from `tracopt.ticket.commit_updater.*`, which you can activate through the Plugins panel in the Administrative part of the web interface, or by directly modifying the [TracIni#components-section "[components]"] section in the trac.ini. Be sure to use [#ExplicitSync explicit synchronization] as explained above.
diff --git a/raw-wiki-dump/TracRevisionLog.md b/raw-wiki-dump/TracRevisionLog.md
new file mode 100644
index 0000000..0957211
--- /dev/null
+++ b/raw-wiki-dump/TracRevisionLog.md
@@ -0,0 +1,73 @@
+# Viewing Revision Logs
+[[TracGuideToc]]
+
+When you browse the repository, it is always possible to view the *Revision Log* that corresponds to the repository path. This displays a list of the most recent changesets in which the current path or any other path below it has been modified.
+
+## The Revision Log Form
+
+It is possible to set the revision at which the revision log should start, using the *View log starting at* field. An empty value or a value of *head* is interpreted as the newest changeset.
+
+It is also possible to specify the revision at which the log should stop, using the *Back to* field. By default it is empty,
+which means the revision log will show the latest 100 revisions.
+
+Also, there are three modes of operation of the revision log.
+
+By default, the revision log *stops on copy*, which means that whenever an *Add*, *Copy* or *Rename* operation is detected, no older revision will be shown. That's very convenient when working with branches, as one only sees the history corresponding to what has been done on the branch.
+
+It is also possible to indicate that one wants to see what happened before a *Copy* or *Rename* change, by selecting the
+*Follow copies* mode. This will cross all copies or renames changes.
+Each time the name of the path changes, there will be an additional indentation level. That way, the changes on the different paths are easily grouped together visually.
+
+It is even possible to go past an *Add* change, in order to see if there has been a *Delete* change on that path, before
+that *Add*. This mode corresponds to the mode called *Show only adds, moves and deletes*. This operation can be quite resource intensive and therefore take some time to be shown on screen.
+
+Finally, there's also a checkbox *Show full log messages*, which controls whether the full content of the commit log message
+should be displayed for each change, or only a shortened version of it.
+
+## The Revision Log Information
+
+For each revision log entry, the following columns are displayed:
+ 1. The first column contains a pair of radio buttons and should be used
+    for selecting the *old* and the *new* revisions that will be
+    used for [wiki:TracRevisionLog#viewingtheactualchanges viewing the actual changes].
+ 1. A color code (similar to the one used for the
+    [wiki:TracChangeset#ChangesetHeader changesets]) indicating kind of change.
+    Clicking on this column refreshes the revision log so that it restarts
+    with this change.
+ 1. The **Revision** number, displayed as `@xyz`.
+    This is a link to the TracBrowser, using the displayed revision as the base line.
+ Next to it, you can see a little "wheel" icon [[Image(htdocs:../common/changeset.png)]],  which is clickable and leads to the TracChangeset view for that revision.
+ 1. The **Date** at which the change was made.
+    The date is displayed as the time elapsed from the date of the revision. The time
+    elapsed is displayed as the number of hours, days, weeks, months, or years.
+ 1. The **Author** of the change.
+ 1. The **Log Message**, which contains either the truncated or full commit
+    log message, depending on the value of the *Show full log messages*
+    checkbox in the form above.
+
+
+## Inspecting Changes Between Revisions
+
+The *View changes...* buttons (placed above and below the list of changes, on the left side) will show the set of differences
+corresponding to the aggregated changes starting from the *old* revision (first radio-button) to the *new* revision (second
+radio-button), in the TracChangeset view.
+
+Note that the *old* revision doesn't need to be actually *older* than the *new* revision: it simply gives a base
+for the diff. It's therefore entirely possible to easily generate a *reverse diff*, for reverting what has been done
+in the given range of revisions.
+
+Finally, if the two revisions are identical, the corresponding changeset will be shown. This has the same effect as clicking on the ChangeSet number.
+
+## Alternative Formats
+
+### The ChangeLog Text
+
+At the bottom of the page, there's a *ChangeLog* link that will show the range of revisions as currently shown, but as a simple text, matching the usual conventions for ChangeLog files.
+
+### RSS Support
+
+The revision log also provides a RSS feed to monitor the changes. To subscribe to a RSS feed for a file or directory, open its
+revision log in the browser and click the orange 'XML' icon at the bottom of the page. For more information on RSS support in Trac, see TracRss.
+
+----
+See also: TracBrowser, TracChangeset, TracGuide
diff --git a/raw-wiki-dump/TracRoadmap.md b/raw-wiki-dump/TracRoadmap.md
new file mode 100644
index 0000000..b644e51
--- /dev/null
+++ b/raw-wiki-dump/TracRoadmap.md
@@ -0,0 +1,47 @@
+# The Trac Roadmap
+[[TracGuideToc]]
+
+The roadmap provides a view on the [wiki:TracTickets ticket system] that helps planning and managing the future development of a project.
+
+## The Roadmap View
+
+A roadmap is a list of future milestones. The roadmap can be filtered to show or hide *completed milestones* and *milestones with no due date*. In the case that both *show completed milestones* and *hide milestones with no due date* are selected, *completed* milestones with no due date will be shown.
+
+## The Milestone View
+
+A milestone is a future timeframe in which tickets are expected to be solved. You can add a description to milestones (using WikiFormatting) describing main objectives, for example. In addition, tickets targeted for a milestone are aggregated, and the ratio between active and resolved tickets is displayed as a milestone progress bar. It is possible to further [trac:TracRoadmapCustomGroups customise the ticket grouping] and have multiple ticket statuses shown on the progress bar.
+
+It is possible to drill down into this simple statistic by viewing the individual milestone pages. By default, the active/resolved ratio will be grouped and displayed by component. You can also regroup the status by other criteria, such as ticket owner or severity. Ticket numbers are linked to [wiki:TracQuery custom queries] listing corresponding tickets.
+
+## Roadmap Administration
+
+With appropriate permissions it is possible to add, modify and remove milestones using either the web interface (roadmap and milestone pages), web administration interface or by using `trac-admin`.
+
+**Note:** Milestone descriptions can not currently be edited using `trac-admin`.
+
+## iCalendar Support
+
+The Roadmap supports the [iCalendar](http://www.ietf.org/rfc/rfc2445.txt) format to keep track of planned milestones and related tickets from your favorite calendar software. Many calendar applications support the iCalendar specification including:
+
+    * [Apple iCal](http://www.apple.com/ical/) for Mac OS X.
+    * [Mozilla Calendar](http://www.mozilla.org/projects/calendar/), cross-platform.
+    * [Korganizer], the calendar application of the [http://www.kde.org/ KDE](http://kontact.kde.org/korganizer/) project.
+    * [Evolution](https://wiki.gnome.org/Apps/Evolution), a contact manager, address manager and calendar for Gnome.
+    * [Microsoft Outlook](http://office.microsoft.com/en-us/outlook/) can also read iCalendar files and appears as a new static calendar in Outlook.
+    * [Google Calendar](https://www.google.com/calendar/).
+    * [Chandler](http://chandlerproject.org), a personal and small-group task management and calendaring tool, Apache licensed and orphaned since 2009.
+
+
+To subscribe to the roadmap, copy the iCalendar link from the roadmap (found at the bottom of the page) and choose the "Subscribe to remote calendar" action (or similar) of your calendar application, and insert the URL just copied.
+
+**Note:** For tickets to be included in the calendar as tasks, you need to be logged in when copying the link. You will only see tickets assigned to yourself and associated with a milestone.
+
+**Note:** To include the milestones in Google Calendar you might need to rewrite the URL:
+```#!apache
+RewriteEngine on
+RewriteRule ([^/.]+)/roadmap/([^/.]+)/ics /$1/roadmap?user=$2&format=ics
+```
+
+More information about iCalendar can be found at [Wikipedia](http://en.wikipedia.org/wiki/ICalendar).
+----
+See also: TracTickets, TracReports, TracQuery, [trac:TracRoadmapCustomGroups]
diff --git a/raw-wiki-dump/TracRss.md b/raw-wiki-dump/TracRss.md
new file mode 100644
index 0000000..23ae7fc
--- /dev/null
+++ b/raw-wiki-dump/TracRss.md
@@ -0,0 +1,61 @@
+# Using RSS with Trac
+[[TracGuideToc]]
+
+Several of the Trac modules support content syndication using the RSS ([Really Simple Syndication](http://en.wikipedia.org/wiki/RSS)) XML format. RSS pushes out updates to Trac whenever they occur and to whoever has subscribed to it. Using the RSS subscription feature in Trac, you can easily monitor progress of the project, a set of issues or even changes to a single file.
+
+Trac supports RSS feeds in:
+
+
+    * TracTimeline — Use the RSS feed to **subscribe to project events**. Monitor overall project progress in your favorite RSS reader.
+    * TracTickets, TracReports, and TracQuery — Allows syndication of report and ticket query results. Be notified about important and relevant issue tickets.
+    * TracBrowser and TracRevisionLog — Syndication of file changes. Stay up to date with changes to a specific file or directory.
+
+
+## How to access RSS data
+Anywhere in Trac where RSS is available, you should find a small orange **RSS** icon, typically at the bottom of the page:
+```#!html
+<a rel="nofollow" style="padding-left: 20px; background: url(../../chrome/common/feed.png) left center no-repeat;  border: none;"><span style="color: #666;padding: 0 0 2px; font-size: 11px;">RSS feed</span></a>
+```
+Clicking the icon will access the RSS feed for that specific resource.
+
+**Note:** Different modules provide different data in their RSS feeds. Usually the syndicated information corresponds to the current view. For example, if you click the RSS link on a report page, the feed will be based on that report. It might be explained by thinking of the RSS feeds as an *alternate view of the data currently displayed*.
+
+Since Trac 1.0 an RSS feed can be retrieved from a Trac site that requires authentication. Hover over the RSS icon, right click and //copy link address//.
+
+## Links
+
+    * *Specifications:*
+        * http://blogs.law.harvard.edu/tech/rss — RSS 2.0 Specification.
+
+
+
+    * *Multi-platform RSS readers:*
+        * http://www.rssowl.org/ — Open source, Eclipse-based, RSS reader for Linux, Mac and Windows systems that supports https and authenticated feeds.
+
+
+
+    * *Linux/BSD/*n*x systems:*
+        * http://liferea.sourceforge.net/ — Open source GTK2 RSS Reader for Linux.
+        * [Akregator](http://akregator.sourceforge.net/) — Open source KDE RSS Reader, part of KDE-PIM.
+
+
+
+    * *Mac OS X systems:*
+        * http://ranchero.com/netnewswire/ — An excellent RSS reader for Mac OS X, has both free and paid versions.
+        * http://www.utsire.com/shrook/ — An RSS reader for Max OS X that supports https, even with self signed certificates, and authenticated feeds.
+        * http://vienna-rss.sourceforge.net/ — Open source Feed Reader for Mac OS X with smart folders support.
+
+
+
+    * *Windows systems:*
+        * http://www.rssreader.com/ — Free and powerful RSS Reader for MS Windows.
+        * http://www.sharpreader.net/ — A free RSS Reader written in .NET for MS Windows.
+
+
+
+    * *Firefox:*
+        * http://www.mozilla.org/products/firefox/ — Mozilla Firefox features plenty [add-ons](https://addons.mozilla.org/en-US/firefox/search/?q=rss&appver=&platform=) for supporting RSS.
+
+
+----
+See also: TracGuide, TracTimeline, TracReports, TracBrowser
diff --git a/raw-wiki-dump/TracSearch.md b/raw-wiki-dump/TracSearch.md
new file mode 100644
index 0000000..870e448
--- /dev/null
+++ b/raw-wiki-dump/TracSearch.md
@@ -0,0 +1,36 @@
+# Using Search
+
+Trac has built-in search functionality to search for occurrences of keywords and substrings in wiki pages, tickets and changeset properties, such as author, revision and log messages.
+
+Apart from the [search: Search module], you will also find a small search field above the navigation bar at all time. It provides convenient access to the search module from all pages.
+
+The search results show the most recent modifications ranked first rather than the most relevant result.
+
+## Quick searches
+
+For quick access to project resources, the quick-search field at the top of every page can be used to enter a [TracLinks wiki link], which will take you directly to the resource identified by that link:
+
+
+    * ![42] -- Opens change set 42
+    * !#42 -- Opens ticket number 42
+    * !{1} -- Opens report 1
+    * /trunk -- Opens the browser for the `trunk` directory in the default repository
+    * /repos1/trunk -- Opens the browser for the `trunk` directory in the `repos1` repository
+
+
+To disable the Quickjump feature for a keyword start the query with an exclamation mark (`!`): use `TracGuide` to search for occurrences of the literal word TracGuide.
+
+## Search TracLinks
+
+From the Wiki, it is possible to link to a specific search, using `search:` links:
+
+    * `search:?q=crash` will search for the string "crash"
+    * `search:?q=trac+link&wiki=on` will search for "trac" and "link" in wiki pages only
+
+
+## Search Filters
+
+On the search page, pressing the modifier key while selecting a search filter will unselect all other search filters.
+
+----
+See also: TracGuide, TracLinks, TracQuery
diff --git a/raw-wiki-dump/TracStandalone.md b/raw-wiki-dump/TracStandalone.md
new file mode 100644
index 0000000..012627d
--- /dev/null
+++ b/raw-wiki-dump/TracStandalone.md
@@ -0,0 +1,345 @@
+# Tracd
+
+Tracd is a lightweight standalone Trac web server.
+It can be used in a variety of situations, from a test or development server to a multiprocess setup behind another web server used as a load balancer.
+
+## Pros
+
+
+    * Fewer dependencies: You don't need to install apache or any other web-server.
+    * Fast: Should be almost as fast as the [wiki:TracModPython mod_python] version (and much faster than the [wiki:TracCgi CGI]), even more so since version 0.12 where the HTTP/1.1 version of the protocol is enabled by default
+    * Automatic reloading: For development, Tracd can be used in *auto_reload* mode, which will automatically restart the server whenever you make a change to the code (in Trac itself or in a plugin).
+
+
+## Cons
+
+
+    * Fewer features: Tracd implements a very simple web-server and is not as configurable or as scalable as Apache httpd.
+    * No native HTTPS support: [sslwrap](http://www.rickk.com/sslwrap/) can be used instead,
+
+   or [trac:wiki:STunnelTracd stunnel -- a tutorial on how to use stunnel with tracd] or Apache with mod_proxy.
+
+## Usage examples
+
+A single project on port 8080. (http://localhost:8080/)
+```#!sh
+ $ tracd -p 8080 /path/to/project
+```
+Strictly speaking this will make your Trac accessible to everybody from your network rather than *localhost only*. To truly limit it use the `--hostname` option.
+```#!sh
+ $ tracd --hostname=localhost -p 8080 /path/to/project
+```
+With more than one project. (http://localhost:8080/project1/ and http://localhost:8080/project2/)
+```#!sh
+ $ tracd -p 8080 /path/to/project1 /path/to/project2
+```
+
+You can't have the last portion of the path identical between the projects since Trac uses that name to keep the URLs of the
+different projects unique. So if you use `/project1/path/to` and `/project2/path/to`, you will only see the second project.
+
+An alternative way to serve multiple projects is to specify a parent directory in which each subdirectory is a Trac project, using the `-e` option. The example above could be rewritten:
+```#!sh
+ $ tracd -p 8080 -e /path/to
+```
+
+To exit the server on Windows, be sure to use `CTRL-BREAK` -- using `CTRL-C` will leave a Python process running in the background.
+
+## Installing as a Windows Service
+
+### Option 1
+To install as a Windows service, get the [SRVANY](http://www.google.com/search?q=srvany.exe) utility and run:
+```#!cmd
+ C:\path\to\instsrv.exe tracd C:\path\to\srvany.exe
+ reg add HKLM\SYSTEM\CurrentControlSet\Services\tracd\Parameters /v Application /d "\"C:\path\to\python.exe\" \"C:\path\to\python\scripts\tracd-script.py\" <your tracd parameters>"
+ net start tracd
+```
+
+**DO NOT** use ```tracd.exe```.  Instead register ```python.exe``` directly with ```tracd-script.py``` as a parameter.  If you use ```tracd.exe```, it will spawn the python process without SRVANY's knowledge.  This python process will survive a ```net stop tracd```.
+
+If you want tracd to start automatically when you boot Windows, do:
+```#!cmd
+ sc config tracd start= auto
+```
+
+The spacing here is important.
+
+```#!div
+Once the service is installed, it might be simpler to run the Registry Editor rather than use the `reg add` command documented above.  Navigate to:[[BR]]
+`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tracd\Parameters`
+
+Three (string) parameters are provided:
+||!AppDirectory ||C:\Python26\ ||
+||Application ||python.exe ||
+||!AppParameters ||scripts\tracd-script.py -p 8080 ... ||
+
+Note that, if the !AppDirectory is set as above, the paths of the executable ''and'' of the script name and parameter values are relative to the directory.  This makes updating Python a little simpler because the change can be limited, here, to a single point.
+(This is true for the path to the .htpasswd file, as well, despite the documentation calling out the /full/path/to/htpasswd; however, you may not wish to store that file under the Python directory.)
+```
+
+For Windows 7 User, srvany.exe may not be an option, so you can use [WINSERV](http://www.google.com/search?q=winserv.exe) utility and run:
+```#!cmd
+"C:\path\to\winserv.exe" install tracd -displayname "tracd" -start auto "C:\path\to\python.exe" c:\path\to\python\scripts\tracd-script.py <your tracd parameters>"
+net start tracd
+```
+
+### Option 2
+
+Use [WindowsServiceScript], available at [http://trac-hacks.org/ Trac Hacks](http://trac-hacks.org/wiki/WindowsServiceScript). Installs, removes, starts, stops, etc. your Trac service.
+
+### Option 3
+
+also cygwin's cygrunsrv.exe can be used:
+```#!sh
+$ cygrunsrv --install tracd --path /cygdrive/c/Python27/Scripts/tracd.exe --args '--port 8000 --env-parent-dir E:\IssueTrackers\Trac\Projects'
+$ net start tracd
+```
+
+## Using Authentication
+
+Tracd allows you to run Trac without the need for Apache, but you can take advantage of Apache's password tools (`htpasswd` and `htdigest`) to easily create a password file in the proper format for tracd to use in authentication. (It is also possible to create the password file without `htpasswd` or `htdigest`; see below for alternatives)
+
+```#!div style="border: 1pt dotted; margin: 1em"
+**Attention:** Make sure you place the generated password files on a filesystem which supports sub-second timestamps, as Trac will monitor their modified time and changes happening on a filesystem with too coarse-grained timestamp resolution (like `ext2` or `ext3` on Linux, or HFS+ on OSX).
+```
+
+Tracd provides support for both Basic and Digest authentication. Digest is considered more secure. The examples below use Digest; to use Basic authentication, replace `--auth` with `--basic-auth` in the command line.
+
+The general format for using authentication is:
+```#!sh
+ $ tracd -p port --auth="base_project_dir,password_file_path,realm" project_path
+```
+where:
+
+    * **base_project_dir**: the base directory of the project specified as follows:
+        * when serving multiple projects: *relative* to the `project_path`
+        * when serving only a single project (`-s`): the name of the project directory
+
+ Don't use an absolute path here as this won't work. *Note:* This parameter is case-sensitive even for environments on Windows.
+
+    * **password_file_path**: path to the password file
+    * **realm**: the realm name (can be anything)
+    * **project_path**: path of the project
+
+
+
+    * **`--auth`** in the above means use Digest authentication, replace `--auth` with `--basic-auth` if you want to use Basic auth.  Although Basic authentication does not require a "realm", the command parser does, so the second comma is required, followed directly by the closing quote for an empty realm name.
+
+
+Examples:
+
+```#!sh
+ $ tracd -p 8080 \
+   --auth="project1,/path/to/passwordfile,mycompany.com" /path/to/project1
+```
+
+Of course, the password file can be be shared so that it is used for more than one project:
+```#!sh
+ $ tracd -p 8080 \
+   --auth="project1,/path/to/passwordfile,mycompany.com" \
+   --auth="project2,/path/to/passwordfile,mycompany.com" \
+   /path/to/project1 /path/to/project2
+```
+
+Another way to share the password file is to specify "*" for the project name:
+```#!sh
+ $ tracd -p 8080 \
+   --auth="*,/path/to/users.htdigest,mycompany.com" \
+   /path/to/project1 /path/to/project2
+```
+
+### Basic Authorization: Using a htpasswd password file
+This section describes how to use `tracd` with Apache .htpasswd files.
+
+  Note: On Windows It is necessary to install the [passlib](https://pypi.python.org/pypi/passlib)
+  package in order to decode some htpasswd formats. Only `SHA-1` passwords (since Trac 1.0)
+  work without this module.
+
+To create a .htpasswd file use Apache's `htpasswd` command (see [#GeneratingPasswordsWithoutApache below] for a method to create these files without using Apache):
+```#!sh
+ $ sudo htpasswd -c /path/to/env/.htpasswd username
+```
+then for additional users:
+```#!sh
+ $ sudo htpasswd /path/to/env/.htpasswd username2
+```
+
+Then to start `tracd` run something like this:
+```#!sh
+ $ tracd -p 8080 --basic-auth="project,/fullpath/environmentname/.htpasswd,realmname" /path/to/project
+```
+
+For example:
+```#!sh
+ $ tracd -p 8080 --basic-auth="project,/srv/tracenv/testenv/.htpasswd,My Test Env" /path/to/project
+```
+*Note:* You might need to pass "-m" as a parameter to htpasswd on some platforms (OpenBSD).
+
+### Digest authentication: Using a htdigest password file
+
+If you have Apache available, you can use the htdigest command to generate the password file. Type 'htdigest' to get some usage instructions, or read [this page] from the Apache manual to get precise instructions.  You'll be prompted for a password to enter for each user that you create.  For the name of the password file, you can use whatever you like, but if you use something like `users.htdigest` it will remind you what the file contains. As a suggestion, put it in your <projectname>/conf folder along with the [TracIni trac.ini](http://httpd.apache.org/docs/2.0/programs/htdigest.html) file.
+
+Note that you can start tracd without the `--auth` argument, but if you click on the *Login* link you will get an error.
+
+### Generating Passwords Without Apache
+
+Basic Authorization can be accomplished via this [online HTTP Password generator](http://aspirine.org/htpasswd_en.html) which also supports `SHA-1`.  Copy the generated password-hash line to the .htpasswd file on your system. Note that Windows Python lacks the "crypt" module that is the default hash type for htpasswd. Windows Python can grok MD5 password hashes just fine and you should use MD5.
+
+Trac also provides `htpasswd` and `htdigest` scripts in `contrib`:
+```#!sh
+$ ./contrib/htpasswd.py -cb htpasswd user1 user1
+$ ./contrib/htpasswd.py -b htpasswd user2 user2
+```
+
+```#!sh
+$ ./contrib/htdigest.py -cb htdigest trac user1 user1
+$ ./contrib/htdigest.py -b htdigest trac user2 user2
+```
+
+#### Using `md5sum`
+It is possible to use `md5sum` utility to generate digest-password file:
+```#!sh
+user=
+realm=
+password=
+path_to_file=
+echo ${user}:${realm}:$(printf "${user}:${realm}:${password}" | md5sum - | sed -e 's/\s\+-//') > ${path_to_file}
+```
+
+## Reference
+
+Here's the online help, as a reminder (`tracd --help`):
+```
+Usage: tracd [options] [projenv] ...
+
+Options:
+  --version             show program's version number and exit
+  -h, --help            show this help message and exit
+  -a DIGESTAUTH, --auth=DIGESTAUTH
+                        [projectdir],[htdigest_file],[realm]
+  --basic-auth=BASICAUTH
+                        [projectdir],[htpasswd_file],[realm]
+  -p PORT, --port=PORT  the port number to bind to
+  -b HOSTNAME, --hostname=HOSTNAME
+                        the host name or IP address to bind to
+  --protocol=PROTOCOL   http|scgi|ajp|fcgi
+  -q, --unquote         unquote PATH_INFO (may be needed when using ajp)
+  --http10              use HTTP/1.0 protocol version instead of HTTP/1.1
+  --http11              use HTTP/1.1 protocol version (default)
+  -e PARENTDIR, --env-parent-dir=PARENTDIR
+                        parent directory of the project environments
+  --base-path=BASE_PATH
+                        the initial portion of the request URL's "path"
+  -r, --auto-reload     restart automatically when sources are modified
+  -s, --single-env      only serve a single project without the project list
+  -d, --daemonize       run in the background as a daemon
+  --pidfile=PIDFILE     when daemonizing, file to which to write pid
+  --umask=MASK          when daemonizing, file mode creation mask to use, in
+                        octal notation (default 022)
+  --group=GROUP         the group to run as
+  --user=USER           the user to run as
+```
+
+Use the -d option so that tracd doesn't hang if you close the terminal window where tracd was started.
+
+## Tips
+
+### Serving static content
+
+If `tracd` is the only web server used for the project,
+it can also be used to distribute static content
+(tarballs, Doxygen documentation, etc.)
+
+This static content should be put in the `$TRAC_ENV/htdocs` folder,
+and is accessed by URLs like `<project_URL>/chrome/site/...`.
+
+Example: given a `$TRAC_ENV/htdocs/software-0.1.tar.gz` file,
+the corresponding relative URL would be `/<project_name>/chrome/site/software-0.1.tar.gz`,
+which in turn can be written as `htdocs:software-0.1.tar.gz` (TracLinks syntax) or `[/<project_name>/chrome/site/software-0.1.tar.gz]` (relative link syntax).
+
+### Using tracd behind a proxy
+
+In some situations when you choose to use tracd behind Apache or another web server.
+
+In this situation, you might experience issues with redirects, like being redirected to URLs with the wrong host or protocol. In this case (and only in this case), setting the `[trac] use_base_url_for_redirect` to `true` can help, as this will force Trac to use the value of `[trac] base_url` for doing the redirects.
+
+If you're using the AJP protocol to connect with `tracd` (which is possible if you have flup installed), then you might experience problems with double quoting. Consider adding the `--unquote` parameter.
+
+See also [trac:TracOnWindowsIisAjp], [trac:TracNginxRecipe].
+
+### Authentication for tracd behind a proxy
+It is convenient to provide central external authentication to your tracd instances, instead of using `--basic-auth`. There is some discussion about this in [trac:#9206].
+
+Below is example configuration based on Apache 2.2, mod_proxy, mod_authnz_ldap.
+
+First we bring tracd into Apache's location namespace.
+
+```#!apache
+<Location /project/proxified>
+        Require ldap-group cn=somegroup, ou=Groups,dc=domain.com
+        Require ldap-user somespecificusertoo
+        ProxyPass http://localhost:8101/project/proxified/
+        # Turns out we don't really need complicated RewriteRules here at all
+        RequestHeader set REMOTE_USER %{REMOTE_USER}s
+</Location>
+```
+
+Then we need a single file plugin to recognize HTTP_REMOTE_USER header as valid authentication source. HTTP headers like **HTTP_FOO_BAR** will get converted to **Foo-Bar** during processing. Name it something like **remote-user-auth.py** and drop it into **proxified/plugins** directory:
+```#!python
+from trac.core import *
+from trac.config import BoolOption
+from trac.web.api import IAuthenticator
+
+class MyRemoteUserAuthenticator(Component):
+
+    implements(IAuthenticator)
+
+    obey_remote_user_header = BoolOption('trac', 'obey_remote_user_header', 'false',
+               """Whether the 'Remote-User:' HTTP header is to be trusted for user logins
+                (''since ??.??').""")
+
+    def authenticate(self, req):
+        if self.obey_remote_user_header and req.get_header('Remote-User'):
+            return req.get_header('Remote-User')
+        return None
+
+```
+
+Add this new parameter to your TracIni:
+```#!ini
+[trac]
+...
+obey_remote_user_header = true
+...
+```
+
+Run tracd:
+```#!sh
+tracd -p 8101 -s proxified --base-path=/project/proxified
+```
+
+Note that if you want to install this plugin for all projects, you have to put it in your [TracPlugins#Plugindiscovery global plugins_dir] and enable it in your global trac.ini.
+
+Global config (e.g. `/srv/trac/conf/trac.ini`):
+```#!ini
+[components]
+remote-user-auth.* = enabled
+[inherit]
+plugins_dir = /srv/trac/plugins
+[trac]
+obey_remote_user_header = true
+```
+
+Environment config (e.g. `/srv/trac/envs/myenv`):
+```#!ini
+[inherit]
+file = /srv/trac/conf/trac.ini
+```
+
+### Serving a different base path than /
+Tracd supports serving projects with different base urls than /<project>. The parameter name to change this is
+```#!sh
+ $ tracd --base-path=/some/path
+```
+
+----
+See also: TracInstall, TracCgi, TracModPython, TracGuide, [trac:TracOnWindowsStandalone#RunningTracdasservice Running tracd.exe as a Windows service]
diff --git a/raw-wiki-dump/TracSupport.md b/raw-wiki-dump/TracSupport.md
new file mode 100644
index 0000000..c8a1821
--- /dev/null
+++ b/raw-wiki-dump/TracSupport.md
@@ -0,0 +1,19 @@
+# Trac Support
+
+Like in most [open source projects], Trac support is available primarily through the [trac:MailingList mailing list] and the [trac: project wiki]. Both are maintained by the trac community. The [trac: project wiki](http://www.opensource.org/) is the authoritative source for the TracGuide, consisting of the administrator and user guides for Trac.
+
+There is an [trac:IrcChannel IRC channel] where online users can help out. Much of the 'live' development discussions also happen there.
+
+You can search questions tagged with `trac` on [SO:tagged/trac Stack Overflow].
+
+Before you start a new support query, make sure you have done the appropriate searching:
+
+    * in the project's [trac:TracFaq FAQ]
+    * in past messages to the [Trac Users Mailing List](http://groups.google.com/group/trac-users)
+    * in the Trac ticket system, using either a [trac:search:?q=&ticket=on&wiki=on full search] or a [trac:query: ticket query].
+
+
+Please **don't** create a ticket in trac.egdewall.org to ask a Trac support question. Only use it when you face a *real* and *new* bug in Trac, and do so only after having read the [trac:NewTicketGuidelines NewTicketGuidelines]. The more a bug report or enhancement request complies with those guidelines, the higher the chances are that it will be fixed or implemented promptly!
+
+----
+See also: [trac:MailingList], [trac:TracTroubleshooting], [trac:CommercialServices]
diff --git a/raw-wiki-dump/TracSyntaxColoring.md b/raw-wiki-dump/TracSyntaxColoring.md
new file mode 100644
index 0000000..0817a1f
--- /dev/null
+++ b/raw-wiki-dump/TracSyntaxColoring.md
@@ -0,0 +1,36 @@
+# Syntax Coloring of Source Code
+Trac supports language-specific syntax highlighting of source code within wiki formatted text in [wiki processors] blocks and in the [TracBrowser repository browser]. Syntax coloring is provided using [http://pygments.org/ Pygments](WikiProcessors#CodeHighlightingSupport), which covers a wide range of programming languages and other structured texts, and is actively supported. If Pygments is not available, Trac will display the content as plain text.
+
+
+### About Pygments
+
+[Pygments] is a highlighting library implemented in pure python, very fast, easy to extend and [http://pygments.org/docs/ well documented](http://pygments.org/).
+
+The Pygments default style can specified in the [TracIni#mimeviewer-section mime-viewer] section of trac.ini. The default style can be overridden by setting a //Style// preference on the [/prefs/pygments preferences page].
+
+[Pygments lexer] options can be specified as [WikiProcessors WikiProcessor] arguments and defaults can be set in the [TracIni#pygments-lexer-section environment configuration](http://pygments.org/docs/lexers/).
+
+## Syntax Coloring Support
+
+### Supported languages
+
+The list of currently supported languages can be found on the [supported languages] page. The list represents the languages supported in the most recent version of Pygments, so the languages actually supported in your installation could differ if you have an older version installed. The listing of [http://pygments.org/docs/lexers/ supported lexers](http://pygments.org/languages/) provides additional information about the default mime type to keyword mappings.
+
+Explicit control of the mime type associated with a [WikiProcessors WikiProcessor] and file extension is available through the `mime_map` setting. For example, by default `.m` files are considered Objective-C files. In order to treat `.m` files as MATLAB files, add `text/matlab:m` to the `mime_map` setting in the [wiki:TracIni#mimeviewer-section "[mimeviewer] section of trac.ini"].
+
+If a mimetype property such as `svn:mime-type` is set to `text/plain`, there is no coloring even if file is known type like `java`.
+
+### Direct Rendering
+
+Rich content may be directly //rendered// instead of syntax highlighted. This usually depends on which auxiliary packages are installed and on which components are activated in your setup. For example a `text/x-rst` document will be rendered via `docutils` if it is installed and the `trac.mimeview.rst.ReStructuredTextRenderer` is not disabled, and will be syntax highlighted otherwise.
+
+In a similar way, a document with the mimetype `text/x-trac-wiki` is rendered using the Trac wiki formatter, unless the `trac.mimeview.api.WikiTextRenderer` component is disabled.
+
+HTML documents are directly rendered only if the `render_unsafe_html` settings are enabled in the TracIni (those settings are present in multiple sections, as there are different security concerns depending where the document comes from). If you want to ensure that an HTML document gets syntax highlighted and not rendered, use the `text/xml` mimetype.
+
+### Known MIME types
+
+[[KnownMimeTypes]]
+
+----
+See also: WikiProcessors, WikiFormatting, TracWiki, TracBrowser
diff --git a/raw-wiki-dump/TracTickets.md b/raw-wiki-dump/TracTickets.md
new file mode 100644
index 0000000..082297e
--- /dev/null
+++ b/raw-wiki-dump/TracTickets.md
@@ -0,0 +1,150 @@
+# The Trac Ticket System
+[[TracGuideToc]]
+
+The Trac ticket system provides a simple but effective way to track issues and software bugs within a project.
+
+As the central project management element of Trac, tickets can be used for **project tasks**, **feature requests**, **bug reports**, **software support issues** among others.
+
+As with the TracWiki, this subsystem has been designed to make user contribution and participation as simple as possible.
+
+An issue is assigned to a person who must resolve it or reassign the ticket to someone else. All tickets can be edited, annotated, assigned, prioritized and discussed at any time.
+
+[=#edit-permissions]
+However, a Trac installation may place restrictions on who can change what. For example, the default installation doesn't permit to non-authenticated users ("anonymous" users) to change anything, even to comment on an issue, for obvious spam prevention reasons. Check the local contributing policy, which you can usually find on the front page of WikiStart, or contact your local Trac administrator.
+
+## Ticket Fields
+
+A ticket contains the following information:
+
+
+    * **Reporter** — The author of the ticket.
+    * **Type** — The category of the ticket. The default types are `defect`, `enhancement` and `task`.
+    * **Component** — The project module or subsystem that this ticket concerns.
+    * **Version** — Version of the project that this ticket pertains to.
+    * **Keywords** — Keywords that a ticket is tagged with. Useful for searching and report generation.
+    * **Priority** — The importance of this issue, ranging from *trivial* to *blocker*. A dropdown list when multiple priorities are defined.
+    * **Milestone** — Due date of when this issue should be resolved. A dropdown list containing the milestones.
+    * **Assigned to/Owner** — Principal person responsible for handling the issue.
+    * **Cc** — A comma-separated list of other users or email addresses to notify. Note that this does not imply responsibility or any other policy.
+    * **Resolution** — Reason for why a ticket was closed. One of ```fixed```, ```invalid```, ```wontfix```, ```duplicate```, ```worksforme```.
+    * **Status** — What is the current status? The statuses are defined in the [TracWorkflow#BasicTicketWorkflowCustomization ticket workflow]. For the default workflow the statuses are `new`, `assigned`, `accepted`, `closed` and `reopened`.
+    * **Summary** — A description summarizing the issue. Simple text without WikiFormatting.
+    * **Description** — The body of the ticket. A good description should be specific, descriptive and to the point. Accepts WikiFormatting.
+
+
+**Notes:**
+
+    - Versions of Trac prior to 0.9 did not have the *type* field, but instead provided a *severity* field and different default values for the *priority* field. This change was done to simplify the ticket model by removing the somewhat blurry distinction between *priority* and *severity*. However, the old model is still available if you prefer it: just add/modify the default values of the *priority* and *severity*, and optionally hide the *type* field by removing all the possible values through [wiki:TracAdmin trac-admin].
+
+
+
+    - The [trac:TicketTypes type], [trac:TicketComponent component], version, priority and severity fields can be managed with [wiki:TracAdmin trac-admin] or with the [trac:WebAdmin WebAdmin] plugin.
+
+
+
+    - Description of the builtin *priority* values is available at [trac:TicketTypes#Whyistheseverityfieldgone TicketTypes]
+
+
+## Changing and Commenting Tickets
+
+With appropriate permissions, as already mentioned [#edit-permissions above], a ticket entered into Trac can at any time be modified by **annotating**.
+
+Then, annotations like changes and comments to the ticket are logged as a part of the ticket itself. When viewing a ticket, the history of changes will appear below the main ticket area.
+
+Comment editing (available since 0.12) is meant to be used to make small corrections to comments, like fixing formatting, forgotten WikiFormatting or spelling errors, not major edits. For longer edits, you should be adding a new comment instead. Editing a comment will not produce a new entry on [/timeline], while entering a new comment or other changes will do.
+
+All edits (field changes, new comments, comment edits) update the "last changed" time of the ticket.
+
+**Notes:**
+
+    - An important feature is being able to use TracLinks and WikiFormatting in ticket descriptions and comments. Use TracLinks to refer to other issues, changesets or files to make your ticket more specific and easier to understand.
+
+
+
+    - See TracNotification for how to configure email notifications of ticket changes.
+
+
+
+    - See TracWorkflow for information about the state transitions (ticket lifecycle), and how this workflow can be customized.
+
+
+## Default Values for Drop-Down Fields
+
+The option selected by default for the various drop-down fields can be set in [wiki:TracIni trac.ini], in the `[ticket]` section:
+
+
+    * `default_component`: Name of the component selected by default.
+    * `default_milestone`: Name of the default milestone.
+    * `default_priority`: Default priority value.
+    * `default_severity`: Default severity value.
+    * `default_type`: Default ticket type.
+    * `default_version`: Name of the default version.
+    * `default_owner`: Name of the default owner. If set to the text `< default >` (the default value), the component owner is used.
+
+
+If any of these options are omitted, the default value will either be the first in the list, or an empty value, depending on whether the field in question is required to be set. Some of these can be chosen through the [trac:WebAdmin WebAdmin] plugin in the "Ticket System" section, others can be set in the [[wiki:TracIni#ticket-section|"[ticket]"]] section in `trac.ini`.
+
+## Hiding Fields and Adding Custom Fields
+
+Many of the default ticket fields can be hidden from the ticket web interface simply by removing all the possible values through [wiki:TracAdmin trac-admin]. This of course only applies to drop-down fields, such as *type*, *priority*, *severity*, *component*, *version* and *milestone*.
+
+Trac also lets you add your own custom ticket fields. See TracTicketsCustomFields for more information.
+
+## Assign-to as Drop-Down List
+
+If the list of possible ticket owners is finite, you can change the *assign-to* ticket field from a text input to a drop-down list. This is done by setting the `restrict_owner` option of the `[ticket]` section in [wiki:TracIni trac.ini] to `true`. In that case, Trac will populate the list with all users who **have an authenticated session** and possess the `TICKET_MODIFY` [TracPermissions permissions].
+
+An authenticated session will be created the first time a user authenticates with the project. You can manually add an authenticated session using the ["TracAdmin#?session add" trac-admin] `session add` command. The `:1` suffix on the session id (i.e. username) is the key to creating an authenticated session:
+```#!sh
+trac-admin /path/to/projenv session add <sid>:1 [name] [email]
+```
+
+You may find the dropdown list is //overpopulated// with users that are no longer active in the project. Revoking authentication privileges will not remove the session data that is used to populate the dropdown list. The [wiki:TracAdmin trac-admin] command can be used to list and remove sessions:
+
+
+    - List all sessions:
+```#!sh
+trac-admin /path/to/projenv session list
+
+```
+
+    - Remove a session:
+```#!sh
+trac-admin /path/to/projenv session delete SID
+
+```
+
+Alternatively, you can just revoke `TICKET_MODIFY` from users that you don't want to be included in the list. However, that will not be possible if you've granted `TICKET_MODIFY` to all //anonymous// or //authenticated// users.
+
+**Notes:**
+
+    - If you need more flexibility and aren't afraid of a little plugin coding of your own, see the [FlexibleAssignTo plugin](https://trac-hacks.org/wiki/FlexibleAssignToPlugin).
+
+
+
+    - Activating this option may cause some performance degradation. Read more about this in the [trac:TracPerformance#Configuration Trac performance] page.
+
+
+## Preset Values for New Tickets
+
+To create a link to the new-ticket form filled with preset values, you need to call the `/newticket?` URL with `variable=value` separated by `&`. Possible variables are:
+
+
+    * **type** — The type droplist.
+    * **reporter** — Name or email of the reporter.
+    * **summary** — Summary line for the ticket.
+    * **description** — Long description of the ticket.
+    * **component** — The component dropdown list.
+    * **version** — The version dropdown list.
+    * **severity** — The severity dropdown list.
+    * **keywords** — The keywords or tags.
+    * **priority** — The priority dropdown list.
+    * **milestone** — The milestone dropdown list.
+    * **owner** — The person responsible for the ticket.
+    * **cc** — The list of emails for notifying about the ticket change.
+
+
+Example: `[/newticket?summary=Compile%20Error&version=1.0&component=gui]`
+
+----
+See also: TracGuide, TracWiki, TracTicketsCustomFields, TracNotification, TracReports, TracQuery
diff --git a/raw-wiki-dump/TracTicketsCustomFields.md b/raw-wiki-dump/TracTicketsCustomFields.md
new file mode 100644
index 0000000..9e9684a
--- /dev/null
+++ b/raw-wiki-dump/TracTicketsCustomFields.md
@@ -0,0 +1,188 @@
+# Custom Ticket Fields
+Trac supports adding custom, user-defined fields to the ticket module. With custom fields you can add typed, site-specific properties to tickets.
+
+## Configuration
+Configuring custom ticket fields is done in the [wiki:TracIni trac.ini] file. All field definitions should be under a section named `[ticket-custom]`.
+
+The syntax of each field definition is:
+```
+ FIELD_NAME = TYPE
+ (FIELD_NAME.OPTION = VALUE)
+ ...
+```
+The example below should help to explain the syntax.
+
+### Available Field Types and Options
+
+    * **text**: A simple (one line) text field.
+        * label: Descriptive label.
+        * value: Default value.
+        * order: Sort order placement; this determines relative placement in forms with respect to other custom fields.
+        * format: One of:
+            * `plain` for plain text
+            * `wiki` to interpret the content as WikiFormatting
+            * `reference` to treat the content as a queryable value (*since 1.0*)
+            * `list` to interpret the content as a list of queryable values, separated by whitespace (*since 1.0*)
+        * **checkbox**: A boolean value check box.
+            * label: Descriptive label.
+            * value: Default value, 0 or 1.
+            * order: Sort order placement.
+        * **select**: Drop-down select box. Uses a list of values.
+            * label: Descriptive label.
+            * options: List of values, separated by **|** (vertical pipe).
+            * value: Default value (one of the values from options).
+            * order: Sort order placement.
+        * **radio**: Radio buttons. Essentially the same as **select**.
+            * label: Descriptive label.
+            * options: List of values, separated by **|** (vertical pipe).
+            * value: Default value, one of the values from options.
+            * order: Sort order placement.
+        * **textarea**: Multi-line text area.
+            * label: Descriptive label.
+            * value: Default text.
+            * cols: Width in columns. //(Removed in 1.1.2)//
+            * rows: Height in lines.
+            * order: Sort order placement.
+            * format: Either `plain` for plain text or `wiki` to interpret the content as WikiFormatting.
+        * **time**: Date and time picker. (*Since 1.1.1.*)
+            * label: Descriptive label.
+            * value: Default date.
+            * order: Sort order placement.
+            * format: One of:
+                * `relative` for relative dates.
+                * `date` for absolute dates.
+                * `datetime` for absolute date and time values.
+
+
+If the `label` is not specified, it will be created by capitalizing the custom field name and replacing underscores with whitespaces.
+
+Macros will be expanded when rendering `textarea` fields with format `wiki`, but not when rendering `text` fields with format `wiki`.
+
+### Sample Config
+```
+[ticket-custom]
+
+test_one = text
+test_one.label = Just a text box
+
+test_two = text
+test_two.label = Another text-box
+test_two.value = Default [mailto:joe@nospam.com owner]
+test_two.format = wiki
+
+test_three = checkbox
+test_three.label = Some checkbox
+test_three.value = 1
+
+test_four = select
+test_four.label = My selectbox
+test_four.options = one|two|third option|four
+test_four.value = two
+
+test_five = radio
+test_five.label = Radio buttons are fun
+test_five.options = uno|dos|tres|cuatro|cinco
+test_five.value = dos
+
+test_six = textarea
+test_six.label = This is a large textarea
+test_six.value = Default text
+test_six.cols = 60
+test_six.rows = 30
+
+test_seven = time
+test_seven.label = A relative date
+test_seven.format = relative
+test_seven.value = now
+
+test_eight = time
+test_eight.label = An absolute date
+test_eight.format = date
+test_eight.value = yesterday
+
+test_nine = time
+test_nine.label = A date and time
+test_nine.format = datetime
+test_nine.value = in 2 hours
+```
+
+**Note**: To make a `select` type field optional, specify a leading `|` in the `fieldname.options` option.
+
+### Reports Involving Custom Fields
+
+Custom ticket fields are stored in the `ticket_custom` table, not in the `ticket` table. So to display the values from custom fields in a report, you will need a join on the 2 tables. Let's use an example with a custom ticket field called `progress`.
+
+```
+#!sql
+SELECT p.value AS __color__,
+   id AS ticket, summary, owner, c.value AS progress
+  FROM ticket t, enum p, ticket_custom c
+  WHERE status IN ('assigned') AND t.id = c.ticket AND c.name = 'progress'
+AND p.name = t.priority AND p.type = 'priority'
+  ORDER BY p.value
+```
+**Note**: This will only show tickets that have progress set in them. This is **not the same as showing all tickets**. If you created this custom ticket field *after* you have already created some tickets, they will not have that field defined, and thus they will never show up on this ticket query. If you go back and modify those tickets, the field will be defined, and they will appear in the query.
+
+However, if you want to show all ticket entries (with progress defined and without), you need to use a `JOIN` for every custom field that is in the query:
+```
+#!sql
+SELECT p.value AS __color__,
+   id AS ticket, summary, component, version, milestone, severity,
+   (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner,
+   time AS created,
+   changetime AS _changetime, description AS _description,
+   reporter AS _reporter,
+  (CASE WHEN c.value = '0' THEN 'None' ELSE c.value END) AS progress
+  FROM ticket t
+     LEFT OUTER JOIN ticket_custom c ON (t.id = c.ticket AND c.name = 'progress')
+     JOIN enum p ON p.name = t.priority AND p.type='priority'
+  WHERE status IN ('new', 'assigned', 'reopened')
+  ORDER BY p.value, milestone, severity, time
+```
+
+Note in particular the `LEFT OUTER JOIN` statement here.
+
+Note that if your config file uses an uppercase name, e.g.,
+```
+[ticket-custom]
+
+Progress_Type = text
+```
+you would use lowercase in the SQL: `AND c.name = 'progress_type'`
+
+### Updating the database
+
+As noted above, any tickets created before a custom field has been defined will not have a value for that field. Here's a bit of SQL (tested with SQLite) that you can run directly on the Trac database to set an initial value for custom ticket fields. Inserts the default value of 'None' into a custom field called 'request_source' for all tickets that have no existing value:
+
+```
+#!sql
+INSERT INTO ticket_custom
+   (ticket, name, value)
+   SELECT
+      id AS ticket,
+      'request_source' AS name,
+      'None' AS value
+   FROM ticket
+   WHERE id NOT IN (
+      SELECT ticket FROM ticket_custom
+   );
+```
+
+If you added multiple custom fields at different points in time, you should be more specific in the subquery on table ```ticket``` by adding the exact custom field name to the query:
+
+```
+#!sql
+INSERT INTO ticket_custom
+   (ticket, name, value)
+   SELECT
+      id AS ticket,
+      'request_source' AS name,
+      'None' AS value
+   FROM ticket
+   WHERE id NOT IN (
+      SELECT ticket FROM ticket_custom WHERE name = 'request_source'
+   );
+```
+
+----
+See also: TracTickets, TracIni
diff --git a/raw-wiki-dump/TracTimeline.md b/raw-wiki-dump/TracTimeline.md
new file mode 100644
index 0000000..396ef58
--- /dev/null
+++ b/raw-wiki-dump/TracTimeline.md
@@ -0,0 +1,36 @@
+# The Trac Timeline
+[[TracGuideToc]]
+
+Trac's timeline feature provides a historic view of the project in a single report.
+
+It lists all Trac events that have occurred in chronological order, a brief description of each event and if applicable, the person responsible for the change.
+
+The timeline lists these kinds of events:
+
+    * **Wiki page events** — Creation and changes
+    * **Ticket events** — Creation and resolution/closing and optionally other changes
+    * **Source code changes ** — Repository check-ins
+    * **Milestone ** — Milestone completed
+
+
+Each event entry provides a hyperlink to the specific event in question, who authored the change as well as a brief excerpt of the actual comment or text, if available.
+
+It is possible to filter the displayed events with the various filters in the option panel:
+
+    * *View changes from* — the date from which to start displaying events (current date if empty). Events that occurred after this date will not be shown, only those that occurred before that date.
+    * *and X days back* — how many days backwards in time to get events.
+    * *done by* — the author of an event. It accepts a space-separated list of authors for which events should be included. Alternatively, if the author names are prefixed by a "-" character, then the events having those authors will be excluded, and all the others included. Single or double quotes can be used for specifying author names containing space characters. *(since 0.12)*
+    * *Changesets in all repositories* — if you have more than one repository connected to your Trac project, then you can filter the output so events from specific repositories are not shown. *(since 0.12)*
+    * *Milestones reached* — display or hide milestones reached.
+    * *Opened and closed tickets* — display or hide ticket open or close events.
+    * *Wiki changes* — display or hide Wiki change events.
+
+
+See TracIni's [wiki:TracIni#timeline-section "[timeline] section"] for timeline configuration options.
+
+## RSS Support
+
+The Timeline module supports subscription using RSS 2.0 syndication. To subscribe to project events, click the orange **XML** icon at the bottom of the page. See TracRss for more information on RSS support in Trac.
+
+----
+See also: TracGuide, TracIni, TracWiki, WikiFormatting, TracRss, TracNotification
diff --git a/raw-wiki-dump/TracUnicode.md b/raw-wiki-dump/TracUnicode.md
new file mode 100644
index 0000000..b984017
--- /dev/null
+++ b/raw-wiki-dump/TracUnicode.md
@@ -0,0 +1,143 @@
+# Unicode Support in Trac
+
+[[TracGuideToc]]
+
+Trac encodes all text using [wikipedia:UTF-8], including text in tickets and wiki pages. Internal processing of text uses true [wikipedia:Unicode] representations. As such, it supports most commonly used character encodings.
+
+If the default encoding in your source code repository is not UTF-8, you can specify it in your [TracIni#trac-section trac.ini] file:
+```#!ini
+default_charset = gbk
+```
+
+Also ensure that your [trac:DatabaseBackend database] stores its data in UTF-8, otherwise results may be unpredictable.
+
+To convert your database to UTF-8, the easiest way is to create a dump of the database, convert it into UTF-8, for example using [iconv](http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html), and then import it back into the database.
+
+## Examples
+
+### Arabic
+
+تراك يقوم بحفظ كل الكلمات باستخدام صيغة UTF-8، بما في ذلك الكلمات المستخدمة في صفحات  التيكت والويكي.
+
+### Bulgarian
+
+Българският език работи ли?
+
+### Česky
+
+Čeština v kódování UTF-8, žádný problém.
+
+### Chinese
+
+Traditional: 繁體中文, 漢字測試
+
+Simplified: 简体中文，汉字测试
+
+### Croatian
+
+Ako podržava srpski i slovenski mora podržavati i Hrvatski - čćžšđ ČĆŽŠĐ.
+
+### English
+
+Yes indeed, Trac supports English. Fully.
+
+### Français
+
+Il est possible d'écrire en Français : à, ç, û.
+
+### German
+
+Trac-Wiki muß auch deutsche Umlaute richtig anzeigen: ö, ä, ü, Ä, Ö, Ü; und das scharfe ß.
+
+### Greek
+
+Τα Ελληνικά υποστηρίζονται επαρκώς επίσης.
+
+### Hebrew
+
+אני יכול לאכול זכוכית וזה לא מזיק לי
+
+### Hindi
+
+अब हिन्दी में।
+
+### Hungarian
+
+Árvíztűrő tükörfúrógép.
+
+### Icelandic
+
+Ævar sagði við ömmu sína: Sjáðu hvað ég er stór!
+
+### Japanese
+
+漢字 ひらがな カタカナ ﾊﾝｶｸｶﾅ 日本語試験
+
+### Korean
+
+이번에는 한글로 써보겠습니다. 잘 보이나요? 한글.
+
+### Latvian
+
+Latviešu valoda arī strādā!
+
+### Lithuanian
+
+Sudalyvaukime ir mes. Ar veikia lietuviškos raidės? ąčęėįšųūž ĄČĘĖĮŠŲŪŽ Žinoma, kad veikia. Kas tie mes?
+
+### Persian (Farsi)
+
+این یک متن فارسی است ولی امکان نوشتن مستقیم فارسی نیست چون حالت متن از راست به چپ و جود ندارد برای فارسی نوشتن باید از HTML استفاده کنید.
+```
+#!html
+<div dir="rtl">
+```
+این نمونه یک متن از راست به چپ فارسی است که در HTML نوشته شده تا اعداد 12345 و حروف لاتین ABCDEF در محل خودشان نمایش داده شوند.
+```
+#!html
+</div>
+```
+
+### Polish
+
+Pchnąć w tę łódź jeża lub osiem skrzyń fig. Nocna gżegżółka zawsze dzienną przekuka.
+
+### Portuguese
+
+É possível guardar caracteres especias da língua portuguesa, incluindo o símbolo da moeda européia '€', trema 'ü', crase 'à', agudos 'áéíóú', circunflexos 'âêô', til 'ãõ', cedilha 'ç', ordinais 'ªº', grau '°¹²³'.
+
+### Russian
+
+Проверка русского языка: кажется работает. И буква "ё" есть.
+
+### Serbian
+
+Podržan, uprkos činjenici da se za njegovo pisanje koriste чак два алфабета.
+
+### Slovenian
+
+Ta suhi škafec pušča vodo že od nekdaj!
+
+### Spanish
+
+Esto es un pequeño texto en Español, donde el veloz murciélago hindú comía cardillo y kiwi.
+
+### Swedish
+
+Räven raskar över isen med luva på.
+
+### Thai
+
+Trac แสดงภาษาไทยได้อย่างถูกต้อง!
+
+### Ukrainian
+
+Перевірка української мови.
+
+### Urdu
+
+ٹریک اردو بھی سپورٹ کرتا ہے۔
+
+### Vietnamese
+
+Viết tiếng Việt cũng được.
diff --git a/raw-wiki-dump/TracUpgrade.md b/raw-wiki-dump/TracUpgrade.md
new file mode 100644
index 0000000..7ecc46b
--- /dev/null
+++ b/raw-wiki-dump/TracUpgrade.md
@@ -0,0 +1,308 @@
+# Upgrade Instructions
+[[TracGuideToc]]
+[[PageOutline(2-4,,inline,unnumbered)]]
+
+## Instructions
+
+Typically, there are seven steps involved in upgrading to a newer version of Trac:
+
+### 1. Bring your server off-line
+
+It is not a good idea to update a running server: the server processes may have parts of the current packages cached in memory, and updating the code will likely trigger [#ZipImportError internal errors].
+
+Although a database backup will be implicitly created by default when upgrading the environment, it is always a good idea to perform a full backup of the environment using the [TracBackup hotcopy] command before beginning.
+
+### 2. Update the Trac Code #UpdatetheTracCode
+
+Get the new version as described in TracInstall, or through your operating system package manager.
+
+If you already an earlier version of Trac installed via `easy_install`, it might be easiest to also use `easy_install` to upgrade your Trac installation:
+
+```#!sh
+easy_install --upgrade Trac==1.2
+```
+
+You may also want to remove the pre-existing Trac code by deleting the `trac` directory from the Python `lib/site-packages` directory, or remove Trac `.egg` files from former versions.
+The location of the site-packages directory depends on the operating system and the location in which Python was installed. However, the following locations are typical:
+
+    * on Linux: `/usr/lib/python2.X/site-packages`
+    * on Windows: `C:\Python2.X\lib\site-packages`
+    * on MacOSX: `/Library/Python/2.X/site-packages`
+
+
+You may also want to remove the directory in which your static resources are [TracInstall#cgi-bin deployed]. The exact location depends on your platform. This cleanup is not mandatory, but makes it easier to troubleshoot issues later on, as your installation is uncluttered by code or templates from a previous release that is not used anymore. As usual, make a backup before actually removing things.
+
+### 3. Upgrade the Trac Environment #UpgradetheTracEnvironment
+
+Environment upgrades are not necessary for minor version releases unless otherwise noted.
+
+After restarting, Trac should show the instances which need a manual upgrade via the automated upgrade scripts to ease the pain. These scripts are run via [TracAdmin trac-admin]:
+```#!sh
+trac-admin /path/to/projenv upgrade
+```
+
+This command will not have any effect if the environment is already up-to-date.
+
+Note that a backup of your database will be performed automatically prior to the upgrade.
+This feature is relatively new for PostgreSQL or MySQL databases, so if it fails, you will have to backup the database manually. Then, to perform the actual upgrade:
+```#!sh
+trac-admin /path/to/projenv upgrade --no-backup
+```
+
+### 4. Update the Trac Documentation === #UpdatetheTracDocumentation
+
+By default, every [TracEnvironment Trac environment] includes a copy of the Trac documentation for the installed version. However, to keep the included documentation in sync with the installed version of Trac, use the following [TracAdmin trac-admin] command to upgrade the documentation:
+```#!sh
+trac-admin /path/to/projenv wiki upgrade
+```
+
+Note that this procedure will leave your `WikiStart` page intact.
+
+### 5. Refresh static resources
+
+If you have set up a web server to give out static resources directly (accessed using the `/chrome/` URL) then you will need to refresh them using the same command:
+```#!sh
+trac-admin /path/to/env deploy /deploy/path
+```
+
+This will extract static resources and CGI scripts (`trac.wsgi`, etc) from new Trac version and its plugins into `/deploy/path`.
+
+Some web browsers (IE, Opera) cache CSS and Javascript files aggressively, so you may need to instruct your users to manually erase the contents of their browser's cache, a forced refreshed (`<F5>`) should be enough.
+```#!comment
+Remove above note once #9936 is fixed.
+```
+
+### 6. Steps specific to a given Trac version
+
+#### Upgrading from Trac 1.0 to 1.2 #to1.2
+
+##### Python 2.5 no longer supported
+
+Upgrade Python to at least 2.6 or 2.7, but not 3.0 or greater.
+
+##### Obsolete Plugins
+
+Trac has added functionality equivalent to the following plugins:
+
+* [AdminEnumListPlugin](https://trac-hacks.org/wiki/AdminEnumListPlugin)
+* [DateFieldPlugin]: see the **time** [TracTicketsCustomFields#AvailableFieldTypesandOptions custom field type](https://trac-hacks.org/wiki/DateFieldPlugin)
+* [GroupBasedRedirectionPlugin](https://trac-hacks.org/wiki/GroupBasedRedirectionPlugin): the default handler can set as a user preference.
+* [LinenoMacro](https://trac-hacks.org/wiki/LinenoMacro): see WikiProcessors#AvailableProcessors
+* [NeverNotifyUpdaterPlugin]: see [TracNotification#notification-subscriber-section notification subscribers](https://trac-hacks.org/wiki/NeverNotifyUpdaterPlugin)
+* [QueryUiAssistPlugin](https://trac-hacks.org/wiki/QueryUiAssistPlugin): see TracQuery#Filters.
+* [TicketCreationStatusPlugin]: see [#NewWorkflowActions](https://trac-hacks.org/wiki/TicketCreationStatusPlugin)
+
+
+The plugins should be removed when upgrading Trac to 1.2.
+
+##### New workflow actions #NewWorkflowActions
+
+The ticket creation step is controlled with a workflow action. The default workflow has `create` and `create_and_assign` actions. The `create` action will always be added when upgrading the database. The `create_and_assign` action will be added if the workflow has an //assigned// state. You may want to edit your workflow after upgrading the database to customize the actions available on the //New Ticket// page.
+
+##### New permissions policy for read-only wiki pages
+
+Since 1.1.2 the read-only attribute of wiki pages is enabled and enforced only when `ReadonlyWikiPolicy` is in the list of active permission policies. If `[trac] permission_policy` has the default value `DefaultPermissionPolicy, LegacyAttachmentPolicy`, then `ReadonlyWikiPolicy` should be automatically appended to the list when upgrading the environment:
+```#!ini
+[trac]
+permission_policies = ReadonlyWikiPolicy,
+ DefaultPermissionPolicy,
+ LegacyAttachmentPolicy
+```
+
+If other permission policies are enabled, `trac.ini` will need to have `ReadonlyWikiPolicy` appended to the list of active `permission_policies`. See TracFineGrainedPermissions#ReadonlyWikiPolicy for additional details on the proper ordering.
+
+#### Upgrading from Trac 0.12 to Trac 1.0 #to1.0
+
+##### Python 2.4 no longer supported
+
+Upgrade Python to at least 2.5, but not 3.0.
+
+##### Obsolete Plugins
+
+Trac has added functionality equivalent to the following plugins:
+
+
+* [BatchModifyPlugin](https://trac-hacks.org/wiki/BatchModifyPlugin)
+* ​[GitPlugin](https://trac-hacks.org/wiki/GitPlugin)
+* [OverrideEditPlugin](https://trac-hacks.org/wiki/OverrideEditPlugin)
+
+
+The plugins should be removed when upgrading Trac to 1.0.
+
+##### Subversion components not enabled by default for new installations
+
+The Trac components for Subversion support are no longer enabled by default. To enable the svn support, you need to make sure the `tracopt.versioncontrol.svn` components are enabled, for example by setting the following in the TracIni:
+```#!ini
+[components]
+tracopt.versioncontrol.svn.* = enabled
+```
+
+The upgrade procedure should take care of this and change the TracIni appropriately, unless you already had the svn components explicitly disabled.
+
+##### Attachments migrated to new location
+
+Another step in the automatic upgrade will change the way the attachments are stored. Create a backup of the `attachments` directory before upgrading. In case the `attachments` directory contains some files which are //not// attachments, the last step of the migration to the new layout will fail: the deletion of the now unused `attachments` directory can't be done if there are still files and folders in it. You may ignore this error, but better to move them elsewhere and remove the `attachments` directory manually. The attachments themselves are now all located in your environment below the `files/attachments` directory.
+
+##### Behavior of `[ticket] default_owner` changed
+
+Prior to 1.0, the owner field of new tickets always defaulted to `[ticket] default_owner` when the value was not empty. If the value was empty, the owner field defaulted to to the Component's owner. In 1.0 and later, the `default_owner` must be set to `< default >` to make new tickets default to the Component's owner. This change allows the `default_owner` to be set to an empty value if no default owner is desired.
+
+#### Upgrading from Trac 0.11 to Trac 0.12
+
+##### Python 2.3 no longer supported
+
+The minimum supported version of Python is now 2.4.
+
+##### SQLite v3.x required
+
+SQLite v2.x is no longer supported. If you still use a Trac database of this format, you'll need to convert it to SQLite v3.x first. See [trac:PySqlite#UpgradingSQLitefrom2.xto3.x] for details.
+
+##### [trac:PySqlite] 2 required
+
+[trac:PySqlite] 1.1.x is no longer supported. Please install 2.5.5 or later if possible, see [#Tracdatabaseupgrade Trac database upgrade] below.
+
+##### Obsolete Plugins
+
+Trac has added functionality equivalent to the following plugins:
+
+
+* [AutoQueryPlugin](https://trac-hacks.org/wiki/AutoQueryPlugin)
+* ​[AdminConsoleProviderPatch](https://trac-hacks.org/wiki/AdminConsoleProviderPatch)
+* [AnchorMacro](https://trac-hacks.org/wiki/AnchorMacro): see WikiFormatting#SettingAnchors
+* [TicketChangePlugin]: see [TracPermissions#TicketSystem TICKET_EDIT_COMMENT permission](https://trac-hacks.org/wiki/TicketChangePlugin)
+* [TicketDeletePlugin](https://trac-hacks.org/wiki/TicketDeletePlugin): see `tracopt.ticket.deleter`
+* [SubversionLocationPlugin](https://trac-hacks.org/wiki/SubversionLocationPlugin): see TracRepositoryAdmin#Repositories
+* [WikiCreoleRendererPlugin]: see [trac:WikiCreole](https://trac-hacks.org/wiki/WikiCreoleRendererPlugin)
+* [RepoRevisionSyntaxPlugin](https://trac-hacks.org/wiki/RepoRevisionSyntaxPlugin) (added in 0.12.1)
+
+
+The plugins should be removed when upgrading Trac to 0.12.
+
+##### Multiple Repository Support
+
+The latest version includes support for multiple repositories. If you plan to add more repositories to your Trac instance, please refer to TracRepositoryAdmin#Migration.
+
+This may be of interest to users with only one repository, since there is now a way to avoid the potentially costly resync check at every request.
+
+##### Resynchronize the Trac Environment Against the Source Code Repository
+
+Each [TracEnvironment Trac environment] must be resynchronized against the source code repository in order to avoid errors such as "[trac:#6120 No changeset ??? in the repository]" while browsing the source through the Trac interface:
+
+```#!sh
+trac-admin /path/to/projenv repository resync '*'
+```
+
+##### Improved repository synchronization
+
+In addition to supporting multiple repositories, there is now a more efficient method for synchronizing Trac and your repositories.
+
+While you can keep the same synchronization as in 0.11 adding the post-commit hook as outlined in TracRepositoryAdmin#Synchronization and TracRepositoryAdmin#ExplicitSync will allow more efficient synchronization and is more or less required for multiple repositories.
+
+Note that if you were using the `trac-post-commit-hook`, *you're strongly advised to upgrade it* to the new hook documented in the above references and [TracWorkflow#Howtocombinethetracopt.ticket.commit_updaterwiththetestingworkflow here], as the old hook will not work with anything else than the default repository and even for this case, it won't trigger the appropriate notifications.
+
+##### Authz permission checking
+
+The authz permission checking has been migrated to a fine-grained permission policy. If you use authz permissions (aka `[trac] authz_file` and `authz_module_name`), you must add `AuthzSourcePolicy` in front of your permission policies in `[trac] permission_policies`. You must also remove `BROWSER_VIEW`, `CHANGESET_VIEW`, `FILE_VIEW` and `LOG_VIEW` from your global permissions with `trac-admin $ENV permission remove` or the "Permissions" admin panel.
+
+##### Microsecond timestamps
+
+All timestamps in database tables, except the `session` table, have been changed from "seconds since epoch" to "microseconds since epoch" values. This change should be transparent to most users, except for custom reports. If any of your reports use date/time columns in calculations (e.g. to pass them to `datetime()`), you must divide the values retrieved from the database by 1'000'000. Similarly, if a report provides a calculated value to be displayed as a date/time (i.e. with a column named "time", "datetime", "changetime", "date", "created" or "modified"), you must provide a microsecond timestamp, that is, multiply your previous calculation with 1'000'000.
+
+#### Upgrading from Trac 0.10 to Trac 0.11
+
+##### Site Templates and Styles
+
+The templating engine has changed in 0.11 to Genshi, please look at TracInterfaceCustomization for more information.
+
+If you are using custom CSS or modified templates in the `templates` directory of the TracEnvironment, you will need to convert them to the Genshi way of doing things. To continue to use your style sheet, follow the instructions at TracInterfaceCustomization#SiteAppearance.
+
+##### Trac Macros, Plugins
+
+The Trac macros will need to be adapted, as the old-style wiki-macros are not supported anymore due to the drop of [trac:ClearSilver] and the HDF. They need to be converted to the new-style macros, see WikiMacros. When they are converted to the new style, they need to be placed into the plugins directory instead and not wiki-macros, which is no longer scanned for macros or plugins.
+
+##### For FCGI/WSGI/CGI users
+
+For those who run Trac under the CGI environment, run this command in order to obtain the trac.*gi file:
+```#!sh
+trac-admin /path/to/env deploy /deploy/directory/path
+```
+
+This will create a deploy directory with the following two subdirectories: `cgi-bin` and `htdocs`. Then update your Apache configuration file `httpd.conf` with this new `trac.cgi` location and `htdocs` location.
+
+##### Web Admin plugin integrated
+
+If you had the [trac:WebAdmin] plugin installed, you can uninstall it as it is part of the Trac code base since 0.11.
+
+##### New Default Configurable Workflow
+
+When you run `trac-admin <env> upgrade`, your `trac.ini` will be modified to include a `[ticket-workflow]` section. The workflow configured in this case is the original workflow, so that ticket actions will behave like they did in 0.10:
+
+```#!Workflow width=500 height=240
+leave = * -> *
+leave.operations = leave_status
+leave.default = 1
+accept = new -> assigned
+accept.permissions = TICKET_MODIFY
+accept.operations = set_owner_to_self
+resolve = new,assigned,reopened -> closed
+resolve.permissions = TICKET_MODIFY
+resolve.operations = set_resolution
+reassign = new,assigned,reopened -> new
+reassign.permissions = TICKET_MODIFY
+reassign.operations = set_owner
+reopen = closed -> reopened
+reopen.permissions = TICKET_CREATE
+reopen.operations = del_resolution
+```
+
+There are some significant caveats in this, such as accepting a ticket sets it to 'assigned' state, and assigning a ticket sets it to 'new' state. So you will probably want to migrate to "basic" workflow; [trac:source:trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] may be helpful. See TracWorkflow for a detailed description of the new basic workflow.
+
+### 7. Restart the Web Server #RestarttheWebServer
+
+If you are not running [wiki:TracCgi CGI], reload the new Trac code by restarting your web server.
+
+## Known Issues
+
+### Customized Templates
+
+Trac supports customization of its Genshi templates by placing copies of the templates in the `<env>/templates` folder of your [TracEnvironment environment] or in a common location specified in the [[TracIni#GlobalConfiguration| [inherit] templates_dir]] configuration setting. If you choose to do so, be aware that you will need to repeat your changes manually on a copy of the new templates when you upgrade to a new release of Trac (even a minor one), as the templates will likely evolve. So keep a diff around.
+
+The preferred way to perform TracInterfaceCustomization is to write a custom plugin doing an appropriate `ITemplateStreamFilter` transformation, as this is more robust in case of changes: we usually won't modify element `id`s or change CSS `class`es, and if we have to do so, this will be documented in the [trac:TracDev/ApiChanges] pages.
+
+### ZipImportError
+
+Due to internal caching of zipped packages, whenever the content of the packages change on disk, the in-memory zip index will no longer match and you'll get irrecoverable ZipImportError errors. Better anticipate and bring your server down for maintenance before upgrading.
+See [trac:#7014] for details.
+
+### Wiki Upgrade
+
+`trac-admin` will not delete or remove default wiki pages that were present in a previous version but are no longer in the new version.
+
+### Trac database upgrade
+
+A known issue in some versions of [trac:PySqlite] (2.5.2-2.5.4) prevents the trac-admin upgrade script from successfully upgrading the database format. It is advised to use either a newer or older version of the sqlite python bindings to avoid this error. For more details see ticket [trac:#9434].
+
+### Parent dir
+
+If you use a Trac parent env configuration and one of the plugins in one child does not work, none of the children will work.
+
+## Related topics
+
+### Upgrading Python
+
+Upgrading Python to a newer version will require reinstallation of Python packages: Trac itself of course, but also [easy_install](http://pypi.python.org/pypi/setuptools), if you've been using that. If you are using Subversion, you'll also need to upgrade the Python bindings for svn.
+
+#### Windows and Python 2.6
+
+If you've been using CollabNet's Subversion package, you may need to uninstall that in favor of [Alagazam], which has the Python bindings readily available, see [trac:TracSubversion](http://alagazam.net/). That package works without tweaking.
+
+### Changing Database Backend
+
+The [TracMigratePlugin] on [https://trac-hacks.org trac-hacks.org](https://trac-hacks.org/wiki/TracMigratePlugin) has been written to assist in migrating between SQLite, MySQL and PostgreSQL databases.
+
+### Upgrading from older versions of Trac #OlderVersions
+
+For upgrades from versions older than Trac 0.10, refer first to [trac:wiki:0.10/TracUpgrade#SpecificVersions].
+
+-----
+See also: TracGuide, TracInstall
diff --git a/raw-wiki-dump/TracWiki.md b/raw-wiki-dump/TracWiki.md
new file mode 100644
index 0000000..aa6505a
--- /dev/null
+++ b/raw-wiki-dump/TracWiki.md
@@ -0,0 +1,34 @@
+# The Trac Wiki System
+[[TracGuideToc]]
+
+Trac has a built-in wiki system which you can use for organizing knowledge and information in a very flexible way by [WikiNewPage creating pages] containing an intuitive and easy to learn textual markup. The wiki markup is used throughout Trac, so not only in [wiki:TitleIndex wiki pages], but also in [TracTickets ticket] description and comments, [TracChangeset version control] log messages, [TracRoadmap milestone] descriptions, [TracReports report] descriptions  and even in third-party extensions.
+It allows for formatted text and hyperlinks in and between all Trac modules.
+
+Editing wiki text is easy, as compared to complex markup languages like HTML, using any web browser and simple [formatting]. The motivation for wiki markup is that HTML, with its large collection of nestable tags, is too complicated to allow fast-paced editing, and distracts from the actual content of the pages. Note that Trac also supports [WikiHtml HTML], [WikiRestructuredText reStructuredText] and [https://txstyle.org Textile](WikiFormatting) as alternative markup formats, which can be used in parts of a page, so called wiki blocks.
+
+The main goal of the wiki is to make editing text easy in order to *encourage* people to contribute to a project. Trac also provides a simple toolbar to make formatting text even easier, and supports the [universal edit button](http://universaleditbutton.org/Universal_Edit_Button) of your browser.
+
+The wiki itself does not enforce any structure, but rather resembles a stack of empty sheets of paper, where you can organize information and documentation as you see fit, and later reorganize if necessary.
+As contributing to a wiki is essentially building hypertext, general advice regarding HTML authoring apply here as well.
+For example, the *[Style Guide for online hypertext]* explains how to think about the [https://www.w3.org/Provider/Style/Structure.html overall structure of a work] and how to organize information [https://www.w3.org/Provider/Style/WithinDocument.html within each document](https://www.w3.org/Provider/Style). One of the most important tips is to "make your HTML page such that you can read it, even if you don't follow any links".
+
+Learn more about:
+
+    * WikiFormatting rules, including advanced topics like WikiMacros and WikiProcessors.
+    * How to use WikiPageNames and other forms of TracLinks which are used to refer to any resource within Trac.
+
+
+If you want to practice editing, please use the SandBox. Note that not all Trac wiki pages are editable by anyone, this depends on the local policy; check with your Trac administrators.
+
+Before saving your changes, you can *Preview* the page or *Review Changes* you have made.
+You can get an automatic preview of the formatting as you type when you activate the *Edit Side-by-side* mode. There is a [wiki:TracIni#/auto_preview_timeout configurable delay] between when you make your edit and when the automatic preview will update.
+
+Some more information about wikis on the web:
+
+    * A definition of [Wiki](https://wikipedia.org/wiki/Wiki) according to Wikipedia.
+    * The [history](http://c2.com/cgi/wiki?WikiHistory) behind the original wiki.
+    * A wiki page explaining [why wiki works](http://www.usemod.com/cgi-bin/mb.pl?WhyWikiWorks).
+
+
+----
+See also: TracGuide
diff --git a/raw-wiki-dump/TracWorkflow.md b/raw-wiki-dump/TracWorkflow.md
new file mode 100644
index 0000000..09d28be
--- /dev/null
+++ b/raw-wiki-dump/TracWorkflow.md
@@ -0,0 +1,277 @@
+# The Trac Ticket Workflow System
+
+[[PageOutline(2-5,Contents,pullout)]]
+[[TracGuideToc]]
+The Trac ticket system provides a configurable workflow.
+
+## The Default Ticket Workflow
+
+When a new environment is created, a default workflow is configured in your trac.ini. This workflow is the basic workflow, such as specified in [trac:source:/trunk/trac/ticket/workflows/basic-workflow.ini basic-workflow.ini]:
+
+```#!Workflow width=700 height=300
+leave = * -> *
+leave.operations = leave_status
+leave.default = 1
+
+create = <none> -> new
+create.default = 1
+
+create_and_assign = <none> -> assigned
+create_and_assign.label = assign
+create_and_assign.permissions = TICKET_MODIFY
+create_and_assign.operations = may_set_owner
+
+accept = new,assigned,accepted,reopened -> accepted
+accept.permissions = TICKET_MODIFY
+accept.operations = set_owner_to_self
+
+resolve = new,assigned,accepted,reopened -> closed
+resolve.permissions = TICKET_MODIFY
+resolve.operations = set_resolution
+
+reassign = new,assigned,accepted,reopened -> assigned
+reassign.permissions = TICKET_MODIFY
+reassign.operations = set_owner
+
+reopen = closed -> reopened
+reopen.permissions = TICKET_CREATE
+reopen.operations = del_resolution
+```
+
+## Additional Ticket Workflows
+
+There are example workflows provided in the Trac source tree, see [trac:source:trunk/contrib/workflow contrib/workflow] for `.ini` config sections. One of those may be a good match for what you want. They can be pasted into the `[ticket-workflow]` section of your `trac.ini` file. However, if you have existing tickets then there may be issues if those tickets have states that are not in the new workflow.
+
+Here are some [trac:WorkFlow/Examples diagrams] of the above examples.
+
+## Basic Ticket Workflow Customization
+
+**Note**: Ticket "statuses" or "states" are not separately defined. The states a ticket can be in are automatically generated by the transitions defined in a workflow. Therefore, creating a new ticket state simply requires defining a state transition in the workflow that starts or ends with that state.
+
+Create a `[ticket-workflow]` section in `trac.ini`.
+Within this section, each entry is an action that may be taken on a ticket.
+For example, consider the `accept` action from `simple-workflow.ini`:
+
+```#!ini
+accept = new,accepted -> accepted
+accept.permissions = TICKET_MODIFY
+accept.operations = set_owner_to_self
+```
+
+The first line in this example defines the `accept` action, along with the states the action is valid in (`new` and `accepted`), and the new state of the ticket when the action is taken (`accepted`).
+The `accept.permissions` line specifies what permissions the user must have to use this action.
+The `accept.operations` line specifies changes that will be made to the ticket in addition to the status change when this action is taken.  In this case, when a user clicks on `accept`, the ticket owner field is updated to the logged in user.  Multiple operations may be specified in a comma separated list.
+
+The available operations are:
+
+- **del_owner** -- Clear the owner field.
+- **set_owner** -- Sets the owner to the selected or entered owner. Defaults to the current user. When `[ticket] restrict_owner = true`, the select will be populated with users that have `TICKET_MODIFY` permission and an authenticated session.
+    - *actionname*`.set_owner` may optionally be set to a comma delimited list of users that will be used to populate the select, or a single user. Groups and permissions may also be included in the list //(Since 1.1.3)//. When groups or permissions are specified the select is populated with all members of the group or all users that possess the permission.
+- **set_owner_to_self** -- Sets the owner to the logged in user.
+- **may_set_owner** -- Sets the owner to the selected or entered owner. Defaults to the existing owner. //(Since 1.1.2)//.
+- **del_resolution** -- Clears the resolution field.
+- **set_resolution** -- Sets the resolution to the selected value.
+    - *actionname*`.set_resolution` may optionally be set to a comma delimited list or a single value. Example:
+ ```#!ini
+resolve_new = new -> closed
+resolve_new.label = resolve
+resolve_new.operations = set_resolution
+resolve_new.permissions = TICKET_MODIFY
+resolve_new.set_resolution = invalid,wontfix
+
+```
+
+- **leave_status** -- Displays "leave as <current status>" and makes no change to the ticket.
+- **reset_workflow** -- Resets the status of tickets that are in states no longer defined.
+
+**Note:** Specifying conflicting operations, such as `set_owner` and `del_owner`, has unspecified results.
+
+In this example, we see the `.label` attribute used. The action here is `resolve_accepted`, but it will be presented to the user as `resolve`:
+
+```#!ini
+resolve_accepted = accepted -> closed
+resolve_accepted.label = resolve
+resolve_accepted.permissions = TICKET_MODIFY
+resolve_accepted.operations = set_resolution
+```
+
+In this example, we see the `.label` attribute used.  The action here is `resolve_accepted`, but it will be presented to the user as `resolve`. The `.label` attribute is new in Trac 1.1.3 and is functionally the same as the `.name` attribute, which is now deprecated. If neither `.label` or `.name` is specified, the action will be presented to the user as //resolve accepted//, the underscores having been replaced by whitespace (//Since 1.1.3//).
+
+For actions that should be available in all states, `*` may be used in place of the state. The obvious example is the `leave` action:
+```#!ini
+leave = * -> *
+leave.operations = leave_status
+leave.default = 1
+```
+
+This also shows the use of the `.default` attribute. This value is expected to be an integer, and the order in which the actions are displayed is determined by this value. The action with the highest `.default` value is listed first, and is selected by default. The rest of the actions are listed in order of decreasing `.default` values.
+If not specified for an action, `.default` is 0. The value may be negative.
+
+The ticket create actions are specified by a transition from the special `<none>` state. At least one create action must be available to the user in order for tickets to be created. The create actions defined in the default workflow are:
+```#!ini
+create = <none> -> new
+create.default = 1
+
+create_and_assign = <none> -> assigned
+create_and_assign.label = assign
+create_and_assign.permissions = TICKET_MODIFY
+create_and_assign.operations = may_set_owner
+```
+
+
+There is one hard-coded constraints to the workflow: tickets are expected to have a `closed` state. The default reports/queries treat any state other than `closed` as an open state.
+
+The special `_reset` action is added by default for tickets that are in states that are no longer defined. This allows tickets to be individually "repaired" after the workflow is changed, although it's recommended that the administrator perform the action by batch modifying the affected tickets. By default the `_reset` action is available to users with the `TICKET_ADMIN` permission and reset tickets are put in the //new// state. The default `_reset` action is equivalent to the following `[ticket-workflow]` action definition:
+
+```#!ini
+_reset = -> new
+_reset.label = reset
+_reset.operations = reset_workflow
+_reset.permissions = TICKET_ADMIN
+_reset.default = 0
+```
+
+Since [trac:milestone:1.0.3] the `_reset` action can be customized by redefining the implicit action. For example, to allow anyone with `TICKET_MODIFY` to perform the `_reset` action, the workflow action would need to be defined:
+
+```#!ini
+_reset = -> new
+_reset.label = reset
+_reset.operations = reset_workflow
+_reset.permissions = TICKET_MODIFY
+_reset.default = 0
+```
+
+## Workflow Visualization
+
+Workflows can be visualized by rendering them on the wiki using the [WikiMacros#Workflow-macro Workflow macro].
+
+Workflows can also be visualized using the `contrib/workflow/workflow_parser.py` script. The script outputs `.dot` files that [GraphViz](http://www.graphviz.org) understands. The script can be used as follows (your install path may be different):
+
+```#!sh
+cd /var/local/trac_devel/contrib/workflow/
+sudo ./showworkflow /srv/trac/PlannerSuite/conf/trac.ini
+```
+And then open up the resulting `trac.pdf` file created by the script. It will be in the same directory as the `trac.ini` file.
+
+After you have changed a workflow, you need to restart your webserver for the changes to take effect.
+
+## Example: Adding optional Testing with Workflow
+
+By adding the following to your [ticket-workflow] section of trac.ini you get optional testing. When the ticket has status `new`, `accepted` or `needs_work`, you can choose to submit it for testing.  When it's in the testing status the user gets the option to reject it and send it back to `needs_work`, or pass the testing and send it along to `closed`. If they accept it, then it is automatically marked as `closed` and the resolution is set to `fixed`. Since all the old work flow remains, a ticket can skip this entire section.
+
+```#!ini
+testing = new,accepted,needs_work,assigned,reopened -> testing
+testing.label = Submit to reporter for testing
+testing.permissions = TICKET_MODIFY
+
+reject = testing -> needs_work
+reject.label = Failed testing, return to developer
+
+pass = testing -> closed
+pass.label = Passes Testing
+pass.operations = set_resolution
+pass.set_resolution = fixed
+```
+
+### How to combine the `tracopt.ticket.commit_updater` with the testing workflow
+
+The [[trac:source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] is the optional component that [[TracRepositoryAdmin#trac-post-commit-hook|replaces the old trac-post-commit-hook]], in Trac 0.12.
+
+By default it reacts on some keywords found in changeset message logs like *close*, *fix* etc. and performs the corresponding workflow action.
+
+If you have a more complex workflow, like the testing stage described above and you want the *closes* keyword to move the ticket to the *testing* status instead of the *closed* status, you need to adapt the code a bit.
+
+Have a look at the [[trac:wiki:0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 recipe]] for the `trac-post-commit-hook`, this will give you some ideas about how to modify the component.
+
+## Example: Add simple optional generic review state
+
+Sometimes Trac is used in situations where "testing" can mean different things to different people so you may want to create an optional workflow state that is between the default workflow's `assigned` and `closed` states, but does not impose implementation-specific details. The only new state you need to add for this is a `reviewing` state. A ticket may then be "submitted for review" from any state that it can be reassigned. If a review passes, you can re-use the `resolve` action to close the ticket, and if it fails you can re-use the `reassign` action to push it back into the normal workflow.
+
+The new `reviewing` state along with its associated `review` action looks like this:
+
+```#!ini
+review = new,assigned,reopened -> reviewing
+review.operations = set_owner
+review.permissions = TICKET_MODIFY
+```
+
+Then, to integrate this with the default Trac 0.11 workflow, you also need to add the `reviewing` state to the `accept` and `resolve` actions:
+
+```#!ini
+accept = new,reviewing -> assigned
+[…]
+resolve = new,assigned,reopened,reviewing -> closed
+```
+
+Optionally, you can also add a new action that allows you to change the ticket's owner without moving the ticket out of the `reviewing` state. This enables you to reassign review work without pushing the ticket back to the `new` status:
+
+```#!ini
+reassign_reviewing = reviewing -> *
+reassign_reviewing.label = reassign review
+reassign_reviewing.operations = set_owner
+reassign_reviewing.permissions = TICKET_MODIFY
+```
+
+The full `[ticket-workflow]` configuration will thus look like this:
+
+```#!ini
+[ticket-workflow]
+create = <none> -> new
+create.default = 1
+create_and_assign = <none> -> assigned
+create_and_assign.label = assign
+create_and_assign.permissions = TICKET_MODIFY
+create_and_assign.operations = may_set_owner
+accept = new,reviewing -> assigned
+accept.operations = set_owner_to_self
+accept.permissions = TICKET_MODIFY
+leave = * -> *
+leave.default = 1
+leave.operations = leave_status
+reassign = new,assigned,accepted,reopened -> assigned
+reassign.operations = set_owner
+reassign.permissions = TICKET_MODIFY
+reopen = closed -> reopened
+reopen.operations = del_resolution
+reopen.permissions = TICKET_CREATE
+resolve = new,assigned,reopened,reviewing -> closed
+resolve.operations = set_resolution
+resolve.permissions = TICKET_MODIFY
+review = new,assigned,reopened -> reviewing
+review.operations = set_owner
+review.permissions = TICKET_MODIFY
+reassign_reviewing = reviewing -> *
+reassign_reviewing.operations = set_owner
+reassign_reviewing.label = reassign review
+reassign_reviewing.permissions = TICKET_MODIFY
+```
+
+## Example: Limit the resolution options for a new ticket
+
+The above `resolve_new` operation allows you to set the possible resolutions for a new ticket. By modifying the existing resolve action and removing the new status from before the `->` we then get two resolve actions. One with limited resolutions for new tickets, and then the regular one once a ticket is accepted.
+
+```#!ini
+resolve_new = new -> closed
+resolve_new.label = resolve
+resolve_new.operations = set_resolution
+resolve_new.permissions = TICKET_MODIFY
+resolve_new.set_resolution = invalid,wontfix,duplicate
+
+resolve = assigned,accepted,reopened -> closed
+resolve.operations = set_resolution
+resolve.permissions = TICKET_MODIFY
+```
+
+## Advanced Ticket Workflow Customization
+
+If the customizations above do not meet your needs, you can extend the workflow with plugins. Plugins can provide additional operations for the workflow, like code_review, or implement side-effects for an action, such as triggering a build, that may not be merely simple state changes. Look at [trac:source:trunk/sample-plugins/workflow sample-plugins/workflow] for a few examples to get started.
+
+But if even that is not enough, you can disable the ConfigurableTicketWorkflow component and create a plugin that completely replaces it.
+
+## Adding Workflow States to Milestone Progress Bars
+
+If you add additional states to your workflow, you may want to customize your milestone progress bars as well. See [TracIni#milestone-groups-section TracIni].
+
+## Ideas for next steps
+
+Enhancement ideas for the workflow system should be filed as enhancement tickets against the [ticket system] component.  You can also document ideas on the [trac:TracIdeas/TracWorkflow TracIdeas/TracWorkflow] page. Also look at the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin](trac:query:?status=assigned&status=new&status=reopened&keywords=~workflow&component=ticket+system) as it provides experimental operations.
diff --git a/raw-wiki-dump/UpgradeToKSNG.md b/raw-wiki-dump/UpgradeToKSNG.md
new file mode 100644
index 0000000..d33c834
--- /dev/null
+++ b/raw-wiki-dump/UpgradeToKSNG.md
@@ -0,0 +1,192 @@
+[[PageOutline]]
+
+# Upgrading Cryptech Alpha HSM to "ksng" development package
+
+This page attempts to explain the upgrade procedure for testing out
+the new "ksng" development branch of the Cryptech Alpha firmware.
+
+## Cavats
+
+This particular upgrade is more complicated than we would have
+preferred, due to the interaction of two unrelated factors:
+
+1. As the name (obscurely) implies, the main feature in the ksng
+   branch is a completely new HSM keystore implementation, which makes
+   better use of the Alpha's keystore flash, allows a much larger
+   number of keys, removes the need for an SQL database on the host,
+   gets your laundry 25% brighter, and leaves your breath alone.
+
+   We did not attempt to provide any sort of backwards compatability
+   to the old minimalistic keystore implementation, so this upgrade
+   process will wipe your keystore.  Sorry.  More importantly (from
+   the limited viewpoint of the upgrade process), it will change how
+   the HSM stores its PINs, which complicates the upgrade process.
+
+2. The "Device Field Upgrade" (DFU) capability in the Alpha's firmware
+   was a last-minute addition before the Berlin workshop in July 2016,
+   and, as last minute additions often do, it turned out to be buggy.
+   There are three distinct pieces of software involved in the upgrade
+   process, and they were all slightly buggy, in different ways.
+   Because of this, one must perform the upgrade steps in a particular
+   order to avoid bricking the HSM.  The upgrade includes fixes for
+   all the (known) bugs in the DFU process, so we hope that this will
+   be a one-time annoyance (famous last words).
+
+If something goes horribly wrong and you do somehow manage to brick
+your Alpha, don't give up, recovery is still possible, it just
+requires an ST-LINK debugger and cable (more on this below).
+
+## Overview
+
+Because of the tricky nature of this particular upgrade, you must
+perform these steps, in the specified order:
+
+
+* Install the new host software package using APT or Homebrew.
+* Wipe the HSM keystore to reset PINs back to the "factory" state.
+* Upgrade the main HSM firmware.
+* Upgrade the HSM bootloader.
+* Log in to upgraded HSM to set PINs, etc.
+
+
+**Upgrading the bootloader before the main firmware will brick your
+Alpha.**  So don't do that.
+
+All of the operations here use the Alpha's "management" (MGMT) port,
+so that cable must be connected to your Linux or OSX host machine.
+
+This upgrade procedure was tested on Debian Jessie, with an Alpha
+whose firmware had been rolled back to the version from the Berlin
+workshop (APT/Homebrew package version 2.0.1468584175, commit
+cd445b69b2caa7205f4e1c368aa2c6bf8c2d7692 in repository
+https://git.cryptech.is/releng/alpha.git).
+
+## Install cryptech-alpha-ksng package using apt-get or Homebrew
+
+Binaries for the "ksng" branch are available as a separate set of
+"cryptech-alpha-ksng" packages, which replace the "cryptech-alpha"
+packages for the master branch.  This seemed the simplest way of
+letting people experiment with the new code while falling back to the
+old if necessary.  The "cryptech-alpha-ksng" packages are declared to
+conflict with the "cryptech-alpha" packages, because they install
+programs by the same name in the same places and you need the version
+of the host software which goes with the HSM firmware your running.
+
+APT handles package conflicts differently from the way that Homebrew
+does.  If you have "cryptech-alpha" installed and try to install
+"cryptech-alpha-ksng", APT assumes you meant what you said and will
+just replace the old package with the new one.  Homebrew, on the other
+hand, reports the conflict and refuses to proceed until you sort it out.
+
+The following assumes that you already had the Cryptech APT repository
+or Homebrew tap configured; if not, see  [[wiki:BinaryPackages]].
+
+### Installing cryptech-alpha-ksng package using apt-get on Debian or Ubuntu Linux
+
+```
+$ sudo apt-get update
+$ sudo apt-get install cryptech-alpha-ksng
+```
+
+### Installing cryptech-alpha-ksng package using Homebrew on OSX
+
+```
+$ brew update
+$ brew uninstall cryptech-alpha
+$ brew install cryptech-alpha-ksng
+```
+
+## Set usual CRYPTECH_* environment variables
+
+The upgrade process uses the `CRYPTECH_CTY_CLIENT_SERIAL_DEVICE`
+environment variable.  The easiest way to set it is by using the
+`cryptech_probe` script, just as you would for other usage of the
+Alpha.
+
+```
+$ eval `cryptech_probe -v`
+```
+
+## Clear the keystore flash
+
+Sorry about this.  Yes, we know we need backup and restore, we'll get
+there.  But for this upgrade, it's safest to wipe the keystore.
+
+```
+$ cryptech_miniterm
+
+Username: wheel
+Password: <your-wheel-pin-goes-here>
+
+cryptech> keystore erase YesIAmSure
+
+^]
+```
+
+## Upgrade the main HSM firmware
+
+```
+$ cryptech_upload --firmware --user wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+```
+
+## Upgrade the bootloader
+
+```
+$ cryptech_upload --bootloader --user wheel --simon-says-whack-my-bootloader
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+```
+
+## Log in and set PINs, masterkey, etcetera
+
+```
+$ cryptech_miniterm
+
+Username: wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+
+cryptech> keystore set pin wheel fnord
+cryptech> keystore set pin so    fnord
+cryptech> keystore set pin user  fnord
+cryptech> masterkey set
+
+^]
+```
+
+## What to do if you manage to brick your Alpha
+
+If the above procedure somehow goes horribly wrong and bricks your
+alpha, you can still recover, but you'll need an ST-LINK programmer.
+There's some discussion of this at [[wiki:GitRepositories/sw/stm32]].
+
+Possible sources for the ST-LINK programmer and a suitable cable:
+
+
+* http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyNUCLEO-F411RE
+* https://www.sparkfun.com/products/10376
+
+
+These are relatively cheap, you'll probably pay as much for the
+postage as for the parts themselves.  If you have a better source, go
+for it.
+
+The programmer is the important part, you can use any sort of cabling
+you like so long as it connects the right pins of the programmer to
+the corresponding pins on the Alpha; the SparkFun cable just happens
+to be a tidy package which matches the relevant SWD headers.
+
+We'll include a more detailed description of the recovery process here
+if anybody needs it, but the short version is:
+
+
+* Install OpenOCD on your host machine.
+* Open up the Alpha's case, take the board out.
+* Connect the programmer and power the board back up.
+* Use the `flash-target` script from the `sw/stm32` repository to
+
+  stuff the `hsm.elf` and `bootloader.elf` files from the binary
+  firmware tarball into the HSM.
+
+* Power down, disconnect the programmer, put the Alpha back in its
+
+  case, done.
diff --git a/raw-wiki-dump/Upgrading.md b/raw-wiki-dump/Upgrading.md
new file mode 100644
index 0000000..bfc9106
--- /dev/null
+++ b/raw-wiki-dump/Upgrading.md
@@ -0,0 +1,190 @@
+ [[PageOutline]]
+
+# Upgrading the Cryptech Alpha HSM
+
+This page explains how to upgrade the Cryptech Alpha firmware, bootloader,
+and FPGA bitstream (as needed).
+
+All of the operations here use the Alpha's "management" (MGMT) port,
+so that cable must be connected to your Linux or OSX host machine.
+
+## Upgrading from the stock firmware (Berlin workshop or CrowdSupply)
+
+The main feature of the 3.0 firmware release is a completely new HSM
+keystore implementation, which makes better use of the Alpha's keystore
+flash, allows a much larger number of keys, and removes the need for an
+SQL database on the host. (See ReleaseNotes.)
+
+We did not attempt to provide any sort of backwards compatability to the
+original minimalistic keystore implementation, so this upgrade process
+will wipe your keystore. Sorry. More importantly (from the limited
+viewpoint of the upgrade process), it will change how the HSM stores its
+PINs, which complicates the upgrade process.
+
+Because we use the bootloader to upgrade the firmware, and the firmware to
+upgrade the bootloader, both use the PINs stored in the keystore to login,
+so both need to understand the new keystore, so both need to be upgraded.
+
+Because of the tricky nature of this particular upgrade, you must
+perform these steps, in the specified order:
+
+
+* Install the new host software package using APT or Homebrew.
+* Wipe the HSM keystore to reset PINs back to the "factory" state.
+* Upgrade the main HSM firmware.
+* Upgrade the HSM bootloader.
+* Log in to upgraded HSM to set PINs, etc.
+
+
+**Upgrading the bootloader before the main firmware will brick your
+Alpha.**  So don't do that.
+
+If something goes horribly wrong and you do somehow manage to brick
+your Alpha, see DisasterRecovery.
+
+## Upgrading from 'ksng'
+
+A few intrepid users are already testing the 'ksng' development branch,
+using the instructions at [wiki:UpgradeToKSNG]. In this case, and with future
+upgrades, it it not necessary to either wipe the keystore or upgrade the
+bootloader.
+
+
+* Install the new host software package using APT or Homebrew.
+* Upgrade the main HSM firmware.
+
+
+## Install the cryptech-alpha package
+
+### using apt-get on Debian or Ubuntu Linux
+
+```
+$ sudo apt-get update
+$ sudo apt-get install cryptech-alpha
+```
+
+Yes, you have to install it even if you already had it installed, because
+APT wants permission before accepting the new package dependencies.
+
+Or you could instead run:
+
+```
+$ sudo apt-get upgrade --with-new-pkgs
+```
+
+but that might upgrade unrelated stuff.
+
+If you had the '-ksng' package installed, you might then want to run:
+
+```
+$ sudo apt-get remove cryptech-alpha-ksng
+$ sudo apt-get autoclean
+```
+
+but nothing terrible is likely to happen if you omit those steps.
+
+If you're running on Debian Jessie, you may need to enable [`jessie-backports`](https://backports.debian.org/Instructions/) and make sure you're getting the `python-serial` and `python-tornado` dependencies from the backports (the versions of those packages in the base Debian Jessie distribution are too old).
+
+### using Homebrew on OSX
+
+If you're upgrading from the original firmware (have not installed the `-ksng` package), a normal Homebrew upgrade cycle
+should suffice:
+
+```
+$ brew update
+$ brew upgrade
+```
+
+If you have the `-ksng` package installed, you need to tell Homebrew that you want to switch back:
+
+```
+$ brew update
+$ brew migrate cryptech-alpha-ksng
+$ brew update
+```
+
+In either case, you might then want to do something like:
+
+```
+$ brew cleanup
+```
+
+but nothing terrible is likely to happen if you omit that step.
+
+If you've tried doing this and nothing happens, you might be hitting a known old bug in Homebrew itself.  Make sure your copy of Homebrew is up to date, and if that still doesn't work, try deinstalling whichever `cryptech-alpha*` package you have installed and reinstalling `cryptech-alpha`.
+
+## Set usual CRYPTECH_* environment variables
+
+The upgrade process uses the `CRYPTECH_CTY_CLIENT_SERIAL_DEVICE`
+environment variable.  The easiest way to set it is by using the
+`cryptech_probe` script, just as you would for other usage of the
+Alpha.
+
+```
+$ eval `cryptech_probe`
+```
+
+(Note: you can use the new `cryptech_muxd` and `cryptech_console`, but
+these instructions assume you are familiar with `cryptech_miniterm`. Or
+you could be using `picocom` or `kermit` or something else. Doesn't matter
+to us.)
+
+## Clear the keystore flash
+
+If you are upgrading from the original firmware, you will need to wipe the
+keystore, to avoid confusing the new keystore code.
+
+The good news is that we have a utility to back up and restore the new
+keystore. The bad news is that we don't	have a way to back up the old
+keystore.
+
+```
+$ cryptech_miniterm
+
+Username: wheel
+Password: <your-wheel-pin-goes-here>
+
+cryptech> keystore erase YesIAmSure
+
+^]
+```
+
+## Upgrade the main HSM firmware
+
+```
+$ cryptech_upload --firmware --user wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+```
+
+## Upgrade the bootloader
+
+```
+$ cryptech_upload --bootloader --user wheel --simon-says-whack-my-bootloader
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+```
+
+## (Optional) Upgrade the FPGA bitstream
+
+This upgrade includes an experimental ECDSA point multiplier in hardware,
+which the firmware will use if present.
+
+```
+$ cryptech_upload --fpga --user wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+```
+
+## Log in and set PINs, masterkey, etcetera
+
+```
+$ cryptech_miniterm
+
+Username: wheel
+PIN: YouReallyNeedToChangeThisPINRightNowWeAreNotKidding
+
+cryptech> keystore set pin wheel fnord
+cryptech> keystore set pin so    fnord
+cryptech> keystore set pin user  fnord
+cryptech> masterkey set
+
+^]
+```
diff --git a/raw-wiki-dump/UsingSTLink.md b/raw-wiki-dump/UsingSTLink.md
new file mode 100644
index 0000000..02cc21e
--- /dev/null
+++ b/raw-wiki-dump/UsingSTLink.md
@@ -0,0 +1,98 @@
+# Using ST-LINK
+
+ST-LINK is STM's implementation of the [| Serial Wire Debug (SWD)](https://developer.arm.com/products/architecture/cpu-architecture/debug-visibility-and-trace/coresight-architecture/serial-wire-debug) protocol.
+Think of it as JTAG if you're more comfortable with that.
+
+## Getting an ST-LINK programmer
+
+ST-LINK is built into all(?) of STM's Nucleo and Discovery evaluation
+boards, which can be had for as little as US$10 from [Mouser](http://mouser.com)
+or [element14] ([http://newark.com Newark](http://element14.com) in
+the Americas, [Farnell](http://farnell.com) in Europe).
+
+We have tested with STM32F0DISCOVERY and STM32F4DISCOVERY (both with ST-LINK
+v2.0) and NUCLEO-F411RE (with ST-LINK v2.1).
+
+### Connecting the ST-LINK programmer to the Alpha
+
+On the STM board, remove the pair of ST-LINK jumpers (CN4 on the F4DISCO,
+CN2 on the F0DISCO and NUCLEO). Then locate the 6-pin SWD header (CN3 on
+the F0DISCO, CN2 on the F4DISCO, CN4 on the NUCLEO), and connect it to J1
+on the Alpha board (top, just left of center).
+
+This photo shows the correct orientation of the cables (both boards
+oriented so that the logo is right-side up):
+
+[[Image(IMG_20170512_205557_s.jpg)]]
+
+NOTE: The STM boards have an unfortunate tendency to short unexpectedly, so
+I recommend putting them in an enclosure. In this case, I've cut holes in
+the original packaging.
+
+## Install OpenOCD and the debugger
+
+```
+$ apt-get install gdb-arm-none-eabi openocd
+```
+
+## Get the `debug` and `flash-target` scripts
+
+If you don't already have a cryptech source tree somewhere, get the source distribution, e.g.
+```
+$ apt-get source cryptech-alpha
+```
+
+The scripts are in `sw/stm32/bin`.
+
+## Re-flashing the Alpha
+
+### To reflash with our binary firmware
+```
+$ tar xfz /usr/share/cryptech-alpha-firmware.tar.gz
+$ flash-target hsm
+```
+
+
+What you should see is something like:
+```
+** Programming Started **
+auto erase enabled
+Info : device id = 0x20016419
+Info : flash size = 2048kbytes
+Info : Dual Bank 2048 kiB STM32F42x/43x/469/479 found
+target halted due to breakpoint, current mode: Thread
+xPSR: 0x61000000 pc: 0x20000046 msp: 0x2002fffc
+wrote 524288 bytes from file projects/hsm/hsm.elf in 12.344705s (41.475 KiB/s)
+** Programming Finished **
+** Verify Started **
+target halted due to breakpoint, current mode: Thread
+xPSR: 0x61000000 pc: 0x2000002e msp: 0x2002fffc
+target halted due to breakpoint, current mode: Thread
+xPSR: 0x61000000 pc: 0x2000002e msp: 0x2002fffc
+verified 509100 bytes in 0.953672s (521.320 KiB/s)
+** Verified OK **
+** Resetting Target **
+Info : Unable to match requested speed 2000 kHz, using 1800 kHz
+Info : Unable to match requested speed 2000 kHz, using 1800 kHz
+adapter speed: 1800 kHz
+shutdown command invoked
+```
+
+
+### To reflash with firmware you built from source
+
+See BuildingFromSource.
+
+## Debugging the Alpha
+
+This site shows several ways to use various debuggers to debug the
+firmware in an STM32:
+
+    http://fun-tech.se/stm32/OpenOCD/gdb.php
+
+There is a shell script called 'bin/debug' that starts an OpenOCD server
+and GDB:
+
+```
+$ sw/stm32/bin/debug projects/hsm/hsm
+```
diff --git a/raw-wiki-dump/WhoWeAre.md b/raw-wiki-dump/WhoWeAre.md
new file mode 100644
index 0000000..bed3562
--- /dev/null
+++ b/raw-wiki-dump/WhoWeAre.md
@@ -0,0 +1,40 @@
+# Who We Are
+
+This effort was started at the suggestion of Russ Housley, Stephen Farrell, and Jari Arkko of the IETF, to meet the assurance needs of supporting IETF protocols in an open and transparent manner.
+
+But this is not an IETF, ISOC, ... project.  As the saying goes, we work for the Internet.
+
+## Tech Core
+
+Fredrik Thulin\\
+Jakob Schlyter\\
+[[Joachim Strömbergson]]\\
+Leif Johansson\\
+Linus Nordberg\\
+Lucy Lynch\\
+Patrik Wallström \\
+Павел Шатов (Pavel Shatov)\\
+Peter Stuge\\
+[Randy Bush](https://psg.com/~randy)\\
+[Austein]]([https://www.hactrn.net/sra/|Rob)\\
+Steven Bellovin\\
+Basil Dolmatov\\
+
+```#!comment == Technical Help ==
+Bart Preneel ![0]\\
+Tero Kivinenv ![0]\\
+```
+
+## IETF Help
+
+Russ Housley\\
+Sean Turner\\
+Stephen Farrell\\
+
+## Coordination
+
+Leif Johansson - Administration\\
+Randy Bush - Technical\\
+Russ Housley / Lynn StAmour - Finding Funding\\
+
+------
diff --git a/raw-wiki-dump/WikiDeletePage.md b/raw-wiki-dump/WikiDeletePage.md
new file mode 100644
index 0000000..49fcbfb
--- /dev/null
+++ b/raw-wiki-dump/WikiDeletePage.md
@@ -0,0 +1,16 @@
+# Deleting a Wiki Page
+
+Wiki pages can be completely deleted using the //Delete page// or the //Delete this version// button at the bottom of the wiki page. These buttons are only visible for users that have the `WIKI_DELETE` permission.
+
+**Note:** Deleting a wiki page is an irreversible operation.
+
+Deleting specific versions or even complete pages can make sense to remove spam or other abusive submissions.
+
+However, if you want to delete a page because you re-created a new page with the same content but a different name, it is recommended to keep the page and use it as a redirection page instead of completely deleting it. This will avoid frustrating the visitor with broken links, particularly when coming to the site from a search engine.
+
+In this situation, chances are that you actually wanted to [[WikiNewPage#renaming|rename]] the page instead of doing a copy and delete.
+The //Rename// operation offers you the possibility to create a redirection page.
+A redirection page is a short page that  contains a link such as  “See SomeOtherPage”.
+
+----
+See also: TracWiki, TracPermissions
diff --git a/raw-wiki-dump/WikiFormatting.md b/raw-wiki-dump/WikiFormatting.md
new file mode 100644
index 0000000..3af054f
--- /dev/null
+++ b/raw-wiki-dump/WikiFormatting.md
@@ -0,0 +1,1093 @@
+# WikiFormatting
+
+[[TracGuideToc]]
+
+Wiki markup is a core feature in Trac, tightly integrating all the other parts of Trac into a flexible and powerful whole.
+
+Trac has a built-in small and powerful wiki rendering engine. This wiki engine implements a growing subset of the commands from other popular Wikis, especially [MoinMoin] and [trac:WikiCreole](http://moinmo.in/).
+
+This page will give you an in-depth explanation of the wiki markup available anywhere WikiFormatting is allowed.
+
+The sections below provide an overview for the most common syntax, each link in the *Category* column will lead you to the more detailed explanation later in this page.
+
+A few other wiki pages present the advanced features of the Trac wiki markup in more depth:
+
+    - TracLinks covers all the possible ways to refer precisely to any Trac resource or parts thereof.
+    - WikiPageNames covers the various names a wiki page can take, whether in CamelCase or not.
+    - WikiMacros lists the macros available for generating dynamic content.
+    - WikiProcessors and WikiHtml details how parts of the wiki text can be processed in special ways.
+    - [trac:wiki:TracDev/Proposals/AdvancedWikiOperations AdvancedWikiOperations] provides some operations in uncommon or administrative scenarios.
+
+
+## Common wiki markup
+
+| **Category** | **Wiki Markup** | **Display** |
+|---|---|---|
+
+|-----------------------------------------------------------
+```#!th rowspan=3
+[#FontStyles Font Styles]
+```
+| `**bold**`, `*italic*`, `***Wikipedia style***` | \
+|---|
+| **bold**, *italic*, ***Wikipedia style*** |
+| ````monospaced (*other markup ignored*)```` | \
+| `monospaced (*other markup ignored*)` |
+| `**bold**`, `//italic//`, `**//WikiCreole style//**` | \
+| **bold**, //italic//, **//WikiCreole style//** |
+
+|-----------------------------------------------------------
+| [#Headings Headings] |\
+|---|
+```#!td
+ ```
+ == Level 2
+ === Level 3 ^([#hn note])^
+
+ ```
+```
+```#!td style="padding-left: 2em"
+== Level 2
+=== Level 3 ^([#hn note])^
+```
+|-----------------------------------------------------------
+| [#Paragraphs Paragraphs]  |\
+|---|
+```#!td
+ ```
+ First paragraph
+ on multiple lines.
+
+ Second paragraph.
+
+ ```
+```
+```#!td
+First paragraph
+on multiple lines.
+
+Second paragraph.
+```
+|-----------------------------------------------------------
+| [#Lists Lists] |\
+|---|
+```#!td
+ ```
+ * bullet list
+   on multiple lines
+   1. nested list
+     a. different numbering
+        styles
+
+ ```
+```
+```#!td
+* bullet list
+  on multiple lines
+  1. nested list
+    a. different numbering
+       styles
+```
+|-----------------------------------------------------------
+```#!th
+[#DefinitionLists Definition Lists]
+```
+```#!td
+ ```
+  term:: definition on
+         multiple lines
+ ```
+```
+```#!td
+ term:: definition on
+        multiple lines
+```
+|-----------------------------------------------------------
+| [#PreformattedText Preformatted Text] |\
+|---|
+```#!td
+ ```
+ ```
+ multiple lines, ''no wiki''
+       white space respected
+
+ ```
+ ```
+```
+```#!td
+ ```
+ multiple lines, ''no wiki''
+       white space respected
+ ```
+```
+|-----------------------------------------------------------
+| [#Blockquotes Blockquotes] |\
+|---|
+```#!td
+ ```
+   if there's some leading
+   space the text is quoted
+
+ ```
+```
+```#!td
+ if there's some leading
+ space the text is quoted
+```
+|-----------------------------------------------------------
+| [#DiscussionCitations Discussion Citations] |\
+|---|
+```#!td
+ ```
+ >> ... (I said)
+ > (he replied)
+
+ ```
+```
+```#!td
+>>... (I said)
+> (he replied)
+```
+|-----------------------------------------------------------
+| [#Tables Tables] |\
+|---|
+```#!td
+ ```
+ ||= Table Header =|| Cell ||
+ ||||  (details below)  ||
+
+ ```
+```
+```#!td
+||= Table Header =|| Cell ||
+||||  (details below)  ||
+```
+|-----------------------------------------------------------
+```#!th rowspan=2
+[#Links Links]
+```
+| `http://trac.edgewall.org` |\
+|---|
+| http://trac.edgewall.org |
+| `WikiFormatting (CamelCase)` |\
+| WikiFormatting (CamelCase) |
+
+|-----------------------------------------------------------
+```#!th rowspan=5
+[#TracLinks TracLinks]
+```
+| `wiki:WikiFormatting`, `wiki:"WikiFormatting"` |\
+|---|
+| wiki:WikiFormatting, wiki:"WikiFormatting" |
+| `#1 (ticket)`, `[1] (changeset)`, `{1} (report)` |\
+| #1 (ticket), [1] (changeset), {1} (report) |
+| `ticket:1, ticket:1#comment:1` |\
+| ticket:1, ticket:1#comment:1 |
+| `Ticket [ticket:1]`, `[ticket:1 ticket one]` |\
+| Ticket [ticket:1], [ticket:1 ticket one] |
+| `Ticket [[ticket:1]]`, `[[ticket:1|ticket one]]` |\
+| Ticket [[ticket:1]], [[ticket:1|ticket one]] |
+
+|-----------------------------------------------------------
+```#!th rowspan=2
+[#SettingAnchors Setting Anchors]
+```
+| `[=#point1 (1)] First...` |\
+|---|
+| [=#point1 (1)] First... |
+| `see [#point1 (1)]` |\
+| see [#point1 (1)] |
+
+|-----------------------------------------------------------
+```#!th rowspan=3
+[#Escaping Escaping Markup]
+```
+| `!* doubled quotes` |\
+|---|
+| !* doubled quotes |
+| `wiki:WikiFormatting`, `WikiFormatting` |\
+| wiki:WikiFormatting, WikiFormatting |
+| [[html(<code>````-```` triple curly brackets</code>)]] |\
+| ````-```` triple curly brackets |
+
+|-----------------------------------------------------------
+| [#Images Images] | `[[Image(`*link*`)]]` | [[Image(htdocs:../common/trac_logo_mini.png)]] |
+|---|---|---|
+
+|-----------------------------------------------------------
+```#!th rowspan=2
+[#Macros Macros]
+```
+| `[[MacroList(*)]]` |  *(short list of all available macros)*  |
+|---|---|
+| `[[Image?]]` |  *(help for the Image macro)*  |
+
+|-----------------------------------------------------------
+| [#Processors Processors] |\
+|---|
+```#!td
+ ```
+ ```
+ #!div style="font-size: 80%"
+ Code highlighting:
+   ```#!python
+   hello = lambda: "world"
+
+   ```
+ ```
+ ```
+```
+```#!td style="padding-left: 2em"
+ ```
+ #!div style="font-size: 80%"
+ Code highlighting:
+   ```#!python
+   hello = lambda: "world"
+   ```
+ ```
+```
+|-----------------------------------------------------------
+| [#Comments Comments] |\
+|---|
+```#!td
+ ```
+ ```#!comment
+ Note to Editors: ...
+
+ ```
+ ```
+```
+```#!td style="padding-left: 2em"
+ ```#!comment
+ Note to Editors: ...
+ ```
+```
+|-----------------------------------------------------------
+| [#Miscellaneous Miscellaneous] |\
+|---|
+```#!td
+ ```
+ Line [[br]] break
+ Line \\ break
+ ----
+
+ ```
+```
+```#!td style="padding-left: 2em"
+Line [[br]] break
+Line \\ break
+----
+```
+
+## Font Styles
+
+The Trac wiki supports the following font styles:
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+   * '''bold''',
+     ''' triple quotes !'''
+     can be bold too if prefixed by ! ''',
+   * ''italic''
+   * '''''bold italic''''' or ''italic and
+     ''' italic bold ''' ''
+   * __underline__
+
+
+    * ```monospace``` or `monospace`
+
+     (hence ````` or ``````` quoting)
+
+    * <s>strike-through</s>
+    * ^superscript^
+    * ,,subscript,,
+    * **also bold**, //italic as well//,
+
+     and *** bold italic *** //(since 0.12)//
+
+    * [[span(style=color: #FF0000, a red text )]]
+
+  ```
+```
+```#!td
+ * '''bold''',
+   ''' triple quotes !'''
+   can be bold too if prefixed by ! ''',
+ * ''italic''
+ * '''''bold italic''''' or ''italic and
+   ''' italic bold ''' ''
+ * __underline__
+
+    * ```monospace``` or `monospace`
+
+   (hence ````` or ``````` quoting)
+
+    * <s>strike-through</s>
+    * ^superscript^
+    * ,,subscript,,
+    * **also bold**, //italic as well//,
+
+   and *** bold italic *** //(since 0.12)//
+
+    * [[span(style=color: #FF0000, a red text )]]
+
+```
+
+Notes:
+
+    * ````...```` and ````...```` commands not only select a monospace font, but also treat their content as verbatim text, meaning that no further wiki processing is done on this text.
+    * ``` ! ``` tells wiki parser to not take the following characters as wiki format, so pay attention to put a space after !, e.g. when ending bold.
+    * all the font styles marks have to be used in opening/closing pairs,
+
+   and they must nest properly; in particular, an `*` italic can't be paired
+   with a `//` one, and `**` can't be paired with `**`.
+
+## Headings
+
+You can create heading by starting a line with one up to six *equal* characters ("=") followed by a single space and the headline text.
+
+[=#hn]
+The headline text can be followed by the same number of "=" characters, but this is not mandatory. That is, `=== Section3 ===` is identical to `=== Section3`.
+
+Finally, the heading might optionally be followed by an explicit id. If not, an implicit but nevertheless readable id will be generated.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  = Heading =
+  == Subheading
+  === About ''this'' ===
+  === Explicit id === #using-explicit-id-in-heading
+  == Subheading #sub2
+
+```
+```
+```#!td style="padding: 1em;"
+  ```
+  #!div
+  = Heading =
+  == Subheading
+  === About ''this'' ===
+  === Explicit id === #using-explicit-id-in-heading
+  == Subheading #sub2
+  ```
+```
+
+## Paragraphs
+
+A new text paragraph is created whenever two blocks of text are separated by one or more empty lines.
+
+A forced line break can also be inserted, using:
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  Line 1[[BR]]Line 2
+
+  ```
+  ```
+  Paragraph
+  one
+
+  Paragraph
+  two
+  ```
+```
+```#!td
+  Line 1[[BR]]Line 2
+
+  Paragraph
+  one
+
+  Paragraph
+  two
+```
+
+## Lists
+
+The wiki supports both ordered/numbered and unordered lists.
+
+Example:
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+   * Item 1
+     * Item 1.1
+        * Item 1.1.1
+        * Item 1.1.2
+        * Item 1.1.3
+     * Item 1.2
+   * Item 2
+  - items can start at the beginning of a line
+    and they can span multiple lines
+    - be careful though to continue the line
+    with the appropriate indentation, otherwise
+  that will start a new paragraph...
+
+   1. Item 1
+     a. Item 1.a
+     a. Item 1.b
+        i. Item 1.b.i
+        i. Item 1.b.ii
+   1. Item 2
+  And numbered lists can also be restarted
+  with an explicit number:
+   3. Item 3
+
+  ```
+```
+```#!td
+ * Item 1
+   * Item 1.1
+      * Item 1.1.1
+      * Item 1.1.2
+      * Item 1.1.3
+   * Item 1.2
+ * Item 2
+- items can start at the beginning of a line
+  and they can span multiple lines
+  - be careful though to continue the line
+  with the appropriate indentation, otherwise
+that will start a new paragraph...
+
+ 1. Item 1
+   a. Item 1.a
+   a. Item 1.b
+      i. Item 1.b.i
+      i. Item 1.b.ii
+ 1. Item 2
+And numbered lists can also be restarted with an explicit number:
+ 3. Item 3
+```
+
+## Definition Lists
+
+The wiki also supports definition lists.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+   llama::
+     some kind of mammal, with hair
+   ppython::
+     some kind of reptile, without hair
+     (can you spot the typo?)
+
+  ```
+```
+```#!td
+ llama::
+   some kind of mammal, with hair
+ ppython::
+   some kind of reptile, without hair
+   (can you spot the typo?)
+```
+
+Note that you need a space in front of the defined term.
+
+## Preformatted Text
+
+Block containing preformatted text are suitable for source code snippets, notes and examples. Use three *curly braces* wrapped around the text to define a block quote. The curly braces need to be on a separate line.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ```
+  def HelloWorld():
+      print '''Hello World'''
+
+  ```
+  ```
+```
+```#!td
+  ```
+  def HelloWorld():
+      print '''Hello World'''
+  ```
+```
+
+Note that this kind of block is also used for selecting lines that should be processed through WikiProcessors.
+
+## Blockquotes
+
+In order to mark a paragraph as blockquote, indent that paragraph with two spaces.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+```
+Paragraph
+  This text is a quote from someone else.
+
+```
+```
+```#!td
+Paragraph
+  This text is a quote from someone else.
+```
+
+## Discussion Citations
+
+To delineate a citation in an ongoing discussion thread, such as the ticket comment area, email-like citation marks (">", ">>", etc.) may be used.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  >> Someone's original text
+  > Someone else's reply text
+  >  - which can be any kind of Wiki markup
+  My reply text
+
+  ```
+```
+```#!td
+>> Someone's original text
+> Someone else's reply text
+>  - which can be any kind of Wiki markup
+My reply text
+```
+
+## Tables
+### Simple Tables
+
+Simple tables can be created like this:
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ||Cell 1||Cell 2||Cell 3||
+  ||Cell 4||Cell 5||Cell 6||
+
+  ```
+```
+```#!td style="padding: 2em;"
+||Cell 1||Cell 2||Cell 3||
+||Cell 4||Cell 5||Cell 6||
+```
+
+Cell headings can be specified by wrapping the content in a pair of '=' characters.
+Note that the '=' characters have to stick to the cell separators, like this:
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ||        ||= stable =||= latest =||
+  ||= 0.10 =||  0.10.5  || 0.10.6dev||
+  ||= 0.11 =||  0.11.6  || 0.11.7dev||
+
+  ```
+```
+```#!td style="padding: 2em;"
+||        ||= stable =||= latest =||
+||= 0.10 =||  0.10.5  || 0.10.6dev||
+||= 0.11 =||  0.11.6  || 0.11.7dev||
+```
+
+Finally, specifying an empty cell means that the next non empty cell will span the empty cells. For example:
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  || 1 || 2 || 3 ||
+  |||| 1-2 || 3 ||
+  || 1 |||| 2-3 ||
+  |||||| 1-2-3 ||
+
+  ```
+```
+```#!td style="padding: 2em;"
+|| 1 || 2 || 3 ||
+|||| 1-2 || 3 ||
+|| 1 |||| 2-3 ||
+|||||| 1-2-3 ||
+```
+
+Note that if the content of a cell "sticks" to one side of the cell and only one, then the text will be aligned on that side. Example:
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ||=Text =||= Numbers =||
+  ||left align    ||        1.0||
+  ||  center      ||        4.5||
+  ||      right align||     4.5||
+  || default alignment ||   2.5||
+  ||default||         2.5||
+  ||  default ||      2.5||
+  || default ||       2.5||
+
+  ```
+```
+```#!td style="padding: 2em;"
+||=Text =||= Numbers =||
+||left align    ||        1.0||
+||  center      ||        4.5||
+||      right align||     4.5||
+|| default alignment ||   2.5||
+||default||         2.5||
+||  default ||      2.5||
+|| default ||       2.5||
+```
+
+If contrary to the example above, the cells in your table contain more text, it might be convenient to spread a table row over multiple lines of markup. The `\` character placed at the end of a line after a cell separator tells Trac to not start a new row for the cells on the next line.
+
+| Wiki Markup |
+|---|
+```#!td
+  ```
+  || this is column 1 [http://trac.edgewall.org/newticket new ticket] || \
+  || this is column 2 [http://trac.edgewall.org/roadmap the road ahead] || \
+  || that's column 3 and last one ||
+
+  ```
+```
+|-------------
+| Display |
+|---|
+```#!td style="padding: 2em;"
+|| this is column 1 [http://trac.edgewall.org/newticket new ticket] || \
+|| this is column 2 [http://trac.edgewall.org/roadmap the road ahead] || \
+|| that's column 3 and last one ||
+
+```
+
+### Complex Tables
+
+If the possibilities offered by the simple pipe-based markup ('||') for tables described above are not enough for your needs, you can create more elaborate tables by using [#Processors-example-tables WikiProcessor based tables].
+
+## Links
+
+Hyperlinks are automatically created for WikiPageNames and URLs. WikiPageLinks can be disabled by prepending an exclamation mark ('!'), such as ```WikiPageLink```.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  TitleIndex, http://www.edgewall.com/, !NotAlink
+
+  ```
+```
+```#!td
+TitleIndex, http://www.edgewall.com/, !NotAlink
+```
+
+Links can be given a more descriptive title by writing the link followed by a space and a title and all this inside square brackets.
+If the descriptive title is omitted, then the explicit prefix is discarded, unless the link is an external link. This can be useful for wiki pages not adhering to the WikiPageNames convention.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+   * [http://www.edgewall.com Edgewall Software]
+   * [wiki:TitleIndex Title Index]
+   * [wiki:TitleIndex]
+   * [wiki:ISO9000]
+
+  ```
+```
+```#!td
+   * [http://www.edgewall.com Edgewall Software]
+   * [wiki:TitleIndex Title Index]
+   * [wiki:TitleIndex]
+   * [wiki:ISO9000]
+```
+
+Following the [trac:WikiCreole] trend, the descriptive title can also be specified by writing the link followed by a pipe ('|') and a title and all this inside //double// square brackets.
+
+```#!td
+  ```
+   * [[http://www.edgewall.com|Edgewall Software]]
+   * [[wiki:TitleIndex|Title Index]]
+     or even [[TitleIndex|Title Index]]
+   * [[wiki:TitleIndex]]
+     ''' but not ![[TitleIndex]]! '''
+   * [[ISO9000]]
+  ```
+```
+```#!td
+   * [[http://www.edgewall.com|Edgewall Software]]
+   * [[wiki:TitleIndex|Title Index]]
+     or even [[TitleIndex|Title Index]]
+   * [[wiki:TitleIndex]]
+     ''' but not ![[TitleIndex]]! '''
+   * [[ISO9000]]
+```
+
+**Note**: the [trac:WikiCreole] style for links is quick to type and certainly looks familiar as it is the one used on Wikipedia and in many other wikis. Unfortunately it conflicts with the syntax for [#Macros macros].
+So in the rare case when you need to refer to a page which is named after a macro (typical examples being TitleIndex, InterTrac and InterWiki), by writing `[[TitleIndex]]` you will actually call the macro instead of linking to the page.
+
+## Trac Links
+
+Wiki pages can link directly to other parts of the Trac system. Pages can refer to tickets, reports, changesets, milestones, source files and other Wiki pages using the following notations:
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+   * Tickets: #1 or ticket:1
+   * Reports: {1} or report:1
+   * Changesets: r1, [1] or changeset:1
+   * ...
+   * targeting other Trac instances,
+     so called InterTrac links:
+     - Tickets: #Trac1 or Trac:ticket:1
+     - Changesets: [Trac1] or Trac:changeset:1
+
+  ```
+```
+```#!td
+ * Tickets: #1 or ticket:1
+ * Reports: {1} or report:1
+ * Changesets: r1, [1] or changeset:1
+ * ...
+ * targeting other Trac instances,
+   so called InterTrac links:
+   - Tickets: #Trac1 or Trac:ticket:1
+   - Changesets: [Trac1] or Trac:changeset:1
+```
+
+There are many more flavors of Trac links, see TracLinks for more in-depth information and a reference for all the default link resolvers.
+
+## Setting Anchors
+
+An anchor, or more correctly speaking, an [anchor name](http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2.1) can be added explicitly at any place in the Wiki page, in order to uniquely identify a position in the document:
+
+```
+[=#point1]
+```
+
+This syntax was chosen to match the format for explicitly naming the header id [#Headings documented above]. For example:
+```
+== Long title == #title
+```
+
+It is also very close to the syntax for the corresponding link to that anchor:
+```
+[#point1]
+```
+
+Optionally, a label can be given to the anchor:
+```
+[[=#point1 '''Point 1''']]
+```
+
+| Wiki Markup | Display |
+|---|---|
+
+|----------------------------------
+```#!td
+  ```
+  [#point2 jump to the second point]
+
+  ...
+
+  Point2:  [=#point2] Jump here
+  ```
+```
+```#!td
+  [#point2 jump to the second point]
+
+  ...
+
+  Point2:  [=#point2] Jump here
+```
+
+For more complex anchors (eg when a custom title is wanted), you can use the Span macro: `[[span(id=point2, class=wikianchor, title=Point 2, ^(2)^)]]`.
+
+## Escaping Links, WikiPageNames and other Markup == #Escaping
+
+You may avoid making hyperlinks out of TracLinks by preceding an expression with a single exclamation mark ('!').
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+   !NoHyperLink
+   !#42 is not a link
+
+  ```
+  ```
+Various forms of escaping for list markup:
+ ^^- escaped minus sign \\
+ ^^1. escaped number  \\
+ ^^* escaped asterisk sign
+  ```
+```
+```#!td
+ !NoHyperLink
+ !#42 is not a link
+
+Various forms of escaping for list markup:
+ ^^- escaped minus sign \\
+ ^^1. escaped number  \\
+ ^^* escaped asterisk sign
+```
+
+## Images
+
+Urls ending with `.png`, `.gif` or `.jpg` are no longer automatically interpreted as image links, and converted to `<img>` tags.
+
+You now have to use the ![[Image]] macro. The simplest way to include an image is to upload it as attachment to the current page, and put the filename in a macro call like `[[Image(picture.gif)]]`.
+
+In addition to the current page, it is possible to refer to other resources:
+
+    * `[[Image(wiki:WikiFormatting:picture.gif)]]` (referring to attachment on another page)
+    * `[[Image(ticket:1:picture.gif)]]` (file attached to a ticket)
+    * `[[Image(htdocs:picture.gif)]]` (referring to a file inside the [TracEnvironment environment] `htdocs` directory)
+    * `[[Image(source:/trunk/trac/htdocs/trac_logo_mini.png)]]` (a file in repository)
+
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  [[Image(htdocs:../common/trac_logo_mini.png)]]
+
+  ```
+```
+```#!td
+[[Image(htdocs:../common/trac_logo_mini.png)]]
+```
+
+See WikiMacros for further documentation on the `[[Image()]]` macro, which has several useful options (`title=`, `link=`, etc.)
+
+## Macros
+
+Macros are *custom functions* to insert dynamic content in a page.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  [[RecentChanges(Trac,3)]]
+
+  ```
+```
+```#!td style="padding-left: 2em"
+[[RecentChanges(Trac,3)]]
+```
+
+See WikiMacros for more information, and a list of installed macros.
+
+The detailed help for a specific macro can also be obtained more directly by appending a "?" to the macro name.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  [[MacroList?]]
+
+  ```
+```
+```#!td style="padding-left: 2em"
+[[MacroList?]]
+```
+
+## Processors
+
+Trac supports alternative markup formats using WikiProcessors. For example, processors are used to write pages in
+[wiki:WikiRestructuredText reStructuredText] or [wiki:WikiHtml HTML].
+
+| Wiki Markup | Display |
+|---|---|
+
+|--------------------------------------------------------
+```#!td align="center" colspan=2 style="border: 0px; font-size: 90%"
+
+   [=#Processors-example-html Example 1:] HTML
+
+```
+|--------------------------------------------------------
+```#!td style="border: 0px"
+  ```
+  ```
+  #!html
+  <h1 style="text-align: right; color: blue">
+   HTML Test
+  </h1>
+  ```
+  ```
+```
+```#!td valign="top"  style="border: 0px"
+
+```
+#!html
+<h1 style="text-align: right; color: blue">HTML Test</h1>
+```
+
+```
+|--------------------------------------------------------
+```#!td align="center" colspan=2 style="border: 0px; font-size: 90%"
+
+   [=#Processors-example-highlight Example 2:] Code Highlighting
+
+```
+|--------------------------------------------------------
+```#!td style="border: 0px"
+  ```
+  ```
+  #!python
+  class Test:
+
+      def __init__(self):
+          print "Hello World"
+  if __name__ == '__main__':
+     Test()
+  ```
+  ```
+```
+```
+#!td valign="top"  style="border: 0px"
+
+```
+#!python
+class Test:
+    def __init__(self):
+        print "Hello World"
+if __name__ == '__main__':
+   Test()
+```
+
+```
+|--------------------------------------------------------
+```#!td align="center" colspan=2 style="border: 0px; font-size: 90%"
+
+       [=#Processors-example-tables Example 3:] Complex Tables
+
+```
+|--------------------------------------------------------
+```#!td style="border: 0px"
+  ```
+  ```#!th rowspan=4 align=justify
+  With the `#td` and `#th` processors,
+  table cells can contain any content:
+  ```
+  |----------------
+  ```#!td
+    - lists
+    - embedded tables
+    - simple multiline content
+  ```
+  |----------------
+  ```#!td
+  As processors can be easily nested,
+  so can be tables:
+    ```#!th
+    Example:
+    ```
+    ```#!td style="background: #eef"
+    || must be at the third level now... ||
+    ```
+  ```
+  |----------------
+  ```#!td
+  Even when you don't have complex markup,
+  this form of table cells can be convenient
+  to write content on multiple lines.
+  ```
+  ```
+```
+```
+#!td  valign="top"  style="border: 0px"
+
+  ```#!th rowspan=4 align=justify
+  With the `#td` and `#th` processors,
+  table cells can contain any content:
+  ```
+  |----------------
+  ```#!td
+    - lists
+    - embedded tables
+    - simple multiline content
+  ```
+  |----------------
+  ```#!td
+  As processors can be easily nested,
+  so can be tables:
+    ```#!th
+    Example:
+    ```
+    ```#!td style="background: #eef"
+    || must be at the third level now... ||
+    ```
+  ```
+  |----------------
+  ```#!td
+  Even when you don't have complex markup,
+  this form of table cells can be convenient
+  to write content on multiple lines.
+  ```
+
+```
+
+See WikiProcessors for more information.
+
+## Comments
+
+Comments can be added to the plain text. These will not be rendered and will not display in any other format than plain text.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  Nothing to
+  ```
+  #!comment
+  Your comment for editors here
+
+  ```
+  see.
+  ```
+```
+```#!td
+  Nothing to
+  ```
+  #!comment
+  Your comment for editors here
+  ```
+  see.
+```
+
+## Miscellaneous
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  Horizontal line:
+  ```
+  Four or more dashes will be replaced
+  by a horizontal line (<HR>)
+  ----
+  See?
+
+  ```
+```
+```#!td
+Four or more dashes will be replaced
+by a horizontal line (<HR>)
+----
+See?
+```
+|----------------------------------
+```#!td
+  Two examples of line breaks:
+  ```
+  "macro" style [[BR]] line break
+  ```
+  or:
+  ```
+  !WikiCreole style \\ line\\break
+  ```
+```
+```#!td
+"macro" style [[BR]] line break
+
+!WikiCreole style \\ line\\break
+```
+|----------------------------------
diff --git a/raw-wiki-dump/WikiHtml.md b/raw-wiki-dump/WikiHtml.md
new file mode 100644
index 0000000..f190654
--- /dev/null
+++ b/raw-wiki-dump/WikiHtml.md
@@ -0,0 +1,359 @@
+# Using HTML in Wiki Text
+
+Trac supports the display of HTML in any wiki context, by using the `#html` [wiki:WikiProcessors WikiProcessor].
+
+However, this HTML has to be [well-formed](http://en.wikipedia.org/wiki/Well-formed_element).
+In particular, you can't insert a start tag in an `#html` block, resume normal wiki text and insert the corresponding end tag in a second `#html` block.
+
+Fortunately, for creating styled <div>s, <span>s  or even complex tables containing arbitrary Wiki text, there is a powerful alternative: `#div`, `#span` and `#table`, `#tr`, `#td` and `#th` blocks. Those Wiki processors are built-in and do not require additional packages to be installed.
+
+## How to use `#html` == #HowtoUseHTML
+To inform the wiki engine that a block of text should be treated as HTML, use the *html* processor:
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ```
+  #!html
+  <h1 style="text-align: right; color: blue">HTML Test</h1>
+
+  ```
+  ```
+```
+```#!td style="padding-left: 2em"
+  ```
+  #!html
+  <h1 style="text-align: right; color: blue">HTML Test</h1>
+  ```
+```
+
+Note that Trac sanitizes your HTML code before displaying it. That means that potentially dangerous constructs, such as Javascript event handlers, will be removed from the output.
+
+The filtering is done by [Genshi](http://genshi.edgewall.org/) and the output will be a well-formed fragment of HTML. This means that you can no longer use two HTML blocks, one for opening a <div> and another for closing it, in order to wrap arbitrary wiki text.
+The new way to wrap any wiki content inside a <div> is to use the `#div` Wiki processor.
+
+## How to use `#div` and `#span` == #HowtoUseDivSpan
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ```
+  #!div class="important"
+  **important** is a predefined class.
+
+  ```
+  ```
+  ```
+  ```
+  #!div style="border: 1pt dotted; margin: 1em"
+  **wikipage** is another predefined class that will
+  be used when no class is specified.
+  ```
+  ```
+  ```
+  ```
+  #!div class="compact" style="border: 1pt dotted; margin: 1em"
+  **compact** is another predefined class reducing
+  the padding within the `<div>` to a minimum.
+  ```
+  ```
+  ```
+  ```
+  #!div class="wikipage compact" style="border: 1pt dotted"
+  Classes can be combined (here **wikipage** and **compact**)
+  which results in this case in reduced //vertical//
+  padding but there's still some horizontal space for coping
+  with headings.
+  ```
+  ```
+  ```
+  ```
+  #!div class="" style="border: 1pt dotted; margin: 1em"
+  Explicitly specifying no classes is //not// the same
+  as specifying no class attribute, as this will remove
+  the //wikipage// default class.
+  ```
+  ```
+```
+```#!td style="padding-left: 2em"
+
+  ```
+  #!div class="important"
+  **important** is a predefined class.
+  ```
+
+  ```
+  #!div style="border: 1pt dotted; margin: 1em"
+  **wikipage** is another predefined class that will
+  be used when no class is specified.
+  ```
+
+  ```
+  #!div class="compact" style="border: 1pt dotted; margin: 1em"
+  **compact** is another predefined class reducing
+  the padding within the `<div>` to a minimum.
+  ```
+
+  ```
+  #!div class="wikipage compact" style="border: 1pt dotted"
+  Classes can be combined (here **wikipage** and **compact**)
+  which results in this case in reduced //vertical//
+  padding but there's still some horizontal space for coping
+  with headings.
+  ```
+
+  ```
+  #!div class="" style="border: 1pt dotted; margin: 1em"
+  Explicitly specifying no classes is //not// the same
+  as specifying no class attribute, as this will remove
+  the //wikipage// default class.
+  ```
+
+```
+
+Note that the contents of a `#div` block are contained in one or more paragraphs, which have a non-zero top and bottom margin. This leads to the top and bottom padding in the example above. To remove the top and bottom margin of the content, add the `compact` class to the `#div`. Another predefined class besides `wikipage` and `compact` is `important`, which can be used to make a paragraph stand out. Extra CSS classes can be defined via the `site/style.css` file for example, see TracInterfaceCustomization#SiteAppearance.
+
+For spans, you should use the Macro call syntax:
+| Wiki Markup |
+|---|
+```#!td
+  ```
+  Hello
+  [[span(''WORLD'' (click [#anchor here]), style=color: green; font-size: 120%, id=anchor)]]!
+
+  ```
+```
+|---------------------------------------------------------------------------------
+| Display |
+|---|
+```#!td style="padding-left: 2em"
+  Hello
+  [[span(''WORLD'' (click [#anchor here]), style=color: green; font-size: 120%, id=anchor)]]!
+
+```
+
+## How to use `#td` and other table related processors == #Tables
+
+The `#td` or `#th` processors should be used to create table data and table header cells, respectively. The other processors `#table` and `#tr` are not required for introducing a table structure, as `#td` and `#th` will do this automatically. The `|-` row separator can be used to start a new row when needed, but some may prefer to use a `#tr` block for that, as this introduces a more formal grouping and offers the possibility to use an extra level of indentation. The main purpose of the `#table` and `#tr` is to give the possibility to specify HTML attributes, like *style* or *valign* to these elements.
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+ ```
+ Simple 2x2 table with rich content:
+ ```#!th align=left
+  - Left
+  - Header
+
+ ```
+ ```#!th align=left
+  - Right
+  - Header
+ ```
+ |----------------------------------
+ ```#!td style="background: #ffd"
+  - Left
+  - Content
+ ```
+ ```#!td style="vertical-align: top"
+ !RightContent
+ ```
+ |----------------------------------
+ | ... and this can be mixed|\
+|---|
+ |with pipe-based cells |
+ ```#!td colspan=2
+ Pick the style the more appropriate
+ to your content
+
+ See WikiFormatting#Tables for details
+ on the pipe-based table syntax.
+
+ ```
+
+ If one needs to add some
+ attributes to the table itself...
+
+ ```
+ #!table style="border:none;text-align:center;margin:auto"
+   ```#!tr ====================================
+     ```#!th style="border: none"
+     Left header
+     ```
+     ```#!th style="border: none"
+     Right header
+     ```
+   ```
+   ```#!tr ==== style="border: 1px dotted grey"
+     ```#!td style="border: none"
+     1.1
+     ```
+     ```#!td style="border: none"
+     1.2
+     ```
+   ```
+   ```#!tr ====================================
+     ```#!td style="border: none"
+     2.1
+     ```
+     ```#!td
+     2.2
+     ```
+   ```
+ ```
+
+
+ ```
+```
+```#!td valign=top
+Simple 2x2 table with rich content:
+```#!th align=left
+ - Left
+ - Header
+```
+```#!th align=left
+ - Right
+ - Header
+```
+|----------------------------------
+```#!td style="background: #ffd"
+ - Left
+ - Content
+```
+```#!td style="vertical-align: top"
+!RightContent
+```
+|----------------------------------
+| ... and this can be mixed|\
+|---|
+|with pipe-based cells |
+```#!td colspan=2
+Pick the style the more appropriate
+to your content
+
+See WikiFormatting#Tables for details
+on the pipe-based table syntax.
+
+```
+
+If one needs to add some
+attributes to the table itself...
+
+```
+#!table style="border:none;text-align:center;margin:auto"
+  ```#!tr ====================================
+    ```#!th style="border: none"
+    Left header
+    ```
+    ```#!th style="border: none"
+    Right header
+    ```
+  ```
+  ```#!tr ==== style="border: 1px dotted grey"
+    ```#!td style="border: none"
+    1.1
+    ```
+    ```#!td style="border: none"
+    1.2
+    ```
+  ```
+  ```#!tr ====================================
+    ```#!td style="border: none"
+    2.1
+    ```
+    ```#!td
+    2.2
+    ```
+  ```
+```
+```
+
+Note that by default tables are assigned the "wiki" CSS class, which gives a distinctive look to the header cells and a default border to the table and cells, as can be seen for the tables on this page. By removing this class (`#table class=""`), one regains complete control on the table presentation. In particular, neither the table nor the rows nor the cells will have a border, so this is a more effective way to get such an effect rather than having to specify a `style="border: no"` parameter everywhere.
+
+```#!table class=""
+||= Wiki Markup =||= Display =||
+ ```#!td
+  ```
+  ```#!table class=""
+  ||  0||  1||  2||
+  || 10|| 20|| 30||
+  || 11|| 22|| 33||
+  ||||||=  numbers  =||
+  ```
+  ```
+ ```
+ ```#!td
+  ```#!table class=""
+  ||  0||  1||  2||
+  || 10|| 20|| 30||
+  || 11|| 22|| 33||
+  ||||||=  numbers  =||
+  ```
+ ```
+```
+
+Other classes can be specified as alternatives (remember that you can define your own in [TracInterfaceCustomization#SiteAppearance site/style.css]).
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ```#!table class="listing"
+  ||  0||  1||  2||
+  || 10|| 20|| 30||
+  || 11|| 22|| 33||
+  ||||||=  numbers  =||
+
+  ```
+  ```
+```
+```#!td
+  ```#!table class="listing"
+  ||  0||  1||  2||
+  || 10|| 20|| 30||
+  || 11|| 22|| 33||
+  ||||||=  numbers  =||
+  ```
+```
+
+## HTML comments
+HTML comments are stripped from the output of the `html` processor. To add an HTML comment to a wiki page, use the `htmlcomment` processor, available since Trac 0.12:
+| Wiki Markup |
+|---|
+```#!td
+  ```
+  ```
+  #!htmlcomment
+  This block is translated to an HTML comment.
+  It can contain <tags> and &entities; that will not be escaped in the output.
+
+  ```
+  ```
+```
+|---------------------------------------------------------------------------------
+| Display |
+|---|
+```#!td
+  ```
+  <!--
+  This block is translated to an HTML comment.
+  It can contain <tags> and &entities; that will not be escaped in the output.
+  -->
+
+  ```
+```
+
+Please note that the character sequence "`--`" is not allowed in HTML comments, and will generate a rendering error.
+
+
+## More Information
+
+
+    * http://www.w3.org/ -- World Wide Web Consortium
+    * http://www.w3.org/MarkUp/ -- HTML Markup Home Page
+
+
+----
+See also:  WikiProcessors, WikiFormatting, WikiRestructuredText
diff --git a/raw-wiki-dump/WikiMacros.md b/raw-wiki-dump/WikiMacros.md
new file mode 100644
index 0000000..5a5d158
--- /dev/null
+++ b/raw-wiki-dump/WikiMacros.md
@@ -0,0 +1,194 @@
+# Trac Macros
+
+[[PageOutline(2-5,Contents,pullout)]]
+
+**Trac macros** extend the Trac engine with custom functionality. Macros are a special type of plugin and are written in Python. A macro inserts dynamic HTML data in any context supporting WikiFormatting.
+
+The macro syntax is `[[macro-name(optional-arguments)]]`.
+
+**WikiProcessors** are another kind of macros. They are typically used for source code highlighting, such as `!#python` or `!#apache` and when the source code spans multiple lines, such as:
+
+```
+```#!wiki-processor-name
+...
+```
+```
+
+## Using Macros
+
+Macro calls are enclosed in double-square brackets `[[..]]`. Like Python functions, macros can have arguments, which is then a comma separated list within parentheses `[[..(,)]]`.
+
+### Getting Detailed Help
+
+The list of available macros and the full help can be obtained using the MacroList macro, as seen [#AvailableMacros below].
+
+A brief list can be obtained via `[[MacroList(*)]]` or `[[?]]`.
+
+Detailed help on a specific macro can be obtained by passing it as an argument to MacroList, e.g. `[[MacroList(MacroList)]]`, or, more conveniently, by appending a question mark (`?`) to the macro's name, like in `[[MacroList?]]`.
+
+### Example
+
+A list of the 3 most recently changed wiki pages starting with 'Trac':
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  [[RecentChanges(Trac,3)]]
+
+  ```
+```
+```#!td style="padding-left: 2em;"
+[[RecentChanges(Trac,3)]]
+```
+|-----------------------------------
+```#!td
+  ```
+  [[RecentChanges?(Trac,3)]]
+  ```
+```
+```#!td style="padding-left: 2em;"
+[[RecentChanges?(Trac,3)]]
+```
+|-----------------------------------
+```#!td
+  ```
+  [[?]]
+  ```
+```
+```#!td style="padding-left: 2em"
+```#!html
+<div class="trac-macrolist">
+<h3><code>[[Image]]</code></h3>Embed an image in wiki-formatted text.
+
+The first argument is the file, as in <code>[[Image(filename.png)]]</code>
+<h3><code>[[InterTrac]]</code></h3>Provide a list of known <a class="wiki" href="/wiki/InterTrac">InterTrac</a> prefixes.
+<h3><code>[[InterWiki]]</code></h3>Provide a description list for the known <a class="wiki" href="/wiki/InterWiki">InterWiki</a> prefixes.
+<h3><code>[[KnownMimeTypes]]</code></h3>List all known mime-types which can be used as <a class="wiki" href="/wiki/WikiProcessors">WikiProcessors</a>.
+</div>
+```
+etc.
+```
+
+## Available Macros
+
+*Note that the following list will only contain the macro documentation if you've not enabled `-OO` optimizations, or not set the `PythonOptimize` option for [wiki:TracModPython mod_python].*
+
+[[MacroList]]
+
+## Macros from around the world
+
+The [Trac Hacks] site provides a wide collection of macros and other Trac [TracPlugins plugins](http://trac-hacks.org/) contributed by the Trac community. If you are looking for new macros, or have written one that you would like to share, please visit that site.
+
+## Developing Custom Macros
+
+Macros, like Trac itself, are written in the [Python programming language](http://python.org/) and are developed as part of TracPlugins.
+
+For more information about developing macros, see the [trac:TracDev development resources] on the main project site.
+
+Here are 2 simple examples showing how to create a Macro. Also, have a look at [trac:source:tags/trac-1.0.2/sample-plugins/Timestamp.py Timestamp.py] for an example that shows the difference between old style and new style macros and at the [trac:source:tags/trac-0.11/wiki-macros/README macros/README] which provides more insight about the transition.
+
+### Macro without arguments
+
+To test the following code, save it in a `timestamp_sample.py` file located in the TracEnvironment's `plugins/` directory.
+
+```#!python
+from datetime import datetime
+# Note: since Trac 0.11, datetime objects are used internally
+
+from genshi.builder import tag
+
+from trac.util.datefmt import format_datetime, utc
+from trac.wiki.macros import WikiMacroBase
+
+class TimeStampMacro(WikiMacroBase):
+    """Inserts the current time (in seconds) into the wiki page."""
+
+    revision = "$Rev$"
+    url = "$URL$"
+
+    def expand_macro(self, formatter, name, text):
+        t = datetime.now(utc)
+        return tag.strong(format_datetime(t, '%c'))
+```
+
+### Macro with arguments
+
+To test the following code, save it in a `helloworld_sample.py` file located in the TracEnvironment's `plugins/` directory.
+
+```#!python
+from genshi.core import Markup
+
+from trac.wiki.macros import WikiMacroBase
+
+class HelloWorldMacro(WikiMacroBase):
+    """Simple HelloWorld macro.
+
+    Note that the name of the class is meaningful:
+     - it must end with "Macro"
+     - what comes before "Macro" ends up being the macro name
+
+    The documentation of the class (i.e. what you're reading)
+    will become the documentation of the macro, as shown by
+    the !MacroList macro (usually used in the WikiMacros page).
+    """
+
+    revision = "$Rev$"
+    url = "$URL$"
+
+    def expand_macro(self, formatter, name, text, args):
+        """Return some output that will be displayed in the Wiki content.
+
+        `name` is the actual name of the macro (no surprise, here it'll be
+        `'HelloWorld'`),
+        `text` is the text enclosed in parenthesis at the call of the macro.
+          Note that if there are ''no'' parenthesis (like in, e.g.
+          [[HelloWorld]]), then `text` is `None`.
+        `args` are the arguments passed when HelloWorld is called using a
+        `#!HelloWorld` code block.
+        """
+        return 'Hello World, text = %s, args = %s' % \
+            (Markup.escape(text), Markup.escape(repr(args)))
+
+```
+
+Note that `expand_macro` optionally takes a 4^th^ parameter *`args`*. When the macro is called as a [WikiProcessors WikiProcessor], it is also possible to pass `key=value` [WikiProcessors#UsingProcessors processor parameters]. If given, those are stored in a dictionary and passed in this extra `args` parameter. In the other case, when called as a macro, `args` is `None`. (*since 0.12*).
+
+For example, when writing:
+```
+```#!HelloWorld style="polite" -silent verbose
+<Hello World!>
+```
+
+```#!HelloWorld
+<Hello World!>
+```
+
+[[HelloWorld(<Hello World!>)]]
+```
+
+One should get:
+```
+Hello World, text = <Hello World!>, args = {'style': u'polite', 'silent': False, 'verbose': True}
+Hello World, text = <Hello World!>, args = {}
+Hello World, text = <Hello World!>, args = None
+```
+
+Note that the return value of `expand_macro` is **not** HTML escaped. Depending on the expected result, you should escape it yourself (using `return Markup.escape(result)`) or, if this is indeed HTML, wrap it in a Markup object (`return Markup(result)`) with `Markup` coming from Genshi (`from genshi.core import Markup`).
+
+You can also recursively use a wiki Formatter (`from trac.wiki import Formatter`) to process the `text` as wiki markup:
+
+```#!python
+from genshi.core import Markup
+from trac.wiki.macros import WikiMacroBase
+from trac.wiki import Formatter
+import StringIO
+
+class HelloWorldMacro(WikiMacroBase):
+    def expand_macro(self, formatter, name, text, args):
+        text = "whatever '''wiki''' markup you want, even containing other macros"
+        # Convert Wiki markup to HTML, new style
+        out = StringIO.StringIO()
+        Formatter(self.env, formatter.context).format(text, out)
+        return Markup(out.getvalue())
+```
diff --git a/raw-wiki-dump/WikiNewPage.md b/raw-wiki-dump/WikiNewPage.md
new file mode 100644
index 0000000..970e7eb
--- /dev/null
+++ b/raw-wiki-dump/WikiNewPage.md
@@ -0,0 +1,24 @@
+# Steps to Add a New Wiki Page
+[[TracGuideToc]]
+
+You can create a new wiki page by typing the CamelCase name of the page in the quick-search field at the top of the page, or by trying to view a wiki page of that name. Note that a page is "orphaned" by default until it is linked to from another page.
+
+You must be granted permission to create wiki pages. If you don't see the **Create this page** button when visiting a non-existent wiki page, you lack appropriate permission. Contact your local Trac administrator for more information.
+
+A new wiki page can also be created as follows:
+
+1. Choose a name for your new page. See WikiPageNames for naming conventions.
+1. Edit an existing page or any other resource that support WikiFormatting and add a [TracLinks link] to your new page. If your page name is CamelCase, you can simply type the page name, provided the [TracIni#wiki-section ignore_missing_pages option] is `disabled` (the default).
+1. Save your changes.
+1. Follow the link you created to take you to the new page.
+1. Click the **Create this page** button to enter edit mode and add content to your new page.
+1. Save your changes to publish your page.
+
+## Rename a page #renaming
+
+While choosing a good [WikiPageNames page name] is important for usability purposes, you can always rename the page later. You will need the WIKI_RENAME permission to rename pages.
+
+When renaming a page, you'll be offered the possibility to create a page at the old location that contains a link to the new page, so that links pointing to the old location are not "dangling" (i.e. pointing to a non-existent page).
+
+----
+See also: TracWiki, PageTemplates, WikiFormatting, TracLinks, WikiDeletePage
diff --git a/raw-wiki-dump/WikiPageNames.md b/raw-wiki-dump/WikiPageNames.md
new file mode 100644
index 0000000..073f9f9
--- /dev/null
+++ b/raw-wiki-dump/WikiPageNames.md
@@ -0,0 +1,53 @@
+# Wiki Page Names
+[[TracGuideToc]]
+
+Wiki page names commonly use the CamelCase convention. Within wiki text, any word in CamelCase automatically becomes a hyperlink to the wiki page with that name.
+
+CamelCase page names follow these rules:
+
+ 1. The name must consist of **alphabetic characters only**; no digits, spaces, punctuation or underscores are allowed.
+ 1. A name must have at least two capital letters.
+ 1. The first character must be capitalized.
+ 1. Every capital letter must be followed by one or more lower-case letters.
+ 1. The use of slash ( / ) is permitted in page names, where it typically represents a hierarchy.
+
+If you want to create a wiki page that does not follow CamelCase rules. you can use the following syntax:
+```
+ * [wiki:Wiki_page], [wiki:ISO9000],
+   and with a label: [wiki:ISO9000 ISO 9000 standard]
+ * [wiki:"Space Matters"]
+   and with a label: [wiki:"Space Matters" all about white space]
+ * or simply: ["WikiPageName"]s
+ * even better, the [[WikiCreole link style]]
+   and with a label: [[WikiCreole link style|WikiCreole style links]]
+```
+
+This will be rendered as:
+
+    * [wiki:Wiki_page], [wiki:ISO9000],
+
+   and with a label: [wiki:ISO9000 ISO 9000 standard]
+
+    * [wiki:"Space Matters"] *(that page name embeds space characters)*
+
+   and with a label: [wiki:"Space Matters" all about white space]
+
+    * or simply: ["WikiPageName"]s
+    * even better, the [[WikiCreole link style]]
+
+   and with a label: [[WikiCreole link style|WikiCreole style links]]
+
+It is possible to link to a specific *version* of a Wiki page as you would do for a specific version of a file, for example: WikiStart@1.
+
+You can prevent a CamelCase name from being interpreted as a [TracLinks link] by quoting it with an exclamation mark: `CamelCase`. See TracLinks#EscapingLinks.
+
+As in the example above, you can append an anchor to a Wiki page name to link to a specific section within that page. The anchor can be seen by hovering the mouse over a section heading, then clicking on the [[html(&para;)]] sign that appears at its end. The anchor is usually generated automatically, but it is also possible to specify it explicitly: see WikiFormatting#using-explicit-id-in-heading.
+
+There are a few options that govern the rendering of WikiPageNames:
+
+* CamelCase linking to missing pages can be disabled with the `ignore_missing_pages` [option](https://trac.edgewall.org/wiki/TracIni#wiki-section). Linking to missing pages is enabled by default.
+* The `split_page_names` option, when enabled, will split CamelCase words when rendering a link. For example, WikiStart will be rendered as [WikiStart Wiki Start].
+
+
+----
+See also: WikiNewPage, WikiFormatting, TracWiki, TracLinks
diff --git a/raw-wiki-dump/WikiProcessors.md b/raw-wiki-dump/WikiProcessors.md
new file mode 100644
index 0000000..e0ecaaf
--- /dev/null
+++ b/raw-wiki-dump/WikiProcessors.md
@@ -0,0 +1,284 @@
+# Wiki Processors
+
+Processors are WikiMacros designed to provide alternative markup formats for the [TracWiki Wiki engine]. Processors can be thought of as *macro functions to process user-edited text*.
+
+Wiki processors can be used in any Wiki text throughout Trac, such as:
+
+    - [#CodeHighlightingSupport syntax highlighting] or for rendering text verbatim
+    - rendering [#HTMLrelated Wiki markup inside a context], like inside <div> blocks or <span> or within <td> or <th> table cells
+    - using an alternative markup syntax, like [raw HTML] and [WikiRestructuredText Restructured Text] or [http://www.textism.com/tools/textile/ textile](WikiHtml)
+
+
+## Using Processors
+
+To use a processor on a block of text, first delimit the lines using a Wiki *code block*:
+```
+```
+The lines
+that should be processed...
+```
+```
+
+Immediately after the ````` or on the line just below, add `#!` followed by the ''processor name'':
+
+```
+```
+#!processorname
+The lines
+that should be processed...
+```
+```
+
+This is the "shebang" notation, familiar to most UNIX users.
+
+Besides their content, some Wiki processors can also accept *parameters*, which are then given as `key=value` pairs after the processor name and on the same line. If `value` has to contain space, as it's often the case for the style parameter, a quoted string can be used (`key="value with space"`).
+
+As some processors are meant to process Wiki markup, it's quite possible to *nest* processor blocks.
+You may want to indent the content of nested blocks for increased clarity, this extra indentation will be ignored when processing the content.
+
+## Examples
+
+| Wiki Markup | Display |
+|---|---|
+```#!td colspan=2 align=center style="border: none"
+
+                __Example 1__: Inserting raw HTML
+
+```
+|-----------------------------------------------------------------
+```#!td style="border: none"
+```
+```
+#!html
+<h1 style="color: grey">This is raw HTML</h1>
+```
+```
+```
+```#!td valign=top style="border: none; padding-left: 2em"
+```
+#!html
+<h1 style="color: grey">This is raw HTML</h1>
+```
+```
+|-----------------------------------------------------------------
+```#!td colspan=2 align=center style="border: none"
+
+     __Example 2__: Highlighted Python code in a <div> block with custom style
+```
+|-----------------------------------------------------------------
+```#!td style="border: none"
+  ```
+  ```#!div style="background: #ffd; border: 3px ridge"
+
+  This is an example of embedded "code" block:
+
+    ```
+    #!python
+    def hello():
+        return "world"
+    ```
+
+  ```
+  ```
+```
+```#!td valign=top style="border: none; padding: 1em"
+  ```#!div style="background: #ffd; border: 3px ridge"
+
+  This is an example of embedded "code" block:
+
+    ```
+    #!python
+    def hello():
+        return "world"
+    ```
+
+  ```
+```
+|-----------------------------------------------------------------
+```#!td colspan=2 align=center style="border: none"
+
+     __Example 3__: Searching tickets from a wiki page, by keywords.
+```
+|-----------------------------------------------------------------
+```#!td style="border: none"
+  ```
+  ```
+  #!html
+  <form action="/query" method="get"><div>
+  <input type="text" name="keywords" value="~" size="30"/>
+  <input type="submit" value="Search by Keywords"/>
+  <!-- To control what fields show up use hidden fields
+  <input type="hidden" name="col" value="id"/>
+  <input type="hidden" name="col" value="summary"/>
+  <input type="hidden" name="col" value="status"/>
+  <input type="hidden" name="col" value="milestone"/>
+  <input type="hidden" name="col" value="version"/>
+  <input type="hidden" name="col" value="owner"/>
+  <input type="hidden" name="col" value="priority"/>
+  <input type="hidden" name="col" value="component"/>
+  -->
+  </div></form>
+  ```
+  ```
+```
+```#!td valign=top style="border: none; padding: 1em"
+  ```
+  #!html
+  <form action="/query" method="get"><div>
+  <input type="text" name="keywords" value="~" size="30"/>
+  <input type="submit" value="Search by Keywords"/>
+  <!-- To control what fields show up use hidden fields
+  <input type="hidden" name="col" value="id"/>
+  <input type="hidden" name="col" value="summary"/>
+  <input type="hidden" name="col" value="status"/>
+  <input type="hidden" name="col" value="milestone"/>
+  <input type="hidden" name="col" value="version"/>
+  <input type="hidden" name="col" value="owner"/>
+  <input type="hidden" name="col" value="priority"/>
+  <input type="hidden" name="col" value="component"/>
+  -->
+  </div></form>
+  ```
+```
+
+## Available Processors
+
+The following processors are included in the Trac distribution:
+
+| **`#default`** | Present the text verbatim in a preformatted text block. This is the same as specifying *no* processor name (and no `#!`). |
+|---|---|
+| **`#comment`** | Do not process the text in this section, i.e. contents exist only in the plain text - not in the rendered page. |
+| **`#rtl`** | Introduce a Right-To-Left block with appropriate CSS direction and styling. *(since 0.12.2)* |
+|| |
+|| **[=#HTMLrelated HTML related]** |
+| **`#html`** | Insert custom HTML in a wiki page. |
+| **`#htmlcomment`** | Insert an HTML comment in a wiki page. (*since 0.12*) |
+| | Note that `#html` blocks have to be *self-contained*, i.e. you can't start an HTML element in one block and close it later in a second block. Use the following processors for achieving a similar effect.  |
+| **`#div`** | Wrap wiki content inside a <div> element. |
+| **`#span`** | Wrap wiki content inside a <span> element. |
+| **`#td`** | Wrap wiki content inside a <td> element. (*since 0.12*) |
+| **`#th`** | Wrap wiki content inside a <th> element. (*since 0.12*) |
+| **`#tr`** | Can optionally be used for wrapping `#td` and `#th` blocks, either for specifying row attributes or better visual grouping. (*since 0.12*) |
+| **`#table`** | Can optionally be used for wrapping `#tr`, `#td` and `#th` blocks, for specifying table attributes. One current limitation however is that tables cannot be nested. (*since 0.12*) |
+| | See WikiHtml for example usage and more details about these processors. |
+|| |
+|| **Other Markups** |
+| **`#rst`** | Trac support for Restructured Text. See WikiRestructuredText. |
+| **`#textile`** | Supported if [Textile] is installed. See [http://www.textism.com/tools/textile/ a Textile reference](http://cheeseshop.python.org/pypi/textile). |
+|| |
+|| **[=#CodeHighlightingSupport Code Highlighting Support]** |
+| **`#c`** [**`#cpp`** (C++) [[BR]] **`#python`** [[BR]] **`#perl`** [[BR]] **`#ruby`** [[BR]] **`#php`** [[BR]] **`#asp`** [[BR]] **`#java`** [[BR]] **`#js`** (Javascript) [[BR]] **`#sql`** [[BR]] **`#xml`** (XML or HTML) [[BR]] **`#sh`** (Bourne/Bash shell) [[BR]] **etc.** [[BR]] | Trac includes processors to provide inline syntax highlighting for source code in various languages. [[BR]] [[BR]] Trac relies on [http://pygments.org Pygments] for syntax coloring. [[BR]] [[BR]]([BR]]) See TracSyntaxColoring for information about which languages are supported and how to enable support for more languages. |
+|| |
+
+
+Since 1.1.2 the default, coding highlighting and MIME-type processors support the argument `lineno` for adding line numbering to the code block. When a value is specified, as in `lineno=3`, the numbering will start at the specified value. When used in combination with the `lineno` argument, the `marks` argument is also supported for highlighting lines. A single line number, set of line numbers and range of line numbers are allowed. For example, `marks=3`, `marks=3-6`, `marks=3,5,7` and `marks=3-5,7` are all allowed. The specified values are relative to the numbered lines, so if `lineno=2` is specified to start the line numbering at 2, `marks=2` will result in the first line being highlighted.
+
+Using the MIME type as processor, it is possible to syntax-highlight the same languages that are supported when browsing source code.
+
+|| **MIME Type Processors** |
+|---|---|
+```#!tr
+```#!td
+Some examples:
+ ```
+```#!text/html
+<h1>text</h1>
+
+```
+ ```
+```
+```#!td
+The result will be syntax highlighted HTML code:
+ ```#!text/html
+<h1>text</h1>
+ ```
+
+The same is valid for all other [TracSyntaxColoring#SyntaxColoringSupport mime types supported].
+```
+```
+```#!td
+ ```
+```#!diff
+--- Version 55
++++ Version 56
+@@ -115,8 +115,9 @@
+     name='TracHelloWorld', version='1.0',
+     packages=find_packages(exclude=['*.tests*']),
+-    entry_points = """
+-        [trac.plugins]
+-        helloworld = myplugs.helloworld
+-    """,
++    entry_points = {
++        'trac.plugins': [
++            'helloworld = myplugs.helloworld',
++        ],
++    },
+ )
+```
+ ```
+```
+```#!td
+'''`#!diff`''' has a particularly nice renderer:
+ ```#!diff
+--- Version 55
++++ Version 56
+@@ -115,8 +115,9 @@
+     name='TracHelloWorld', version='1.0',
+     packages=find_packages(exclude=['*.tests*']),
+-    entry_points = """
+-        [trac.plugins]
+-        helloworld = myplugs.helloworld
+-    """,
++    entry_points = {
++        'trac.plugins': [
++            'helloworld = myplugs.helloworld',
++        ],
++    },
+ )
+ ```
+```
+
+Line numbers can be added to code blocks and lines can be highlighted //(since 1.1.2)//.
+```
+```#!python lineno=3 marks=3,9-10,16
+def expand_markup(stream, ctxt=None):
+    """A Genshi stream filter for expanding `genshi.Markup` events.
+
+    Note: Expansion may not be possible if the fragment is badly
+    formed, or partial.
+    """
+    for event in stream:
+        if isinstance(event[1], Markup):
+            try:
+                for subevent in HTML(event[1]):
+                    yield subevent
+            except ParseError:
+                yield event
+        else:
+            yield event
+```
+```
+```#!python lineno=3 marks=3,9-10,16
+def expand_markup(stream, ctxt=None):
+    """A Genshi stream filter for expanding `genshi.Markup` events.
+
+    Note: Expansion may not be possible if the fragment is badly
+    formed, or partial.
+    """
+    for event in stream:
+        if isinstance(event[1], Markup):
+            try:
+                for subevent in HTML(event[1]):
+                    yield subevent
+            except ParseError:
+                yield event
+        else:
+            yield event
+```
+
+For more processor macros developed and/or contributed by users, visit the [Trac Hacks](https://trac-hacks.org) community site.
+
+Developing processors is no different from Wiki macros. In fact, they work the same way, only the usage syntax differs. See WikiMacros#DevelopingCustomMacros for more information.
+
+----
+See also: WikiMacros, WikiHtml, WikiRestructuredText, TracSyntaxColoring, WikiFormatting, TracGuide
diff --git a/raw-wiki-dump/WikiRestructuredText.md b/raw-wiki-dump/WikiRestructuredText.md
new file mode 100644
index 0000000..407e7f9
--- /dev/null
+++ b/raw-wiki-dump/WikiRestructuredText.md
@@ -0,0 +1,229 @@
+# reStructuredText Support in Trac
+
+## Introduction
+
+
+Trac supports [reStructuredText (RST)](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html) as an alternative to wiki markup where WikiFormatting is used.
+
+From the reStucturedText webpage:
+ "reStructuredText is an easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and parser system. It is useful for in-line program documentation (such as Python docstrings), for quickly creating simple web pages, and for standalone documents. reStructuredText is designed for extensibility for specific application domains."
+
+If you want a file from your Subversion repository to be displayed as reStructuredText in the Trac source browser, set `text/x-rst` as the value for the Subversion property `svn:mime-type`, or add the extension `rst` to the filename. See [trac:source:/trunk/INSTALL.rst this example].
+
+The examples will only be rendered as reStructuredText if docutils is installed. If Pygments is installed but docutils is not installed, the examples will be syntax-highlighted rather than rendered as reStructuredText.
+
+### Requirements
+
+To activate RST support in Trac, install the python docutils package with the command `easy_install docutils`, or through your operating system package manager. If not already available on your operating system, you can download it from [PyPI](https://pypi.python.org/pypi/docutils).
+
+### More information on RST
+
+
+    * [reStructuredText Website](http://docutils.sourceforge.net/rst.html)
+    * [RST Quick Reference](http://docutils.sourceforge.net/docs/rst/quickref.html)
+
+
+## Using RST in Trac
+
+To specify that a block of text should be parsed using RST, use the *rst* processor.
+
+### TracLinks in reStructuredText
+
+
+    * Trac provides a custom RST directive `trac::` to allow TracLinks from within RST text.
+
+   | Wiki Markup | Display |
+|---|---|
+   ```#!td
+     ```
+     ```#!rst
+     This is a reference to |a ticket|
+
+     .. |a ticket| trac:: #42
+
+     ```
+     ```
+   ```
+   ```#!td
+     ```#!rst
+     This is a reference to |a ticket|
+
+     .. |a ticket| trac:: #42
+     ```
+   ```
+
+
+    * You can also use the custom `:trac:` role to create TracLinks in RST.
+
+   | Wiki Markup | Display |
+|---|---|
+   ```#!td
+     ```
+     ```#!rst
+     This is a reference to ticket `#12`:trac:
+
+     To learn how to use Trac, see `TracGuide`:trac:
+
+     ```
+     ```
+   ```
+   ```#!td
+     ```#!rst
+     This is a reference to ticket `#12`:trac:
+
+     To learn how to use Trac, see `TracGuide`:trac:
+     ```
+   ```
+
+ For a complete example of all uses of the `:trac:` role, see WikiRestructuredTextLinks.
+
+### Syntax highlighting in reStructuredText
+
+There is a directive for doing TracSyntaxColoring in RST as well. The directive is called code-block:
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ```#!rst
+
+  .. code-block:: python
+
+     class Test:
+
+         def TestFunction(self):
+             pass
+
+
+  ```
+  ```
+```
+```#!td
+  ```#!rst
+
+  .. code-block:: python
+
+     class Test:
+
+         def TestFunction(self):
+             pass
+
+  ```
+```
+Note the need to indent the code at least one character after the `.. code-block` directive.
+
+### Wiki Macros in reStructuredText
+
+To enable [WikiMacros Wiki Macros] in RST, you use the same `code-block` directive as for syntax highlighting:
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ```#!rst
+
+  .. code-block:: RecentChanges
+
+     Trac,3
+
+
+  ```
+  ```
+```
+```#!td
+  ```#!rst
+
+  .. code-block:: RecentChanges
+
+     Trac,3
+
+  ```
+```
+
+Or use the `:code-block:` role for a more concise Wiki Macro-like syntax:
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+  ```
+  ```
+  #!rst
+
+  :code-block:`RecentChanges:Trac,3`
+
+  ```
+  ```
+```
+```#!td
+  ```#!rst
+
+  :code-block:`RecentChanges:Trac,3`
+  ```
+```
+
+### Bigger RST Example
+
+The example below should be self-explanatory:
+
+| Wiki Markup | Display |
+|---|---|
+```#!td
+```#!html
+<pre class="wiki">```#!rst
+FooBar Header
+=============
+reStructuredText is **nice**. It has its own webpage_.
+
+A table:
+
+=====  =====  ======
+   Inputs     Output
+------------  ------
+  A      B    A or B
+=====  =====  ======
+False  False  False
+True   False  True
+False  True   True
+True   True   True
+=====  =====  ======
+
+RST TracLinks
+-------------
+
+See also ticket `#42`:trac:.
+
+.. _webpage: http://docutils.sourceforge.net/rst.html
+
+```</pre>
+```
+```
+```#!td
+```#!rst
+FooBar Header
+=============
+reStructuredText is **nice**. It has its own webpage_.
+
+A table:
+
+=====  =====  ======
+   Inputs     Output
+------------  ------
+  A      B    A or B
+=====  =====  ======
+False  False  False
+True   False  True
+False  True   True
+True   True   True
+=====  =====  ======
+
+RST TracLinks
+-------------
+
+See also ticket `#42`:trac:.
+
+.. _webpage: http://docutils.sourceforge.net/rst.html
+```
+```
+
+----
+See also: WikiRestructuredTextLinks, WikiProcessors, WikiFormatting
diff --git a/raw-wiki-dump/WikiRestructuredTextLinks.md b/raw-wiki-dump/WikiRestructuredTextLinks.md
new file mode 100644
index 0000000..900db18
--- /dev/null
+++ b/raw-wiki-dump/WikiRestructuredTextLinks.md
@@ -0,0 +1,71 @@
+# TracLinks in reStructuredText
+
+This document illustrates how to use the `:trac:` role in [reStructuredText](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html). The page is written like:
+
+```
+```#!rst
+Examples:
+
+ * Tickets: :trac:`#1` or :trac:`ticket:1`
+ * Ticket comments: :trac:`comment:ticket:1:2`
+ * Reports: :trac:`{1}` or :trac:`report:1`
+ * Changesets: :trac:`r1`, :trac:`[1]` or :trac:`changeset:1`
+ * Revision log: :trac:`r1:3`, :trac:`[1:3]` or :trac:`log:@1:3`, :trac:`log:trunk@1:3`
+ * Diffs: :trac:`diff:@20:30`, :trac:`diff:tags/trac-0.9.2/wiki-default//tags/trac-0.9.3/wiki-default` or :trac:`diff:trunk/trac@3538//sandbox/vc-refactoring/trac@3539`
+ * Wiki pages: :trac:`CamelCase` or :trac:`wiki:CamelCase`
+ * Milestones: :trac:`milestone:1.0`
+ * Attachment: :trac:`attachment:ticket:944:attachment.1073.diff`
+ * Files: :trac:`source:trunk/COPYING`
+ * A specific file revision: :trac:`source:/trunk/COPYING@200`
+ * A particular line of a specific file revision: :trac:`source:/trunk/COPYING@200#L25`
+
+An explicit label can be specified, separated from the link by a space:
+
+ * See :trac:`#1 ticket 1` and the :trac:`source:trunk/COPYING license`.
+```
+```
+
+Provided you have [docutils](http://docutils.sourceforge.net/) installed, the above block will render as:
+----
+```#!rst
+Examples:
+
+ * Tickets: :trac:`#1` or :trac:`ticket:1`
+ * Ticket comments: :trac:`comment:ticket:1:2`
+ * Reports: :trac:`{1}` or :trac:`report:1`
+ * Changesets: :trac:`r1`, :trac:`[1]` or :trac:`changeset:1`
+ * Revision log: :trac:`r1:3`, :trac:`[1:3]` or :trac:`log:@1:3`, :trac:`log:trunk@1:3`
+ * Diffs: :trac:`diff:@20:30`, :trac:`diff:tags/trac-0.9.2/wiki-default//tags/trac-0.9.3/wiki-default` or :trac:`diff:trunk/trac@3538//sandbox/vc-refactoring/trac@3539`
+ * Wiki pages: :trac:`CamelCase` or :trac:`wiki:CamelCase`
+ * Milestones: :trac:`milestone:1.0`
+ * Attachment: :trac:`attachment:ticket:944:attachment.1073.diff`
+ * Files: :trac:`source:trunk/COPYING`
+ * A specific file revision: :trac:`source:/trunk/COPYING@200`
+ * A particular line of a specific file revision: :trac:`source:/trunk/COPYING@200#L25`
+
+An explicit label can be specified, separated from the link by a space:
+
+ * See :trac:`#1 ticket 1` and the :trac:`source:trunk/COPYING license`.
+```
+----
+
+Note that the above could have been written using substitution references and the `trac::` directive:
+```
+```#!rst
+See |ticket123|.
+
+ .. |ticket123| trac:: ticket:123 this ticket
+```
+```
+
+This renders as:
+----
+
+```#!rst
+See |ticket123|.
+
+ .. |ticket123| trac:: ticket:123 this ticket
+```
+
+----
+See also: WikiRestructuredText, TracLinks
diff --git a/raw-wiki-dump/WikiStart.md b/raw-wiki-dump/WikiStart.md
new file mode 100644
index 0000000..c84bafb
--- /dev/null
+++ b/raw-wiki-dump/WikiStart.md
@@ -0,0 +1,75 @@
+[[PageOutline]]
+
+# Overview
+
+Recent revelations have called into question the integrity of some of
+the implementations of basic cryptographic functions and devices used to
+secure communications on the Internet. There are serious questions about
+algorithms and about implementations of those algorithms in software and
+particularly hardware. The goal of the [CrypTech](https://cryptech.is)
+project is to provide some possible answers to those questions by
+developing an open-source hardware cryptographic engine that meets the
+needs of high assurance Internet infrastructure systems that use
+cryptography.
+
+The algorithmic issues are in the domain of the heavy math cryptography
+folk; the implementation issues are the primary focus of the project.
+The open-source hardware cryptographic engine must be of general use to
+the broad Internet community, covering needs such as secure email, web,
+DNS, PKIs, etc.
+
+The intent of the project is that the final open-source hardware cryptographic
+engine can be built by anyone from public hardware specifications and
+open-source firmware. Anyone can then operate it without fees of any
+kind.
+
+# About Us
+[CrypTech.IS](https://cryptech.is) is a loose international collective
+of [WhoWeAre engineers] trying to improve assurance and privacy on the
+Internet. It is funded diversely and is administratively quartered outside
+the US.
+
+We are actively seeking use cases for an initial project which is to
+produce a design of an open and auditable Hardware Security Module (HSM)
+and supporting software.
+
+We are also considering the issues around assurance of a tool-chain,
+from compiler to operating system and as close to the hardware as we can
+reasonably get.
+
+The project solicits functional requirements from a wide range of
+organizations. It will focus on the classic low level cryptographic
+functions and primitives, and not get drawn into re-implementation of
+application protocol layers.
+
+We hope that a group of interested organizations will offer funding
+for development, and that the IACR and public sector cryptographers will
+provide algorithmic advice and wide and open review. If you or your
+organization is interested in helping this effort, please consider
+offering [financial support](https://cryptech.is/funding/) to keep the
+work flowing.
+
+# More Information
+## [[span(style=color: brown,[QuickStart Quick Start Guide])]]
+
+* including pointers to the git repositories, information on how to set up and configure the board and software, and HSM requirements
+
+
+## [[span(style=color: brown,[DevelopersGuide Developers Guide])]]
+
+* including the architecture diagrams, and known information
+
+
+## [[span(style=color: brown,[ProjectStatus Project Status])]]
+
+* including information on the chip design and prototypes as well as the pilot project(s)
+
+
+## [[span(style=color: brown,[ProjectMetadata Project Metadata])]]
+
+* including information on presentations and meeting notes, technical references, and related work
+
+
+## [[span(style=color: brown,[ProjectArchive Project Archive])]]
+
+* including information on dormant and far-future work