samueleresca commented on code in PR #1242: URL: https://github.com/apache/pekko-http/pull/1242#discussion_r3973316248
########## THREAT_MODEL.md: ########## @@ -0,0 +1,392 @@ +# Apache Pekko HTTP — Threat Model + +**Status:** Reviewed by a Pekko maintainer. **All ten questions in §14 are answered** and are settled model, and §5b records the project's standing position on configuration defaults. One item is referred rather than settled: whether the upstream-coordination sentence in `security.md` should be promoted into `SECURITY.md` (§14 Q10). No claim in this document is now uncited: every assertion is either cited to Pekko HTTP's own source and configuration, or stated by a maintainer. + +| | | +| --- | --- | +| **Project** | Apache Pekko HTTP | +| **Written against** | commit `85d7243`, `main` | +| **Date** | 2026-08-27 | +| **Authors** | ASF Security team, at the request of the Pekko PMC | +| **Version binding** | Versioned alongside the project. A report against version *N* is triaged against the model as it stood at *N*, not at `main`. | +| **Reporting** | Findings that violate a §8 property should be reported per [`SECURITY.md`](SECURITY.md). Findings under §3 or §9 will be closed citing this document. | +| **Companion model** | Pekko HTTP is built on Pekko Streams and Actors. The actor, remoting and cluster layers are modeled in [`apache/pekko`'s `THREAT_MODEL.md`](https://github.com/apache/pekko/blob/main/THREAT_MODEL.md); this document does not restate them. | + +**Provenance legend.** +*(documented)* — stated in Pekko HTTP's own docs or `reference.conf` comments, cited. +*(maintainer)* — stated by a Pekko maintainer in review of this document. +*(inferred)* — reasoned from code or config defaults, **not yet confirmed**; each has a matching question in §14. + +**Confidence:** 20 documented / 28 maintainer / 0 inferred — counting inline tags only. The §5a limits table and the §15 back-map carry a further ~35 documented facts under a single collective citation each, so the document is more evidence-backed than the bare ratio suggests. **Nothing in the document is inferred any more.** Q1-Q9 were answered by a maintainer in review; Q3, Q5 and Q9 were resolved against the source first, the last of these replacing §5's negative claims with a cited scan. Q3, Q4, Q5 and (in part) Q9 are worth noting as corrections rather than confirmations — in each, the draft's claim did not survive contact with the code: Q4 and Q5 had the facts backwards while the proposed triage disposition survived intact; Q3's review found a real defect in the containment check it examined (fixed in [#1218](https://github.com/apache/pekko-http/pull/1218)); and Q9's source scan had missed the one place the main sources write files (§5). + +Apache Pekko HTTP is a Scala/Java toolkit for building HTTP-based services and clients on top of Pekko Streams. It provides a full HTTP/1.1 and HTTP/2 implementation — parsing, connection management, marshalling, and a routing DSL of composable "directives" — as an **embeddable library**, not a standalone server. The application supplies the routes, the authentication, and the deployment. + +--- + +## §2 Scope and intended use + +Pekko HTTP is a library the application embeds. There is no Pekko HTTP daemon to secure independently of the service built on it. + +Caller roles: + +- **The embedding application** — fully trusted. Defines routes, supplies handlers, chooses configuration. +- **The operator/deployer** — trusted for the instance. Chooses what sits in front of the service (see §4), TLS termination, and limits. +- **The HTTP client** — **untrusted**. This is the adversary the model is mostly about. + +### Component families + +| Family | Modules | Entry point | In model | +| --- | --- | --- | --- | +| Core protocol | `http-core`, `parsing` | Wire bytes → `HttpRequest` / `HttpResponse` | **yes — primary surface** | +| HTTP/2 | `http2-tests` support in `http-core` | HTTP/2 framing, HPACK, streams | **yes** | +| Routing DSL | `http` | `Route`, directives, rejection/exception handling | **yes** | +| Marshalling | `http-marshallers-scala`, `http-marshallers-java` | JSON/XML entity conversion | **yes** | +| CORS | `http-cors` | `cors()` directive | **yes — see §5a** | +| Caching | `http-caching` | response cache directives | **yes** | +| Test kits | `http-testkit`, `http-testkit-munit`, `http-tests`, `http-compatibility-tests`, `http2-tests` | — | **no** — §3 | +| Benchmarks | `http-bench-jmh` | — | **no** — §3 | +| Lint / build / docs | `http-scalafix`, `docs`, `project`, `scripts`, `legal` | — | **no** — §3 | + +*(maintainer — the in/out split is confirmed by the Pekko maintainers; see §14 Q6)* + +--- + +## §3 Out of scope (explicit non-goals) + +- **Test kits, benchmarks, scalafix rules, build tooling and documentation sources.** A finding in `http-bench-jmh` or any `*-tests` module is `OUT-OF-MODEL: unsupported-component`. *(maintainer — §14 Q6)* +- **Pekko HTTP is not a WAF, and not an edge-hardened server.** The documentation says so plainly: applications *"should not be exposed to the public internet directly"* and an *"enterprise grade routing solution"* or a load balancer such as Apache HTTP Server or Nginx *"would be safer"* *(documented — `security.md`)*. See §4. +- **Pekko HTTP is not an authentication or authorization system.** It ships `authenticateBasic`, `authenticateOAuth2` and `authorize` directives, but these are *plumbing*: the credential check is a function the application supplies. Pekko HTTP has no user store, no session model, and no policy engine. *(maintainer — §14 Q7)* +- **The actor, stream, remoting and cluster layers** are out of scope here and covered by `apache/pekko`'s threat model. +- **Attackers who already control the embedding process** are out of scope. *(maintainer — §14 Q7)* + +--- + +## §4 Trust boundaries and data flow + +**The trust boundary is the inbound HTTP request.** Everything derived from wire bytes — request line, headers, cookies, entity, HTTP/2 frames — is attacker-controlled until the application validates it. + +Pekko HTTP's documented posture is unusual and important enough to quote in full: + +> "Pekko HTTP-based applications should not be exposed to the public internet directly. We believe Pekko HTTP behaves pretty well under most known Denial of Service attacks, but if you want the best security, you should use an enterprise grade routing solution. Even using a load balancing solution like an up-to-date version of Apache HTTP Server or Nginx would be safer than exposing Pekko HTTP-based applications directly to the public internet." +> — *(documented — `security.md`, "Security model")* + +Read carefully, this makes a **graded** claim rather than a binary one: Pekko HTTP asserts it *"behaves pretty well under most known"* DoS attacks — not that it is DoS-proof, and not that DoS is out of scope. That hedge was the single most consequential ambiguity in this model for triage; §14 Q1 has now resolved it into the content-vs-volume line, which is the rule triage actually applies. + +### Reachability preconditions per family + +- **Core protocol / HTTP/2** — reachable from raw wire bytes. The strongest in-model surface: a parser defect here needs no application cooperation. +- **Routing DSL** — reachable from a request that the application's own routes expose. A finding must name the directive and show a route shape a reasonable application would write. +- **Marshalling** — reachable from an entity body **only where the application has bound that marshaller to a route**. Findings in the underlying JSON/XML library belong to that library. +- **CORS** — reachable only where the application has installed the `cors()` directive. It is opt-in, not on by default. See §5a. +- **Caching** — reachable only where the application has installed a caching directive; cache-key correctness is the sharp edge. + +--- + +## §5 Assumptions about the environment + +- **Runtime.** A conformant JVM. Pekko HTTP does not defend against a hostile JVM or in-process attacker. *(maintainer — §14 Q7)* +- **Fronting infrastructure.** The documented expectation is that something sits in front in production *(documented — `security.md`)*. Per §14 Q1 this is load-bearing for *volume* only: the proxy is relied on for flood and slow-loris defence, not for bounding a single request, which is P1's job. +- **TLS.** Pekko HTTP can terminate TLS itself (`HttpsConnectionContext`) and this is supported, though the documented recommendation to front the service (§4) means termination is commonly the proxy's job in production. Cipher and protocol selection come from the JSSE context the application supplies — Pekko HTTP pins nothing and overrides no JDK default, so cipher strength is a deployment property. *(maintainer — §14 Q8)* +- **Client IP.** `remote-address-attribute` ships `off` *(documented — `reference.conf`)*. When on, the attribute reflects the **socket** peer, which behind a proxy is the proxy; forwarding headers never feed it. Header-derived client IP is opt-in at the call site: `extractClientIP` reads `X-Forwarded-For` / `X-Real-Ip` and is therefore client-controllable, while `extractDirectClientIP` reads the attribute alone and is not. Choosing between them is the application's decision (§14 Q4). *(documented — `MiscDirectives.scala`)* + +### What Pekko HTTP does not do to its host + +Negative claims, rarely written down and therefore verified against the source rather than asserted. The scan below covers the main sources of `http-core`, `http`, `parsing`, `http-caching` and `http-cors` *(documented — source scan, §14 Q9)*: + +- **Binds no port until the application calls a `bind*` method.** Binding is reachable only through the public `Http().bind` / `bindAndHandle*` entry points (`Http.scala:179-292`); nothing binds at class or extension initialization. +- **Installs no signal handlers and spawns no child processes.** No `sun.misc.Signal`/`SignalHandler`, `ProcessBuilder` or `Runtime.exec` in the main sources. +- **Registers no JVM shutdown hook.** There is no `addShutdownHook` anywhere in Pekko HTTP's main sources. Any hook an integrator observes comes from the actor system, not from here — see the caveat below. +- **Touches the file system only through directives the application installs.** The disk-serving directives (`getFromFile`, `getFromDirectory`) read. The upload directives **write**: `storeUploadedFile(s)` streams entity bytes to a destination the application's function chooses, and `fileUploadAll` buffers each part into a `Files.createTempFile` temp file registered with `deleteOnExit` (`FileUploadDirectives.scala:178-179`; in-flight [#1217](https://github.com/apache/pekko-http/pull/1217) moves those temp files into one directory per actor system, removed by a `CoordinatedShutdown` task after the system drains, in place of the per-file `deleteOnExit` registrations). Both are reachable only where the application binds them to a route; nothing writes at initialization or outside an installed directive. Beyond `FileUploadDirectives`, the main sources contain no `FileOutputStream`, `Files.write`, `FileWriter` or `createTempFile`. *(The draft claimed Pekko HTTP writes no files at all; th e scan missed the upload directives — corrected in review, §14 Q9.)* +- **Does not mutate process-global state at initialization** — no `System.setProperty`, `Security.setProperty`, `Security.addProvider` or `setDefault(...)`. + +**One inherited caveat, highlighted because it is easy to misattribute.** The claims above cover Pekko HTTP's own modules, not the `ActorSystem` it runs on. `apache/pekko` *does* register JVM shutdown hooks — one in `CoordinatedShutdown`, and a second in Artery when remoting is enabled — so an integrator running a Pekko HTTP service **will** observe shutdown hooks in the process. They arrive with the actor system and are modeled in the companion document. **Pekko HTTP itself adds none**, and that is the claim this section makes: *"a Pekko HTTP process has no shutdown hook"* is false, while *"Pekko HTTP registers no shutdown hook"* is true and is what §14 Q9 settles. *(maintainer — §14 Q9)* + +--- + +## §5a Configuration variants that change the security envelope + +Pekko HTTP's resistance to malformed and abusive input is almost entirely a function of `pekko.http.server.parsing.*`. These are the **documented, shipped** limits *(all documented — `http-core/src/main/resources/reference.conf`)*: + +| Setting | Default | What it bounds | +| --- | --- | --- | +| `max-uri-length` | `2k` | Request-line URI | +| `max-method-length` | `16` | Method token | +| `max-header-name-length` | `64` | Single header name | +| `max-header-value-length` | `8k` | Single header value | +| `max-header-count` | `64` | Headers per message | +| `max-content-length` | `8m` (server) | Entity size | +| `max-chunk-size` | `1m` | Single chunk | +| `max-chunk-count` | `100000` | Chunks per message | +| `max-chunk-ext-length` | `256` | Chunk extension | +| `max-comment-parsing-depth` | `5` | Nested comment recursion | +| `max-to-strict-bytes` | `8m` | `toStrict` materialization | +| `max-concurrent-streams` | `256` | HTTP/2 concurrent streams | +| `max-header-list-size` | `64 KiB` | HTTP/2 decompressed header list, **and** the accumulated HEADERS + CONTINUATION fragments for one header block | +| `max-connections` | `1024` | Server connections | +| `pipelining-limit` | `1` | In-flight pipelined requests | +| `idle-timeout` | `60 s` | Connection idle | +| `request-timeout` | `20 s` | Per-request handling | +| `uri-parsing-mode` | `strict` | URI leniency | +| `cookie-parsing-mode` | `rfc6265` | Cookie leniency | +| `verbose-error-messages` | `off` | Whether parse errors leak detail to the client — **secure default** | +| `illegal-response-header-name-processing-mode` | `error` | Blocks response-splitting via header names — **secure default** | +| `illegal-response-header-value-processing-mode` | `error` | Blocks response-splitting via header values — **secure default** | +| `server-header` | `pekko-http/${version}` | Advertises product and version | +| `remote-address-attribute` | `off` | Exposes socket peer address to routes | +| `transparent-head-requests` | `off` | HEAD handled as GET | + +**These limits are the model's quantitative spine.** A report that a request *within* every documented limit causes disproportionate resource use is `VALID`; one that simply exceeds a limit is P1 working, and one that needs a limit raised is `OUT-OF-MODEL: non-default-build` (§14 Q1). + +### The CORS defaults — ruled (§5b, §14 Q2) + +`http-cors` ships: + +| Setting | Default | +| --- | --- | +| `allowed-origins` | `"*"` | +| `allow-credentials` | `yes` | +| `allowed-headers` | `"*"` | +| `allowed-methods` | `["GET", "POST", "HEAD", "OPTIONS"]` | +| `allow-generic-http-requests` | `yes` | + +The module's own documentation states the interaction precisely: *"if parameter is `*` and credentials are not allowed, a `*` is set in `Access-Control-Allow-Origin`. Otherwise, the origins given in the `Origin` request header are echoed."* *(documented — `http-cors/reference.conf`)* + +So with **both** defaults in force, the directive **echoes the requesting `Origin` and allows credentials** — the maximally permissive CORS posture. Two facts bound how alarming that is: the `cors()` directive is **opt-in**, so this affects only applications that chose to enable CORS; and it is a documented, deliberate default rather than an accident. It is nonetheless the most permissive default in the project. Its disposition follows §5b: the shipped value is a compatibility choice, and a request to change it is not a vulnerability report (§14 Q2). *(maintainer — §14 Q2)* + +--- + +## §5b Security posture: hardening, not secure-by-default + +Pekko HTTP is a long-lived toolkit whose deployment base is inherited from Akka HTTP, and `http-cors` carries a second inheritance on top of that — its defaults arrived with the code donated by Lomig Mégard (`legal/CorsNotice.txt`). Its configuration defaults are chosen for compatibility with those deployments, in which operators have already been tasked with fronting the service (§4, §10.1) and choosing limits appropriate to their traffic. Changing a default to a more restrictive value breaks those deployments on upgrade, sometimes without a clear signal as to why — a tightened parsing limit surfaces as requests that used to work now failing with a 4xx. + +Pekko HTTP therefore takes the following position *(maintainer)*: + +1. **Defaults are compatibility choices, not security claims.** §5a lists every setting whose default affects the security envelope; §10 lists what the operator must do as a result. Read together they are the contract: Pekko HTTP states what it does not provide, and states what it expects of the operator instead. +2. **A report that a default should be more restrictive is not a vulnerability report.** It is a change request, and is closed as `BY-DESIGN: default-configuration` (§13). This covers the recurring ones: the CORS pair in §5a, `server-header` disclosing a version, and every limit someone considers too generous. +3. **Proposals to change a default are welcome, and belong on the development list.** The PMC will weigh them in good faith on their merits — the compatibility cost, whether a migration path exists, and whether a major version is in flight. Defaults can and do change; they change through project discussion, not as the remediation of a security report. +4. **If an implementation is wrong, Pekko HTTP fixes it.** Where a control does not do what it is documented to do once enabled, that is a defect, in scope, at the severity §8 assigns. **This is the sharp end of the model.** The §5a limits and the §8 properties are only worth what their implementations deliver: a `max-header-list-size` that fails to bound CONTINUATION accumulation, an `illegal-response-header-value-processing-mode = error` that lets a CRLF through, a `safeDirectoryChildPath` that can be walked out of — those are the findings this project wants. This posture governs which value ships as the default — never whether the mechanism works. + +**Users are free to strengthen any §5a setting**, and §10 says which ones matter most. What the project will not do is change the shipped value on their behalf. + +--- + +## §6 Assumptions about inputs + +| Surface | Input | Attacker-controllable? | Who must enforce what | +| --- | --- | --- | --- | +| Any bound route | Request line (method, URI, version) | **Yes** | Pekko HTTP: §5a length limits | +| Any bound route | Headers, incl. `Host`, `Cookie` | **Yes** | Pekko HTTP: count/length limits. App: semantic trust | +| Any bound route | `X-Forwarded-*`, `X-Real-Ip` | **Yes** — trivially spoofable | **App** — surfaced by `extractClientIP`, never validated; use `extractDirectClientIP` for access control or rate limiting (§14 Q4) | +| Any bound route | Entity body (fixed, chunked, streamed) | **Yes** | Pekko HTTP: size/chunk limits. App: content validation | +| HTTP/2 | Frames, HPACK table, stream IDs | **Yes** | Pekko HTTP: `max-concurrent-streams` | +| Route with marshaller | Entity parsed to a domain type | **Yes** | Underlying JSON/XML library + app | +| `cors()` | `Origin`, `Access-Control-Request-*` | **Yes** | Operator: §5a CORS config | +| File-serving directives | Path segments | **Yes** | Pekko HTTP + app — see §14 Q3 | +| Client API | Response from an upstream server | **Yes** if the upstream is untrusted | App: treat responses as untrusted | +| Config | `application.conf` | **No** — trusted deployment input | Operator | + +--- + +## §7 Adversary model + +**In scope:** + +- **The remote HTTP client.** Can send arbitrary bytes, malformed framing, oversized or deeply-nested input, many concurrent connections, and abusive HTTP/2 frame sequences. The primary adversary — though per §14 Q1 what this adversary achieves through sheer *volume* is the proxy's problem, not the library's. *(maintainer — §14 Q7)* +- **A malicious upstream server**, where the application uses the client API against an untrusted endpoint. *(maintainer — §14 Q7)* +- **A cross-origin web attacker**, where the application enables CORS. *(maintainer — §14 Q2)* + +**Explicitly out of scope:** + +- **Attackers with code execution in the embedding JVM.** Already inside. +- **The embedding application itself.** A route that deliberately leaks data is an application bug. +- **Side-channel observers.** No general timing guarantees are made about routing or parsing. Credential comparison is the exception: `Credentials.Provided.verify` compares in constant time (see §8 P8), so a timing finding there is in scope, while one against an application-supplied `provideVerify` is not. *(documented — `SecurityDirectives.scala`, `EnhancedByteArray.scala`)* + +--- + +## §8 Security properties Pekko HTTP provides + +| # | Property & conditions | Violation symptom | Severity | Provenance | +| --- | --- | --- | --- | --- | +| P1 | **Inbound messages are bounded** by the §5a limits; input exceeding them is rejected rather than buffered | OOM or unbounded buffering from input *within* documented limits | **Critical** | *(documented — `reference.conf`)* | +| P2 | **Response splitting is blocked**: illegal response header names and values are `error` by default, not passed through | CRLF in an application-supplied header reaching the wire | **Critical** | *(documented — `reference.conf`)* | +| P3 | **Parse errors do not leak detail to the client** — `verbose-error-messages = off` | Internal parse state or stack detail in a 400 response under defaults | High | *(documented — `reference.conf`)* | +| P4 | **Strict URI and RFC6265 cookie parsing by default**, rather than lenient normalization that invites smuggling | Two components disagreeing on a URI or cookie under `strict` | High | *(documented — `reference.conf`)* | +| P5 | **Connection and request lifetimes are bounded** — `idle-timeout 60s`, `request-timeout 20s`, `max-connections 1024`, `pipelining-limit 1` | A client holding resources indefinitely under defaults | High | *(documented — `reference.conf`)* | +| P6 | **HTTP/2 concurrency is bounded** — `max-concurrent-streams = 256` | Unbounded stream/state growth on one connection | High | *(documented — `reference.conf`)* | +| P7 | **HTTP/2 header blocks are bounded** — `max-header-list-size = 64 KiB` caps the decompressed header list *and* the accumulated HEADERS + CONTINUATION fragments, so a header block the peer never terminates with `END_HEADERS` cannot grow without bound; over-limit blocks get `GOAWAY(ENHANCE_YOUR_CALM)` rather than being buffered | Unbounded buffering from a CONTINUATION flood or an oversized header list | **Critical** | *(documented — `reference.conf`)* | +| P8 | **Credential comparison is constant-time** where the verifier calls `Credentials.verify` — it compares via `secure_==`, which XOR-accumulates over the full length after a length check, rather than short-circuiting on the first differing byte | Secret recoverable byte-by-byte from response timing against a `verify`-based verifier | High | *(documented — `SecurityDirectives.scala`, `EnhancedByteArray.scala:37`)* | + +**P1-P7 are default-on properties** — a notable contrast with `apache/pekko`, where the strongest controls must be switched on. P8 is the exception: it holds only for a verifier that calls `Credentials.verify`, which is why §10.4 states it as a downstream responsibility. The boundary of the DoS claim, once this model's largest ambiguity, is now fixed by the §14 Q1 content-vs-volume line. + +--- + +## §9 Security properties Pekko HTTP does **not** provide + +- **No claim of complete DoS resistance.** The documented wording is *"behaves pretty well under most known Denial of Service attacks"*, immediately followed by a recommendation to front it with a load balancer or enterprise routing solution *(documented — `security.md`)*. Per §14 Q1 this disclaimer is **scoped to volume**: Pekko HTTP does not claim to withstand floods, but it *does* claim that one in-limits request cannot provoke disproportionate work — that part is P1, and a violation is `VALID`. *(maintainer — §14 Q1)* +- **No edge hardening.** Rate limiting, IP reputation, request scrubbing, connection-count throttling beyond `max-connections`, slow-loris mitigation beyond `idle-timeout` — none are provided, and none are planned. *(maintainer — §14 Q1)* +- **No authentication or authorization.** The security directives are plumbing; the credential check is the application's function. *(maintainer — §14 Q7)* +- **No CSRF protection.** No token issuance or verification is provided. *(maintainer — §14 Q7)* +- **No output encoding / XSS defence.** Pekko HTTP renders what the application marshals. *(maintainer — §14 Q7)* +- **No trusted client-IP derivation from headers.** `extractClientIP` surfaces `X-Forwarded-For` / `X-Real-Ip` without validating them, and Pekko HTTP has no trusted-proxy chain configuration. `extractDirectClientIP` is the trustworthy accessor, but it yields the last proxy rather than the client. See §5 and §14 Q4. + +### False friends + +- **The security directives are not a security *system*.** `authenticateBasic` and `authenticateOAuth2` route credentials to an application-supplied verifier; they impose no password policy, no rate limiting and no lockout. They *do* supply a constant-time comparison (§8 P8) — but only to a verifier that calls `Credentials.verify`; one that pattern-matches the secret out and uses `==` gets none of it. +- **`allowed-origins = "*"` does not mean "no credentials are exposed".** Combined with the shipped `allow-credentials = yes`, it echoes the caller's `Origin` (§5a). +- **`remote-address-attribute` is not the client IP behind a proxy.** It is the socket peer. +- **`max-content-length` is not a global memory bound.** It bounds one entity; concurrent connections multiply it. +- **A rejection is not a failure.** The routing DSL's rejection mechanism is control flow, not a security control — an unhandled rejection can fall through to a different route. + +### Well-known attack classes left to the caller + +- **Request smuggling / desync** between a fronting proxy and Pekko HTTP — inherently a two-party property; strict parsing (P4) helps but cannot settle it alone. +- **Slow-loris and connection exhaustion** — `idle-timeout` and `max-connections` (P5) bound what one connection holds and how many are accepted, but exhausting those bounds by volume is disclaimed (§14 Q1). A single connection that evades `idle-timeout` while holding resources is the in-scope version. +- **Decompression bombs** in request bodies, where the application enables decoding. Review Comment: nit: Decompression bombs left to the caller is not entirely true. The operator still has options to configure some maximums in the request (e.g., decode-max-bytes-per-chunk and `decode-max-size`: https://github.com/apache/pekko-http/blob/85d7243e745d68c987b79c5c4d56958f582a5c34/http/src/main/resources/reference.conf#L41-L50 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
